itakura

PMS Instance

板倉製作所テナント設定 / Itakura Seisakusho — Tenant Configuration

目的: 汎用 DDD モデルを板倉製作所の業務に適用するためのテナント固有設定。本ドキュメントは DDD モデル (docs/ddd/) の「インスタンス」であり、ケイパビリティ・用語ラベル・区分マスタの初期値・採番ルール・そして §16 MigrationConfig（Phase-3 ETL が READ する移行設定）を記録する。

業種: 高量産自動車部品製造 (repetitive — 繰返生産・かんばん・標準在庫) 旧システム: AS/400 RPG（MENUG1/MENUM/MENUW … 等）— 忠実 TS/Postgres パイロット = itakura-sys 採番キー: 号口 (ごうくち) = BDI- prefix（AS/400 BDIナンバー体系を継承） 決算月: 3月 / 締日: 月末 (31日) / 消費税率: 10% SSOT: 実設定値は configs/itakura/tenant-config.yaml。本書はその設計判断の散文版。

1. 機能ケイパビリティ (§17 Capabilities)

板倉は高量産テナントとして 9 フラグすべてを有効化。world/create は全フラグ false（暗転）。 configs/itakura/tenant-config.yaml の capabilities ブロックを参照（SSOT）。

フラグ	値	対応アグリゲート
`inventory`	`true`	Inventory (StockLedger) — 引当・入出庫
`repetitiveProduction`	`true`	RepetitiveProduction — まとめ連鎖・かんばん・標準在庫
`prototype`	`true`	Prototype — 試作 (ZKDP 'J' 区分由来)
`consignedParts`	`true`	ConsignedParts — アイシン支給品 (SMMP)
`tooling`	`true`	Tooling — 工具・治具
`moldLifecycle`	`true`	MoldLifecycle — 金型 (MDMP)・ショット数
`warehouse`	`true`	Warehouse — 自動倉庫・棚番 (TBMP)
`materialMaster`	`true`	MaterialMaster — 材質 (ZSMP)・板厚 (SZMP)
`ediIntegration`	`true`	EdiIntegration — AS/400 EDI 取込エッジ

スキーマ均一原則: フラグが false でもテーブルは存在する。フラグは「機能が使えるか」を制御。 repetitiveProductionConfig で既定在庫場所 = ITAKURA-WH-MAIN / 既定セグメント = OWNED_PRODUCTION。

2. 用語ラベル (§18 Terminology) + レガシーメニュー対応 (§19 LegacyMenuMap)

AS/400 固有呼称を UI に適用（yaml terminology ブロック — SSOT）。

対象	ラベル	由来
`salesOrder` (entityLabel)	号口	受注の社内呼称
`salesOrder.orderNumber`	BDIナンバー	AS/400 受注№ (JUDP.junoju)
`salesOrder.name`	号口名
`productionInstruction` (entityLabel)	工機	製作指示の社内呼称
`productionInstruction.instructionNumber`	工機番号
`product.designNumber`	設計№	YXMP.yxcdsk（西暦変換マスタ）由来
`productionInstruction.{pending/in_progress/completed}`	未着工 / 着工中 / 完成

legacyMenuMap (onMatch: navigate): AS/400 メニューコード → 新 ScreenId のナビ補助。 MENUG1→procurement_entry（外製）, MENUM→master_product, MENUW→order_detail, MENUS1→sales_entry, MENUJ1→order_list, MENUT1/A1/B1→production_instruction, MENUK1/Z1→master_product, MENUX1→system_settings。

3. 区分マスタ (§3 Classifications) + 採番 (§4 DocumentNumbering)

3.1 単位 (unitOfMeasure)

yaml に登録済み: PCS 個 / SET 式 / UNIT 台 / KG kg / M m / HR h。旧システムには独立した単位マスタは無く、明細列 (sfdp.sftani 等 char 列) に直接保持。 → 移行時は文字列値を上記 6 コードへ正規化（§16 unit-code crosswalk 参照）。

3.2 仕入先・得意先区分

仕入先マスタ simp (PK sicdsi 仕入先コード, numeric)。sicdnc ナイスコード、sid101 転送除外区分。
得意先マスタ tkmp (PK tkcdtk 得意先コード, numeric)。tkd101 営業担当区分。
部品の 内外コード bhmp.bhcdng / jhmp.jhcdng（社内製作 vs 外製の判別）→ InternalProcessCategory にマップ。
社内工程区分 (yaml): PRESS / MACHINING / ASSEMBLY / INSPECT（全 isDirect=true）。

3.3 採番 (yaml `documentNumbering`, `caseKeyMode: per-entity`)

全エンティティ BDI-* prefix・6桁・resetCycle: never。旧 AS/400 の採番カウンタ（NKMP ナンバー管理 / JKMP 受注管理 / RNMP ロット№）を継承する。

entityType	prefix	旧カウンタ (itakura-sys)
`sales_order`	`BDI-`	JKMP.jkrnbn 連番 / JUDP.junoju 受注№
`quotation`	`BDI-Q`	—
`purchase_order`	`BDI-P`	NKMP.nkrnbn（外製発注 MENUG1）
`sales_invoice`	`BDI-I`	NKMP.nknode 伝票番号
`cash_receipt`	`BDI-R`	—
`delivery_notice`	`BDI-D`	—
`supplier_payment`	`BDI-S`	—
`production_instruction`	`BDI-W`	RNMP.rnnort ロット№

currentValue は yaml 上は全て 0。実際の継続開始値は §16 numberSequenceStartValues で与える（下記）。

4. §16 マイグレーション設定 (MigrationConfig) — Phase-3 ETL の中核

これは Phase-3 ETL が READ する唯一の構造化移行設定。 現状 yaml にも Zod ローダ (src/config/tenant.ts) にも 未実装 → Phase-3 ビルドで (a) Zod ブロック追加 + (b) yaml への populate を行う。本節はそのドラフト値。

LOCKED 設計判断:

構造的ルーティング（どの旧テーブル → どのドメインセグメント）は ETL コード側に置く。 §16 legacyCodeMappings には 値レベル の変換表のみを置く。

part_id = 旧品番 (jhbnhn / bhhnbb) をそのまま verbatim。キーイング同一性を保持し、再採番しない。

4.1 `legacyCodeMappings`: `Record<string, Record<string, string>>`

migration:
  legacySystemType: "AS/400 RPG (faithful TS/Postgres pilot: itakura-sys)"
  dataImportStartDate: TBD   # 移行対象の起点 (カットオーバー時に確定)

  legacyCodeMappings:
    # --- 在庫セグメント crosswalk（DOC ONLY: 実ルーティングは ETL コードに存在） ---
    # ZKDP.zkkuzk 在庫区分 → ドメイン在庫セグメント。
    # NOTE: これは「源泉テーブル → セグメント」の構造的ルーティングであり、
    #       実体は ETL コードが持つ。ここには参照用に記録するのみ。
    in_stock_segment:
      "J": "PROTOTYPE"          # ZKDP = 試作品在庫データ → 試作セグメント
      "B": "OWNED_PRODUCTION"   # 量産自社在庫 → 自社生産セグメント
      # 保管場所 ZKDP.zkhkpl (char 20) → locationId は config-locked (ITAKURA-WH-MAIN 等) で ETL 解決

    # --- 値レベル crosswalk（identity-preserved where possible / 実データ確定後に充填） ---
    supplier_code:    {}   # 旧 simp.sicdsi (numeric 6) → 新 supplier code。TBD; 可能な限り identity 保持
    customer_code:    {}   # 旧 tkmp.tkcdtk (numeric 6) → 新 customer code。TBD; 可能な限り identity 保持
    unit_code:        {}   # 旧 明細単位文字列 (sftani 等) → 新 PCS/SET/UNIT/KG/M/HR。TBD
    internal_external: {}  # 旧 内外コード bhcdng/jhcdng → InternalProcessCategory。TBD
    # part_id は remap しない（品番 jhbnhn/bhhnbb を verbatim 採用 — LOCKED）

空 {} の扱い: 値が空の crosswalk は「合成データ Phase-3 ではフィクスチャから種取り、本番カットオーバーでは実データ突合後に充填」を意味する。in_stock_segment のみ確定値を持つ（ただし構造的ルーティング本体は ETL コード側 — ここは参照ドキュメント）。

4.2 `numberSequenceStartValues`: `Record<entityType, integer>`

旧採番カウンタの継続開始値。カットオーバー時に旧 NKMP/JKMP/RNMP の最終連番から carry-over。合成データ Phase-3 では フィクスチャから seed する。

  numberSequenceStartValues:
    sales_order:            TBD   # JKMP.jkrnbn / JUDP.junoju 最終 +1
    purchase_order:         TBD   # NKMP.nkrnbn 最終 +1
    production_instruction: TBD   # RNMP.rnnort 最終 +1
    sales_invoice:          TBD   # NKMP.nknode 最終 +1
    quotation:              TBD
    cash_receipt:           TBD
    delivery_notice:        TBD
    supplier_payment:       TBD

採番継続性は データ完全性ではなくキーイング同一性の問題。板倉の現場が記憶する BDIナンバー／受注№を破壊しないため、新採番は旧カウンタの直後から続ける（§4 currentValue: 0 はこの値で上書き）。

4.3 実装ステータス

項目	状態
§16 Zod ブロック (`src/config/tenant.ts`)	未実装 → Phase-3 で追加
`configs/itakura/tenant-config.yaml` の `migration:` ブロック	未実装 → Phase-3 で populate
構造的ルーティング (源泉テーブル→セグメント)	ETL コード側（§16 ではない）— LOCKED
値レベル crosswalk	§16 `legacyCodeMappings`（本節）— 実データ確定後に充填

5. ギャップ・要確認

legacyCodeMappings の値（supplier/customer/unit/internal_external）は 実データ未突合のため全て TBD。合成データ Phase-3 はフィクスチャ生成側で種取り。
dataImportStartDate および numberSequenceStartValues の具体値はカットオーバー時に旧カウンタから確定。
旧システムに独立した 単位マスタ無し（明細 char 列に直書き）→ unit crosswalk は文字列正規化が必要。
ZKDP テーブルコメントは「試作品在庫データ」だが zkkuzk='B' で量産自社在庫も保持する二役構造。セグメント分岐は ETL コードが担う（本書 4.1 は参照のみ）。