iDempiere 想定業務フロー 1.1 購買依頼 Requisition / ワークフロー workflow 実行

設定に対してどのようにワークフローが処理されるか確認します。


トランザクションを開始する前に必ず Cache Resetを行ってください。
設定した Workflow が反映されていないことがあります。
（わたしはこれに気がつかずに検証時間を多く無駄にしてしまいました。。）
Menu -> System Admin -> General Rules -> Cache Reset


User の Role を持つ西島さんでログオンします。

Menu -> Requisition-to-Invoice -> Requisition　から

ここでは次の３つの 購買依頼を作成しました。
購買依頼１
Document Type: Purchase Requisition
Date: 01/26/2015
Price List: PO-PriceList
Product: Portable two (@¥6,000)
Quantity: 8  (Total ¥48,000)

購買依頼２
Document Type: Purchase Requisition
Date: 01/26/2015
Price List: PO-PriceList
Product: Portable two (@¥6,000)
Quantity: 10  (Total ¥60,000)

購買依頼３

Document Type: Purchase Requisition
Date: 01/26/2015
Price List: PO-PriceList
Product: Portable two (@¥6,000)
Quantity: 12  (Total ¥72,000)

購買依頼４

Document Type: Purchase Requisition
Date: 01/26/2015
Price List: PO-PriceList
Product: Portable two (@¥6,000)
Quantity: 20  (Total ¥120,000)

（数量と合計金額が異なるだけ）

それぞれの結果です。

購買依頼１

 購買依頼２

 購買依頼３

購買依頼４

結果をまとめると

購買依頼１：48,000 Completed
購買依頼２：60,000 Completed
購買依頼３：72,000 Suspended
購買依頼４：120,000 Cannot Approve - No Approver

ここから、購買依頼３のみ上長の承認プロセスに入ったことがわかります。

もし、Process_Requisition の 新たに追加した Node "Give me your approval." に Conditionを登録しなかった場合はどうなっていたでしょうか？
（言い換えると常に App

結論は次の様になります。
購買依頼１：48,000 Completed
購買依頼２：60,000 Suspended
購買依頼３：72,000 Suspended

購買依頼４：120,000 Cannot Approve - No Approver

これは Role に次の様に定義したためです。
Minotta Film User / Approval Amount: 50,000
Minotta Film Admin / Approval Amount: 100,000

User Role の西島さんは ¥50,000までしか承認権限を持っていません。
このためIsApproveのチェックで ¥50,000を超えていた場合、Supervisor（上司）に承認を求めるロジックが働きます。

今回設定した Condition は、総額が ¥70,000を超えていたら Approval プロセスに入るというものです。

わたしはちと混乱して、理解に時間がかかりましたが（Cache Reset のこともあり）、 Conditionは iDempiere の内部処理であるIsApprove を起動する条件というだけです。
あくまでも承認ロジックは下記の設定により決まることが基本です。

１：ユーザーの上長の設定（組織階層含む）
２：ロールの承認限度額の設定

Workflow に設定する Condition は、このルールに例外的な運用をするものだと思います。
上の例では、本来 user role である西島さんは ¥50,000までしか承認できません。
しかし Condition により ¥70,000 までは "Give me your approval."プロセスには入らず、伝票ステータスを Completed にします。
¥70,000を超えたら "Give me your approval." に入るのですが、この価格は user role には承認権限がないため、直ちに上司にエスカレーションされます。

エスカレーション先の多田さんも、iDempiere の role は user であるため、この価格の承認権限は持っていないため、さらに上司の広瀬さんにエスカレーションをします。
(Supervisor に多田さんの名前を入れても同じrole であれば iDempiere上ではスルーされるだけです。異なるrole で適切な決済権限を持っていて初めて意味を持つエスカレーションとなります。）

広瀬さんは admin role のため、 ¥100,000まで承認できます。
このため平瀬さんは画面を開くと未処理の workflow があることが通知されており、必要な承認をすることが出来ます。
上にあるように ¥100,000を超える金額の場合の承認権限を持った role が存在せず、 No-Approver となり先に進むことができなくなります。

広瀬さんでのログイン画面

ワークフローを開いて、メッセージを指定した画面

Answer に Yes/No を指定し、下のOK ボタンをおします。

これで Purchase Requisition が承認され、status が Completed となりました。

ちなみに user role の Approval Amount を ¥70,000にして、 Transition の Condition を削除すると、上記と同じ結果を得ることになります。

今回感じたのは、承認行為の伝搬を「なにで」定義するのが良いのか？ということです。
 Role/Supervisor/Organization/Workflow(condition)

結論は、iDempiereを導入する組織により適切な実現方法は変わるのでしょうし、構造を理解した上で最適な方法（少なくてもその時点で）を提案することがサービスの提供側からすると力量となるのでしょう。

現時点個人的には Role をうまく活用すべきだと感じています。
このテストでは Admin / User というRoleしかありませんが、基本的に呼び方は　「普通の担当者」と「管理権限を持つ人」程度の区分けであり、通常の業務における決済権限をコントロールするのに適した呼称を持った定義ではありません。

実際の業務で Roleを考えたとき、少なくとも次を実現できるレベルまでRoleを作成する必要があります。もちろん異なる軸が追加されたら直積で増えるためあっという間に Roleは管理不可能なレベルに増加してしまう恐れがあります。

１：販売・購買・経理などの組織で行える業務を識別できる
２：決済権限による決済額上限を識別できる

Roleを管理不能なまで増やさないための、奥の手として Condition を利用するのもありではないでしょうか？

余談ですが、
１：今回 workflow のNode名は "Give me your approval."としましたが、iDempiere の標準としては (DocApproval) など、括弧をつけて作成するようです。私はこの名前が予約語的な意味を持つのか持たないのかを確認するためにあえて別の名前を付けました。
２：Adempiere 書籍では、　System ユーザーでログインしているようです。今回は他クライアントへの影響を出さないために Minotta Film Admin ユーザーで作業を行いました。
このため、Node (DocPrepare) に元々あった Transition の Sequence (10) が変更できなかったため、新規追加の Sequence は (5)  という違和感のあるナンバリングとなっています。
３：Adempiere 書籍では、Workflow の章にCache Reset について記述が見つけられませんでした。workflow 修正後は必須です。（前の章でドキュメントタイプを変更した時にはCache Reset の記述はあったのだけど、、、）