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

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）

1. 应收主交易单据

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

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

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

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

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

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

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

❌ 不受 OU 隔离（无 ORG_ID）

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

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

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

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

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

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

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

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

1. 用户登录职责 → 锁定 BG（HR:Business Group）
2. 程序执行MO_GLOBAL.INIT('AR')
3. 根据 Security Profile 加载当前 BG 内授权 OU 集合存入会话上下文 multi_org2
4. 查询同义词时 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 资金抵消，标准实现路径：

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

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

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

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

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

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

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

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

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

六、底层关键数据表

1. HR_OPERATING_UNITSOU 视图，关联 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;

1. AR 核心交易表关键字段RA_CUSTOMER_TRX_ALL.ORG_IDAR_CASH_RECEIPTS_ALL.ORG_IDAR_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 架构差异）