华为MetaERP # Oracle EBS R12 AR 视角：Operating Unit（OU 运营单元）深度完整解析承接前面 BG / Ledger / LE / INV 组织层级，先锚定

原创于 2026-08-23 10:23:36 发布 · 30 阅读

本内容遵循CC 4.0 BY-SA版权协议

Oracle EBS R12 AR 视角：Operating Unit（OU 运营单元）深度完整解析

承接前面 BG / Ledger / LE / INV 组织层级，先锚定层级位置：

Business Group (BG)
        ↓
Ledger（主分类账，会计主体）
        ↓
Legal Entity (LE 法人)
        ↓
Operating Unit (OU) ◀——MOAC核心管控对象、AR核心隔离层
        ↓
Inventory Organization（库存组织，物流层，AR不以此隔离）

核心一句话总结： OU 是 EBS R12 采购、销售、应收、应付等交易类模块的【业务运营隔离单元】；MOAC 就是一套专门用来管控 OU 访问权限的安全框架；AR 所有应收单据底层依靠 ORG_ID（OU 主键）实现数据隔离。

一、OU 官方设计哲学与定位

1. 定义

Operating Unit，运营单元。面向业务交易、收入、应收、采购支出、客户交易的运营边界。 Oracle R12 架构思想：会计主体（Ledger/LE）与业务运营单元解耦。

Ledger：管科目、本位币、会计日历、总账余额（会计视角）
LE：管法人、纳税、法定报表、公司间交易（法律税务视角）
OU：管日常购销业务、应收应付单据、业务配置（运营业务视角）

2. 典型业务映射

OU 可以设置为：销售分公司、区域事业部、独立分销板块、海外业务单元。业务规则：

一个 LE（法人）可以拥有多个 OU；一个 OU 只能归属一个 Ledger、一个默认 LE、一个 BG； OU 创建后归属 BG、Ledger 原则上不可变更。

二、OU 隔离边界：哪些对象带 ORG_ID，受 OU 隔离（AR 重点）

✅ 【AR 模块内，按 OU 隔离】（全部存在 ORG_ID）

应收主交易单据

RA_CUSTOMER_TRX_ALL（应收发票）
AR_CASH_RECEIPTS_ALL（收款单）
AR_RECEIVABLE_APPLICATIONS_ALL（核销记录）
AR_ADJUSTMENTS_ALL（调整单）
AR_CREDIT_MEMOS_ALL（贷项通知单）

AR 业务配置（OU 私有，跨 OU 不共享）

AR 系统选项（System Options）
事务类型 Transaction Types
收款方法 Receipt Methods
自动会计 AutoAccounting 规则
核销规则、催款配置、银行收款账户
收款批来源、汇率损益配置

TCA 客户相关 HZ_CUST_SITES_ALL 客户地点携带 ORG_ID

同一客户账户 HZ_CUST_ACCOUNTS（全局共享），可以在 OU1、OU2 分别建立不同账单地点、不同信用收款条款，实现集团客户分 OU 独立交易。

✅ 配套交易模块同样 OU 隔离

OM 销售订单、PO 采购订单、AP 发票、AP 付款。

❌ 不受 OU 隔离（无 ORG_ID）

GL 总账科目、Ledger、会计日历
TCA 客户主体 HZ_PARTIES、客户账户 HZ_CUST_ACCOUNTS
HR 员工、岗位（BG 隔离）
库存物料主数据、库存余额（INV 库存组织隔离）

三、OU 与 MOAC 的耦合关系（重中之重）

1. MOAC 本质：只管控 OU 访问

MOAC = Multi-Org Access Control 作用范围：同一个 BG 内部的多个 OU。 MOAC 不管理 LE、不管理库存组织、不管理 Ledger。

两种运行模式由配置文件控制：

M 模式（多组织模式，MOAC 开启） 职责配置文件 MO: Security Profile → 职责可以访问 Security Profile 内定义的一组 OU；表单出现 Operating Unit LOV，用户可动态切换 OU。配置文件 MO: Operating Unit 失效。
S 模式（单组织模式，兼容 R11i） 未设置 Security Profile，使用 MO: Operating Unit；职责永久锁定单一 OU，界面无 OU 选择框。

2. MOAC 底层技术实现：VPD + ORG_SEC 策略

所有 AR _ALL 表的 APPS 同义词（如 AR_TRANSACTIONS）绑定 VPD 策略 ORG_SEC 运行流程：

用户登录职责 → 锁定 BG（HR:Business Group）
程序执行 MO_GLOBAL.INIT('AR')
根据 Security Profile 加载当前 BG 内授权 OU 集合存入会话上下文 multi_org2
查询同义词时 VPD 自动追加过滤条件
- M 模式：ORG_ID IN (授权OU列表)
- S 模式：ORG_ID = current_org_id

⚠️关键区分： VPD 只是查询权限过滤； AR 禁止跨 OU 核销是应用业务逻辑约束，不是 VPD 权限限制。 即便你通过 SQL 直接查询两个 OU 单据，系统依然不允许 OU A 收款核销 OU B 发票。

四、AR 模块中 OU 最核心的硬性业务约束（架构底层限制）

约束 1：单据创建时永久绑定 ORG_ID，不可迁移

发票、收款一旦创建，ORG_ID 固化；无法把一张发票从 OU82 转移到 OU83。

约束 2：原生禁止跨 OU 核销（EBS R12 标志性局限，对比 Fusion）

表：AR_RECEIVABLE_APPLICATIONS_ALL 核销时校验：收款单 ORG_ID = 被核销发票 ORG_ID

根源：EBS 设计中，OU 是独立应收资金池；每个 OU 自有收款、自有应收余额。 Fusion BU 架构取消该限制，支持全局收款池跨 BU 核销。

若业务需要跨 OU 资金抵消，标准实现路径：

公司间应收 / 应付 Intercompany
使用杂项收款、OU 间转账分录模拟资金划转
开发定制程序（不推荐，容易破坏 SLA 会计一致性）

约束 3：AutoInvoice 批导入强制绑定单一 OU

一批接口数据只能归属同一个 ORG_ID；多 OU 单据必须分多批导入。

约束 4：AR 标准并发程序默认只处理当前上下文 OU

Create Accounting、自动核销、催款程序，只读取 MO 上下文 current_org_id 对应的单据；如需批量处理多个 OU，自定义程序需要循环切换 MO 上下文。

五、OU 和周边组织实体关联规则（结构化整理）

BG → 包含多个 Ledger；
Ledger → 包含多个 LE、多个 OU；
LE → 可以拥有多个 OU；一个 OU 绑定一个默认 LE；
OU → 可以拥有多个 INV 库存组织；一个 INV 只能归属一个 OU；
一个 OU 只能归属唯一 BG、唯一 Ledger。

业务示例： Ledger（CNY 账套） ├─LE01 甲有限公司 │ ├─OU01 国内销售一部 │ └─OU02 国内销售二部 └─LE02 乙有限公司 └─OU03 海外销售部

MOAC 职责 Security Profile 同时包含 OU01、OU02、OU03： ✅ 同一个职责可查看三家 OU 应收发票 ❌ OU01 收款不能核销 OU02/OU03 发票

六、底层关键数据表

HR_OPERATING_UNITS OU 视图，关联 HR_ALL_ORGANIZATION_UNITS_F；包含 ORG_ID、OU 名称、BUSINESS_GROUP_ID、LEGAL_ENTITY_ID、SET_OF_BOOKS_ID。

SELECT organization_id ou_id,
       name ou_name,
       business_group_id bg_id,
       legal_entity_id le_id,
       set_of_books_id ledger_id
FROM hr_operating_units;

AR 核心交易表关键字段 RA_CUSTOMER_TRX_ALL.ORG_ID AR_CASH_RECEIPTS_ALL.ORG_ID AR_RECEIVABLE_APPLICATIONS_ALL.ORG_ID

七、OU 实施常见架构方案选型（财务落地参考）

方案 1：按业务线 / 销售区域划分 OU（销售型集团常用）

优点：区域应收独立资金池、独立对账、独立 AR 业务配置；缺点：产生大量跨 OU 交易，需要处理内部往来。

方案 2：一个 LE 只设一个 OU（最简单推荐）

同一法人下所有销售业务放入单一 OU； ✅ 无跨 OU 核销障碍，应收资金池统一；适合单一法人、多条产品线但不需要独立应收资金隔离企业。

方案 3：不要以仓库（INV）划分 OU

高频误区：想用库存组织区分应收。 ❌ INV 无法隔离 AR 单据；同一 OU 下多个仓库发票全部混在同一应收池；如果需要仓库独立应收对账，只能拆分 OU。

八、典型实施误区澄清

误区 1：MOAC 开启就支持跨 OU 核销

❌ MOAC 只是查询权限框架，不能修改 AR 底层业务模型约束。

误区 2：LE=OU，一个法人只能一个 OU

❌ 一个法人可多个 OU，用于业务线隔离。

误区 3：AR 系统选项、自动会计规则可以跨 OU 共享

❌ 全部按 OU 隔离，每个 OU 独立维护一套 AR 配置。

误区 4：客户地点全局共享，不带 ORG_ID

❌ HZ_CUST_SITES_ALL 带有 ORG_ID，实现同一客户不同 OU 独立账单地址。

误区 5：切换 OU，TCA 客户账户看不到

❌ HZ_CUST_ACCOUNTS 全局可见；只是客户地点随 OU 过滤。

九、串联完整 O2C 链路，展示 OU 作用（AR 视角）

BG集团业务组
    ↓
Ledger 人民币主分类账
        ↓
LE 华南贸易有限公司
            ↓
OU 华南销售中心（ORG_ID=82，MOAC管控节点）
                ↓
INV广州仓、INV深圳仓（多库存组织，物流隔离）
                    ↓
OM销售订单 ORG_ID=82
                        ↓
发运确认 → AutoInvoice生成AR发票 ORG_ID=82，WAREHOUSE_ID记录发货仓库
                            ↓
录入收款单 ORG_ID=82
                                ↓
收款与发票正常核销（同OU无限制）

财务共享职责开启 MOAC，同时授权 OU82、OU85：

可分别查看华南、华东所有应收单据
华南收款不能核销华东发票

十、横向对比：EBS OU vs Fusion BU（承接你持续研究的 EBS ↔ Fusion AR 架构差异）

对比项	EBS R12 Operating Unit(OU)	Fusion Business Unit(BU)
定位	业务运营交易隔离单元	业务单元，融合原 OU 部分能力
权限框架	MOAC + VPD	数据访问集 Data Access Set
收款池	按 OU 割裂，禁止跨 OU 原生核销	全局收款池，支持跨 BU 核销
配置载体	AR 系统选项按 OU 隔离	AR 配置依附 BU
组织隶属	隶属于 Ledger、LE、BG	无 BG 概念，隶属于 Ledger
表命名	AR_XXX_ALL 携带 ORG_ID	AR_XXX，携带 BUSINESS_UNIT_ID