ERP系统配置

3.1引言

全新安装的ORACLE EBS系统（也称为“FRESH系统”），必需首先完成相关“系统设置”才能够真正使用。从“系统设置”所包含内容的性质与用途角度来看，实际的系统设置内容可以划分为两部分：一是与具体业务实践没有关系或关系不大，通常具有“全局性”影响的部分，这部分内容可称之谓“基础设置或基础数据”。例如“用户权限、组织结构、单位、币种、地址”等等；二是与具体的业务种类或系统功能关系比较密切，但影响范围通常仅限于特定业务模块系统的部分，这部分内容可称之谓“业务设置或模块设置”。例如“模块系统参数、特定业务功能设置”等等。

对于初学者来说，首先学习并熟练掌握系统的“基础数据”或“基础设置”方面的相关内容非常重要，这部分内容由于一般不涉及复杂的“具体业务”，故相对来说比较简单和容易理解，但它们是读者以后“进阶”到比较复杂的“业务设置或模块设置”的学习基础。考虑到一开始就以“FRESH”系统作为EBS系统学习与讨论的基础，对于初学者来说难度较大，故本章内容将基于Vision Demo系统的已有测试数据，对EBS系统的有关“基础设置与基础数据”内容作讨论。系统的相关基础设置或基础数据，部分在安装时已经有初始化的预置值可直接使用，仅在必要时需根据具体的业务需要作自定义调整或设置。读者在学习过程中，可以参考本书（下部）最后章节“EBS R12全新系统设置及业务测试实例”中的相关内容。

需要说明的是，本章内容的讨论假定读者已经具备基本的系统相关使用知识与技能，例如能够基本领会与掌握上一章“ORACLE EBS系统功能的应用基础”中的有关内容。本章所讨论的内容仅限于从系统功能与业务应用两方面来看比较重要或者容易存疑的部分，并不能面面俱到，旨在帮助读者掌握核心、抓住要点。此外，本章（及后续各章）为讨论需要所附系统界面截图，均取自ORACLE EBS 系统的测试环境“Vision Demo”，版本以R12.1.1为主，辅之以版本R11.5.10，界面语言主要为中文，必要时辅之以英文。两个EBS系统版本在界面与功能应用方面实际可能有一些差异，但一般不会影响对基本问题的讨论，必要时会作相关说明。

3.1.1安全性管理

从系统使用角度来看，系统管理的一项重要的日常工作是关于“用户”及其“权限”的管理，在ORACLE EBS中即所谓“安全性”（Security）管理。“安全性”是一个涵义较之“权限”更为丰富、更为广阔的概念术语，它虽然比较抽象，但顾名思义，它很好地涵盖了在实际业务与系统使用中，有关企业数据与信息管理的某些需要重点保护、控制的内容。

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

3.1.2菜单

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

图 3‑1 EBS 系统的菜单设置

EBS系统在安装好后，针对每个应用模块均已经预定义包括所有功能（或权限）所谓的“超级用户菜单”（Super User Menu），企业（系统管理员）在定义用户“责任”时可利用“排除法”来满足实际的业务管理需要。此外，系统还提供了某些“仅具查询”功能的预定义菜单，供需要限制不能做业务的用户使用。

3.1.3责任

相较于“菜单”的耳熟能详，EBS系统的所谓“责任”（ Responsibility）概念就生涩、抽象得多，通常可以将之与人们相对熟悉的“角色”（Role）概念来参看。在企业管理中通常会将人员按“岗位角色”来划分，例如“计划员、采购员、仓管员”等等，它们通常对应于一定的岗位职责（责任），有真实的业务管理涵义，比较具体。系统预先定义的角色，分配给用户（User）后，该用户就具有该角色的全部应用功能；

EBS系统并未象其它产品（如SAP）那样直接使用“角色”概念，而是使用比较抽象的“责任”概念来表示某些功能（入口菜单）的组合。“责任”可以不具有真实的管理涵义，如所谓“销售经理”责任之下，尽可以与“采购员”有相同的菜单项，具有完全相同的功能，而这一点如对应到实际的“岗位角色”，显然是不合适的。角色（Role）更清楚直接，但使用不够灵活；责任（Responsibility）可灵活使用，但容易带来理解上的歧义与误会，使用时要注意区分。如图 3‑2所示的“责任”定义界面。

图 3‑2 EBS 系统的责任设置

每个责任必须对应关联一个确定的菜单，但可以使用“排除”功能使之具有不同的菜单结构组合，这里的“排除”功能并不影响菜单原先的结构设置，这方便并简化了系统管理员对“责任”与“菜单”的管理。“责任名”总是从属于某一“应用产品”（模块），不同的模块可定义具有完全相同的“责任名”（包括菜单），但这两个完全相同的责任名在“配置文件”作层次结构设置时，可以具有不同的值，这进一步提供了系统的灵活性。责任一经定义就不可删除，只能通过设置有效期使之失效。“数据组”设置是为责任链接 Oracle 数据库帐户（使用预置的“标准”即可）。设置“请求组”则决定了责任可以使用的“请求”（并发程序）范围；“可采用”应用产品范围设置（Web、自助等），只起到统计分析的系统管理作用，实际并不影响具体的功能应用。

3.1.4用户（User）

EBS系统在安装后将具有一个名为“SYSADMIN”（密码sysadmin）且具有“系统管理员”责任的初始用户（该用户有时也被称之为“超级管理员”）。使用此初始用户可设置“菜单、责任及用户”。如图 3‑3所示“用户”的定义界面。

图 3‑3 EBS 系统的用户设置

每个定义的系统“用户”可以关联若干个不同的责任，每个责任也可以设定用户使用的有效日期范围。具有多个“责任”的用户在登录使用系统时，需要在不同“责任”间作选择切换，并非可以同时使用。系统初始设置时设定的用户密码，在用户初次登录时，将被系统提示要求修改。密码可以设定“使用天数”或“访问次数”的限制，系统的预警平台可以设置密码失效的提前预警，以督促用户及时修改。

系统“用户”一经设置无法删除，只能使用“有效期”设置使之失效。“用户”不一定必须和HRM模块设置的“人员”关联，但对于有些模块的应用功能，关联已经HRM恰当设置的“人员”则是必须的。而关联“客户”或“供应商”则主要起到统计分析的系统管理作用，并不影响具体的功能应用。用户所关联的“电子邮件”地址，主要是供系统预警平台发送信息使用。

另外，关于EBS 系统使用相关“配置文件”诸如“MO:业务实体、MO:安全配置文件、HR:安全配置文件、GL:数据访问权限集、GL帐套名或GL分类帐名称”等等，进一步对责任或用户的“实体接入”权限进行细分的问题，将在下面的“组织架构”设置中讨论。关于具体应用模块中对责任或用户的权限作更进一步划分问题，例如库存模块的“组织进入”（Access）、发运模块的“权限管理”（Grant）等，以后将在本书的相关应用系统章节中再来讨论。

3.2会计科目弹性域结构

在讨论EBS的“组织结构”的设置之前，有必要先讨论会计科目弹性域（Accounting Flexfield）及其帐套（SOB）或分类帐（Ledger）的设置问题。“帐套”是R11及之前系统中的术语，“分类帐”是R12中替代帐套并为有所区别而使用的术语。为表述方便，后文如不特别指明，习惯上的“帐套”术语将等同于“分类帐”术语。在EBS关于“组织实体”的概念范畴中，“分类账”或“帐套”实际上也是“组织实体”的一种存在形式。

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

ORACLE的ERP产品最初也是从财务软件发展起来的，总账GL是其第一个应用模块。事实上，在计算机或管理软件出现以前，企业所谓“集团管控”的需求及实践早已存在。ORACLE财务软件中包含“多公司信息”的所谓“会计科目弹性域结构”设计，使得财务工作的集团管控更加具备技术上的可行性与方便性。一个最基本、最简单的会计科目弹性域结构就是“公司代码+会计科目代码”的组合，它的原始业务需求来源并无多少深奥之处。

在EBS系统的会计科目弹性域结构中，体现国家法律法规要求的“会计科目”成为其中必不可少的一个组成段即“自然账户”段，自然账户所使用的值集，即为通常所说的“科目表”。系统在自然账户之上附加“公司、部门”等多个段信息，大大方便了在公司内及公司间的会计数据的统计分析工作。如图 3‑4所示，就是一个典型的5段式会计科目弹性域结构。

图3-4中的“公司段”为“平衡段”（弹性域限定词 Flexfield  Qualifiers，是具有某种特定属性的“识别标记”），表示在“公司段”层面，日记账（Journals，“会计分录”）的“借项等于贷项”，总是平衡的。

图 3‑4 会计科目弹性域结构

公司段的值集为包含所有公司代码的LOV，包括法律实体及基于公司管理需要而设定的运营实体；如图 3‑5所示会计科目弹性域结构的“公司段”值集定义。

图 3‑5 会计科目弹性域结构公司段值集设置

在EBS系统中定义的法律实体LE必须对应于公司段值集中的（至少）一个值（行），但R11与R12的区别是，R11在定义LE时并没有明确告诉系统对应（绑定）哪个段值，只要用户自己清楚并不混淆即可。而在R12定义LE时，需要将其与会计科目弹性域结构中的某一个（或几个）公司段值明确关联，这是R12的改进之处，避免了R11实际使用中当定义的法律实体LE数量较多时可能产生的混淆不清。

“部门段”的弹性域限定词为“成本中心段”，成本中心LOV值可能是企业中的一个具体行政组织，也可能表示共享一个成本中心的多个行政组织的组合，还可能是表示基于统计管理需要而设定的多个成本中心的组合；如图 3‑6所示。

图 3‑6 会计科目弹性域结构成本中心段值集设置

“账户段”的弹性域限定词为“自然账户段”，其LOV值即法定科目表及为统计需要而设置的汇总科目；如图 3‑7所示。

图 3‑7会计科目弹性域结构自然账户段值集设置

注意，图 3‑7与图 3‑5、图 3‑6中的“段限定词”的内容有所不同，它具体规定了自然账户的段值所代表的会计科目的类别（资产、负债等）。“弹性域限定词”与“段限定词”是两个不同的概念，段限定词的取值受控于弹性域限定词的取值。

会计科目弹性域结构的“子账户段”表示“二级科目或明细科目”，与账户段的一级科目具有汇总与被汇总的关系；“产品段”，则表示基于特定统计分析需要而设置的产品LOV。

系统允许会计科目弹性域结构设置最多30个段，但必须至少包含两个段“平衡段、自然账户段”。由于会计科目弹性域结构一经设定并使用之后，以后修改比较困难，故通常会设定一个或多个预留段，如可在上述典型的5段结构之外再增加一个暂时不使用的段（预留段）而成为6段结构。会计科目弹性域结构的设定是系统基础设置的重要工作之一，有关详细设置方法与步骤请参看相关系统设置文档。

此外，EBS系统针对所有弹性域的“段值”的接入权限，提供了“安全性”设置功能，控制“责任”实际可以使用的段值范围，如图 3‑8所示。

图 3‑8 会计科目弹性域结构的安全性功能

3.3分类帐（帐套）

会计科目弹性域结构（COA）、币种（Currency）、日历（Clander）三者的组合构成EBS R11及之前系统的所谓“帐套”（SOB）。在R12中，再增加一个维度“会计方法或会计惯例”，即成为所谓“分类帐（Ledger）”。所谓“会计方法或会计惯例”，例如对于不同国家或地区、不同企业，会计法规可能规定物品单价5000元是作为“固定资产”还是“期间费用”处理的判定标准，也可能规定这个判定标准是1万元。标准不同，记账的会计科目也就不同，企业报告的经营结果也就会有差别。一个诸如在香港注册的企业，一方面需要向香港政府机关提交符合本地法规的财务报告，另一方面可能还需要向在国内的总公司提供符合国内法规的财务报告（便于考核管理），这就出现所谓“多账簿”（对应R12中的主辅分类帐）的系统功能问题。如图 3‑9是EBS R11中“帐套”的定义界面：

图 3‑9 R11系统帐套设置

如图 3‑10所示则是EBS R12中使用“会计科目管理器AMB”设置“主要分类帐（Primary Ledger）”与“辅助分类帐（Second Ledger）”的定义界面。

图 3‑10 R12主分类帐设置

EBS R12中定义的一个“主要分类帐”可以附带定义与之关联的多个“辅助分类帐”，如图 3‑11所示。

图 3‑11 R12主分类帐关联的辅助分类帐

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

图 3‑12 R12主辅分类帐科目表映射

图 3‑13所示为当主辅分类帐的科目表不同时，系统科目表映射的定义界面，账户规则定义中可见，源账户可以是一个范围，而目标账户只能是一个。

图 3‑13 R12科目表映射规则设置

ORACLE EBS R12中四维（4C）定义的“分类帐Ledger”构成了ORACLE系统“多账簿”功能的处理基础。实际上，在R11中三维（3C）定义的“帐套SOB”也有“多报告币账簿”的概念，但那仅限于财务报表在不同币种之间的自动转换，并不是真正意义上的系统“多账簿”功能（即一个公司自动生成符合会计法规要求的多套帐）。

ORACLE EBS R12“多账簿”功能的核心与关键是各相关应用模块（子分类帐应用产品）在向总账模块传送日记账时，如何自动为总账中的“主要分类帐和辅助分类帐”自动生成各自的日记账分录。这就涉及到分别为主辅分类帐设置图 3‑10中的 “子分类帐会计选项”的问题，它实际包括两个步骤，一是为系统定义哪些应用模块可以使用子分类帐会计方法（ORACLE已经预定义）。如图 3‑14所示，系统已经预定义了包括PO/AP/AR/CST/FA等在内的21个需要用到子分类帐会计方法的应用产品。

图 3‑14 R12子分类帐应用产品

二是为已经定义的子分类帐的应用模块分别针对主、辅分类帐设置“子分类帐会计选项”，如图 2‑15所示。

图 3‑15 R12 子分类帐会计选项

其中的“事件分类选项”及其相关设置是系统最基础、最复杂也是最抽象的过程，包括了复杂的系统预定义工作，诸如会计事件分类（Event Class）与会计事件类型（Event Type）组合定义、日记账行定义、日记账行类型定义等等。每个子分类帐应用产品的系统事务处理默认是基于主要分类帐的“代码组合”及其账户生成器规则，当子分类帐应用产品系统启动“向GL传送日记账”流程时，对于每个会计事件分类的“分类—类型”组合，流程将按照“子分类帐会计方法”中所包含的日记账行类型之“条件”与“账户推导规则”生成相应的“帐户代码”（CCID）及日记账行。不同的分类帐如主辅分类帐，生成的CCID可能不同，而这正是“多账簿”功能所需要的。

有关“子分类帐会计方法”设置的详细过程需参照ORACLE相关设置文档。如图 3‑16所示仅是其中的定义界面之一。

对于EBS R12来说，即使不使用辅助分类帐也要为“主要分类帐”添加“子分类帐会计方法”，它可以是ORACLE预置默认的，也可以是用户修改后自定义的。实际上对于EBS R11来说，安装时相当于ORACLE为所有的帐套（SOB）直接预置了子分类帐会计方法，系统将复杂的子分类帐会计方法定义向用户屏蔽了，用户无法修改调整。

复杂的“子分类帐会计方法”定义是EBS R12为实现“多账簿”功能而必须付出的代价。所幸的是它只对GL模块的使用有一定影响，对各相关应用模块的用户使用并无直接影响，从R11到R12，“多账簿”功能只相当于多调用了一个“服务”，EBS系统升级保持了良好的继承性。

图 3‑16 会计事件分类选项设置

3.4分类账（帐套）访问

在EBS的总账GL模块中，由于工作的对象主要是基于“账户代码”的日记账（会计分录）的数据信息，来自各业务模块的有关不同公司的会计数据的“组织属性”实际上通过账户代码中的不同公司段值已经得到体现，与各来源业务模块（子分类帐应用产品）中的相关“（业务）组织属性”设置无关。故总账模块与其它业务模块比较，总账模块无需再作所谓“组织”的划分，可说是“无组织”的。

总账系统用户一般来说可以处理所有公司的会计数据（除非作弹性域段值的安全性设置）。如果一定要说总账GL也有类似业务组织属性划分的话，那么这个“组织实体”就是帐套或分类帐，系统将使用类似业务模块的“组织接入”配置文件（如“MO：业务实体”）的“帐套访问”配置文件（例如R11的“GL 帐套名”或R12的“GL：数据访问权限集”、 “GL 分类帐名称”等），来分隔用户的工作权限。

有关“帐套访问”配置文件的使用有下述注意事项：对于配置文件“GL 帐套名”， R11中该参数的LOV由系统基于创建的SOB名自动创建，一旦为其赋值后，用户登录时系统自动定位于已指定SOB。由于GL模块与业务实体OU无关，所以进入GL后，数据的区隔主要基于这个参数，但这个参数并不限制某些需要跨SOB功能如FSG对数据的访问。如图 3‑17所示。

图 3‑17 R11的帐套访问配置文件“GL帐套名”设置

对于配置文件“GL 分类帐名称”， 该参数只在R12中有，类似R11中的“GL帐套名”，但作用与R11大不相同，其LOV为分类帐名的集合（创建时自动添加），只表示当前用户所进入的该“分类帐”同时还需要用到子分类帐产品诸如AP/AR等。如图 3‑18所示。

图 3‑18 R12的GL 分类账名称配置文件设置

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

图 3‑19R12 分类账访问配置文件“GL:数据访问权限集”设置

配置文件“GL：数据访问权限集”的取值LOV需要在系统中另外设置，每个取值包含了若干已经定义的分类帐/分类帐集及其读写权限，用户进入后，可在表单界面于其中选择切换，如图 3‑20所示。

图 3‑20 R12 配置文件“GL:数据访问权限集”可用值的设置

要特别注意，对于R12的“GL 分类帐名称”的任何一次修改（包括清空），都会自动影响“GL：数据访问权限集”的值。系统之所以如此设计，目的在于保证原R11的业务控制功能不变，通过增加参数，在R12中控制“可访问数据的范围”。因此正确的做法应该是：先设定“GL 分类帐名称”的值，实现基本的业务功能（与子分类帐产品关联），再修改“GL：数据访问权限集”的默认值，控制数据可访问范围，但必须保证其值包含了前者的值。

R12 在“创建分类帐、定义分类帐集”时会自动创建“数据访问权限集”LOV值，并且其类型为“全部分类帐”，提供完整读写权限。在需要进一步限制对分类帐、分类帐集或分类帐/分类帐集的特定平衡段值或管理段值的读写权限时，用户需要创建自己的数据访问权限集。

另外，在R12中还可以为财务系统特别定义“访问权限集”，并分配给责任来限制该责任所具有的功能（系统预置了一个不可修改的“超级用户定义访问权限集”）。如图 3‑21所示。

图 3‑21总账系统的数据访问权限的责任分配

注意不要该访问权限控制与参数“GL：数据访问权限集”的权限功能相混淆，因为这是在已经进入的当前“分类帐”之下的总账数据权限的控制，而不是能否进入相关“分类帐”的控制。

最后需指出的是，EBS系统所谓“多账簿”功能与“多帐套（分类帐）访问”功能是两个不同的概念。“多账簿”功能表示“一个用户的同一业务处理，系统自动生成多本帐”，反映的是系统业务处理功能，R12具备，而R11则不完全具备（R11仅能提供多币种报表）。“多帐套（分类帐）访问”功能表示“一个用户如何接入多个帐套（分类帐）”的权限管理方式（“上下文”环境切换方式）。R11虽也具备，但对于同一用户，必须通过在具有相同业务功能的不同责任间切换才能实现，使用时不是太方便，而R12的同一用户，无需进行“责任”切换，仅通过在表单上直接选择切换就能实现，使用比较方便。R12与R11的上下文切换方式虽然不同，但切换后的系统业务处理功能则基本相同。

3.5组织结构

在企业管理实践的过程中，“组织”（Organization）一词是个经常需用到的概念，一般与“人员”与“职能”这两个要素密切相关，反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等。企业内部行政组织（部门）的划分是企业基于“职能驱动”业务管理模式进行运作的基础。目前，适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际是默认包含了企业运作的“组织职能”划分特性。

但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题。一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。这种系统实现方式虽有理解、掌握比较容易的优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。国内有所谓高端管理软件在系统实施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的情况，导致系统陷入几乎无法使用的困境，其症结正在于此。

与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。作为ERP鼻祖的SAP将系统组织简单地分为“集团（Client）、公司代码（Company Code）、采购组织（Purchase Org）、销售组织（Sale Org）、工厂（Plant）”等类别。而ORACLE EBS的组织设置本质上与之基本相似，但作为后来者作了进一步抽象与简化，系统组织划分为“业务组（Business Group）、法律实体（Legal Entity）、业务实体（Operating Unit）、库存组织（Inventory Org）”等。

如果说SAP的组织模型字面上多少还带有一点“行政组织”痕迹的话（这可能是某些声称学SAP的国内产品误入歧途的原因），ORACLE EBS系统的组织模型字面上已经几乎看不出与“行政组织”还有什么关系，其中的“Inventory  Org”现今中文翻译成“库存组织”，容易令人望文生义和企业的“仓库管理部门（Warehouse）”混淆，但Inventory的本义实际应该是“存货”，称之为“存货组织”或许更好一些。如图 3‑22所示ORACLE系统有关核心业务的多组织模型。

图 3‑22中的“财务、销售、采购”并非系统单独存在的“组织实体”，它仅表示业务实体（OU）所具有的相关业务处理功能。“子库”是特殊的系统组织实体，没有上下文环境可进入，主要表示库存组织之下的某种业务功能。

图 3‑22 EBS 多组织系统模型

3.5.1业务组（BG）

EBS所谓“业务组”的概念可以与企业的“集团”概念相参考，但不同的是一个企业在系统中可以设置多个“业务组（集团）”。通常对于一个企业来说，系统中有一个“业务组”就够了，这表示企业就是一个“集团公司”。而对于某些业务“多元化”的特大型公司（如跨国公司），则可能需要在系统中设置多个“业务组”，表示企业由多个“集团公司”组成。

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

图 3‑23 EBS 初始安装预置的业务组

当以系统预置超级用户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下的所有新建组织，名称不允许相同。

3.5.2法人实体（LE）

法人实体（LE，Legal Entity）对应于真实世界中的按国家法律法规要求注册的“法人公司”。在R11中，LE在组织表单定义时，对于每个LE必须为其“法人主体会计科目”关联一个“帐套SOB”。每个LE对应一个SOB，这与真实世界的法规要求是吻合的。如图 3‑24所示。

图 3‑24 EBS R11的法人实体设置

要注意的是，在R11中定义LE时，并未作与“会计科目弹性域结构”的“公司段”值关联，用户必须对于其是与公司段值中的哪个值对应心中有数。而在R12中，原库存或人力资源模块的“组织”表单设置功能，已经不能设置（创建）“法人主体”，改为在专门的“法人主体配置器”中设置，已经在“法人主体配置器”中创建的“法人主体”在“组织”窗口无法被查看。有关R12的“法人主体配置器“功能的使用，因比较复杂，请参看本书（下部）最后章节“EBS R12全新系统的基本设置过程与业务流程测试实例”中的相关内容。

R12改为在定义“分类帐”时的“会计科目设置管理器”中分配法人实体LE。一个分类帐设置（主/辅分类帐）可以添加多个LE，但每个LE只能具有一个分类帐设置。如图 3‑25所示。

图 3‑25 R12 分类帐的法人主体分配

在R12中，还必须为法人主体分配会计科目弹性域结构的公司段即“平衡段值”。每个LE可以分配多个“平衡段”值，公司段值集中每个段值一旦被分配给某LE，则其它LE就不能再被分配。

此外，在R11或R12中创建一个LE后，应当及时到会计科目弹性域结构中添加需要对应的公司段值LOV（一个或多个），并重新进行弹性域的编译，否则系统可能会弹出错误报警信息。R12中一个LE可对应多个公司平衡段值，代表有多个分公司，LE是它们的合并。主/辅分类帐可拥有相同或不同的公司段值集，表示从不同的维度（如按地区、按产品等）去划分公司以方便考核。如图 3‑26所示为LE添加平衡段值。

图 3‑26 R12 法人主体分配平衡段值

对于R11来说，法律实体LE的设置对具体的业务处理影响不大，其与系统用户或责任不关联，不直接影响系统上下文的切换，故有人甚至认为EBS R11的LE设置作用不大。这对于系统的内部运作来讲情况确实近似如此，但对于需要通过系统产生供外部使用的具有法律意义的文书（如采购订单、财务报表等等），严格区分法律主体LE还是必须的。而对于R12来说，显然更多地考虑了外部使用的这种法律要求（即所谓“法规遵从性”或“合规性”），并在相关业务应用模块的权限控制管理中有所体现，例如R12的税务设置、银行账户使用等。

3.5.3业务实体（OU）

业务实体（OU，Operating Unit）是EBS系统组织设置的重点也是难点之一。它与法人主体LE本身没有必然的关系，与会计科目弹性域结构中的“公司段”也没有直接关系。从企业实际业务管理需要的角度去看，业务实体OU可以看作是在系统中按照业务的相似性，把多个不同公司（包括LE）的业务处理过程及数据划分成相对独立的“管理单元”。在每个管理单元内部，各公司的业务运作共享相关数据并执行统一的业务策略。

例如，有一个业务多元化的企业既生产医院使用的X光机也生产普通电视机，并且其下属在全国各地有多家生产X光机或电视机的分公司、子公司。由于这两种产品所使用的物料、供应商以及针对的客户群差异很大，企业为方便管理，可以将“业务运营”划分为两个相对独立的“业务管理群组”，对应到EBS系统中就是两个业务实体OU。

从企业日常业务运作管理的角度来看，对于单纯的电视机业务，全国范围内就设一个公司负责计划、生产、采购、销售等运营管理最为简便，但企业从非运营管理角度例如“税收优惠、地方政策”等等因素考虑，有时不得不在全国各地乃至世界各地注册若干所谓“法人公司”，以便向当地政府纳税并接受其财务会计方面的监管。

EBS在一个业务实体OU下，例如“电视机管理群组”，包含了全国各地所有负责生产或销售电视机的分公司、子公司（LE）的日常业务运作，在业务运作的组织层面忽略了作为法人实体的公司信息，但在反映业务运营最终结果的财务阶段（GL），仍能够方便地按照各地的法规要求提供财务数据与结果。而对于负责具体业务的系统用户来说，日常工作几乎不用关心或考虑“法人公司”的设置问题。

EBS中LE的数量可以根据需要任意增加，但对于OU的数量基于管理方便性则要求尽可能精简。EBS产品早期在实施过程中，存在一个公司（LE）对应一个OU的做法或一个OU只能属于一个LE的说法，这种做法或说法并不恰当。某些低端产品的设计由于未能有效区分“法人主体（公司）”与“业务实体（运营）”两者在系统中既相连接又有本质区别的特殊关系，只好采取一个法人公司对应一个系统业务实体的“笨办法”，企业规模小倒还能对付，一旦规模变大，注册公司增多，所谓的“系统多组织架构”就变得根本不具可用性。

ORACLE EBS业务实体OU的系统特性极大地方便了企业运作的日常管理，具有高度的灵活性与可扩展性。如图 3‑27是R11的OU定义界面。（R12 的业务实体虽也可以类似R11在“组织”功能中完成，但有一定的限制条件。R12的业务实体通常是在“会计科目管理器”中进行设置的，具体请参看本书（下部）最后章节“EBS R12全新系统设置与业务测试实例”中的相关内容。

图 3‑27 R11 业务实体设置

图 3‑27中的“业务实体信息”中，必须而且只能为之设定一个“帐套”，即一个OU只能属于一个帐套（反之，一个帐套可以分配给多个OU）。要注意的是，上述业务实体信息中的法人实体设定，并不代表OU只能属于一个LE，它只是表示在“业务实体”中进行业务操作需要法人实体信息时提供默认值（在R12中明确了是“默认值”这一点）。

在EBS中，一个OU可以同时指定给多个LE，上面“电视机管理群组”的例子已经说明了这一点；一个LE也可以有多个OU，这相当于一个注册的法人实体公司下，有多个需要独立运营的“事业部”（如X光机和电视机）。OU与LE是“多对多”的关系，但有一个限制性的前提条件，即OU与LE必须属于同一个SOB或Ledger。由于LE与OU的设置在系统中可以独立进行，因此如果双方的SOB或Ledger不同，则不能建立连接关系。

如果说法人实体LE与真实世界的企业行政管理组织架构还有点关系的话，业务实体OU则是与行政管理几乎无关，企业内部的行政组织变化对OU的设置没有直接影响。在EBS中有关采购管理、销售订单履行、应收应付管理等业务模块的功能均是建立在OU基础之上的。用户在执行上述相关模块的业务处理时，总是必须进入确定的OU（上下文环境）才可以进行，EBS的所谓“多组织”功能（MOAC）实际是针对多业务实体OU而言的，与真实世界中的“多公司”（LE）没有多大直接关系。

实际上，SAP的“采购组织、销售组织”设置也是与真实世界的行政组织“采购部、销售部”无关的，ORACLE抛弃了“采购组织、销售组织”的概念，OU实际上就起到了类似的组织分隔作用。ORACLE在某些官方文档中，如果因描述需要而提及所谓“采购组织、销售组织”等概念，大多数情况下实际指的就是业务实体OU。（但有时也可能是指OU下的库存INV组织）。

3.5.4库存组织（INV）

ORACLE EBS的库存组织（INV）是系统组织设置的最基础、也是最重要的工作之一。库存组织的内涵远不是真实世界的“仓库部门”那么简单，它除了是有关“物料接收与发出”等业务功能的基础之外，更重要的是，它还是EBS系统有关计划（MPS/MRP）、在制品管理（WIP）、物料清单（BOM）、发运管理等模块业务功能的操作与管理平台。如图 3‑28所示（R11与R12完全相同）。

图 3‑28 库存组织设置

EBS中的库存组织INV的作用与功能可以与SAP中的工厂Plant参看。一个库存组织INV只能属于一个确定的帐套SOB（分类帐）、一个确定的法人主体LE、一个确定的业务实体OU，具有唯一性的关系（注意：R11的设置界面未考虑SOB/LE/OU的关联限定，容易产生错误；R12作了改进，在选定Ledger之后，可用的LE/OU就被限定）。反之，一个“帐套（分类帐）/法人实体/业务实体”组合则可以有多个库存组织INV。此外，一个OU下的多个INV可以对应属于该OU的不同LE，这相当于将分属于两个法人公司的生产两种产品的四个工厂，按相同产品两两组合抽取出来，分属于两个不同OU进行日常业务管理。

在EBS中还有两个组织概念“MRP组织、WIP组织”，它们实际是必须构建于库存组织之上的组织概念，表示该库存组织还可以（或需要）进行MRP或WIP的功能（但实际相关设置并无控制作用）。对于绝大多数基于库存组织INV的业务功能（个别除外），系统用户在做业务操作时，均必须首先进行INV组织的选择切换，以便进入确定的INV组织上下文环境。库存组织的作用是如此基础，以至于ORACLE的官方文档在提及组织（Org）概念时，如果未作特别说明，默认就是指INV组织。

3.5.5公司成本中心（Cost Center）

EBS的所谓“成本中心组织”并没有业务处理的功能，它的设置主要是考虑与“会计科目弹性域结构”中的“公司段值”与“成本中心段值”的对应关系问题。如图 3‑29所示。

在系统中创建“公司成本中心组织”后，可以运行一个“并发检查程序”，以校验“会计科目弹性域结构”中的段值是否与所有的“公司成本中心”组织的设置保持一致。当在“会计科目弹性域结构”中的“成本中心段”值集中添加LOV值并重新编译后，也可以运行系统的“自动组织”并发程序功能，由系统自动创建“公司成本中心”组织。

图 3‑29成本中心设置

应当注意的是，一个公司成本中心组织及其成本中心段值，不可能属于不同法人实体LE及其公司段值，这与真实世界中的管理要求是一致的。库存组织INV与会计科目弹性域中的“成本中心”段（部门）则具有“一对一或多对一”的关系，即一个“成本中心”段值可以有多个库存组织INV，但一个库存组织INV只能属于一个确定的成本中心。

3.5.6人力资源组织（HR）

系统的人力资源HR组织设置与HRM模块的相关业务处理功能相关，与核心业务/财务处理功能关系不大，主要是需要注意其是否和“成本中心”关联，需要时可以输入“成本中心”代码，其LOV就是“会计科目弹性域”结构中成本中心段的值集。如图 3‑30所示。

图 3‑30HR组织设置

3.6多组织访问

在EBS组织设置界面中，所谓的组织“类型”（Type）划分仅是基于组织自身的统计分析工作需要而定义的一个“维度”，例如“公司总部、产品线”等等，并不影响系统的业务处理功能。真正起作用的是设置界面中的“组织分类”（Classification），系统预置的组织分类LOV除了上述“业务组、法律实体、业务实体、库存组织”等之外，还有诸如“资产组织、运营公司、雇主”等等选项。在EBS系统中各应用模块所具有的业务处理功能通常需构建在一个确定的“组织分类”之上，“组织”是相关业务处理功能的平台，企业是否需要作相关组织分类设置、如何设置，取决于企业所需要使用到的应用模块功能。

例如所谓“资产组织”的设置，它是在企业需使用到资产管理模块FA时才涉及到。“资产组织”实际上是所谓“资产账簿”的代名词，它只是表示有关资产信息的一个数据维度，作用主要在于分隔数据范围，用户进入系统作业务处理时，并不需要作上下文业务环境的切换。对于这类并不涉及“上下文”环境切换的所谓“组织”，ORACLR系统的设计主要是为了借用“组织”所具有的“层次结构”（Hierarchy）概念来达到“多组织接入”权限的控制功能。

需指出的是，这里的组织“层次结构”与真实世界企业的行政管理组织层次结构没有直接关系（尽管可能有所参考），它只是企业根据某种需要（如权限管理控制、数据统计汇报等）而人为设定的一个“层次结构”，例如将系统中已经设置的任意数量的“业务实体”或“库存组织”等等组织名，人为地设定一个具有上下级关系、自顶向下的金字塔形多层结构。如图 3‑31所示。

图 3‑31 EBS 的组织层次结构设置

图3-31中开始定义组织结构层次时，一旦选定（最）顶端组织名，则就只能为之分配下属组织名，如要给下属组织分配更下一级的组织，则需点击“向下”按钮，将当前该下属组织上升到“顶端组织”位置。点击“向上”按钮，则将当前“顶端组织”下降到下属组织位置。企业可以根据实际需要设定若干个具有不同内部结构的“组织层次结构”名称，以供定义系统所谓“安全性配置文件”时调用。如图 3‑32所示。

图 3‑32 安全性配置文件设置

图 3‑32中所定义“安全性配置文件”是系统用以控制包括“组织安全性”等在内的各种安全性控制的基础，它具体规定了系统安全性控制的范围与实现方式，所有定义的“安全性配置文件”名构成系统多组织接入控制参数“MO：安全性配置文件”的LOV。如图 3‑33所示。

图 3‑33“ MO：安全性配置文件”的设置

EBS 通过“MO：业务实体”、“MO：安全性配置文件”、“MO：默认业务实体”这三个系统配置文件的共同作用，实现所谓“多组织接入”控制功能MOAC。但上述三个配置文件在R11与R12中的作用有比较大的差别。

对于“MO：业务实体”， 在R11中必须设定，而且起决定性控制作用，其LOV由系统基于创建的OU name自动创建，用户登录时系统自动定位于指定OU。而在R12中，一旦设定“MO：安全性配置文件”，则此配置文件失效而不起作用。

对于“MO：安全性配置文件”， 在R11中虽有，但实际不起OU接入的控制作用，只针对FA等模块的得某些应用如数据统计等起作用。因此，一般认为R11并不具有完善的多组织接入控制功能。在R12中，该参数如果不设定，则必须设定“MO：业务实体”参数；一旦“MO：安全性配置文件”参数被设定，则就起决定作用，系统主要依赖其实现MOAC。

对于“MO：默认业务实体”， 在R11中虽有但实际不起作用。在R12中，随“MO：安全配置文件”起作用后才起作用，其LOV是所有已定义OU，但如果设定值不在“MO：安全配置文件”所选择的“组织层次架构”的范围内，则仍不起作用（即在与OU相关诸如PO、OM等的FORM界面，OU字段的默认值仍然为空）。这似乎是ORACLE 系统设计方面的一个难题，即“MO：默认业务实体”的LOV值集无法与“MO：安全性配置文件”中“组织层次架构”中的OU值范围保持一致。

ORACLE强调其“多组织接入MOAC”功能主要是针对业务实体OU而言，其另外一层含义是，所有构建于库存组织INV上的应用功能，实际是与上述配置文件无关的。库存组织的可接入性是在“组织访问”控制功能中，专门设定库存组织与“责任”的关联性，如图 3‑34所示。

图 3‑34 库存组织的访问权限设置

按照ORACLE的说法，如果系统在初始的时候，不定义库存组织的“组织访问”控制，则所有“责任”可访问所有INV，一旦限制或分配其中一个，则其余均必须逐个进行分配以建立“库存组织”与“责任”的链接关系。

总之，EBS系统通过“弹性域段值安全性”、“帐套/分类帐安全性”、“多组织接入安全性（MOAC）”、“库存组织访问控制”等多维度、多方面的组合系统设置，提供了灵活、方便的用户权限管理功能，厘清并掌握它们的复杂关系是系统实施的一项重要基础性工作。

3.7基础数据

基础数据通常是指与具体业务关系不大且具有全局性、基础性的一些基本数据，例如日历Calendar、币种Currency、汇率Rate、单位UOM、地点Location等。这些基础数据的系统设置有些比较简单如“币种”，有些与真实世界的情况相似如“日历”，有些则可能比较抽象复杂如“地点”等等，情况多种多样。以下择其要者，作相关说明。

3.7.1设置日历

EBS中的日历设置，实际包括两大类，一类是与会计工作相关的，包括“会计日历”、“会计事务处理日历”等，它们的使用范围较小，有专门用途，一般是在总账模块设置（略）；一类是工作日日历，它与企业的日常业务工作相关，使用范围广泛，大多数涉及库存组织的业务模块都可能与之相关。如图 3‑35所示。

图 3‑35工作日历设置

图 3‑35中，“日历日期范围”的“起始日期”（周几）选择，与“工作日模式”设置，将共同决定“休息日”是在周几。调整“起始日期”可以将“休息日”选定在“周六、周日”；“例外休息日”，需要在“例外清单”中人工输入具体的例外日期。系统初始安装时虽有预置的“工作日历（名）”（需修改更新后才可用），但实际通常都是自定义新的“工作日历（名）”以用于系统相关设置。此外，需要注意的是，在自定义新增“工作日历”或更新已存在“工作日历”后，需要通过在工具栏的“建立”功能启动一个后台并发程序，以最终完成设置工作。

3.7.2设置币种

各国或地区的“货币”币种是一种客观存在，EBS系统初始安装已经预置了几乎所有企业可能使用到的币种，必要时还可以添加。用户可以决定哪些币种需要启用，以及维护其使用时的“精确度”。如图 3‑36所示。（注意，系统初始安装时仅默认启用了USD，其它币种需作启用设置）

图 3‑36币种设置

3.7.3设置汇率

企业对于不同币种汇率转换的管理是一项重要的基础性工作，它对企业的经营结果有重要影响。为方便该项工作的开展，EBS 在总账GL系统专门提供了一个名为“币种汇率管理器”的工具，如图 3‑37所示。

图 3‑37 币种管理器

企业可以使用“币种汇率管理器”，根据工作需要设定多个“汇率类型”（系统初始安装已预置了Corporate等值），并为之维护“每日汇率”或基于帐套的“期间汇率”，汇率的维护可以按一段时间范围来进行，也可以通过外部的“电子表格”导入数据。“币种汇率管理器”实际是将原先UI界面相对独立的“汇率类型定义、每日汇率维护、期间汇率维护”系统功能，用WEB页面整合统一起来，实际内容并没有变化。用户仍可以使用原“汇率类型定义、每日汇率维护、期间汇率维护”的UI界面功能。有关详情请参考本书（下部）最后章节“EBS R12全新系统设置及业务测试实例”的相关内容。

3.7.4设置单位

计量单位虽然也可以看作是一种客观存在，但单位与基本单位之间的转换关系，则可能是与具体物料相关的（例如鸡蛋1斤=15个，鸭蛋1斤=10个等，转换系数不同）。由于EBS的物料是定义在库存组织INV上的，故单位及转换关系也是基于库存组织INV设置的。如图 3‑38所示。

图 3‑38单位设置

EBS的单位转换，提供了不考虑具体物料的“标准转换”，例如1米=100厘米等，也提供了基于不同物料的在同一“单位分类”（如长度、重量、体积等）内部的转换，例如牛奶 1箱=20盒，茶叶 1箱=10盒等；以及不同物料在不同“单位分类”之间的转换，例如牛奶 1公斤=4盒，茶叶 1公斤=2盒等。注意。系统初始安装时，“单位”无可用预置值，需全新设置。设置单位虽然需要在确定的库存组织上下文环境之下，但实际是数据可以在库存组织间共享的。

3.7.5设置地点

EBS中所谓“地点”的概念不仅非常抽象，而且十分重要，因为系统相关业务处理功能如“接收、发运、人员分配”等等都与“地点”密切相关。EBS中的所谓“地点”原意实际上涉及三个词：Location、Address、Site。译成中文称为“地点”，也是导致其理解困难的重要原因之一。系统初始安装不可能有预置值可用，必需根据企业实际情况，对全部可用的“地点“进行相关设置。如图 3‑39所示。（为了区别清楚，使用英文界面显示）

图 3‑39地点（Location）设置

Address（地址）比较好理解，它表示一个地理坐标概念，例如“北京市朝阳区安定路甲3号”等，EBS系统以一个“说明性弹性域”来精确描述，非常方便。各个国家的Address表述格式可能不同（如中国与美国有差别），故系统有所谓“中国式地址”、“美国式地址”之分等等。

Location（地点）的系统涵义则理解比较抽象，系统定义的名称可以看作是与一个具体Address相关联的一个或多个不同“称谓代号”，例如与上述Address“北京市朝阳区安定路甲3号”关联的Location“鸟巢、国家体育场、奥林匹克公园、奥运主会场”等等。也可以是一个不与具体地址Address相关联但大家都明白的称谓代号，例如Location“天安门、首都机场”等等。

EBS系统最初使用比较“简短”的Location代替比较“冗长”的Address，仅仅是为了方便IT“标准化”处理的需要。但在以后的发展过程中，系统设计逐步赋予Location更多与业务处理功能相关的“属性”，为了区分这些不同属性，系统又以更加虚拟的Site（站点）来加以区分，如图3-39中所示。一个Location可以具有“发运到Ship-to”、“接收至Receiving”、“开票到Bill-to”、“内部Internal”等等不同（Site）的系统功用。

更进一步，EBS系统使用“地点”来实现采购申请、接收、运输清单和人员的分配，以及确定内部组织与内部客户、供应商的关联关系；使用同一供应商的不同Site来区分定义供应商所具有的不同“业务控制”属性；使用同一客户所具有的不同Location—Site组合来区分定义客户所具有的不同业务功能（OM的某些业务功能必须将客户的外部Address—Location组合与系统内部Location关联方才有效）等等；详情以后相关模块再进一步讨论。

总之，搞清楚EBS系统Address、Location、Site的三者关系，对于理解掌握系统功能十分重要，其核心与关键是不能将比较抽象的Location或Site与比较具体的Address相混淆，两者虽有一定关系，但Location或Site更多地是从系统实现的需要出发，而做的某种“形而上”表达。

3.8并发管理

ORACLE EBS系统在后台通过运行大量“并发处理程序”的方式保证相关业务功能的实现，系统需要对这些在后台运行的“并发程序”进行有效管理，这是通过所谓“并发管理器”来实现的。系统后台可以有多个不同的“并发管理器”来管理不同的并发程序，“并发管理器”本身实际上也是并发程序，对于这些多个“并发管理器”，系统也要通过“管理并发管理器”菜单功能进行相关设置。

系统内存在的所谓“并发管理器”按功用划分主要有三大类：内部监控程序、并发管理器、事务处理管理器。“内部监控程序”类型的管理器的功用是“监测处于并行并发处理环境下的内部并发管理器”。“并发管理器”类型的管理器的功用是“启动运行并发程序”；“ 事务处理管理器”类型的管理器的功用是“处理客户端用户发出的同步请求”。

系统在初始安装后，已经预置有若干不同类型的20多个管理器，系统也允许用户根据特殊需要自定义新的管理器。以下重点介绍几个重要的系统预置管理器的有关内容。

3.8.1内部管理器

“内部管理器”充当所有其它管理器的“上层管理器”。内部管理器可以对单个管理器进行启动、验证其状态、重置以及关闭等操作。用户不能改变其定义（工作班次、特殊规则）。如图 3‑40所示。

图 3‑40 内部管理器

3.8.2标准管理器

“标准管理器”可接受任何请求，它无特别的规定。标准管理器始终处于活动状态，即一年 365 天，一天 24 小时全天候工作。标准管理器可作为安全网使用，因为它始终可用于运行任何请求。其定义一般不可轻易更改，否则可能导致某些程序无法正常运行。如图 3‑41所示。

图 3‑41 标准管理器

3.8.3事务处理管理器

常规并发管理器只允许“异步”执行运行时间长、数据密集的应用程序，而事务处理管理器则也支持“同步”处理客户机端发出的特定请求（并发程序请求运行计划的“立即”执行选项，本质上仍属于“异步”方式）。如果客户机程序发出同步运行服务器端程序的请求，则事务处理管理器会立即运行此请求，然后将状态返回至此客户机程序。事务处理管理器会等待由客户机程序发送信号，而不会轮询并发请求表来确定该如何执行操作。如图 3‑42所示。

图 3‑42 事务处理管理器（库存管理器）

事务处理（库存）管理器（系统内部使用，“同步方式”）管理包括“物料事务处理、移动事务处理、资源成本事务处理、物料成本事务处理”的系统“联机”处理。系统在用户等待时“同步”作相关事务处理的处理，并且在完成后才将系统控制返回给用户。这在业务量较大、系统繁忙时，用户等待的时间可能较长，影响用户的工作效率。

对于事务处理（库存）管理器（请求使用，异步方式），如果相关配置文件“TP：INV 事务处理处理模式”设置为“并发”或“后台”模式，则用户应当启动“物料事务处理、移动事务处理、资源成本事务处理、物料成本事务处理”并发流程于适当的“周期”运行状态。通常在事务处理工作量比较大时，应采取这种方式，以节省在库存管理系统锁定事务处理窗口和处理事务处理时所花费的空闲时间，提高用户的工作效率。

由于“事务处理”在整个EBS系统运行中的普遍性与重要性，系统为此提供了一个专门的界面功能（菜单项，非系统管理员也可授权使用）以满足对相关“事务处理”并发程序的管理监控（“启动管理器”的工作方式与提交“请求”类似），如图 3‑43所示。

图 3‑43 接口管理器

上述“事务处理（库存）管理器”所管理的事务处理并发程序（成本管理器等），每个系统只运行一个“实体”，为所有组织、用户服务，故系统设置必须对其运行方式进行恰当的“计划”。与之类似的重要系统事务处理并发程序还有“计划管理器”（受“MRP管理器”管理），“接收事务处理处理器”（受“接收事务处理管理器”管理）。

要注意的是，系统许多业务流程类的事务处理“并发程序” 由于承担的后台任务比较复杂，实际起着某种业务流程运作的管理作用，故习惯上也可能以“××管理器、××处理器”来命名，例如“计划管理器（控制计划系统有关预测冲减、需求冲减等等事项的自动程序，）、成本管理器（控制数据的自动计算与更新等等事项的自动程序）、接收事务处理处理器（控制PO接收的库存更新等事项的自动程序）”等等，但它们本质上仍只是一个“并发程序”，不能将之与上一层的管理这些并发程序的真正“并发管理器”相混淆。

3.8.4管理并发管理器

全新的系统在初始安装时，除负责管理“计划管理器”的“MRP管理器”定义，需设置“工作班次”的流程数之后才可使用之外，其它重要的“并发管理器”均处于默认的工作状态。设置并发管理器时需要用到的“工作班次”（系统初始已经有预置值Standard），可自定义设置以作为LOV。工作班次可以同时运行的“流程数”在设置并发管理器时应设置适当值。如图 3‑44所示。

图 3‑44 并发管理器的工作班次设置

“并发管理器”定义时需用到的“特殊规则”（系统初始无预置值），可直接输入“包括或排除”类型为“程序、请求类型、用户、ORACLE标识”的具体条目组合。这些条目的组合也可以事先定义为各种“组合规则”，供定义“并发管理器”时作为LOV调用。如图 3‑45所示。

图 3‑45 并发管理器的特殊规则设置

有关“并发程序”的运行计划及其“并发管理器”的定义工作，应当考虑系统的负载均衡，以保证系统的性能与运行效率。对于系统运行的所有“并发管理器”，系统管理员可以在“管理并发管理器”窗口进行干预、管理，如“终止、重新启动”，以及查看“并发管理器”正在管理的“哪些程序”正在运行等等。如图 3‑46所示。

图 3‑46 并发管理器的管理

企业在系统使用过程中，基于业务变化发展的需要，不断地自定义开发各种“报表类”并发程序是一项重要的日常工作。这些自定义报表并发程序的系统管理方式没有什么特殊性，它们可以使用系统预置的“并发管理器”进行管理，也可以自定义新的“并发管理器”。

对于EBS系统中处于各种运行状态的并发程序，系统管理员可以在“请求”窗口，通过设定不同查询选项（如特定请求之状态、阶段等等），查询监控相关“并发程序”的进程状况，并根据实际情况作出处理（如暂挂、重启、取消、诊断等等）。如图 3‑47所示。

图 3‑47 并发请求的监控

3.9工作流

系统关于工作流的设置工作包含三部分内容：一是为系统设置工作流管理员，并在必要时根据业务需要设置工作流运行属性，控制工作流的运行方式；二是对相关“工作流进程”进行监控管理，并根据需要对工作流进程进行干预；三基于企业的特殊需要，使用Workflow Builder软件包工具自定义工作流（这部分内容比较复杂、技术化，故略）。

3.9.1工作流管理与监控

系统在安装后的初始化工作流管理员是系统超级用户SYSADMIN，企业应当首先使用SYSADMIN进入系统，将工作流管理员改为一个真实的用户，或者输入“*”，则所有用户都“可以”具有工作流管理员权限（用户实际是否有工作流管理权限还必须取决于其被赋予的“责任”或“菜单”功能），如图 3‑48所示。

图 3‑48 系统工作流管理员的设置

系统所有工作流类型在初始安装之后，无需特别设置均可以直接使用。必要时，工作流管理员可进入“开发员工作室”TAB页，查找出有关“工作流类型”，并根据业务管理需要自定义修改设置其运行“属性”，以便控制其运行方式。如图 3‑49所示。

图 3‑49 工作流类型查找

图3-49中，工作流管理员选定具体需设置的工作流后，点击“运行”则可以打开该工作流的“属性”设置界面。不同工作流可设置的“属性”可能各不相同。工作流的相关属性设置，除了某些必需值（在系统初始安装时已经有默认值）之外，其余都是可选的。如图 3‑50所示。

图 3‑50 工作流属性设置

工作流管理员在工作流管理“状态监控程序”TAB页，可以监控选定工作流的具体运行情况的若干条目列表，针对每一个条目，可以查看其“活动历史记录、状态图、参与者回应、详细资料”等若干信息，必要时根据实际工作需要，工作流管理员可对系统有关业务流程的用户操作活动实施干预，包括更新属性、倒退、暂停、取消等。典型的工作流管理员活动干预如“撤销原单审批并退回、审批人更改”等等。如图 3‑51所示。

图 3‑51 管理员工作流状态监控

对于每一个普通用户，可以使用“工作流列表”菜单功能，查看与自己的业务操作相关的有关工作流的相关信息。如图 3‑52所示。

图 3‑52 R11普通用户工作流状态监控

3.9.2账户生成器流程

系统在各应用模块基于业务处理功能，预置有若干不同工作流，有关详情本书以后相关章节会结合具体业务模块应用再作详细讨论。以下重点介绍一个比较特殊的工作流“账户生成器流程”。该流程在多个业务模块中均需使用，系统实施有初始默认设置可用，用户可以根据业务需要自定义修改其相关设置。

传统的手工业务模式下，所有可能涉及会计记账处理的业务处理例如物料接收、发出等等，作为业务处理人员在日常工作过程中是不需要考虑如何记账的，只是需要将有关业务处理记录例如入库单、出库单等作为原始凭证提交给会计人员去做处理。会计人员依据这些原始凭证制作“记账凭证”并手工为之指定“会计科目”或“账户代码”，以便正确地向总账GL实施“过账”。

手工业务模式或会计电算化模式下，由于作为原始凭证的业务单据不包含准确的记账信息（会计科目或账户代码），需要会计人员手工去做处理，这在业务量很大，记账科目数量设置较多的情况下，会计人员的工作负担将十分繁重。再考虑人工处理难免有疏漏，可能需要反复“对账”，每月月底必须及时结账关账、时间紧迫等等因素，故非人工的、高度准确的“会计分录（日记账）”自动生成功能（即所谓“自动会计”）就是系统设计时必须考虑解决的重要问题。

在EBS系统中，账户代码被扩展为一个包含多个段组合的会计科目弹性域结构，系统在业务流程类表单例如采购订单、发票等做业务处理时，依赖所谓“账户生成器流程”根据业务处理的自身属性，自动生成准确的帐户代码组合并记录于业务表单的相关字段中，如图 3‑53所示采购申请界面每个申请行（分配）所对应的“会计账户”（弹性域结构）：

图 3‑53 账户生成器流程所所自动生成的会计账户

系统周期或人工启动向总账GL的“过账”流程，对符合条件的“事务处理”成批生成会计分录（日记账，是否还需复核审批视乎企业规定），一般来说无需再做繁琐的“对账”工作。这就大大减轻了会计人员的工作负担，记账科目数量的多少一般也不再成为使用的障碍。在手工或电算化模式下，由于需要人工分配会计账户，会计人员往往因为会导致工作量增大的原因而不愿意设置某些过渡性的“中间科目”，例如物料接收的“应计负债”等，这对于会计工作的合理性与准确性有不小的负面影响。

基于每个新定义的分类帐（帐套），EBS系统均会自动默认生成所需的“账户生成器”预置值。系统预置有14个账户生成器工作流类型，对于每个“账户生成器”工作流，如有业务需要，用户可以修改设置不同于默认值的“流程”（每个工作流类型的可用LOV值，用户可以使用Workflow Builder自定义修改调整或添加），如图 3‑54所示。

图 3‑54 EBS 系统账户生成器流程设置（默认）

“账户生成器”实际是基于“会计科目弹性域结构”而定义生成的。一旦某“会计科目弹性域结构”被用于设置分类帐（帐套），系统均会自动（启动相关并发程序）为该会计科目弹性域结构生成所需的“账户生成器”。自定义调整设置某“会计科目弹性域结构”的“账户生成器”，会影响到所有相关联的“分类帐（帐套）”的会计流程。会计科目弹性域结构不同，账户生成器流程设置可以不同。对于每个“账户生成器”，EBS都提供了默认的流程供使用。R11系统的账户生成器生成的账户代码被直接用之于向总账GL传送，而R12系统由于存在“多账簿”的不同“会计方法”因素，各子分类帐产品（业务模块）基于事务处理会计科目弹性域结构通过账户生成器而生成的帐户代码，在向总账GL传送时，还需结合“会计方法”中的“账户推导规则”等设置，才能在相应分类帐的总账GL生成正确的会计分录（日记账）。

3.10系统预置的有关数据与设置

对于EBS系统的学习与研究者来说，最合适、最方便也是最常用的测试系统是ORACLE 公司提供的VIS DEMO安装系统，仅当初学者对EBS系统的认识与使用水平达到一定程度时，才可以考虑安装一个全新的Fresh系统，并进行完整的系统基本配置练习。但是，在EBS的VIS DEMO测试系统的实际使用过程中，对于初学者来说，有时也会对DEMO系统中的某些设置与数据，产生“是系统安装时就预置的，还是系统安装之后自定义设置的”等疑问与混淆不清的问题，从而影响到实际的学习进程与。

对于初学者来说，理想的学习方式是在使用VIS DEMO测试系统的过程中，必要时可以与Fresh系统进行对比分析，以便能作出正确的区分判断。但这通常会受到系统安装条件的限制，不太容易做到。故本节内容将对初学者可能经常遇到，也比较关心的系统初始安装时的预置的有关基础数据与设置作必要的补充说明。必要时，读者可参考本书（下部）最后章节“EBS R12全新系统基本配置及流程测试实例”的相关内容。

3.10.1安全性管理的初始设置

一个全新安装的EBSR12系统（Fresh Database），以SYSADMIN用户名登录，密码为sysadmin（注意EBS密码区分大小写），Home Page 可见系统所初始预置的10多个“责任”中包含“系统管理员”（System Administrator），如图 3‑55所示。

图 3‑55 系统预置的超级用户及责任

进入系统的GUI界面后，在“用户”定义界面，可查询到有30多个初始化的User，比较特殊与重要的User 是两个“SYSADMIN、GUEST”，GUEST无密码设置，可以作为测试时的特殊用户使用。如图 3‑56所示。

图 3‑56 系统预置的用户

其中有些用户（User）是系统残留，并不可用，还有些是只有用户名，但并未为之分配责任。注意，图 3‑56初始的GUI界面预置的默认配色方案，为演示方便已通过系统配置文件“Java color scheme”做设置调整。

系统初始预置的“责任”有1500多个，范围涉及所有模块的几乎所有“岗位角色”，企业可基于自身的管理习惯制定相应的责任“命名规则”，以定义新的“责任”。如图 3‑57所示。

图 3‑57 系统预置的责任

系统初始预置的“菜单”有12000多个，基本上覆盖了实际工作中几乎所有可能应用的需要，如企业需要“个性化”的菜单显示效果（Prompt），则可以自定义用户菜单，形成特定的菜单结构。如图 3‑58所示。

图 3‑58 系统预置的菜单

为了控制相关责任（用户）可以使用的并发请求程序，系统预置了700多个“请求组”，如有必要可以自定义请求组，或对预置的请求组进行调整设置。如图 3‑59所示。

图 3‑59 系统预置的请求组

3.10.2配置文件的初始设置

R12系统配置文件总数有6600多个（版本不同，配置文件的数量会有一定差异），绝大多数有初始化的默认值，可以有需要时再来修改，有关系统配置文件的初始设置情况（系统配置时时尤其可能希望了解），可以使用工具栏“文件—导出”功能将它们全部导出，以方便的格式如EXCEL集中查看，如图 3‑60所示。

图 3‑60 系统配置文件预置值（导出）

有些必须设置且没有默认值的配置文件，例如“GL 分类帐名 ”、“MO：业务实体”等，由于其可用LOV取决于系统的其它具体设置如分类账（帐套）、业务实体OU等，故这些特殊的配置文件初始进入时会报错。这些少数的特殊配置文件是全新系统置时的重点与难点，在完成相关会计科目弹性域结构、分类账、组织架构等等设置后，应及时为这些特殊“配置文件”赋值。

3.10.3值集的初始设置

EBS系统初始预置有16000多个值集名（Value Set Name），包括近2000个“验证”类型为“无”，无需LOV的特殊值集名。如图 3‑61所示。

图 3‑61 系统预置的值集名

系统预置的值集名，也可以根据需要修改添加新的LOV行。用户通常需要对系统键弹性域与说明性弹性域所使用到的值集，根据企业具体情况，进行完善的定义设置（尤其是键弹性域所需使用的值集）。

3.10.4弹性域的初始设置

所有的“说明性弹性域”系统初始安装均无预置结构，均需根据业务需要全新设置。系统存在的说明性弹性域数量达2500多个，每个说明性弹性域均允许根据所设置的不同上下文参考字段值，设置不同的结构。系统预置有一个“全局数据元上下文”作为默认可用的结构设置。说明性弹性域的设置与使用通常与实际业务的某些特殊需要相关，故这里不作详细讨论。

键弹性域的系统安装预置，则可分三种情况，一种是系统已经存在且只允许存在一个弹性域结构名称（但无具体的结构设置），用户必需完善其结构设置。如“库存货位弹性域”等；二种是系统只有一个预置的结构名称实例，并无具体的结构设置，需要企业根据自己的情况自定义完成设置，或自定义新增弹性域结构名称并完成设置。如“会计科目弹性域”；三种是系统有若干个预置的结构名称，并已被应用于不同场合的多个应用。如使用范围广泛的“物料类别弹性域结构（Item Categories）”，系统已经预置有20个不同结构名称（部分有结构设置，部分则无），用户还可根据需要添加结构名称，系统预置的结构也可以进行更改。如图 3‑62所示。

图 3‑62 系统预置的物料类别键弹性域结构

弹性域结构的段也可以不选择值集而留空，则此时，此段就好象使用了这样一个值集：验证类型为“无”，格式类型为“字符”，宽度与基础键弹性域段列相同（即与弹性域系统设计所允许的段最大字符长度相同），允许混合大小写字母字符，无右对齐或填零。对于基础列不是“字符”列的任何段，则必须使用值集，否则将不能够编译弹性域。但需注意，“会计科目弹性域”必需使用值集。

已经定义并编译好的弹性域结构（键或说明性），在使用时均会打开弹出式窗口，以便逐段输入数据。但这样输入对于一些常用到的“代码组合”，既不方便记忆，也不方便输入，为此，ORACLE为某些弹性域结构的代码组合提供了“别名”（Aliases）定义的功能。例如，实际工作使用得比较多的“账户代码”的“账户别名”就是一个典型。

3.10.5单据编号的初始设置

单据编号的“自定义单据类别及编号方式”其“单据序列（编号发生器）”无预置值可用，需全新设置，而“单据类别”则存在部分“总账、应付、应收”可用预置值。如所图 3‑63示。

图 3‑63 系统预置的单据类别

而单据编号的“系统参数编号方式”与“数据库编号方式”，顾名思义，前者不可能有预置值，取决于系统参数中的设置，后者则不可能自定义，只能使用数据库自带的预置值。

3.10.6单据附件的初始设置

系统在初始安装时，已经默认定义了实际工作中可能需用到的各种附件“类别”并分配给了相应“附件功能”种类（表单或功能），可在“应用开发员”责任的相应菜单中查询可见。必要时用户可自定义添加新的附件种类（如“至采购员TEST”）并分配给相应“附件功能种类（表单或功能）”，如图 3‑64所示。

图 3‑64 系统单据附件类别预置值

用户也可以由“附件功能”菜单进入为确定的“附件功能种类”分配需要使用的“附件类别”，其结果与图 3‑64中由“附件种类”分配至“附件功能种类”相同，如图 3‑65所示。

图 3‑65 为附件功能分配附件种类

3.11全新系统设置的层次性结构

基于EBS系统设计逻辑的灵活性、可扩展性等内在特点，对于全新Fresh系统的设置来说，其设置内容与过程具有从“全系统公共层面设置”到“分支系统公用层面设置”，再到“模块系统层面专用设置”的层次性结构特点。了解并掌握系统这种“层次性结构设置”特点，不仅有助于实际工作中的实施团队合作，快速完成系统配置，而且对于系统功能的学习与研究也有很大帮助。

3.11.1全系统公共层面设置

不涉及具体应用模块或具全局性、属于EBS全系统层面的系统设置内容，主要包括“系统管理、弹性域、分类帐（帐套）、组织、物料相关”五个方面的内容。如图 3‑66所示表达了EBS（R11）全系统公共层面的基础设置内容与层次结构。

图 3‑66 EBS 系统的全系统公共层面设置内容结构

3.11.2分支系统公用层面设置

EBS核心系统习惯上可以划分为四大分支系统：财务、制造、分销、人力资源。每一大分支系统也有相关的公用层面设置，如图 3‑67所示是EBS（R11）公共“分销系统”的基础设置内容与层次结构（公共财务、制造、人力资源的相关层次结构比较简单，故略）。

图 3‑67 EBS分销系统的公用层面设置

3.11.3模块系统层面的专用设置

涉及具体应用模块的系统设置，情况就更为复杂，通常需要按照应用模块的设置流程图，结合全系统与分支系统的设置情况来决定具体如何执行。如图 3‑68所示是比较复杂的EBS（R11）采购系统的设置步骤与内容。

图 3‑68 采购系统的设置步骤与内容

对应上述设置步骤的是下述列表3-1清单。流程图和设置步骤清单包括了所有设置步骤，其中一些步骤是必需的，而另外一些步骤则是可选的。“具有默认值的必需步骤”是指虽然是必需，但系统安装时有预置的默认值可用，但通常需要复查一下这些默认值，以决定是否要对其进行更改。其中有些步骤在“全系统”或“分支系统”层如果已经设置，则在系统模块层就无需再执行这些设置步骤。

表3-1：系统模块层的设置步骤清单

如果要实施使用多个 EBS 系统模块产品，ORACLE建议使用 Oracle Applications 实施向导 (AIW，Oracle Applications Implementation Wizard User's Guide) 来协调整个设置活动。该“向导”将指导用户完成对已安装应用产品的设置步骤，给出满足交叉产品相关性要求的逻辑实施顺序并免去多余的设置步骤。用户可以使用“向导”来查看以图形表示的设置步骤概览、查阅设置活动的联机帮助和打开相应的设置窗口，通过使用“向导”来为每个步骤记录备注信息，还可以记录实施情况以供日后参考和复查。注意，EBS所谓“系统层、分支系统层”设置，仅就其影响与作用范围而言，并非有独立的系统存在，它们同样也是分散存在于各应用模块之中。

3.12结语

对系统基础设置的有关内容有一定的理解与认识，是后续学习掌握系统有关应用功能的基础，初学者应给予足够重视。不过，对于上述由“全系统层面”到“分支系统层面”，再到各“应用模块系统”的基础设置的具体过程与操作细节，对于初学者来说，在开始阶段有基本的了解即可，不一定要求能完全掌握。因为全新EBS系统的设置是一个复杂、繁琐且细致的系统性工程，过程的实践性很强。完整的、详细的全新系统设置过程涉及的系统模块比较多，范围比较大，完成的难度比较高，在对系统流程与应用功能的认识缺乏足够积累的情况下，急于求成可能只会达到“事倍功半”的效果，影响学习者的信心与耐心，反而不利于学习的进步与提高。

因此，本书建议初学者在对本章有关系统基础设置的要点内容有了相应的认识之后，不必急于去尝试完成全新Fresh系统的全部设置，而是按本书后续相关章节的内容安排，循序渐进，在至少完成了EBS供应链核心系统相关模块的“基本业务流程”与“基本应用功能”的学习之后，再在本书（下部）最后章节“EBS R12 全新系统设置与与业务测试实例”的内容指导之下，着手完成一个全新Fresh系统的设置过程，这样不仅符合对复杂事物的认识过程的规律，而且学习的效率与效果也会比较好。转载请注明出处:

转载自http://lxfamn.cn/blog

未经允许不得转载：lxfamn » ERP系统配置