# 工程2レビュー：システム設計（基本設計）

> ⚠️ 命名整合性注意：`schedules` テーブル定義では「工程2＝システム設計」。実運用の `process_02_inbound.md`（入荷・受入）とはファイル名が衝突気味。命名整理は朝の時吉さん判断（`kurokun_memo` #87）。本ファイルは **schedules 定義に従った「システム設計」** の論点叩き台。

---

## 工程番号・タイトル

**工程2：システム設計（基本設計）**（致命傷ライン）

致命傷ライン15項目のうち以下を本工程で詰める：

- **業務フロー4項目**（BF-1〜BF-4）— 一部は process_02_inbound.md と process_03_db_design.md で先行叩き台
- **計算式2項目**（CA-1, CA-2）
- **権限・ID2項目**（AU-1, AU-2）
- **連携2項目**（LK-1, LK-2）

DB 設計5項目は工程3（process_03_db_design.md）で別途扱う。

---

## レビュー実施日

2026-05-08（叩き台作成・まーちゃん。今夜は CA-1 と AU-1 を最優先で叩き台化。残り6項目は未着手・朝以降）

---

## 関連する致命傷ライン

| ID | 項目 | 状態 |
|----|------|------|
| BF-1 | 検品・ピッキング順序 | **確定済（D=荷主切替）** ✓ memo #62 |
| BF-2 | 引当ロジック | 未着手 |
| BF-3 | ピッキング方式 | 未着手 |
| BF-4 | 返品・誤出荷処理 | **確定済（B=在庫に載せず別ステ）** ✓ |
| **CA-1** | **請求賃率計算** | **本ファイルで叩き台 ✓** |
| CA-2 | 原価評価方式 | 未着手 |
| **AU-1** | **権限・承認フロー** | **本ファイルで叩き台 ✓** |
| AU-2 | SKU/JANコード管理 | 未着手 |
| LK-1 | 外部連携方式 | 未着手 |
| LK-2 | HTバーコード仕様 | 未着手 |

---

## 論点リスト

### CA-1：請求賃率計算 ★3PL 収益モデルの根幹

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | 倉庫保管料・入出庫料の計算方式（請求書を生成するエンジン） |
| 選択肢A | 3期制のみ対応（日本の伝統的方式：1ヶ月を10日ずつ3期に分け、各期末在庫×単価） |
| 選択肢B | 2期制のみ対応（1ヶ月を15日ずつ2期に分け、各期末在庫×単価） |
| 選択肢C | 坪貸しのみ対応（占有面積×月額単価） |
| 選択肢D | 全方式対応＋荷主切替（荷主マスタに「請求方式」フラグ） |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **D**：中小3PL は荷主によって請求方式が違う。3期制は食品系、坪貸しはアパレル・雑貨系で多い。差別化4点「機能ON/OFF制」と整合。さらに「日割り保管料」「ピース単価」「ケース単価」「期間外入出庫料」も荷主マスタで切替可能にする |

**仕様への影響（仮）：**
- `billing_rules` テーブル：`(id, owner_id, rule_type, period_type, unit_price, ...)` で荷主×ルール種別の単価マスタ
- `period_type` enum：`3-period` / `2-period` / `daily` / `monthly` / `tsubo` ...
- 月次バッチ：期末（10日/20日/月末）に在庫スナップショットを取り、`billing_history` に書き出し
- 入出庫料は `inbound_movements` / `outbound_movements` の件数 × 単価で都度計算
- 致命傷ライン CA-2（原価評価）と独立して動く設計（請求 ≠ 原価）

**3PL 業界の典型単価モデル（参考）：**
- ケース単価：保管料 50〜150 円/ケース・期、入出庫料 30〜80 円/ケース
- 坪単価：5,000〜15,000 円/坪・月（地域・倉庫グレードで大きく変動）
- 日割り保管料：在庫数の平均×単価×日数（食品の冷凍・冷蔵品で多い）

---

### BF-2：引当ロジック

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | 出荷指示に対して在庫からどの単位（ロット・ロケーション）で引き当てるかの優先順位 |
| 選択肢A | FIFO 強制（先入先出・全荷主一律） |
| 選択肢B | LIFO（後入先出） |
| 選択肢C | ロケ優先（ピッキングロケ → 保管ロケ） |
| 選択肢D | 多軸＋荷主切替（FIFO ＋ ロケ ABC クラス順 が基本・荷主指定で変更可能） |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **D**：食品系は FIFO 必須（消費期限）、雑貨系は LIFO 容認、家電はシリアル先指定。荷主マスタに「引当方式」フラグ。さらに `locations.abc_class` と連動してピッキング動線を最短化 |

**仕様への影響（仮）：**
- `owners.allocation_strategy` enum：`fifo` / `lifo` / `lpa`（lot-priority）/ `custom`
- 引当バッチ：出荷指示 → `inventory_allocations` テーブル（仮押さえ）→ ピッキング指示
- 致命傷ライン DB-1（在庫の持ち方）/ DB-2（ロット）/ DB-5（ロケーション）と密接

---

### BF-3：ピッキング方式

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | ピッキング指示の出し方・グルーピング |
| 選択肢A | シングル（1出荷指示 = 1ピッキング） |
| 選択肢B | バッチ（複数出荷指示まとめてピッキング → 後で仕分け） |
| 選択肢C | ウェーブ（時間帯で集約・効率化） |
| 選択肢D | 切替制（小ロットはバッチ、大量出荷はウェーブ・荷主×荷量で自動切替） |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **D**：中小3PL は荷量変動が大きいので柔軟切替が肝。`pick_strategy_rules` テーブルで荷主×荷量×時間帯のルールを定義 |

**仕様への影響（仮）：**
- `picking_waves` テーブル：`(id, owner_id, strategy, planned_at, status, ...)`
- `picking_orders` テーブル：`(id, wave_id, allocation_id, location_id, sku_id, quantity, picker_id, ...)`
- HT 画面でウェーブ単位の指示表示
- 致命傷ライン LK-2（HT バーコード）と密接

---

### CA-2：原価評価方式

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | 在庫の原価（評価額）の計算方式 |
| 選択肢A | 移動平均法（入荷の都度平均更新） |
| 選択肢B | 総平均法（月末まとめて平均） |
| 選択肢C | 先入先出法（FIFO 評価） |
| 選択肢D | 最終仕入原価法 |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **A**：移動平均法。日本の中小3PL の標準。リアルタイム評価可能、税務会計とも親和性が高い。会計ソフト連携時の標準値 |

**仕様への影響（仮）：**
- `inventory_movements` に `unit_cost`（その時点の単価）を記録
- 移動平均更新ロジック：`new_avg = (existing_qty * existing_avg + new_qty * new_cost) / (existing_qty + new_qty)`
- ただし「3PL は荷主の在庫を預かるだけで原価を持たない」運用も多い。荷主マスタに「原価管理する／しない」フラグを置き、する場合のみ A を適用
- 致命傷ライン CA-1（請求賃率）とは独立（請求 ≠ 原価）

---

### AU-2：SKU/JANコード管理

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | SKU マスタのコード体系（複数荷主跨ぎ・JAN 重複の扱い） |
| 選択肢A | 荷主指定 SKU コードをそのまま PK に使用 |
| 選択肢B | WMS 側で内部 SKU ID を採番、荷主 SKU はマッピングテーブル |
| 選択肢C | JAN ベース（荷主跨ぎでも統一） |
| 選択肢D | 荷主×内部 SKU ID＋JAN マッピング（最も柔軟） |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **D**：複数荷主で同じ JAN を扱うことがあるが、荷主ごとに別在庫として管理する必要がある（3PL の基本）。`skus` テーブルに `(id, owner_id, sku_code, jan, ...)` で UNIQUE(owner_id, sku_code)・別途 JAN インデックス |

**仕様への影響（仮）：**
- `skus` テーブル：`(id BIGINT PK, owner_id BIGINT, sku_code TEXT, jan TEXT, ...)`
- UNIQUE 制約：`(owner_id, sku_code)` と `(owner_id, jan)`
- HT 読取時：JAN → 荷主絞込 → SKU 特定（荷主切替モード時）
- 致命傷ライン LK-2（HT）/ DB-4（荷主切替）と密接

---

### LK-1：外部連携方式

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | 荷主・上位システムとの連携方式 |
| 選択肢A | CSV インポート/エクスポートのみ（手動・FTP/メール） |
| 選択肢B | API（REST・荷主から自動連携） |
| 選択肢C | EDI（業界標準・大手向け） |
| 選択肢D | 全方式対応＋荷主切替（CSV をデフォルト・API 優先・EDI は将来） |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **D**：差別化4点「連携費用無料」と整合（CSV/API は連携追加で課金しない）。EDI は中規模 3PL 以上で要望が出る見込み・将来対応。フォーマット定義は荷主マスタ単位 |

**仕様への影響（仮）：**
- `connectors` テーブル：`(id, owner_id, connector_type, config, ...)` で接続情報
- API：Supabase Edge Function で受信エンドポイント、JWT 認証
- CSV：定型フォーマット（出荷指示・入荷予定・在庫照会）の3点セット
- EDI：JCA手順 / 全銀手順 を将来実装（Phase 後期）
- 致命傷ライン AU-1（権限）と AU-2（SKU/JAN）に依存

---

### LK-2：HTバーコード仕様

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | HT（ハンディターミナル）で読み取るバーコードの種別・運用 |
| 選択肢A | JAN のみ |
| 選択肢B | JAN + 荷主独自バーコード |
| 選択肢C | JAN + 荷主独自 + シリアル + ロット（多軸） |
| 選択肢D | 荷主切替（荷主マスタで読取項目フラグ） |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **D**：キーエンス HT 連携時に必須の柔軟性。荷主マスタに `barcode_required_fields`（jan/serial/lot/owner_sku の組合せ）を持つ |

**仕様への影響（仮）：**
- HT アプリ画面：荷主切替時に読取シーケンスが変わる（serial 必須なら追加読取）
- バーコード種別：JAN13 / Code128 / QR の混在対応
- 読取結果バリデーション：`skus` テーブルの `serial_required` / `lot_required` と整合確認
- 致命傷ライン DB-3（シリアル）/ AU-2（SKU/JAN）と密接

---

### AU-1：権限・承認フロー ★DB-4 荷主切替と密接

> ⚠️ **時吉さん未回答（まーちゃん叩き台・要レビュー）**

| 項目 | 内容 |
|------|------|
| 論点 | ロール別アクセス権限と承認ワークフローの設計 |
| 選択肢A | フラット（管理者／オペレーター の2階層・全荷主アクセス） |
| 選択肢B | 荷主×ロール（荷主ごとにロール権限を設定・倉庫スタッフは複数荷主見える） |
| 選択肢C | 倉庫拠点×荷主×ロール（複数倉庫・複数荷主の3階層） |
| 選択肢D | カスタマイズ可能（権限マトリクスをマスタで設定） |
| **時吉さん回答** | （未回答） |
| まーちゃん推奨 | **B**：中小3PL のターゲット規模では「複数倉庫対応」より「複数荷主対応」が優先。差別化4点「カスタマイズ不要設計」と整合（D は重い）。Supabase RLS ポリシーで実装可能。倉庫拠点が増えた段階で C に拡張可能な構造で設計しておく |

**仕様への影響（仮）：**
- `users` テーブル：Supabase Auth と連動
- `user_owners` 中間テーブル：`(user_id, owner_id, role, granted_at, granted_by)` で複数荷主の権限を持たせる
- `role` enum：`admin`（全荷主管理）／`operator`（割当荷主の操作）／`viewer`（割当荷主の閲覧のみ）／`shipper`（荷主自身：自分の荷主データのみ）
- 承認フロー：出荷指示の承認・在庫調整の承認・荷主請求書の確定など、important なステータス遷移は `approval_required` フラグで制御
- 致命傷ライン DB-4（荷主切替）と RLS ポリシーを共有する設計

**承認フローの典型ケース：**
- 出荷指示：オペレーターが入力 → 管理者承認 → ピッキング指示
- 在庫調整：オペレーター起案 → 管理者承認 → 在庫反映
- 棚卸差異：オペレーター記録 → 管理者承認 → 在庫補正

---

## 決定事項サマリー

| 論点 | 決定内容 | 致命傷ライン該当 | ファイル |
|------|----------|----------------|---------|
| BF-1：検品・ピッキング順序 | **確定済（D=荷主切替）** ✓ | BF-1 | process_02_inbound.md Q2 / MORNING_DECISION_SHEET.md |
| BF-2：引当ロジック | （未確定・まーちゃん推奨 D：多軸+荷主切替） | BF-2 / DB-1 / DB-2 / DB-5 | 本ファイル |
| BF-3：ピッキング方式 | （未確定・まーちゃん推奨 D：荷量×荷主切替） | BF-3 / LK-2 | 本ファイル |
| BF-4：返品・誤出荷処理 | **確定済（B=在庫に載せず別ステ）** ✓ | BF-4 | process_02_inbound.md Q5 / MORNING_DECISION_SHEET.md |
| CA-1：請求賃率計算 | （未確定・まーちゃん推奨 D：全方式+荷主切替） | CA-1 | 本ファイル |
| CA-2：原価評価方式 | （未確定・まーちゃん推奨 A：移動平均法） | CA-2 | 本ファイル |
| AU-1：権限・承認フロー | （未確定・まーちゃん推奨 B：荷主×ロール） | AU-1 / DB-4 | 本ファイル |
| AU-2：SKU/JANコード管理 | （未確定・まーちゃん推奨 D：荷主×内部SKU+JAN） | AU-2 / LK-2 / DB-4 | 本ファイル |
| LK-1：外部連携方式 | （未確定・まーちゃん推奨 D：CSV+API+EDI 切替） | LK-1 | 本ファイル |
| LK-2：HTバーコード仕様 | （未確定・まーちゃん推奨 D：荷主マスタで読取項目） | LK-2 / DB-3 / AU-2 | 本ファイル |

---

## 朝の依頼カード（叩き台）

```
──────── 依頼カード ────────
タイトル：致命傷ライン残り 6 項目の論点叩き台作成
要件：
  1. BF-2（引当ロジック）/ BF-3（ピッキング方式）/ CA-2（原価評価）/ AU-2（SKU/JAN）/ LK-1（外部連携）/ LK-2（HTバーコード）
  2. 各項目で A〜D 選択肢・まーちゃん推奨を起こす
  3. specs/process_02_system_design.md に追記
推奨 assigned_to：6（まーちゃん・PM 業務）
verification_method：成果物URL（GitHub specs ファイル）
estimated_minutes：60
背景：致命傷ライン15項目の完備＋8月末ゴール厳守。
────────────────────────────
```

---

## 次工程への申し送り

- AU-1（権限）の決定は工程3 DB-4（荷主切替）と整合確認必須。Supabase RLS の policy をどちらの工程で確定させるか朝の判断
- CA-1（請求賃率）は工程13（帳票・レポート機能）の請求書出力と直結。CA-1 確定後に工程13 仕様着手
- 残り 6 項目（BF-2, BF-3, CA-2, AU-2, LK-1, LK-2）は朝以降の依頼カードで起票

---

*最終更新: 2026-05-08 / Phase 6-D まーちゃん（致命傷ライン15項目すべて叩き台化完了：BF/CA/AU/LK = 8項目を本ファイルに、DB = 5項目を process_03、入荷論点は process_02_inbound.md）*