卸売・商社の受注管理が崩れる典型は、「受注＝1件＝1回で出荷・請求が終わる」という前提でシステムを作ってしまうことです。 実際は、分納（部分出荷）、直送（メーカー直送）、取り寄せ、メーカー回答待ち、バックオーダー（欠品繰越）が混在します。 この混在を“受注のステータス”だけで表現しようとすると、どこかで破綻します。
卸売の設計では、最低でも次の粒度を分けて考えると破綻しにくいです。
この「粒度を分ける」発想は、問い合わせ管理で「案件」と「履歴」を分けるのと近いです。一覧の見せ方や保存ビューの考え方は 保存ビュー・フィルタ設計 が参考になります。
受注ヘッダに細かい工程を入れすぎると、更新されなくなります。 ヘッダのステータスは、全体の顔として「今この受注はどこで止まっているか」を示す程度に絞るのが現実的です。
ステータスを増やしすぎないルール作りは ステータス運用の決め方 が土台になります。期限や優先度が絡む場合は 期限・優先度の運用 とセットで決めると、現場が回りやすいです。
明細は、調達方法（在庫／取り寄せ／直送）で実務が変わります。 ここを一つのステータス列で表現しようとすると、例外だらけになります。まずは明細に「調達区分」を持たせ、その区分ごとに必要な状態を持ちます。
| 調達区分 | 代表的な状態 | 詰まりポイント |
|---|---|---|
| 在庫出荷 | 引当済→出荷待ち→出荷済 | 引当の優先順位、欠品 |
| 取り寄せ | 発注済→メーカー回答待ち→入荷待ち→出荷 | 納期回答、部分入荷 |
| 直送 | 直送依頼→出荷連絡待ち→直送完了 | メーカー側の出荷情報の遅れ |
「回答待ち」「入荷待ち」のような“待ち”を明確にするのが、実務の渋滞を減らします。待ちの扱いは、問い合わせ管理の視点で ステータス設計の実例 も参考になります。
分納や欠品繰越が起きると、数量が割れます。 ここで「明細数量＝出荷数量」としてしまうと、履歴が追えません。おすすめは、明細に「受注数量」と「残数量」を持ち、出荷（ロット）を積み上げて残数量を減らす方式です。
残数量がある案件だけを追い込みたい場合、一覧のフィルタが命です。フィルタ設計の考え方は ビュー・フィルタ設計 を土台にすると、現場の“探す時間”が減ります。
卸売では、誰が最終責任を持つかが工程で変わります。 「受注担当＝営業」だけにすると、受発注担当や倉庫が動けません。 逆に「全部受発注担当」にすると、顧客調整（納期交渉）が回りません。 現実的には、責任を段階で移譲する設計が合います。
割当の基本ロジック（自動候補＋手動確定）を作るなら 担当者割当ロジック が土台になります。 また、振り分け条件（エリア・取引先・商品カテゴリ）を固めるなら 振り分けルールの決め方 が役立ちます。
卸売の実務負荷の多くは、納期回答の往復です。 受注段階で必要条件（納入先、時間指定、直送可否など）が揃っていないと、納期回答ができません。 見積や問い合わせの入力設計としては BtoBフォームの入力項目チューニング の考え方で、「納期回答に必要な最小セット」を先に揃えると、往復が減ります。
卸売・商社の全体像（見積→受注→出荷→請求）を俯瞰するなら、卸売・商社（BtoB企業）向け を入口に整理すると、ステータス設計が“ただのラベル付け”で終わらず、部門間の役割分担まで固まります。
卸売・商社の受注管理は、分納・直送・バックオーダーが混在するため、受注ヘッダだけで表現すると破綻します。 受注・明細・出荷・請求の粒度を分け、ヘッダは最小ステータス、明細は調達区分ごとの“待ち”を表現する。数量が割れる前提で出荷ロットを積み上げ、担当割当を段階移譲にすると、迷子と放置が減ります。