上周跟一位财务总监聊，他说了件挺典型的事。月结第二天，老板问「上个月营收怎么掉了六个点」，他让新上的 AI 助手直接查。几秒钟，系统给了一个数，还附了句解释：主要来自华东区两个大客户订单延迟。听着挺像那么回事。
他多问了一句：这个「营收」是按开票算的，还是按收入确认算的？助手答不上来。他自己回去翻，发现是已开票未发货的部分被算进去了——这批货压在仓库，客户还没签收，按合同要到下个月才确认收入。
这就是今天要讲的事。11 月 13 日，Databricks 上线了 Genie 的 ChatGPT 插件，让员工可以直接用自然语言问 SAP ERP 里的数据。技术链路做得挺讲究，但真正决定这套东西能不能用的，不在链路，在「营收」这两个字到底指什么。
一、一笔生意，在系统里有四个日子
Databricks 那篇说明里有一句话，我认为是整篇最值钱的：一张销售订单、一次发货、一张发票、一笔收入过账，可以是同一笔生意的不同阶段，也可能落在不同的会计期间。所以当有人问「营收为什么掉了」，答案取决于你用的是确认收入、开票销售，还是已确认订单，还取决于账套、币种、退货和内部交易怎么处理。
换成 Odoo 的说法，一笔生意在库里至少留下四个日期：
| 业务事件 | 落在哪个对象 | 日期字段 |
|---|---|---|
| 客户下单 | sale.order（销售订单） | date_order 订单日期 |
| 仓库发货 | stock.picking（调拨单） | date_done 完成日期 |
| 开票 | account.move（客户发票） | invoice_date 开票日期 |
| 记账与收入确认 | account.move 的记账日期，或收入确认分录 | date 记账日期 |
你说「上个月的营收」，取哪个字段，答案能差出一个月。四种取法都说得通，但只有一个是你和老板都认的那个。剩下三个不是错的，是没被说清楚。
采购侧的坑更细。一张采购订单可以有多条计划行，每行有自己的交期和数量（purchase.order.line 上的 date_planned）。库存数字里还含质检中的、被别的订单预留的——Odoo 里 stock.quant 的 reserved_quantity 一扣，可用的 free_qty 跟 qty_available 就不是一个数。一张部分收货的单子，表头写着已交货，缺料还在那儿。
最容易糊过去的一句汇报：「报表跑出来了，数据没问题。」跑出来只证明 SQL 语法对，不证明它回答的是你问的那个问题。这两件事在演示里长得一模一样。
二、定义不写下来，模型只能猜
Genie 的做法值得看一下。它靠两样东西理解问题：Genie Ontology，和 SAP 侧提供的技术元数据。
Ontology 里有一部分是 Unity Catalog 里显式建模的定义——比如一个被批准的「营收」指标，会规定用哪个账套、哪套会计日历、按什么规则折算币种。另一部分是从仪表盘和保存的查询里学到的上下文。SAP Business Data Cloud 还能提供字段描述和主外键关系，这些关系帮它把表连对。
但有一句话得划出来：哪些交易算进这个指标，是业务团队定义的。不是模型推断的，也不是实施顾问拍脑袋定的。
这句话落到项目上，就是一张卡。我在不少项目里推过这个东西，一开始大家都嫌土，后来每次都靠它吵架。
| 栏目 | 要写什么 | 常见错误 |
|---|---|---|
| 指标名 | 口语怎么说，报表上怎么写 | 一个名字对应三张报表 |
| 取数对象 | 主表 + 关联表，写清层级 | 用订单表算营收 |
| 过滤条件 | 状态、公司、客户类型、退货处理 | 把内部交易算进去 |
| 日期字段 | 到底是哪一个日期 | 四个日期混着用 |
| 金额口径 | 含税 / 不含税、币种折算、折扣 | 本位币和原币不分 |
| 批准人 | 谁签字，改动谁复核 | 写完没人认 |
六个栏目，一张卡，十个高频指标就是十张。听起来像文牍主义，但它是唯一能在三个部门吵架时拿出证据的东西。更实际的一点：这张卡也是 AI 问数能不能上生产的前置条件。你让模型去猜「在制」的定义，它就会给出一个语法完美、口径可疑的答案，然后被转进管理层的周报。
三、能问什么，和能改什么，是两张授权表
还有一层容易被忽略：Databricks 这套东西是只读的。改采购订单、释放冻结的发票、做过账调整，仍然要走另一套有授权的 ERP 接口或工作流。 报告里写得很直白——插件给了 ChatGPT 一个做 ERP 分析的界面，写操作它不管。
这个切分值得抄进自己的架构里。读和写不是一个权限等级，是两个世界。
- 读的边界是「能看到哪些行」。Genie 是按登录用户在 Unity Catalog 里执行权限的，不是插件自己带权限。Odoo 里对应的是 ir.rule 记录规则加公司上下文，谁能看到哪家公司的单据，靠这个。
- 写的边界是「能触发哪些动作」。不是给模型一个数据库连接，而是把允许的动作做成有限的几个工具或 server action，模型只能请求菜单上有的菜。
- 还有一层是「结果会出现在哪里」。零拷贝共享只说明数据怎么访问，答案照样会显示在对话框里。采购单号、数量、确认交期是采购员需要的；供应商银行账号在这类分析里没有任何理由出现。这是一份字段级可见性清单要解决的问题。
另外提醒一句时间感。零拷贝不等于答案新鲜。答案的时间取决于 ERP 的变更什么时候进入那个数据产品，以及查询里其他数据集上次刷新是什么时候。采购员一边看未清采购订单、一边看仓库库存，两个数据集的刷新节奏可能不同。一个大额收货刚好在某个数据集刷新之后到，结论就变了。所以结果里必须显示数据时间戳——这不是锦上添花，是让人知道自己在看哪一刻的账。
多公司、多币种是另一个高频翻车点，而且比单公司更难自证。同一个「集团营收」，在三处就可能走岔：
- 范围。是当前公司（env.company）还是已激活的公司集合（company_ids）？Odoo 里这两个不是一回事，界面上切一下公司，数字就变了，但报表标题往往不跟着变。
- 币种。用单据原币、公司本位币，还是集团报告币种？如果用折算，按哪天的汇率——单据日期、记账日期，还是月末汇率？这三天的汇率可能都不一样。
- 内部交易。集团合并要不要抵销关联公司之间的买卖？不抵销，营收会虚高；抵销了，又得解释为什么单家公司的报表对不上。
这三条不写清，跨公司问数基本没法用。而它们恰好是最没人愿意写进文档的部分，因为写下来就意味着以后不能随口改。
四、拿旧报表当考卷，别拿新报表当成绩
Databricks 给了一套很实在的试点方法，我觉得可以直接搬。找一张现成的采购订单异常报表当基线，让 Genie 用同一个截止时间、同一个工厂范围跑一遍，然后逐行比。
关键在测试集要包含什么：部分收货的单子、被取消的计划行、修订过的供应商确认、不同工厂权限的用户。这几类恰好是最容易答错的。检查三件事——答案有没有用被批准的定义、有没有链回具体记录、有没有把数据时间戳显示出来。
衡量指标也别搞复杂：漏报的缺料、误报的告警、查一件事花的时间。三个数就够了。
这套方法有个好处：它不比较谁答得快，只比较谁答得对。而「对」是有参照物的——上个月那张报表就是参照物。
顺带说一句规模的事。SAF-Holland 用 SAP Business Data Cloud 加 SAP Databricks 分析了 1 亿多条 SAP 记录，调度协议、交货、客户、物料都在里面，S/4HANA 仍然是它的记录系统。他们的全球数字智能高级经理 David Gund 估计，类似的分析工作流放到别处至少要五倍时间。这个案例的启发不是「上云快五倍」，而是：数据层可以另建，记录系统不能动。谁记账、谁出数，这两件事分开之后，很多争论就清楚了。
五、给正在做这件事的人三句话
先给十个高频指标写口径卡，谁签字谁负责。不用等 AI 项目立项，这件事本身就能减少一半的报表争议。
把能问什么和能改什么分开授权。只读连接先跑三个月，看清楚大家会问什么、会问出什么，再谈让不让它动数据。
用旧报表做基线逐行比。不要用一套新做的看板去证明另一套新做的看板对。参照物越老，越可信。
回到那位财务总监。他后来做的事很简单：把「营收」拆成三个词——已开票、已发货未开票、已确认收入，每个词配一张卡，写清取数对象和批准人。再让助手回答时必须先说明用的是哪一个。
系统没换，模型没换，多了一张纸。但从那以后，没人再在月结会上为「你说的营收是哪个营收」吵半小时。
问数这件事，最贵的从来不是算力。
参考来源：ERP News《How Databricks Genie Brings SAP ERP Data Into ChatGPT》（2026-11-13）；Databricks 2026-11-11 版本说明与 Genie Ontology 发布信息。
众谛信息 · 企业管理数字化观察 · 文中 Odoo 字段名以 Odoo 19/20 为准。
