Odoo 企业版批量付款为什么在导出前就会拦住一批 payment：SEPA 映射、付款方法与导出保护讲透

account_batch_payment 的重点不在文件导出，而在导出前先把付款状态、收款账户规则和 SEPA 地址完整性校验干净。

主要参考：

- `enterprise/account_batch_payment/models/account_batch_payment.py`

• enterprise/account_batch_payment/tests/test_batch_payment.py

  ---

  一、这不是单模块按钮，而是一条跨模块链路

  很多人把这个功能理解成某个界面上的一个按钮、一个 smart button，或者一次自动创建。但从源码看，真正重要的是：上游对象先保留业务上下文，中间层做状态/域/权限判断，下游对象再接住这个上下文继续工作。只看最后一个界面动作，很容易把问题看窄。

  二、核心跨链路是怎么跑通的

  1. 批量付款校验先看批次里是否有 payment，再根据付款方法决定是否需要生成导出文件。
  2. _check_and_post_draft_payments() 会先尝试把草稿付款过账，把单个付款的 UserError 汇总成批次级错误向导。
  3. SEPA 转账场景还会检查 partner 地址是否具备 city 与 country，以及收款账户是否允许 outbound payment。

  这就是为什么我把它归类为“跨模块链路”题：这里至少同时牵涉了业务对象、会计/项目/销售对象，以及状态或权限判断，而不是单个模型内部的小机制。

  三、最容易踩错的边界

  • 已经被银行流水匹配的付款不再允许继续作为待发送 payment 混入批次。
  • 已发送付款会被单独拦出来，避免重复下发银行文件。
  • 当错误只有一条时系统直接给 RedirectWarning，多条时才打开汇总 wizard，减少会计来回点表单。

  这些边界决定了数据是否还能回到正确的模块继续流动。如果边界被自定义绕开，后面最常见的结果就是：报表看起来还能出， drill-down 却已经解释不通。

  四、落地时最值得先验的三件事

  1. 不要把“导出失败”理解成银行接口问题，很多失败其实发生在本地校验阶段。
  2. 批量付款前先清理 partner 银行账户与地址资料，能显著减少会计人工回退。
  3. 如果你要排查为什么按钮不让导出，先看 payment state，再看 payment method。

  五、结论

  真正的防呆发生在导出之前：状态、地址、收款账户和已发送标记都要先过关。 这也是企业版功能最容易被低估的地方：看上去只是一个入口，实质上是在多个子系统之间持续传递状态、上下文、数据或权限。