ORACLE EBS 基础设置要点简介
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），容后在相关模块文档中再来讨论。
二、会计科目弹性域结构
在讨论EBS的“组织结构”的设置之前，有必要先讨论会计科目弹性域（Accounting Flexfield）及其帐套（SOB）或分类帐（Ledger）的设置问题。“帐套”是R11及之前系统中的术语，“分类帐”是R12中替代帐套并为有所区别而使用的术语。为表述方便，后文如不特别指明，习惯上的“帐套”术语将等同于“分类帐”术语。在EBS关于“组织实体”的概念范畴中，帐套实际上也是“组织实体”的一种存在形式，之所以如此和ORACLE产品的发展历史有一定关系。
会计科目是企业进行财务数据核算工作的基础，各个国家基于企业监管与税收工作的需要而制定的会计法律法规都对之有相应规定。我国于2006年颁布的新会计准则将会计科目分为六大类：资产类、负债类、共同类、所有者权益、成本类、损益类，共计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
所示：
所示：
注意，图7与图5、6中的“段限定词”的内容有所不同，它具体规定了自然账户的段值所代表的会计科目的类别（资产、负债等），“弹性域限定词”与“段限定词”是两个不同的概念，段限定词的取值受控于弹性域限定词的取值。
会计科目弹性域结构的“子账户段”表示“二级科目或明细科目”，与账户段的一级科目具有汇总与被汇总的关系；“产品段”，则表示基于特定统计分析需要而设置的产品LOV。
系统允许设置最多30个段，但必须至少包含两个段（平衡段、自然账户段）。由于会计科目弹性域结构一经设定并使用之后，以后修改比较困难，故通常会设定一个或多个预留段，如可在上述典型的5段结构之外再增加一个暂时不使用的段（预留段）而成为6段结构。会计科目弹性域结构的设定是系统基础设置的重要工作之一，有关详细设置方法与步骤请参看相关系统设置文档。
此外，EBS系统针对所有弹性域的“段值”的接入权限，提供了“安全性”设置功能，控制“责任”实际可以使用
的段值范围，如下图8所示：
三、帐套（分类帐）
会计科目弹性域结构（COA）、币种（Currency）、日历（Clander）三者的组合构成EBS R11及之前系统的所谓“帐套”（SOB）。在R12中，再增加一个维度“会计方法或会计惯例”，即成为所谓“分类帐”。所谓“会计方法或惯例”，例如对于不同国家或地区、不同企业，会计法规可能规定物品单价5000元是作为“固定资产”还是“期间费用”处理的判定标准，也可能规定这个判定标准是1万元。标准不同，记账的会计科目也就不同，企业报告的经营结果也就会有差别。一个诸如在香港注册的企业，一方面需要向香港政府机关提交符合本地法规的财务报告，另一方面可能还需要向在国内的总公司提供符合国内法规的财务报告（便于考核管理），这就出现所谓“多账簿”（对应R12
中的主辅分类帐）的系统功能问题。如下图9是EBS R11中“帐套”的定义界面：
帐（Second Ledger）”的定义界面：
R12中定义的一个“主要分类帐”可以附带定义与之关联的多个“辅助分类帐”，如下图11所示：
“主要分类帐”与“辅助分类帐”，可以有不同的科目表结构（COA）。由于系统其它的应用模块（R12中称之为“子分类帐应用产品”），例如PO/AP/AR等等，其事务处理默认是基于“主要分类帐”的会计科目表（COA），所以，如果主辅分类帐的科目表不同，则必须在两者之间建立“映射（Mapping）”关系（1对1或多对1的关系）。如下图12所示为主辅分类帐的映射定义界面，如果两者科目表相同（币种不同），则该定义界面将有所不同，没有“科目表”
映射的内容，只有后面部分（币种转换及日记账转换等）：
一个范围，而目标账户只能是一个：
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：数据访问权限集”控制）：