很多团队一看到“从审批生成采购询价”，就默认是一条审批请求对应一张 RFQ。Odoo 企业版并不是这么做的。
这篇文章主要参考：
enterprise/approvals_purchase/models/approval_request.pyenterprise/approvals_purchase/models/approval_product_line.py
一、系统真正优化的是“采购聚合效率”，不是单据一对一
action_create_purchase_orders() 里最值得看的是 _create_purchase_orders()。它先逐行处理产品行，再决定这行该落到哪个 vendor、当前公司下是否已有可复用的 draft RFQ，以及找到 RFQ 后是复用旧行还是新建一条 PO line。审批请求只是采购需求来源，不是采购单据边界。
二、RFQ 复用规则到底看什么
_get_purchase_orders_domain(vendor) 的默认条件有四个：
company_id相同；partner_id相同；state = draft；currency_id = seller_id.currency_id。
所以同一家供应商却没并到同一张 RFQ，很多时候不是 bug，而是币种或公司边界不同。
三、找到 RFQ 后，也不是一定新建行
源码会继续查是否已有兼容的 purchase.order.line：order_id 属于候选 RFQ、product_id 相同、product_uom_id 与 seller 的采购单位兼容。命中后不会重新造一行，而是直接增加 product_qty。这意味着审批单和 RFQ 行不是一一映射，而是“多审批需求并入同一采购行”。
四、origin 不是装饰字段，而是追溯索引
如果采购单已存在，系统会把当前审批请求名追加到 purchase_order.origin。而且不是简单覆盖，而是先拆分已有 origin，缺什么补什么，避免重复拼接。多个审批汇总到同一张 RFQ 后，后续追溯就不能只靠采购单号，而要回到 origin 与行级链接一起看。
五、结论
企业版采购审批生成 RFQ 的核心思路，不是把审批“打印成采购单”，而是把需求按采购语义进行聚合。谁能合并、怎么合并、如何保留来源，源码都已经替你定义好了边界。
DISCUSSION
评论区