前回の補足: 液体商品でドラム缶単位の個別原価を行う際には, 仕入ロットの仕組みで対処する事も可能ですね。ロットの設定がヤヤコシイくなりますが。
ドラム缶などから出庫すると綺麗に使いきれなくて、残りがでます。残りを保存しておいて1単位分溜まると、出庫することもありますが、システム処理にとっては、煩雑になります。….個別原価の把握がし難いし。
これはロット単位で仕入れて、部品を組み立てて出荷する場合に当てはまり、生産管理の一部の仕組みが取り入れることがあります。この場合、ロット単位で残り'(端数)のをどうするかで処理が分岐したりするので販売管理システムからみると厄介です。市販の販売管理システムだと、親子部品構成で対応しているようです。
引当/ 取置のサブシステムがあるケースがあります。
在庫の扱いに引当があります。すでに納品先が確定している在庫品です。
それと似たものに、取置があります。納品先が未確定だが、自分の事業所の扱い分を唾付けしておくものです。
この場合は、在庫数は狂わないですが、運用上の数問題がでてきます。
取置状態の商品が放置され,日の目をみないで破棄されることがあります。(有効期間がある食品なども)
取置分が過剰に存在していて、フリー在庫が少なく、頻繁に発注したりします。
取置物品の適正化を監視する仕組みを考えないと、部署による我侭取置を抑制てきません。その結果、在庫があるのに数が足りない事態になります。
引当/ 取置の経験でこんなことがありました。
既存のシステムが 引当サブシステム/ 取置サブシステムと別のサブ扱いになっていて要件書/設計書も別物として作成されてました。
原則は
在庫とすればの状態が取置/引当の識別ができる。 (数量補足か個別補足かはありますが)
取置伝票/引当伝票も最終納品先か唾付け先かの識別ができる。
これでOKなので、サブシステムにするまでも無いのですが、既存に慣れていて、かつシステムに不慣れな顧客の場合、サブシステムの形をとった方が話しは纏まります。 業務面からの分類はそのようにしました。
実装面ではしてません。 このように業務面からみたシステム構成と実装面からみたシステム構成が一致しない場合がたまにあったりします。(よくないなぁとは思うのですが)
在庫<=取置 <=引当 <= 納品の関係を見ていくと、Object指向な設計をしたくなったりしますね。