みんなの投稿

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

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

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

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

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

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

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

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

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

なんどもすみません。

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

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

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

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

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

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

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

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

以上です。

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

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

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