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 想定業務 在庫 実地棚卸 Physical Inventory

唐突感ありますが、実地棚卸時の在庫数の反映やってみます。

Menu -> Material Management -> Physical Inventory
から画面を開きます

Physical Inventory （実在庫）画面で、
該当する Warehouse （倉庫）を指定し、 Document Type は Physical Inventory を選択します。（これしか選択できません）

次に Create Inventory Count List ボタンを押します。
これは指定の倉庫内にある”はず”の製品数量を表示する Product Category (製品カテゴリー)
を指定できるポップアップダイアログが表示されます。
ちなみに下の画面はすでに Product Category に ICレコーダーと指定済みのため、該当する製品が表示されています。

ちなみにProduct Category のポップアップで何も指定せずOKすると、その倉庫にある全製品が表示されます。

Product Category 「ICレコーダー」は「 音メモ君」 と「音メモ君2号」が倉庫にありました。
子タブに表示されている
Quantity Book が iDempiere上での想定数量です。
Quantity Count は実際の数量を入力します。

音メモ君の棚卸しをしたら 15個しか無かったとします。
このまま子タブの音メモ君の行をクリックして数量を変更できます。
ここでは今までのように子タブに移動して数量を修正してみます。

 子タブの画面を見ると、 Quantity Book はグレーアウトで修正不可であることがわかります。
Quantity Count の数量を実在庫に合わせます。ここでは15個と入力しました。
Inventory Typeは

Inventory Difference と Charge Account と選択できますが、
まず棚卸しと想定しますので、 Inventory Difference を選択します。

これでおしまい。親タブに戻り、 Document Action で Complete しましょう。

 Complete できたら、仕訳を見てみます。
（Posted ボタンを押す）

Accounted Credit （貸方）に製品資産
Accounted Debit （借方）に 倉庫差異
として仕訳されています。


ずいぶん前の話になりますが、この仕訳は以前の投稿「iDempiereで新規作成したクライアントへ日本の勘定科目をインポートしてみる。」で読み込んだものです。

勘定科目に AccountingUS.csv を用いている場合は
Accounted Credit （貸方）に Product asset
Accounted Debit （借方）に Inventory Shrinkage
のようです。なるほど、倉庫差異は Inventory Shrinkage って表現するのね。（もちろんその他の表現もあるのでしょうが、、）逆にこれを日本語で表現すれば「棚卸消耗」といった科目ですね。

つまり実地棚卸しの差異に使う科目は「倉庫差異」でも「棚卸消耗」でも良いってことですね。
ググってみると「棚卸消耗」の方が優勢の気がしますが、仮に実地棚卸の時に倉庫の数量が多かった場合、私のように会計になれない人間からすると「消耗」という言葉やこれが貸方に来るのはちと心理的抵抗がある気もします。この点「倉庫差異」などと増減が曖昧な科目名であれば理解はしやすいのですが、、
（仕訳そのものが正しくされていれば、言葉は常識の範囲内で社内で統一されていれば問題ないのだと思います。）


 先ほど、数量を在庫実数に合わせて変更したところで、
Inventory Type に Inventory Difference と Charge Account と選択できましたが、Charge Account とは、例えばプロモーションなどの勘定など、自社都合で使用したために在庫数量が変わってしまった場合などに選択します。

--------------ちょっと注釈-------------
自社都合で利用する場合は、わざわざ Physical Inventory で倉庫の数量の総数を入力するより、はじめから「そのものずばり」の画面を使った方が楽です。

Menu -> Material Management -> Internal Use Inventory

たまたま実棚の時に何かしらの目的のために持ち出したことが発覚したときに Physical Inventory からも入力出来る様にしてあるのかもしれません。
----------------------------------------------


Charge Account を選択すると、Charge先のアカウントの選択フィールドが出現します。

もちろんこのCharge先アカウントを空白のままで保存したり、親タブに戻ることはできません。

 ここでCharge を選択できれば良いのですが、まだ Charge Accountの登録をしていない方は何も選択できません。

ここでは下のように登録済みという前提で Charge Account を選択してみます。

親タブに戻り、 Document Action を Completeすると前回の仕訳と異なり

Accounted Credit （貸方）に製品資産
Accounted Debit （借方）に Other Advertising & Promotion

と仕訳されました。

 この仕訳は
Menu -> Performance Analysis -> Generate Charges から作成できます。

 画面にてアカウントの一覧がでますので、適切な科目にチェックをし、右下の Create From Account ボタンを押すと、この科目が Charge  Account として選択出来るようになります。

 また、新たに追加擦る場合は上の画面の Search Key と Name を入力して Create New Record ボタンを押すと追加されます。

この段階で先ほどの様に仕訳が可能となるのですが、まだきちんと動きを確認していないので、今回かけることはここまでです。
（すごい中途半端ですいません。もちっと私に勉強が必要です。オペレーションレベルの話だと思って許してください。）