Oracle权威资料EBS基础设置全手册SHP.doc

H:\精品资料\建筑精品网原稿ok（删除公文）\建筑精品网5未上传百度
ORACLE EBS 基础设置手册

一、 安全性管理
二、 会计科目弹性域结构
三、 帐套( 分类帐)
四、 组织架构
( 一) 业务组( BG)
( 二) 法律实体( LE)
( 三) 业务实体( OU)
( 四) 库存组织( INV)
( 五) 公司成本中心( Cost Center)
( 六) HR组织
( 七) 多组织接入控制
五、 基础数据
( 一) 关于”日历”
( 二) 关于”币种”
( 三) 关于”汇率”
( 四) 关于”单位”
( 五) 关于”地点”
六、 并发管理
七、 工作流
八、 系统初始化设置
( 一) 关于安全性。
( 二) 关于配置文件
( 三) 值集与弹性域
( 四) 分类账( 帐套) 与组织架构
( 五) 单据编号
( 六) 层次性设置结构
九、 结语
首先需要说明的是, 本系列文档假定读者已经具备基本的系统相关使用知识与技能(例如, 能够基本事会”ORACLE EBS系统应用基础概述”中的内容), 故所讨论的内容仅限于笔者认为从系统使用与实际业务两方面来看比较重要或者容易存疑的问题, 并不能面面俱到, 旨在帮助读者掌握核心、 抓住要点( 详尽内容必须参考ORACLE相关官方文档) 。文中为讨论需要所附图文均取自ORACLE EBS 的测试环境( Vision Demo) , 版本以R12.1.1为主, 辅之以版本R11.5.10, 界面语言主要为中文( 必要时辅之以英文) 。两个EBS版本在界面与功能应用方面实际可能有一些差异, 必要时会作相关说明, 但一般不会影响对基本问题的讨论。
技术是业务的抽象与工具, 业务是技术的来源与目的。本系列文档通篇将秉持”从业务的角度去审视技术, 从技术的角度去回归业务”的方法论( 这里的所谓”技术”, 意指”系统实现”) , 去探讨系统实现与业务实践的融合问题, 以求逐步能达到技术与业务的融会贯通。限于笔者的认知水平, 有讹误或不正确之处, 欢迎批评指正。

一、 安全性管理
 从系统使用角度来看, 系统管理的一项重要的日常工作是关于”用户”及其”权限”的管理, 在ORACLE中即所谓”安全性”( Security) 管理。”安全性”是一个涵义较之”权限”更为丰富、 更为广阔的概念术语, 它虽然比较抽象, 但顾名思义, 它很好地涵盖了于实际业务与系统使用中, 有关企业数据与信息管理的某些需要重点保护、 控制的内容。
有关用户权限的管理, 在ORACLE系统中主要有三个基本要素构成: 菜单( Menu) 、 责任( Responsibility) 、 以及用户( User) 。三者的有机结合构成了系统权限或安全性管理的基础, 辅之以参数或”安全性配置文件”等的使用, 则进一步对用户的”实体( 组织、 帐套或分类帐) 接入”权限进行细分。另外, 系统在各个应用模块中, 还将可能基于不同业务特点采取各具特色的系统实现方式, 对用户的准入管理或功能权限作更进一步的划分( 具体方式与系统设计者的个人偏好也有一定关系, 不能一概而论) 。
”菜单”( Menu) 在今天信息时代的日常生活中已是一个很普通的术语。ORACLE中的”菜单”概念并无甚特别, 它也是表示用户的系统应用功能入口。最基本的”菜单”由系统预置的若干”表单功能”所组成, EBS当前大概具有2万个左右的此类表单功能; ( 基于某些特殊需要, 系统还可提供虽不可见但可由表单内包含的逻辑调用的某些非表单”子功能”, 需开发后台设置) 。用户能够自定义包括若干基本菜单作为”子菜单”的用户菜单, 自定义的”用户菜单”也能够作为”子菜单”来使用, 这样就形成了一个菜单结构( 树形图) 。如图1所示菜单定义及可选择使用的系统预置表单功能LIST:

EBS系统在安装好后, 针对每个应用模块均已经预定义包括所有功能( 或权限) 所谓的”超级用户菜单”( Super User Menu) , 企业( 系统管理员) 在定义用户”责任”时可利用”排除法”来满足实际的业务管理需要。另外, 系统还提供了”仅具查询”功能的预定义菜单, 供某些需要限制做业务的用户使用。
相较于”菜单”的耳熟能详, EBS的所谓”责任”( Responsibility) 概念就生涩、 抽象得多, 一般能够将之与人们相对熟悉的”角色”( Role) 概念来参看。在企业管理中一般会将人员按”岗位角色”来划分, 例如”计划员、 采购员、 仓管员”等等, 它们一般对应于一定的岗位职责( 责任) , 有真实的业务管理涵义, 比较具体。系统预先定义的角色, 分配给用户( User) 后, 该用户就具有该角色的全部应用功能; 但EBS未象其它产品( 如SAP) 使用角色概念, 而是使用”责任”概念, 则更倾向于抽象地表示某些功能( 入口菜单) 的组合, 能够不具有真实的管理涵义, 比如所谓”销售经理”责任之下, 尽能够与”采购员”有相同的菜单项, 具有完全相同的功能, 而这一点如对应到实际的”岗位角色”, 显然是不合适的。Role更清楚直接, 但使用不够灵活; Responsibility可灵活使用, 但容易带来理解上的歧义与误会, 使用时要注意区分。如下图2所示的”责任”定义界面:

每个责任必须对应关联一个确定的菜单, 但能够使用”排除”功能使之具有不同的菜单结构组合, 这里的”排除”功能并不影响菜单原先的结构设置, 这方便并简化了系统管理员对”责任”与”菜单”的管理。”责任名”总是从属于某一”应用产品”( 模块) , 不同的模块可定义具有完全相同的”责任名”( 包括菜单) , 但这两个完全相同的责任名在”配置文件”作层次结构设置时, 能够具有不同的值, 这进一步提供了系统的灵活性。责任一经定义就不可删除, 只能经过设置有效期使之失效。为之设置”请求组”则限制了其能够使用的”请求”( 并发程序) 范围。至于其”可采用”应用产品范围设置( Web、 自助等) , 似乎只起到统计分析的系统管理作用, 实际并不影响具体的功能应用。
系统在安装后将具有一个名为”SYSADMIN”( 密码sysadmin) 且具有”系统管理员”责任的初始用户( 该用户有时也被称之为”超级管理员”) 。使用此初始用户可设置”菜单、 责任及用户”。如下图3所示”用户”的定义界面:

    每个定义的系统”用户”能够关联若干个不同的责任, 每个责任也能够设定用户使用的有效日期范围。具有多个责任的用户在登录使用系统时, 需要在不同责任间作选择切换, 并非能够同时使用。系统初始设置时设定的密码, 在用户初次登录时, 将被系统提示要求修改。密码能够设定”使用天数”或”访问次数”的限制, 系统的预警平台能够设置密码失效的提前预警, 以督促用户及时修改。”用户”一经设置也无法删除, 只能使用有效期设置使之失效。”用户”不一定必须和HRM模块设置的”人员”关联, 但对于有些模块的应用功能, 关联已经HRM恰当设置的”人员”则是必须的。而关联”客户”或”供应商”则主要起到统计分析的系统管理作用, 并不影响具体的功能应用。用户所关联的”电子邮件”地址, 主要是供系统预警平台发送信息使用。
关于EBS 系统使用相关”配置文件”诸如”MO:业务实体、 MO:安全配置文件、 HR:安全配置文件、 GL:数据访问权限集、 GL帐套名或GL分类帐名称”等等, 进一步对责任或用户的”实体接入”权限进行细分的问题( R12与R11比较, 变化较大) , 将在下面的”组织架构”设置中讨论。
关于具体应用模块中对责任或用户的权限作更进一步划分问题, 例如库存模块的”组织进入”( Access) 、 发运模块的”权限管理”( Grant) , 容后在相关模块文档中再来讨论。
 定义一个user, 能够给她多个responsibility; 一个responsibility对应一个menu, 但可根据实际需要禁用一些该menu中的功能和子菜单; 一个menu包括多个子menu。( 一般系统装完后就有了menu, 用户后期能够根据自己的需要再定义menu)
二、 会计科目弹性域结构
在讨论EBS的”组织结构”的设置之前, 有必要先讨论会计科目弹性域( Accounting Flexfield) 及其帐套( SOB) 或分类帐( Ledger) 的设置问题。”帐套”是R11及之前系统中的术语, ”分类帐”是R12中替代帐套并为有所区别而使用的术语。为表述方便, 后文如不特别指明, 习惯上的”帐套”术语将等同于”分类帐”术语。在EBS关于”组织实体”的概念范畴中, 帐套实际上也是”组织实体”的一种存在形式, 之因此如此和ORACLE产品的发展历史有一定关系。
会计科目是企业进行财务数据核算工作的基础, 各个国家基于企业监管与税收工作的需要而制定的会计法律法规都对之有相应规定。中国于 颁布的新会计准则将会计科目分为六大类: 资产类、 负债类、 共同类、 所有者权益、 成本类、 损益类, 共计156个( 一级) 科目。简单的财务会计软件或单公司规模很小时, 类似手工记账的”电算化”系统实现方式问题不大, 但当会计业务管理需求复杂, 企业从单公司向多公司集团化方向发展时, 就必须考虑在系统层面如何方便地对多个公司的会计数据进行集中统一管理的问题。
ORACLE的ERP产品最初也是从财务软件发展起来的, 总账GL是其第一个应用模块。事实上, 在计算机或管理软件出现以前, 企业所谓”集团管控”的需求及实践早已存在。ORACLE财务软件中包含”多公司信息”的独特会计科目弹性域结构设计, 使得财务工作的集团管控更加具备技术上的可行性与方便性。一个最基本、 最简单的会计科目弹性域结构就是”公司代码+会计科目代码”的组合, 它的原始业务需求来源并无多少深奥之处。
在ORACLE的会计科目弹性域结构中, 体现国家法律法规要求的”会计科目”成为其中必不可少的一个组成段即”自然账户”段, 自然账户所使用的值集, 即为一般所说的”科目表”。系统在自然账户之上附加”公司、 部门”等多个段信息, 大大方便了在公司内及公司间的会计数据的统计分析工作。如图4所示, 就是一个典型的5段式会计科目弹性域结构:

图中的”公司段”为”平衡段”( 弹性域限定词 Flexfield  Qualifiers, 是具有某种特定属性的”识别标记”) , 表示在”公司段”层面, 日记账( Journals, ”会计分录”) 的”借项等于贷项”, 总是平衡的。其值集为包含所有公司的代码LOV, 包括法律实体及基于公司管理需要而设定的运营实体; 如图5所示会计科目弹性域结构的”公司段”值集定义:

在EBS系统中定义的法律实体LE必须对应于公司段值集中的( 至少) 一个值( 行) , 但R11与R12的区别是, R11在定义LE时并没有明确告诉系统对应( 绑定) 哪个段值, 只要用户自己清楚并不混淆即可。而在R12定义LE时, 需要将其与会计科目弹性域结构中的某个公司段值明确关联, 这是R12的改进之处, 避免了R11实际使用中当定义的法律实体LE数量较多时可能产生的混淆不清。
”部门段”的弹性域限定词为”成本中心段”, 成本中心LOV值可能是企业中的一个具体行政组织, 也可能表示共享一个成本中心的多个行政组织的组合, 还可能是表示基于统计管理需要而设定的多个成本中心的组合; 如下图6所示:

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

注意, 图7与图5、 6中的”段限定词”的内容有所不同, 它具体规定了自然账户的段值所代表的会计科目的类别( 资产、 负债等) , ”弹性域限定词”与”段限定词”是两个不同的概念, 段限定词的取值受控于弹性域限定词的取值。
会计科目弹性域结构的”子账户段”表示”二级科目或明细科目”, 与账户段的一级科目具有汇总与被汇总的关系; ”产品段”, 则表示基于特定统计分析需要而设置的产品LOV。
系统允许设置最多30个段, 但必须至少包含两个段( 平衡段、 自然账户段) 。由于会计科目弹性域结构一经设定并使用之后, 以后修改比较困难, 故一般会设定一个或多个预留段, 如可在上述典型的5段结构之外再增加一个暂时不使用的段( 预留段) 而成为6段结构。会计科目弹性域结构的设定是系统基础设置的重要工作之一, 有关详细设置方法与步骤请参看相关系统设置文档。
另外, EBS系统针对所有弹性域的”段值”的接入权限, 提供了”安全性”设置功能, 控制”责任”实际能够使用的段值范围, 如下图8所示:

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

如下图10所示是EBS R12中使用”会计科目管理器AMB”设置”主要分类帐( Primary Ledger) ”与”辅助分类帐( Second Ledger) ”的定义界面:

R12中定义的一个”主要分类帐”能够附带定义与之关联的多个”辅助分类帐”, 如下图11所示:

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

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

ORACLE EBS R12中四维( 4C) 定义的”分类帐Ledger”构成了ORACLE系统”多账簿”功能的处理基础。实际上, 在R11中三维( 3C) 定义的”帐套SOB”也有”多报告币账簿”的概念, 但那仅限于财务报表在不同币种之间的自动转换, 并不是真正意义上的系统”多账簿”功能( 即一个公司自动生成符合会计法规要求的多套帐) 。
ORACLE EBS R12”多账簿”功能的核心与关键是各相关应用模块( 子分类帐应用产品) 在向总账模块传送日记账时, 如何自动为总账中的”主要分类帐和辅助分类帐”自动生成各自的日记账分录。这就涉及到分别为主辅分类帐设置图10中的 ”子分类帐会计选项”的问题, 它实际包括两个步骤, 一是为系统定义哪些应用模块能够使用子分类帐会计方法( ORACLE已经预定义) ; 如下图14所示, 系统已经预定义了包括PO/AP/AR/CST/FA等在内的21个需要用到子分类帐会计方法的应用产品:

二是为已经定义子分类帐的应用模块分别针对主辅分类帐设置”子分类帐会计方法”, 如下图15所示:

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

对于EBS R12来说, 即使不使用辅助分类帐也要为”主要分类帐”添加”子分类帐会计方法”, 它能够使ORACLE预置默认的, 也能够使用户修改后自定义的。实际上对于EBS R11来说, 安装时相当于ORACLE为所有的SOB直接预置了子分类帐会计方法, 系统将复杂的子分类帐会计方法定义向用户屏蔽了, 用户无法修改调整。
复杂的”子分类帐会计方法”定义是EBS R12为实现”多账簿”功能而必须付出的代价。所幸的是它只对GL模块的使用有一定影响, 对各相关应用模块的用户使用并无直接影响, 从R11到R12, ”多账簿”功能只相当于多调用了一个”服务”, EBS系统升级与使用保持了良好的继承性。
在EBS的总账GL模块中, 由于工作的对象主要是基于”账户代码”的日记账( 会计分录) 的数据信息, 来自各业务模块的有关不同公司的会计数据的”组织属性”实际上经过账户代码中的不同公司段值已经得到体现, 与各来源业务模块( 子分类帐应用产品) 中的相关”( 业务) 组织属性”设置无关。故总账模块与其它业务模块比较, 总账模块无需再作所谓”组织”的划分, 可说是”无组织”的。
总账系统用户一般来说能够处理所有公司的会计数据( 除非作弹性域段值的安全性设置) 。如果一定要说总账GL也有类似业务组织属性划分的话, 那么这个”组织实体”就是帐套或分类帐, 系统将使用类似业务模块的”组织接入”配置文件( 如”MO: 业务实体”) 的”帐套接入”配置文件( 例如R11的”GL 帐套名”或R12的”GL: 数据访问权限集”、 ”GL 分类帐名称”等) , 来分隔用户的工作权限。
有关”帐套接入”配置文件的使用有下述注意事项。对于配置文件”GL 帐套名”, R11中该参数的LOV由系统基于创立的SOB名自动创立, 一旦为其赋值后, 用户登录时系统自动定位于已指定SOB。由于GL模块与OU无关, 因此进入GL后, 数据的区隔主要基于这个参数, 但这个参数并不限制某些需要跨SOB功能如FSG对数据的访问。如下图17所示:

对于配置文件”GL 分类帐名称”, 该参数只在R12中有, 类似R11中的”GL帐套名”, 但作用与R11大不相同, 其LOV为分类帐名的集合( 创立时自动添加) , 只表示当前用户所进入的该”分类帐”同时还需要用到子分类帐产品诸如AP/AR等等。如下图18所示( 而当前用户所能够进入的分类帐则是由”GL: 数据访问权限集”控制) :

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

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

要特别注意, 对于R12的”GL 分类帐名称”的任何一次修改( 包括清空) , 都会自动影响”GL: 数据访问权限集”的值。系统之因此如此设计, 目的在于保证原R11的业务控制功能不变, 经过增加参数, 在R12中控制”可访问数据的范围”。因此正确的做法应该是: 先设定”GL 分类帐名称”的值, 实现基本的业务功能( 与子分类帐产品关联) , 再修改”GL: 数据访问权限集”的默认值, 控制数据可访问范围, 但必须保证其值包含了前者的值。
测试中发现, 如果”GL 分类帐名称”配置文件值留空, 而修改设定了”GL: 数据访问权限集”, ”GL: 数据访问权限集”默认的分类帐并未出现在FORM的窗口界面中, 这似乎是设计人员的疏忽。
ORACLE GL 在”创立分类帐、 定义分类帐集”时会自动创立”数据访问权限集”LOV值, 而且其类型为”全部分类帐”, 提供完整读写权限。在需要进一步限制对分类帐、 分类帐集或分类帐/分类帐集的特定平衡段值或管理段值的读写权限时, 用户需要创立自己的数据访问权限集。
在R12中还能够为财务系统另外定义”访问权限集”( 不同于参数”GL: 数据访问权限集”) , 并分配给责任来限制该责任所具有的功能( 当然这是在已经进入的当前分类帐之下的) 。系统预置了一个”超级用户定义访问权限集”( 不可修改) 。推测”权限”的限制方式可能是”倒剥式”( 为空时, 权限最大, 每增多一项, 就少一个与之对应的权限) , 如下图21所示:

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

四、 组织架构
在企业管理实践的过程中, ”组织”( 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中定义了也无用) , 改为在定义”分类帐”时的”会计科目设置管理器”WEB中定义并分配法人实体LE。一个分类帐设置( 主辅分类帐) 能够添加多个LE, 但每个LE只能具有一个分类帐设置。如下图25所示:

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

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

( 三) 业务实体( 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的这一系统特性极大地方便了企业运作的日常管理, 具有高度的灵活性与可扩展性。如下图27是R11的OU定义界面:

图中的”业务实体信息”中, 必须而且只能为之设定一个”帐套”, 即一个OU只能属于一个帐套( 反之, 一个帐套能够分配给多个OU) 。要注意的是, 上述业务实体信息中的法人实体设定, 并不代表OU只能属于一个LE, 它只是表示在”业务实体”中进行业务操作需要法人实体信息时提供默认值( 在R12中明确了是”默认值”这一点) 。R12中的业务实体定义同R11基本相同, 只是将帐套改为”主要分类帐”。
在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组织) 。

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

EBS中的库存组织INV的作用与功能能够与SAP中的工厂Plant参看。一个库存组织INV只能属于一个确定的帐套SOB、 一个确定的法人实体LE、 一个确定的业务实体OU, 具有唯一性的关系( 注意: R11的设置界面未考虑SOB/LE/OU的关联限定, 容易产生错误; R12作了改进, 在选定Ledger之后, 可用的LE/OU就被限定) 。反之, 一个”帐套/法人实体/业务实体”组合则能够有多个库存组织INV。另外, 一个OU下的多个INV能够对应属于该OU的不同LE, 这相当于将