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

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个（一级）科目。简单财务会计软件或单企业规模很小时，类似手工记账“电算化”系统实现方法问题不大，但当会计业务管理需求复杂，企业从单企业向多企业集团化方向发展时，就必需考虑在系统层面怎样方便地对多个企业会计数据进行集中统一管理问题。
ORACLEERP产品最初也是从财务软件发展起来，总账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设置全部对具体业务处理影响不大，其和系统用户或责任不关联，不直接影响系统上下文切换，故有些人甚至认为EBSLE设置作用不大。这对于系统内部运作来讲情况确实近似如此，但对于需要经过系统产生供外部使用含有法律意义文书（如采购订单、财务报表等等），严格区分法律实体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是R11OU定义界面：

图中“业务实体信息”中，必需而且只能为之设定一个“帐套”，即一个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，这相当于将分属于两个法人企业生产两种产品四个工厂，按相同产品两两组合抽取出来，分属于两个不一样OU进行日常业务管理。
在EBS中还有两个组织概念“MRP组织、WIP组织”，它们实际是必需构建于库存组织之上组织概念，表示该库存组织还能够进行MRP或WIP功效。系统之所以如此处理，关键是为了控制一些INV不能做MRP或WIP而已，因为基于物料接收或发出需要所设定INV数量可能比较多。
对于绝大多数基于库存组织INV业务功效（部分除外），系统用户在做业务操作时，均必需首优异行INV选择切换，方便进入确定INV上下文环境。库存组织作用是如此基础，以至于EBS相关文档在提及组织（Org）概念时，假如未作尤其说明，默认就是指INV组织。

（五）企业成本中心（Cost Center）
 EBS所谓“成本中心组织”并没有业务处理功效，它设置关键是考虑和“会计科目弹性域结构”中“企业段值”和“成本中心段值”对应关系问题。以下图29所表示：

在系统中创建“企业成本中心组织”后，能够运行一个“并发检验程序”，以校验“会计科目弹性域结构”中段值是否和全部“企业成本中心”组织设置保持一致。
当在“会计科目弹性域结构”中“成本中心段”值集中添加LOV值并重新编译后，能够运行系统“自动组织”并发程序功效，由系统自动创建“企业成本中心”组织。
应该注意是，一个企业成本中心组织及其成本中心段值，不可能属于不一样法人实体LE及其企业段值，这和真实世界中管理要求是一致。库存组织INV和会计科目弹性域中“成本中心”段（部门）则含有“一对一或多对一”关系，即一个“成本中心”段值能够有多个库存组织INV，但一个库存组织INV只能属于一个确定成本中心。

（六）HR组织
  系统HR组织设置是和HRM模块相关业务处理功效相关，和关键业务/财务处理功效关系不大，关键是需要注意其是否和“成本中心”关联，需要时能够输入“成本中心”代码，其LOV就是“会计科目弹性域”结构中成本中心段值集。以下图30所表示：

（七）多组织接入控制
在图30EBS组织设置界面中，所谓组织“类型”（Type）划分仅是基于组织本身统计分析工作需要而定义一个“维度”，比如“企业总部、产品线”等等，并不影响系统业务处理功效。真正起作用是设置界面中“组织分类”（Classification），系统预置组织分类LOV除了上述“业务组、法律实体、业务实体、库存组织”等之外，还有诸如“资产组织、运行企业、雇主”等等选项。在EBS系统中各应用模块所含有业务处理功效通常需构建在一个确定“组织分类”之上，“组织”是相关业务处理功效平台，企业是否需要作相关组织分类设置、怎样设置，取决于企业所需要使用到应用模块功效。
比如所谓“资产组织”设置，它是在企业需使用到资产管理模块FA时才包含到。“资产组织”实际上是所谓“资产账簿”代名词，它只是表示相关资产信息一个数据维度，作用关键在于分隔数据范围，用户进入系统作业务处理时，并不需要作上下文业务环境切换。对于这类并不包含“上下文”环境切换所谓“组织”，ORACLR系统设计关键是为了借用“组织”所含有“层次结构”（Hierarchy）概念来达成“多组织接入”权限控制功效。
需指出是，这里组织“层次结构”和真实世界企