前提（命名ルール）
- 追加DB（空DB）を
kpiとし - スキーマは
kg_pocを推奨 - 企業差分を閉じ込めるため
基本すべてcompany_keyorcompany_idを持つ
1) 組織・原価センタ（企業差分の最重要）
| 目的 | Odoo拡張想定 | kpi DB 新規テーブル案 |
|---|---|---|
| 組織/拠点/部門辞書 | hr.department / res.company / （必要なら res.partner） | kg_poc.org_unit |
| 原価センタ辞書 | 標準で専用テーブルが弱いので拡張で持つ想定 | kg_poc.cost_center |
| 組織→原価センタ | hr.department に拡張フィールド or M2M | kg_poc.org_cost_center_map |
kpi側の最小列イメージ
org_unit(org_key, name, parent_org_key, company_key, external_ref)cost_center(cc_key, name, company_key, external_ref)org_cost_center_map(org_key, cc_key, company_key)
2) 製品・品目・材料（材料ドライバの基盤）
| 目的 | Odoo拡張想定 | kpi DB 新規テーブル案 |
|---|---|---|
| 製品/品目マスタ | product_template, product_product | kg_poc.product |
| 材料辞書（カテゴリ含む） | product_* を材料カテゴリで拡張 | kg_poc.material |
| 製品→材料（BOM視点） | mrp_bom, mrp_bom_line | kg_poc.product_material_map |
kpi側
product(product_key, name, category, company_key, external_ref)material(material_key, name, category, uom, company_key, external_ref)product_material_map(product_key, material_key, company_key, weight?)
3) 工程・ステップ・ルーティング（工程ドライバの基盤）
製造が絡む管理会計/RCAではここが核になります。
| 目的 | Odoo拡張想定 | kpi DB 新規テーブル案 |
|---|---|---|
| 工程辞書 | mrp.routing（バージョン差あり）/ mrp.workcenter と紐づけ | kg_poc.process |
| Step（工程の最小単位） | Odoo標準では抽象度が高いので独自拡張 | kg_poc.step |
| Process→Step | ルーティング拡張 | kg_poc.process_step_map |
| 製品→Process | mrp_routing*/BOM拡張 | kg_poc.product_process_map |
kpi側
process(process_key, name, category, company_key, external_ref)step(step_key, name, sequence, work_center_key?, company_key, external_ref)process_step_map(process_key, step_key, company_key)product_process_map(product_key, process_key, company_key)
4) スキル（説明要因）
| 目的 | Odoo拡張想定 | kpi DB 新規テーブル案 |
|---|---|---|
| スキル辞書 | hr.skill（導入状況次第）/ hr.employee 拡張 | kg_poc.skill |
| Step→RequiredSkill | ルーティング/作業指示拡張 | kg_poc.step_required_skill |
| （任意）人/チームの保有スキル | hr.employee 拡張 | kg_poc.actor_skill |
kpi側
skill(skill_key, name, level_scale, company_key, external_ref)step_required_skill(step_key, skill_key, required_level?, company_key)actor_skill(actor_key, skill_key, actual_level?, company_key)
※ actor は人でもチームでもOK
5) 標準値（標準工数・標準使用量）
| 目的 | Odoo拡張想定 | kpi DB 新規テーブル案 |
|---|---|---|
| 標準工数 | mrp.workcenter/routing拡張 | kg_poc.standard_labor_time |
| 標準使用量 | mrp_bom_line + 工程ひも付け拡張 | kg_poc.standard_material_qty |
kpi側
standard_labor_time(step_key, std_minutes, valid_from?, valid_to?, company_key)standard_material_qty(step_key, material_key, std_qty, uom, valid_from?, valid_to?, company_key)
6) 実績（販売・購買・在庫）
ここはOdoo参照で十分ですが、
PoCで“静的に作る”なら kpi 側に鏡を持ってもOK。
| 目的 | Odoo拡張想定 | kpi DB 新規テーブル案 |
|---|---|---|
| 販売実績 | sale_order, sale_order_line | kg_poc.fact_sales |
| 購買実績 | purchase_order, purchase_order_line | kg_poc.fact_purchase |
| 在庫実績 | stock_move, stock_quant | kg_poc.fact_inventory |
kpi側（任意）
fact_sales(doc_no, product_key, qty, price, amount, org_key?, period_key, company_key, source_ref)fact_purchase(...)fact_inventory(...)
Phase 1 は静的でもOKなので、
ここは“薄く”で大丈夫。
7) 会計（本番で会計が動く想定の受け皿）
あなたの方針どおり、
- Odoo会計UIは今は触らない
- でも 設計としては存在前提
なので、こう併記します。
| 目的 | Odoo拡張想定 | kpi DB 新規テーブル案 |
|---|---|---|
| 仕訳ヘッダ | account_move | kg_poc.gl_entry |
| 仕訳明細 | account_move_line | kg_poc.gl_line |
| 勘定科目 | account_account | kg_poc.gl_account |
kpi側
gl_account(code, name, account_type, company_key, external_ref)gl_entry(entry_key, entry_date, ref, company_key, source_ref)gl_line(entry_key, account_code, debit, credit, memo?, company_key)
PoCはここを静的GLの正本として使うのが安全。
8) Phase 1 の“骨格テーブル”（KPI→Component→Driver）
ここがあなたの設計の中核。
| 目的 | Odoo拡張想定 | kpi DB 新規テーブル案 |
|---|---|---|
| KPI定義 | Odoo標準に相当物なし（独自） | kg_poc.kpi_def |
| Component定義 | Odoo標準に相当物なし（独自） | kg_poc.component_def |
| KPI→Component | 独自 | kg_poc.kpi_component_map |
| Component→材料ドライバ | 独自 | kg_poc.component_material_driver_map |
| Component→工程ドライバ | 独自 | kg_poc.component_process_driver_map |
| KPI結果 | 独自 | kg_poc.kpi_result |
| 結果→根拠 | 独自 | kg_poc.kpi_evidence_map |
kpi側最小列
kpi_def(kpi_key, name, kpi_level, driver_type?, unit?, company_key)component_def(component_key, component_type, name, company_key, external_ref?)kpi_component_map(kpi_key, component_key, company_key)component_material_driver_map(component_key, material_key or material_category, company_key, weight?)component_process_driver_map(component_key, process_key or process_category, company_key, weight?)kpi_result(company_key, period_key, kpi_key, value, calc_basis, notes?)kpi_evidence_map(result_key or company+period+kpi, evidence_ref, company_key)
まとめ：Phase 1 で“現実の開発イメージが湧く”最小セット
Odoo拡張の影が濃い領域
- 組織
- 製品/材料
- 工程/ステップ
- スキル
- 標準値
- 実績（販売/購買/在庫）
- 会計（将来）
PoCの骨格として必ず独自になる領域
- KPI定義
- Component
- KPI→Component→Driver
- KPI結果
- Evidence
あなたの狙いに一番合う運用ルール
- Odoo DB：参照専用
- kpi DB：辞書/標準値/マッピング/静的GL/PoC結果の正本
- Neo4j：kpi DB の派生
これで
「企業ごとの差分は辞書とマッピング」
をRDB設計でも言い切れる状態になります。
コメントを残す