« 逆方向バリデーションを自動化する | トップページ | 自治体システムは日本に1個あればいい »

2012.03.09

セット商品の原価と在庫推移

 ござ先輩の「自社業務システムのDB設計メモ(受注業務編)」のエントリに触発されて、「CONCEPTWARE/販売管理」への「セット商品」の組み込みに取り掛かった。「CONCEPTWARE/生産管理」の実装を始める前に、販売管理システムにセット商品に必要な要素を組み込んでおきたいとは以前から考えていた。これまでも「在庫振替」の機能を使えば事後的に対処できたのだが、セット商品としてあらかじめ定義しておくことで、製造指示のようなこともやれるからだ。

 セット商品とは、いくつかの商品を組み合わせたものである。売れ筋商品をまとめたものであったり、組み合わせて利用されることが多いものまとめたものだったりする。たとえば3種類のお酒があるとして、それぞれ単品でも販売されるいっぽう、3つをまとめた「利き酒セット」としても販売される、といった具合だ。

 もちろんセット商品の内訳を人が覚えておくのではなく、(1)のようにマスターテーブルにあらかじめ記録しておく。素朴な形だが「セット構成」は、生産管理システムにおける「部品表(BOM)」に相当する(注)。

(1)商品とセット構成

[商品] 商品id,商品名
+  0000001 八海山本醸造
|  0000002 八海山大吟醸
|  0000003 八海山純米酒
|  0000004 八海山利き酒セット

└―∈[セット構成] 親商品id,子商品id,構成数
          0000004 0000001  1
          0000004 0000002  1
          0000004 0000003  1

 セット商品にはいくつかのタイプがある。たとえば、マッチとポンプを組み合わせて売るとしよう(いやはや)。ただしその組み合わせで受注されることが多いだけであって、それらは荷姿として組み付けられたものではないとする。出荷指示書や納品書の上にはマッチとポンプは別行で示される。このような場合、このまとまりは「実体のないセット商品」である。受注の際に「マッチポンプセット」を選べば、その場でマッチとポンプの2商品として展開されて受注データとして記録される形にしておけばよい。実体がない点で、生産管理システムにおける「ファントム」に似ている。

 では、マッチとポンプとが簡単な形で「組み付け」されているとする。この場合、あらかじめ組み付けて在庫しておく必要はなく、出荷作業に組み付け工程を含めてしまえる。このような出荷作業のことをとくに「出荷加工」という。出荷指示書には出荷加工ができるような摘要が盛り込まれなければならない。このまとまりは「実体はあるが在庫されないセット商品」である。

 こんどは、マッチとポンプとが化粧箱に収められるとする。化粧箱には「あら便利!よく火が着くマッチとよく火が消えるポンプのお得なセット」といった調子で商品名やイラストが印刷されているとする。こうなると、構成品が仕入品であるとしても、このセット商品は販売会社の独自企画商品である。「利き酒セット」はこのタイプに含まれそうだ。この場合のセット商品はあらかじめ加工されて在庫される本格的なもので、生産管理システムで言う「製造品」と変わらない。

 なお、ござ先輩の記事にもあるように、セット商品の内訳を納品書上で示したい場合がある。ただし、セット商品であれば常にすべての構成品を示せばよいというわけではなく、示したいものだけを示せるようであったほうがよい(たとえば上述の「化粧箱」などは内訳として示されてもしょうがない)。そのためには、セット構成に「納品書出力区分」を置けばよい。納品書発行プログラムは、この情報にもとづいてセット商品の内訳を出力するかどうかを判断する。

 さて、3つ目のタイプのセット商品で会計上とくに問題になるのが「原価」である。原価がわからないと粗利(あらり)もわからない。通常品であれば仕入原価や諸掛(しょがかり。仕入にともなう仕入原価以外の経費)を考えるだけで原価をとれるのだが、セット商品ではそうはいかない。上の例では、マッチとポンプそれぞれの原価に加え、化粧箱(包材)の原価、それに組み付け作業にともなう加工費が、セット商品の原価要素として上乗せされる必要がある。構成品の原価は取りやすいが、加工費は取りにくい。標準加工単価を決めておいてこれで通す方法もあるが、実績値も取れたほうがいい(そうでなければ標準加工単価も設定できない)。

 在庫更新や実績加工費収集の起点となるテーブルが、(2)の「商品セット指示」である。今後の販売に備えてセット商品の在庫を増やしておこうと考えた時点で、セット指示を新規追加する。このときに「セット構成」にもとづいて構成展開されて「商品セット指示明細」が追加され、作業指示書が発行される、といった手順で処理される。実際のモデルは倉庫ロケやロットの管理項目を含むためもっと複雑だが、雰囲気はわかってもらえるだろう。

(2)商品と商品セット指示

[商品] 商品id,商品名
++ 0000001 ラクダ印マッチ100本入
|| 0000002 小型強力汲み上げポンプT1000
|| 0000003 マッチポンプセット
||
|└―∈[セット構成] 親商品id,子商品id,構成数
|          0000003 0000001  5
|          0000003 0000002  1

└―…[商品セット指示] 指示id,商品id,指示数,作業時間,...
   +        000256 0000003 10   0.3
   |
   └―∈[商品セット指示明細] 指示id,子商品id,所要量
                 000256 0000001  50
                 000256 0000002  10

 発行された指示書にもとづいて作業が終わると、当該の商品セット指示データに対して完了報告がなされる。そのときに実績作業時間が入力され、これに規定の賃率が掛け合わされることで実績加工費が得られる。また、独自企画商品であればあらたにロット番号を振ったり、構成品の投入ロット内訳を管理するためにも、これらの指示データが起点となるだろう。

 また、セット商品や製造品を扱う場合に問題になるのが、関連商品の「在庫推移」である。当然ながら、セット商品というものはその構成品の在庫がなければ用意できない。ゆえに、構成品の現在庫はもちろんのこと、将来の在庫推移までわかるようでありたい。

 そのために「CONCEPTWARE/販売管理」では、発注、出荷、倉庫間移動などの入出庫予定系テーブルについて、「受払予定」という汎化テーブルを対応させてある。それぞれのデータの追加・更新・削除に連動して、受払予定の内容が自動更新される。これによって、全商品の将来の在庫推移までがリアルタイムに変化するのである。詳しい説明は省くが、この「在庫推移監視方式」は「MRP(資材所要量)」よりも単純かつ実用的なしくみである。

 この枠組みに商品セット指示を組み込んでしまえばよい。すなわち、商品セット指示が新規追加されたなら、作業完了予定日にもとづいてセット商品の受払予定(入庫予定)が追加され、セット構成品の受払予定(出庫予定)が追加されるようにする。さらに、セット作業の完了報告がなされたなら、それらの受払予定が消えると同時に、実績値にもとづいて受払実績が追加され在庫残高が更新されるようにする。

 どうだろう。工程管理の要素こそないが、セット商品(製造品)と構成品の動きだけ見れば生産管理システムとそっくりだ。生産管理システムと言うと難しそうだが、その基本骨格は販売管理システムにおけるセット商品の動きを見ればおおよそ理解できる。ようするに生産管理システムは「セット商品管理機能と工程管理機能とが組み込まれた販売管理システム」である。この改善にともなって販売管理システムは、実システムとしても教材としても使い勝手のよいものとなるだろう。

このブログでの関連記事:
在庫引当から在庫推移へ(前編)
在庫引当から在庫推移へ(後編)

注:本格的な部品表ではPKを{親商品id,子商品id}ではなく{親商品id,行番}の形にしたほうがよい。構成品として同一品番を複数並べることがあるからだ。

|

« 逆方向バリデーションを自動化する | トップページ | 自治体システムは日本に1個あればいい »

コメント

セット品は問題をはらんでいますね。組み立て作業を伴うにも係らず、生産管理システムではなく営業在庫管理システムで扱われるので、見過ごされがちなんじゃないかと思います。渡辺さんが本記事に書かれているようなセット品の受払管理は、できていない企業も多いのではないかと推察します。さらに言えば、在庫管理だけではなく需給計画でも厄介者になりがちです(セット品需要を構成品目需要に展開しなければならないので)。業務システムについて、やるべきことはまだまだ沢山ありますね。

投稿: keis | 2012.03.14 13:01

ござ先輩こと、湯本と申します。言及して頂いて驚きです。「販売管理システムで学ぶモデリング講座」をSIer勤務時代に拝読し勉強させて頂いていたので、こんな形で恩返しが出来て嬉しく思っています。

セットに対する考え方は元々出版流通のシステムを検討していた時に生まれたもので、よくある「XX文庫:夏の100冊」的なものに対応する為に考えたものです。

全ての業務には新規登録/訂正/削除の3つが必ず存在しますが、ご指摘の受払予定のように、それらを吸収できない業務システムが多いように思います。データ設計で吸収できることはどんどん吸収していきたいと思います。

投稿: ござ先輩 | 2012.03.20 17:20

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: セット商品の原価と在庫推移:

« 逆方向バリデーションを自動化する | トップページ | 自治体システムは日本に1個あればいい »