比利時有一家做魚子醬的家族企業，叫 Imperial Heritage Caviar。客戶名單裡有米其林三星餐廳、豪華酒店，還有一位私人遊艇船東。公司不大，系統裡約 500 個活躍客戶。
它的訂單入口很真實：WhatsApp、郵件、簡訊、電話。主廚們往往在晚市結束後才想起第二天要補貨，訊息常常整夜進來。過去，把這些訂單敲進 Dynamics 365 Business Central，每天要花一到兩個小時。生意越大，這兩小時越像一根刺——它擠掉的不是行政時間，是跟客戶說話的時間。
2026 年 11 月 11 日，微軟把這個案例掛上了客戶故事欄目。結果不難猜：手工錄單壓到 30 分鐘以內，常規訂單準備只需幾秒，複雜訂單的返工「幾乎消失」。但真正值得看的不是這些數字，是他們怎麼劃邊界。
一、兩個智能體，三個技能，一個確認鍵
他們一開始想用 Business Central 預置的銷售訂單智慧代理。那個智慧代理主要處理郵件進來的訂單，一條線索走到黑，滿足不了多通路的需求。更麻煩的是，公司裡每個人偏好的 AI 工具不一樣——有人習慣 Teams 裡的 Copilot，有人習慣 Claude。
於是技術夥伴 Deltanexx 做了兩個：一個基於 Microsoft Copilot Studio，一個基於 Anthropic 的 Claude。兩個都透過 Business Central 的 MCP server 連接，能讀、能寫、即時執行。上層換了兩個「腦子」，下層共用同一套介面。
技能只有三個，而且都是業務動作，不是技術動作：建銷售訂單、建客戶檔案、出客戶跟進報表。看起來少，但每一個都對應一件每天必須發生的事。
| 技能 | 邊界怎麼劃 | 為什麼這麼劃 |
|---|---|---|
| 建銷售訂單 | 把自然語言翻成客戶與物料記錄，可以參照歷史發票複現已談定的價格和產品編碼；先呈現明細，人確認後才創建 | 訂單一旦落庫就會佔庫存、算交期，錯一張要連著改三處 |
| 建客戶檔案 | 新建之前，先查系統裡有沒有這個客戶 | 重複建檔不會報錯，但會讓對帳、返點、信用額度全部錯位 |
| 客戶跟進報表 | 生成週報與銷售概覽，不發外部 | 報表是給人做判斷的，不是給機器執行的 |
治理部分寫得比功能更細，這才是案例的價值所在。Copilot Studio 那側走的是 Business Central MCP 工具加微軟預註冊應用；Claude 那側在客戶自己的 Microsoft Entra ID 租用戶裡單獨註冊應用，由管理員同意委派式存取。MCP 的設定本身界定了智慧代理可以呼叫哪些 API 和操作，Azure Application Insights 記錄呼叫，供監控和支援。
翻譯成白話：不是給智能體一個超級帳號，而是給它一份寫清楚能開哪幾扇門的通行證，再加一本進出登記簿。
這個案例的最小結構，可以照抄：一個入口（自然語言，渠道隨意）+ 三個技能（建單、建客戶、出報表）+ 一個確認鍵（落庫前必須人看過）+ 一條審計日誌（誰調用了什麼）。四件東西湊齊，一個十幾個人的公司就能自己維護，不需要立一個「AI 平台項目」。
二、真正難的不是讀單據，是認得對
四天前，美國食品供應鏈公司 GrubMarket 發布了一個採購訂單智能體。它做的事和上面很像：把供應商發票、收貨單、甚至一段自然語言，轉成結構化的採購訂單，使用者可以核對後一鍵寫進 ERP。
產品說明裡有意思的不是識別能力——支援照片、PDF、表格、純文字，這已經是 2025 年的基本功。有意思的是它講匹配的那一段：產品匹配不只比名稱，而是用歷史訂單行為、按客戶配置的「企業詞典」，加上針對具體供應商的 AI 訓練，把供應商寫的品名映射到分銷商自己的商品目錄。
這句話點破了一件事。單據自動化的瓶頸早就不在「讀得懂」，而在「認得對」。
| 環節 | 看起來的難點 | 實際上的難點 |
|---|---|---|
| 讀單據 | OCR 準不準、格式多不多 | 已相對成熟，屬於工程問題，肯花錢就能解決 |
| 認商品 | 名字對不對得上 | 供應商料號不等於內部料號；一物多名；新品沒有歷史可參照 |
| 算數量 | 數字抄對沒 | 採購單位與庫存單位不同，箱、件、公斤換算錯一步，庫存和成本一起歪 |
| 定價格 | 發票上有金額 | 含稅與不含稅、運費與附加費、臨時議價，口徑不同對帳就打架 |
更麻煩的是，這四道關的錯誤不會互相抵消，而是各自放大。一張採購訂單寫錯物料，庫存多一批不存在的貨，成本按錯的單價攤進產成品，毛利分析跟著失真，應付帳款最後還要跟供應商吵一次。讀錯一個字，四個部門各返工一遍。
這也解釋了為什麼「企業詞典」這種聽起來一點不性感的東西開始被產品化。它不是知識庫，而是把公司內部的命名習慣固化成一份可維護的表：誰維護、多久更新一次、新舊料號怎麼並存。這是管理問題，不是模型問題。
三、把這套東西放回 Odoo，是四道具體的關
如果你在做 Odoo 的實施，上面那些話可以一步步落到具體的表和欄位上。Odoo 的好處是這些東西都在同一個庫裡，不用跨系統拼；壞處也是同一個——錯一次，整個庫一起錯。
| 關卡 | Odoo 裡對應什麼 | 常見的坑 |
|---|---|---|
| 客戶 | res.partner，按名稱、電子郵件、電話、稅號做重複提示 | 提示不等於攔截。同名不同主體、集團與門店混建、海外客戶缺稅號，都會留下重複檔案 |
| 物料 | product.product 的內部參考與條碼；product.supplierinfo 上的供應商料號與供應商品名 | 供應商料號只存在於對方系統；同一物料多個別稱；新品沒有歷史訂單可參照 |
| 單位 | uom.uom 與 uom.category 的換算因子，採購單位可與庫存單位不同 | 採購按箱、庫存按件、銷售按公斤，三個單位分屬不同類別，換算寫錯就是系統性偏差 |
| 價格 | product.supplierinfo 的供應商價格、客戶價目表、歷史發票行 | 含稅不含稅混用；運費沒進成本；臨時議價進了單價卻沒人改回價目表 |
四道關裡，最容易做、收益最大的是第二道。Odoo 的 supplierinfo 天生就是一張「供應商說法到我們說法」的對照表，只是很多專案上線時只填了價格和交期，沒填供應商料號與品名。等到要做單據自動化，才發現這張表是空的——於是智慧體只能靠模糊比對猜，猜錯的比例高到業務不敢用。
一個具體的建議：把 supplierinfo 當作資料資產來治理，而不是當作價格表來填。每個主要供應商的前 50 個常用物料，供應商料號、供應商品名、最小包裝、交期四項補齊，單據自動化的準確率會有肉眼可見的變化。這項工作不需要 AI，只需要一個人和兩週時間。
確認鍵該放在哪一層
微軟那個案例裡，確認發生在「訂單建立之前」。放到 Odoo 裡，對應的是明確的一條線：智慧體只寫草稿，確認動作由人觸發。
- 銷售側：智能體建 sale.order 的草稿報價單，人核對後點確認；不要讓智能體直接走到確認狀態。
- 採購側：智能體建 purchase.order 的詢價單，人核對後轉採購訂單。
- 會計側：智能體只寫 account.move 草稿，過帳由人做。
理由很樸素：草稿可以改、可以刪、可以不算數；一旦確認，庫存預佔、交期承諾、財務憑證就會連鎖發生。把不可逆的動作留給人，是這類項目最便宜的風險控制。
還有一件常被忽略的事：確認頁面要給人「看得懂的差異」。只顯示「智能體建議：客戶 ABC、物料 XYZ、數量 200」，人沒法判斷。要顯示的是與歷史相比變了什麼——客戶換了、物料換了、單價比上次高了 8%、交期比標準承諾短了三天。差異才是判斷依據，欄位羅列不是。
四、給實施者的三條
第一，把別名表當成交付物。專案驗收清單裡加三張表：供應商料號對照、客戶簡稱對照、單位換算對照。每張表要有維護人、更新頻率、失效標記。沒有這三張表，智慧體再聰明也只能猜；有了這三張表，哪怕用最簡單的規則匹配也能跑起來。
第二，先只做「讀」和「起草」，別急著做「改」。讀資料、生成草稿、給人看差異，這三件事錯了代價很小。改價、改交期、刪行、合併單據，這四件事錯了要追溯半天。很多項目的翻車點不是能力不夠，是第一天就把寫權限開到了最大。
第三，用歷史單據做回放測試，而不是用演示資料。抽上一個月的 100 張真實單據，故意覆蓋四類情況：新客戶、新物料、臨時改價、退貨。測兩個指標：一次通過率，以及平均要人工改幾個欄位。這兩個數比任何演示都誠實。
最容易被跳過的一步：回放測試裡要包含「同一張單據用不同入口再跑一遍」。郵件進來的和聊天裡說的，結果是否一致？不一致的地方，是渠道差異還是系統在猜？這個問題在演示階段問不出來，只有回放能問出來。
回到那家比利時公司。他們的方案開發只用了幾週，採購和供應商的 API 已經配進 MCP，下一步是做採購技能。這個節奏說明一件事：當介面、權限、技能邊界都收在一處時，加一個新技能的邊際成本很低。真正花時間的，是前面把邊界想清楚的那幾週。
國內很多企業卡在相反的地方：模型接了三家，接口寫了十幾個，技能做了二十個，但供應商料號還沒人維護，客戶檔案裡躺著三千個重複聯絡人。這時候上智能體，等於讓一個新人拿著錯電話本去拜訪客戶，跑得越快，錯得越多。
一句話總結：AI 在單據上的競爭力，最後不落在模型上，落在你們公司有多少張沒人維護的對照表上。模型三個月換一代，對照表不會自己長出來。
資料來源：Microsoft Customer Stories《Imperial Heritage Caviar doubles time saved on administrative tasks by adding AI to its Dynamics 365 Business Central platform》（2026-11-11，含公司所有者 Elisabeth Colman、Deltanexx 管理合夥人 Dhia Athmini 表述，以及 MCP 設定、Entra ID 應用程式註冊、Application Insights 記錄等治理細節）；PR Newswire《GrubMarket Launches AI Agent That Transforms Purchase Order Processing for Food Distributors》（2026-11-10，含企業詞典、供應商專屬訓練、多管道提交與 ERP 整合範圍）。Odoo 側欄位與機制說明基於 Odoo 19/20 標準功能，具體行為隨版本與在地化模組而異，實施前需在測試庫驗證。
資料口徑說明：比利時案例的「每天 1 至 2 小時壓到 30 分鐘以內」「常規準備幾秒」「返工幾乎消失」均為客戶方估算，未披露統計區間與樣本量；GrubMarket 未披露匹配準確率、客戶數量與定價。文中 Odoo 建議為實施經驗判斷，不構成對具體專案結果的承諾。
眾諦信息（Zodioo）· 企業數位化觀察 · 2026-11-12
