2015年1月30日金曜日

iDempiere レポート Report 作成 その2

前回の続きです。

今回はテンプレートをコピーして、修正してきます。
Menu -> System Admin -> General Rules -> Printing -> Print Format
から Order_Header のテンプレートを選択します。

Copy Record アイコンをクリックし、新しくプリントフォーマットを作ります。
Name は適当に変えて保存しておきます。(あとで再修正しますので、適当に、、)
この時点では子タブの中は空白なので驚かないでください。
一度保存したら、ギヤマークのプロセスアイコンをクリックし、 表示されるCopy/Create ボタンを押します。
プリントフォーマットの一覧が出てきますので、そこから先ほどと同様 Order_Header **TEMPLATE** を選択します。

この処理が完了すると、 Name も Order_Header **TEMPLATE** に戻ってしまっていますので、改めて Name を修正して保存します。

これらと同じ作業を Order_Line にも行い Header と Line を新たに作成しておきます。

現時点では Header は **TEMPLATE** のコピーなので、ここから呼び出される明細行はオリジナルのまま、つまり新しく作った Line のフォーマットをいくら修正しても反映されません。

新たに作成した Order_Header Minotta Film を修正して、 Order_Line Minotta Filmを呼び出すように加工します。

Order_Header Minotta Film を開き、子タブのFormat Itemから Order という名称の行を探します。
Included Print Format の指定を Order_Line Minotta Film に修正し保存します。

これであ Order_Header Minotta Film を呼び出せば、明細行も Order_Line Minotta Filmになりました。

次は Order の印刷を行う時、 Order_Header Minotta Film を呼び出すように指定します。
指定方法は前回あらかじめ記載したので省略します。

iDempiere レポート Report 作成 その1

表示する項目名など、始め「なにがなにやら」ですが、いろいろいじって試してみるしかないと思います。
書籍 ADEMPIERE 3.4 ERP SOLUTIONには、サンプルが記載されているので、書籍お持ちの方は「とっかかり」として言われるがままにやってみるのが良いかもしれません。

また、日本語環境で作業を行うと、より項目名がわかりやすく作業のイメージを掴みやすいかもしれません。

iDempiere 日本語化ふたたび (iDempiere Lab版)



iDempiere レポート Report 作成 その1

これまでレポートはよく分からなくて、手つかずで来てしまいました。

書籍 ADEMPIERE 3.4 ERP SOLUTION の中にレポート系の設定手順がありましたのでやってみます。

書籍には、レポートの書式の例も記載さているのですが、こういったデザインに関するものをなぞるのは憚られるため、iDempiere のレポートの構造とレポート作成の操作についてのみ私の理解を書こうと思います。

レポートの日本語問題ですが、前回の日本語化によりレポートでも日本語を表示できるようになったのはいいのですが、英語環境では相変わらずです。(これも設定すればいいのでしょうが、、)

というわけで、設定は英語環境で、レポートの確認は日本語環境で行います。
(住所などアルファベットで書けばいいのですが、、せっかく日本語化もしたことですし<-自分でもちょっと意味不明ですが、、)

まず以前やった Standard Order で送ったメール(標準のレポート)はこんな感じでした。

 修正したのはこんな感じです。まずiDempiere のレポートですが、下の画面を見てください。

Menu -> System Admin -> General Rules -> Printing -> Print Format
様々なレポートフォーマットがあるのがわかります。
色つきの枠が今回関係するところ(ヘッダー部分、明細(Line)も必要です)です。

緑枠はテンプレートです。これをコピーして修正して使います。
赤枠の Order Header Minotta Film が修正したものです。

青枠はこの Client 作成時に自動で作られたものです。標準ではこのレポート書式が使われます。
(始めからこの青枠の書式を修正すれば良いのかもしれませんが、今後複数のレポート書式を作り出せるようにテンプレートからコピーして新たな書式を作ってみることにします。)

複数の書式が存在するということは、どの書式を正ととするかの指定が必要ということです。これを指定するのは次の画面です。

1:Menu -> Performance Analysis -> Accounting Rules -> Document Type
多くの伝票が登録されています。今回はこの中から Standard Order を選択します。
画面下の方に Print Format を指定するフィールドがあります。
まずこの指定がチェックされます。
ここが空欄だった場合次にいきます。

2:Menu -> System Admin -> General Rules -> Printing -> Print Form   (Print Formatではありません)
このは System / Minotta Filem の2種類があります。(他のクライアントの定義は見えていないだけ)
Standard Order は、Order Print Format で指定されているプリント書式を使用します。
ここではすでに新規登録済みの Order_Header Minotta Film が指定されています。標準では Order Header **1000001** xxxxxとか表示されているはずです。

さて、新規にプリント書式を登録する前に、テンプレート開いて構造を確認してみます。
Menu -> System Admin -> General Rules -> Printing -> Print Format
先ほど青枠、赤枠、緑枠があった画面の緑枠の Order_Header **TEMPLATE**を開いた画面です。
子タブは3つあります。
Display Order (どの項目を表示するか、その順番はどうするか?)
Sort Order (まだ確認していませんが、複数出力するときの順番でしょうか?)
Format Item  (出力する項目をどのように表示するか?場所その他)

Display Order は左右で別のウィンドゥがあり、左側で出力する項目を選択(左右三角で指定)し、右側で出力の順番を指定(上下三角で移動)します。

下は Format Item です。
Display Order で指定されている順番に並んでいますので、修正したい項目を選択します。
下は Display Order を開いたところです。
様々な設定項目があります。
あれこれあって難しいのですが、私がいじったのは主に下の属性です。(Format Typeなどにより表示される項目が異なるので必ずしも出ているわけではないのですが)

  • Area
    • ヘッダー部分か、コンテンツか、フッターかを指定します。
  • Relative Position
    • 順番が前の項目からみて、相対的な出力場所指定をするのか、それとも絶対的な出力場所の指定をするのかを指定します。チェックを入れると相対的な指示となります。
    • 例えば、自社情報・顧客情報・ドキュメント情報などそれぞれのブロック的な表現をすることができます。
    • 処理は並び順で行われるため、例えば顧客情報の中で一番始めに出てくる顧客名はこのチェックははずして、 X position, Y positionで出力位置を指定します。
    • 敬称や住所などは顧客名に対して相対的な指定をすれば、あるまとまりを表現することができます。
  • Set NL Position
    • 上の Relative Position と合わせてブロック的な表現をするのに使います。
    • その項目を以降の項目の基準にするかどうかを指定します。つまり Relative Positionで絶対的な位置を指定し、この Set NL Positionでその位置を固定します。すると次の項目からは相対的な指定をすればまとまりを作ることができます。
  • Next Line
    • 相対的な表現の場合、次の行に折り返すかを指定します。
  • X Position / Y Position
    • 絶対的な表現の場合の出力位置をしていします。
  • X Space / Y Space
    • 相対的な表現の場合、例えば顧客名と敬称の間にちょっと間を開けるなど位置を調整します。
ちなみに Format Type が Image の場合、Image URL に JPG などの画像を格納したディレクトリを指定するのですが、その書式例は次の様になります。(場所の善し悪しはともかく。。あと CentoOS 側にてidempiereからアクセスできる必要があります。)

file:///home//idempiere//image//abcd.jpg

スラッシュは始め3つ、あとの区切り部分では2つずつです。

長くなってきたのでここで一度中断します。




2015年1月29日木曜日

iDempiere 日本語化ふたたび (Compiere Distribution Lab版)

おおお、すごい。

以前一度日本語化したものの、今ひとつな感じもあり基本英語環境を使ってきました。
でも iDempiere Lab 殿の HPにて日本語化方法を見て改めてやってみました。

手順もわかりやすく記載されており、ここで書き直すとかえって混乱を引き起こす恐れもあるため本家へのリンクとさせていただきます。

コチラをどうぞ  -> 【Cempiere Distribution Lab】日本語の翻訳ファイルの適用方法


こちらが英語版(今まで見慣れた画面)
こちらが日本語版

かっこいい!


ただ、このブログは基本英語版の画面で話しをすすめていくつもりです。
(日本の)ユーザー側には日本語画面の方が良いと思うのですが、サポートする側としては英語版のターミノロジー(言葉)を理解している方が都合が良いこともあるので。。

このブログでも日本語で表記したり補足したりするときに言葉の不統一でいつも悩んでいたこともあり、日本語での記述は極力 iDempiere Lab 殿の言葉に合わせていきたいと考えています。


あと、レポートに日本語が出ない問題で悩んでいたのですが、こっちも解決。
ちゃんと日本語が表示されました。

しかし、これはありがたい。
感謝です。


これだけで終わるとちょっと寂しいので、今回AWS CentOS にFTPデーモンを仕込んだので、これだけちょっと記述しておきたいと思います。

AWS の CentOS AMI は ftpd はインストールされていません。
このため必要な場合は yum する必要があります。

--------------
# yum -y install vsftpd
メッセージ省略

# chkconfig vsftpd on
メッセージ省略
---------------
これだけです。
サービス立ち上げればいいのですが、あれこれ考えずに再起動すればOKです。

AWS側で Firewall の設定が必要です。
AWS -> EC2 -> NETWORK & SECURITY -> Security Gourp
Inbound に EDIT ボタンで"穴"を追加します。

EDIT ダイアログで Add Rule ボタンをおして
ALL TCP / My IP
すると今自分が使っている IPアドレスが自動で入力されるので OK を押します。

基本 FTP をしたい作業が終わったらこのポートの穴はふさいでおいた方がいいでしょう。
(ローカル側のIP アドレスを固定で契約している人はあまり気にする必要無いかもしれませんが、一般的には変わる可能性もありますし。)

と、設定したもののの、今回の日本語化では実際にはサーバー側の Firefox で直接サーバー側に必要ファイルをダウンロードしたのでこの設定は使いませんでした。
まぁ、そのうち使うこともあるでしょう。

蛇足とは思いますが、、、
FTP の使い方詳細はUNIX/Linux コマンド関連の HP をググって頂くとして、たぶん使うであろうコマンドだけ記述しておきます。


ls (サーバー側のディレクトリ内ファイル表示)
pwd (サーバー側のカレントディレクトリ表示)
cd (サーバー側のディレクトリの移動)
mkdir (サーバー側のディレクトリ作成)
!ls (ローカル側のディレクトリ内ファイル表示)
!pwd (ローカル側のカレントディレクトリ表示)
lcd (ローカル側のディレクトリ移動、これは ! ではなく小文字エル)
put (ファイルのアップロード)
get (ファイルのダウンロード)
mput (複数ファイルの一括アップロード)
mget (複数ファイルの一括ダウンロード)
bye (FTP終了)
この程度知っていれば困らないと思います。



iDempiere 想定業務フロー 1.7 Sales Order 受注 ワークフロー 検証

前回の投稿で特定の顧客のSales Order  (Document Type:Standard Order)から受注した場合、担当者にメール送信するワークフローの設定をしたので、試してみます。

正直言うと、「想定外」のことがいろいろと。。

今回新規追加した Process_SO_Amadon_Alert の Node: (SendEmail) で、指定した送信先メールアドレスにメールが飛ぶことは確認できたのですが、、、、
(現在空欄ですが、下図赤枠の部分です。)
Sales Order 作成時に必須項目である Sales Representative の人にもメールが飛んでしまいます。
ちなみにワークフローで指定した人を Sales Representative に指定した場合、同じメールが届くことになります。(2通来る)

代替案その1:
メールは Amadon担当者と Sales Representative  の両方に送信されることを許容する

代替案その2:
ワークフロー側の Email Address を空欄にし、 Sales Representative に Amadon担当者をセットする。
(Business Partner 画面で、 Amadon の Sales Representative に担当者名をセットしておけば、SO 作成時に Amadon向け受注とすればデフォルトで担当者名がセットされる)

代替案その2は業態や会社によって、営業の評価軸に関係することもあり個別に検討が必要かと思います。
(例えばここで入力した Sales Representative が営業の成績の要素となっている場合などは選択できないかもしれません)

今回はこの会社は基本的に担当顧客の売上(利益)で営業が評価されると想定し、代替案その2として先に進みたいと思います。

というわけで簡単に確認してみます。


Menu -> Quote-to-Invoice -> Sales Orders -> Sales Order
新規作成

Target Document Type: Standard Order
Business Partner: Amadon
Price List: 適当に
Sales Representative: 多田さん(Amadon担当、Business Partner 画面で担当者として登録済み)
Order Line: 適当に

これで Document Action を Complete します。

ワークフローの動作を確認してみます。

Menu -> System Admin -> General Rules -> Workflow ->  Workflow Process

親タブの2行がオーダーの登録で起動されたワークフロー、うち1行目が今回の Process_SO_Amadon_Alert

これを選択すると、実行された Node が出ます。
ここに (SendEmail) とあるので、(Start) に設定した Condition を満たしており、 (SendEmail)が実行されたことがわかります。

送信されてきたメールがこちら。(ちょっと本文がずれてますが、、)

Amadon 以外の受注を試してみます。

 Business Partner は ヨドゴシ として、受注します。


子タブを見ると今度は (SendEmail)が見当たりません。

これで特定の顧客からの受注時にメールを飛ばすワークフローは完成です。
思ったのですが、 Process_SO_Amado_Alert 作らなくても Process_Order のワークフローを修正すればむやみにワークフロー増やさなくても良いかもしれませんね。
(パフォーマンスにどの程度影響するのかによりますが、)

--------------------
メール送信のテストは結構検証が大変です。
というのも、どこで詰まっているのかわかりませんが、数時間遅れてメールが届くこともあり、検証時に結果のパターン認識が思うように進みませんでした。。(同じ条件でもメールの受け取り方が違うように見えて悩んでいると、あとあとメールが届くとか、、)
検証するときはサーバーの /var/log/maillog を直接見た方がいいかもしれませんね。
-----------------------

iDempiere 想定業務フロー 1.7 Sales Order 受注 ワークフロー

書籍ADEMPIERE 3.4 ERP SOLUTIONS  では、もう一つワークフローの例を挙げています。
ある特定のベンダーに対する発注がキャンセルされた場合に、メールにて通知するというものです。

この仕組みを理解したいと思うのですが、せっかくですからちょっと違うケースでトライしてみようと思います。

想定するシナリオとしては、次の様に考えてみました。
顧客 Amadonは Minotta Film にとって超大口顧客であり、Amadonからの受注には特別な注意をはらって納入まで専任者にステータスのトラックをしてもらいたい。

このためAmadonからの受注を受けたら専任者にメールを自動発信し、専任者が見落とすことのないように管理できる様にする。

(実際には Ama○on からの発注は1日複数回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 を追加していきます。
追加するノードは3つ
(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 に3つの 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 やら出てきます。
内部コードが必要なため、DBを見てみます。

サーバーに接続し、PostgreSQLを開きます。
DBまわりのことは以前の投稿をご参照ください。
AWS EC2 CentOS6.5 に もう一度はじめからPostgreSQL9.3 を インストールしてみた(その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)
-----------------------


Minotta Film の Client IDは '1000001' であることがわかります。

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  となります。

--------------------------
余談1
書籍ADEMPIERE 3.4 ERP SOLUTIONS に Business Partner ID についてはAdempiereからの確認方法についての記述があったのですが、よく分からず挫折。
いずれにせよ Document Type ID は調べる必要があったのでDBを直接見ました。
余談2
せめてDBを覗くツール使った方が楽なのですが、今のところSQLで間に合うのでもちっとこのまま行きます。
余談3
Condition の Value に式を書いてあげればDB覗く必要ないのかもしれません。
例えば 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 の3つをすべて or を指定してありますが、おそらく誤植だと思います。
また、ワークフローの画面も前の節で使った Process_Requisition のものなので、これも??です。
時折トラップありますので、確認が必要ですね。



2015年1月28日水曜日

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

前回までで、 Requisition の部内承認からの Status Completed までのワークフローをメールによる承認依頼付きでやってみました。
ただし現状では Create PO from Requisition は明示的にユーザーが実行する必要があります。


書籍 ADEMPIERE 3.4 ERP SOLUTIONS にあるワークフローの作成例に この Create PO from Requisition も自動化する設定が載っているので、これを参考に設定してみます。

新しい想定業務フローはこちら、(相変わらずバックグラウンド処理にもプロセスID振ってありますが今は無視してください。。)

新しい Process_Requisitionは次の様な仕様となります。



追加は色つきのところです。

これまでやってきたように、他の client に影響を与えないように Minotta Film の admin でログインします。(Organization は *)

Menu -> System Admin -> General Rules -> Workflow -> Workflow
から Process_Requisition を選択し、Node を追加します。(この作業にもずいぶんなれてきました。。)

Search Key とName に (Convert2PO) (名前は単なる識別子であることは確認済みなので、ここからはワークフローの Node のネーミングのお約束に従うことにします。)
Action: Apps Process
Process: Create PO from Requisition_M_Requisition_POCreate

(書籍ADEMPIERE 3.4 ERP SOLUTIONS には Process に M_Requisition_POCreate とだけ書いてあり、探すのに苦労しましたが、 Create の一団のところにありました。)
次は子タブの Parameter です。ここは初めていじるな。。。
Process Parameter: Requisition
Attribute Value: @M_Requisition_ID@ 
この "@" に囲まれたものは、、、
以前の投稿「iDempiere アプリケーション辞書 画面のカスタマイズ(Default Logic)」でちょっとでてきました。
これは M_Requisition_ID という変数にセットされた値が展開されるということです。

では、この M_Requisition_ID とは何なのでしょうか?
それはこのワークフローが呼び出されている時に処理されている Requesiton の IDです。
つまり、この (Create2PO)は、これを処理している Requsition の伝票に対して POへ変換するということになります。

今作成した (Create2PO) は Process_Requisiton の最後です。このため現時点の最後の Node  の (DocComplete) から呼び出されるように設定します。

(DocComplete) を開き、Transition を新規作成します。

Next Node: (Create2PO)

これで終了。保存・終了し、確認してみます。

以前と同様西島さんでログインし、 Requisitionを新規作成します。

私はM_Requisition_IDの意味確認のため、前回作成した Requisitonを残して処理をしてみました。

まずは前回のRequisition の残骸( Create PO from Requisition していないもの)
Requisition の Document No 900085 はApprove 済みで Status は Completed ですが、まだ Create PO from Requisition されていないことを示しています。
(Create PO from Requisition されると、この行が消されます。)
 新たに Requisitionを作成します。
Requisition No は 900086 です。
作成直後の Open Requisitionです。
900085 はそのままですが、 900086が追加されています。
Doc Action: Complete / Doc Status: In-Progress であることから承認待ちであることが解ります。

広瀬さん宛てにメールで承認依頼が飛bので、広瀬さんでログインし直し承認をします。
(画面省略)
 承認後、西島さんでログインしなおします。

で、また Open Requisition 確認、
先ほど Requisition した 900086が消えています。(900085 は依然として残っています)
Open Requisition から消えたと言うことは、 すでにPurchase Order に変換 されているはずですので、確認してみます。
Requisition の Document No 900086 から Purchase Order の Document No 800078  が生成されているのが解ります。
 中を確認してみると、
今Requisition 900086 から生成された Purchase Order 800078 が Document Status: Drafted にて生成されていることが解ります。


ワークフローにより Create PO from Requisition のプロセスは、コンディションを設定していないので、承認の要不要に関わらず実行されます。つまりCreate PO from Requisitionはこれで必要なくなりました。
ただし、この投稿で確認したように、適用前のトランザクション (Requisition 900085) が残っているとそのままになってしまいますので後片付けはしておくことにします。(笑)

書籍 ADEMPIERE 3.4 ERP SOLUTIONS には Requisitionのワークフロー中に、フィールドに文字列を書き込む Nodeの実装についても解説しています。
現時点私は食指動かずスルーします。ご興味のある方は挑戦してみてはいかがでしょうか?


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

Requisition のワークフローを流してみます。
プロセスは前回の通り、(1.1.3 購買完了は人間がやる作業ではないので色を変えました。説明上プロセスIDは残してありますが、いづれ整理します)



ユーザー西島さんでログインします。

1.1.1 Purchase Requisition の新規作成&内容の登録
Document Type / Delivery Date / Price List を入力・保存し、 Requisition Line にて Product /Quantity を入力・保存します。

この際、上記青枠の合計金額が ワークフローの条件 Total Lines > 70,000 となるようにします。( 100,000を超えると Admin Role の Approval Amount を超えてしまうのでエラーが出ます。)

1.1.2 Document Action
この状態で Document Action に Complete を選びます。
処理が完了すると、左上に Suspended と控えめなメッセージが出ます。(もっとアピールした方がいいのに。。)
ためしに Menu -> Requisition-to-Invoice -> Open Requisition を見てみると
Action は Complete で、 Status は In-Progress であることがわかります。

1.1.4 メールの確認
しばらく待つと、メールが飛んできます。
送信者は 前回 Client のところで登録した idempiere_mail@minotta.test
宛先は西島さんの上長である広瀬さんのメール idempiere@xxxx.com
(ちなみに西島さんの直属の上司は多田さんの設定なのですが、role が user なのでiDempiere の権限設定上スルーされて admin の広瀬さんに承認依頼が飛んでいます。)

1.1.5 Approval 購買依頼の承認

広瀬さんでログインし直します。
Home の Activity で Workflow (1) となっており、承認すべきものがわかります。

開いて Answer: Yes で OK

OKの場合は特に人間がすべきことはなく、バックグラウンドにて Status  は Completed に変わります。

西島さんに入り直して、もう一度 Menu -> Requisition-to-Invoice -> Open Requisition を見てみると
Action は Close で、 Status は Completed であることがわかります。
ちなみに広瀬さんの承認時に Answer : NO とすると、
否認のメールが西島さんに飛びます。
西島さんでログインすると、Home の Activity に Note(1) UnprocessedDocument (1) とかなっているので、そのRequisition を開き、 Document Action を Void として取り下げるか、一度Prepare に戻して修正してから再度 Complete して承認を依頼するなどします。