資料中心：預先建好的資料底座
AI GO 最大的價值不在於它的介面，而在於它已經幫您建好了什麼。這一章盤點平台預建的資料模型——有哪些表、表與表之間怎麼關聯、以及哪些業務引擎已經接在上面。
這些是您的 Custom App 與 API 一開始就能用的東西。
為什麼這件事重要
自己從零開始建一套企業資料模型，最花時間的不是建表，而是把表接起來：訂單要連到客戶、連到產品、連到出貨單、連到發票、連到收款、連到會計傳票。任何一段沒接好，帳就對不起來。
AI GO 把這一整套關聯與連動預先建好了。您的應用程式要做的，是決定要用哪一段，而不是重建它。
八大模組
CRM 客戶關係
| 表 | 用途 |
|---|---|
customers | 客戶主檔（含客戶等級、業務負責人、付款條件、信用額度） |
customer_levels | 客戶等級與基礎折扣率 |
customer_tags / customer_tag_rel | 客戶標籤與綁定關係 |
customer_tag_prices | 標籤專屬協議價 |
| 商機、銷售團隊、活動排程 | 銷售管線管理 |
| 銷售階段、遺失原因、定期營收 | 管線設定 |
| 行銷活動 / 來源 / 媒介 | UTM 歸因 |
銷售管理
銷售訂單、報價範本、產品列表、產品分類。訂單明細關聯到產品，產品關聯到分類，分類決定預設的收入科目與稅率。
採購管理
採購訂單、採購請求、供應商主檔、供應商價格。訂單同時追蹤「已收貨數量」與「已開帳數量」，讓進項帳單只針對差額產生。
庫存 / 倉儲
| 分區 | 表 |
|---|---|
| 作業 | 調撥／揀貨單、庫存移動、報廢單、出貨批次 |
| 庫存管理 | 盤點紀錄、規格轉化 |
| 庫存報告 | 即時庫存量、批號／序號 |
| 成本 | 到岸成本 |
| 設定 | 倉庫、補貨規則、路線、包裝、儲存分類、運費群組 |
製造 MRP
生產訂單、工序工單、拆解單、BOM 物料清單、工序步驟、工作中心。
會計財務
| 分區 | 表 |
|---|---|
| 憑證 | 銷項發票、進項帳單、傳票管理 |
| 收付款 | 客戶收款、供應商付款、暫收付款 |
| 折讓與調整 | 銷項折讓、進項折讓 |
| 帳務處理 | 日記帳分錄、常用傳票範本、固定資產、存貨估價、總分類帳、銀行對帳、對帳工作區、鎖帳管理 |
專案管理
所有專案、專案更新、專案階段、專案標籤。
人力資源
員工、部門、職位、假別、薪資結算等，含 HR 設定與進階設定。
已經接好的業務引擎
這是預建資料底座的第二層價值：表之間不是靜態關聯，而是有邏輯在跑。
| 引擎 | 觸發時機 | 自動發生什麼 |
|---|---|---|
| 銷售開票連動 | 已確認訂單建立發票 | 抓明細與待開票數量、帶入產品分類的收入科目與稅率，產生銷項發票草稿 |
| 採購進項連動 | 採購訂單建立帳單 | 只針對「已收貨未開帳」的差額產生進項帳單草稿，借方帶入費用科目 |
| 存貨即時計價 | 庫存移動完成 | 依「數量 × 單位成本」直接產生已過帳的存貨計價傳票 |
| 薪資結算連動 | 確認／撤銷薪資批次 | 產生應付薪資傳票；撤銷時自動產生沖銷分錄 |
| 收付款沖銷 | 收付款單過帳 | 以先進先出自動核銷未結清發票，並推導付款狀態 |
完整說明見第 14 章。重點是：這些連動對所有入口一視同仁——不論資料是從 Custom App、API 還是 AI 助理寫進來的，引擎都會照樣運作。
每張表都有的四個系統欄位
| 欄位 | 型別 | 說明 |
|---|---|---|
id | UUID | 主鍵，自動生成 |
created_at | timestamptz | 建立時間，自動設定 |
updated_at | timestamptz | 更新時間，自動更新 |
tenant_id | UUID | 組織識別，自動注入，構成列級隔離 |
寫入時不需要（也不應該）自行提供這四個欄位，系統會自動處理。
custom_data：不改結構就能存業態專屬資料
所有功能性資料表都帶有一個 custom_data JSONB 欄位，專門讓應用程式存放平台沒有預設的欄位。
{
"name": "新客戶",
"email": "[email protected]",
"custom_data": {
"passport_no": "A123456789",
"travel_pref": ["eco", "window_seat"]
}
}
它接受任意 JSON 結構（物件、陣列、巢狀皆可），並遵循與其他欄位相同的租戶隔離與授權規則。
注意：custom_data 也是一個需要授權的欄位。若應用程式的引用清單中沒有包含它，讀取時看不到、寫入時會被忽略。
若您需要的是可查詢、可索引、有型別約束的欄位，custom_data 不是正確工具——請改用延伸欄位或自建表（第 5 章）。
存取這些表的三種方式
| 方式 | 用於 | 授權模型 |
|---|---|---|
| 主控台表格檢視 | 查核、稽核、少量修正 | 使用者的角色權限 |
Custom App SDK（ctx.db / src/db.ts） | 應用程式執行期 | 引用宣告 ＋ Scope 核可 |
| REST Proxy API | 第三方系統 | 引用宣告（已發布快照）＋ API Key |
三者共用同一套查詢引擎與同一套護欄。差別只在認證方式與引用版本。
引用：欄位級的存取授權
不論是 Custom App 還是第三方系統，都不能直接存取 ERP 表——必須先建立引用（Reference），明確宣告：
- 要存取哪一張表
- 表裡的哪些欄位
- 允許哪些操作（
read/create/update/delete）
沒有宣告的表、沒有宣告的欄位，一律存取不到。系統核心表（身分驗證、租戶管理、權限設定、稽核紀錄）永遠不可引用。
可引用的表清單可以用 API 查詢：
GET /api/v1/refs/available-tables
GET /api/v1/refs/tables/{table_name}/columns
欄位查詢的回應會標示型別、是否可為空、是否為外鍵及其指向——這是您規劃資料流時的權威來源，比任何文件清單都準確。
資料模型的擴充路徑
當預建的表不夠用時，您有三條路，由輕到重：
custom_data——最輕，不改結構，適合非結構化的附加資料- 延伸欄位——在既有 ERP 表上加真正的欄位，可查詢、有型別
- 自建表——建全新的表，租戶層級，支援關聯
三者的取捨見第 5 章。