自社業務システムDB設計メモ(仕入・発注編)

これで一旦打ち止めです。

仕入れコピー

お客様から発注が来て、それがＡというメーカーの注文のみだったとしましょう。直送可否に限らず、業務的には｢A社の納品伝票を仕入として入力｣と｢お客様に注文分の納品伝票を作成する｣という２つの業務が発生します。仕入入力の内容と納品の内容が全く同じならば、それをコピーして納品伝票を作成したいですよね！

また、仕入れの場合はメーカー伝票の伝票番号を入力して紐づけることが多いので、仕入れについては伝票番号は自動採番ではなく自由入力可能にして、一意制約もなしで。仕入IDは連番で。そんな感じで。売上伝票は連番でもオレオレルールの採番でも、ご自由に。

仕入れ単価がその時々でまちまち。同じ商品でも去年売れ残って持ち越したヤツ(キャリー品と言いますが)は安くなるし。仕入れ単価は商品に対して複数存在する。マジメに粗利を出す場合は、注文明細テーブルに仕入れ単価を入れ込む必要があるのですが、どこの出荷がその単価で仕入れた商品なのかは確認するのが大変なので非現実的、と。なので、仕入れ単価はまちまちだけど商品テーブルにカラム用意しておｋだと思ってる派。こまけぇこたあ(ry

返品分の仕分

日々販売をしていますと、商品の不良がたまっていきます。売上・請求管理システムなのに商品テーブルに仕入先IDが入っていない設計のDBがあるんですけど、これ絶対良くない。返品はモノが来なければ返せないので請求日はいつになるかわかりませんが、｢2012年1月～2012年2月分のA社の返品合計を品番別に集計｣できれば、モレもなくなる。赤伝の内容など覚えていないわけですし。集計が出来ればその内容をコピーして、仕入の赤伝を起こせば良いだけ。なので、商品テーブルには仕入先IDがないとあきまへん。

複数の仕入先にまたがる調達業務が死ねる

お客様様よりA,B,Cの３社の商材の発注をひとつの注文としてもらったとする。これの調整がゴイスー大変なんですね。その都度メーカーに発注を流すとなると、当然欠品しているモノが出てくる。また、在庫があったとしても１点しかなければ送料がかかる。メーカーが元払いで荷物を出す場合は、送料負担の基準値がある。大抵は卸値合計がウン万円で送料無料になる。先走って送料負担して寄せたとして、その翌日にまた発注かけないといけなくなると、2回分送料かかる。

なので、弊社のお客様からのご注文内容を精査し、メーカーが送料を負担してくれる発注金額まで注文をため込んで集計する必要がある。これを注文内容毎にExcelに転記して集計してたら死ねるので、当然仕入先IDごとにリアルタイムに集計してあげて、発注タイミングを見極められる情報を与えてあげる、と。その次はその集計データを元に在庫確認を行い最終的な数を確定させて、仕入伝票にしてあげる、と。

しかしながら、仕入れは品番単位で納品は顧客単位なので、その仕入れた商品を注文もらった顧客に振り分けてあげる機能が必要になる。そして欠品でなかった場合、顧客が入荷次第の発送を望むことが多いので、仕入先に入荷予定日をもらって注文残テーブルに保管するという処理も必要だ。で、バッチでアラートあげてあげる、と。そろそろ欠品の商材が入荷する頃ですよ、仕入先に確認しちゃいなYOという。そして、A,B,Cの３社商品調達内容が確定して初めて、出荷可否が決められる。そこの情報を営業マンに提供するのが調達管理の仕事。めんどいったらありゃしないのですが、ここをルーチン化できれば業務効率めっちゃage♂age♂やで。

取ってきた注文は明細単位でステータス管理できなければ意味がないってことです。仕入れも同じことが言えます。

とりあえずまとめ

自分の頭の整理のために４回分書いてきて思うんですが、DB設計がクソだと対応していない業務に遭遇した場合、ちょっと手を入れようとすると修正がちょこまか発生する扱いづらいシステムになります。UIがクソだと使いづらい、DB設計がクソだと扱いづらい。コードがクソだと手に負えない。この三すくみの関係。どれかがダメでも、ITシステムの価値はやはり落ちるわけでして。良い意味で僕はジェラリストでありたいなぁ、と。UIは担当者が知りたい情報を教えてあげるモノ、DBは会社が知りたい情報を教えてあげるモノかもしれないっすね。B to Cは一点集中が望ましいのですが、B to Bは複数の問題を解決してあげることが重要かなって思います。

滅茶苦茶ドッグフード喰ってます！これがエンジニアとしての肥やしです！頑張ります！