审批流里“批准采购”最怕一句话说完，结果仓库、收货路线和供应商拆单全靠人脑补。
这篇文章主要参考了以下企业版源码与测试入口：
enterprise/approvals_purchase_stock/models/approval_product_line.pyenterprise/approvals_purchase_stock/models/approval_request.pyenterprise/approvals_purchase_stock/tests/test_approvals_purchase_stock.py
一、这个模块真正解决的不是表面动作，而是跨模块语义对齐
approvals_purchase_stock 把审批、采购、库存三条线绑在一起：审批商品行要先知道落哪个仓、走哪个收货类型，再按供应商构造采购单，最后把这些选择安全地回写到审批流里。
如果只看 UI，很容易把它理解成一个按钮、一张表或一个新视图。但从 approvals_purchase_stock 的模型、测试和桥接关系看，官方真正关心的是：前台动作发生以后，后端主链路能不能继续保持同一套业务语义。
二、核心机制链路
1. 审批商品行先决定仓储上下文
_default_warehouse_id() 与 _get_picking_type() 表明，审批行不是抽象需求，而是已经要落到哪个 warehouse、用哪种入库路线。
2. 采购单按供应商域构造
_get_purchase_orders_domain(vendor) 与 _get_purchase_order_values(vendor) 说明，系统并不会把不同 vendor 的需求随手塞一张单，而是按供应商拆分并继承正确上下文。
3. 审批请求要感知这些库存字段是否该显示
approval_request._compute_hide_location() 暗示并非所有审批类型都暴露 location 相关字段；显示边界本身就是流程治理的一部分。
三、最容易被误解的边界
- 以为审批通过就能无脑建 PO，忽略仓库与 picking type。
- 把多个供应商的审批商品混在一张采购单里。
- 审批单 UI 不区分是否需要库存位置信息，导致使用者乱填或漏填。
这些误解之所以常见，往往是因为大家只看见“入口动作”，却没有继续追到模型方法、状态切换、聚合口径和测试场景里去看 Odoo 究竟把什么当成事实、把什么当成辅助信息。
四、实施与排查时，建议按这个顺序看
- 先看 approval product line 默认 warehouse 是否正确。
- 再查不同 vendor 下 purchase order domain 是否拆分。
- 最后核对生成的 PO / picking type 是否与审批请求预期一致。
对企业版功能来说，排查顺序非常重要。很多看似是“结果不对”的问题，真正根因往往更早：字段上下文没带过去、桥接对象没建、状态机没推进、或者权限/公司边界一开始就错了。
五、结论
采购审批真正难的不是“批不批”，而是批准后的需求必须无缝落进仓储与采购执行语义里。
DISCUSSION
评论区