Odoo 企业版供应商账单 OCR 为什么 partner、税和银行账户不会一次性全自动定死：VAT、IBAN 与历史单据回填讲透

OCR 最容易被误解成“识别完直接自动入账”，但 account_invoice_extract 更像一个跨模块回填器：它要在 partner、税、银行账户与账单字段之间谨慎找落点。

主要参考：

- `enterprise/account_invoice_extract/models/account_invoice.py`

• enterprise/account_invoice_extract/tests/test_account_invoice_extract.py

  ---

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

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

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

  1. OCR 结果进入账单后，系统先按 VAT、历史提取版式、IBAN、供应商名称依次找 partner，而不是直接创建一个新供应商。
  2. 如果 OCR 给出 IBAN 和 SWIFT，系统会根据公司、伙伴和验证结果决定是复用现有 bank account，还是新建 partner bank。
  3. 税额回填也不是“识别出 13% 就结束”，它会先参考该供应商历史单据、journal 默认税，再回落到税表搜索。

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

  三、最容易踩错的边界

  • 只有在合适的采购单据上下文里，IBAN/银行账户才会真正写回 partner bank。
  • 如果已有人工录入内容，系统不会为了 OCR 候选值把整张账单重写。
  • 当 OCR 信息不够确定时，系统宁可停在 draft 供会计确认，也不会为了“全自动”硬猜。

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

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

  1. 把 OCR 定位成“回填候选层”，不要把会计审核职责交给模型。
  2. 供应商历史单据越规范，税与 partner 命中率越高。
  3. 排查账单 OCR 错配时，先看 partner 识别路径，再看税识别路径，最后才看采购单扩展。

  五、结论

  OCR 真正负责的是跨对象回填，不是替会计跳过 partner、税和银行账户判断。 这也是企业版功能最容易被低估的地方：看上去只是一个入口，实质上是在多个子系统之间持续传递状态、上下文、数据或权限。