Odoo 企业版 Account Reports 为什么不是“一个模型配几张报表”：custom handler、菜单挂接与发送管线讲透

很多人第一次接触 Account Reports，会把它当成“若干财务报表模型 + 几个导出按钮”。但企业版源码真正提供的是一套报表框架：报表定义、handler 扩展、菜单绑定、异步发送与导出能力是同一个系统里的不同层。

主要参考：

• enterprise/account_reports/models/account_report.py
• enterprise/account_reports/models/account_report_send.py
• enterprise/account_reports/models/ir_actions.py

一、报表对象不是页面，而是框架入口

account.report 的职责并不是只保存报表名称和行定义。它更像一个“报表运行器入口”，负责接住 options、过滤器、列定义、展开行为和导出逻辑。

真正重要的是：前端看到的每次切换期间、币种、公司、比较列，本质上都要先被归入一份 options，再由后端拿这份 options 驱动整个报表生命周期。

二、custom handler 解决的是“同框架，不同行为”

企业版很多报表不是通过复制一整个报表引擎来实现差异，而是通过 custom handler 模型来覆写某些步骤。这样同一套 Account Reports 底盘上，既能跑总账，也能跑税报、管理分析、国家本地化报表。

框架上的好处很明显：

• 共用同一套 options / column / export 基础设施
• 差异行为集中在 handler
• 菜单与 action 仍能指回同类报表对象

三、菜单挂接不是 UI 小事，而是报表分发入口

报表为什么能以“菜单项 → 某报表视图”稳定打开？这背后不只是 action 记录，而是 ir.actions 扩展与 account.report 之间的绑定约定。它确保菜单打开时，系统知道该把哪一份 report 以及哪种默认上下文交给前端。

这也是为什么做本地化财务报表时，菜单配置经常和 report handler 一样重要——菜单没挂对，报表根本不会以预期入口被使用。

四、发送流程说明 Account Reports 把“生成”和“交付”都纳进框架

很多系统把导出做完就结束了，剩下发邮件、入队列、异步批量处理交给外部脚本。Account Reports 企业版不是这样。它把 send 也纳进模型层，让报表既能被算出来，也能沿官方方式被交付出去。

这意味着报表框架不仅关心“怎么算”，也关心“怎么发、何时发、由谁发、失败如何重试”。对企业使用来说，这才是真正可落地的报表系统。

五、最容易误解的地方：不要把 options 当临时查询参数

在 Account Reports 里，options 不是前端随手拼的一袋参数。它更像报表运行时上下文：

• 哪些过滤器开启
• 哪些列需要显示
• 比较期如何展开
• 多公司/多币种如何落地
• 导出时该取什么结果

因此做定制时最值得复用的，不是某一行计算代码，而是 options 初始化与流转方式。

六、结论

Account Reports 企业版的强大，不在于“预置报表多”，而在于它提供了一套可挂菜单、可切 options、可换 handler、可导出、可发送的统一报表底盘。

理解了这点，才知道为什么它更接近一个报表框架，而不是几张报表页面。