前言
若要將 odoo 與其他商業軟體進行比較差異，我會說 odoo 與其他的大型 ERP 系統比較大的差異在於 odoo 的系統模組化設計。odoo 在系統規劃過程中透過高度模組化的設計，將不同的功能需求進行模組劃分，這樣的設計我們可以用樂高積木來做理解。在每個導入個案中，我們可以針對其不同之需求進行模塊組合拼湊出對於需求個案來說"剛剛好"的系統，而非將所有的功能一次裝上，如此一來，我們可以達成系統介面與功能面之整潔，同時又可以保有企業流程未來持續增長的彈性。
再次拿出樂高積木來幫大家做快速的理解，如果說每件樂高積木作品中最大的零件或區塊，那必定是作為乘載整個樂高積木的底層，在一些樂高作品中如果有一些重要的功能需求，我們也經常發現對應這些功能之重要模組(如電控模組、馬達模組)等，也都會設計安裝於底層，來滿足整個作品來使用。類似的觀念也適用於 odoo 的底層模組架構，針對一些系統重要的功能或運作架構，在 odoo 中一般都將這些功能的規劃安排在底層模組裡。而對於應用面的模組而言，我們僅需呼叫使用即可！
模組名稱：Base等系統底層模組
功能與特點
作為odoo系統之統合性應用，有相當多之系統架構規劃於底層系統進行定義與規劃，以下針對經常在應用模組開發中會使用的功能做簡單介紹：
1.系統使用者/公司/聯繫人主檔
作為不管哪個系統而言，系統使用者主檔(res.user)可能是每個系統都相當基礎的功能需求。
而在odoo中比較特殊的，是在odoo的公司(res.company)運作架構。在其他系統中的設計，通常是預設一個資料庫僅對應到一間公司，因此當我們面對多公司之管理需求時，通常就會必須面對到相對複雜的跨資料庫之資料管理。在odoo系統中，存在在一個資料庫中運行多公司之可能性，省下了不少的煩惱！
另外 odoo 在聯繫人( res.partner )的設計更是有趣。在過去的資料規劃上來說，我們可能在客戶、供應商、公司員工等等資料會透過分拆的資料表來進行儲存，而當中有相當多重複的類似欄位(如名稱、地址等等)。分拆的資料表在進行系統使用時很有可能會針對相同對象重複建檔(如員工同時也是公司的客戶等)，這也造成系統內在進行一些整合性比對時的困難。odoo 在聯繫人之設計上，將不管是客戶、供應商、系統使用者甚至公司自身都為一個系統之聯繫人，因此所有與公司運作流程上可能有關連的對象都可以透過聯繫人來進行資料整合，避免過去的各種困擾！
2.資料庫
說到 odoo 的資料庫，就不能不說 odoo 的 ORM 架構，ORM 為 Object Relational Mapping 的縮寫，在中文翻譯上可以稱為物件關係對映，維基百科是這樣說的：ORM 是一種程式設計之技術，此技術用於實現物件導向程式語言裡不同類型系統的資料之間的轉換。
odoo 的 ORM 架構協助我們將一些基礎會使用的資料庫開發功能先寫成物件式之程式讓我們可以快速呼叫並且幫我們處理好在資料庫中該做的事，如此一來我們不用再花時間去處理資料庫的欄位設置，減少開發資料庫時可能發生的錯誤，並可以花更多精力專注於系統之程式邏輯！
相關 odoo 的 ORM 框架可以透過 odoo 官方文件了解更多！
