Oracle EBS R12 AR 模块 MOACMulti-Org Access Control完整深度解析一、MOAC 诞生背景与设计哲学1. R11i 多组织痛点理解 MOAC 价值的前提R11i无 MOAC采用单 OU 绑定职责模型一个职责只能绑定单一 OUMO: Operating Unit财务共享服务中心人员处理多 OU 业务必须频繁切换职责底层依靠CLIENT_INFO存放 ORG_ID视图AR_TRANSACTIONSAR_TRANSACTIONS_ALL WHERE ORG_ID 传入ID无法在同一职责下跨 OU 查询、批量处理交易。2. R12 MOAC 核心设计目标单一职责访问多个 Operating UnitOU支撑集团财务共享服务SSC。顶层架构分层EBS R12 组织层级AR 直接依赖Business Group业务组HR顶层 ↓ Legal Entity法人实体 ← Ledger/Set of Books账套 ↓ Operating UnitOU 运营单元← AR/AP/OM核心业务隔离维度✅AR 视角关键定义Ledger账套法人会计主体会计科目、本位币、会计日历全局共享主数据无 ORG_ID 隔离OUOperating Unit业务运营隔离单元应收发票、收款、核销、客户地点、事务类型、自动会计、系统选项全部按 OU 隔离MOAC控制同一职责可以访问一组 OU 集合实现 “单职责多 OU 操作”。核心哲学一句话OU 负责业务数据隔离MOAC 负责权限访问控制账套负责会计主体隔离。二、MOAC 三大核心配置文件AR 日常最重要R12 淘汰 R11i 单一MO: Operating Unit三个配置互斥 / 优先级明确配置文件作用生效模式AR 业务表现MO: Security ProfileMO 安全性配置文件定义该职责可访问全部 OU 清单多 OU 模式M 模式优先级最高Form 界面出现 OU 选择 LOV可切换 OU 录入发票、收款MO: Default Operating UnitMO 默认业务实体多 OU 模式下表单打开默认选中的 OU配合 Security Profile 使用打开应收工作台默认带出指定 OUMO: Operating UnitMO 业务实体兼容 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-StripingORG_ID 条纹隔离AR 所有业务表统一命名规范XXX_ALLAR_TRANSACTIONS_ALL、AR_CASH_RECEIPTS_ALL、AR_RECEIVABLE_APPLICATIONS_ALL、AR_DISTRIBUTIONS_ALL所有交易行强制携带 ORG_ID标记该单据归属哪个 OUAPPS 下同义词AR_TRANSACTIONS AR_TRANSACTIONS_ALLR11i 的视图被废弃。重点_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 模式单 OUWHERE ORG_ID 当前上下文ORG_IDM 模式MOAC 多 OUWHERE ORG_ID IN (允许访问的OU集合)3.3 MOAC 会话上下文核心命名空间 multi_org2-- 两个关键上下文变量 namespace: multi_org2 1. access_modeS单组织 / M多组织 2. current_org_id当前操作的OU IDM模式下可动态切换R11i 依赖CLIENT_INFOR12 MOAC 废弃 CLIENT_INFO改用 DBMS_SESSION 应用上下文。3.4 MO_GLOBAL 标准核心 APIAR 开发必备-- 1. MOAC初始化并发程序/自定义程序入口必须调用 MO_GLOBAL.INIT(p_appl_short_name AR); -- 2. 设置访问模式 -- p_access_mode: S单OUp_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_IDTCA 客户主数据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_ID82不能直接核销 OU BORG_ID83的发票 底层约束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 UnitS 模式界面看不到 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_IDOU 同一客户可以为多个 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 OUBusiness Unit BU访问控制MOAC VPD 上下文安全配置 数据访问集收款模型收款归属单一 OU禁止跨 OU 原生核销全局收款中心原生支持跨 BU 自动核销组织与账套OU 从属 Ledger关系松散BU 隶属于 Ledger模型标准化底层标识ORG_IDBUSINESS_UNIT_ID表命名AR_XXX_ALLAR_XXX无_ALL 后缀多组织访问会话切换 OU 上下文BO 层原生支持跨 BU 查询与处理