ORACLE_EBS_多组织架构简介
EBS系统组织架构讲解
EBS系统组织架构讲解EBS系统（Enterprise Business System，企业商业系统）的组织架构一般由多个部门和职能团队组成，以实现企业的信息化和数字化管理。
在这篇文章中，我将详细讲解EBS系统的组织架构，并介绍各个部门和团队的职责和作用。
1.研发部门：负责EBS系统的开发和维护工作。
该部门通常包括软件工程师、数据库管理员、系统分析师等技术人员，负责系统的设计、编码、测试和修复等工作。
研发团队需要根据用户需求和企业的业务流程，设计和实现各个功能模块，并确保系统的稳定性和安全性。
2.实施部门：负责EBS系统的实施和部署工作。
该部门通常包括顾问、项目经理、系统工程师等人员，负责与客户进行沟通和了解需求，制定系统实施计划，并负责系统的安装、配置和测试等工作。
实施团队需要与用户密切合作，确保系统能够满足用户的需求，并提供培训和支持。
3.运维部门：负责EBS系统的运行和维护工作。
该部门通常包括系统管理员、网络管理员、技术支持等人员，负责系统的日常运维、监控和故障处理等工作。
运维团队需要确保系统的可用性和性能，及时处理用户的问题和反馈，并定期进行系统升级和优化。
4.数据管理部门：负责EBS系统中的数据管理工作。
该部门通常包括数据分析师、数据管理员等人员，负责数据的采集、清洗、存储和分析等工作。
数据管理团队需要确保系统中的数据准确可靠，并通过数据分析提供决策支持和业务优化。
5.用户支持部门：负责EBS系统的用户支持和问题解答工作。
该部门通常包括客户服务人员、售后支持人员等，负责回答用户的问题、解决用户遇到的困难，并提供技术支持和培训。
用户支持团队需要时刻与用户保持沟通，及时解决用户的问题，并收集用户的反馈和需求。
此外，为了更好地管理和协调EBS系统的开发和运维工作，往往还会设立一个项目管理办公室（Project Management Office，简称PMO）。
PMO负责项目的规划、执行和监控，协调各个部门和团队之间的合作和沟通，提供项目管理的方法和工具，并负责项目的进度和质量的控制。
oracle ebs学习
Oracle ebs 组织架构介绍SAP将系统组织简单地分为“集团（Client）、公司代码（Company Code）、采购组织（Purchase Org）、销售组织（Sale Org）、工厂（Plant）”等类别。
ORACLE的组织设置本质上与之基本相似，但作为后来者作了进一步抽象与简化，系统组织划分为“业务组（Business Group）、法律实体（Legal Entity）、业务实体（Operating Unit）、库存组织（Inventory Org）”等。
1、业务组【BG】参考“集团”概念，通常一个企业设置一个，对于业务多元化的特大型公司，可以设置多个。
当以系统预置超级用户SYSADMIN进入后，应首先设置一个具有在HRM或INV下创建组织功能的“责任”名，随后给此责任的“HR：User Type”配置文件设定值为“HR User”，则该责任就有了创建新BG的能力。
系统每新建一个BG，就会自动在配置文件“HR：安全性配置文件”的LOV中自动添加一个与新建BG同名的可选值（初始时只有“Setup Business Group”一个值）。
在某一个BG 下（初始为Setup Business Group）新建的任何责任，系统都将该责任的配置文件“HR：安全性配置文件”值默认为当前BG。
要在进入系统时能切换到新的BG，必须先修改该责任的“HR：安全性配置文件”设定值。
2、法律实体【LE】：对应于真实世界中的按国家法律法规要求注册的“法人公司”。
LE在组织FORM定义时，对于每个LE必须为其“法人主体会计科目”关联一个“帐套SOB”。
每个LE对应一个SOB，这与真实世界的法规要求是吻合的。
在定义“分类帐”时的“会计科目设置管理器”WEB中定义并分配法人实体LE。
一个分类帐设置（主辅分类帐）可以添加多个LE，但每个LE只能具有一个分类帐设置。
创建一个LE后，应当及时到会计科目弹性域结构中添加需要对应的公司段值LOV（一个或多个），并重新进行弹性域的编译，否则系统可能会弹出错误报警信息。
ORACLE-EBS-OU-BG-INV-HR等组织架构介绍复习过程
ORACLE EBS-组织架构介绍（一）业务组（（一）业务组（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）”等。
ORACLE-EBS-组织架构介绍
（一）业务组（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）”等。
oracle_ebs表结构及功能总结(财务,制造,分销模块)
oracle_ebs表结构及功能总结(财务,制造,分销模块)oracle_ebs表结构及功能总结(财务,制造,分销模块)Oracleapplication表结构1．表结构，WHO字段来实现通过菜单HELP下的HISTORY来找表2.通过LAST_QUERY来判断所使用的表LAST_QUERY是系统变量保存所执行的最后一次的SQL语句BLOCK一定选SYSTEM作为一个虚拟的BLOCK用HELP菜单下面的EXAMING子菜单3.用TRACE的办法来实现找表4.查看源代码来找表基本表结构学习目的：了解数据库的设计思想1.库存模块INV表结构，主要是物料的保存和搬运组织：分为库存组织和经营单位对于来说首先定义成一个经营单位，主要是进行业务核算的基本单位，是经营单位每一个生产单位作为一个库存组织，库存组织不作为核算单位组织表是HR_ORGANIZATION_UNITS存放所有的组织ORG_ID表示的经营单位ORGANIZATION_ID表示库存组织通过制造物料参数表MTL_PARAMETERS来查看库存组织IDMTL_SYSTEM_ITEM物料信息原材料仓库，半成品仓库，成品仓库子库存属于库存组织的一个结构，子库存下面还可以有一个叫库位的结构物料的位置由：库存组织+子库存+库位子库存放置在MTL_SECONDARY_INVENTORIES表中货位信息放置在MTL_ITEM_LOCATIONS表中在MTL_ITEM_LOCATIONS中的SEGMENT1存放其库位名称MTL_ONHAND_QUANTITIES表存放物料的现有量表其中LOCATION_ID表示库位信息MTL_SYSTEM_ITEMS表存放所有库存组织，所有物料MTL_MATERIAL_TRANSACTIONS物料事务处发表（存放物料的进货销售）TRANSACTION_IDINVENTORY_ID表示操作的物料IDTRANSACTION_QUANTITY表示货物的数量正数为搬进负数为搬出PRIMARY_QUANTITY表示主计量单位TRANSACTION_COST表示物料的成本ACTUAL_COST表示通过算法得到的物料成本ITEM_MASTER物料主表PRIMAR_UNIT_OF_MEASURE表示主计量单位MTL_CATEGORY_SET表表示产品分类级MTL_CATAGROYS2.PO采购模块从供应商订购和接收货物先请购-采购单-接收货物请购单头表PO_REQUISITION_HEADERS_ALLORG_ID为经营组织单位行表PO_REQUISITION_LINES_ALL其中DESTINATION_ORGANIZATION_ID 库存组织ID表后带ALL表示支持多组织的表，否则为单组织有一些环境变量在运行环境下才有值，导致有一些表不能查找到数据采购单PO_HEADERS_ALLVENDOR_ID供应商ID表示我向那个供应商采购的信息PO_VENDORS为供应商基表PO_LINES_ALLpo_LINE_ID主键QUANTITY表示数量UNIT_PRICE为准确价格ORG_ID表示经营单位的采购订单采购接收RCV_TRANSACTIONS表接收的数据事务关心TRANSACTION_TYPE和DESTINATION_TYPE_CODE字段接收和退回都要考虑接收后会影响库存3.OM销售模块怎么做销售定单，非常复杂从OE出来的核心是销售订单挑库---〉物料搬运单〉发运SO_HEADERS_ALL表已经不用客户信息存放在表RA_CUSTOMERS其中RA_ADDRESS表示客户地址RA_ADDRESSES_ALLRA_SITE_USES_ALL表表示货品抵达如果是BILL_TO表示可以开票SHIP_TO表示发货销售订单表OE_ORDER_HEADERS_ALLSOLD_TO_ORG_ID对应的是客户表的RA_CUSTOMERS的字段CUSTOMER_IDSHIP_TO_ORG_ID对应RA_SET_USES_ALL的SHIP_TOINVOICE_TO_ORG_ID对应RA_SET_USES_ALL的BILL_TO 销售订单行表OE_ORDER_LINES_ALL4.BOM物料清单BOM_BILL_OF_MATERIALS表主建是BILL_SEQUENCE_IDORGANIZATION_ID库存组织ASSEMBLY_ITEM_ID装配件ID(可以查系统物料表得到信息)BILL_SEQUENCE_ID内部号码适应一个装配件多个BOMBOM_INVENTORY_COMPONENTSBOM_OPERATIONAL_ROUTING工艺路线表BOM_STANDARD_OPERATIONS5.WIP（WORKINPROCESS）在制品依靠BOM模块关心JOB状态，JOB的信息WIP_ENTITIES表里的PRIMARY_ITEM_ID为此JOB生产的东西WIP_ENTITY_NAMEJOB的名字WIP_DISCREATE_JOBS所有离散任务DATE_RELEASED释放日期DATE_CLOSE关闭日期SCHEDUAL_COMPLETION_DATE完成日期WIP_MOVE_TRANSACTIONS表示生产过程中的工序的移动怎么处理返工，怎么处理报废在一个个工序中分为几个工布有排队、报废、和WIP发放装配件完工入库产品退回WIPWIP退回到库存6.GL总帐凭证:凭证批、凭证头、平整行GL_JE_BATCHES凭证日期----DEFAULT_EFFECTIVE_DATE会计期间----DEFAULT_PERIOD_NAME原SET_OF_BOOKS_ID帐套IDGL_JE_HEADERS批号：JE_BATCH_ID会计期间：PERIOD_NAME凭证类型：JE_CATEGORY 凭证来源：JE_SOURCE帐套：SET_OF_BOOKS_IDCODINAE_COMBINATION_IDGL_JE_LINESGL_SET_OF_BOOKSGL_CODE_COMBINATIONS表保存会计科目GL_BALANCES总账余额表7.AR应收应收发票表示RA_CUSTOMER_TRX_ALLCUSTOMER_TRX_ID发票编号RA_CUSTOMER_TRX_LINES_ALL发票行一般有两种类型ITEM和TAX收款情况表AR_CASH_RECEIPTS_ALL(包含非收款信息)核销关系表AR_RECEIVABLE_APPLICATIONS_ALL8.AP应付应付发票表AP_INVOICES_ALL实际付款表AP_CHECKS_ALLAP_INVOICE_PAYMENTS9.FA固定资产资产信息表FA_ADDITIONSCURRENT_UNITS资产的数量资产类别FA_CATEGORIES资产帐薄FA_BOOK_CONTROLSFA_BOOKS折旧一般有直线法和产量法FA_DISTRIBUTION_HISTORY资产分配信息FA_DEPRN_DETAIL折旧信息表FA_TRANSCATION_HEADERS折旧事务表主要报表库存收发存报表不采购订单表接收情况表销售订单表生产任务情况表嫂返工率分析表供应商对帐单，给部门使用多少采购接受事务RCV_TRANSACTIONSPO_HEADERS_ALLPO_LINES_ALLMTL_SYSTEM_ITEMS HR_ORGANIZATION_UNITSMTL_SECONDARY_INVENTORIESMTL_ITEM_LOCATIO NS日期：事物日期RCV_TRANSACTIONS中的TRANSACTION_DATE类型：即RCV_TRANSACTIONS中的TRANSACTION_TYPE接收目的：即RCV_TRANSACTIONS中的DESTINATION_TYPE_CODE物料名称：相关定单行指定的物料名称单位：是RCV_TRANSACTIONS中的PRIMARY_UNIT_OF_MEASURE库存组织：是RCV_TRANSACTIONS中的ORGANIZATION_ID，其对应HR_ORGANIZATION_UNITS里的NAME子库存：RCV_TRANSACTIONS中的SUBINVENTORY_CODE库位：RCV_TRANSACTIONS中的LOCATOR_ID指定库位ID,在MTL_ITEM_LOCATIONS中的SEGEMENT1数量：RCV_TRANSACTIONS中的primary_QUANTITY定单号：RCV_TRANSACTIONS中的PO_HEADER_ID指定的定单的号定单行号：RCV_TRANSACTIONS中的PO_LINE_ID指定的定单行号物料库存现有量MTL_ONHAND_QUANTITIESMTL_SYSTEM_ITEMSHR_ORGANIZATIONSMTL_SECONDARY_INVENTORIESMTL_ITEM_LOCATIONS物料:即物料名称MTL_SYSTEM_ITEMS中的SEGEMENT1单位:主计量单位MTL_SYSTEM_ITEMS中的PRIMARY_UNIT_OF_MEASURE库存组织:HR_ORGANIZATION_UNITS子库存:子库存编码,MTL_SECONDARY_INVENTORIES中的SUBINVENTORY_CODE库位:库位编码,MTL_ITEM_LOCATIONS中的SEGEMENT1总帐凭证GL_JE_HEADERSGL_JE_LINESGL_CODE_COMBINATIONS_KFVGL_SETS_OF_BOOKS凭证名:凭证名称,GL_JE_HEADERS中的NAME日期:凭证日期,GL_JE_HEADERS中的DEFAULT_EFFECTIVE_DATE过帐状态:当GL_JE_HEADERS中的STATUS为P的时候表示”已过帐”,为U的时候表示”未过帐”币种:GL_JE_HEADERS中的CURRENCY_CODE 科目:GL_CODE_COMBINATIONS_KFV中的CONCATENATED_SEGEMENTS借方金额:GL_JE_LINES中的ENTERED_DR贷方金额:GL_JE_LINES中的ENTERED_CR说明:GL_JE_LINES中的DESCRIPTION帐套:GL_SETS_OF_BOOKS中的NAME,SET_OF_BOOKS_ID限定凭证友情提示：本文中关于《oracle_ebs表结构及功能总结(财务,制造,分销模块)》给出的范例仅供您参考拓展思维使用，oracle_ebs表结构及功能总结(财务,制造,分销模块)：该篇文章建议您自主创作。
完整word版,ORACLE EBS架构
ORACLE EBS-组织架构介绍 (引用)2010年08月05日星期四 11:43（一）业务组（BG）（二）法律实体（LE）（三）业务实体（OU）（四）库存组织（INV）（五）公司成本中心（Cost Center）（六）HR组织（七）多组织接入控制在企业管理实践的过程中，“组织”（Organization）一词是个经常需用到的概念，一般与“人员”与“职能”这两个要素密切相关，反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等。
企业内部行政组织（部门）的划分是企业基于“职能驱动”业务管理模式进行运作的基础。
目前，国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的“组织职能”划分问题。
但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题。
一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。
这种系统实现方式虽有理解、掌握比较容易的优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。
国内有所谓高端管理软件在系统实施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况”，导致系统几乎没法使用的困境，其症结正在于此。
与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。
作为ERP鼻祖的SAP将系统组织简单地分为“集团（Client）、公司代码（Company Code）、采购组织（Purchase Org）、销售组织（Sale Org）、工厂（Plant）”等类别。
ORACLE-EBS-多组织架构简介说课讲解
Oracle EBS多组织结构ORACLE EBS-个很大的卖点是它的多组织结构. ORACLE EBS的文档资料里面解释呈现这样一个树型图：营运单元未完待续.接上.实际上，ORACLE电子商务套件中的组织属性可以分为如下几类：1. 业务组: 它代表组织结构的最高层次, 它分离了人力资源的信息. 例如, 当你查询人员时，它会列出所有分配给相应业务组的成员，而你自己所属于的组织只不过是业务组的一份子. 这样说可能造成一种误解：一个公司只能有一个业务组，实际上可能有多个，但是业务组之间不能共享信息.2. 帐簿：它其实不能称为一种组织，更象组织中的一个层次或性. 一个业务组中可以有一个或者多个帐簿.3. 法律实体：法律实体类型赋予组织税码以及其它与法律相关的属性. 一套帐簿可以分配给多个法律实体.4. 平衡实体：平衡实体就是帐户结构中的一个段，即平衡段. 在你准备财务报表的时候它体现你的帐户实体.5. 业务实体：如果一个组织应用到现金管理，订单管理，运输，应收，应付和采购模块，则它就是一个业务实体. 它可能是一个销售中心，一个分公司，或者一个部门. 对于这些应用，EBS按照法律实体分离了业务信息，每个用户只能访问到他自己所属于的业务实体的信息. 一个法律实体下面可以有一个或者多个业务实体.6. 库存组织：当一个组织要用到库存事物（例如接收，转移等），或者它要负责制造和分销产品时，这个组织就是一个库存组织. 它可能是一个制造厂，仓库，分销中心或者销售部门. 当用到下列模块时， EBS 按照库存组织来分割业务信息： Oracle Inventory， Bills of Material，Engineering， Work in Process， Master Scheduling/MRP， Capacity， and Purchasing receiving functions. 当你登陆到这些模块时， ORACLE EBS 会提示你选择一个库存组织. 同样，一个业务实体下面可以有一个或者多个库存组织.7. 人力资源组织：它体现了一个公司的基本工作结构. 只有当一个组织是人力资源组织时你才能分配人员给这个组织. 一个业务组中可以有一个或者多个人力资源组织.8. 资产组织：资产组织属性使组织可以执行与资产相关的功能. 只有当一个组织属于资产组织时，才能使用Oracle Assets.还需要说明一点的是：EBS的一个组织并非只能归属于一个类型•例如，例如，一个组织是一个业务实体，若在这个组织中要用到Oracle Inventory，那么它同时还是一个库存组织. 所以，组织类型代表了组织的一种属性，而不是把组织简单的分类.当你在实施的时候，可能用不同的模型来描述组织结构.当你在实施HR的时候，你可能会按照下图来描述:当你在实施制造，物流和财务的时候，你更加可能按下图所示去进行组织的设置可能设置一个或多个业务组，一个业务组下面可能包含一个或多个帐套，一个帐套下面可能有一个或多个业务实体（也就是多个子公司共用一个帐套）,一个业务实体下面可能有一个或多个业务机构，一个业务机构下面又可能有一个或多个库存组织，一个库存组织下面又可能有一个或多个子库存，在下面依次是库位和货架（相当于行和列）.这两种模型并非是孤立的，而应该综合考虑•例如，你设置一个业务组织，但同时你还要分配人员给这个组织，那么你同时还要把它设置为一个HR组织.接下来我们来讨论如何实施多组织结构，我们将遵循如下步骤：1．规划和描述组织结构。
ORACLE_EBS_系统应用基础概述
ORACLE_EBS_系统应用基础概述ORACLE EBS（Enterprise Business Suite）是由ORACLE公司开发的一套集成化的企业应用系统，用于管理企业的关键业务流程。
它包括了财务、人力资源、供应链管理、供应商关系管理、生产制造、销售和客户关系管理等多个模块，帮助企业实现业务处理的自动化和优化。
首先，ORACLEEBS的核心模块包括财务管理、人力资源管理和供应链管理。
财务管理模块包括总账、应付账款、应收账款等功能，用于管理企业的财务状况和流动资金。
人力资源管理模块包括员工档案、薪资管理、绩效评估等功能，用于管理企业人力资源。
供应链管理模块包括采购、仓库管理、物流等功能，用于优化企业的供应链流程。
其次，ORACLEEBS还提供了供应商关系管理和生产制造模块。
供应商关系管理模块包括供应商评估、合同管理、供应商支付等功能，用于优化企业与供应商之间的合作关系。
生产制造模块包括生产计划、物料需求计划、生产执行等功能，用于提高企业的生产效率和产品质量。
除了核心模块外，ORACLEEBS还提供了销售和客户关系管理模块。
销售模块包括销售订单管理、合同管理、销售报价等功能，用于管理企业的销售过程和客户关系。
客户关系管理模块包括客户档案、客户服务、市场营销等功能，用于提高企业的客户满意度和市场竞争力。
首先，ORACLEEBS具有高度的集成性。
它可以与其他企业应用系统（如CRM系统、SCM系统）进行无缝集成，实现信息的共享和流转，提高企业的业务效率。
同时，它还可以与ORACLE数据库进行集成，实现数据的共享和存储。
其次，ORACLEEBS拥有丰富的功能和强大的定制能力。
它提供了大量的功能模块和标准业务流程，可以满足不同企业的需求。
同时，它还允许企业进行定制开发，根据自身的业务特点和需求来进行个性化配置。
再次，ORACLEEBS具有灵活的部署选项。
它可以在企业内部部署，也可以通过云服务进行部署。
ORACLEEBS基础设置之组织架构
ORACLEEBS基础设置之组织架构ORACLE EBS（Enterprise Business Suite）是甲骨文公司开发的一款集成式企业资源规划（ERP）软件系统，可以帮助企业进行各类业务的管理和协调。
在使用ORACLE EBS之前，首先需要进行一系列的基础设置，其中之一就是组织架构的设置。
组织架构是指企业内部不同部门之间的关系和职责分工。
在ORACLEEBS中，通过设置组织架构可以实现企业内部各部门之间的协作和信息流动。
下面将详细介绍ORACLEEBS中组织架构的设置。
首先，要设置组织架构，需要在ORACLEEBS中创建组织。
组织可以包括多个级别，一般组织架构最高层级为公司，下面可以包括多个业务单元，每个业务单元下面又可以包括多个部门。
通过这样的层级结构可以实现不同组织之间的隔离和相互关联。
在创建组织时，需要输入组织的详细信息，包括组织名称、组织代码、组织类型等。
组织类型可以根据企业的实际情况进行设置，常见的组织类型包括公司、业务单元、地区、部门等。
通过设置不同的组织类型，可以实现对不同组织的不同管理需求。
在设置组织架构时，还可以设置组织之间的关系。
ORACLEEBS可以支持不同组织之间的父子关系、兄弟关系等。
通过设置组织之间的关系，可以实现信息的共享和协同，提高组织的工作效率。
在进行组织架构设置之后，还需要进行职责和职位的设置。
职责是指组织架构中不同部门或职位的职责和权限。
职位是指组织中不同职员所担任的职位。
通过设置职责和职位，可以实现对组织内部人员的权限管理和工作分配。
在设置职责和职位时，需要指定职责和职位的名称、描述、权限等信息。
通过设置不同的权限，可以限制不同职责和职位的操作范围，提高组织的安全性和保密性。
最后，还需要设置组织的层次结构和员工的隶属关系。
通过设置组织的层次结构，可以实现组织之间的上下级关系。
通过设置员工的隶属关系，可以将员工与特定的组织或职位进行关联，方便进行人员的管理和工作分配。
Oracle_EBS多组织结构
多组织结构ORACLE EBS一个很大的卖点是它的多组织结构．ORACLE EBS的文档资料里面解释呈现这样一个树型图：未完待续.实际上, ORACLE电子商务套件中的组织属性可以分为如下几类:1. 业务组: 它代表组织结构的最高层次, 它分离了人力资源的信息. 例如, 当你查询人员时, 它会列出所有分配给相应业务组的成员, 而你自己所属于的组织只不过是业务组的一份子. 这样说可能造成一种误解: 一个公司只能有一个业务组, 实际上可能有多个, 但是业务组之间不能共享信息.2. 帐簿: 它其实不能称为一种组织, 更象组织中的一个层次或性. 一个业务组中可以有一个或者多个帐簿.3. 法律实体: 法律实体类型赋予组织税码以及其它与法律相关的属性. 一套帐簿可以分配给多个法律实体.4. 平衡实体: 平衡实体就是帐户结构中的一个段, 即平衡段. 在你准备财务报表的时候它体现你的帐户实体.5. 业务实体: 如果一个组织应用到现金管理, 订单管理, 运输, 应收, 应付和采购模块, 则它就是一个业务实体. 它可能是一个销售中心, 一个分公司, 或者一个部门. 对于这些应用, EBS按照法律实体分离了业务信息, 每个用户只能访问到他自己所属于的业务实体的信息. 一个法律实体下面可以有一个或者多个业务实体.6. 库存组织: 当一个组织要用到库存事物(例如接收, 转移等), 或者它要负责制造和分销产品时, 这个组织就是一个库存组织. 它可能是一个制造厂, 仓库, 分销中心或者销售部门. 当用到下列模块时, EBS按照库存组织来分割业务信息: Oracle Inventory, Bills of Material, Engineering, Work in Process, Master Scheduling/MRP, Capacity, and Purchasing receiving functions. 当你登陆到这些模块时, ORACLE EBS会提示你选择一个库存组织. 同样, 一个业务实体下面可以有一个或者多个库存组织.7. 人力资源组织: 它体现了一个公司的基本工作结构. 只有当一个组织是人力资源组织时, 你才能分配人员给这个组织. 一个业务组中可以有一个或者多个人力资源组织.8. 资产组织: 资产组织属性使组织可以执行与资产相关的功能. 只有当一个组织属于资产组织时, 才能使用Oracle Assets.还需要说明一点的是: EBS的一个组织并非只能归属于一个类型. 例如, 例如, 一个组织是一个业务实体, 若在这个组织中要用到Oracle Inventory, 那么它同时还是一个库存组织. 所以, 组织类型代表了组织的一种属性, 而不是把组织简单的分类.当你在实施的时候, 可能用不同的模型来描述组织结构.当你在实施HR的时候, 你可能会按照下图来描述:这个模型中, 业务组是公司中的顶层组织. 再下面是政府报告实体, 它体现了联邦或本地政府确认你作为一个雇员的方式. 再下面就是人力资源组织.当你在实施制造, 物流和财务的时候, 你更加可能按下图所示去进行组织的设置:实际上, 这个图形也基本上决定了你的组织的设置的顺序. 一般来说, 一个集团公司下面可能设置一个或多个业务组, 一个业务组下面可能包含一个或多个帐套, 一个帐套下面可能有一个或多个业务实体(也就是多个子公司共用一个帐套), 一个业务实体下面可能有一个或多个业务机构, 一个业务机构下面又可能有一个或多个库存组织, 一个库存组织下面又可能有一个或多个子库存, 在下面依次是库位和货架(相当于行和列).这两种模型并非是孤立的, 而应该综合考虑. 例如, 你设置一个业务组织, 但同时你还要分配人员给这个组织, 那么你同时还要把它设置为一个HR组织.接下来我们来讨论如何实施多组织结构，我们将遵循如下步骤：1．规划和描述组织结构。
ORACLE-EBS-OU-BG-INV-HR等组织架构介绍
ORACLEEBS-组织架构介绍（一）业务组（（一）业务组（BG）（二）法律实体（LE）（三）业务实体（OU）（四）库存组织（INV）（五）公司成本中心（CostCenter）（六）HR组织（七）多组织接入控制在企业管理实践の过程中，“组织”（Organization）一词是个经常需用到の概念，一般与“人员”与“职能”这两个要素密切相关，反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等。
企业内部行政组织（部门）の划分是企业基于“职能驱动”业务管理模式进行运作の基础。
目前，国内适用于小企业使用の大多数低端管理软件并不考虑系统中の“组织”设置问题，其系统应用模块の划分，例如采购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作の“组织职能”划分问题。
但是，对于业务复杂、规模较大の企业（如所谓“集团企业”），管理软件使用与实施の系统“组织设置”问题将是一个首要の重要问题。
一个常见の、也是错误の系统实现方式就是将企业の“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。
这种系统实现方式虽有理解、掌握比较容易の优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式の基本管理原则。
国内有所谓高端管理软件在系统实施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织の“盛况”，导致系统几乎没法使用の困境，其症结正在于此。
与企业の“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统の“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大の过程中具有延续性与继承性。
作为ERP鼻祖のSAP将系统组织简单地分为“集团（Client）、公司代码（CompanyCode）、采购组织（PurchaseOrg）、销售组织（SaleOrg）、工厂（Plant）”等类别。
ORACLE の组织设置本质上与之基本相似，但作为后来者作了进一步抽象与简化，系统组织划分为“业务组（BusinessGroup）、法律实体（LegalEntity）、业务实体（OperatingUnit）、库存组织（InventoryOrg）”等。
ORACLEEBS多组织架构简介
Oracle EBS 多组织结构ORACLE EBS一个很大的卖点是它的多组织结构．ORACLE EBS的文档资料里面解释呈现这样一个树型图：未完待续.接上.实际上, ORACLE电子商务套件中的组织属性可以分为如下几类:1. 业务组: 它代表组织结构的最高层次, 它分离了人力资源的信息. 例如, 当你查询人员时, 它会列出所有分配给相应业务组的成员, 而你自己所属于的组织只不过是业务组的一份子. 这样说可能造成一种误解: 一个公司只能有一个业务组, 实际上可能有多个, 但是业务组之间不能共享信息.2. 帐簿: 它其实不能称为一种组织, 更象组织中的一个层次或性. 一个业务组中可以有一个或者多个帐簿.3. 法律实体: 法律实体类型赋予组织税码以及其它与法律相关的属性. 一套帐簿可以分配给多个法律实体.4. 平衡实体: 平衡实体就是帐户结构中的一个段, 即平衡段. 在你准备财务报表的时候它体现你的帐户实体.5. 业务实体: 如果一个组织应用到现金管理, 订单管理, 运输, 应收, 应付和采购模块, 则它就是一个业务实体. 它可能是一个销售中心, 一个分公司, 或者一个部门. 对于这些应用, EBS按照法律实体分离了业务信息, 每个用户只能访问到他自己所属于的业务实体的信息. 一个法律实体下面可以有一个或者多个业务实体.6. 库存组织: 当一个组织要用到库存事物(例如接收, 转移等), 或者它要负责制造和分销产品时, 这个组织就是一个库存组织. 它可能是一个制造厂, 仓库, 分销中心或者销售部门. 当用到下列模块时, EBS按照库存组织来分割业务信息: Oracle Inventory, Bills of Material, Engineering, Work in Process, Master Scheduling/MRP, Capacity, and Purchasing receiving functions. 当你登陆到这些模块时, ORACLE EBS会提示你选择一个库存组织. 同样, 一个业务实体下面可以有一个或者多个库存组织.7. 人力资源组织: 它体现了一个公司的基本工作结构. 只有当一个组织是人力资源组织时, 你才能分配人员给这个组织. 一个业务组中可以有一个或者多个人力资源组织.8. 资产组织: 资产组织属性使组织可以执行与资产相关的功能. 只有当一个组织属于资产组织时, 才能使用Oracle Assets.还需要说明一点的是: EBS的一个组织并非只能归属于一个类型. 例如, 例如, 一个组织是一个业务实体, 若在这个组织中要用到Oracle Inventory, 那么它同时还是一个库存组织. 所以, 组织类型代表了组织的一种属性, 而不是把组织简单的分类.当你在实施的时候, 可能用不同的模型来描述组织结构.当你在实施HR的时候, 你可能会按照下图来描述:这个模型中, 业务组是公司中的顶层组织. 再下面是政府报告实体, 它体现了联邦或本地政府确认你作为一个雇员的方式. 再下面就是人力资源组织.当你在实施制造, 物流和财务的时候, 你更加可能按下图所示去进行组织的设置:实际上, 这个图形也基本上决定了你的组织的设置的顺序. 一般来说, 一个集团公司下面可能设置一个或多个业务组, 一个业务组下面可能包含一个或多个帐套, 一个帐套下面可能有一个或多个业务实体(也就是多个子公司共用一个帐套), 一个业务实体下面可能有一个或多个业务机构, 一个业务机构下面又可能有一个或多个库存组织, 一个库存组织下面又可能有一个或多个子库存, 在下面依次是库位和货架(相当于行和列).这两种模型并非是孤立的, 而应该综合考虑. 例如, 你设置一个业务组织, 但同时你还要分配人员给这个组织, 那么你同时还要把它设置为一个HR组织.接下来我们来讨论如何实施多组织结构，我们将遵循如下步骤：1．规划和描述组织结构。
ORACLE EBS 基础设置之组织架构
ORACLE EBS 基础设置之组织架构四、组织架构在企业管理实践的过程中，“组织”（Organization）一词是个经常需用到的概念，一般与“人员”与“职能”这两个要素密切相关，反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等。
企业内部行政组织（部门）的划分是企业基于“职能驱动”业务管理模式进行运作的基础。
目前，国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的“组织职能”划分问题。
但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题。
一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。
这种系统实现方式虽有理解、掌握比较容易的优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。
国内有所谓高端管理软件在系统实施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况”，导致系统几乎没法使用的困境，其症结正在于此。
与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。
作为ERP鼻祖的SAP将系统组织简单地分为“集团（Client）、公司代码（Company Code）、采购组织（Purchase Org）、销售组织（Sale Org）、工厂（Plant）”等类别。
ORACLE的组织设置本质上与之基本相似，但作为后来者作了进一步抽象与简化，系统组织划分为“业务组（Business Group）、法律实体（Legal Entity）、业务实体（Operating Unit）、库存组织（Inventory Org）”等。
ebs系统架构简介1——三层结构上篇
ebs系统架构简介1——三层结构上篇《 Applications DBA 基础》3- 4 系统架构及基本系统管理知识1. 系统架构介绍==============Oracle 的applications 主要包括⼀个⽂件系统，⼀个数据库：⽽⽂件系统包括：forms（⽤来交互和更新数据）、reports（⽤来显⽰标准的输出数据）、⼀致性程序（提供了⼤容量、⾮交互的数据更新操作）、程序和sql脚本（管理这个系统）、html和java（⽤来显⽰⽤户界⾯和实现商业应⽤）数据库包括：数据对象（表、索引等）、代码对象（sql、plsql块，过程、函数、触发器）分层架构分析：1、Desktop Tier：Oracle applications 的架构是 multi-tier 的。
不同层有不同的 components 如下：在Desktop Tier 上既有典型的HTML界⾯⼜有传统的 FORMS 界⾯。
FORMS界⾯通过Forms client Applet （Java client Applet的⼀种）与应⽤服务器联系，下载有关的JAR file。
原来的11i 需要 Oracle 专⽤的JVM，叫 Jinitiator。
R12 中只需要标准的 J2SE plugin JVM。
JAR ⽂件包含了所有需要的类⽂件，⽤来显⽰ebs所有描述性的form表单。
对于form 客户端的applet，⼀般常⽤的jar⽂件在第⼀次session的时候就会下载到本地；但是对于不常⽤的jar⽂件，使⽤的时候才会下载下来。
所有下载下来的⽂件都会cache到本地的客户端，以供后续的会话使⽤，具体的cache⽬录如下：<HOMEDRIVE>\Documents and Settings\<Windows User Name>\Application Data\Sun\Java\Deployment\cache 我⾃⼰的在这个⽬录⾥：C:\Users\liu\AppData\LocalLow\Sun\Java\Deployment\cache在R12中，我们可通过java插件的控制台（从哪个java图标点——打开控制⾯板——⾼级——java控制台）所有对jar⽂件的更新都会被安装到应⽤层，然后才会被⾃动下载到客户端那⼀层。
多组织结构(1)
多组织结构
ORACＬE ＥBS一个很大的卖点是它的多组织结构.OＲACLＥEBS的文档资料里面解释呈现这样一个树型图:
未完待续.
接上.
实际上, ORＡCLE电子商务套件中的组织属性可以分为如下几类：
1. 业务组: 它代表组织结构的最高层次, 它分离了人力资源的信息. 例如, 当你查询人员时，它会列出所有分配给相应业务组的成员，而你自己所属于的组织只不过是业务组的一份子. 这样说可能造成一种误解: 一个公司只能有一个业务组, 实际上可能有多个, 但是业务组之间不能共享信息.
2. 帐簿：它其实不能称为一种组织, 更象组织中的一个层次或性．一个业务组中可以有一个或者多个帐簿.
3. 法律实体: 法律实体类型赋予组织税码以及其它与法律相关的属性. 一套帐簿可以分配给多个法律实体.
4. 平衡实体: 平衡实体就是帐户结构中的一个段，即平衡段．在你准备财务报表的时候它体现你的帐户实体.
5. 业务实体: 如果一个组织应用到现金管理, 订单管理, 运输, 应收, 应付和采购模块, 则它就是一个业务实体. 它可能是一个销售中心，一个分公司, 或者一个部门. 对于这些应用, EＢS按照法律实体分离了业务信息，每个用户只能访问到他自己所属于的业务实体的信息. 一个法律实体下面可以有一个或者多个业务实体.
6．库存组织：当一个组织要用到库存事物(例如接收，转移等), 或者它要负责制造和分销产品时, 这个组织就是一个库存组织. 它可能是一个制造厂, 仓库, 分销中心或者销售部门. 当用到下列模块时, ＥBＳ按照库存组织来分割业务信息: Oｒａｃlｅ Inventorｙ, Ｂiｌｌs of Material, Eｎgineeｒing, Worｋｉn Procesｓ, Mａｓter Schｅduｌｉ。
ORACLE EBS-组织架构介绍-8页文档资料
ORACLE EBS-组织架构介绍（一）业务组（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）”等。
Oracle_EBS_学习手册一_系统组织架构设置
系统架构的设置操作手册作者：hzs创建日期：2011年12月2日更新日期：年月日版本： 1.0目录目录 (2)系统组织结构的概述 (3)系统组织结构模型 (3)系统组织结构操作 (4)构建系统组织结构 (4)定义总帐职责 (4)定义库存职责 (5)定义应付管理职责 (6)定义应收管理职责 (7)定义地点 (8)定义业务组 (8)库存职责关联业务组 (9)定义帐套 (10)定义段 (10)定义值集 (15)定义会计日历 (17)定义法人实体 (18)设置会计科目 (19)总帐职责关联分类账 (23)定义业务实体 (24)库存职责关联业务实体 (26)定义库存组织 (27)库存职责和库存组织关联 (30)系统组织结构模型业务组安通公司hzs_INV构建系统组织结构定义总帐职责路径：建立职责（N）系统管理员->安全性->责任->定义将“总账”职责关联用户定义库存职责路径：建立职责（N）系统管理员->安全性->责任->定义1 定义“库存”职责将用户和职责关联定义应付管理职责路径：建立职责（N）系统管理员->安全性->责任->定义1 定义职责2 将用户和职责关联定义应收管理职责路径：建立职责（N）系统管理员->安全性->责任->定义1 定义职责2 将用户和职责关联路径：库存职责（N）设置->组织->地点定义业务组路径：库存职责（N）设置->组织->组织1 “地点”信息填入业务组中2 填写业务组信息路径：系统管理员（N）配置文件->系统点击查找，选择“地点”和“库存职责”定义帐套定义段路径：设置->财务系统->弹性域->关键字->段1 找到应用产品总帐管理系统添加hzs_acc_flex01键弹性域2 点击段，进入定义段3 点击值集定义最大尺寸填写值集名称4 点击弹性域限定词启用balancing segment5 定义成本中心段按上述步骤进行截图：限定词的选择6 定义科目段启用弹性域限定词natural account segment7 定义备用段8 冻结弹性域，若弹性域不冻结则不可以使用定义值集路径：设置->财务系统->弹性域->关键字->段1 定义公司段的值集有效值2 定义成本中心段出现问题：在定义层次结构限定词时出现不能设定，显示灰色4 解决问题后完成后如下图(现在已经使用dataload 导入科目)5 定义其他段的值集定义会计日历路径：设置->财务系统->日历->类型1 定义会计周期为13个，最后一个为调整期2 定义会计期间定义法人实体路径：设置->财务系统->会计科目设置管理器->会计科目设置1 创建法人实体：安通_hzs设置会计科目路径：设置->财务系统->会计科目设置管理器->会计科目设置说明：会计科目的设置将有以下三个步骤，分别是分配法人主体，定义会计科目表示，以及保存会计结构。
ORACLE EBS-组织架构介绍
（一）业务组（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）”等。
oracleebs简介
oracleebs简介哎。
现在这年头，只搞db⼈越来越少，dba的地位越来越低。
没办法。
为了⽣存，哥哥决定再跨⼀个新的领域，去oracle的应⽤领域去学oracle ebs去。
开⼯：ebs的内部技术架构：简单概括为如下⼏个部分：多组织、多语⾔、多币种、模块化，集成性、并发处理、多技术混⽤。
我们看⼀下ebs R12的服务器架构组成：2、名词解释ERP系统中有很多职能集成所必需，但⼿⼯管理⽅式下所没有的重要名词。
以下⼀⼀解释这些名词的意义及功能。
1．现存量(On Hand Quantity)即仓库中现有料品（成品、半成品、采购件）的库存数量。
如果按英⽂直译叫做“在⼿量”，所以现存量表⽰⼀个已经拥有的料品的数量。
2．在单量(On Order Quantity)假设本公司向供应商发出⼀张采购订单，采购A料品300个库存单位，这时我们就可以说料品A的“在单量”为300个库存单位。
在单量表⽰“已经计划好了将来要有，但⽬前还未真正拥有的数量”，直观地把它想象成是⼀个“在单据上的”数量。
（1）对采购件⽽⾔：指已下采购订单⽽供应⼚商尚未交货（验收⼊库）的数量。
（2）对⾃制成品、半成品⽽⾔：指已下⽣产订单⽽制造车间尚未完⼯⼊库的数量。
（3）对委外件⽽⾔：指已下达委外单⽽委外⼚商尚未交货（验收⼊库）的数量。
3．预约量(Allocated Quantity)如果客户向本公司下单订购A产品100台，双⽅约定20天后交货。
这时产品A的“预约量”就为100台。
“预约”表⽰⼀种“将来要发⽣⽽现在还没有发⽣的”需求量。
为什么在接到客户订单时，电脑系统要记录客户订购产品的“预约量”呢？因为预约量代表⼀种“待发”的数量，可以让我们事先预估料品将来的现存量是否会不⾜，⽽针对可能发⽣的缺货状况预作准备。
（1）对采购件⽽⾔：已发⽣产订单或委外单，要领⽤⽽车间或委外⼚商尚未领料的数量。
（2）对成品⽽⾔：已接到客户订单⽽尚未交货的数量。
（3）对⾃制半成品⽽⾔：已发⽣产订单或委外单，要领⽤⽽车间或委外⼚商尚未领料的数量。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
OracleEBS多组织结构
ORACLEEBS一个很大的卖点是它的多组织结构．ORACLEEBS的文档资料里面解释呈现这样一个树型图：
未完待续.
接上.
实际上,ORACLE电子商务套件中的组织属性可以分为如下几类:
1.业务组:它代表组织结构的最高层次,它分离了人力资源的信息.例如,当你查询
人员时,它会列出所有分配给相应业务组的成员,而你自己所属于的组织只不过是业务组的一份子.这样说可能造成一种误解:一个公司只能有一个业务组,实际上可能有多个,
但是业务组之间不能共享信息.
2.帐簿:它其实不能称为一种组织,更象组织中的一个层次或性.一个业务组中可以有一
个或者多个帐簿.
3.法律实体:法律实体类型赋予组织税码以及其它与法律相关的属性.一套帐簿可以分配给多个法律实体.
4.平衡实体:平衡实体就是帐户结构中的一个段,即平衡段.在你准备财务报表的时候它
体现你的帐户实体.
5.业务实体:如果一个组织应用到现金管理,订单管理,运输,应收,应付和采购模块,
则它就是一个业务实体.它可能是一个销售中心,一个分公司,或者一个部门.对于这些
应用,EBS按照法律实体分离了业务信息,每个用户只能访问到他自己所属于的业务实体的信息.一个法律实体下面可以有一个或者多个业务实体.
6.库存组织:当一个组织要用到库存事物(例如接收,转移等),或者它要负责制造和分销
产品时,这个组织就是一个库存组织.它可能是一个制造厂,仓库,分销中心或者销售部门.当用到下列模块时,EBS按照库存组织来分割业务信息:OracleInventory,Billsof Material,Engineering,WorkinProcess,MasterScheduling/MRP,Capacity,and Purchasingreceivingfunctions.当你登陆到这些模块时,ORACLEEBS会提示你选择一
个库存组织.同样,一个业务实体下面可以有一个或者多个库存组织.
7.人力资源组织:它体现了一个公司的基本工作结构.只有当一个组织是人力资源组织时, 你才能分配人员给这个组织.一个业务组中可以有一个或者多个人力资源组织.
8.资产组织:资产组织属性使组织可以执行与资产相关的功能.只有当一个组织属于资产组织时,才能使用OracleAssets.
还需要说明一点的是:EBS的一个组织并非只能归属于一个类型.例如,例如,一个组织是一个业务实体,若在这个组织中要用到OracleInventory,那么它同时还是一个库存组织. 所以,组织类型代表了组织的一种属性,而不是把组织简单的分类.
当你在实施的时候,可能用不同的模型来描述组织结构.
当你在实施HR的时候,你可能会按照下图来描述:
这个模型中,业务组是公司中的顶层组织.再下面是政府报告实体,它体现了联邦或本地政府确认你作为一个雇员的方式.再下面就是人力资源组织.
当你在实施制造,物流和财务的时候,你更加可能按下图所示去进行组织的设置:
实际上,这个图形也基本上决定了你的组织的设置的顺序.一般来说,一个集团公司下面可能设置一个或多个业务组,一个业务组下面可能包含一个或多个帐套,一个帐套下面可能有一个或多个业务实体(也就是多个子公司共用一个帐套),一个业务实体下面可能有一个或多个业务机构,一个业务机构下面又可能有一个或多个库存组织,一个库存组织下面又可能有一个或多个子库存,在下面依次是库位和货架(相当于行和列).
这两种模型并非是孤立的,而应该综合考虑.例如,你设置一个业务组织,但同时你
还要分配人员给这个组织,那么你同时还要把它设置为一个HR组织.
接下来我们来讨论如何实施多组织结构，我们将遵循如下步骤：
1．规划和描述组织结构。
这一步是关键，实施多组织结构能否成功，就在于能否正确描述它，组织结构应该能够描述成如下层次结构：
⑴，业务组
⑵，会计帐簿
⑶，法律实体
⑷，业务实体
⑸，库存组织
2．定义会计帐簿：这一步使用GENERALEDGER职责实现。
会计科目弹性域，币种，会计日历是定义会计帐簿的三要素。
因此，本步骤假定这些已经完成。
3．定义地点：每一个组织总是对应于一个地点，也可能多个组织使用同一个地点。
ORACLE EBS使用地点来实现采购申请，接收，运输清单和人员分配。
4．定义业务组：系统中必须至少有一个业务组.你可以根据需要创建新的业务组.若不需
要用到多个业务组,则你可以使用系统中预定义的业务组,通过部分修改来满足你的要求. 若你创建了一个新的业务组,则你需要在职责层修改参数才能访问新的业务组.在你创建
了一个新的业务组之后,ORACLEHR自动创建一个以新业务组名字命名的安全参数值.你必
须在创建其它任何类型的组织之前定义好你所有的业务组,因为业务组会隔离包括组织结
构在内的所有业务信息,你如,你在一个业务组定义的人员信息,任何其他的业务组都不
可能访问.以下步骤教你如何定义一个新的业务组:
⑴,首先,你必须在职责层修改参数HR:UserType的值为HRUser,从而使这个职
责可以访问定义组织窗口.这个职责一般是Inventory或者HumanResources.
如图:
⑵,以刚才被修改参数的职责登陆到定义组织窗口,定义所有的业务组.如图:
在赋予组织以业务组属性时,会要求你输入业务组信息,包括人力资源模块的各种弹性域结构,在此假设这些弹性域结构已经被设置好,如图:
定义完所有的业务组之前,请不要定义任何其它类型的组织,因为任何职
责在任意时刻只能关联到一个业务组,你当前登陆所用的职责只能访问当前职责所对应的业务组,而不能同时访问其它任何业务组;也就是说,你在当前职
责下定义的任何非业务组类型的组织都自动对应到当前业务组,如果你还想定义其它业务组下面的非业务组类型的组织,你必须修改相应职责的参数HR: SecurityProfile的值为这个业务组所对应的安全参数值然后再重新登陆(前面讲到过,在你创建了一个新的业务组之后,ORACLEHR自动创建一个以新业务组名字命名的安全参数值).如图:
创建了新的业务组之后,你还应该让需要访问这个业务组数据的职责与之建立关联,完成这项工作需设置职责层参数HR:BusinessGroup,如图:
⑶,接下来就是用已经关联到相应业务组的职责登陆,创建属于这个业务组的的各种组织了.首先创建法律实体,以此职责创建的法律实体都会自动关连到这个业务组.接着创建业务实体,会要求你输入业务组信息,包括它所属于的法律实体和帐簿信息.如图:
接着创建库存组织,会要求你输入法律实体和帐簿信息和它所属于的业务实体信息.如图:
若这个组织同时还要用到资产管理,你还要赋予此组织资产组织的属性或者新建一个资产组织.若要分配人员到某个组织,则你要赋予此组织为HR组织,如图:
WORD格式
设置完一个业务组下面的组织结构之后,若你还需要设置其他业务组的组织结构, 请退出当前登陆,然后用已经关联到这个业务组的职责登陆,创建各种组织, 它们会自动对应到这个业务组.按照这个顺序创建的组织,它们(业务组,法律实体,业务实体,库存组织)会呈现出如下图所示的关系:
这里,只是完成了公司组织框架.在真正实施的时候,还有很多与各模块和职责相关的参数需要设置.留待下一步再讨论.
Z专业资料整理。