[iDempiere] 多租戶架構解密：Client、Organization、Role 的設計哲學

小編 2026/02/072026/02/07 發佈留言

本篇文章更新時間：2026/02/07
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持。

如果你打算導入 iDempiere，在碰觸任何商業流程之前，必須先搞懂它的多租戶架構。這不是可選的進階知識 — 它是 iDempiere 一切運作的根基。搞不清楚 Client、Organization、Role 的關係，後續的每一步都會走歪。

這篇文章會用白話文搭配 GardenWorld 示範公司的實例，帶你理解 iDempiere 的四層架構設計。

這是 iDempiere 開源 ERP 系列文章 的第 3 篇。

為什麼需要多租戶架構？

想像你是一家集團的 IT 主管，集團旗下有三家子公司。你有幾種選擇：

每家公司各裝一套 ERP：三套系統、三組資料庫、三倍維護成本。要做集團合併報表時，得手動從三個系統拉資料。
三家公司共用一套 ERP，但完全隔離：同一個系統內，每家公司看不到彼此的資料。管理員可以一次管理所有公司，報表可以合併產出。

iDempiere 走的是第二條路 — 這就是 多租戶（Multi-Tenant） 架構。一套 iDempiere 系統、一個資料庫，可以服務多個完全獨立的公司（Client），每個公司內又可以有多個組織（Organization）。

四層架構：System → Client → Organization → Role/User

iDempiere 的權限與資料隔離架構分為四層：

System（系統層）
  └── Client / Tenant（公司/租戶層）
        └── Organization（組織層）
              └── Role → User（角色 → 使用者層）

讓我們逐層拆解。

第一層：System（系統層）

System 是 iDempiere 安裝的最頂層。一套 iDempiere 安裝就是一個 System。

用途：系統層級的設定，如資料庫結構、Application Dictionary、全域參數
存取權限：只有 System Administrator 角色（預設帳號 SuperUser / System）可以操作
注意：System 層的設定會影響所有 Client，修改要非常謹慎

在 iDempiere 中，有一個內建的「System」 Client（Client ID = 0），專門用來管理系統層級的設定。普通使用者永遠不需要登入這個 Client。

第二層：Client / Tenant（公司/租戶層）

Client（新版文件改稱 Tenant）是 資料隔離的最高邊界。根據 iDempiere 官方文件的定義：

A Tenant (formerly known as Client) is a global consolidated collection of financial entities.

白話文：一個 Client 就是一個獨立的公司（或集團）。不同 Client 之間的資料完全隔離，互相看不到。

每個 Client 擁有獨立的：

會計架構（Accounting Schema）
會計科目表（Chart of Accounts）
商業夥伴（Business Partners）
產品主檔（Products）
倉庫（Warehouses）
使用者與角色定義
樹狀結構定義（Tree Definition）

典型使用情境：

一家獨立公司 = 一個 Client
一個集團旗下有多家子公司 = 多個 Client（如果子公司需要完全獨立的帳簿）
同一套系統服務多個不同客戶（SaaS 模式）= 每個客戶一個 Client

第三層：Organization（組織層）

Organization 是 Client 底下的子單位。根據官方文件：

An Organization is a legal, financial or taxation entity inside a Tenant, most commonly referred to as a "set of books."

白話文：Organization 是公司內部的事業部、分公司、分支機構或部門 — 任何需要獨立記帳的單位。

Organization 的重要特性：

所有總帳紀錄都綁定在 Organization 上：每一筆會計分錄都必須屬於某個 Organization
Summary vs Transactional：
- Summary Organization（彙總組織）：用於財務合併，不能直接過帳。例如「總公司」
- Transactional Organization（交易組織）：實際做交易的單位，可以過帳。例如「台北分公司」「高雄分公司」
每個 Client 必須有一個 Organization 「*」：代號為星號（*）的 Organization 是一個特殊的「全組織」，用來存放跨組織共用的資料（如共用的產品主檔、商業夥伴等）

Organization 架構範例

Client: 台灣科技集團
├── * (全組織，共用資料)
├── 總部 (Summary，用於合併報表)
│   ├── 台北分公司 (Transactional，獨立記帳)
│   ├── 高雄分公司 (Transactional，獨立記帳)
│   └── 海外事業部 (Summary)
│       ├── 日本子公司 (Transactional)
│       └── 越南子公司 (Transactional)

第四層：Role → User（角色 → 使用者層）

iDempiere 使用 RBAC（Role-Based Access Control，角色基礎的存取控制） 來管理權限。

Role（角色） 定義了：

可以存取哪些 Organization
可以操作哪些功能視窗（Window）
可以執行哪些流程（Process）
可以產出哪些報表（Report）
資料的讀寫權限

User（使用者） 是實際登入系統的人。一個 User 可以被指派 多個 Role，登入時選擇要使用哪個角色。

登入時的四重選擇：

每次登入 iDempiere 時，使用者會看到四個下拉選單（參考 Wiki: Login Help）：

Role：選擇要使用的角色（決定了可見範圍和權限）
Client：選擇要操作的公司（通常由 Role 自動決定）
Organization：選擇要操作的組織（決定了交易歸屬）
Warehouse：選擇預設倉庫（庫存相關操作會使用）

這個設計讓同一個人可以在不同角色間切換 — 例如一位經理同時負責台北分公司和高雄分公司的業務，他可以切換 Organization 來分別處理。

GardenWorld 示範公司的架構實例

iDempiere 內建的 GardenWorld 示範公司是理解這套架構最好的教材。

Client 層

安裝完成後，系統預設有兩個 Client：

System（ID: 0）：系統管理專用，不做業務操作
GardenWorld（ID: 11）：示範公司，模擬一家園藝用品公司

Organization 層

GardenWorld 底下有多個 Organization：

*：全組織（共用資料）
HQ：總部（Summary）
Store Central / Store East / Store West：三個區域門市（Transactional）
Fertilizer：肥料事業部（Transactional）

Role 層

GardenWorld 定義了多個角色：

GardenWorld Admin：管理員角色，可以存取所有功能和所有 Organization
GardenWorld User：一般使用者角色，權限受限

User 層

GardenAdmin（密碼：GardenAdmin）：綁定 GardenWorld Admin 角色
GardenUser（密碼：GardenUser）：綁定 GardenWorld User 角色

實務規劃建議

理解了架構之後，在實際導入 iDempiere 時，你需要回答以下問題：

Client 規劃

你有幾家獨立的公司需要使用這套系統？
這些公司之間是否需要完全隔離資料？
如果是集團企業，考慮每家法人實體一個 Client
如果是單一公司，一個 Client 就夠了

Organization 規劃

公司內部有哪些需要獨立記帳的單位？
哪些是彙總用（Summary），哪些是實際交易用（Transactional）？
注意：Organization 一旦有交易資料就很難修改結構，規劃階段務必想清楚

Role 規劃

公司有哪些職能角色？（業務、採購、倉管、會計、主管等）
每個角色需要存取哪些功能？
哪些角色可以跨 Organization 操作？
審批流程中的層級（如主管核准訂單）

常見規劃錯誤

把部門當 Client：除非是完全獨立的法人實體，否則用 Organization 即可
Organization 規劃不做 Summary 層：如果未來需要合併報表，沒有 Summary Organization 會很麻煩
Role 太粗或太細：太粗導致權限外洩，太細導致管理複雜。建議先從職能出發

本地化考量

對於台灣企業，在規劃架構時還需要考慮：

會計科目表：iDempiere 預設的 Chart of Accounts 不符合台灣會計準則，需要自行建立或匯入適合台灣的科目表
繁體中文語系：預設翻譯完成度僅約 2%，建議使用社群提供的繁體中文語系包，詳細安裝方法可參考我的文章〈iDempiere 部署上線版的流程方法（含中文化）〉以及〈[iDempiere] User, Client 與本地化〉
多幣別：如果有外幣交易需求，在 Client 層設定會計架構時就需要定義幣別和匯率更新機制

小結

iDempiere 的四層架構（System → Client → Organization → Role/User）是它處理多公司、多組織情境的核心設計。理解這個架構：

Client = 獨立公司，資料完全隔離
Organization = 公司內的記帳單位，有 Summary 和 Transactional 之分
Role = 權限的集合，決定使用者能看到和做什麼
User = 實際登入的人，可以有多個 Role

這是導入 iDempiere 時最重要的前置工作之一。規劃得好，後續的流程設定會順暢許多；規劃不當，未來修改的代價很高。

下一篇，我們會進入動手做的階段 — 用 Docker 在十分鐘內把 iDempiere 跑起來，親手體驗 GardenWorld 的架構。

iDempiere 開源 ERP 系列文章（完整目錄）

第 1 篇：iDempiere 是什麼？從 Compiere 到社群驅動的開源 ERP 全解析
第 2 篇：iDempiere vs Odoo vs ERPNext：開源 ERP 三強怎麼選？
第 3 篇：多租戶架構解密：Client、Organization、Role 的設計哲學（本篇）
第 4 篇：快速體驗：用 Docker 十分鐘跑起來
第 5 篇：正式環境部署：從零到上線的完整指南
第 6 篇：銷售流程全走查：從報價到收款
第 7 篇：採購流程全走查：從請購到付款
第 8 篇：庫存與物料管理：倉庫、定價與產品屬性設定
第 9 篇：會計與財務報表：文件驅動會計的哲學與實踐
第 10 篇：退貨處理與 Open Items 管理
第 11 篇：製造模組入門：BOM、工單與生產排程
第 12 篇：Workflow 引擎與商業流程自動化
第 13 篇：Plugin 開發入門：用 OSGi 擴充 iDempiere
第 14 篇：台灣在地化挑戰：統一發票、會計法規與中文化
第 15 篇：導入實戰建議：從評估、規劃到上線的路線圖

參考資料

取消回覆

文章

文章