みんなの投稿

2026/01/07 11:39

【サブテーブル内を更新キーにした複数レコードの自動更新】

現在、備品発注・管理システムのアプリを作成しています。

やりたいことは以下の通りです。
(1)備品管理マスターアプリ
 ①備品コード
 ②備品名
 ③最大在庫数
 ④商品URL
 ⑤申請状況
(2)申請用のアプリ(発注者へ発注依頼をするためのアプリ)
 マスターの備品コードに紐付けてルックアップで備品情報を取得
 ↓
 複数の商品発注申請を可能にするため、サブテーブルで表を作成
 ↓
 保存し、申請
(3)備品管理マスターアプリ
 申請が完了した商品に対する申請状況を[済]に変更する
 ↓
 これにより、申請用アプリにて済になっている商品に対しての
 二重発注ができないようにルックアップで制限をかける

【現状の課題】
申請用アプリにTISさんの「アプリ間レコード更新プラグイン」を入れましたが、サブテーブルが対応していなく、複数商品を申請した際に、複数レコードの更新が出来るようにしたいのですが、現状はそのような設定はできなさそうです。
何か良い案がありますでしょうか。

宜しくお願いいたします。

3件のコメント (新着順)

横からすみません🙇🏻

興味あったので、kintone芸人によるカスタマイズ相談サポート!|カスタムGPTで、「テーブル内の特定列値をキーにして別アプリのレコードを更新するプラグインが知りたい」と訊いてみました。

[回答]
「テーブル内の特定列の値をキーにして別アプリのレコードを更新する」ことを“そのまま”実現できる既製プラグインはかなり限定的で、要件次第では カスタマイズ(JavaScript)前提になるケースが多いです。

で、更に訊いてみたところ、プラグインでkrewDataなら「保存後に発注書のテーブルの備品コードをキーに備品マスタの発注フラグを”済”にして、プロセス管理のステータスが”検収済”となったら、”未”に戻す」というようなことはできるようです。
(実務を考えると、検収までをプロセス管理に入れるのが💡)

それ以外だと、JSカスタマイズに行ってしまうようです。
(ちなみに、CUSTOMINEだと全部書き切れると思いますが、「TiSのプラグインを導入してみた」ということで、詳細説明は割愛させていただきます。)

ご参考になりますかどうか…


Isol
建設業
2026/01/09 11:54

ご丁寧にありがとうございます。
テーブル内のフィールドをキーにして別アプリのレコードを更新する方法ですが、TISさんの条件分岐プラグインで実現ができました!

今回教えて頂いた、GPT知らなかったので、教えて頂き大変ありがたいです。
ありがとうございます!

ふゆき
製造業
2026/01/07 14:17

(2)申請用のアプリの「テーブルの中のData」を
(3)備品管理マスターアプリに「copy」したい

けど、アプリ間レコード更新プラグイン では設定できない

ので、変わりとなるPluginを探している

と云うことで、よろしいでしょうか?

であるならば、TISさんのブランド違い
の Boost! Upsert
なら可能みたいです テーブルからレコードにコピーする方法

情報まで!

ちなみに、(2)申請用のアプリのテーブル内に
申請状況(フィールド)を設け、初期値 [済]の設定が必要となると思います

 👆これは Boost! Style を使い「非表示」にすることができます

---検証の追記(Pluginの設定画像を追加添付)---

検証の結果、上記 取消線部分は不必要になりました
詳細は、添付にてご確認をお願いします😊

 画像の端が読めないときは、ココ を参照ください😎


Isol
建設業
2026/01/07 14:33

ご回答ありがとうございます。
お試しでやってみます!
助かりました。

ふゆき
製造業
2026/01/08 10:05

検証してみました スミマセン🙇 
初期値 [済]のフィールドは必要なくなりました

前出のコメントを修正してありますので
ご確認をお願いします😊

Isol
建設業
2026/01/09 11:55

ご丁寧に修正までして頂き本当にありがとうございます。

確認させて頂きました。
指定したいフィールドをプルダウンから文字列に変更することで実現できました!

この度はありがとうございました。

suji バッジ画像
2026/01/07 12:32

こんにちは。

内容について確認です。

今回のやりたい事として⑤の申請状況を[済]にしたい、ということですが
いつまでも済の状態だと困ってしまうと思います(在庫使い切り備品なら大丈夫ですが)。
この部分はどう解決している、もしくは解決する予定でしょうか?

また、このアプリとは別に、備品の在庫管理アプリを持っている、という認識でよいでしょうか?


Isol
建設業
2026/01/07 13:10

ご返信ありがとうございます。

いつまでも済の状態だと困ってしまうと思います(在庫使い切り備品なら大丈夫ですが)。
この部分はどう解決している、もしくは解決する予定でしょうか?
→申請アプリの方にプロセスを組んでおり、承認者が承認し、ステータスが[発注済み]になったら、[済]に切り替えるように設定しようと思っております。

現在存在するアプリは
①備品管理マスターアプリ
②備品発注依頼アプリ
上記の2点になります。

宜しくお願いいたします。

suji バッジ画像
2026/01/07 13:44

回答ありがとうございます。
数点追加確認です。

① 念のため確認ですが備品発注依頼アプリ=申請アプリとの認識でよいでしょうか。
② 申請アプリのプロセス管理ですが、承認者が承認すると
  申請アプリのステータスが[発注済み]になる、という理解でよいですか?
③ ②で[済]になったものは、誰がどのタイミングで[済]の状態を解除しますか? 
  例)備品が納品されたタイミングで備品在庫管理担当者が編集
④ 在庫が足りないな~、という判断は実在庫の状況などを見て
  備品在庫管理担当者が別途判断する、ということよいですか?

Isol
建設業
2026/01/07 14:32

① 念のため確認ですが備品発注依頼アプリ=申請アプリとの認識でよいでしょうか。
→はい。そうです。
② 申請アプリのプロセス管理ですが、承認者が承認すると
  申請アプリのステータスが[発注済み]になる、という理解でよいですか?
→はい。そうです。
③ ②で[済]になったものは、誰がどのタイミングで[済]の状態を解除しますか? 
  例)備品が納品されたタイミングで備品在庫管理担当者が編集
→発注者が発注を完了すると、レコード自体が完了ステータスになり、このタイミングでマスターの申請状況も済から[完]に自動で更新することで、再度在庫の申請を可能にしたいと思っています。
④ 在庫が足りないな~、という判断は実在庫の状況などを見て
  備品在庫管理担当者が別途判断する、ということよいですか?
→はい。そうです。

suji バッジ画像
2026/01/07 15:05

なんどもすみません。

③ ②で[済]になったものは、誰がどのタイミングで[済]の状態を解除しますか? 

こちらがうまく伝わってないようなので再度…。
想定フローを図示できるとわかりやすいのですが、テキストで記述します。

パターン1
在庫担当者Aが在庫が無いと気づく
→備品管理マスターアプリを見たら[済]になってない
→在庫担当者Aが備品発注依頼アプリで依頼する
→備品発注依頼アプリで承認される
→承認されたので備品管理マスターアプリが[済]になる
→発注済みの備品が納品され、在庫が補充される
※フロー終了※

~数カ月後~
在庫担当者Aが在庫が無いと気づく
→備品管理マスターアプリを見たら[済]になっている
→他担当者が手配済みであると認識
<在庫が補充されず不足が発生>

起こりえる事象:備品管理マスターアプリが[済]のままなので
次のサイクルで備品在庫が不足した場合も手配済みと認識されてしまう



パターン2
※フロー開始※
在庫担当者Aが在庫が無いと気づく
→備品管理マスターアプリを見たら[済]になってない
→在庫担当者Aが備品発注依頼アプリで依頼する
→依頼アプリが未承認のタイミングで在庫担当者Bも在庫が無いと気づく
→備品管理マスターアプリを見たら[済]になってない
→在庫担当者Bが備品発注依頼アプリで依頼する
<依頼が重複し、過剰発注されてしまう>

起こりえる事象:依頼アプリの提出→承認までの間に再度在庫チェックが
なされると、依頼が重複してしまう




なお、kintoneとは別の話になりますが、在庫管理はある程度
データの連続性を持たせないと厳しいです。取扱品目数と頻度にもよりますが。
また、不足・補充のルールも明確にしておく必要があるかと考えます。

以上です。

Isol
建設業
2026/01/09 11:57

ご丁寧にありがとうございます。

現在パターン1の運用になっておりますので、運用で利用者が混乱しないようフローを再度見直したいと思います。

この度は本当にありがとうございました!