这是多组织访问的第二篇文章,翻译自Anil Passi的Multi Org R12
我们都知道,在Oracle Release 12中多组织模型(Multi Org)会被改变, 它被叫作多组织访问控制(Multi Org Access Control, MOAC). 我会告诉你做出这样改变的原因以及这将会如何的影响到你. 我也会告诉你如何一点也不影响到你现有的设置[如果你不想使用 MOAC- 多组织访问控制的话]
如果你对EBS R12中的多组织不宵熟悉的话,你可以先看EBS Multi Org 基础. 那会向你解释在R12中当前的多组织模型是如何工作的.请参考链接了解R12中的多组织访问控制 : Whitepaper on User Group Site
业务上这样改变的理由
-----------------------------------------
四年前,我被要求设计一个具有以下需求的应付票据(Payables Invoice)扫描程序:
1. 我的客户有100个以上的法人实体(legal entities)和组织单元(organization units).
2. 他们想在一个中心的地方收取所有的纸质应付票据. 更有效的, 对所有的法人实体/组织单元,所收到的票据都只有一个地址.
3. 所有的票据都在这个中心地方扫描.
4. 扫描的图像通过一个队列被班加罗尔的团队输入到系统中
这样,就出现了些问题:
--------------------------
扫描的票据首先应该根据Operating Uint来排序.
为什么呢? 因为, 对于每一个OU,都有一个不同的 "Payables Clerk" 的职责. 这个可怜的录入员要根据录入票据所属的OU来选择职责. 而且,你也不能强制的要求供应商以XML的形式来过账到你的系统中,所以录入员必须要保证每一张纸制的票据都被录入到正确的组织机构/OU中.
Oracle EBS Release 12 是如何来拯救他的呢?
在 R12中, 那个录入员不再是一个"可怜的录入员", 因为他不必再根据不同的法人实体来改变职责, 这就是Oracle EBS R12设计的强大之处,它迎合了当今共享服务解决方案的需求.
这是否就意味着应付录入职责能访问所有的OU呢?
如果你的业务有这样的需求,那么在R12中就能够做到这样,你可以把一个组织机构层次中的节点或者是Operating Unit列表赋予你的职责, 或者说,你现在可以给一个职责赋予多个Operating Unit,这可以通过组织机构层次或者组织机构列表.
这听起来非常像 HR Security Profiles, 我们可以看看链接 Oracle HRMS Security Profiles ?
是的,实际上R12中的Multi-org模型就是用的是Security Profiles. 如果你看了上面那个链接,你就会对HRMS中的Security Profile有一个更清晰的认识.
这就意味着,一个security profile会作为一个profile选项附加到职责中?
是的.
如果我不想实现这个增强的功能呢? 这会破坏我现有的多组织(multi org)设置吗?
Oracle在升级时有她的高明之处. 除非你启用了Security Profile的特性,否则你的Multi-org将会和R12以前的版本一样工作.
R12中的多组织访问控制依然会填充org_Id列吗?
当然,每一条数据依然和一个单独的org绑定.
我们能重用为HRMS定义的security profiles吗?
我建议你保持Multi-org Security Profile和HRMS Security Profile二者的独立性, HR Security Profiles 也迎合当今的潮流和不同的HR相关属性来保持一定的地位,但我们知道这一次Multi-Org将会胜出.
现在我们回去应付录入中,当录入一张票据时,他们是如何给每个票据指定一个正确的OU呢?
这是通过在窗口中输入OU项的值来实现的,在R12之前的版本中这个项是隐藏的,但是现在在所有用到多组织安全配置的窗体中这个值都是可输入的.
在R12中,用户会输入一个附加项吗?
不完全是,如果你想,你可以根据职责来指定一个默认的OU, 这也是在Profile中实现的.
这个Progile的名字是 [我目前还不知道], 但是它确实存在, 所以我才说了.
所以, 我们会有两个新的profile选项?
没错,一个是用于附加的Surity Profile,另一个用于默认的ORG.
运行dbms_client_info.set_client_info(101)后会发生什么?
这将成为一个冗余的功能,在R12中我们使用包mo_global,这个包在11.5.10中已经存在,而且如果你打开它,你会发现它用的是行级别的安全控制. 从技术上来说我认为 dbms_client_info.set_client_info 还会继续工作下去,但是如果你启用了MultiOrg Security特性后,这将产生无法估计的结果.
这将会如何影响我的客制化?
声明 1 :- 如果你对client-info进行硬编码,那很显然的将不能继续工作
声明 2 :- 同样的, 如果你过去用fnd_profile.org_Id, 那将也不能工作.
如果你决定不在R12中启用多组织访问控制(Multi Org Access Control)的话,那么以上两个声明则不成立.