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