ORACLE--ERP--基础设置要点介绍.doc

1、ORACLE ERP 基础设置要点简介首先需要说明的是，本系列文档假定读者已经具备基本的系统相关使用知识与技能(例如，能够基本领会“ORACLE EBS 系统应用基础概述 ”中的内容) ，故所讨论的内容仅限于笔者认为从系统使用与实际业务两方面来看比较重要或者容易存疑的问题，并不能面面俱到，旨在帮助读者掌握核心、抓住要点（详尽内容必须参考 ORACLE 相关官方文档）。文中为讨论需要所附图文均取自 ORACLE EBS 的测试环境（Vision Demo），版本以 R12.1.1 为主，辅之以版本 R11.5.10，界面语言主要为中文（必要时辅之以英文）。两个 EBS 版本在界面与功能应用方面实

2、际可能有一些差异，必要时会作相关说明，但一般不会影响对基本问题的讨论。技术是业务的抽象与工具，业务是技术的来源与目的。本系列文档通篇将秉持“从业务的角度去审视技术，从技术的角度去回归业务”的方法论（这里的所谓“技术”，意指“系统实现”），去探讨系统实现与业务实践的融合问题，以求逐步能达到技术与业务的融会贯通。限于笔者的认知水平，有讹误或不正确之处，欢迎批评指正。一、安全性管理从系统使用角度来看，系统管理的一项重要的日常工作是关于“用户”及其“权限”的管理，在ORACLE 中即所谓 “安全性” （Security）管理。“安全性 ”是一个涵义较之“权限”更为丰富、更为广阔的概念术语，它虽然比较抽

3、象，但顾名思义，它很好地涵盖了于实际业务与系统使用中，有关企业数据与信息管理的某些需要重点保护、控制的内容。有关用户权限的管理，在 ORACLE 系统中主要有三个基本要素构成：菜单（ Menu）、责任（Responsibility）、以及用户（User）。三者的有机结合构成了系统权限或安全性管理的基础，辅之以参数或“安全性配置文件”等的使用，则进一步对用户的“实体（组织、帐套或分类帐）接入”权限进行细分。此外，系统在各个应用模块中，还将可能基于不同业务特点采取各具特色的系统实现方式，对用户的准入管理或功能权限作更进一步的划分（具体方式与系统设计者的个人偏好也有一定关系，不能一概而论）。“菜单”

4、（Menu）在今天信息时代的日常生活中已是一个很普通的术语。 ORACLE 中的“菜单”概念并无甚特别，它也是表示用户的系统应用功能入口。最基本的“菜单”由系统预置的若干“表单功能”所组成，EBS 目前大概具有 2 万个左右的此类表单功能；（基于某些特殊需要，系统还可提供虽不可见但可由表单内包含的逻辑调用的某些非表单“子功能”，需开发后台设置）。用户可以自定义包括若干基本菜单作为“子菜单”的用户菜单，自定义的“用户菜单”也可以作为“子菜单”来使用，这样就形成了一个菜单结构（树形图）。如图 1 所示菜单定义及可选择使用的系统预置表单功能 LIST：EBS 系统在安装好后，针对每个应用模块均已经预

5、定义包括所有功能（或权限）所谓的“超级用户菜单”（Super User Menu），企业（系统管理员）在定义用户“责任”时可利用“排除法”来满足实际的业务管理需要。此外，系统还提供了“仅具查询”功能的预定义菜单，供某些需要限制做业务的用户使用。相较于“菜单”的耳熟能详，EBS 的所谓“责任”（ Responsibility）概念就生涩、抽象得多，通常可以将之与人们相对熟悉的“角色”（Role ）概念来参看。在企业管理中通常会将人员按“岗位角色”来划分，例如“计划员、采购员、仓管员”等等，它们通常对应于一定的岗位职责（责任），有真实的业务管理涵义，比较具体。系统预先定义的角色，分配给用户（Use

6、r）后，该用户就具有该角色的全部应用功能；但 EBS 未象其它产品（如 SAP）使用角色概念，而是使用“责任”概念，则更倾向于抽象地表示某些功能（入口菜单）的组合，可以不具有真实的管理涵义，比如所谓“销售经理”责任之下，尽可以与“采购员”有相同的菜单项，具有完全相同的功能，而这一点如对应到实际的“岗位角色”，显然是不合适的。Role 更清楚直接，但使用不够灵活；Responsibility 可灵活使用，但容易带来理解上的歧义与误会，使用时要注意区分。如下图 2 所示的“责任”定义界面：每个责任必须对应关联一个确定的菜单，但可以使用“排除”功能使之具有不同的菜单结构组合，这里的“排除”功能并不影

7、响菜单原先的结构设置，这方便并简化了系统管理员对“责任”与“菜单”的管理。“责任名”总是从属于某一“应用产品”（模块），不同的模块可定义具有完全相同的“责任名”（包括菜单），但这两个完全相同的责任名在“配置文件”作层次结构设置时，可以具有不同的值，这进一步提供了系统的灵活性。责任一经定义就不可删除，只能通过设置有效期使之失效。为之设置“请求组”则限制了其可以使用的“请求”（并发程序）范围。至于其“可采用”应用产品范围设置（Web、自助等），似乎只起到统计分析的系统管理作用，实际并不影响具体的功能应用。系统在安装后将具有一个名为“SYSADMIN”（密码 sysadmin）且具有“系统管理员”责

8、任的初始用户（该用户有时也被称之为“超级管理员”）。使用此初始用户可设置“菜单、责任及用户”。如下图 3 所示“用户”的定义界面：每个定义的系统“用户”可以关联若干个不同的责任，每个责任也可以设定用户使用的有效日期范围。具有多个责任的用户在登录使用系统时，需要在不同责任间作选择切换，并非可以同时使用。系统初始设置时设定的密码，在用户初次登录时，将被系统提示要求修改。密码可以设定“使用天数”或“访问次数”的限制，系统的预警平台可以设置密码失效的提前预警，以督促用户及时修改。“用户”一经设置也无法删除，只能使用有效期设置使之失效。“用户”不一定必须和 HRM 模块设置的 “人员”关联，但对于有些模

9、块的应用功能，关联已经 HRM 恰当设置的“ 人员”则是必须的。而关联“ 客户”或“供应商”则主要起到统计分析的系统管理作用，并不影响具体的功能应用。用户所关联的“电子邮件”地址，主要是供系统预警平台发送信息使用。关于 EBS 系统使用相关“配置文件”诸如“MO:业务实体、MO:安全配置文件、HR:安全配置文件、GL:数据访问权限集、GL 帐套名或 GL 分类帐名称”等等，进一步对责任或用户的“实体接入”权限进行细分的问题（R12 与 R11 比较，变化较大），将在下面的“组织架构”设置中讨论。关于具体应用模块中对责任或用户的权限作更进一步划分问题，例如库存模块的“组织进入”（Access ）

10、、发运模块的“权限管理 ”（Grant ），容后在相关模块文档中再来讨论。二、会计科目弹性域结构在讨论 EBS 的“组织结构”的设置之前，有必要先讨论会计科目弹性域（Accounting Flexfield）及其帐套（SOB）或分类帐（Ledger）的设置问题。“帐套”是 R11 及之前系统中的术语，“分类帐”是 R12 中替代帐套并为有所区别而使用的术语。为表述方便，后文如不特别指明，习惯上的“帐套”术语将等同于“分类帐”术语。在 EBS 关于“组织实体”的概念范畴中，帐套实际上也是“组织实体”的一种存在形式，之所以如此和 ORACLE 产品的发展历史有一定关系。会计科目是企业进行财务数据核

11、算工作的基础，各个国家基于企业监管与税收工作的需要而制定的会计法律法规都对之有相应规定。我国于 2006 年颁布的新会计准则将会计科目分为六大类：资产类、负债类、共同类、所有者权益、成本类、损益类，共计 156 个（一级）科目。简单的财务会计软件或单公司规模很小时，类似手工记账的“电算化”系统实现方式问题不大，但当会计业务管理需求复杂，企业从单公司向多公司集团化方向发展时，就必须考虑在系统层面如何方便地对多个公司的会计数据进行集中统一管理的问题。ORACLE 的 ERP 产品最初也是从财务软件发展起来的，总账 GL 是其第一个应用模块。事实上，在计算机或管理软件出现以前，企业所谓“集团管控”的

12、需求及实践早已存在。ORACLE 财务软件中包含“多公司信息”的独特会计科目弹性域结构设计，使得财务工作的集团管控更加具备技术上的可行性与方便性。一个最基本、最简单的会计科目弹性域结构就是“公司代码+ 会计科目代码”的组合，它的原始业务需求来源并无多少深奥之处。在 ORACLE 的会计科目弹性域结构中，体现国家法律法规要求的“会计科目”成为其中必不可少的一个组成段即“自然账户”段，自然账户所使用的值集，即为通常所说的“科目表”。系统在自然账户之上附加“公司、部门”等多个段信息，大大方便了在公司内及公司间的会计数据的统计分析工作。如图 4 所示，就是一个典型的 5 段式会计科目弹性域结构：图中的

13、“公司段”为“平衡段”（弹性域限定词 Flexfield Qualifiers，是具有某种特定属性的“识别标记”），表示在“公司段”层面，日记账（Journals ，“会计分录 ”）的“借项等于贷项”，总是平衡的。其值集为包含所有公司的代码 LOV，包括法律实体及基于公司管理需要而设定的运营实体；如图 5 所示会计科目弹性域结构的“公司段”值集定义：在 EBS 系统中定义的法律实体 LE 必须对应于公司段值集中的（至少）一个值（行），但 R11 与 R12 的区别是，R11 在定义 LE 时并没有明确告诉系统对应（绑定）哪个段值，只要用户自己清楚并不混淆即可。而在 R12 定义 LE 时，需要

14、将其与会计科目弹性域结构中的某个公司段值明确关联，这是 R12 的改进之处，避免了 R11 实际使用中当定义的法律实体 LE 数量较多时可能产生的混淆不清。“部门段”的弹性域限定词为“成本中心段”，成本中心 LOV 值可能是企业中的一个具体行政组织，也可能表示共享一个成本中心的多个行政组织的组合，还可能是表示基于统计管理需要而设定的多个成本中心的组合；如下图 6 所示：“账户段”的弹性域限定词为“自然账户段”，其 LOV 值即法定科目表及为统计需要而设置的汇总科目；如图 7 所示：注意，图 7 与图 5、6 中的“段限定词 ”的内容有所不同，它具体规定了自然账户的段值所代表的会计科目的类别（资

15、产、负债等），“弹性域限定词”与“段限定词”是两个不同的概念，段限定词的取值受控于弹性域限定词的取值。会计科目弹性域结构的“子账户段”表示“二级科目或明细科目”，与账户段的一级科目具有汇总与被汇总的关系；“产品段”，则表示基于特定统计分析需要而设置的产品 LOV。系统允许设置最多 30 个段，但必须至少包含两个段（平衡段、自然账户段）。由于会计科目弹性域结构一经设定并使用之后，以后修改比较困难，故通常会设定一个或多个预留段，如可在上述典型的 5 段结构之外再增加一个暂时不使用的段（预留段）而成为 6 段结构。会计科目弹性域结构的设定是系统基础设置的重要工作之一，有关详细设置方法与步骤请参看相关

16、系统设置文档。此外，EBS 系统针对所有弹性域的“段值”的接入权限，提供了“安全性”设置功能，控制“责任”实际可以使用的段值范围，如下图 8 所示：三、帐套（分类帐）会计科目弹性域结构（COA）、币种（Currency）、日历（ Clander）三者的组合构成 EBS R11 及之前系统的所谓“帐套”（SOB）。在 R12 中，再增加一个维度“会计方法或会计惯例”，即成为所谓“分类帐”。所谓“会计方法或惯例”，例如对于不同国家或地区、不同企业，会计法规可能规定物品单价 5000 元是作为“固定资产”还是“期间费用”处理的判定标准，也可能规定这个判定标准是 1 万元。标准不同，记账的会计科目也就

17、不同，企业报告的经营结果也就会有差别。一个诸如在香港注册的企业，一方面需要向香港政府机关提交符合本地法规的财务报告，另一方面可能还需要向在国内的总公司提供符合国内法规的财务报告（便于考核管理），这就出现所谓“多账簿”（对应 R12 中的主辅分类帐）的系统功能问题。如下图 9 是 EBS R11中“帐套”的定义界面：如下图 10 所示是 EBS R12 中使用“会计科目管理器 AMB”设置“主要分类帐（Primary Ledger）”与“辅助分类帐（Second Ledger）”的定义界面：R12 中定义的一个“主要分类帐”可以附带定义与之关联的多个 “辅助分类帐”，如下图 11 所示：“主要分

18、类帐”与“辅助分类帐”，可以有不同的科目表结构（COA）。由于系统其它的应用模块（R12中称之为“子分类帐应用产品”），例如 PO/AP/AR 等等，其事务处理默认是基于“主要分类帐”的会计科目表（COA），所以，如果主辅分类帐的科目表不同，则必须在两者之间建立“映射（Mapping ）”关系（1 对 1 或多对 1 的关系）。如下图 12 所示为主辅分类帐的映射定义界面，如果两者科目表相同（币种不同），则该定义界面将有所不同，没有“科目表”映射的内容，只有后面部分（币种转换及日记账转换等）：下图 13 所示为当主辅分类帐的科目表不同时，系统科目表映射的定义界面，账户规则定义中可见，源账户可以

19、是一个范围，而目标账户只能是一个：ORACLE EBS R12 中四维（4C）定义的“分类帐 Ledger”构成了 ORACLE 系统“多账簿”功能的处理基础。实际上，在 R11 中三维（3C）定义的“帐套 SOB”也有“多报告币账簿”的概念，但那仅限于财务报表在不同币种之间的自动转换，并不是真正意义上的系统“多账簿”功能（即一个公司自动生成符合会计法规要求的多套帐）。ORACLE EBS R12“多账簿”功能的核心与关键是各相关应用模块（子分类帐应用产品）在向总账模块传送日记账时，如何自动为总账中的“主要分类帐和辅助分类帐”自动生成各自的日记账分录。这就涉及到分别为主辅分类帐设置图 10 中

20、的 “子分类帐会计选项”的问题，它实际包括两个步骤，一是为系统定义哪些应用模块可以使用子分类帐会计方法（ORACLE 已经预定义）；如下图 14 所示，系统已经预定义了包括PO/AP/AR/CST/FA 等在内的 21 个需要用到子分类帐会计方法的应用产品：二是为已经定义子分类帐的应用模块分别针对主辅分类帐设置“子分类帐会计方法”，如下图 15 所示：其中的“事件分类选项”及其相关设置是系统最基础、最复杂也是最抽象的过程，包括了复杂的用户预定义工作，诸如会计事件分类（Event Class）与会计事件类型（Event Type）组合定义、日记账行定义、日记账行类型定义等等。每个子分类帐应用产品

21、的系统事务处理默认是基于主要分类帐的“代码组合”及其账户生成器规则，当子分类帐应用产品系统启动“向 GL 传送日记账”流程时，对于每个会计事件分类的“分类类型”组合，流程将按照“子分类帐会计方法”中所包含的日记账行类型之“条件”与“账户推导规则”生成相应的“帐户代码”（CCID ）及日记账行。不同的分类帐如主辅分类帐，生成的 CCID 可能不同，而这正是“多账簿”功能所需要的。有关“子分类帐会计方法”设置的详细过程需参照 ORACLE 相关文档。如下图 16所示仅是其中的定义界面之一：对于 EBS R12 来说，即使不使用辅助分类帐也要为“主要分类帐”添加“子分类帐会计方法”，它可以使 ORA

22、CLE 预置默认的，也可以使用户修改后自定义的。实际上对于 EBS R11 来说，安装时相当于 ORACLE为所有的 SOB 直接预置了子分类帐会计方法，系统将复杂的子分类帐会计方法定义向用户屏蔽了，用户无法修改调整。复杂的“子分类帐会计方法”定义是 EBS R12 为实现“多账簿”功能而必须付出的代价。所幸的是它只对 GL 模块的使用有一定影响，对各相关应用模块的用户使用并无直接影响，从 R11 到 R12，“多账簿”功能只相当于多调用了一个“服务”，EBS 系统升级与使用保持了良好的继承性。在 EBS 的总账 GL 模块中，由于工作的对象主要是基于“账户代码”的日记账（会计分录）的数据信息

23、，来自各业务模块的有关不同公司的会计数据的“组织属性”实际上通过账户代码中的不同公司段值已经得到体现，与各来源业务模块（子分类帐应用产品）中的相关“（业务）组织属性”设置无关。故总账模块与其它业务模块比较，总账模块无需再作所谓“组织”的划分，可说是“无组织”的。总账系统用户一般来说可以处理所有公司的会计数据（除非作弹性域段值的安全性设置）。如果一定要说总账 GL 也有类似业务组织属性划分的话，那么这个“组织实体”就是帐套或分类帐，系统将使用类似业务模块的“组织接入”配置文件（如“MO：业务实体”）的“ 帐套接入”配置文件（例如 R11 的“GL 帐套名”或 R12 的“GL ：数据访问权限集”

24、、 “GL 分类帐名称”等），来分隔用户的工作权限。有关“帐套接入”配置文件的使用有下述注意事项。对于配置文件“GL 帐套名”， R11 中该参数的LOV 由系统基于创建的 SOB 名自动创建，一旦为其赋值后，用户登录时系统自动定位于已指定 SOB。由于GL 模块与 OU 无关，所以进入 GL 后，数据的区隔主要基于这个参数，但这个参数并不限制某些需要跨 SOB功能如 FSG 对数据的访问。如下图 17 所示：对于配置文件“GL 分类帐名称”， 该参数只在 R12 中有，类似 R11 中的“GL 帐套名”，但作用与R11 大不相同，其 LOV 为分类帐名的集合（创建时自动添加），只表示当前用户

25、所进入的该“分类帐”同时还需要用到子分类帐产品诸如 AP/AR 等等。如下图 18 所示（而当前用户所能够进入的分类帐则是由“GL：数据访问权限集”控制）：对于配置文件“GL：数据访问权限集”， 该参数只在 R12 中才有，必须设置（有值），否则系统会报错。但是系统给出了特别控制机制，即在每当修改设置“GL 分类帐名称”时，系统会同时自动修改“GL：数据访问权限集”的值，使之与“GL 分类帐名称”的值一致。如果是先设置“GL 分类帐名称”，后修改了“GL：数据访问权限集”的默认值，则系统在进入日记账的 FORM 时，如果后者的值不包含前者的值，则前者的设置被无效，但系统无法使用相关子分类帐产品

26、。如果后者的值包含前者的值，则前者的值代表该分类帐还需要使用相关子分类帐产品。如下图 19 所示：配置文件“GL：数据访问权限集”的取值 LOV 需要在系统中另外设置，每个取值包含了若干已经定义的分类帐/分类帐集及其读写权限，用户进入后，可在 FORM 界面于其中选择切换，如下图 20 所示：要特别注意，对于 R12 的“GL 分类帐名称”的任何一次修改（包括清空），都会自动影响“GL：数据访问权限集”的值。系统之所以如此设计，目的在于保证原 R11 的业务控制功能不变，通过增加参数，在R12 中控制“可访问数据的范围”。因此正确的做法应该是：先设定 “GL 分类帐名称”的值，实现基本的业务功

27、能（与子分类帐产品关联），再修改“GL：数据访问权限集”的默认值，控制数据可访问范围，但必须保证其值包含了前者的值。测试中发现，如果“GL 分类帐名称”配置文件值留空，而修改设定了“GL：数据访问权限集”，“GL：数据访问权限集”默认的分类帐并未出现在 FORM 的窗口界面中，这似乎是设计人员的疏忽。ORACLE GL 在“创建分类帐、定义分类帐集”时会自动创建“数据访问权限集”LOV 值，并且其类型为“全部分类帐”，提供完整读写权限。在需要进一步限制对分类帐、分类帐集或分类帐/分类帐集的特定平衡段值或管理段值的读写权限时，用户需要创建自己的数据访问权限集。在 R12 中还可以为财务系统另外定

28、义“访问权限集”（不同于参数 “GL：数据访问权限集”），并分配给责任来限制该责任所具有的功能（当然这是在已经进入的当前分类帐之下的）。系统预置了一个“超级用户定义访问权限集”（不可修改）。推测“权限”的限制方式可能是“倒剥式”（为空时，权限最大，每增多一项，就少一个与之对应的权限），如下图 21 所示：最后需注意的是，EBS 系统所谓“多账簿”功能与“多帐套（分类帐）接入”功能是两个不同的概念。“多账簿”功能表示“一个用户的同一业务处理，系统自动生成多本帐”，反映的是系统业务处理功能，R12具备，而 R11 不完全具备（R11 仅能提供多币种报表）。“多帐套（分类帐）接入”功能表示“一个用户

29、如何接入多个帐套（分类帐）”的权限管理方式（“上下文”环境切换方式），R11 也具备，但对于同一用户，必须通过在具有相同业务功能的不同责任间切换才能实现，使用时不是太方便，而 R12 的同一用户，无需进行“责任”切换，仅通过在表单上直接选择切换就能实现，使用比较方便。R12 与 R11 的上下文切换方式虽然不同，但切换后的系统业务处理功能则基本相同。四、组织架构在企业管理实践的过程中，“组织”（Organization）一词是个经常需用到的概念，一般与“人员”与“职能”这两个要素密切相关，反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等。企业内部行政组织（部门）的划分是

30、企业基于“职能驱动”业务管理模式进行运作的基础。目前，国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的“组织职能”划分问题。但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题。一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。这种系统实现方式虽有理解、掌握比较容易的优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。国内有所谓

31、高端管理软件在系统实施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况”，导致系统几乎没法使用的困境，其症结正在于此。与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。作为 ERP 鼻祖的 SAP 将系统组织简单地分为“集团（Client）、公司代码（ Company Code）、采购组织（Purchase Org）、销售组织（ Sale Org）、工厂（Plant ）”等类别。ORACLE 的组织设置本质上与之基本相似，但作

32、为后来者作了进一步抽象与简化，系统组织划分为“业务组（Business Group）、法律实体（Legal Entity）、业务实体（ Operating Unit）、库存组织（ Inventory Org）”等。如果说 SAP 的组织模型字面上多少还带有一点“行政组织”痕迹的话（这可能是某些声称学 SAP 的国内产品误入歧途的原因），ORACLE 系统的组织模型字面上已经几乎看不出与 “行政组织”还有什么关系，其中的“Inventory Org”现今中文翻译成 “库存组织”，容易令人望文生义和企业的 “仓库管理部门（Warehouse ）”混淆，但 Inventory 的本义实际应该是“存货

33、”，称之为“存货组织”或许更好一些。如下图 22 所示 ORACLE 系统有关核心业务的多组织模型：上图中的“财务、销售、采购”并非系统的“组织实体”，它仅表示业务实体（OU）具有的相关业务处理功能。“子库”是特殊的系统组织实体，没有上下文环境可进入，主要表示库存组织之下的某种业务功能。（一）业务组（BG）“业务组”的概念可以与企业的“集团”概念参看，但不同的是一个企业在系统中可以设置多个“业务组（集团）”。通常对于一个企业来说，系统中有一个“业务组”就够了，这表示企业就是一个“集团公司”。而对于某些业务“多元化”的特大型公司（如跨国公司），则可能需要在系统中设置多个“业务组”，表示企业由多个

34、“集团公司”组成。业务组设置是系统组织设置的第一步，是最高层级的组织形态，但它主要是与人力资源信息的分隔有关，即“人员信息”的设置在一个 BG 范围内是由各业务模块共享的（如果需要）。一旦系统设置的用户名（User）被与 “人员”（Employee）关联，无论使用什么“责任”进入系统，都会定位至一个确定的 BG 中，任何责任在任意时刻只能关联一个 BG。EBS 安装好后，系统里面已经预置了一个名为“Setup Business Group”的“初始业务组 ”。如图 23 所示系统预置的“Setup Business Group”：当以系统预置超级用户 SYSADMIN 进入后，应首先设置一个具

35、有在 HRM 或 INV 下创建组织功能的“责任”名，随后给此责任的“HR：User Type”配置文件设定值为 “HR User”，则该责任就有了创建新 BG 的能力。通常需要一次性将企业所需要的 BG 全部建立，一般另创建一个与企业名称一致如“某某集团”的新BG 就可以了，也可以（不推荐）直接使用系统预设的“Setup Business Group”而不创建新 BG。系统每新建一个 BG，就会自动在配置文件“HR：安全性配置文件”的 LOV 中自动添加一个与新建 BG同名的可选值（初始时只有“Setup Business Group”一个值）。在某一个 BG 下（初始为 Setup Bus

36、iness Group）新建的任何责任，系统都将该责任的配置文件“HR ：安全性配置文件”值默认为当前 BG。要在进入系统时能切换到新的 BG，必须先修改该责任的“HR：安全性配置文件”设定值。如果将配置文件“HR：交叉业务组”的值设为“是”，则在不同 BG 下，新建的组织名称应当（虽然可以）不同，否则查看时可能会引起混淆。在同一个 BG 下的所有新建组织，名称不允许相同。（二）法律实体（LE）法律实体（LE，Legal Entity）对应于真实世界中的按国家法律法规要求注册的 “法人公司”。在 R11中，LE 在组织 FORM 定义时，对于每个 LE 必须为其“法人主体会计科目”关联一个“帐

37、套 SOB”。每个 LE对应一个 SOB，这与真实世界的法规要求是吻合的。如下图 24 所示：要注意的是，在 R11 中定义的 LE 时，并未作与“会计科目弹性域结构”的“公司段”值关联，用户必须对于其是与公司段值中的哪个值对应心中有数。而在 R12 中， LE 的组织定义虽在 FORM 中仍然保留，但 LE的“法人主体会计科目”的 FORM 设置被废弃（故 FORM 中定义了也无用），改为在定义“分类帐”时的“会计科目设置管理器”WEB 中定义并分配法人实体 LE。一个分类帐设置（主辅分类帐）可以添加多个 LE，但每个 LE 只能具有一个分类帐设置。如下图 25 所示：在 R12 中，还必须

38、为法人实体分配会计科目弹性域结构的公司段即平衡段值。每个 LE 可以分配多个“平衡段”值，公司段值集中每个段值一旦被分配给某 LE，则其它 LE 就不能再被分配。在 R11 或 R12 中创建一个 LE 后，应当及时到会计科目弹性域结构中添加需要对应的公司段值 LOV（一个或多个），并重新进行弹性域的编译，否则系统可能会弹出错误报警信息。R12 中一个 LE 对应多个公司平衡段值，代表有多个分公司，LE 是它们的合并。主辅分类帐可拥有相同或不同的公司段值集，表示从不同的维度（如按地区、按产品等）去划分公司以方便考核。如图 26 所示为 LE 添加平衡段值：无论是 R11 还是 R12，法律实体

39、 LE 的设置都对具体的业务处理影响不大，其与系统用户或责任不关联，不直接影响系统上下文的切换，故有人甚至认为 EBS 的 LE 设置作用不大。这对于系统的内部运作来讲情况确实近似如此，但对于需要通过系统产生供外部使用的具有法律意义的文书（如采购订单、财务报表等等），严格区分法律实体 LE 还是必须的。 R12 显然更多地考虑了外部使用的这种法律要求（即所谓“法规遵从性”或“合规性”），并在相关业务应用模块中有所体现。（三）业务实体（OU）业务实体（OU，Operating Unit）是 EBS 系统组织设置的重点也是难点之一。它与法人主体 LE 本身没有必然的关系，与会计科目弹性域结构中的“

40、公司段”也没有直接关系。从企业实际业务管理需要的角度去看，业务实体 OU 可以看作是在系统中按照业务的相似性，把多个不同公司（包括 LE）的业务处理过程及数据划分成相对独立的“管理单元”。在每个管理单元内部，各公司的业务运作共享相关数据并执行统一的业务策略。例如，有一个业务多元化的企业既生产医院使用的 X 光机也生产普通电视机，并且其下属在全国各地有多家生产 X 光机或电视机的分公司、子公司。由于这两种产品所使用的物料、供应商以及针对的客户群差异很大，企业为方便管理，可以将“业务运营”划分为两个相对独立的“业务管理群组”，对应到 EBS 系统中就是两个业务实体 OU。从企业日常业务运作管理的角

41、度来看，对于单纯的电视机业务，全国范围内就设一个公司负责计划、生产、采购、销售等运营管理最为简便，但企业从非运营管理角度例如“税收优惠、地方政策”等等因素考虑，有时不得不在全国各地乃至世界各地注册若干所谓“公司”，以便向当地政府纳税并接受其财务会计方面的监管。EBS 在一个业务实体 OU 下，例如“电视机管理群组”，包含了全国各地所有负责生产或销售电视机的分公司、子公司（LE）的日常业务运作，在业务运作的组织层面忽略了作为法人实体的公司信息，但在反映业务运营最终结果的财务阶段（GL ），仍能够方便地按照各地的法规要求提供财务数据与结果。而对于负责具体业务的系统用户来说，日常工作几乎不用关心或考

42、虑“公司”的设置问题。EBS 中 LE 的数量可以根据需要任意增加，但对于 OU 的数量基于管理方便性则要求尽可能精简。EBS 产品早期在实施过程中，存在一个公司（LE）对应一个 OU 的做法或一个 OU 只能属于一个 LE 的说法，这种做法或说法并不恰当。某些国内产品的设计由于未能有效区分“法律实体（公司）”与“业务实体（运营）”两者在系统中既相连接又有本质区别的特殊关系，只好采取一个法人公司对应一个系统业务实体的“笨办法”，企业规模小倒还能对付，一旦规模变大，注册公司增多，所谓的“系统多组织架构”就变得根本不具可用性。ORACLE EBS 业务实体 OU 的这一系统特性极大地方便了企业运作的日常管理，具有高度的灵活性与可扩展性。如下图 27 是 R11 的 OU 定义界面：