华为MetaERP # Oracle EBS R12 AR 模块 MOAC（Multi-Org Access Control）完整深度解析## 一、MOAC 诞生背景与设计哲学### 1. R-平芜编程栈

Oracle EBS R12 AR 模块 MOAC（Multi-Org Access Control）完整深度解析

一、MOAC 诞生背景与设计哲学

1. R11i 多组织痛点（理解 MOAC 价值的前提）

R11i无 MOAC，采用单 OU 绑定职责模型：

一个职责只能绑定单一 OU（MO: Operating Unit）；
财务共享服务中心人员处理多 OU 业务，必须频繁切换职责；
底层依靠CLIENT_INFO存放 ORG_ID，视图AR_TRANSACTIONS=AR_TRANSACTIONS_ALL WHERE ORG_ID = 传入ID；
无法在同一职责下跨 OU 查询、批量处理交易。

2. R12 MOAC 核心设计目标

单一职责，访问多个 Operating Unit（OU），支撑集团财务共享服务（SSC）。顶层架构分层（EBS R12 组织层级，AR 直接依赖）

Business Group（业务组，HR顶层） ↓ Legal Entity（法人实体） ← Ledger/Set of Books（账套） ↓ Operating Unit（OU 运营单元）← AR/AP/OM核心业务隔离维度

✅AR 视角关键定义

Ledger（账套）：法人会计主体，会计科目、本位币、会计日历；全局共享主数据，无 ORG_ID 隔离；
OU（Operating Unit）：业务运营隔离单元，应收发票、收款、核销、客户地点、事务类型、自动会计、系统选项全部按 OU 隔离；
MOAC：控制同一职责可以访问一组 OU 集合，实现 “单职责多 OU 操作”。

核心哲学一句话：OU 负责业务数据隔离；MOAC 负责权限访问控制；账套负责会计主体隔离。

二、MOAC 三大核心配置文件（AR 日常最重要）

R12 淘汰 R11i 单一MO: Operating Unit，三个配置互斥 / 优先级明确：

配置文件	作用	生效模式	AR 业务表现
MO: Security Profile（MO 安全性配置文件）	定义该职责可访问全部 OU 清单	多 OU 模式（M 模式）优先级最高	Form 界面出现 OU 选择 LOV，可切换 OU 录入发票、收款
MO: Default Operating Unit（MO 默认业务实体）	多 OU 模式下，表单打开默认选中的 OU	配合 Security Profile 使用	打开应收工作台默认带出指定 OU
MO: Operating Unit（MO 业务实体）	兼容 R11i 遗留，单一 OU 模式（S 模式）	仅能访问单个 OU	界面无 OU 选择 LOV，等价 R11i 模型

优先级规则：MO: Security Profile存在 → 启用MOAC 多组织模式（M），忽略MO: Operating Unit；未设置 Security Profile → 降级为传统单 OU 模式（S）。

实施标准建议：共享服务中心职责一律启用 Security Profile 开启 MOAC。

三、底层技术实现原理（VPD + 会话上下文，AR_ALL 表隔离机制）

3.1 存储层：Org-Striping（ORG_ID 条纹隔离）

AR 所有业务表统一命名规范：XXX_ALL

AR_TRANSACTIONS_ALL、AR_CASH_RECEIPTS_ALL、AR_RECEIVABLE_APPLICATIONS_ALL、AR_DISTRIBUTIONS_ALL
所有交易行强制携带 ORG_ID，标记该单据归属哪个 OU；
APPS 下同义词：AR_TRANSACTIONS = AR_TRANSACTIONS_ALL（R11i 的视图被废弃）。

重点：_ALL 表物理存储所有 OU 数据，依靠数据库策略动态过滤，不再依靠静态视图 WHERE 条件。

3.2 核心技术：Oracle VPD（虚拟私有数据库）Policy

所有 AR _ALL 同义词绑定 Policy Name =ORG_SEC策略函数：MO_GLOBAL.ORG_SECURITY运行时逻辑：

用户打开应收表单 / 运行并发程序，EBS 调用MO_GLOBAL.INIT初始化 MOAC 上下文；
根据职责上的MO: Security Profile，读取允许访问的 OU 列表存入 session 上下文multi_org2；
查询AR_TRANSACTIONS（同义词）时，VPD 自动追加动态 WHERE 条件：
- S 模式（单 OU）：WHERE ORG_ID = 当前上下文ORG_ID
- M 模式（MOAC 多 OU）：WHERE ORG_ID IN (允许访问的OU集合)

3.3 MOAC 会话上下文（核心命名空间 multi_org2）

-- 两个关键上下文变量 namespace: multi_org2 1. access_mode：'S'=单组织 / 'M'=多组织 2. current_org_id：当前操作的OU ID（M模式下可动态切换）

R11i 依赖CLIENT_INFO，R12 MOAC 废弃 CLIENT_INFO，改用 DBMS_SESSION 应用上下文。

3.4 MO_GLOBAL 标准核心 API（AR 开发必备）

-- 1. MOAC初始化（并发程序/自定义程序入口必须调用） MO_GLOBAL.INIT(p_appl_short_name => 'AR'); -- 2. 设置访问模式 -- p_access_mode: 'S'单OU，p_org_id传入组织ID MO_GLOBAL.SET_POLICY_CONTEXT(p_access_mode => 'S', p_org_id => 82); -- p_access_mode: 'M'多OU模式，清空current_org_id MO_GLOBAL.SET_POLICY_CONTEXT(p_access_mode => 'M', p_org_id => NULL); -- 3. 获取当前上下文OU MO_GLOBAL.GET_CURRENT_ORG_ID; -- 4. 判断当前是否MOAC多组织模式 MO_GLOBAL.IS_MULTI_ORG_ENABLED;

⚠️开发红线：自定义报表 / 接口访问 AR_XXX_ALL，必须先执行 MO_GLOBAL.INIT；禁止直接硬编码 WHERE ORG_ID；禁止直接 DML_ALL 表，优先调用 AR 标准 API。

四、AR 模块 MOAC 业务模型：对象、表、OU 隔离边界

4.1 AR 内哪些对象受 OU 隔离（ORG_ID）

✅按 OU 隔离（存在 ORG_ID）

应收事务：AR_TRANSACTIONS_ALL/AR_TRANSACTION_LINES_ALL
收款：AR_CASH_RECEIPTS_ALL
核销记录：AR_RECEIVABLE_APPLICATIONS_ALL
会计分配：AR_DISTRIBUTIONS_ALL
调整单：AR_ADJUSTMENTS_ALL
收款批、银行收款账户、事务类型、自动会计规则、AR 系统选项

❌全局共享，无 ORG_ID

TCA 客户主数据HZ_PARTIES（客户主体全局）
客户账户HZ_CUST_ACCOUNTS（账户全局）

⚠️ 关键区分：客户地点 HZ_CUST_SITES_ALL 带 ORG_ID！同一个客户，可以在 OU1、OU2 分别创建不同收款地点，实现 “集团客户，分 OU 独立交易”。

4.2 AR MOAC 最重要业务限制（极易踩坑）

MOAC 只解决【查看权限】，不能突破 AR 原生业务规则！

跨 OU 核销原生不支持OU A 收款（AR_CASH_RECEIPTS_ALL.ORG_ID=82）不能直接核销 OU B（ORG_ID=83）的发票；底层约束：AR_RECEIVABLE_APPLICATIONS_ALL核销记录强制收款与发票 ORG_ID 一致。 ✅ 解决方案：
- 使用公司间事务（Intercompany）；
- 或通过杂项收款 / 转账收款做 OU 间资金划转； Fusion AR 原生支持跨 BU 收款核销，这是和 EBS 最大差异。
收款归属固定 OU，创建收款时绑定 ORG_ID，无法跨 OU 移动收款
AutoInvoice 导入，每一批次单据必须归属同一个 OU；如需多 OU 导入，分多批执行。
AR 标准并发程序（Create Accounting、自动核销）默认在当前上下文 OU 内执行；想要跨 OU 批量处理，需要开发定制包装程序循环切换 MO 上下文。

五、AR Form 界面 MOAC 运行流程（应收工作台）

用户登录应收职责，职责配置MO: Security Profile→ 进入 M 模式；
打开Transactions Workbench / Receipts；
系统调用MO_GLOBAL.INIT('AR')；
界面弹出 / 顶部出现Operating Unit LOV 选择框；
用户选择 OU →MO_GLOBAL.SET_POLICY_CONTEXT('S',选中ORG_ID)；
VPD 动态过滤，仅展示该 OU 下发票 / 收款；
切换 OU 时，重新执行 SET_POLICY_CONTEXT 刷新上下文。

现象解释：若职责只有MO: Operating Unit（S 模式），界面看不到 OU 选择框，直接锁定单一 OU。

六、PL/SQL 开发标准模板（AR 接口 / 并发程序 MOAC 规范）

模板 1：并发程序标准 MOAC 初始化（单 OU 循环处理）

DECLARE v_org_id NUMBER := 82; BEGIN -- 1. 标准Apps初始化 FND_GLOBAL.APPS_INITIALIZE( user_id => 1234, resp_id => 5678, resp_appl_id => 222 ); -- 2. MOAC初始化（AR模块必须执行） MO_GLOBAL.INIT(p_appl_short_name => 'AR'); -- 3. 设置当前操作OU MO_GLOBAL.SET_POLICY_CONTEXT( p_access_mode => 'S', p_org_id => v_org_id ); -- 业务逻辑：调用AR收款/发票API -- AR_CASH_RECEIPT_API_PUB.CREATE_CASH_RECEIPT... EXCEPTION WHEN OTHERS THEN RAISE; END; /

模板 2：多 OU 循环遍历（共享服务中心批量报表）

-- 查询该Security Profile允许访问的全部OU SELECT org_id, name FROM hr_operating_units hou WHERE MO_GLOBAL.ORG_SECURITY(hou.org_id) = 1;

循环每一个 ORG_ID，循环内调用SET_POLICY_CONTEXT切换上下文，再查询 AR 表。

❌ 常见错误写法

缺少MO_GLOBAL.INIT，直接查询AR_TRANSACTIONS→ VPD 策略失效，返回全部 OU 数据；
直接查询AR_TRANSACTIONS_ALL不带过滤，绕过 VPD，存在数据安全漏洞；
API 创建收款 / 发票不设置正确 ORG_ID，导致单据归属错乱。

七、MOAC 与 AR 关键功能联动

7.1 AutoAccounting（自动会计）

自动会计规则按 OU 定义；MOAC 切换 OU 后，系统加载当前 OU 对应的自动会计配置。

7.2 Create Accounting（创建会计分录）

程序读取当前 MO 上下文 ORG_ID，仅处理该 OU 未生成会计的交易；想要跨 OU 生成会计，必须循环切换 MO 上下文。

7.3 TCA 客户模型协同

客户主体全局共享；客户地点绑定 ORG_ID（OU）；同一客户，可以为多个 OU 维护不同账单地址、收款条款、信用配置。

7.4 公司间应收 Intercompany AR

公司间交易依赖 OU 之间交易流（Transaction Flow）定义； MOAC 允许一个职责同时查询交易双方 OU 的发票，但不能直接跨 OU 核销。

八、MOAC 架构优缺点总结（迁移 Fusion 重要对比）

✅优势

支撑财务共享中心，大幅减少职责数量；
权限集中管控，通过 Security Profile 统一管理 OU 访问清单；
底层基于标准数据库 VPD，安全隔离可靠；
同一会话可动态切换 OU，无需重新登录。

❌固有局限（也是 Fusion 重构的动因）

MOAC 仅解决查询权限，无法突破 AR 业务层跨 OU 核销限制；
OU 和账套弱绑定，一个 Ledger 下可以多个 OU，但缺少统一全局收款池；
上下文基于会话，并发程序多 OU 处理需要手动循环切换；
配置复杂，容易出现 Profile 层级冲突（职责层 / 用户层 / 站点层优先级混淆）；
所有交易单据创建时刻永久绑定 ORG_ID，无法迁移 OU；
依旧是 “事务按 OU 割裂” 模型，与 Fusion BU 全局统一收款中心架构存在代差。

九、EBS AR MOAC VS Fusion AR BU 架构核心差异回顾（承接上一轮对话）

维度	EBS R12 AR MOAC(OU)	Fusion AR (Business Unit BU)
隔离单元	Operating Unit OU	Business Unit BU
访问控制	MOAC + VPD 上下文	安全配置 + 数据访问集
收款模型	收款归属单一 OU，禁止跨 OU 原生核销	全局收款中心，原生支持跨 BU 自动核销
组织与账套	OU 从属 Ledger，关系松散	BU 隶属于 Ledger，模型标准化
底层标识	ORG_ID	BUSINESS_UNIT_ID
表命名	AR_XXX_ALL	AR_XXX（无_ALL 后缀）
多组织访问	会话切换 OU 上下文	BO 层原生支持跨 BU 查询与处理