自社業務システムDB設計メモ(出荷・在庫管理編)

前回のエントリが意外とブクマされたので驚いてる。いつかこのメモたちは立派なER図になって各業務ごとにポイントを書いた素敵なPDFに姿を変えることになるでしょう。その時は資料を公開します。1万円で（え

在庫は商品のプロパティ？

そう思ってた時期が僕にもありました。最初は在庫はエンティティだという気持ちがあったのでテーブルを作ってたんですが、商品のステータスに変動して在庫を管理する必要がないので、商品テーブルと在庫テーブルを分ける意味がないという結論になりました。それが「うほ・・・」となったのが１年ほど前にお手伝いした出版流通業者さんのお仕事。同じ商品でも｢良品」と「不良」で在庫を別に分ける必要があり、かつ不良の商品が良品に戻ることがある。書籍は再販制度により、不良の商品を改装して良品扱いにすることが可能なので、良品と不良品を行ったり来たりする必要があるわけ。更に言えば改装中・断裁・献本みたいなステータスもあったり。

よって、前回の取置のように｢同じ商品だけどフリーと取置のようにステータスが複数あり、各々管理する必要がある｣場合は在庫テーブルを用意すべき。そうでないなら、商品テーブルに在庫カラムを設けてもいいだろう。ただ、入出庫管理表作るときが大変だけど。あと、倉庫が広い場合はピッキングしやすいように棚番を商品テーブルに設けることもある。倉庫が複数あれば倉庫マスタ作るしかない。A倉庫からB倉庫へ商品移動することもあるので(スペース確保のため)、移動はできるようにせんとあきまへん。

注文と出荷のタイミング

モノを納める業態の場合は、｢注文内容をそのまま活かして同じ到着日に出荷できる｣のであれば、注文と出荷を分ける必要は無い。が、注文内容と出荷のタイミングがずれるのであれば、注文に対して複数の出荷業務が発生するため、注文と出荷を分けなければならない。分ける必要がある場合は注文が本社で納品先が店舗みたいな、発注者と納品先が異なる場合が１つ。もう１つは同じ商品でも到着日が違う場合。また、注文によってはメーカーの入荷状況に引きずられて、｢入荷次第発送」もある。注文に従ってモノを揃えるってのは結構大変。なので、｢注文内容｣と｢出荷内容｣の差違を可能な限りトラッキングして、｢残があるのかキャンセルなのか」を把握できるのが望ましいけど、実際あんまりチェックしてない。

本部と店舗の親子関係

大きなチェーン店舗に良くあるパターンで、バイヤーと店が分かれている場合。バイヤーが本社でドカンと在庫を抑え、各店に配分する。もしくは各店から発注する。なので、ベストは｢注文は本社で抱えてこめて、それを動的に各店に分配する｣ことができる仕組み。単純だよね。本部と店舗に親子関係を持たせるだけ。1:Nを作るだけ。これだけで使い勝手は格段に向上する。また、もちろんその時は本社で取り置いている注文明細の一覧を引っ張るように。フリーから落とすんじゃないで。

また、良く訓練された会社になると｢Ａ社で取り置いていたものをＢ社に回す」というテクニックが出来るようになる。なので、出荷データに｢取り置いた顧客のID｣を用意しておくと更にグッド。どこの取置がどこに行くのかを把握できるようになる。

取置管理

悩ましいんだけど、一番簡単なのが注文明細テーブルに取置出荷総数を加算するというもの。取置在庫というのは顧客からの注文総数のこと。A001が200､B001が500という注文そのものが取置在庫になるという考え方。なので、出荷する時には｢注文明細IDを記憶しておいて、そこにある出荷総数カラムを++してあげる｣という感じになる。明細をgroupbyすればいいんじゃね？って思うけど、注文明細テーブルだけ引っこ抜く設計はSQL的に楽。注文明細にステータスを持っているから、｢where 顧客コード = ? and 状態 = 'とりおき'｣で抜ける。当然、出荷数に変更があったら出荷明細を直した後にこの注文明細の出荷総数を変更する必要があるから、そこめんどいところ。出荷明細集計して、取置在庫と比較する場合は引っこ抜くのが大変。訂正・削除には強い。トレードオフ。

強引にまとめ

よい子の諸君！DB設計ってのは可能な限り発行するSQLをどれだけシンプルに出来るかどうかってことだな！