MPS 最难的地方，不是填表，而是填进去的数字什么时候触发制造、什么时候触发采购，以及为什么。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/mrp_mps/models/mrp_mps.pyenterprise/mrp_mps/wizard/mrp_mps_forecast_suggestion.pyenterprise/mrp_mps/tests/test_mrp_mps.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
mrp_mps 的难点不在表格，而在预测如何变成正确时点的生产或采购建议：组件的间接需求怎么算，提前期怎样推回补货日期，什么时候该建 MO，什么时候该推 RFQ。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 mrp_mps 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. schedule 先识别路线和供应商
_compute_route_and_supplier()、_compute_is_manufacture_route() 说明同一个 forecast 数量，在不同 route 下会走出完全不同的补货动作。
2. 间接需求必须单独计算
test_indirect_demand、test_indirect_demand_kit 表明主产品预测会向下游组件传导；如果只看直接销售需求，组件永远晚一步。
3. replenish timing 依赖 lead time
多组 lead_times 测试和 action_replenish(based_on_lead_time=False) 说明补货时点并不是点按钮的当天，而要按提前期回推。
三、最容易被误解的边界
- 把 MPS 当成“更大一点的补货表”。
- 只填成品预测，不关注组件间接需求。
- 忽略采购/制造 lead time，导致建议数量对了、时点却错了。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先查 schedule 的 route / supplier 判定。
- 再核对 indirect demand 是否把下游组件卷进来。
- 最后看 replenish 动作是否按 lead time 生成 RFQ 或 MO。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
主生产计划真正值钱的地方，不是“看未来”，而是把未来预测翻译成今天该执行的制造和采购动作。
DISCUSSION
评论区