Odoo 银行对账模型为什么不只是“自动记账规则”：account.reconcile.model 到底在匹配什么
很多人把 Odoo 对账模型理解成简单自动分录模板，但 account.reconcile.model 真正处理的是匹配条件、建议逻辑和自动对账边界。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
Odoo 企业版工资单入账为什么不是“验证后生成一张分录”这么简单：按月合批、NET 规则、多银行卡拆付与支付边界讲透
很多人以为 Odoo 企业版 payroll 接会计，只是在工资单验证后顺手生成一张 journal entry。源码真正做的是一套按工资结构 journal 与月份分组、按 salary rule 决定合并/拆分、按 NET 规则处理净薪口径、按员工银行卡分摊付款，并且只有在分录已过账、NET 贷方科目可核销、银行账户可信时才允许进入 payment register。
Odoo 企业版在线批量付款为什么不是“点发送=银行已处理”：SEPA 批次、KYC、Webhook 与状态机链路讲透
很多人看到 Odoo 企业版把 SEPA 批量付款接到在线银行链路后，会以为 validate 一次就等于银行已执行。可 `account_online_payment` 真正做的是把“可否在线支付”“是否完成 KYC”“是否已发起签署”“银行是否回传状态”拆成多层状态：link 激活、batch initiation、sign、webhook、cron 查询、draft 锁定，各自回答不同问题。
Odoo 企业版 Account Follow-up 为什么不是“逾期就催”而已：next action date、no followup 与负责人选派边界讲透
很多人把 Odoo 企业版催款理解成“发封提醒邮件”。真正看 account_followup 源码会发现，官方做的是一套客户级催收状态机：先按逾期与 level 算出 followup_line，再结合 next_action_date、no_followup、责任人分配和 activity 创建，决定今天到底该不该催、催到哪一级、由谁跟。
Odoo 企业版 Account Reports 为什么不是“点一下就导 Excel”而已：options 引擎、journal groups 与导出管线边界讲透
很多人把 Odoo 企业版财务报表理解成“前端选条件、后台跑 SQL、最后导 Excel”。真正看 `account_reports` 源码会发现，官方做的是一套更重的报表引擎：先把 date/comparison/journals 等状态收敛成 options，再由 report/handler 组合产线条与导出，journal groups、return periods、多公司、异步 send & print 和流式文件下载都围绕这套 options 语义展开。
Odoo 企业版批量付款为什么会出现“总额没变、未结清变少、状态还在 sent”：`account_batch_payment` 金额与状态链路讲透
很多人第一次用 Odoo 企业版批量付款，会困惑同一批 payment 明明总额没变，batch 的 residual 却会下降，甚至状态会从 draft 变 sent、再变 reconciled。源码里这不是显示问题，而是 `amount`、`amount_residual(_currency)` 与 `state` 分别回答三件不同的事：批次规模、剩余未核销金额，以及是否已发送并完成匹配。
Odoo 企业版银行对账单 OCR 为什么不是“上传即导入”：post-commit 发送、webhook 回调与覆盖保护讲透
很多人把企业版银行对账单 OCR 理解成“上传 PDF 后系统直接生成流水”。但从 `account_bank_statement_extract` 与 `iap_extract` 源码看，官方真正设计的是一条异步链：先建 statement、事务提交后再扣 OCR credits、由 webhook 回调触发结果拉取，并用 extractable state 防止覆盖已经人工处理的流水。