2012-06-01

簡単? FileMakerで在庫管理(2) ―― 繰越処理の考え方

 今回は、繰越処理に伴う在庫算出について考えていきましょう。
 在庫算出の基本については、以下の記事をご覧ください。
 簡単? FileMakerで在庫管理(1) ―― 在庫算出の基本


繰越処理の考え方


 入出庫のレコードが増えてくると、在庫算出時に合計する入出庫明細レコードが膨大になり、処理速度が低下します。
 そこで、在庫数の繰越処理を行うことによって、在庫算出処理の速度向上をはかる必要がでてきます。
 
 たとえば、商品Aの2011年6月~2012年5月の入出庫明細データが10万件あったとします。
 2012年5月31日時点の商品Aの在庫を算出しようとして、入出庫明細レコードを10万件を対象に、Sum(入庫明細::入庫数)-Sum(出庫明細::出庫数) をやっていては、処理時間が膨大になってしまいますが、繰越処理を実行することによって2012年4月末時点の商品Aの在庫数を商品テーブルに保管しておき、5月1日~5/31の入出庫明細レコードのみをSumの対象となるようにリレーションを組めば、Sumの対象となるデータは、(単純計算で)10分の1以下となります。

 また、以下のように繰越処理を行った場合と、行ってない場合とでは、在庫算出の計算式が違ってきます。

A式: 導入時在庫数+(4/25以前の入庫計)-(4/25以前の出庫計)

注:
上図で「1/10より前の入出庫データが作成されてはマズイだろ?」と考えた人は鋭いですね。そういうのが気になる人は入出庫伝票入力・更新時に、1/10より前の日付は入力できないように、制御を考えてみてください。

B式: 繰越処理日≦在庫基準日の場合の在庫算出式
繰越在庫数+(4/1~4/25の入庫計)-(4/1~4/25の出庫計)


C式: 繰越処理日<在庫基準日の場合の在庫算出式
  導入時在庫数+(2/28以前の入庫計)-(2/28以前の出庫計)

 要はA、B、Cの式をCase分けして、ひとつにまとめる必要があるわけです。



繰越処理と制御


 さて、繰越処理で考えておかなければいけないことが一つあります。それは、繰越処理日(上記例では3/31)以前のデータ、在庫に関していえば、既存の入出庫レコードの出庫日と入庫日、出庫数と入庫数を変更不可にしておく必要があります。また、繰越処理日以前の同レコードは削除されてはならないし、繰越処理日以前の入出庫日を持つ同レコードは作成されてもいけないのです。 

 その理由は、[繰越在庫数]との整合性がなくなってしまうからです。

注:
 繰越処理を行っても、入出庫のレコードはどんどん蓄積されていき、入出庫レコードを削除しなければならない日がいつかはやってきます。そのときの処理は別途考えておく必要があります。


在庫管理は簡単か?


 残念ながら答えは NO です
 システム的には、繰越処理とそれに伴う伝票制御、旧データ削除時の処理を考慮せざるを得ず、在庫管理システムを作るのはやはり簡単ではない、というのが結論になります。

 また、繰越処理関連を適正に実装できたとしても、1カ月に同一商品の取引が数百回以上あるような業務では在庫算出処理の遅延も予想され、別の在庫算出手法(拙稿の「FileMaker V10による在庫管理、一考」の123を参照)の採用も選択肢に入れなければならないでしょう。



土屋

0 件のコメント: