我的网站,欢迎您的光临！
当前位置： >
Oracle ERP：EBS功能结构分析
编辑：admin
Oracle ERP
&&& Oracle提供的ERP产品名为EBS，即Oracle E-Business Suite，是ERP领域名声很大的商用软件之一。
&&& Oracle ERP于1998年面世，此后，甲骨文公司总共推出了6个增强版本，到目前为止已经是一套成熟的、功能齐全的应用套件。随着云计算时代的到来，EBS的12.2版本估计也会在今年推出，12.2版本主要是为了适应云计算的发展，在应用技术和架构上可能会有所改变。
&&& 追溯历史，2006年，甲骨文发布了EBS 12.0版本，2008年发布了12.2版本，到目前为止，12.2的Beta版本已经出来了。
&&& Oracle EBS 是一组适用于整个企业的综合性业务应用产品，完全在 Internet 上运行。EBS 对内部流程的支持扩展到了企业之外，包括客户、供应商和其他贸易伙伴。可以在产品开发、计划、采购、订单履行和其他业务流程的早期就与客户和供应商进行协作，还可以与合作伙伴共享设计、预测、订单和交货状态等实时信息。另外，将企业与客户和供应商相关联，有助于企业了解全局动态，并实现业务信息的双向流动。
&&& Oracle EBS可在一个数据库中支持多种语言、所有币种和多种法规要求。可以在同一个 Unicode 例程中安装所有的语言。贸易伙伴可以按其选择的语言接收业务文档，用户可以使用其选择的格式查看和输入日期、数值和币种。
&&& Oracle EBS是一个综合性企业应用产品集，它是根据一个公用的数据模型集成而来的。通过 OracleEBS的统一信息结构，来自 Oracle 应用产品和非 Oracle 应用产品的数据合并在一起，这样客户、供应商、合作伙伴、员工和所有业务实体便可以在整个企业中使用一致的定义。可以创建一个全局定义，允许所有人（全局范围）访问相同的数据。使用单一的公用数据模型，可确保所有应用产品间的信息和事务处理流程都是准确且一致的。
评论列表（网友评论仅供网友表达个人看法，并不表明本站同意其观点或证实其描述）
本类排行榜ORACLE EBS 系统主数据管理（B）
ORACLE EBS 系统主数据管理
二、物料（Item）
（三）Item
的类别（Category）
（四）Item的单位（UOM）
&&&&&& （五）Item
的制造商部件号（MPN）
（六）Item的版本（Revision）
（七）Item的组织控制（Master
（八）Item的属性及相互关系概述
（九）Item的属性内容简介（Attribute）
（十）Item的属性快查
（十一）Item的客户与供应商关系
（十二）Item的物料关系（Relationship）
（十三）Item的交叉参考（Cross Reference）
（十四）Item 创建的模板（Template）
（十五）Item的目录组（Catalog Groups）
（十六）Item的待定状态（Pending Status）
（十七）Item
的属性组织间查看与复制
（十八）Item的删除
（十九）Item的其它来源方式
三、供应商（Supplier）
（一）供应商的分类概述
（二）供应商“名称与编号”（Supplier
Name/Number）
（三）供应商的“地点”（Site）
（四）供应商的“分类”属性（Classification）
（五）供应商的“接收”属性（Receiving）
（六）供应商Site层的“一般”属性
（七）供应商Site层的“联系人”属性
（八）供应商的多组织支持（MOAC）
（九）供应商（Site）的“采购”属性
（十）供应商（Site）的“控制”属性（Control）
（十一）供应商（Site）的“付款”属性（Payment）
（十二）供应商（Site）的“会计”属性
（十三）供应商（Site）的“银行账户”属性
（十四）供应商（Site）的“发票税”属性
（十五）供应商（Site）的“预扣税”属性
（十六）供应商（Site）的“纳税申报”及“EDI”属性
（十七）R12的供应商定义与维护
（十八）供应商的合并
四、客户（Customer）
（一）客户数据管理概述
（二）EBS 交易社区架构（TCA）
（三）客户的配置文件分类（Profile
（四）客户的创建规则
（五）客户的多组织控制（MOAC）
（六）客户的交易方层属性及交易方关系
（七）客户的账户层与地点层属性
（八）客户账户层的“分类”分组属性
（九）客户账户层的“市场营销”分组属性
（十）客户账户层的“关系”分组属性
（十一）客户账户地点层的“特性”分组属性
（十二）客户账户与地点层的“通信”分组属性
（十三）客户账户与地点层的“联系人”分组属性
（十四）客户账户与地点层的“联系人：职责”分组属性
（十五）客户账户与地点层的“银行账户”分组属性
（十六）客户账户与地点层的“付款方法”分组属性
（十七）客户账户与地点层的“配置文件：事务处理”分组属性
（十八）客户账户与地点层的“配置文件：单据打印”分组属性
（十九）客户账户与地点层的“配置文件：金额”分组属性
（二十）客户账户的“地址地点与业务目的”属性
（二十一）R12客户的账户层与地点层属性
（二十二）客户数据的合并
（二十三）客户数据的其它管理功能
（三）Item 的类别（Category）
上面所讲到的Item编码中的分类（UNSPSC），一般来说还不是系统（各应用功能模块）中真正使用到的类别，原因是编码中的分类所基于的分类基准（或用途）主要考虑的是“工程”目的，而各应用模块例如INV、PO等中所需使用的分类更多地是需考虑业务管理目的，这就好比我们将“人员”分类，有时需按“性别”（男、女）分，有时需按“学历”（博士、硕士、学士）分，有时还需按“年龄段”（老年、中年、青年）分等等。
对于EBS中一个确定的Item来说，可以同时具有多个不同的“类别集（Category Set）”，以满足各个应用模块的使用需要。这里之所以称其为“类别集”，源于其中包含若干个LOV值，系统将每个具体的LOV值称之为“类别”（Category）并最终分配给Item。EBS的每个相关应用模块必须设定默认关联一个“类别集”，称之为“默认类别集”。如下图6所示：
<img id="uchomelocalimg[]" alt="系列之五：ORACLE EBS 系统主数据管理（B） - season - season" src="/upload//40.jpg">
不同应用模块所使用的“默认类别集”可以相同也可以不同。用户在进入相关业务模块的“表单”界面时，打开的Item类别的弹性域结构取决于“默认类别集”所关联的类别键弹性域结构定义。在“≤ORACLE系统与实践≥系列之三：EBS的基础设置要点简介”中，关于“Item类别弹性域结构”的介绍已经说过，系统安装初始化时，ORACLE已经基于“业界最佳实践经验”，预设了若干不同的“类别弹性域结构”，这些不同弹性域结构同样也被ORACLE在“默认类别集”定义界面中预设了相应的关联（上述系统安装预设，用户如不满意，均可以修改）。这无疑大大方便了用户的使用，也正是ORACLE产品包含丰富管理思想的体现所在。
对于每一个被使用的“类别集”，需要进行定义或对系统预设进行修改完善，每个类别集关联一个已经预先定义编译的“类别键弹性域结构”。如下图7所示：
<img id="uchomelocalimg[]" alt="系列之五：ORACLE EBS 系统主数据管理（B） - season - season" src="/upload//01.jpg">
上图7中，如果选定“允许存在多个物料类别分配”，则可以将一个物料分配给某个类别集内的多个类别。这主要是用于某些特殊功能的情况，如“装箱”功能中的“创建装箱组”，定义一个“危险”类别集，将某个物料同时分配给“毒药”和“腐蚀物”类别。
上图7中，如果选定“强制使用有效类别列表”，则需要对其下的“类别列表”进行维护，其作用主要是控制PO界面的类别的LOV值（选择组合）只能存在于这里的定义列表中时才有效（否则会报错提示）。
上图7中的“人员类别”窗口的作用，是为了控制某些类别只允许特定“责任/人员”才可以访问（未设定则不做限制）。上图中的“分配”窗口，只是提供一种将多个“类别”快速成批分配给（包括维护）多个Item的工具。在单个Item定义时分配类别的结果，会显示在这里，这里所做的维护改变也会反映在定义Item时的分配类别界面中。如下图8所示为Item定义时的类别分配界面：
<img id="uchomelocalimg[]" alt="系列之五：ORACLE EBS 系统主数据管理（B） - season - season" src="/upload//02.jpg">
此外，为进一步控制上图7与图8中定义或设置时具体类别Category组合的实际可用性（在弹性域定义中可能已经通过值集验证进行设置，这里提供补充控制功能），系统通过专门的定义类别可用性功能，内容包括是否启用、是否为i-Procurement启用（仅适用于R11）、供应商是否可查看（用于i-supplier）、Web申请是否可用，来根据实际业务需要对Category的可能代码组合做更为细致，也更为灵活的限制。如下图9所示：
<img id="uchomelocalimg[]" alt="系列之五：ORACLE EBS 系统主数据管理（B） - season - season" src="/upload//43.jpg">
总之，EBS中的Item 的类别Category非常关键、非常重要，系统的其它相关功能如权限控制、审批设置以及费用账户等等（以后在相关应用功能模块中再详细讨论）均会基于物料定义时的Category设置来进行，它与所谓物料的“Commodity管理”相结合，提供了企业业务管理所需的强大系统功能，是“业界最佳实践经验”的总结与结晶。
（四）Item的单位（UOM）
&&&&&& 在“≤ORACLE系统与实践≥系列之三：EBS的基础设置要点简介”中，关于“单位设置”的介绍已经说过，EBS的单位及其换算关系是定义在INV组织之上并且可以与特定物料相关的。在Item定义中，可以为之指定“主要单位”（Primary）与“辅助单位”（Secondary），并且规定两者换算所允许的偏差系数（Deviation Factor）。这主要是为了满足实际工作中某些特殊物料的特殊计量需求，某些液态的化工原料如乙醇、汽油等，计价、储存可能是按吨、公斤或桶来计量的，但实际使用则可能是按“升”来计量，例如国内加油站进货按吨计，给车加油时按升计。由于两者的换算关系可能受不同场合“温度、压力”等因素的影响，实际计量与原先“标准”条件下定义的换算关系存在一定偏差。系统对于所产生的这种偏差必须有明确的规定。
&& 在EBS的Item定义中，在“主要”（Main）标签页（Tab），针对单位（UOM）主要是就库存余额数量的“跟踪”（Tracking）、产品定价（Pricing）的计量，如何进行事务处理做了规定，如下图10所示：
<img id="uchomelocalimg[]" alt="系列之五：ORACLE EBS 系统主数据管理（B） - season - season" src="/upload//44.jpg">
&&& 上图10中的几个字段“跟踪、定价、辅助、默认、正负偏差系数、转换”的取值关系颇为复杂，建议参考ORACLE相关官方文档（INV UG）。其中的一个可能结果是，只要手工输入的辅助单位的计量实际值与主要单位的计量值的实际换算关系在规定的偏差范围内，系统均当成标准换算关系进行处理，这对于库存数量余额的准确跟踪及产品正确定价将十分重要。
（五）Item 的制造商部件号（MPN）
&&&&& 前面在讲Item编码时已经提到，EBS中的一个Item可以对应多个制造商的MPN，这是所谓物料的“Commodity管理”的重要内容。要做到这一点，在EBS中首先需定义制造商及其MPN的值。如下图11所示：
<img id="uchomelocalimg[]" alt="系列之五：ORACLE EBS 系统主数据管理（B） - season - season" src="/upload//45.jpg">
&&&&注意，不要将制造商（Manufacturer）与系统中的供应商（Supplier）混为一谈。制造商有可能也是供应商，但在系统中两者是分开设置的，没有连接关系。上图11中的制造商列表值是直接手工输入的，每一个制造商在“部件”（Parts）界面需要手工输入该制造商的“部件号”并与系统Item相关联。这里的Item与MPN的关联定义也可以在Item定义显示和维护，如下图12所示：
<img id="uchomelocalimg[]" alt="系列之五：ORACLE EBS 系统主数据管理（B） - season - season" src="/upload//46.jpg">
&&&&&上图12中MPN设置的制造商取值，不可以手工输入，只能以图11的定义制造商列表作为其LOV，但“部件”字段可以手工维护，其作用与图11中的“部件”设置界面相同。
（六）Item的版本（Revision）
&&&&& 物料的版本管理对于实际业务及系统管理都是一项基础性工作，EBS在Item的定义界面提供了物料的版本维护功能。如下图13所示：
<img id="uchomelocalimg[]" alt="系列之五：ORACLE EBS 系统主数据管理（B） - season - season" src="/upload//97.jpg">
&&& 系统使用字母、数字和字符（如 *、& 和 #）来标记版本。其中字母必须大写，数字可以包括小数点。为确保版本正确地排序，小数点后应该使用数字。有效版本包括：A、B、 01、 02、 A1、 B1、1A、1B、0.0、 0.1、A.0、 A.1 等。版本按 ASCII 规则进行排序，每个版本号必须高于它的上一版本。按照 ASCII 排序规则，10 排在 9 的前面，因此在版本 9 之后不能使用版本 10 来定义下一版本。
&&& 除了在Item定义窗口维护版本信息外，EBS系统在物料清单（BOM）及工程更改单（ECO）也可以对Item的版本进行维护，维护的结果在三处的最终显示是相同的。
（七）Item的组织控制（Master Org）
&&& 前面关于Item的一些基本概念的介绍，均没有涉及Item的组织控制问题。ORACLE的Item定义是基于INV组织的，这是其早期有关“主数据”管理的一个重要特点。以前，另外两个主数据“客户、供应商”也是基于确定的组织（OU）来定义设置的，但从R12开始，客户与供应商的初始定义已经开始独立于组织（OU，上下文环境）来进行，然后再分配给相关组织（OU）使用。
&&&& 既然客户与供应商的主数据系统管理方式已经做了调整，为什么Item的主数据管理方式却保持不变呢？推测的原因可能是，一来Item的影响面太广，改动太大，不方便进行；二来原Item的主组织（Master Org）定义方式也有其独到的优势，它在处理一些实际与库存事务关系不大的“服务类或费用类”Item的工作过程中比较方便，例如PO在做服务类或费用类Item的接收时，可以直接基于“主组织”（可能是虚拟的，并不与管理实体对应）来进行，可以与库存类的Item的接收方式保持一致，无需另外做特殊考虑。
&&& &在ORACLE EBS系统中，系统虽然允许设定多个“主组织”来定义Item，然后再将Item分配给多个INV组织使用，但ORACLE强烈建议系统只设定唯一的主组织，而这一点与实际工作中的“主数据”集中管控的要求也是一致的。当在系统中设置INV组织时，在INV组织参数窗口的“物料主文件组织”字段，可选的LOV值包括当前INV名本身，以及已经被其它INV设定为“主组织”的INV名。一旦用户选定当前INV名作为主组织，则在设置其他INV的组织参数时，也可以在主组织可选LOV值中见到它。
EBS的“主组织”使用是不受帐套（科目弹性域结构）、业务实体的范围限制的，具有不同帐套/业务实体的INV可以具有同样的Item主组织。“主组织”的这一特性为大型企业Item的集中管控工作的开展提供了极大的方便性与高度的灵活性。用户在进入INV模块（或其他基于INV的应用模块）时，均需选择一个确定的INV，以进入确定的INV上下文环境。一旦进入INV，则其Item的主组织就已经唯一确定（由该INV组织的参数定义决定）。被选定作为“主组织”的INV作为“业务功能”组织使用时，与其它INV并无任何区别。唯一的特殊之处在于，定义主组织Item时，在“组织分配”界面无需再向“组织层”的自己作分配（系统已经默认分配），但有关“属性控制”的设置，仍然与其它被分配的INV组织完全一样。如下图14是Item定义中的“组织分配”界面：
<img id="uchomelocalimg[]" alt="系列之五：ORACLE EBS 系统主数据管理（B） - season - season" src="/upload//38.jpg">
所有Item均只能在其“主组织”界面（并非指必须进入主组织所在的上下文）定义后，才能分配给相关的INV组织使用。上图14中可以分配的INV列表取决于每个INV组织参数定义的“主组织”与当前INV（上图14中的第一行）的“主组织”是否相同。除了当前INV组织，其余INV组织的“组织属性”窗口均可以另外打开（当前INV组织的组织属性窗口实际已经打开，在Item定义界面的“组织”与“主组织”间直接切换），以便定义属于本组织的相关属性。
EBS系统在Item的“主组织”（Master Org）与组织（Org）之间，提供了相关“属性”如何控制的机制。如下图15所示：
<img id="uchomelocalimg[]" alt="系列之五：ORACLE EBS 系统主数据管理（B） - season - season" src="/upload//69.jpg">
上图15中，组名字段会显示属性组的名称。属性按功能分组，例如主要、库存和接收。在定义或更新物料、定义模板或查看物料属性时，可以显示特定组的属性，这样可以更容易地查找特定属性。“控制地点”可以在“主层”与“组织层”间选择。主要层：在主要层定义和维护此属性，对于同一物料，此属性的值在所有组织中均相同；组织层：在组织层定义并维护此属性，对于同一物料，每个组织均可为此属性定义一个不同的值（某些属性只能在特定层设置，在这些情况下，只具有一个选项）。
对于某些“状态属性”，系统除提供“主层”与“组织层”的控制地点选择外，还提供“状态设置”控制方式的选择：“默认值、不使用、设置值”。这需要与前文所述“物料状态”的控制方式的设定结合使用。可以设置控制方式的“状态属性”共10个（如图4中所示），包括：允许BOM、在WIP中制造、启用客户订单、启用内部订单、启用开票、启用执行流程（应用于“流程制造”）、启用配方（应用于“流程制造”）、可采购、可储存、可处理。Item的状态属性与其它属性或相互之间可能有一定的制约关系。例如，如果将库存物料设置为否，则不能将可储存设置为是。
（八）Item的属性及相互关系概述
物料Item广泛使用于企业实际工作中的方方面面，为了达致业务流程运作的规范化、标准化、自动化，实现企业“实物流、资金流、信息流”的统一，就必须在系统中对Item的相关流程属性作统一的、预先的设置。它是企业管理实践与业务流程运作如何实现“集中统一”的典型体现，是管理信息系统具有强大功能与高度灵活性的核心基础。因此，它也是系统实施与应用的关键步骤。
EBS的Item可定义（或必需定义）的属性值总数多达300多个，为了方便对这些属性的管理，EBS按属性的“流程功能”进行了分组，目前一共分为17个属性组（即Item定义界面的Tab标签页），包括“主要、库存、物料清单、资产管理、成本计算、采购、接收、物理属性、总计划、MPS/MRP计划、提前期、在制品、订单管理、开票、流程制造、服务”。
这些Item的属性分组（Tab页）大体上与系统的应用模块有一定的对应关系，相关业务模块使用时，有关Item的基础设置主要与相对应的属性Tab页内容有关。
每一个属性组有若干可定义属性值（字段），其中一部分属于“必需项”（一般均有默认值，可修改），另一部分则属于“可选项”（可留空）。一部分是属于“业务控制”属性，可以直接用于控制系统中的相关业务操作，如“可采购、可储存”等等，另一部分则是属于“流程控制”属性，可以直接或间接控制所使用的具体业务流程种类或方式，例如“计划方法、BOM物料模型”等等，还有部分属于“参考引用”属性，主要是向有关单据提供默认的参考值。某些属性之间具有确定的关联性，一旦定义了其中一个值，其余相关属性的值也就随之确定。关于属性间相互关系的具体内容，比较复杂，必须仔细参考ORACLE相关应用文档（如下述各表，仅供参考）。这些特定属性间的特定关系分为四大类：
（1）要求的属性值：
如果某些相关属性具有下表所示的值，则必须输入特定属性的值：
需求时间范围天数
将需求时间范围设置为自定义
保留款帐户
将“冲销保留款”参数设置为是
将库存资产值设置为否并将库存物料设置为是
外协加工单位类型
将外协加工物料设置为是
计划时间范围天数
将计划时间范围设置为自定义
发放时间范围天数
将发放时间范围设置为自定义
重复性计划
将 MRP 计划方法设置为 MPS 计划或 MRP 计划
服务延续期间不为 NULL
储存期限天数
将批次到期（储存期限）控制设置为物料储存期限天数
将补充来源类型设置为库存
将批次控制设置为全部批次控制
起始批前缀
将批次控制设置为全部批次控制
起始序列号
将序列号控制设置为预定义序列号
起始序列前缀
将序列号控制设置为预定义序列号
（2）相互关联属性
特定属性值取决于其它属性值。例如，如果挑库组件设置为是，则计划方法必须是未计划。以下是属性之间的相互关联：
按订单装配
将挑库组件设置为是或将 BOM 物料类型设置为计划
按订单装配或挑库组件
将 BOM 物料类型设置为模型或选件类
“挑库组件”为否、“按订单装配”为否但“WIP 供应类型”不为虚拟件
“BOM 物料类型”不为标准或 将“挑库组件”设置为是。
将“库存物料”设置为否
在 WIP 中制造
将“库存物料”设置为否或 BOM 物料类型不为标准
将“容器”设置为否
启用成本计算
将“库存资产”设置为是
将“BOM 物料类型”设置为计划
启用客户订单
将“客户订购”设置为否
需求时间范围天数
“需求时间范围”不为自定义
“BOM 物料类型”不为标准
启用内部订单
将“内部订购”设置为否
将“容器”和“运载工具”均设置为否
将“可开票物料”设置为否
提前期批量
将“重复性计划”设置为是
最大装载重量
将“容器”和“运载工具”均设置为否
最小装载百分比
将“容器”和“运载工具”均设置为否
将“按订单装配”设置为是或将“BOM 物料类型”设置为计划或“计划方法”不为未计划
将“模型完工发运”设置为是
计划时间范围天数
“计划时间范围”不为自定义
将“挑库组件”设置为是
后加工提前期
将“制造或采购”设置为制造
将“采购物料”设置为否
发放时间范围天数
“发放时间范围”不为自定义
未将货位限制在预定义列表中
将“限制子库存”设置为未将子库存限制在预定义列表中
未将货位限制在预定义列表中
将“库存货位控制”设置为动态输入货位控制
限制子库存
将子库存限制在预定义列表中
将“限制货位”设置为将货位限制在预定义列表中
可服务产品
将“支持服务”设置为是
将“BOM 物料类型”设置为计划
将“库存物料”设置为否
库存货位控制
无货位控制或未预指定货位控制
将“限制货位”设置为将货位限制在预定义列表中
将“可服务产品”设置为是
将“可储存”设置为否
（3）可更新的属性
可以在特殊情况下更改某些属性值。下表显示了可更新的属性和更改这些属性值时应具备的条件：
“按订单装配”为是，或“挑库组件”为是或“WIP 供应类型”为虚拟件
BOM 物料类型
“物料清单”存在或作为 BOM 的组件存在，或作为标准 BOM 的替代组件存在。例外：可根据组件和替代组件的产品系列进行更改。
启用成本计算
不存在现有量
需求时间范围天数
“需求时间范围”为自定义时间范围
库存资产值
不存在现有量
不存在现有量
不存在需求
未完成销售订单行包含一个不同于新值的值
外协加工部件
“采购物料”为是
计划时间范围天数
“计划时间范围”为自定义时间范围
发放时间范围天数
“发放时间范围”为自定义时间范围
重复性计划
未按 MRP 计划
不存在需求
不存在现有量
未完成销售订单行包含一个不同于新值的值
序列号控制
不存在现有量
储存期限控制
不存在现有量
未完成销售订单行包含一个不同于新值的值
（4）控制层相关性
只能在特殊情况下更改某些属性的控制层，否则会产生特定结果。下表显示了某些属性和在特定条件下可更新的控制层以及更改控制层所产生的结果。
物料状态 &
任何子组织中都不存在待定状态
将更新状态控制或默认控制下的所有状态属性
库存资产值或启用成本计算
具有已定义 WIP 参数的组织将使用其本身作为成本计算的主组织（在定义 WIP 参数时不能与成本计算的不同组织相关联）
物料成本在组织间是相同的
库存资产值
主层或组织层
“启用成本计算”将更新为同一层
所有物料定义属性
在“组织层”维护功能区域的默认类别集
文章评论 以下网友留言只代表其个人观点，不代表本网站的观点和立场。ORACLE EBS-组织架构介绍 -五星文库
免费文档下载
ORACLE EBS-组织架构介绍
导读：ORACLEEBS-组织架构介绍，（四）库存组织（INV），（六）HR组织，（七）多组织接入控制，“组织”（Organization）一词是个经常需用到的概念，企业内部行政组织（部门）的划分是企业基于“职能驱动”业务管理模式进行运作的基础，国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，实际上就已经基本反映了企业运作的“组织职能”划分问题，管理软件使用与实施的系统“组
ORACLE EBS-组织架构介绍
（一）业务组（BG）
（二）法律实体（LE）
（三）业务实体（OU）
（四）库存组织（INV）
（五）公司成本中心（Cost Center）
（六）HR组织
（七）多组织接入控制
在企业管理实践的过程中，“组织”（Organization）一词是个经常需用到的概念，一般与“人员”与“职能”这两个要素密切相关，反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等。企业内部行政组织（部门）的划分是企业基于“职能驱动”业务管理模式进行运作的基础。目前，国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的“组织职能”划分问题。
但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题。一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。这种系统实现方式虽有理解、掌握比较容易的优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。国内有所谓高端管理软件在系统实施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况”，导致系统几乎没法使用的困境，其症结正在于此。
与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。作为ERP鼻祖的SAP将系统组织简单地分为“集团（Client）、公司代码（Company Code）、采购组织（Purchase Org）、销售组织（Sale Org）、工厂（Plant）”等类别。ORACLE的组织设置本质上与之基本相似，但作为后来者作了进一步抽象与简化，系统组织划分为“业务组（Business Group）、法律实体（Legal Entity）、业务实体（Operating Unit）、库存组织（Inventory Org）”等。 如果说SAP的组织模型字面上多少还带有一点“行政组织”痕迹的话（这可能是某些声称学SAP的国内产品误入歧途的原因），ORACLE系统的组织模型字面上已经几乎看不出与“行政组织”还
有什么关系，其中的“Inventory Org
”现今中文翻译成“库存组织”，容易令人望文生义和企业的“仓库管理部门（Warehouse）”混淆，但Inventory的本义实际应该是“存货”，称之为“存货组织”或许更好一些。如下图22所示ORACLE系统有关核心业务的多组织模型：
上图中的“财务、销售、采购”并非系统的“组织实体”，它仅表示业务实体（OU）具有的相关业务处理功能。“子库”是特殊的系统组织实体，没有上下文环境可进入，主要表示库存组织之下的某种业务功能。
（一）业务组（BG）
“业务组”的概念可以与企业的“集团”概念参看，但不同的是一个企业在系统中可以设置多个“业务组（集团）”。通常对于一个企业来说，系统中有一个“业务组”就够了，这表示企业就是一个“集团公司”。而对于某些业务“多元化”的特大型公司（如跨国公司），则可能需要在系统中设置多个“业务组”，表示企业由多个“集团公司”组成。
业务组设置是系统组织设置的第一步，是最高层级的组织形态，但它主要是与人力资源信息的分隔有关，即“人
员信息”的设置在一个BG范围内是由各业务模块共享的（如果需要）。一旦系统设置的用户名（User）被与“人员”（Employee）关联，无论使用什么“责任”进入系统，都会定位至一个确定的BG中，任何责任在任意时刻只能关联一个BG。EBS安装好后，系统里面已经预置了一个名为“Setup Business Group”的“初始业务组”。如图23所示系统预置的“Setup Business Group”：
当以系统预置超级用户SYSADMIN进入后，应首先设置一个具有在HRM或INV下创建组织功能 的“责任”名，随后给此责任的“HR：User Type”配置文件设定值为“HR User”，则该责任就有了创建新BG的能力。通常需要一次性将企业所需要的BG全部建立，一般另创建一个与企业名称一致如“某某集团”的新BG就可以了，也可以（不推荐）直接使用系统预设的“Setup Business Group”而不创建新BG。
系统每新建一个BG，就会自动在配置文件“HR：安全性配置文件”的LOV中自动添加一个与新建BG同名的可选值（初始时只有“Setup Business Group”一个值）。在某一个BG下（初始为Setup Business Group）新建的任何责任，系统都将该责任的配置文件“HR：安全性配置文件”值
默认为当前BG。要在进入系统时能切换到新的BG，必须先修改该责任的“HR：安全性配置文件”设定值。
如果将配置文件“HR：交叉业务组”的值设为“是”，则在不同BG下，新建的组织名称应当（虽然可以）不同，否则查看时可能会引起混淆。在同一个BG下的所有新建组织，名称不允许相同。
（二）法律实体（LE）
法律实体（LE，Legal Entity）对应于真实世界中的按国家法律法规要求注册的“法人公司”。在R11中，LE在组织FORM定义时，对于每个LE必须为其“法人主体会计科目”关联一个“帐套SOB”。每个LE对应一个SOB，这与真实世界的法规要求是吻合的。如下图24所示：
要注意的是，在R11中定义的LE时，并未作与“会计科目弹性域结构”的“公司段”值关联，用户必须对于其是与公司段值中的哪个值对应心中有数。而在R12中，LE的组织定义虽在FORM中仍然保留，但LE的“法人主体会计科目”的FORM设置被废弃（故FORM中定义了也无用），改
包含总结汇报、IT计算机、党团工作、旅游景点、工作范文、文档下载、人文社科、出国留学以及ORACLE EBS-组织架构介绍 等内容。本文共5页
相关内容搜索
