条件でフローを制御する

最終更新日: 2021年10月13日
R8 | R9

物品購入伺いワークフロー

ここでは「物品購入伺い」を例に説明します。図1のモデル定義を用います。

図1 物品購入伺いモデル

サンプル (1) 後続の承認者をスキップさせる

ルール

次のルールを適用します。金額によって「次の承認者がスキップされる」というものです。

金額課長承認部長承認本部長承認社長承認(決裁)
50万円未満---
50万円以上100万円未満--
100万円以上1,000万円未満-
1,000万円以上

アカウント

次の5つのアカウントを用意します。

アカウント氏名
user1申請者
user2課長
user3部長
user4本部長
user5社長

フローパターン

「順次・順次・順次・順次・順次フロー」を用意します。 説明文に「申請→課長承認→部長承認→本部長承認→決裁」と記載します。最後の「決裁」は「社長承認」を兼ねるとします。

図2 フローパターンの追加

フロー参加者

user1からuser5を図3のように割り当てます。

図3 フロー参加者の追加

フロー設定で条件を指定する

図3で用意した「営業一部物品購入伺いフロー」を選択すると、図4のような初期ルートとなります。

図4 初期状態のフロー設定

ここで「条件設定」欄を用意します。課長承認後、金額によってすぐに決裁とする条件を加えます。条件部の記述ルールは次のとおりです。

  • 条件記述では「起点」と「終点」が必須になります。ノードのIDになります。図において "1.順次" と記載されているノードの "1" の部分がノードIDです。
  • 「終点」に、存在しないノードIDを指定すると、自動的に「決裁」(図中における右側の丸)へ向かいます。例えば "999" などを使うとよいでしょう。
  • 条件部はサーバサイドJavaScriptのコードを記述します。return 文で true または false を返すようにしてください。この条件が成立した(trueが戻された)ときに、終点のノードIDへ移動します。
  • 条件が空の場合は、必ず終点のノードIDへ移動します。
  • 条件を一つ以上追加すると、標準のルートは消去されます。(図5では、図4に元々あった標準の直線的なルートが消えています。)
return kian.price < 500000
図5 条件を1つ追加する

「挿入」ボタンを押下し、申請者から課長承認へのルートを加えた例を図6に示します。ここは条件部を空としています。これによって "1" から "2" へのルートが描画されます。

図6 条件部が空のルート設定

すべてのルートを設定した状態を図7に示します。

図7 すべての条件を設定

実行

課長決裁

50万円未満の購入伺いを行った例を図8,図9に示します。

図8 50万円未満の購入伺い
図9 ワークフローの開始(申請)

課長アカウント(user2)でログオンし、承認します。 この段階で決裁となり、ワークフローは終了します。(図10,図11)

図10 課長による承認行為
図11 課長承認が決裁となる

部長決裁

50万円以上100万円未満の購入伺いを行った例を図12に示します。

図12 50万円以上100万円未満の購入伺い

課長による承認直後が図13となります。フロー状態は「課長承認」となります。

図13 課長承認

続いて部長による承認を行ったのが図14となります。この段階で決裁となります。

図14 部長承認が決裁となる

本部長決裁

100万円以上1,000万円未満の購入伺いを行った例を図15に示します。

図15 100万円以上1,000万円未満の購入伺い

本部長による承認を行ったのが図16となります。この段階で決裁となります。

図16 本部長による承認が決裁となる

社長決裁

1,000万円以上の購入伺いを行った例を図17に示します。

図17 1,000万円以上の購入伺い

社長による承認を行ったのが図18となります。

図18 社長決裁まで行った

サンプル (2) 最初の承認者を選択する

ルール

次のルールを適用します。上の例に加えて、金額によって「最初の承認者」が変わるというものです。

金額課長承認部長承認本部長承認社長承認(決裁)
50万円未満---
50万円以上100万円未満---
100万円以上1,000万円未満---
1,000万円以上---

設定は図19図20のようになります。

図19 条件の設定 (旧画像)
図20 条件の設定 (更新版)
"旧画像" ではなく "更新版" をご利用ください。更新版の違いは次の通りです。(1) 1,000万円以上の商品を申請すると課長、部長、本部長、社長の順に承認しなければならなかった。No.4のルールを追加した。(2) 金額に応じて次の承認者が最終決済者になるため、旧画像の No.5, No.7, No.9 は実行されることがないため削除した。

仕様・制約

申請後のワークフローはいったん却下(または差し戻し)すること

申請後(処理中)のワークフローに対する条件部の変更を行うことはできません。この場合、ワークフローが正常に処理されません。このワークフローはいったん却下するか申請者へ差し戻しを行い、それからワークフロー設定を修正してください。ワークフロー設定完了後に、再び申請を行ってください。

条件部の記述

条件部は複数行にわたって記述することができます。このため複雑な条件を記述できます。例を示します。

var p = kian.price;
if (p < 500000) {
  return true;
}
return false;

項目名にはキャメル記法が適用されます

「モデルID」は設計情報に記載した名前がそのまま利用できます。(上記例では "kian" という表記になります。)

「項目ID」はキャメル記法が適用されます。
例えば項目IDが "group_cd" の場合、スクリプト内では "groupCd" と表記します。

return koubai_model.groupCd == 1

循環について

条件記述の誤りで、フローが循環するような場合は正しく動作しません。設定に際しては循環にならないよう、ご注意ください。

利用できる暗黙変数について

条件を記述するスクリプトでは、当該モデル(ストアモデル)のみが参照できます。他のスクリプトで利用できる暗黙変数 p などはすべて利用できません。(このスクリプトではモデルの値を使って条件判定を行うことに特化したものとなっています。)

スクリプトを変更したときの動作

運用中(テスト中を含む)にスクリプトを修正した場合、ワークフロー利用者(申請者、承認者など)をいったんログアウトし、再度ログオンすることで新しいスクリプトが有効になります。

スクリプトを修正しても、再ログオンしない限り、修正したスクリプトは反映されません。