1行＝商品 × 販売先。縦＝商品／横＝納品日に受注数を打ち込みます（↑↓←→・Enter・Tabでセル移動）。販売先は絞り込みで指定。CSV取込でも登録でき、確定後は出荷割当の需要になります。
この画面の軸は 納品日（買い手に着く日。D20）。買い手が言ってくるのは納品日なので、打ち込みも納品日で受けます。倉庫からモノが出る日（出荷日）は 納品日 − 販売先のリードタイム で決まり、出荷割当・出荷指示はそちらの軸になります。
この画面は倉庫経由の受注だけを扱います。直送 は出しません ─ 直送は手で打ち込む運用が無い（買い手のEC・生協システムから CSV／API で入る）ためです。数量と発注は 「直送発注」（仕入）で見ます。
1行＝1件の受注（＝注文書1枚）。行クリックで注文書を開きます。発注書（仕入）と対になる面で、あちらが生産者 × 入荷日でまとめて1枚なのに対し、こちらは受注1件＝1枚です（買い手から届く注文が最初から1件単位なので、まとめ直す理由がありません）。
一覧は納品日順です。買い手が言ってくるのが納品日なので（D30）、探すときの軸も納品日に合わせています。出荷日は注文書の中に併記します（倉庫からモノが出る日＝D20。出荷割当・出荷指示はそちらの軸）。
注文書は「受注時点の値」を自分で持ちます（スナップショット）。販売先名・宛名・住所・TEL・出荷日・単価を受注が持つので、あとで得意先マスタや販売設定を直しても、この注文書は変わりません。持たないとこうなります ─ ①得意先の LT を直した瞬間に、確定済みの出荷割当が別の出荷日にずれる ②得意先が移転すると、過去の注文書の届け先が書き換わる ③販売設定の単価を直すと、過去の受注金額が変わる。
スナップショットが揃うと customer は「毎回入力しなくて済むための既定値の供給源」になります。実際この画面は販売先名も住所も受注のスナップショットから出していて、得意先マスタを引いていません（橙の比較注記だけが引いています）。ただし sales_order.customer_id は必須です（D31）── マスタが既定値に降格しても、得意先の行は (販売先, 商品, 納品日) の一意キー・実績の集計軸・得意先別単価の名寄せのために要ります（先方品番の名寄せは D39 で後回しにしたので、いまの理由からは外れます）。得意先マスタに無い相手は受信箱で1クリック作成してから受注にします。
金額は税抜のみです（軽減税率はインボイス対応まで持ちません）。請求・売掛は対象外なので、注文書は請求書ではありません。
1件＝商品 × 販売先の受注（左5列はエクセルのセル結合と同じ見え方）。割当先のセルは入力規則と同じドロップダウンで、生産者名の右に予定／割当済／残が並びます。選ぶと不足数だけ数量が自動で入り、上書きもできます（供給残・必要数を超える入力は自動で丸めます）。1つの受注を複数生産者に分けるときは行が増えます（不足があれば空行が自動で出る／充足後に分けたいときは ＋行）。↑↓←→・Tab・Enter でセル移動、Enter/Alt+↓ でドロップダウン、Delete で解除。ロットは紐づけません（ロットを持たないため）。
拠点はありません：倉庫は1つなので供給は常に1本で、拠点内訳や拠点跨ぎの警告は出ません（複数拠点は扱わない＝D26）。
作業単位は出荷日（倉庫からモノが出る日。D20）。需要は 納品日 − 販売先のリードタイム で集めるので、同じ画面に納品日の違う受注が並びます。供給は「その日の入荷」ではなくその出荷日までに使える在庫全部（在庫繰越を含む）。FEFO はありません ─ 入荷ごとの残高を持たないので、古い在庫から先に充てるをシステムが選べません。
直送はこの画面に出しません（D20）。①発注＝割当で決着済みなのでここですることが無い ②直送は出荷日を持たないので出荷日軸のグリッドに置き場所が無い、の2つの理由です。変更は直送発注へ。（旧「グリッドにバッジだけ出す」は廃止）
EC（BtoC）は1行しか立ちません。個人宅は customer に入れず、チャネルまるごとで1得意先（自社EC）にしています ─ 個人を得意先マスタに入れると受注数に比例して数万件に膨らみ、得意先マスタが有界であることを前提にした仕組み（一意キー・得意先別単価・会社接続）が全部壊れるため。個人宅は届け先（delivery_destination＝次フェーズ・D8）として受注にぶら下げます。
この形なら割当の手間も増えません。BtoC は産地を指名して買っていないので個人単位で割当先を決める意味がなく、合計数量に対して1回割り当てれば済みます（🛒 の件数がその内訳）。どの生産者の分が誰に届いたかは、割当ではなくピッキングの結果として残す形になります（ロットは割り当てない＝D3 の延長）。ECサイト自体はこのシステムに載せません（外部カート＋決済で、受注だけ API で入る）。
1行＝発注明細1本（仕入先 × 商品）。受け入れると inbound_line が1本でき、在庫変動が1本立ちます（inventory_transaction・txn_type=入荷・qty は＋）。ロットは作りません ─ 在庫のキーは product だけで、入荷ごとの残高は持ちません。
認証は商品（SKU）が持ちます。入荷のたびに選ばせません ─ 認証は「このSKUとして売るときに名乗るもの」なので、有機と慣行は別SKUです（大根 バラ は 特別栽培＝北山ファーム と 有機JAS＝信州高原オーガニック の2つに分かれています）。1人の生産者の入荷が必ず1つのSKUに入るので、在庫プールは重なりません（D2）。
産地は入荷（inbound_line）が持ちます。入荷履歴には残りますが在庫には効きません ─ 束ねSKUは倉庫で産地が混ざるので、いま在庫にある分の産地は確定できないためです。産地を言い切りたい商品は指名SKUにします。
重量の列はありません。表示している換算値は 入荷数 × 商品の baseQty で、実測しません（D35）。物差しは商品ごとに kg か ピース のどちらかで、品目の中で揃っていれば足せます（大根はピース、ほうれん草は kg）。
発注数と入荷数が違ってよい。過不足はそのまま記録し、丸めません（生姜は 発注15 → 入荷14）。発注残の自動突合はしません（MVP対象外）。
取消はこの画面では行を戻すだけですが、実装では打ち消しの在庫変動を1本立てます ─ 履歴が唯一の正なので、立った行を消しません。
1行＝1つのSKUを別のSKUに変える1回の作業（production_order）。投入も産出も1つずつなので、投入と産出を結ぶ中間表が要りません ─ 変換そのものが1行です。バラで仕入れてパッキングする／ロットで仕入れてカットする／箱で仕入れてバラにほどくが、全部この形に収まります。
複数の原料を混ぜる加工は持ちません。産地が混ざることは supplier_id が空の商品（束ねSKU）が既に表しているので、加工で表す必要がありません（D2）。混合を持つと投入と産出が多対多になり、中間表・原価の按分・「どの投入がどの産出になったか」がまとめて発生します ─ それを全部避けるための1対1です。
完了すると在庫変動が2本立ちます（投入は qty が −、産出は ＋）。投入と産出は別SKUなので相殺しません ─ 減る商品と増える商品が違うだけで、在庫変動としては入荷と同じ1本ずつです。原体とパックは別SKUとして在庫に並びます。
歩留まりは列で持ちません。産出 qty × weightG ÷ 投入 qty × weightG で毎回出しています ─ 実重量を測らない（D35）以上、歩留まり「実績」という独立した事実が無いためです。列にすると実測値に見えてしまいます。数える単位では出せません（本 → 袋なので比べられない）ので、どちらかの重量が未入力なら出しません。
ロットは作りません。どのロットを使ったかは残らないので、トレースは入荷履歴までです（束ねSKUは倉庫で産地が混ざるため、もともと在庫の産地は確定できません）。
認証は商品（SKU）が持ちます（D2）。加工製品が何を名乗るかは産出SKU側で決まるので、有機の原料から作るなら製品も別SKUにします。投入と産出の認証が合っているかはシステムでは見ていません。
副資材（ダンボール等）はここでは消費しません ─ 歩留まりに効かず、出荷用資材は加工ではなく出荷で減るためです。資材の在庫は棚卸で合わせます。
在庫が足りなくても止めません ─ 実績はそのまま記録します（入荷の過不足を丸めないのと同じ）。取消はこの画面では行を戻すだけですが、実装では打ち消しの在庫変動を立てます。
現場の作業者が使う画面は別途（未着手）。ここは事務側で加工の予定を立てて、実績を記録する面です。
持つのは名称・産地（郵便番号／都道府県／市区町村）・出荷〜納品リードタイム・生産者PFの招待ステータスだけ。区分・担当者・認証区分は持ちません（認証は商品（SKU）が持ちます）。産地は既定値で、実体は入荷（inbound_line）が持ちます。
出荷〜納品リードタイム＝この仕入先が出してから自社倉庫に納品されるまでの日数。既定の1本に加えて曜日別の上書きを持てます。基準は入荷日の曜日で、出荷日 = 入荷日 − LT[入荷曜日]。出荷曜日を基準にすると入荷日からの逆算が多価になるため、逆算が一意になる側を採っています（このシステムは入荷日が主軸＝D10）。
これに伴い「生産者の出荷日は管理しない」（D11・D20）は撤回しました。ただし生産者PFへの出荷日の表示は後回しで、生産者との会話は当面すべて納品日ベースです。直送のLT（D36）は 仕入先 × 得意先 の行列になるので引き続き持ちません。
招待はモーダルではなくこの一覧の行から送ります（未招待 → 招待済 → 利用中）。招待は属性ではなく行為なので、フォームの項目にすると手で「利用中」にできてしまうため。
取扱商品の登録導線がいまありません（未決）。モーダルから外したため、D19「登録は仕入先マスタの取扱商品から」を満たす画面が無い状態です。データ（supplier_product）は生きていて、下の「取扱商品」列はその件数を出しています。
取扱商品（supplier_product）が「どの生産者がどの商品を出せるか」の唯一の正（D19）。流通事業者が取引開始時に登録し、契約単価もここに持ちます。これが決まらないと生産者アプリの商品リストも発注グリッドの行も作れません（SKUマスタは流通事業者のものなので、生産者側からは選べない）。
商品＝品目×荷姿 ＋ 生産者（任意）＋ 倉庫/直送で1つ（D2・D23）。品種・等級・階級・不定貫/定貫の別は持ちません（商品マスタを簡略化＝D35）。この領域のテーブルは「品目」と「商品」の2つだけです（D38）── 単位・荷姿・分類・産地はマスタ表にせず、商品／品目のテキスト欄で持ちます。値が数個で増えも減りもしないものを表にすると、参照する手間だけが増えました。実重量を測る業務が回らないため、数量1本で運用します（換算重量は総重量の目安だけに使い、金額計算には効かせない）。
登録画面の項目はこれだけです。必須は品目・単位・届け方・用途の4つ。任意が規格・重量・仕入先・単価の4つ。商品名は自動で、人は入力しません。
商品コード（自社SKU番号）は持ちません。人が読む識別は「品目名＋（生産者）＋規格」で足ります（ほうれん草（類農園） 200g×20袋/ケース）。先方品番/JAN も持ちません ─ 対応表は後から作ります（D39）。それまで受注CSVの商品名寄せは受信箱で人が選ぶ形になります。ただし届いた先方品番の文字列は生のまま保存するので、後から対応表を足したときに過去ぶんも名寄せし直せます。
「既定産地」という項目も持ちません。産地は生産者を指名するかどうかで決まります ─ 指名SKUなら生産者マスタの産地、生産者を指定しない商品なら倉庫で混ざるので既定値に意味がありません。どちらにせよ実体は入荷（inbound_line）が持ち、在庫には効きません。
生産者・届け方・用途は互いに絡むので、同じ場所で選びます。ルールは2つだけ ─ 生産者を指定しない商品は「売る」ためのもの（どこから買うかが決まっていないので 仕入のみ にできず、誰から出るかも決まらないので 直送 にもできない）と、直送は1本道（生産者が必須で、用途は 仕入と販売 に固定）。ありえない選択肢は消さずに薄くして、理由をその場に出します（何があるかは常に見えるように）。生産者を外して成立しなくなった選択は自動で戻しますが、黙っては戻しません ─ 何を戻したか画面で告げます。
荷姿は「規格・単位・重量」の3つだけです。うち規格は自由記述（400g×20袋/箱・10本/箱・バラ）で、計算には一切使いません。内装・外装・入数を構造化しても、荷姿の呼び方が現場ごとに違って機械が読める形にならなかったので、見たまま書く欄に降ろしました。
構造で持つのは2つだけ。ひとつは単位（ケース・箱・本…）で、受注・在庫・発注・出荷はすべてこの単位で数えます。規格からは導出しません（自由記述なので確実に読み取れない）。自由入力＋候補なので、コンテナでもオリコンでも書けます。
もうひとつが重量。主語は必ず「1単位ぶん」です ─ 10本/箱 なら箱1つぶんの12kgで、1本ぶんの1.2kgではありません。裏はg固定で持ち、画面のg/kgは入力のしやすさのためだけ。合計もgのまま足して最後にkgへ直します。未入力でも登録できますが、その商品は在庫の重量集計に出ません。
個数（何本・何袋）の集計はできません。入数を構造で持たなくなったためで、集計は重量だけです。戻すなら任意欄を2つ（入数＋その単位）足すことになります。
「販売単位」という列は持ちません。売らない商品があるため、代わりに用途（仕入と販売／仕入のみ＝加工原料・副資材／販売のみ＝加工製品）で区分します。
生産者が空＝指定なし。複数の生産者の入荷が同じ商品に集まることがあり（倉庫で産地が混ざるのが中間流通の付加価値）、1人からしか入らないこともあります ── どちらも「指定なし」です。生産者が入っていれば指名SKUで、その生産者の入荷は必ずこのSKUに入ります（入荷を2つのSKUに割り振らないので在庫プールが重ならない）。引き換えに同じ生産者の仕入を一部は指名・一部は指定なしで売ることはできません。
届け方が「直送」のSKUは、在庫（inventory 残高）も出荷可能も持ちません（倉庫を通らないので在庫変動を立てない＝D7／出荷可能は倉庫への納品ぶんの数字なので直送は表せない＝D22）。大ロットか宅配便かで荷姿が変わるので、実務上はもともと別SKUになります。産地は商品では既定値のみで、実体は入荷が持ちます。認証は商品（SKU）が持ちます ─ ロットを持たなくなったので、認証は「このSKUとして売るときに名乗るもの」になりました。有機と慣行は別SKUです。
チャネル区分（量販/小売/飲食/宅配/加工/EC）を管理。優先度は持ちません（割当ルールを改めて検討するため落としました）。
リードタイム（LT）は 納品日 = 出荷日 + LT の変換に使います（D20）。1販売先＝1納品先なので、LTは販売先の属性1つで決まります。販売設定・出荷割当・出荷指示は出荷日で動き、買い手の画面にだけこのLTを足した納品日が出ます。
納品先の住所はこの表が持ちます（1販売先＝1納品先）。届け先を販売先から切り離す `delivery_destination` は次フェーズです ─ BtoCの個人宅（受注数に比例して増えるので得意先マスタに入れると数万件並び、先方品番・会社接続が機能しなくなる）とチェーンの店舗別納品（本部に請求・各店へ納品）を扱うときに足します。
招待はこの一覧の行から送ります（未招待 → 招待済 → 利用中）。仕入先マスタの「生産者PF」と同じ形で、招待は属性ではなく行為なのでフォームの項目にはしません。招待はアプリを選ぶ操作ではありません ─ 送るのは「この行をあなたの会社に繋ぎます」という1種類だけで、相手が見る画面は相手側にできるミラー行の向きで決まります（仕入先から送れば相手に customer＝こちらは得意先／販売先から送れば相手に supplier＝こちらは仕入先。だから相手には買い手PFが見える）。承諾したときだけ相手の company が生まれ（plan=free）、すでに使っている相手なら増えずに linked_company_id が張られるだけです。
未招待が多数派でかまいません。買い手PFが要るのは買い手自身に注文を入れてもらうときだけで、CSV／API取込・電話＋注文打込なら接続なしで回ります（量販・加工はEDIが普通）。
基準日は出荷日です（D24）。お届け日基準にすると 猶予 = n − LT になり、LTの長い販売先ほど倉庫の準備時間が消えます。買い手の画面には ＋LT した「お届け◯日前まで」で出ます。
空欄＝締切なし。直送には締切がありません（D36）。締切は買い手アプリにだけ効かせ、注文打込・CSV／API取込は止めません。
倉庫は1つです（複数拠点は扱わない＝D26）。ここが発注書の納品先と生産者アプリの受注詳細に出ます。空欄＝自社の住所と同じとして扱います。
設定は専用のテーブルを作らず company の列として持ちます ─ company が生まれる経路は「自分で作る」と「招待されて生まれる」の2つあり、別表にすると両方の経路で行を作らないと「設定行が無い会社」ができるためです（列なら NULL で成立します）。全項目が任意で、plan=free の会社（生産者・買い手として使っている会社）には締切も倉庫も意味がありません。会社に種別カラムは持たない（D1）のでこの画面を plan で分岐させず、埋まっていないことは使う場所（販売設定・発注書）で促します。
company は他社から読まれる唯一の表です（linked_company_id 越し。買い手アプリが売り手の締切を読み、生産者アプリが卸の倉庫住所を読む）。相手に見せるのは 会社名・住所・倉庫・締切までで、plan と URL は自社だけ。
受注に焼き付けません（D33 の対象外）。倉庫の移転は得意先の移転と頻度が違うので、過去の発注書も現在の住所で表示されます。営業日カレンダー・休業日は持ちません ─ 納品日 = 出荷日 + LT の数え方（暦日か営業日か）と注文締切の n日前 の数え方に同時に効くので、リードタイムの粒度と一緒に決めます。