TATEKANOS Canonical Commercial Architecture

Date: 2026-03-15 JST
Status: Working draft
Purpose: Mitsumori / Toriteki / TATEKAN Core の責務、canonical schema、共通 master、標準連携フローを固定し、個別最適を避けた再設計の正本たたき台とする

1. Architecture Decision (PM-approved 2026-03-16)

master management strategy は次の 3-phase で確定した。

• Phase 1 (NOW): tatekanos_shared に canonical master model を library として追加する
• Phase 2 (post-Toriteki + Mitsumori beta): Core を master-only scope で先行起動し、department / building / business_code / customer / supplier の単一正本とする
• Phase 3 (long-term): 必要なら tatekanos_shared の service 化を検討する

補足:

• Con (TATEKAN Control) は master authority にしない
• Core は beta 後までは pure master authority ではなく、Phase 1 中は各サービスが shared schema + local Datastore で運用する
• 本文書でいう Core = pure master authority は Phase 2 以降の責務 として読む

2. 結論

TATEKANOS の標準形は、次の 3 層構造とする。

• Mitsumori
• 見積正本
• 商流コンテキスト正本（受注前）
• 顧客受注確定まで
• Toriteki
• 仮案件
• 発注
• 履行
• 検収
• 発注/履行進行の正本
• TATEKAN Core
• 共通 pure master 正本
• 受注後商流正本
• 請求 / 入金 / 会計IF 正本
• change set 正式確定

MARCURY は起票元ではなく、商流属性 / 外部連携属性 として扱う。
標準連携フローは次の通り。

Mitsumori
  -> Core
    -> Toriteki
      -> Core
        -> Accounting Adapter

ただしこれは単純な直列ではなく、役割分担は次のように固定する。

• Mitsumori: 顧客向け見積と商流前段
• Toriteki: 協力会社発注と履行実績
• Core: 受注後商流と共通 master と請求/入金/会計

3. 設計原則

3.1 canonical schema 先行

• Core の現行物理DBや GLOVIA販売 テーブルに全体設計を従属させない
• 先に TATEKANOS canonical schema を定義し、その後に Core/GLOVIA へマッピングする
• 物理実装は現行 Core を活かしてよいが、論理設計はそこに縛られない

3.2 pure master と運用拡張の分離

pure master は Core に寄せる。

• department
• building
• business_code
• customer
• supplier

運用拡張は App 側または tenant adapter 側に分ける。

• customer 運用拡張
• 見積段階では Mitsumori
• 受注後は Core
• supplier 運用拡張
• Toriteki

3.3 pure building / pure customer / pure supplier

• building は pure master に保つ
• customer は pure master に保つ
• supplier は pure master に保つ
• 請求先 / 契約先 / 管理会社 / 元請商流先 のような役割情報は master に持たせず、commercial_context に寄せる

3.4 標準形と例外形

• 標準形は Core 併用
• Mitsumori単独 は正式にあり得る
• Toriteki単独 は標準外オプションとして保留する

4. canonical schema の主要 entity

4.1 共通 master

• department
• 組織所属
• 承認系既定値
• 見積既定値
• building
• 基本属性
• 所属 department
• 建物種別
• business_code
• 業務分類
• 会計/売上区分
• 工事分類
• 集計区分
• customer
• pure customer master
• supplier
• pure supplier master

4.2 前段商流

• quotation
• quotation_line
• commercial_context
• quotation_line_execution_map

補足:

• commercial_context は Mitsumori でも正式 entity として持つ
• Mitsumori 見積ヘッダ は複数の commercial_context を持てる
• 見積明細 は commercial_context に明示リンクする
• quotation_line と execution_unit は多対多とし、quotation_line_execution_map に
• 按分数量
• 按分金額
• 補足メモ を持つ

4.3 受注後商流

• sales_order
• execution_unit
• procurement_order
• inspection_event
• invoice
• invoice_line
• receipt
• payment
• accounting_export_batch
• accounting_export_line
• change_set
• approval_event

4.4 粒度ルール

• Core受注1件 は sales_order 1 件
• sales_order 配下に複数の execution_unit を持てる
• execution_unit の標準粒度は 建物 × 業務コード
• execution_unit に対して複数の procurement_order を持てる
• 請求は固定粒度ではなく invoice header + invoice lines

5. アプリ責務

5.1 Mitsumori

責務:

• 見積作成
• 見積承認
• 顧客提示
• commercial_context 前段編集
• 顧客受注確定
• Core への受注昇格起点

補足:

• Mitsumori単独 テナントでは
• 見積作成
• 承認
• 出力/提出
• 受注確度/失注管理
• 簡易受注管理 を標準機能として持つ
• Core 導入テナントでは、簡易受注管理は read-only / 補助表示に留める
• 既存の orders / delegations 相当機能は、Core 併用テナントでは正本機能として維持しない
• orders: Core の sales_order 参照または補助表示へ縮退
• delegations: 見積承認 / 依頼補助へ再定義するか、不要なら整理対象とする

5.2 Toriteki

責務:

• 受注前の仮案件
• 原価見積/RFQ
• 協力会社発注
• 履行
• 検収
• 請求候補化

補足:

• commercial_context は参照のみ
• supplier 運用拡張は Toriteki 主編集
• Toriteki は最終請求正本や最終会計IF正本を持たない

5.3 Core

責務:

• pure master 正本
• sales_order 正本
• 請求対象確定
• 請求確定
• 入金確認
• 会計 export
• change_set 正式確定

UI 方針:

• Core は基幹/管理ハブ寄り
• 主に扱うのは
• master 管理
• 請求確定
• 入金確認
• change set 確定

6. 商流コンテキスト

6.1 定義

commercial_context は、案件上の相手先関係を保持する entity とする。

最低限含むもの:

• 契約先
• 請求先
• 管理会社 / 元請商流先

6.2 配置原則

• building は pure master のまま保つ
• 相手先役割は building や customer に持たせず、commercial_context に寄せ切る
• execution_unit はどの commercial_context に属するかを明示リンクする

6.3 Mitsumori / Core / Toriteki での扱い

• Mitsumori
• 見積段階の正式 entity
• 作成・編集を行う
• Core
• 受注後の正本
• 継続編集を行う
• Toriteki
• 参照のみ

6.4 MARCURY との関係

• MARCURY は commercial_context の一属性または外部連携条件として扱う
• MARCURY への copy-paste / 提出補助の UI 責務は Mitsumori に置く
• 手動運用が残る場合でも、どの画面がそれを補助するかは Mitsumori 側で明確に持つ

7. 標準ライフサイクル

7.1 顧客受注前

1. Mitsumori で quotation と commercial_context を作成
2. 必要なら quotation_line をもとに execution_unit 候補を判定
3. 次の OR 条件を満たす場合、Toriteki に仮案件を起票 - 外注あり - 工事案件 - MARCURY 連動必要
4. Toriteki では 建物 × 業務コード 粒度で仮案件を持つ

7.2 顧客受注確定

1. 顧客受注/契約が確定した時点で Mitsumori -> Core
2. Core に - quotation - quotation_line - commercial_context - sales_order を作成
3. 条件に応じて execution_unit を正式生成

7.3 履行・検収

1. Toriteki で procurement_order を作成
2. 発注・履行・納品・検収を行う
3. inspection_event は Toriteki -> Core へ即時反映

7.4 請求対象化

1. Toriteki が請求候補を作成
2. Core が請求対象化を最終確定
3. invoice / invoice_line を確定
4. receipt / payment と accounting_export へ接続

8. 変更管理

8.1 change_set

• Mitsumori と Toriteki の両方から起票可
• 正式確定は Core
• Core 確定後は Mitsumori / Toriteki へ即時反映

8.2 change_set の対象

• 見積明細
• execution_unit
• 受注増減額
• 追加工事
• 差替
• 減額

9. 承認モデル

承認正本は単一システムに寄せず、業務段階ごとに分散する。

• Mitsumori
• 見積承認
• Toriteki
• 発注承認
• Core
• 請求承認
• change set 承認

department が持つ 承認系既定値 は、承認ルートや承認候補者のデフォルト設定を指す。
承認実績そのものの正本は department に持たせず、各業務段階のシステムと approval_event に記録する。

横断監査用に approval_event を共通記録として持つ。

最低限持つ項目:

• 対象ID
• 承認者
• 結果
• 時刻
• コメント
• 承認段階 / ルート情報

10. 3システム横断連携表

11. Mitsumori / Toriteki の不足・過剰

11.1 Mitsumori に足りないもの

• commercial_context の正式 entity 化
• quotation_line -> execution_unit 多対多マッピング
• business_code 前提の見積構造
• customer pure / 運用拡張分離
• 顧客受注確定から sales_order へ昇格する設計/実装
• change_set 起票モデル
• Core ありテナントでの簡易受注 read-only 化

11.2 Toriteki に足りないもの

• branch / facility から department / building への完全移行
• execution_unit = 建物 × 業務コード 粒度への統一
• commercial_context 参照前提の設計
• procurement_order -> inspection_event -> invoice candidate の canonical 接続
• supplier pure / 運用拡張分離
• change_set 起票モデル

11.3 Mitsumori に余計なもの

• 受注後商流の本格正本化
• 請求/会計まで持つ方向
• agreements / orders を Mitsumori 内部正本として持つ発想

11.4 Toriteki に余計なもの

• 最終請求正本
• 最終会計 export 正本
• branch / facility を family 共通 master として維持すること
• commercial_context 自前正本化

12. 本書のスコープ外

本書は顧客案件に紐づく商流と履行の canonical architecture を対象とする。
次は本書の直接スコープ外とする。

• 一般購買
• 社内消耗品や事務用品の購買フロー
• Toriteki単独 を正式標準形として扱う配備モデル

一般購買は tatekan_responsibility_boundary_memo_20260310.md の整理を参照し、必要に応じて別アーキテクチャで定義する。

13. 実装フェーズ

Phase 1: 共通 master 再編

先行:

• department
• building
• business_code

実装方針:

• tatekanos_shared に canonical master model を library として追加する
• Mitsumori / Toriteki は shared schema を採用するが、この phase では各サービスの local Datastore を使う
• Core はまだ master authority としては起動しない

後段:

• customer
• supplier

Phase 2: Mitsumori -> Core 主線

最小実装で次を一気に通す。

• quotation
• quotation_line
• commercial_context
• 顧客受注確定で sales_order 作成
• 条件付き execution_unit 生成
• これと並行して Core master-only scope を先行起動し、5 master の単一正本を持たせる

Phase 3: Toriteki -> Core 主線

最小実装で次を一気に通す。

• procurement_order
• inspection_event 即時反映
• 請求候補化

Phase 4: 後段統制 / optional shared service 検討

• customer / supplier 再編
• change_set
• receipt / payment
• accounting_export adapter
• 必要なら tatekanos_shared service 化の再評価

14. 保留事項

• Toriteki単独テナント を正式な標準配備モデルにするか
• tenant ごとの adapter 範囲の詳細
• 現行 Core/GLOVIA 物理DBへの具体的マッピング方式
• customer / supplier 後段移行の優先順

15. ClaudeCode レビュー（2026-03-15 19:30 JST）

15.1 全体評価

本文書は responsibility_boundary_memo（2026-03-10）を大幅に発展させた次段の設計文書として十分成立している。canonical schema の定義、pure master vs 運用拡張の分離、commercial_context の first-class entity 化は、Fredy 調査結果とも整合しており設計品質は高い。

15.2 同意する設計判断

• pure master を Core に寄せる判断（department, building, business_code, customer, supplier）
• commercial_context を building/customer に埋め込まず独立 entity とした判断
• execution_unit の標準粒度 = building × business_code
• change_set の分散起票 + Core 確定モデル
• approval_event による横断監査記録
• Mitsumori 単独テナントを正式な標準配備モデルとして認めた判断

15.3 要確認・要明確化の論点

論点1: Mitsumori-first vs Core-first の矛盾解消

responsibility_boundary_memo §3.1 では「Core で案件作成 → Mitsumori で見積作成」としているが、本文書 §6.1 では「Mitsumori で quotation/commercial_context を作成 → 顧客受注確定で Core に sales_order 化」としている。これは逆方向のフローである。

本文書の Mitsumori-first が canonical であるなら、responsibility_boundary_memo の該当箇所を明示的に「旧前提・更新済み」とマークすべき。曖昧なまま残すと実装者が Core-first と Mitsumori-first を混同する。

論点2: department と承認経路のデフォルト設定

Fredy 調査で department に approval_group1-4 が埋め込まれていることを確認した。本文書 §8 では承認を業務段階ごとに分散（Mitsumori=見積承認, Toriteki=発注承認, Core=請求/変更承認）としている。この設計は Fredy パターンより優れている。

ただし明文化が必要: department は「承認のデフォルト設定元」であって「承認実績の正本」ではない。Fredy の承認埋め込みをそのまま継承しないことを明示すべき。

論点3: Mitsumori 既存の /orders, /delegations の扱い

§10.3 で「agreements/orders を Mitsumori 内部正本として持つ発想」を excess と指摘しているが、現在の Mitsumori には既に /orders, /delegations ルートが存在する。移行方針の明確化が必要:

• Core ありテナント: read-only 参照 or Core 昇格前後の補助 UI に縮退
• Mitsumori 単独テナント: 簡易受注管理として限定維持
• delegations: 見積承認/依頼補助へ再定義 or 整理対象

論点4: MARCURY 連携の実務責任

§1 で MARCURY を「商流属性/外部連携属性」として位置付けているのは正しい。ただし、実務的に誰が copy-paste ワークフローを維持するかが未定義。推奨: Mitsumori UI が MARCURY 連携対象案件の提出補助を担う（手動ではあるが UI 責任は Mitsumori 側）。

論点5: 一般購買のスコープ

本文書は顧客案件商流に集中しており、一般購買（社内消耗品・事務用品等）が扱われていない。推奨: §12 保留事項に「一般購買は本 canonical architecture のスコープ外。別アーキテクチャとして扱い、Toriteki を購買ワークフローに流用する余地あり」と明記する。

15.4 追加の設計観察

1. schema と deployment model の分離: Mitsumori 単独可/Toriteki 単独は標準外/Core 標準は「配備モデル」であり、canonical schema とは別の関心事。将来的には別節に分離した方が読みやすい。

2. commercial_context と customer 運用拡張の境界: commercial_context を first-class にした結果、customer 運用拡張との境界を厳密にしないと責務が逆流する。特に請求先/契約先/管理会社は customer 側へ戻さず commercial_context に留めるべき。

3. execution_unit の例外: building × business_code は強い標準粒度だが、time-based recurring services や building をまたがる一括業務が将来出る可能性がある。標準粒度の注記として「例外時は execution_unit を建物横断で束ねる上位 entity を導入する余地あり」程度の escape hatch を記載しておくと安全。

4. Fredy 業務マスターとの関係: 本文書の business_code は Fredy の businesses master に対応する。Fredy 調査で business_code が GLOVIA 連携用コード変換・集計・会計属性付き master であることを確認済み。本文書 §3.1 の business_code 定義（業務分類/会計・売上区分/工事分類/集計区分）は Fredy 実態と整合しており、そのまま採用可能。

TATEKANOS Core Master-Only Design

Date: 2026-03-16 JST Status: DRAFT — ClaudeCode review pending Related Issue: #335

1. Purpose

Phase 2 で TATEKAN Core を pure master authority として先行起動するための基本設計。

この phase の Core は後段商流すべてを持たず、まず 5 master の単一正本を提供する。

対象 master:

• department
• building
• business_code
• customer
• supplier

2. Design Principles

• master authority は Core に一元化する
• commercial flow は後続 phase に分離する
• tenant isolation を最優先する
• canonical schema を先に固定し、物理 Datastore はそれに従属させる

3. Datastore Scope

3.1 Kinds

3.2 Key Policy

• key は {tenant_id}_{code} を基本とする
• code は tenant 内一意
• archive / inactive は論理状態で管理し、物理削除は原則しない

3.3 Common Audit Fields

• tenant_id
• is_active
• is_archived
• created_at
• updated_at
• created_by
• updated_by

4. API Surface

4.1 Basic CRUD

各 master に対し最低限次を持つ:

• GET /api/v1/masters/<master>
• GET /api/v1/masters/<master>/{code}
• POST /api/v1/masters/<master>
• PUT /api/v1/masters/<master>/{code}
• POST /api/v1/masters/<master>/{code}/archive
• POST /api/v1/masters/<master>/{code}/activate

4.2 Bulk / Migration APIs

• POST /api/v1/masters/<master>:bulk_upsert
• POST /api/v1/masters/<master>:validate_import

用途:

• Phase 1 local Datastore からの初回移行
• tenant ごとの定期整備

4.3 Read Requirements

• tenant scoped search
• active / archived filter
• code exact match
• name prefix / partial search

5. Tenant Isolation

5.1 Data Boundary

• すべての read / write は tenant_id を必須条件にする
• cross-tenant lookup は管理者専用の別操作に限定する

5.2 Auth Boundary

• tenant admin は自 tenant の master のみ編集可
• platform admin は横断閲覧・必要時のみ更新可
• service-to-service access は OIDC か同等の server credential を使う

6. Integration with Other Services

6.1 Mitsumori

• 見積画面の master 候補を Core から取得
• Phase 2 以降は local write を停止

6.2 Toriteki

• branch / facility 互換層を保ちながら Core master を参照
• authority write は Core に集約

7. Out of Scope

この文書では扱わない:

• sales_order
• commercial_context
• invoice
• receipt / payment
• accounting_export

これらは Core の後続 phase で追加する。

8. Open Items for ClaudeCode Review

• customer / supplier の canonical field 最終定義
• platform admin と tenant admin の操作境界
• local Datastore を cache にするか、完全に read-through にするか
• import 実行主体を Core UI に置くか、運用 runbook に寄せるか

TATEKANOS Canonical Master Schema — Phase 1

Issue: #335 Phase 1 Date: 2026-03-15 JST Status: Confirmed Related: - docs/Tatekan/tatekanos_canonical_commercial_architecture.md §3.1 - docs/architecture/tatekanos_family_integration.md

1. Confirmed Master Management Strategy (PM-approved 2026-03-16)

TATEKANOS の pure master 管理は、次の 3-phase で進める。

Phase 1 (NOW): tatekanos_shared library 化

• tatekanos_shared に canonical master の model class / validation / serialization を追加する
• ただしこの時点では service 化しない
• Mitsumori / Toriteki / 将来の Core は同じ schema をライブラリとして共有する
• Datastore は各サービスがそれぞれ保持し、各サービスが自分の master を管理する

Phase 2 (post-Toriteki + Mitsumori beta): Core master-only 先行起動

• TATEKAN Core をまず pure master 専用スコープで起動する
• 対象 master は department / building / business_code / customer / supplier
• この時点から Core の Datastore を single source of truth とする
• 後段の commercial flow / invoicing / accounting は Core の後続 phase として追加する

Phase 3 (long-term): tatekanos_shared service 化検討

• library 運用と Core master-only 運用を踏まえて、必要なら tatekanos_shared の service 化を検討する
• ただし現時点では前提化しない

Decision Notes

• Con (TATEKAN Control) は master authority にしない
• post-beta の master authority は Core
• 本文書の schema は Phase 1 の shared library と、Phase 2 以降の Core authority の両方で共通に使う canonical 定義とする

2. 目的

department / building / business_code の3マスターについて: 1. Canonical 項目一覧を定義する 2. Core 正本スキーマ案を提示する 3. Mitsumori / Toriteki / Fredy の現行項目とのマッピング表を作成する

3. Department（部門）

3.1 Canonical 項目一覧

3.2 Core 正本スキーマ案

Kind: tatekanos_departments
Key:  {tenant_id}_{code}

tenant_id               string  required
code                    string  required  unique per tenant
name                    string  required
short_name              string  required
representative          string
postal_code             string
address1                string
address2                string
phone                   string
default_quotation_expiry string          FK -> settings.quotation_expiration
approval_route_default  json            承認ルートデフォルト（後述）
is_active               bool    required default=true
is_archived             bool    required default=false
sort_order              int              default=0
created_at              datetime required
updated_at              datetime required
created_by              string  required
updated_by              string  required

3.3 現行マッピング表

3.4 承認ルートデフォルト設計メモ

Fredy は approval_group1〜4（最大4段階）を department に直接埋め込み。Mitsumori は approval_email_quotation / approval_email_construction で見積承認・工事承認を分離。

Canonical では approval_route_default を JSON で持ち、業務段階ごとのデフォルト承認ルートを柔軟に設定可能とする:

{
  "quotation": ["approver1@example.com", "approver2@example.com"],
  "construction": ["approver3@example.com"],
  "procurement": []
}

注意: これは「承認のデフォルト設定元」であり、承認実績の正本ではない（canonical architecture §8）。

4. Building（建物）

4.1 Canonical 項目一覧

4.2 Core 正本スキーマ案

Kind: tatekanos_buildings
Key:  {tenant_id}_{code}

tenant_id               string  required
code                    string  required  unique per tenant
name                    string  required
short_name              string  required
department_code         string  required  FK -> tatekanos_departments.code
postal_code             string
address1                string
address2                string
building_type           string            enum: own_building / managed_building
phone                   string
owner_name              string
vice_owner_name         string
is_active               bool    required  default=true
is_archived             bool    required  default=false
is_deleted              bool    required  default=false
sort_order              int               default=0
created_at              datetime required
updated_at              datetime required
created_by              string  required
updated_by              string  required

4.3 現行マッピング表

4.4 Toriteki 二層構造メモ

Toriteki は master（toriteki_master_org_*）と operational（toriteki_*）の二層構造。master で保存すると operational に自動同期される。

注意点: - operational 側では branch_name / facility_name が property ではなく key name として格納される - vice_owner_name は master にあるが operational には同期されない - Legacy branch 管理ルート（/admin/branches）も現存

5. Business Code（業務コード）

5.1 Canonical 項目一覧

5.2 Core 正本スキーマ案

Kind: tatekanos_business_codes
Key:  {tenant_id}_{code}

tenant_id                   string  required
code                        string  required  unique per tenant
name                        string  required
name_kana                   string
medium_group_code           string
big_group_code              string
business_division_code      string
business_division_name      string
job_category_code           string
job_category_name           string
price                       decimal
cost                        decimal
selling_price1              decimal
selling_price2              decimal
cost_item_code              string
cost_item_name              string
business_aggregation_code   string
business_aggregation_name   string
sales_division_code         string
sales_division_name         string
sales_cost_item_code        string
sales_cost_item_name        string
is_active                   bool    required  default=true
is_archived                 bool    required  default=false
is_deleted                  bool    required  default=false
created_at                  datetime required
updated_at                  datetime required
created_by                  string  required
updated_by                  string  required

5.3 現行マッピング表

注記: business_code は現時点で Fredy にのみ実装されている。Mitsumori/Toriteki には未実装。canonical architecture §11 Phase 1 で Core に正本を置き、各サービスは参照する設計。

5.4 GLOVIA 連携メモ

Fredy の business_code は GLOVIA 販売連携用のコード変換・集計・会計属性付きマスターとして設計されている（tatekanos_family_integration.md §3 参照）。

TATEKANOS としては、business_code を「Core 連携用コードマスター」として位置付け、Fredy のスキーマをベースに canonical 化する。Mitsumori/Toriteki は見積明細・発注明細で business_code を参照する。

6. 移行時の注意事項

6.1 用語マッピング

6.2 Toriteki 移行の課題

• branch → department: 概念の変更（営業拠点 → 業務統制単位）。承認系・見積既定値の追加が必要
• facility → building: 概念の変更（現場 → 管理対象物件）。building_type の追加が必要
• 二層構造（master + operational）は維持するか、canonical 統合で一層化するか要検討
• operational 側の key name = entity name パターンは canonical では廃止し、code ベースに統一推奨

6.3 Mitsumori 現行の強み

• 既に department/building（facility）構造を採用済み
• Fredy に近い項目セット（representative, postal_code, address, default_quotation_expiry, approval_email）
• toriteki_facility_id でToriteki連携リンクを持つ
• canonical 移行コストが最小

変更履歴

TATEKANファミリー連携アーキテクチャ

作成日: 2026-03-15 作成者: ClaudeCode（Codex調査結果に基づく） ステータス: Draft — PM確認待ち

1. 概要

TATEKANファミリーは以下のサービスで構成される:

設計原則: Fredyの運用パターンを模倣し、Mitsumori/Toritekiの共通基盤（tatekanos_shared）を統一する。

2. Fredyマスターデータアーキテクチャ

2.1 組織・物件軸（Department + Building）

Fredyは 部門（Department）が親、建物（Building）が子 の構造を採用。

Department（部門）マスター

特徴: - 単なる組織単位ではなく、承認経路・見積有効期限を持つ「運用設定付き上位マスター」 - Toritekiの「支店（branch）」より業務統制機能が豊富 - 承認系は独立マスターではなく、部門マスターに埋め込み

Building（建物）マスター

特徴: - 部門配下の管理対象物件 - 一覧画面でログインユーザーの部門を初期選択 - CSV一括インポート/エクスポート対応

2.2 横断コードマスター群

Settings マスターの分類値

2.3 Toritekiとの比較

移行時の注意: 単純renameではなく、branch（営業拠点寄り）→ department（業務統制単位）、facility（現場寄り）→ building（資産/管理対象物寄り）への概念マッピングが必要。

3. 業務マスター（Businesses）詳細

3.1 位置付け

Fredyの業務マスターは GLOVIA販売 = TATEKAN Core連携を成立させるためのコード変換・集計・会計属性付きマスター。

Fredy内部のUX起点ではなく、外部基幹システムに渡すためのコード体系を内包している。

3.2 データモデル

3.3 REST API

3.4 用途

• 見積/契約/発注の明細に付与するコード（business_idが必須選択）
• 原価・売価・費目・売上区分など会計/集計属性を伴う分類マスター
• 工事種別候補（medium_group_code === '8C'）
• GLOVIA販売の費目コード・売上区分・業務集計区分とのマッピング

3.5 Mitsumori/Toritekiへの移植方針

department/buildingの代替ではなく、別カテゴリの「Core連携用コードマスター」 として切り分けて扱う。

4. TATEKANファミリー業務フロー

4.1 全体フロー（正常系）

Mitsumoriで見積作成
  → 社内承認/確定
  → Mercury連携有無を分岐
    ├─ Mercury連携案件: Mercuryにコピペ
    └─ 非Mercury案件: Mitsumoriから直接見積発行
  → 顧客受注確定
  → Coreで受注票起票/受注正本化
  → Toritekiへ履行案件連携
  → Toritekiで出来高/検収管理
  → Coreへ請求対象連携
  → Coreで請求確定/売上計上
  → 会計システム連携

4.2 設計上の確認必須論点（10項目）

4.3 サービス間責任分界

5. 共通基盤（tatekanos_shared）への統合方針

5.1 マスター共通化の基準モデル（Fredy準拠）

5.2 Toriteki移行計画

• branch → department へのマッピング層を設計
• facility → building へのマッピング層を設計
• 既存データの移行スクリプト作成が必要
• 段階的移行: まずMitsumoriでdepartment/building実装 → Toritekiは後続Phase

変更履歴