多组织架构.pdf

多组织架构（一）业务组BG 二法律实体LE 三业务实体OU 四库存组织INV 五公司本钱中心Cost Center 六HR 组织 七多组织接入控制(八)一个集团下的全资子公司才可以设置为OU。假如占百分比的，应设置为新的帐套。在企业管理实践的过程中，“组织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，这相当于将分属于两个法人公司的生产两种产品的四个工厂，按一样产品两两组合抽取出来，分属于两个不同 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 所示：七多组织接入控制 在图30 的 EBS 组织设置界面中，所谓的组织“类型Type划分仅是基于组织自身的统计分析工作需要而定义的一个“维度，例如“公司总部、产品线等等，并不影响系统的业务处理功能。真正起作用的是设置界面中的“组织分类Classification，系统预置的组织分类 LOV 除了上述“业务组、法律实体、业务实体、库存组织等之外，还有诸如“资产组织、运营公司、雇主等等选项。在 EBS 系统中各应用模块所具有的业务处理功能通常需构建在一个确定的“组织分类之上，“组织是相关业务处理功能的平台，企业是否需要作相关组织分类设置、如何设置，取决于企业所需要使用到的应用模块功能。例如所谓“资产组织的设置，它是在企业需使用到资产管理模块FA 时才涉及到。“资产组织实际上是所谓“资产账簿的代名词，它只是表示有关资产信息的一个数据维度，作用主要在于分隔数据范围，用户进入系统作业务处理时，并不需要作上下文业务环境的切换。对于这类并不涉及“上下文环境切换的所谓“组织，ORACLR 系统的设计主要是为了借用“组织所具有的“层次结构Hierarchy概念来到达“多组织接入权限的控制功能。需指出的是，这里的组织“层次结构与真实世界企业的行政管理组织层次结构没有直接关系尽管可能有所参考，它只是企业根据某种需要如权限管理控制、数据统计汇报等而人为设定的一个“层次结构，例如将系统中已经设置的任意数量的“业务实体或“库存组织等等组织Name，人为地设定一个具有上下级关系、自顶向下的金字塔形多层结构。如如下图 31 所示：上图中开始定义时，一旦选定最顶端组织Name，如此就只能为之分配下属组织 Name，如要给下属组织分配更下一级的组织，如此需点击“向下按钮，将当前该下属组织上升到“顶端组织位置。点击“向上按钮，如此将当前“顶端组织下降到下属组织位置。企业可以根据实际需要设定假如干个具有不同内部结构的“组织层次结构Name，以供定义系统所谓“平安性配置文件时调用。如如下图 32 所示：上图所定义“平安性配置文件是系统用以控制包括“组织平安性等在内的各种平安性控制的根底，它具体规定了系统平安性控制的范围与实现方式，所有定义的“平安性配置文件Name 构成系统多组织接入控制参数“MO：平安性配置文件的 LOV。如如下图 33 所示：EBS 通过“MO：业务实体、“MO：平安性配置文件、“MO：默认业务实体这三个系统配置文件的共同作用，实现所谓“多组织接入控制功能MOAC。但上述三个配置文件在 R11 与 R12 中的作用有比拟大的差异。对于“MO：业务实体，在 R11 中必须设定，而且起决定性控制作用，其LOV 由系统基于创立的 OU name 自动创立，用户登录时系统自动定位于指定OU。而在 R12 中，一旦设定“MO：平安性配置文件，如此此配置文件失效而不起作用。对于“MO：平安性配置文件，在 R11 中虽有，但实际不起 OU 接入的控制作用，只针对 FA 等模块的得某些应用如数据统计等起作用。因此，一般认为R11 并不具有完善的多组织接入控制功能。在 R12 中，该参数如果不设定，如此必须设定“MO：业务实体参数；一旦该参数被设定，如此就起决定作用，系统主要依赖其实现 MOAC。对于“MO：默认业务实体，在 R11 中虽有但实际不起作用。在 R12 中，随“MO：平安配置文件起作用后才起作用，其 LOV 是所有已定义 OU，但如果设定值不在“MO：平安配置文件所选择的“组织层次架构的范围内，如此仍不起作用即在与 OU 相关诸如 PO、OM 等的 FORM 界面，OU 字段的默认值仍然为空。这似乎是 ORACLE 系统设计方面的一个难题，即“MO：默认业务实体的 LOV 值集无法与“MO：平安性配置文件中“组织层次架构中的OU 值范围保持一致。ORACLE强调其“多组织接入 MOAC功能主要是针对业务实体 OU 而言，其另外一层含义是，所有构建于库存组织 INV 上的应用功能，实际是与上述配置文件无关的。库存组织的可接入性是在“组织访问控制功能中，专门设定“库存组织与“责任的关联性，如如下图 34 所示：按照ORACLE 的说法，如果系统在初始的时候，不定义库存组织的“组织访问控制，如此所有“责任可访问所有 INV，一旦限制或分配其中一个，如此其余均必须逐个进展分配以建立“库存组织与“责任的链接关系。总之，EBS 系统通过“弹性域段值平安性、“帐套/分类帐平安性、“多组织接入平安性MOAC、“库存组织访问控制等多维度、多方面的组合系统设置，提供了灵活、方便的用户权限管理功能，厘清并掌握它们的复杂关系是系统实施的一项重要根底性工作。一业务组BG 二法律实体LE 三业务实体OU 四库存组织INV 五公司本钱中心Cost Center 六HR 组织 七多组织接入控制 在企业管理实践的过程中，“组织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，这相当于将分属于两个法人公司的生产两种产品的四个工厂，按一样产品两两组合抽取出来，分属于两个不同 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 所示：七多组织接入控制 在图30 的 EBS 组织设置界面中，所谓的组织“类型Type划分仅是基于组织自身的统计分析工作需要而定义的一个“维度，例如“公司总部、产品线等等，并不影响系统的业务处理功能。真正起作用的是设置界面中的“组织分类Classification，系统预置的组织分类 LOV 除了上述“业务组、法律实体、业务实体、库存组织等之外，还有诸如“资产组织、运营公司、雇主等等选项。在 EBS 系统中各应用模块所具有的业务处理功能通常需构建在一个确定的“组织分类之上，“组织是相关业务处理功能的平台，企业是否需要作相关组织分类设置、如何设置，取决于企业所需要使用到的应用模块功能。例如所谓“资产组织的设置，它是在企业需使用到资产管理模块FA 时才涉及到。“资产组织实际上是所谓“资产账簿的代名词，它只是表示有关资产信息的一个数据维度，作用主要在于分隔数据范围，用户进入系统作业务处理时，并不需要作上下文业务环境的切换。对于这类并不涉及“上下文环境切换的所谓“组织，ORACLR 系统的设计主要是为了借用“组织所具有的“层次结构Hierarchy概念来到达“多组织接入权限的控制功能。需指出的是，这里的组织“层次结构与真实世界企业的行政管理组织层次结构没有直接关系尽管可能有所参考，它只是企业根据某种需要如权限管理控制、数据统计汇报等而人为设定的一个“层次结构，例如将系统中已经设置的任意数量的“业务实体或“库存组织等等组织Name，人为地设定一个具有上下级关系、自顶向下的金字塔形多层结构。如如下图 31 所示：上图中开始定义时，一旦选定最顶端组织Name，如此就只能为之分配下属组织 Name，如要给下属组织分配更下一级的组织，如此需点击“向下按钮，将当前该下属组织上升到“顶端组织位置。点击“向上按钮，如此将当前“顶端组织下降到下属组织位置。企业可以根据实际需要设定假如干个具有不同内部结构的“组织层次结构Name，以供定义系统所谓“平安性配置文件时调用。如如下图 32 所示：上图所定义“平安性配置文件是系统用以控制包括“组织平安性等在内的各种平安性控制的根底，它具体规定了系统平安性控制的范围与实现方式，所有定义的“平安性配置文件Name 构