很多团队会问：采购单上已经能看到预算提示了，为什么预算报表里的 committed 数还和界面感觉不完全一样？
答案就在 budget_report.py。企业版不是直接把采购单列表拿来 group by，而是通过 _get_pol_query() 额外拼出一段 SQL，再在 _table_query 里 UNION ALL 到原有预算报表视图里。也就是说，采购预算报表是一个专门建模后的报表口径，不是 UI 视图的翻版。
这段 SQL 先算 qty_invoiced_table：只统计 aml.parent_state = 'posted' 的会计分录行，按发票与退款方向决定正负号，还会在 uom_aml 与 uom_pol 不同时做单位换算。新手常把“已开发票数量”理解成采购行上的一个现成字段，但企业版这里显然更相信过账后的会计事实。
真正的 committed 查询再把 purchase_order_line 与 JSONB_TO_RECORDSET(pol.analytic_json) 做展开，这一步非常关键。它意味着采购行可能对应多段分析分摊，报表不是一行采购行只进一条预算记录，而是按分析切片参与预算归集。再往后，系统按公司条件、预算期间和各个 analytic plan 列做 join，最后只保留 product_qty > qty_invoiced 的部分，表示仍然占用承诺的数量。
这就是为什么报表和采购单视图看起来会有“差半拍”：报表更重视已过账票据、UoM 换算、退款抵减和多维分析展开，而采购单上的即时提示更接近业务操作时的在线判断。两者都对，只是口径不同。
另一个容易误解的点是公司条件。SQL 里同时允许 po.company_id = bl.company_id 和 bl.company_id IS NULL，说明共享预算与公司专属预算都可能落进同一张报表。如果你在多公司环境里只按表面金额核对，很容易误判成“报表重复统计”。
排查采购预算报表时，建议顺序是：先看发票是否真的过账；再看计量单位是否一致；再看 analytic_json 是否拆成了多段；最后再看预算行本身是不是共享公司或重叠范围。很多报表争议，本质上都不是 SQL 错了，而是业务方拿了错误口径去对账。
所以企业版采购预算报表真正做的，是把采购承诺转成一套更接近会计与分析口径的 SQL 事实表，而不是直接把采购单界面搬到报表里。
DISCUSSION
评论区