報價、接單、進貨、庫存、生產、記帳都在同一套系統、同一個資料庫裡。以 Odoo 開源 ERP 為主軸，提供導入規劃、客製化開發、AI agent 串接、台灣法規落地與年度維護。
一句話：公司的中央帳本兼總機。從報價到記帳，全公司只留一份資料。
ERP（Enterprise Resource Planning，企業資源規劃）就是把公司從接單到記帳的整條流程，放進同一套系統、同一個資料庫。
業務開報價單，客戶下單後直接轉成訂單。系統檢查庫存，不夠就開請購單採購、或開工單叫工廠生產。出貨後自動產生發票與應收帳款，帳同時就記好了。從頭到尾只有一份資料，不必重打第二次。
沒有 ERP 的公司通常各用各的：業務一份報價 Excel、倉管一份庫存 Excel、會計一套帳務系統、工廠靠白板與紙本工單。單獨看都對，兜起來就對不起來，月底結帳得人工比對好幾天。
這四個名詞常被混在一起講，但管的事、使用者與預算科目都不一樣。
管成交之後：訂單、採購、庫存、生產、應收應付與記帳。使用者是業務助理、倉管、生管與會計。
管成交之前：客戶名單、商機追到哪一階段、報價紀錄。Odoo 本身就內含 CRM 模組。
管工廠現場的即時派工與機台數據。ERP 給它工單，它回報實際產出。
管伺服器有沒有掛、夜間批次有沒有跑完。不屬於 ERP，由本公司以 Hitachi JP1 承接。
來自比利時的開源企業管理系統，原廠 Odoo S.A. 創立至今超過二十年。聚能智慧為 Odoo 合作夥伴。
選型時，模組數量是其次，該看的是資料與介面的開放程度。這一點決定日後能不能把 AI 導進日常流程，也決定系統的長期掌握權在誰手上。
80 個以上可獨立加裝的模組。先上 CRM 或庫存驗證成效，跑順了再擴大到全公司，不必一次押上整筆預算。
以 PostgreSQL 為資料庫，程式碼與資料表結構公開。可另開唯讀複本供報表、分析與知識庫索引使用，不影響正式系統效能。
任何模型的公開方法都能透過 XML-RPC 或 19.0 新增的 JSON-2 API 呼叫。自訂模組與 Studio 新增的欄位一存在就自動具備 API，不必再開發一層中介介面。
外部呼叫以綁定的使用者身分執行，套用模型存取權限、資料列規則與欄位權限。外接程式不必自行重寫一套權限邏輯。
可完整地端自建，資料落在自有機房或私有雲。升級時間點與測試驗證，企業自己決定，不受單一雲端服務的更新排程牽制。
從幾個人的貿易商到上百人的製造業都在同一套架構上。人多了加使用者、流程複雜了加模組。
AI agent 要能替企業做事，前提是它讀得到、也寫得回 ERP 的資料。閉源 ERP 也有 API，差別在覆蓋範圍由供應商決定。清單外的資料表、清單外的自訂欄位，就得等原廠排程開放。
Odoo 的規則相反。模型一旦存在就自動具備 API，含自行開發的模組與 Studio 建立的欄位。程式端還能透過 ir.model 與 ir.model.fields 自省，自動列舉這台資料庫有哪些模型、哪些欄位、什麼型別。19.0 的 JSON-2 API 另提供 /doc 端點，依實際安裝的模組與自訂欄位動態產生 API 文件。對 AI agent 而言，這等於一份可自動抓取、不必人工維護的工具清單。
台灣客戶常見的字軌管理、發票折讓、補充保費計算等在地欄位，以自訂模組建立之後，同樣會出現在 API 與動態文件裡。agent 立刻能讀寫，不需要另做一層中介介面。
成本結構上也少一層。部分商用 ERP 對第三方系統的間接存取另計授權費用，而 AI agent 天生就是高頻建立單據的角色，這類計費會直接放大（資料來源：市場報導）。Odoo 沒有等價的間接存取收費機制。
兩件事要分開講。能不能開發：Community 與 Enterprise 的地端部署、以及 Odoo.sh，都可以開發自訂模組；只有 Odoo Online（SaaS）不能安裝自訂程式碼，僅能用 Studio 做無程式碼調整。授權怎麼算：Community 核心採 LGPLv3，可自由修改與散布；Enterprise 模組為原廠專有授權，訂閱後可取得原始碼並依自身需求修改，但不可再散布。
以下場景都以「代理人產生草稿或清單、人工確認後才生效」為原則設計。寫入一律落在草稿或待審狀態，訂單確認、付款與對外送信仍由人操作。
開源是這條路的技術前提：資料表與 API 完全開放，外部代理人才能直接讀寫 ERP。圖中為外部代理人搭配地端模型的部署方式，推論全程在自有 GPU 上完成。
讀取來信本文與規格附件，比對料號與該客戶的專屬價目表，產生草稿報價單並附上來源信件。業務核對品項與價格後才按確認，代理人不執行訂單確認。
每日比對供應商發票、採購單與收貨紀錄的數量、單價、幣別與稅率，差異以留言寫在該張發票上並標記待處理。會計從逐張翻單改為只看例外。
讀取現有量、在途量、過去十二個月的出貨紀錄與供應商前置期，算出建議補貨量，寫回補貨規則或產生草稿採購單。安全庫存改為隨銷售型態滾動修正。
判斷來信屬於報價、交期、維修或帳務，寫入工單分類與優先序，同時查出該客戶的訂單與出貨進度填進草稿。草稿裡的交期與單號都是從系統查來的。
以中文提問，代理人轉成查詢條件，對會計分錄與分析項目彙總後回答。回答附上實際使用的篩選條件、筆數與可點回系統的連結，供財會核對。
每日比對訂單售價與該產品的實際成本，對毛利率低於門檻、或與同客戶同品項歷史落差過大的訂單發出通知。錯價與漏算運費在出貨前就抓到，不必等到月結才發現。
依帳齡分級未收款發票，對照客戶信用額度與尚未出貨的訂單，產生催款信草稿與建議暫停出貨清單。催款信一律人工送出，暫停出貨由主管決定。
比對統一編號、電話與地址相似度，找出疑似重複的客戶或供應商，列出各自關聯的訂單與發票筆數。合併動作一律人工執行，避免帳齡與信用額度失真。
月底依序彙總訂單、發票、出貨與工時，產出專案或事業部損益，並記錄每個數字對應的來源單據編號。會計抽核即可，數字可追溯到單張憑證。
Odoo 19.0 起內建 AI 應用，含 AI 代理人、AI 欄位、AI 伺服器動作、郵件範本 AI 指令、文件自動分類、線上客服代理人與語音轉錄，屬企業版功能。標準的 Ask AI 代理人只回答與導覽、不變更資料庫。要建立與修改紀錄，得另外設定代理人的行為情境與可執行工具。19.4 版另加入 MCP（Model Context Protocol）支援。
另一條路是不動 Odoo 的 AI 模組，改由外部代理人透過 API 讀寫資料，推論在企業自己的環境完成。Odoo 端不必客製，升級風險低。權限直接沿用系統原生的存取權限與資料列規則。兩條路怎麼選、資料怎麼流，見下方「地端部署，資料不出機房」。
從流程盤點到導入後調校的六個階段，每一階段都有可以驗收的產出。可以只做前兩段先確認可行性，不必一次做完整套。
ERP 放在自己的機房，與推論不出機房，是兩件要分開規劃的事。
Odoo 可完整地端自建，資料庫與應用服務都跑在自有機房或私有雲。這是 SaaS 專屬的 ERP 給不了的選項。規劃架構時還有一點要先講：原廠 AI 功能目前支援的供應商為 OpenAI 與 Google Gemini，地端與 Odoo.sh 資料庫使用時必須自備 API 金鑰，送出去做推論的那段內容仍會離開機房。要讓推論也留在內部，需要另外規劃架構。
地端推論需要 GPU 資源池與模型服務端點。超融合叢集可同時承載 Odoo 與 GPU 節點，模型服務與 ERP 走內網互通。財報、客戶名單、報價策略與薪資資料全程不出機房，也不經過第三方雲端供應商。底層平台與硬體規劃見超融合與 VMware 替代方案。
需要客製模組、外部 API 串接、多公司架構或地端部署時，訂閱方案要採用支援客製的層級。模組範圍、部署方式與方案層級在選型階段一併確認，不必等到開發中途才調整。授權採訂閱制、依使用者人數計價。原廠價格與優惠條件會調整，實際數字依當期報價試算。
地端模型服務平台還很新，建議先以概念驗證（POC）測過再進正式環境。任務怎麼分級：涉及財務、客戶名單、薪資與報價策略的走地端；一般文案改寫這類低敏感任務才考慮雲端。
台灣客戶最常用到的模組。可依需求逐步啟用，之後要再加也可以。
管潛在客戶與商機，看得到每個案子追到哪一階段。
線上出報價單，確認後一鍵轉訂單，版本與歷史留在系統裡。
請購、詢價、採購單與供應商管理，可依規則自動建議補貨。
多倉庫、多儲位、批號序號追溯、條碼揀貨與盤點。
BOM 用料表、工單、產能與排程，缺料與進度都變成看得到的數字。
總帳、應收應付、銀行對帳、稅務與財報，營運資料直接變成帳務資料。
員工資料、招募、請假與考核。台灣薪資規則由本公司建置，見下方在地化說明。
專案任務、甘特圖與工時記錄，工時可直接轉成請款依據。
商品、庫存、訂單與發票跟 ERP 是同一份資料，不必再做介接。
門市與餐飲收銀，網路中斷可離線收單，恢復連線後再同步。
電商或客戶登入入口若會開放到網際網路上，建議一併評估對外服務的防護，請見網站與 API 防護（WAF）。
台灣法規落地由本公司負責建置與維護。原廠提供的是會計科目表、財報範本與加值中心電子發票模組，其餘依現行法規實作。
Odoo 原廠的台灣在地化模組共四個：l10n_tw（會計科目表與營業稅設定預設值）、l10n_tw_reports（台灣格式財務報表範本），以及 l10n_tw_edi_ecpay 與 l10n_tw_edi_ecpay_website_sale（透過綠界科技這家加值服務中心開立與上傳電子發票，含 B2B、B2C 與電商訂單自動開票）。原廠沒有直連財政部的模組，薪資在地化也不含台灣。這兩塊由本公司建置。
直接採用原廠模組，本公司負責設定與流程對接：發票類別、字軌對應、折讓與作廢流程、電商訂單自動開票。加值中心承擔訊息規格改版、平台介接異動與憑證維護。導入時間最短。
本公司開發整合，直連財政部電子發票整合服務平台。範圍包括：依電子發票資料交換標準訊息建置指引產生 XML、字軌配號與餘號管理、交換目錄與回傳檔解析、依規定時限的存證監控與告警、作廢與折讓流程、載具與中獎資訊處理。規格與 Turnkey 版本更新也持續跟進。發票資料只在企業機房與財政部平台之間流動。
三個問題就能收斂：一年開立多少張發票、有沒有人力負責主機與憑證維運、發票資料能不能經過第三方。開票量大、或要求資料不外流的，適合直連 Turnkey；開票量中低、想把技術風險外包的，適合走加值中心。兩條路也可以先後銜接：先用加值中心快速上線，開票量放大或資安要求提高後再遷移。開票端的資料模型可以共用。
Odoo 的薪資模組是規則引擎，薪資結構與薪資規則可自行定義，因此台灣薪資不是做不到，而是規則要有人建、每年有人維護。建置範圍包含：
主管機關每年公告投保級距與費率，規則要跟著更新。年度維護會持續追蹤這部分。
以原廠台灣科目表為基礎，依實際帳務結構調整科目層級與對應關係。營業稅稅別與進銷項對應也一併設定，並產出符合台灣格式的財務報表。涉及會計政策與稅務認定的部分，先由專業財稅顧問夥伴與貴公司的會計人員或簽證會計師確認，再設定進系統。
勞健保加退保有時效與級距申報義務。適合用排程比對員工到職異動與投保清冊，找出已到職未加保、調薪未同步調整投保級距這類不一致，產生待辦清單，人資確認後再處理。發票端同樣可以每天掃描有沒有單據卡住未上傳，避免逾期存證。
ERP 專案橫跨資訊與財會兩個專業。分工先講清楚，準備工作才排得出來。
・導入規劃：流程訪談、單據盤點、模組與部署方式建議
・系統客製化開發：標準功能不足的部分，開發對應模組
・模組調整：欄位、表單版面、審核流程與報表設定
・台灣法規落地：電子發票路徑實作、薪資規則建置與年度更新
・AI 導入：流程評估、資料整備、知識庫建置、代理人開發與地端模型部署
・與既有系統串接：進銷存、電商平台、物流與人資系統
・資料移轉：客戶、供應商、料號、期初庫存與未結單據
・教育訓練與技轉：分部門實機訓練與操作手冊交付
・年度維護合約：上班時間支援、設定調整與升級評估
・會計科目表的設計與調整
・稅務設定與申報作業的認定
・財務報表格式與會計政策的確認
・期初帳務餘額的確認與結轉
帳務認定與稅務判斷由專業財稅顧問夥伴、貴公司的會計人員與簽證會計師共同確認。確認後的規則，本公司再設定進系統。會計師簽證與稅務簽證屬其專業服務範圍。
八個階段，每一段都有可以驗收的產出。
ERP 導入以數個月為單位。時間多半花在弄清楚內部流程與權責，系統設定其次。分期上線可以讓第一批成效更早出現，後續範圍怎麼定，也有實際依據。
需求訪談階段最常被問到的幾個問題。
社群版（Community）免費且原始碼公開。正式營運需要的完整會計、薪資、原廠支援與版本升級屬於企業版訂閱，AI 應用模組也在企業版。導入規劃、流程調整、客製開發與教育訓練都是實際工時成本。ERP 的成本從來不只授權費那一欄，建議在選型階段一起試算。
三個原則：能用標準功能就不客製、能用 Studio 設定就不寫程式、必須客製時以獨立模組擴充而不動核心程式。用 Odoo.sh 或地端部署，升級時間點自己決定，先在測試環境驗證過再上。原廠版本更新與資安通報的追蹤，屬於年度維護範圍；升級服務在合約裡列為獨立項目。
客製模組的原始碼、資料庫與交付文件都在貴公司手上。日後要自行維護或更換顧問商，接手的人看得到完整內容，不會因為看不到程式碼而動彈不得。
不會。代理人使用專屬系統帳號，套用最小必要的模型存取權限與資料列規則。寫入一律落在草稿或待審狀態。訂單確認、發票過帳、催款信送出這類動作維持人工執行，操作紀錄留在系統內可追溯。導入前也會在測試環境先跑過完整情境。
可以。AI agent 透過 API 讀寫資料，既有系統只要提供可用的介面就能串接。介面不夠用時，可以評估改走資料匯出或中介資料庫。以 Odoo 為資料底層時，模型與欄位一存在就具備 API，串接工作量相對低。
可以，也是建議的做法。常見的起點是 CRM 或庫存：範圍小、成效看得到、對日常作業衝擊也小。跑順了再往採購、製造或會計擴大。
可以，選擇地端部署（On-premise），訂閱方案採用支援客製的層級。若同時評估底層的伺服器、虛擬化平台與 GPU 資源，可一併規劃，詳見超融合與 VMware 替代方案。
分兩部分。Odoo 授權訂閱費依使用者人數與方案層級計價，由原廠訂價。導入服務費依模組數量、客製與 AI 範圍、資料移轉複雜度估算。原廠價格與優惠條件會調整，所以網頁上不標數字，請與我們聯繫取得試算。
請留下聯絡方式與需求說明，我們將安排顧問與工程師與您聯繫。可協助評估的範圍：流程盤點、模組與方案選定、AI 導入、台灣法規落地項目與年度維護。