制造里的改版最怕“图纸改了，但现场到底按哪一版干”没人说得清。PLM 的价值，就是把这件事从口头约定变成受控状态机。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/mrp_plm/models/mrp_bom.pyenterprise/mrp_plm/models/mrp_eco.pyenterprise/mrp_plm/tests/test_mrp_plm.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
mrp_plm 真正解决的是工程变更在制造现场如何受控生效：旧 BOM 上又发生了变化怎么办，ECO 之间如何 rebase，审批阶段怎么卡住，最终何时 apply 成新的版本。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 mrp_plm 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. BOM 变更先进入 ECO，而不是直接改现行版
mrp_production.action_create_eco()、mrp_bom.apply_new_version() 与 mrp_eco 模型说明工程变更先被封装成 ECO，再决定何时入主线。
2. rebase 解决并行变更冲突
tests 里 test_rebase_with_old_bom_change / previous_eco_change 说明，多个 ECO 并行时不能只看谁先保存，而要把后来的改动重放到新的基线上。
3. approval stage 决定谁能放行版本
MrpEcoApproval / Stage 的计算字段和 awaiting_my_validation 搜索说明审批并不是备注，而是版本推进的闸门。
三、最容易被误解的边界
- 把 PLM 当成 BOM 备注历史，直接改现行 BOM。
- 多个 ECO 并行时不做 rebase，最后改动互相覆盖。
- 审批阶段只是“走流程”，却不真正限制 apply new version。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先查变更是否以 ECO 形式创建。
- 再核对 rebase 后 BOM line / operation 是否按预期重放。
- 最后检查审批阶段与 awaiting_my_validation 是否卡住了不该放行的版本。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
PLM 真正守住的，是工程变更从提出、并行、审批到投产的整条版本控制链，而不只是“BOM 多了个 revision 字段”。
DISCUSSION
评论区