Odoo 19 Studio：先判斷費用、資料模型與權限再客製

以服務申請流程判斷何時用 Studio，說明 Standard 升 Custom、群組存取與記錄規則，附自動化設計及驗收邊界。

APAA發佈日期 2026年6月6日內容修改日期2026年10月21日適用版本：Odoo 19

適用範圍

適用 Odoo 19；方案、部署、模組、權限及服務商資格依正文條件，並非所有資料庫均已啟用。

依據 Odoo 19 與適用官方政策研究；沒有新增 Odoo 操作、付款或訊息實測。

先確認標準應用是否已能完成任務。Studio 適合補欄位、視圖與明確流程，並不會自動把一個模糊的營運要求變成安全的應用。本指南以虛構服務申請作設計例子，沒有建立或測試實際應用。

Odoo 19 官方文件明示，在 Standard 資料庫安裝 Studio 會觸發升級至 Custom。年繳／多年合約會建立有 30 日期限的加購訂單；月繳合約會在下一張帳單使用 Custom 費率。不要在正式資料庫以「試一下」方式安裝，然後把它當成免費功能。

比較費用時列出用戶數、合約週期、Custom 與現行方案差額及維護責任；實際地區報價與合約以 Odoo 為準。本指南不捏造香港月費。標準 CRM 或 Project 已能完成的工作，先評估設定而非建立另一套資料。

虛構香港維修公司需要申請編號、客戶、負責人、到期日、狀態與預算。先問這是否現有工單的補充欄位；只有工作確實獨立且有不同生命週期時，才考慮新模型。

客戶應關聯聯絡人紀錄，避免自由文字出現多個同名客戶。金額需伴隨幣別。預算是管理資料，不是發票或已收款證據。建立流水號、附件或看板是設計選項，不表示已完成任何會計對接。

群組／模型存取權限決定讀取、新增、修改及刪除某類資料；記錄規則限制該模型中哪些紀錄可存取。把使用者加入銷售群組，並不能單獨證明只看自己的客戶；隱藏畫面欄位也不能取代資料存取控制。

服務申請可先寫權限矩陣：一般人員讀寫獲分派申請，主管讀寫團隊申請，管理員負責設定。這是需求，不是已生效的規則。後續由不同角色檢查列表、直接紀錄連結、搜尋及匯出；多公司與入口網站需另外分析，不能只以管理員畫面驗收。

設計例：狀態首次轉為「待報價」且已有負責人時，替負責人建立一項準備報價活動。Odoo 19 自動化規則提供觸發、條件及建立活動動作，但設定前要定義哪些欄位變更會觸發、無負責人怎處理、重新儲存是否重複及活動完成後是否再產生。

驗收案例應包括首次轉換、重複儲存、退回再轉換及缺負責人。沒有這些結果，不能宣稱自動化已節省工時。不要把寄出通知視為交易已完成。

保留新增欄位清單、角色矩陣、規則目的及負責維護的人。Studio 可匯出客製模組，但客製匯出不能自動等同完整資料庫備份或無風險跨版本移轉。要撤回改動時先查欄位是否已有資料及下游依賴，不能直接刪欄位恢復舊畫面。

下一步把一個目前無法由標準流程完成的具體問題，寫成「哪個角色、哪筆資料、哪個預期結果」，再決定是否需要 Studio。