上週跟一位財務總監聊，他說了一件挺典型的事。月結第二天，老闆問「上個月營收怎麼掉了六個點」，他讓新上的 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 為準。
