多组织、安全性、组织分配的R11和R12的异同

多组织接入控制在图30的EBS组织设置界面中，所谓的组织“类型〞〔Type〕划分仅是基于组织自身的统计分析工作需要而定义的一个“维度〞，例如“公司总部、产品线〞等等，并不影响系统的业务处理功能。真正起作用的是设置界面中的“组织分类〞〔Classification〕，系统预置的组织分类LOV除了上述“业务组、法律实体、业务实体、库存组织〞等之外，还有诸如“资产组织、运营公司、雇主〞等等选项。在EBS系统中各应用模块所具有的业务处理功能通常需构建在一个确定的“组织分类〞之上，“组织〞是相关业务处理功能的平台，企业是否需要作相关组织分类设置、如何设置，取决于企业所需要使用到的应用模块功能。例如所谓“资产组织〞的设置，它是在企业需使用到资产管理模块FA时才涉及到。“资产组织〞实际上是所谓“资产账簿〞的代名词，它只是表示有关资产信息的一个数据维度，作用主要在于分隔数据范围，用户进入系统作业务处理时，并不需要作上下文业务环境的切换。对于这类并不涉及“上下文〞环境切换的所谓“组织〞，ORACLR系统的设计主要是为了借用“组织〞所具有的“层次结构〞〔Hierarchy〕概念来到达“多组织接入〞权限的控制功能。需指出的是，这里的组织“层次结构〞与真实世界企业的行政管理组织层次结构没有直接关系〔尽管可能有所参考〕，它只是企业根据某种需要〔如权限管理控制、数据统计汇报等〕而人为设定的一个“层次结构〞，例如将系统中已经设置的任意数量的“业务实体〞或“库存组织〞等等组织Name，人为地设定一个具有上下级关系、自顶向下的金字塔形多层结构。如下列图31所示：上图中开始定义时，一旦选定〔最〕顶端组织Name，那么就只能为之分配下属组织Name，如要给下属组织分配更下一级的组织，那么需点击“向下〞按钮，将当前该下属组织上升到“顶端组织〞位置。点击“向上〞按钮，那么将当前“顶端组织〞下降到下属组织位置。企业可以根据实际需要设定假设干个具有不同内部结构的“组织层次结构〞Name，以供定义系统所谓“平安性配置文件〞时调用。如下列图32所示：上图所定义“平安性配置文件〞是系统用以控制包括“组织平安性〞等在内的各种平安性控制的根底，它具体规定了系统平安性控制的范围与实现方式，所有定义的“平安性配置文件〞Name构成系统多组织接入控制参数“MO：平安性配置文件〞的LOV。如下列图33所示：

EBS通过“MO：业务实体〞、“MO：平安性配置文件〞、“MO：默认业务实体〞这三个系统配置文件的共同作用，实现所谓“多组织接入〞控制功能MOAC。但上述三个配置文件在R11与R12中的作用有比拟大的差异。对于“MO：业务实体〞，在R11中必须设定，而且起决定性控制作用，其LOV由系统基于创立的OUname自动创立，用户登录时系统自动定位于指定OU。而在R12中，一旦设定“MO：平安性配置文件〞，那么此配置文件失效而不起作用。对于“MO：平安性配置文件〞，在R11中虽有，但实际不起OU接入的控制作用，只针对FA等模块的得某些应用如数据统计等起作用。因此，一般认为R11并不具有完善的多组织接入控制功能。在R12中，该参数如果不设定，那么必须设定“MO：业务实体〞参数；一旦该参数被设定，那么就起决定作用，系统主要依赖其实现MOAC。对于“MO：默认业务实体〞，在R11中虽有但实际不起作用。在R12中，随“MO：平安配置文件〞起作用后才起作用，其LOV是所有已定义OU，但如果设定值不在“MO：平安配置文件〞所选择的“组织层次架构〞的范围内，那么仍不起作用〔即在与OU相关诸如PO、OM等的FORM界面，OU字段的默认值仍然为空〕。这似乎是ORACLE系统设计方面的一个难题，即“MO：默认业务实体〞的LOV值集无法与“MO：平安性配置文件〞中“组织层次架构〞中的OU值范围保持一致。ORACLE强调其“多组织接入MOAC〞功能主要是针对业务实体OU而言，其另外一层含义是，所有构建于库存组织INV上的应用功能，实际是与上述配置文件无关的。库存组织的可接入性是在“组织访问〞控制功能中，专门设定“库存组织〞与“责任〞的关联性，如下列图34所示：

按照ORACLE的说法，如果系统在初始的时候，不定义库存组织的“组织访问〞控制，那么所有“责任〞可访问所有INV，一旦限制或分配其中一个，那么其余均必须逐个进行分配以建立“库存组织〞与“责任〞的链接关系。因此R12环境下多OU的设置为：定义组织架构及OU信息定义平安配置文件运行〞SecurityListMaintenanceProgram〞请求为用户职责分配〞MO:SecurityProfile〞预制文件的值为平安配置文件的定义为用