WOaky / 販売大臣リプレイス

倉庫マスタ 再設計 設計図

「場所」と「状態」の混在を解きほぐし、移動・取り置き・出荷を素直に扱えるマスタへ。

作成日: 2026-07-18 / 対象: warehouses / stocks / 倉庫移動・取り置き / ステータス: 設計提案(未実装)
結論。いまの倉庫マスタが汚い根本原因は、「物理的な場所」と「在庫の状態」を1つの倉庫コードに混ぜていること。 移動中・取り置き・不良・処分・調整はすべて「場所」ではなく「状態」なので、別の軸に追い出す。 そのうえで倉庫には エリア(拠点)出荷可否フラグ という構造化属性を持たせる。 取り置きは得意先単位で確保するため専用テーブルで持つ。

1現状の問題

現在の warehouses テーブルは code / name / address / is_active / sort_order しか持たず、 種別・エリア・出荷可否といった構造化属性がゼロ。用途はすべて「倉庫名の文字列」に埋め込まれている。

① 状態を倉庫にしている

移動中・不良・処分・調整・取り置きが、独立した倉庫コードとして存在する。物理拠点ではないのに「倉庫」を消費している。

② 同じ場所が別倉庫に割れている

会津 / 会津工場 / 会津処分、中部 / 中部ダイソー のように、同一拠点が複数倉庫に分裂。倉庫間移動の伝票が立つが物理は動かない。

stock_type が死んでいる

在庫の状態を持てる stock_type カラムは存在するのに、コード全体で常に normal のみ。取り置き等は倉庫側で表現してしまっている。

④ 出荷可否の概念が無い

「この倉庫から出荷する / しない」の区別が無く、is_active を場当たり的に流用。EC受注画面ではフィルタすら掛かっておらず、移動中・不良倉庫まで出荷先に選べてしまう。

224倉庫の仕分け

現マスタ全24件を「場所」と「状態」に仕分けると、再設計後の行き先はこうなる。

コード倉庫名現状の性質再設計後の扱い
0000共通倉庫曖昧用途を確認のうえ実倉庫 or 廃止
0001名田庄実在の場所実倉庫(そのまま)
0002会津実在の場所実倉庫・エリア=会津
0003会津工場同一拠点分割実倉庫・エリア=会津(即時移動対象)
0005福谷実在の場所実倉庫
0007東京実在の場所実倉庫
0008小森樹脂実在の場所実倉庫(取引先)
0009本社実在の場所実倉庫
0011高尾工業実在の場所実倉庫(取引先)
0012若狭塗センター実在の場所実倉庫
0013日笠倉庫第二実在の場所実倉庫
0014小浜センター実在の場所実倉庫
0015中部ダイソー同一拠点分割実倉庫・エリア=中部(即時移動対象)
0016中部実在の場所実倉庫・エリア=中部・既定の出荷倉庫
0017海南実在の場所実倉庫
0019調整在庫状態を倉庫化stock_type=adjustment
0020㈲おおきど遠敷実在の場所実倉庫(取引先)
0021江川製作所実在の場所実倉庫(取引先)
0022セリア(四日市倉庫)実在の場所実倉庫(取引先)
0023(有)彩器実在の場所実倉庫(取引先)
0024不良商品状態を倉庫化stock_type=defective
0025会津処分状態を倉庫化会津の stock_type=disposal
0026ダイソー取り置き(会津)取り置きを倉庫化会津 + 取り置きテーブル(得意先=ダイソー)
0027取り置き(中部)取り置きを倉庫化中部 + 取り置きテーブル(得意先単位)
0099移動中状態を倉庫化廃止(既に未使用)

3新しいデータモデル

「場所(倉庫)」「状態(stock_type)」「得意先向け確保(取り置き)」の3層に分離する。

3-1. warehouses — 場所だけを持つ

🏭 warehouses 既存拡張
code / name / address既存(そのまま)
is_activeレコードの有効/無効(既存)
area_code新規 拠点コード。会津/会津工場→「会津」、中部/中部ダイソー→「中部」で束ねる
warehouse_type新規 種別: normal(自社) / partner(取引先) 等の分類
can_ship新規 出荷可否フラグ。出荷候補の絞り込みに使う

エリアは当面 area_code 文字列で足りる。将来エリア名や代表倉庫を持つなら areas マスタへ昇格させる。

3-2. stocks.stock_type — 在庫の状態を復活させる

📦 stocks 既存カラム活用
product_id / warehouse_id / quantity既存
stock_type既存だが常に normal。今後: normal / defective(不良) / disposal(処分) / adjustment(調整)
unique(company, product, warehouse, stock_type)既存の複合ユニーク制約が、同一倉庫での状態並存をそのまま許容する

= 会津倉庫の中で「正常」「不良」「処分」を stock_type で並存させられる。スキーマ変更不要。ただし引当・出荷ロジックが「出荷対象は normal のみ」を判定する改修が必要。

3-3. stock_holds(取り置き)— 得意先単位で確保

🔖 stock_holds 新規テーブル
product_id対象商品
warehouse_id現物がある実倉庫(会津・中部など)
customer_id誰向けの取り置きか(ダイソー等)。ここが倉庫方式では持てなかった軸
quantity取り置き数量
note / valid_to理由・期限(任意)

取り置きは「場所」ではなく「その実倉庫の在庫のうち、この得意先向けに確保した数量」。 出荷可能数=normal在庫 − 他得意先の取り置き合計 という引き方になる。

4この設計が効くポイント

移動中(0099)は廃止

新しい倉庫移動は「移動中倉庫」を経由していない。ステータスと在庫予約で表現し、在庫は移動元→移動先へ直接付け替えている。

draft(未出庫) in_transit(移動中 = ステータス+予約) completed(入庫・在庫付替) 0099 移動中 倉庫

0099 を参照するコードは一箇所も無い。マスタから落として問題なし。

エリア(拠点)で「瞬間移動」

同一 area_code 内の移動(例: 中部 ⇄ 中部ダイソー)は物理を伴わないので、in_transit を飛ばして即 completed にできる。取り置きをテーブル化したことで、取り置き絡みの「見せかけの移動」はそもそも倉庫移動でなくなる。

出荷倉庫フラグ(can_ship)で候補を統一

不良・処分・調整・取引先預けなどを出荷候補から一律で外せる。今バラバラな受注/EC受注の倉庫絞り込みを can_ship = true に統一する。

5進め方(2段階)

安全な属性追加 + 移動中廃止 在庫計算に触らない

warehousesarea_code / warehouse_type / can_ship を追加。名前に埋まっていた用途を属性化。移動中(0099)を廃止し、同一エリア移動を即時完了に。受注/EC受注の出荷候補を can_ship で統一。ここだけで見た目と誤操作は大きく改善。

状態と取り置きの分離 在庫計算に踏み込む

stock_holds(得意先単位取り置き)を新設し 0026/0027 を移行。不良/処分/調整を stock_type へ。引当・出荷ロジックを「出荷可能数 = normal − 取り置き」に改修。要設計・要テスト。

6確認・未決事項

取り置きの「解放」運用

得意先向け取り置きは、いつ・誰が解除するか(出荷で自動消込 / 手動解放 / 期限切れ)。stock_holds のライフサイクルを決める。

取引先預け倉庫の位置づけ

小森樹脂・高尾工業・セリア等は「取引先に預けた在庫」。warehouse_type=partner で分類し、出荷可否をどうするか。

0000 共通倉庫 / 0019 調整在庫の実運用

現場で何に使っているかを確認してから、廃止か stock_type 化かを最終決定する。