簡単？ FileMakerで在庫管理（２） ―― 繰越処理の考え方

　今回は、繰越処理に伴う在庫算出について考えていきましょう。　在庫算出の基本については、以下の記事をご覧ください。

　簡単？　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以前の出庫計）

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

C式：　繰越処理日＜在庫基準日の場合の在庫算出式
　　導入時在庫数+（2/28以前の入庫計）-（2/28以前の出庫計）

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

繰越処理と制御

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

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

やがて訪れるデータ削除の時期について：
　長期間使用するシステムでは、繰越処理を行ってもレコードはどんどん蓄積されていきます。当社が開発・保守を担うシステムでは百数十万件の入出明細データを持つテーブルがありますが、ほぼ定期的にデータ削除を行っています。小社では、FileMaker のテーブルの最大レコード蓄積数は200～300百万件を一つの目安としていますが、データの削除は、システム仕様、実行速度要求、保持データ数要求、バックアップポリシー等の諸事情を勘案し、システムが安定動作することを大前提に実行してください。一般ユーザがデータ削除を行う場合は、一括データ削除機能も必要になります。
　また、削除したデータを照会したい、といった要望も必ずといっていいほどユーザより提示されるので、できれば過去データの照会についても予め考慮してシステム設計を行います。

在庫管理は簡単か？

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

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

　その他の在庫関連記事を読む

土屋