Odoo 银行对账模型为什么不只是“自动记账规则”：account.reconcile.model 到底在匹配什么
很多人把 Odoo 对账模型理解成简单自动分录模板，但 account.reconcile.model 真正处理的是匹配条件、建议逻辑和自动对账边界。
TOPIC PICKS
这个专题的推荐入口
这个专题里读者更常先点开的文章
优先看新补的内容
可以顺着继续读的相邻方向
采购单审批后，收货单、已收数量与发票状态是怎么串起来的
从 purchase.order.button_approve、_create_or_update_picking 到 _prepare_qty_received 和 receipt_status，讲清采购、收货、退货与发票之间的连接。
Odoo 销售确认后为什么会分成“补货链”和“开票链”
销售单确认只做一件事：把订单推进到可履约状态。真正的履约分成补货/出库和开票两条链，分别由 sale_stock 和开票逻辑接管。
Odoo 销售单为什么会卡在“可开票 / 已开票 / Upselling”之间：`invoice_status` 的真实计算逻辑
销售里最常见的误解之一，就是把 `invoice_status` 当成一个简单状态字段。实际上，从 Odoo 19 的 `sale_order_line.py` 和 `sale_order.py` 看，它是由 `qty_to_invoice`、产品开票策略、已交付数量、首付款逻辑，以及整单层的聚合规则共同推出来的结果。本文把这条链路讲清楚。
Odoo 企业版批量付款为什么不是“导完银行回单就彻底结束”：Bank Rec 回写、付款重置与批次状态回滚讲透
很多人以为 Odoo 企业版批量付款只是在生成批次时做一次聚合，等银行流水对上就结束了。但 `account_accountant_batch_payment` 真正补上的，是批次与 Bank Reconciliation widget 之间的双向回写：选中 batch 时怎样往 statement line 塞 move line、无分录付款何时补验证、删除已核销行后为什么 payment 会退回 in_process，而 batch 仍只是“信封”而不是主账实体。
Odoo 安全序列为什么不是“过账后编号固定”就结束：integrity hash、chain gap 与 restricted move 审计链讲透
很多人以为 Odoo 的会计不可篡改只等于“posted 后别改编号”，但 `/home/ubuntu/odoo-temp/addons/account/models/account_move.py` 里的 `_get_integrity_hash_fields()`、`_get_chains_to_hash()` 和 `_hash_moves()` 表明，真正的重点是把同一序列链上的 move 串成可校验的 hash chain，并在 gap、未对账与 restricted 边界上做强约束。
Odoo 银行日记账 Dashboard 为什么不是“账户余额看板”：to check、direct payments、sample data 与多口径数字讲透
很多人把 Odoo 银行日记账看板上的数字当成“银行余额”，但 `/home/ubuntu/odoo-temp/addons/account/models/account_journal_dashboard.py` 明确说明，这里其实把 statement、direct payments、outstanding、misc operations、to check 和 sample data 混成一个运营型 dashboard，口径本来就不止一种。