为什么不能"开箱即用"
如果你直接拿 Odoo 标准的 MRP/PLM 去管电子产品制造，很快会撞上一堵墙：位号（Reference Designator）、AVL/AML（合格供应商/制造商清单）、器件生命周期状态、CPL/Centroid 工程文件、批次到位号级的追溯、车间执行（MES）——这些电子（PCBA/SMT）制造的刚需，Odoo 原生能力和现有开源生态都没有整体覆盖过。
这不是 Odoo 的锅，它本来就是为通用离散制造设计的最小闭环。真正的问题是：怎么在不推倒重来的前提下，把这些能力一点点补齐。
我们的答案是：不追求一次性补全，按投入产出比从高到低分阶段推进。先把数据模型的地基（BOM 层）打牢，再补质量体系，再做替代料和工程变更管理，最后才评估外部元件库和 MES——这也是为什么追溯与 MES 明明投入最大，却排在最后：对"先把 BOM 管起来"这件事，它们的边际帮助最小。
路线图全景
| 阶段 | 目标 | 依赖 | 优先级 |
|---|---|---|---|
| Phase 1 | 电子物料 BOM 数据模型扩展 | 无，立即可开始 | 高（地基） |
| Phase 2 | 器件生命周期与分销商数据对接 | Phase 1 字段就绪 | 高 |
| Phase 3 | 替代料（Alternate Component）管理 | Phase 1 | 中 |
| Phase 4 | 质量体系补齐（OCA quality_control 移植） | 无，可并行 | 中 |
| Phase 5 | 工程变更管理（ECO/ECN 轻量版） | Phase 1 | 中 |
| Phase 6 | 元件库外部化评估（InvenTree POC） | 无，可独立评估 | 低 |
| Phase 7 | 追溯与 MES 长期规划 | Phase 1-3 上线后 | 低（仅立项跟踪） |
关键的排序逻辑：Phase 1 是唯一的强前置依赖。位号、MPN、生命周期状态这些字段一旦定型，后面的分销商数据回填、替代料、BOM 版本化全都直接建在它的数据结构之上——返工成本最高，所以必须最先独立启动。Phase 4 不依赖 Phase 1，可以并行推进。Phase 6、7 是评估性质，不占主线开发资源，可以见缝插针地穿插进行。
分阶段怎么做
Phase 1 · 电子物料 BOM 数据模型扩展（地基）
把位号、MPN、AVL/AML、生命周期状态四类信息落到 Odoo 的 BOM/产品数据模型里。计划新建模块 inair_electronics_bom（依赖 inair_common + mrp），核心动作包括：
mrp.bom.line扩展reference_designator（位号），支持一个 BOM 行对应多个位号；- 新增
product.manufacturer.part（制造商料号）模型，关联产品、制造商、MPN、生命周期状态（active/nrnd/eol/obsolete）； - 扩展
product.supplierinfo或新建 AVL 关联模型（供应商 + 优先级 + 认证状态）； - 改造 BOM list/form 视图，支持按位号搜索；
- 存量数据迁移脚本，不影响现网数据；
- 字段约束 + BOM 展开/成本计算的回归测试。
验收标准很朴素：现有 BOM 功能零回归，新建 BOM 能录入位号/MPN/AVL，旧数据迁移后不会因字段为空而报错。风险也很明确：BOM 行结构改动影响面广，采购、成本核算都读 BOM，上线前必须在测试库跑一轮完整回归。
Phase 2 · 器件生命周期与分销商数据对接
让生命周期状态和合规属性不再靠人工维护。调研 Octopart/贸泽（Mouser）/Digikey 的开放 API，在 inair_common 的 base.external.dbsource 框架上扩展 REST 类型数据源适配器，用 ir.cron 定时按 MPN 批量回填生命周期状态、RoHS/REACH 合规属性；BOM 中出现停产/不推荐器件时，通过 mail.activity 或看板预警。风险点是 API 额度和费用，需要先确认业务量级是否在免费额度内。
Phase 3 · 替代料（Alternate Component）管理
BOM 中一个位置可以配置多个可用元件，按优先级 + 数量换算比例排列。生产发料时（扩展 mrp.production/stock.move）可以选替代料，库存正确扣减；成本核算要反映替代料的实际用料价格。
Phase 4 · 质量体系补齐（OCA quality_control 移植）
在没有企业版 Quality 模块的前提下，评估 OCA/manufacture 下的 quality_control_oca 系列是否有 19.0 分支，没有就走 quilt 或自维护模块移植。配置 IQC（来料）、IPQC（制程）、FQC（成品）三类质检点模板，分别挂接采购入库、生产工单、成品入库节点，质检记录与生产批次关联，为 Phase 7 的追溯打基础。
Phase 5 · 工程变更管理（ECO/ECN 轻量版）
不依赖企业版 PLM，mrp.bom 增加版本号字段及历史版本关联；新建 product.change.order 变更单模型，复用 mail.thread/activity 或 project 工作流做审批；变更生效时检查受影响的在制生产订单/在库物料，给出冲突提示（先做提示级，不要求自动处理）。
Phase 6 · 元件库外部化评估（InvenTree POC）
评估是否值得引入 InvenTree 作为专业元件库，而不是在 Odoo 里重新造轮子。部署试用、评估 REST API 覆盖度，设计 Odoo ↔ InvenTree 的同步方案并明确 Source of Truth，小范围单向同步 POC。产出是一份技术选型报告，不要求生产可用。
Phase 7 · 追溯与 MES（长期规划，仅立项跟踪）
先确认业务方是否有真实的车间自动化/设备联网需求（SMT 贴片机/AOI/ICT 等）。有明确需求再谈自研 vs 对接开源 MES 的可行性。本阶段只产出"做/不做"的结论和依据，避免在没有真实需求时投入这类高成本能力。
悬而未决的问题
- Phase 2 的分销商 API 具体选哪家、免费额度是否够用，需要业务方确认预算和数据量级。
- Phase 4 的 OCA 模块是否有 19.0 兼容分支，要实测才能定移植工作量。
- Phase 6/7 是否推进到实施，取决于评估结论，暂不预排开发资源。
下一步
方案已按阶段拆分为具体的子任务，挂在本 issue 下，可以直接排期启动 Phase 1。