1） 业务组（BG）（2） 法律实体（LE）（3） 业务实体（OU）（4） 库存组织（INV）（5） 公司成本中心（Cost Center）（6） HR 组织（7） 多组织接入控制在企业管理实践的过程中，“组织”（Organization）一词是个经常需用到的概念，一般与“人员”与“职能”这两个要素密切相关，反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等企业内部行政组织（部门）的划分是企业基于“职能驱动”业务管理模式进行运作的基础目前，国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的“组织职能”划分问题但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”这种系统实现方式虽有理解、精选范本掌握比较容易的优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。
国内有所谓高端管理软件在系统实施过程中，常常 出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况”，导致系统几乎没法使用的困境，其症结正在于此与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性作为ERP 鼻祖的 SAP 将系统组织简单地分为“集团（Client）、公司代码（CompanyCode）、采购组织（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 中，任何责任在任意时刻只能关联一个 BGEBS 安装好后，系统里面已经预置了一个名为“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 同名的可选值（初始时只有“SetupBusiness 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 定义界面：业务实体 OU 的这一系统特性极大地方便了企业运作的日常管理，具有高度的灵活性与可扩展性如下图 27 是 R11 的精选范本精选范本精选范本图中的“业务实体信息”中，必须而且只能为之设定一个“帐套”，即一个OU 只能属于一个帐套（反之，一个帐套可以分配给多个 OU）要注意的是，上述业务实体信息中的法人实体设定，并不代表 OU 只能属于一个 LE，它只是表示在“业务实体”中进行业务操作需要法人实体信息时提供默认值（在 R12 中明确了是“默认值”这一点）。
R12 中的业务实体定义同 R11 基本相同，只是将帐套改为“主 要分类帐”在EBS 中，一个 OU 可以同时指定给多个 LE，上面“电视机管理群组”的例子已经说明了这一点；一个 LE 也可以有多个 OU，这相当于一个注册的法人实体公司下，有多个需。