iDempiere 想定業務フロー 在庫移送 In-Transit Material Move 受領確認

前回、前々回の投稿で、在庫移送についてやってみましたが、Document Actuionを Complete した瞬間に処理が完了していました。
在庫の受け取り状況に関わらず、送り出し側が処理をすればＯＫということです。

実際には受け取り側で受領確認をしたら完了とすべきだと思います。
このような動作をする伝票タイプは標準では持っておらず、必要に応じて追加する必要があるようです。

イメージはこんな感じ

通常の Inventory Moveは上図青枠のプロセスです。
親プロセスを定義していないので現時点プロセスIDはありませんが、

1:New Recordで新たな Inventory Move の Document を生成し、必要な項目を入力します。
2:伝票が完成したら 在庫移送指示としてDocument Action で Complete にします。
3:在庫移送指示されると、 Post し（仕訳）、Document Status を Completed に変えます

今回の投稿ではこのプロセスに新たなDocument Type  In-Transit Material Movement を定義し、受領側にて Move Confirmation （受領確認）を追加します。


ADempiere 書籍 "ADEMPIERE 3.4 ERP SOLUTIONS"に記載がありますが、はじめ早とちりして理解したところがあり、ちょっと苦労しました。

ここでも実際に試してみます。

まず、あらたに Document Typeとして "In-Transit Material Movement" を作成します。
作成するといっても、既存の "Material Movement" をコピーして、ちょこちょこっとかえるだけです。

Menu -> Performance Analysis -> Accounting Rules -> Document Type を開きます。
 一覧にして探しても良いですし（2ページあります）、虫眼鏡アイコンから検索してもＯＫです。

 見つかったらグリッド表示を解除し、内容を確認します。
こんな感じ。

Name を　"In-Transit Material Movement" 　へ変更し、
In-Transite にチェックを入れます。

 修正自体はこれで終了。
なぜこれだけでOKなのかは現在理解できていません。ＤＢになんか定義してあるのかな？
いづれ見てみたいと思います。
こういうことは経験や想像だけではなかなかたどり着かないので、書籍など先人の知恵をお借りするしかありませんね。（やっぱり書籍必須かも。。。。）

修正後、一度すべてのタブを終了させて（ Home （Ｘ）タブだけにしてから）、

Menu -> System Admin -> General Rules -> Cache Reset プロセスを実行します。

iDempiere の動作を速くするためにキャッシュしているが、これを削除していいか？とか聞いてきますのでOKを押します。

余談ですが、キャッシュ削除後に再度接続したら、体感的にちょっと早くなったような気がしました。意識していたわけではないので気のせいかもしれません。またいずれ試してみたいと思います。

さて、設定が出来たところで、 Inventory Movement をしてみます。

Inventory Movement を新規作成して Document Type を選択しようとすると。。。。

今追加した In-Transit Material Movement が選択出来るようになりました。

で、これを選んで、、
子タブの Move Line から

製品は Portable Two
移送元は 三郷倉庫
移送先は 幕張倉庫
数量は 3

と指定し、親タブに戻って Document Type を Complete してみます。。。。。
したのですが、、、、なにも起こりません。
いつもの Posted ボタンもなく、特にエラーメッセージもなく。。。

ちとあれこれ悩んだのですが、実はDocument Type に、この In-Transit Material Movement を選んだ場合、受け取り側の担当者が Movement Confirmation をしない限り Complete 出来なかったのです。

まぁ、なるほどね。
よくよく見ると画面右上に　"Open: Move Confirm -xxxxxx"とか書いてあります。

というわけで受け取りの確認します。

Menu -> Material Management -> Move Confirmation
今ひとつ上の Material Movement との紐付けがわかりにくいのですが、Document No を見ると上で示された番号を見ることができます。（10000006）

 で、子タブの Line を開くと、Material Move で移送を指示した3 個が Target Quantity にあります。
問題なく届いた数量を Confirmed Quantity へ入力するのでしょうが、そのままでは面白くないので、1個破損していたことにしてみます。

Target Quantity 3
Confirmed Quantity 2
Scrapped Quantity 1


 親タブに戻って Document Action を Complete してみると、、
なにやら Description のところに Approve されたと記入されるのですが、 Posted ボタンが表示されるわけではありません。。。。

 今ひとつ状況掴めないまま、もとの In-Transit Material Movement 画面を眺めていると。。
突如 Posted ボタンが出現！

なるほどね。

書籍 "ADEMPIERE 3.4 ERP SOLUTIONS" では Move Confirmation で Complete 後にこちらの Inventory Movement でも Complete する必要があるように読めますが、iDempiereでは変わったのでしょうか？（英語力に不安あり、、少なくともiDempiereではInventory Movement では自動で complete されます）

Posted ボタンを押して仕訳を確認してみると、
Confirmed Quantity でしてした2個分のみ仕訳されているのがわかります。

でも破損分はどこにいったのだろう？
Menu -> Performance Analysis -> Accounting Fact Details　にて
詳細を見てみます。
（ちとこまかいので、エクセル書式で出力して項目加工したものです。）

いいのかなぁ？これで、
２、３行目で misato からmakuhari へ（結果的に）2個資産が移ったことがわかります。
４，５行目で misato で倉庫差異で1つ減らしています。
ここだけならいいのですが、６，７行目で同じく倉庫差異（ Description は Scrapped )で１つ減らしています。

これでは１つ余計に資産を減らしていないでしょうか？

もしかしたらMove Confirmation にて Confirmed Quantity と Scraped Quantity の指定が間違えていたのかもしれません。
つまり、Confirmed Quantity は破損していようがなんだろうが、受け取り総数。
Scraped Quantity は総数の中で何個壊れていたか。

ここでの例のように Target Quantity （発送数）は 3であるにも関わらず、 Confirmed Quantity （受け取り数）に２を入力した時点で、makuhariとしては受け取っていない。つまり発送側のmisatoが紛失してしまったことになり、さらに Confirmed Quantity （受け取り数）が２のうち、 Scrapped Quantity （破損数）が１として makuhari でも1つ使用できる在庫が減ったとされていることになっていると思われます。

両方同時に起こりえると考えるとこれが正しい気もします。
やっぱりちゃんと意味を理解しなきゃいけませんね。

---------------------------
書籍 "ADEMPIERE 3.4 ERP SOLUTIONS" を見てみると このケースで私が入力したように
Target Quantity 3
Confirmed Quantity 2
Scrapped Quantity 1

と入力すると記述されているように思います。誤植なのか、iDempiereで仕様が変更されたのか？　　（＊もう一度最後に検証したものを載せます。）

----------------------------

欲を言えば、 In-Transit Material Movement の Posted ボタンで表示される仕訳にもここまで出れば通常のオペレーションのなかで事故に気がつきやすいと思うのだけど。。

受け取り側倉庫での確認時に仕訳されるのはいいのですが、在庫の増減のタイミングも受け取り確認後に計算されるのですが、倉庫間に距離があって輸送時間がかかるときの設定方法はもちっと見てみる必要がありそうです。


------ここからは In-Transit Material Movement の Target/Confirm/Scrapped Quantity の指定方法の再検証エビデンスとなります。-----　特に読み物はありません。

幕張倉庫にある　音メモ君を　三郷倉庫へ　2回 In-Transit Material Movement  します。
操作前
幕張倉庫 14pcs
三郷倉庫 0pcs

1回目移送の指示
In-Transit Material Movement 5pcs

移送先三郷倉庫での受け入れ

Target Quantity 5
Confirmed Quantity 5
Scrapped Quantity 4

 1回目移送後の在庫確認

幕張倉庫 9pcs
三郷倉庫 1pcs

倉庫差異（棚卸消耗）  4pcs

この時点で合計 14pcs から 4pcs 減少で、現時点合計数は 10pcs
これは想定通り

続いて2回目
1回目と同様に2回目の位相指示も 5pcs
In-Transit Material Movement 5pcs

移送先三郷倉庫での受け入れ
Target Quantity 5
Confirmed Quantity 1
Scrapped Quantity 4

 ２回目移送後の在庫確認

幕張倉庫 4pcs
三郷倉庫 -2pcs

倉庫差異（棚卸消耗）  8pcs
(三郷 4pcs、幕張 4pcs）

この時点で合計 10pcs から 8pcs 減少で、現時点合計数は 2pcs

棚卸し消耗も含めた詳細
赤っぽいのが1回目
青っぽいのが2回目

1回目では
4pcs を幕張から三郷へ在庫移転し、
三郷で 4pcs スクラップとして処理

2回目では
1pcs を幕張から三郷へ在庫移転し、
三郷で 4pcs 棚卸消耗
幕張で 4pcs スクラップ

やはり Scrap Quantity は Confirm Quantity の内数としなければならないことがわかります。

iDempiere 想定業務 在庫移送 Inventory Move ② 組織を跨がる倉庫間移送

在庫移動再開です。

今度は Organization（組織）をまたがる倉庫への移動です。
（下図②）

前回同様
Menu -> Material Management -> Inventory Move
を新規作成し、三郷倉庫の Portable two 1個を埼玉倉庫へ移送します。

Document Type にMaterial Movement を選択し、保存、子タブ の Move Line にて次の様に入力します。
製品は Portable Two
移送元は 三郷倉庫
移送先は 埼玉倉庫
数量は 1

親タブに戻って、 Document Action を Complete します。
Posted ボタンを押して仕訳を確認すると、 先ほどと違い製品資産と会計会社取引元勘定が仕訳されていることがわかります。

ここまでの状態でもう一度各倉庫の在庫を調べてみると、

三郷倉庫
元々（前回の組織内倉庫間移送前） 19個あった Portable Two が 13個に減っています。

続いて同一組織内の幕張倉庫
元々 Portable Twoの在庫は無かったのですが、移送分の 5個あることが解ります。

最後に別組織の埼玉倉庫
iDempiere 右上の Change Role ボタンにて Organization を埼玉で入り直します。
その後確認すると

移送した１つがありました。

最後にもう一度

Menu -> Performance Analysis -> Accounting Fact Details
を確認してみましょう。
（本日の仕訳分だけ抽出）

ここで1つ気がつきました。
Menu -> Performance Analysis -> Accounting Fact Details　は同じ物があるのですね。
今回の仕訳を確認するのは下の方の Accounting Fact Details です。

まずは Organization を HQ で抽出
4レコードありますが、上の 2レコードは前回の投稿で幕張と三郷の倉庫間の移送分です。

 続いて Organization を埼玉工場で抽出したものです。

情報としては重複しますが、次は Organization を空白にし、全組織を表示させた物です。

iDempiere 想定業務 在庫移送 Inventory Move

在庫移送をしてみます。

内容は簡単なのですが、まず簡単にシチュエーションの整理からいきます。

現在想定している組織構造です。
（組織構造の善し悪しや理想型についてはここでは置いといて、今こんな感であると理解してください。）

在庫移動は上頭の①、②をやります。
違いは Organization （組織）内の移動なのか、 Organizationをまたがる移動なのかとなります。

ちなみに Warehouse (倉庫）の登録は下のメニューからたどれます。
Menu -> Material Management -> Material Management Rules -> Warehouse & Locators


まずは①からいきます。
それぞれの倉庫にある製品は現在次の様になっています。
三郷倉庫

 カメラ関係の製品がストックされています。
つづいて幕張倉庫

こちらにはＩＣレコーダー関係のみがストックされています。

--------------余談----------------
現時点の倉庫内在庫を見るのはどのようにするのが良いのでしょうか？
私は Physical Inventory を新規作成して 倉庫を指定後、Create Inventory Count List にて、フィルターをかけずに抽出しました。確認後は新規作成した Physical Inventory は削除しました。
------------------------------------


この状態から三郷倉庫の Portable two 5個を幕張倉庫へ移送します。

Menu -> Material Management -> Inventory Move
これを新規作成します。

Document Type が必須なので、Material Movement を選択します。（一択）

-----------------余談-----------------
今は一択ですが、後ほどDocument Type を追加します。
----------------------------------------


移送するだけならこの状態で保存し、子タブの Move Lineを新規作成します。

 子タブで　Move Lineを新規作成すると、次の様に
Product （製品）/ Locator （移送元）/ Locator To （移送先）
が必須と表示されています。

 製品は Portable Two
移送元は 三郷倉庫
移送先は 幕張倉庫
数量は 5
とします。

ここまで入力したら親タブに戻り、Document Action を Complete します。
Complete したら表示される Posted ボタンを押して仕訳を確認すると次の様に見えます。

Credit（貸方）、Debit（借方）ともに Product Asset （製品資産）です。
ま、そりゃそうだ。

これだけではどこからどこへの資産移動なのかわからないのですが、
詳細を見てみましょう。

Menu -> Performance Analysis -> Accounting Fact Details
を確認すると。。。
（本日の仕訳分だけ抽出）

ロケ−タにそれぞれ misato W/H , makuhari W/H とあり、倉庫間で資産が移動されたのがわかります。。。。が、なんか違和感ないですか

仕訳の左右が逆に表示されています。

普通 借方が左で右が貸方ですよねぇ、まぁ、項目名が合っていれば良いのでしょうが、、

私の環境だけなのかな？今はスルーしますが、注意が必要ですね。

---------------------------

GardenWorld も確認したのですが、通常の伝票（例えば PO） ではDebitは左、Creditは右ですが、Accounting Fact Details では逆になっていました。。。なぜだろう？海外では右左にあまりこだわりがないのかな？

---------------------------

 一度中断しますが、次に Organization 違いの在庫移送してみます。（最初の②の分）