Odoo 企业版采购审批撤销后为什么有的 RFQ 会自动回退，有的只能人工处理：取消请求、删行与活动提醒边界

采购审批最危险的时刻，不是“生成 RFQ”而是“需求撤回”。因为这一步很容易把审批世界和采购世界撕开。

这篇文章主要参考：

• enterprise/approvals_purchase/models/approval_request.py

一、取消审批时，企业版先问的不是“要不要删”，而是“采购事实有没有成立”

action_cancel() 在父类取消后，会继续执行 _cancel_approval_request()，把和该审批请求相关的采购行逐单据拆开处理。关键分界线只有一个：purchase_order.state == 'draft' 吗？如果还是 draft，系统认为采购事实尚未正式承诺，可以自动回滚；如果已离开 draft，系统认为采购世界已经继续向前，审批不能越权把它硬撤回来。

二、draft RFQ 会怎么回退

源码里，系统会找到当前审批请求对应到该 RFQ 的所有产品行，然后：数量完全对应的 PO line 进入待删集合；仍承载其他审批数量的，只减掉当前审批对应的数量；如果整张 RFQ 所有行都因此被删掉，系统先把采购单置为 cancel，再 unlink() 整单；最后把 purchase_order_line_id 清空，解除行级回链。

三、非 draft RFQ 为什么只能人工处理

如果 RFQ 已经不在草稿状态，系统会把这些数据放进 require_manual_action，然后通过 _log_cancellation_exception_to_po_chatter() 在采购单上创建 warning activity。审批取消不等于采购取消；一旦采购单进入已确认、已发送、已收货等后续状态，回退动作必须由业务人员判断。

四、结论

企业版的思路很克制：只在仍可安全回退时自动处理，超出安全边界就强制人工接手。采购审批取消的本质，不是撤回一个按钮动作，而是重新协调两个已经分叉的业务世界。