先说结论
在 Odoo 里，自动采购并不总是一条需求就对应一张采购单。
更常见的真实逻辑是：
- 系统先看这些采购需求能不能被视为同类
- 如果关键上下文一致，就可能归并进同一张 PO
- 如果上下文不同，就拆开生成多张
所以“为什么合单 / 为什么没合”，本质上是在问：
系统认不认为这些采购需求属于同一组可合并采购上下文。
为什么这个问题总容易被误会成 bug
因为业务用户看到的通常只是结果：
- 明明是同一天要买的，怎么拆成两张？
- 明明来自不同来源，怎么又合到一张？
如果不理解系统的归并维度，就会觉得：
- 它好像随机在合单
但更常见的现实是：
- 系统并不是在随机，而是在根据它认定的重要上下文来分组。
采购合单真正关心的是什么
它不是在问“这些东西是不是都要买”，而是在问：
- 这些需求是否足够相似，值得放进同一张采购执行对象里
所以合单关注的是：
- 供应商
- 公司
- 采购上下文
- 计划时间或相关规则
也就是说，它本质上是“采购执行归并”问题，而不是“需求存在与否”问题。
为什么来源不同也可能合到一起
因为系统有时更看重的是执行上下文，而不是前台来源长得一不一样。
如果几条需求最终在采购层面看起来是：
- 同供应商
- 同公司
- 同类采购条件
那它们就可能被视为“适合一起下单”。
所以“来源不同”不必然意味着“不该合单”。
为什么同一批需求有时又会被拆开
因为只要关键上下文不一致，系统就可能认为不适合共用同一张 PO。
比如：
- 供应商不同
- 公司不同
- 计划节奏不同
- 某些采购规则差异明显
这时拆开反而更符合执行语义。
所以“没合单”很多时候不是缺陷，而是系统在保护采购边界。
实战里最容易踩的 5 个坑
1. 只看来源单据，不看采购执行上下文
会误判合单逻辑。
2. 以为同一天采购就理应合单
系统看的维度更细。
3. 看到不同来源合到一起，就觉得一定错了
未必。
4. 不先弄清系统到底按哪些维度归并
问题会一直像随机。
5. 定制采购链时忽略归并语义
后面 PO 行为会变得难解释。
一句话记忆法
把它记成一句话：
采购合单不是按“来源像不像”决定，而是按“这些需求在采购执行层面能不能被视为同一组上下文”来决定。
理解这一句，PO 合单逻辑就不会再像黑箱。
DISCUSSION
评论区