ある特定のベンダーに対する発注がキャンセルされた場合に、メールにて通知するというものです。
この仕組みを理解したいと思うのですが、せっかくですからちょっと違うケースでトライしてみようと思います。
想定するシナリオとしては、次の様に考えてみました。
顧客 Amadonは Minotta Film にとって超大口顧客であり、Amadonからの受注には特別な注意をはらって納入まで専任者にステータスのトラックをしてもらいたい。
このためAmadonからの受注を受けたら専任者にメールを自動発信し、専任者が見落とすことのないように管理できる様にする。
（実際には Ama○on からの発注は１日複数回EDI連携したりするのでいちいちメール飛ばしていたら大変ですが、）
さて、この仕組みを実現するにはどうすれば良いのでしょうか？
iDempiereにはDocument の Status が変化したことをトリガーとして処理を開始する機構があります。
受注伝票が起票されたとき、すべての受注を確認し、Business Partner が Amadon だった場合に Email を専任者に送るようワークフローを設定します。
今回は 1.7 受注のプロセスが対象となります。
1.7 受注をブレークダウンし、今回の投稿のプロセスを（無理矢理）書くと下の様になります。
なんのことはないのですが、 受注して、それが Amadonからだったらメール発信するだけです。オーダー追跡は専任者の作業とします。（本来はiDempiereのステータスを確認したりしますが、設定上意識するのはメールを出すところのみ範囲とします）
マスター系からいきます。Admin 広瀬さんでログインします。
専任者は多田さんにします。
Menu -> System Admin -> General Rules -> Security -> User
メールアドレスは idempiere3@xxxx.com
メールを発信しますので、以前の投稿と同様にメールのテンプレートを作成します。
Menu -> Partner Relations -> Mail Template
メールテンプレートを新規作成し、登録します。
Organization: *
Name/Subject: SO from Amadon
Message: We've got SO from Amadon. We have to treat this order carefully.
とでもしましょう。（なんでも構いません）
つづいてワークフローを追加します。
Menu -> System Admin -> General Rules -> Workflow -> Workflow
ワークフローを新規追加
なんちゃって仕様書でこれまでやってきましたが、若干記述が増えると情報量的とスペースの関係に限界が見えてきます。イメージとしてはいいのですが、業務として仕様を表すためには別に書式を用意した方がよさそうです。
Search Key: Process_SO_Amadon_Alert
Name : Process_SO_Amadon_Alert
Workflow Type: Document Value
Table: C_Order
Document Value Logic: @docstatus@=VO
Data Access Level: Client+Organization
Author: Me!
一度セーブして、Node を追加していきます。
追加するノードは３つ
(Start)
Action: Wait
(SendEmail)
Action: Email
Email Address: idempiere3@xxxx.com
Mail Template: SO from Amadon
(End)
Action: Wait
(Start) と (SendEmail) に Transition を追加します。
(Start)
Sequence: 10
Next Node: (SendEmail)
Sequence: 20
Next Node: (End)
(SendEmail)
Sequence: 10
Next Node: (End)
(Start) の Transition に３つの Condition を追加します。
Sequence: 10
And/Or: or
Condition: C_Bpartner_ID_BusinessPartner = （登録した BusinessPartner の ID)
Sequence: 20
And/Or: and
Condition: IsSOTrx_SalesTransaction = Y
Sequence: 30
And/Or: and
Condition:C_DocType_ID_Document Type = (Sale Order の Document ID )
-------------------------
Sequence:20 は、C_Order テーブルは、 Sales Order と Purchase Order 両方で使っており、IsSOTrx フィールドが Y か N で識別しているそうです。
今回の場合は IsSOTrx フィールドが Yes のものを選別しています。
例えば顧客Amadon が仕入れ先にならないと明確であれば、この Sequence:20の Condition は必要無いかもしれません。
--------------------------
ここで、 BusinessPartnerのID やらDocument ID やら出てきます。
内部コードが必要なため、ＤＢを見てみます。
サーバーに接続し、PostgreSQLを開きます。
ＤＢまわりのことは以前の投稿をご参照ください。
「AWS EC2 CentOS6.5 に もう一度はじめからPostgreSQL9.3 を インストールしてみた（その３）」
BusinessPartner ID だけでなく、 Document IDもクライアント毎に異なるため、自分のクライアントIDを把握する必要があります。
----------------------
[root@ip-xxxxx ~]# psql -d idempiere -U adempiere
psql (9.3.5)
Type "help" for help.
idempiere=#
idempiere=# select ad_client_id, name from ad_client;
ad_client_id | name
--------------+-----------------------
11 | GardenWorld
0 | System
1000000 | Net Search Technology
1000001 | Minotta Film
(4 rows)
-----------------------
Business Partner を調べます
-----------------------------
idempiere=# select c_bpartner_id, ad_client_id, name from c_bpartner;
c_bpartner_id | ad_client_id | name
---------------+--------------+-----------------------
119 | 11 | GardenUser BP
112 | 11 | Standard
1000025 | 1000001 | ヨドゴシ 新宿店
1000027 | 1000001 | Amadon
1000024 | 1000001 | ヨドゴシ 練馬店
1000056 | 1000001 | 多田
(61 rows)
-----------------------
大きく間引いていますが、 client 'Amadon' のBusinessPartner ID は 1000027 であることがわかります。Document Type を調べます。
----------------------------
idempiere=# SELECT c_doctype_id , name FROM c_doctype WHERE ad_client_id = '1000001';
c_doctype_id | name
--------------+------------------------------
1000047 | GL Journal
1000048 | GL Journal Batch
1000049 | AR Invoice
1000050 | AR Invoice Indirect
1000051 | AR Credit Memo
1000052 | AP Invoice
1000053 | AP CreditMemo
1000054 | Match Invoice
1000055 | AR Receipt
1000056 | AP Payment
1000057 | Allocation
1000058 | MM Shipment
1000059 | MM Shipment Indirect
1000060 | MM Vendor Return
1000061 | MM Receipt
1000062 | MM Customer Return
1000063 | Purchase Order
1000064 | Match PO
1000065 | Purchase Requisition
1000066 | Vendor Return Material
1000067 | Bank Statement
1000068 | Cash Journal
1000069 | Material Movement
1000070 | Physical Inventory
1000071 | Material Production
1000072 | Project Issue
1000073 | Internal Use Inventory
1000074 | Cost Adjustment
1000075 | Binding offer
1000076 | Non binding offer
1000077 | Prepay Order
1000078 | Customer Return Material
1000079 | Standard Order
1000080 | Credit Order
1000081 | Warehouse Order
1000082 | Manufacturing Order
1000083 | Manufacturing Cost Collector
1000084 | Maintenance Order
1000085 | Quality Order
1000086 | Distribution Order
1000087 | Payroll
1000088 | POS Order
1000089 | AR Pro Forma Invoice
1000090 | GL Document
1000091 | Fixed Assets Disposal
1000092 | Fixed Assets Addition
1000093 | Fixed Assets Depreciation
1000094 | In-Transit Material Movement
(48 rows)
----------------------------
ここでは Standard Order として考えます。IDは 1000079 となります。
--------------------------
余談１
書籍ADEMPIERE 3.4 ERP SOLUTIONS に Business Partner ID についてはAdempiereからの確認方法についての記述があったのですが、よく分からず挫折。
いずれにせよ Document Type ID は調べる必要があったのでＤＢを直接見ました。
余談２
せめてＤＢを覗くツール使った方が楽なのですが、今のところＳＱＬで間に合うのでもちっとこのまま行きます。
余談３
Condition の Value に式を書いてあげればＤＢ覗く必要ないのかもしれません。
例えば Document Type ID は
@SQL=SELECT c_doctype_id FROM c_doctype WHERE ad_client_id = @#AD_Client_ID@ AND name = ’Standard Order';
とか書けばできるかも？？
でもなんでも「汎化」すれば良いとも思いません。変更の確率を考えて実現方法を選択するのも重要だと思います。（コーディング工数だけでなく、テスト工数や実行時のリソースも含めて）
このあたりの記述は以前の投稿「iDempiere アプリケーション辞書 画面のカスタマイズ（Default Logic)」参照ください。
--------------------------------
最後に Workflow Process_SO_Amado_Alertまで戻り、Start Node に (Start) をセットしてからValidateWorkflow ボタンを押し、整合性をチェックします。
（あれ？いままでやってなかったけどいいのかな？たぶんNodeなど変更したらチェックすべきなのでしょうね。）
書籍ADEMPIERE 3.4 ERP SOLUTIONS では
Node (Start) の Condition の３つをすべて or を指定してありますが、おそらく誤植だと思います。
また、ワークフローの画面も前の節で使った Process_Requisition のものなので、これも？？です。
時折トラップありますので、確認が必要ですね。
0 件のコメント:
コメントを投稿