下载文档原格式
ORACLE EBS系统应用基础概述一、前言二、表单与查询（Form and Summary）三、事务处理（Transaction）四、并发流程（Current Process）五、文件夹（Folder）六、弹性域（Flex field）七、值集与查找代码（Value Set and Lookup Code）八、配置文件（Profile）九、单据编号（Document Sequence）十、工作流（Workflow）十一、预警（Alert）十二、应用开放接口（Open Interface and API）十三、结语（注：网站批量发图有问题，上传后显示不清楚。
点击图片打开后，质量尚可）一、前言有网友在论坛发帖惊呼：好不容易把EBS系统安装好了，进去一看傻眼了，不知道从哪儿下手？发出惊叹的这位网友所遇到的问题，实际上也是很多人曾经遇到或正在遇到的问题。
长期以来，国内的非专业人士（例如媒体）提及SAP 或ORACLE的时候，有不少人喜欢用“超级难懂”来形容。
那么，国内专业人士的看法又如何呢？笔者所听到过的最“雷”的说法来自一位国内软件研发的高层主管：SAP/ORACLE太复杂了，其背后的东西、深层次的东西，我们永远不可能搞懂！真是太不可思议。
一方面，国内的业内人士几乎众口一词，我们与SAP/ORACLE相比，技术上没有多大差距，平台工具都是公开的，也没有什么奥秘可言。
SAP/ORACLE由于产品做得早，我们在技术上甚至还有后发优势。
另一方面，我们也常常听到国内有些人将SAP/ORACLE神秘化，认为其包含“复杂的、深刻的管理思想”，是德国人/美国人的东西，我们中国人的企业管理水平低，用不了是正常的。
国情不同，模式不同，中国人应该寻找一条适合自己的道路！真的是这样吗？SAP/ORACLE产品真的是那么神秘、高不可攀？今天专业从事ERP工作的人员，若从个人背景角度来看，通常可以划分为“技术出身”与“业务出身”两类。
系列之三：ORACLE EBS系统应用基础概述一、前言二、表单与查询（Form and Summary）三、事务处理（Transaction）四、并发流程（Current Process）五、文件夹（Folder）六、弹性域（Flex field）七、值集与查找代码（Value Set and Lookup Code）八、配置文件（Profile）九、单据编号（Document Sequence）十、工作流（Workflow）十一、预警（Alert）十二、应用开放接口（Open Interface and API）十三、结语一、前言有网友在论坛发帖惊呼：好不容易把EBS系统安装好了，进去一看傻眼了，不知道从哪儿下手？发出惊叹的这位网友所遇到的问题，实际上也是很多人曾经遇到或正在遇到的问题。
长期以来，国的非专业人士（例如媒体）提及SAP或ORACLE的时候，有不少人喜欢用“超级难懂”来形容。
那么，国专业人士的看法又如何呢？笔者所听到过的最“雷”的说法来自一位国软件研发的高层主管：SAP/ORACLE太复杂了，其背后的东西、深层次的东西，我们永远不可能搞懂！真是太不可思议。
一方面，国的业人士几乎众口一词，我们与SAP/ORACLE 相比，技术上没有多大差距，平台工具都是公开的，也没有什么奥秘可言。
SAP/ORACLE由于产品做得早，我们在技术上甚至还有后发优势。
另一方面，我们也常常听到国有些人将SAP/ORACLE神秘化，认为其包含“复杂的、深刻的管理思想”，是德国人/美国人的东西，我们中国人的企业管理水平低，用不了是正常的。
国情不同，模式不同，中国人应该寻找一条适合自己的道路！真的是这样吗？SAP/ORACLE产品真的是那么神秘、高不可攀？今天专业从事ERP工作的人员，若从个人背景角度来看，通常可以划分为“技术出身”与“业务出身”两类。
“技术出身”的人在学习熟悉系统方面可能有一定优势，但与用户沟通交流的过程中，在迅速准确把握业务本质要领方面可能存在一定困难；而“业务出身”的人，对于与用户的业务沟通交流可能感觉比较容易，但在研究掌握系统方面则可能相对困难一些。
ORACLE EBS 基础设置要点简介三、帐套（分类帐）会计科目弹性域结构（COA）、币种（Currency）、日历（Clander）三者的组合构成EBS R11及之前系统的所谓“帐套”（SOB）。
在R12中，再增加一个维度“会计方法或会计惯例”，即成为所谓“分类帐”。
所谓“会计方法或惯例”，例如对于不同国家或地区、不同企业，会计法规可能规定物品单价5000元是作为“固定资产”还是“期间费用”处理的判定标准，也可能规定这个判定标准是1万元。
标准不同，记账的会计科目也就不同，企业报告的经营结果也就会有差别。
一个诸如在香港注册的企业，一方面需要向香港政府机关提交符合本地法规的财务报告，另一方面可能还需要向在国内的总公司提供符合国内法规的财务报告（便于考核管理），这就出现所谓“多账簿”（对应R12中的主辅分类帐）的系统功能问题。
如下图9是EBS R11中“帐套”的定义接口：如下图10所示是EBS R12中使用“会计科目管理器AMB”设置“主要分类帐（Primary Ledger）”与“辅助分类帐（Second Ledger）”的定义接口：R12中定义的一个“主要分类帐”可以附带定义与之关联的多个“辅助分类帐”，如下图11所示：等等，其事务处理默认是基于“主要分类帐”的会计科目表（COA），所以，如果主辅分类帐的科目表不同，则必须在两者之间建立“映射（Mapping）”关系（1对1或多对1的关系）。
如下图12所示为主辅分类帐的映射定义界面，如果两者科目表相同（币种不同），则该定义界面将有所不同，没有“科目表”映射的内容，只有后面部分（币种转换及日记账转换等）：下图13所示为当主辅分类帐的科目表不同时，系统科目表映射的定义界面，账户规则定义中可见，源账户可以是一个范围，而目标账户只能是一个：ORACLE EBS R12中四维（4C）定义的“分类帐Ledger”构成了ORACLE系统“多账簿”功能的处理基础。
EBS基础要点简介-帐套（分类帐）ORACLE EBS 基础设置要点简介三、帐套（分类帐）会计科目弹性域结构（COA）、币种（Currency）、日历（Clander）三者的组合构成EBS R11及之前系统的所谓“帐套”（SOB）。
在R12中，再增加一个维度“会计方法或会计惯例”，即成为所谓“分类帐”。
所谓“会计方法或惯例”，例如对于不同国家或地区、不同企业，会计法规可能规定物品单价5000元是作为“固定资产”还是“期间费用”处理的判定标准，也可能规定这个判定标准是1万元。
标准不同，记账的会计科目也就不同，企业报告的经营结果也就会有差别。
一个诸如在香港注册的企业，一方面需要向香港政府机关提交符合本地法规的财务报告，另一方面可能还需要向在国内的总公司提供符合国内法规的财务报告（便于考核管理），这就出现所谓“多账簿”（对应R12中的主辅分类帐）的系统功能问题。
如下图9是EBS R11中“帐套”的定义接口：如下图10所示是EBS R12中使用“会计科目管理器AMB”设置“主要分类帐（Primary Ledger）”与“辅助分类帐（Second Ledger）”的定义接口：R12中定义的一个“主要分类帐”可以附带定义与之关联的多个“辅助分类帐”，如下图11所示：等等，其事务处理默认是基于“主要分类帐”的会计科目表（COA），所以，如果主辅分类帐的科目表不同，则必须在两者之间建立“映射（Mapping）”关系（1对1或多对1的关系）。
如下图12所示为主辅分类帐的映射定义界面，如果两者科目表相同（币种不同），则该定义界面将有所不同，没有“科目表”映射的内容，只有后面部分（币种转换及日记账转换等）：下图13所示为当主辅分类帐的科目表不同时，系统科目表映射的定义界面，账户规则定义中可见，源账户可以是一个范围，而目标账户只能是一个：ORACLE EBS R12中四维（4C）定义的“分类帐Ledger”构成了ORACLE系统“多账簿”功能的处理基础。
ORACLE_EBS_系统应用基础概述ORACLE EBS（Enterprise Business Suite）是由ORACLE公司开发的一套集成化的企业应用系统，用于管理企业的关键业务流程。
它包括了财务、人力资源、供应链管理、供应商关系管理、生产制造、销售和客户关系管理等多个模块，帮助企业实现业务处理的自动化和优化。
首先，ORACLEEBS的核心模块包括财务管理、人力资源管理和供应链管理。
财务管理模块包括总账、应付账款、应收账款等功能，用于管理企业的财务状况和流动资金。
人力资源管理模块包括员工档案、薪资管理、绩效评估等功能，用于管理企业人力资源。
供应链管理模块包括采购、仓库管理、物流等功能，用于优化企业的供应链流程。
其次，ORACLEEBS还提供了供应商关系管理和生产制造模块。
供应商关系管理模块包括供应商评估、合同管理、供应商支付等功能，用于优化企业与供应商之间的合作关系。
生产制造模块包括生产计划、物料需求计划、生产执行等功能，用于提高企业的生产效率和产品质量。
除了核心模块外，ORACLEEBS还提供了销售和客户关系管理模块。
销售模块包括销售订单管理、合同管理、销售报价等功能，用于管理企业的销售过程和客户关系。
客户关系管理模块包括客户档案、客户服务、市场营销等功能，用于提高企业的客户满意度和市场竞争力。
首先，ORACLEEBS具有高度的集成性。
它可以与其他企业应用系统（如CRM系统、SCM系统）进行无缝集成，实现信息的共享和流转，提高企业的业务效率。
同时，它还可以与ORACLE数据库进行集成，实现数据的共享和存储。
其次，ORACLEEBS拥有丰富的功能和强大的定制能力。
它提供了大量的功能模块和标准业务流程，可以满足不同企业的需求。
同时，它还允许企业进行定制开发，根据自身的业务特点和需求来进行个性化配置。
再次，ORACLEEBS具有灵活的部署选项。
它可以在企业内部部署，也可以通过云服务进行部署。
系列之三：ORACLE EBS 系统应用基础概述（D）热度 15已有 1021 次阅读2009/11/14 21:18|关键词:EBS ORACLE 系统基础概述ORACLE EBS 系统应用基础概述十一、预警（Alert）十二、应用开放接口（Open Interface and API）十三、结语（注：网站批量发图有问题，上传后显示不清楚。
点击图片打开后，质量尚可）十一、预警（Alert）今天在企业的办公场所或酒店的房间等很多地方，我们都可以见到天花板上装有“烟感报警器”以及“自动喷淋器”，国家对建筑物的消防安全有明确的法律法规，因此这些“报警或灭火”装置几乎已成了建筑物的标准配置。
与之类似，预警平台对于今天的ERP系统来说也几乎是一个标准装备，无论是从系统实现角度还是从业务应用角度来看，它都不是很复杂，比较容易掌握。
ORACLE 的系统预警分两种方式，一是“事件预警”，二是“周期预警”。
两者的基本工作方式均是使用SQL Select语句基于对数据库中的相关值作出条件判定，以决定是否执行某种活动（发出信息，执行并发程序、执行操作系统程序、执行SQL语句）。
更进一步，对于“发出信息”类预警，系统在收到对此信息的符合规定格式的“回复”后，还可以据此自动执行相关活动并完成相关事务处理。
所谓“事件预警”，即当用户在相关数据表中“插入”或“更新”某些值时，系统自动启动已定义的“SQL Select语句”的检查，已确定是否需要发出预警信息或执行某种活动，如下图33所示的一个事件预警定义：在采购管理系统模块中，当出现一个巨大数量的申请行数量被输入时，系统需要向相关责任人发出预警通知（以提醒诸如做好资源准备等）。
所谓“周期预警”，即系统按照事先定义好的周期间隔或频率，自动启动已定义的“SQL Select语句”针对数据库中表的某些值作检查，已确定是否需要发出预警信息或执行某种活动，如下图34所示的一个周期预警定义：在采购管理系统模块中，系统按每两个工作日的间隔频率对所有“一揽子采购协议BPA”的到期情况进行检查，并将需要关注的检查结果（例如某些BPA将在一周之类过期）通知到相关责任人。
系列之三：ORACLE EBS系统应用基础概述一、前言二、表单与查询（Form and Summary）三、事务处理（Transaction）四、并发流程（Current Process）五、文件夹（Folder）六、弹性域（Flex field）七、值集与查找代码（Value Set and Lookup Code）八、配置文件（Profile）九、单据编号（Document Sequence）十、工作流（Workflow）十一、预警（Alert）十二、应用开放接口（Open Interface and API）十三、结语一、前言有网友在论坛发帖惊呼：好不容易把EBS系统安装好了，进去一看傻眼了，不知道从哪儿下手？发出惊叹的这位网友所遇到的问题，实际上也是很多人曾经遇到或正在遇到的问题。
长期以来，国内的非专业人士（例如媒体）提及SAP 或ORACLE的时候，有不少人喜欢用“超级难懂”来形容。
那么，国内专业人士的看法又如何呢？笔者所听到过的最“雷”的说法来自一位国内软件研发的高层主管：SAP/ORACLE太复杂了，其背后的东西、深层次的东西，我们永远不可能搞懂！真是太不可思议。
一方面，国内的业内人士几乎众口一词，我们与SAP/ORACLE相比，技术上没有多大差距，平台工具都是公开的，也没有什么奥秘可言。
SAP/ORACLE由于产品做得早，我们在技术上甚至还有后发优势。
另一方面，我们也常常听到国内有些人将SAP/ORACLE神秘化，认为其包含“复杂的、深刻的管理思想”，是德国人/美国人的东西，我们中国人的企业管理水平低，用不了是正常的。
国情不同，模式不同，中国人应该寻找一条适合自己的道路！真的是这样吗？SAP/ORACLE产品真的是那么神秘、高不可攀？今天专业从事ERP工作的人员，若从个人背景角度来看，通常可以划分为“技术出身”与“业务出身”两类。
“技术出身”的人在学习熟悉系统方面可能有一定优势，但与用户沟通交流的过程中，在迅速准确把握业务本质要领方面可能存在一定困难；而“业务出身”的人，对于与用户的业务沟通交流可能感觉比较容易，但在研究掌握系统方面则可能相对困难一些。
根据笔者曾经做过的调查统计，国内ERP从业人员中“技术出身”的人似乎占了绝大多数。
ORACLE EBS 作为一个有百多个业务应用模块、高度集成的企业管理软件系统，它是现代计算机技术与企业管理实践的高度融合。
它不是模仿企业手工业务过程的“电算化”简单再现，或许正是让很多人感到其“难懂难用”的根本原因所在。
因此，“从实践中来，再到实践中去”，或曰“从业务透视技术，再从技术回归业务”也许正是我们一步一步叩开ORACLE EBS的大门，徜徉其间并游刃有余的方法论。
（这里的所谓“技术”意指“系统实现”）。
业内对于专业从事ERP工作的人员，大致有以下三种分类：一类是所谓“技术顾问”，对于这些人来说，掌握相应的软件开发技能是必要条件，其工作领域的重点一般主要是在系统后台，类似开发系统接口、业务报表，解决一些系统的技术问题等等；二类是所谓“功能顾问”，这些人对于系统的相关模块有不同程度的熟悉，通常是在指导企业使用系统，或努力地在把企业的业务要求变为系统的实现方案；三类是所谓“管理顾问”，这些人通常有比较丰富的企业管理实战经验积累，同时对ERP系统也有比较深刻的认识，能够从企业管理业务流程的整体高度给出咨询建议，最大限度地发掘出ERP系统对于企业管理水平提高的重要作用（这里的“管理顾问”是特指，有别于市面上众多不懂系统、只会“纸上谈兵”的忽悠型“管理顾问”）。
实际工作中，上述三类人员前后之间可能并无明确的划分界线，但大体上有一个随着系统认识水平的提高以及业务运作经验的积累，由低到高发展的过程。
因此，如何实现“从业务角度去透视技术，从技术角度去回归业务”是业内人员所面对的永恒命题，能达到业务与技术的“融会贯通”则是追求的最高境界。
为此，本篇将从博大精深的ORACLE EBS系统最基本的应用基础组成元素开始，从业务—技术—业务，探讨让有些人高深莫测、妄自菲薄的所谓“其背后的东西、深层次的东西”到底是些什么，以便能够最终寻找到帮助我们登堂入室的钥匙与途径。
二、表单与查询（Form and Summary）企业在手工模式下的业务运作过程中，总有各种各样的用于记录业务数据或管理信息的纸面单据，例如“销售订单、采购订单、入库单、出库单”等等。
随着业务量的增加，这些纸面单据的数量是如此之多，以致于企业不得不花费大量人力，将每张单据上的重要信息摘要出来（例如采购订单上的供应商、物料、数量、价格、金额、日期等），另外建立一个数据记录的“索引、清单或台账”等，以方便能在需要时对它们进行查询或统计。
一个最简单的软件管理系统，就是把上述纸面单据“电子化”后放入系统，然后再提供一个在系统里查找这些单据的“查询”功能。
如果你去研究一下目前国内的主流ERP产品，你就会发现这些主要用于中低端市场的国内ERP产品，其每个模块中的应用功能实际主要就是“单据新增与单据查询”这两项。
其单据在系统中的格式和内容与纸面单据是如此近似相像，以致于大多数企业人员学习掌握它们不会感觉有多大困难。
在ORACLE EBS的每个模块中，同样也是要用到各种单据（Form）来录入或保存数据（对应于后台数据库中的“表”），并为之提供相应的查询功能，但ORACLE中的系统单据已经不是纸面单据的简单再现。
系统的UI界面中可以见到各种“表单”（据统计约有3000多种），它们不仅不同于纸面单据，相互之间的性质及查询方式差别也可能很大。
归纳起来，ORACLE各模块中的“表单”按性质与作用大体可分为三大类：第一类是“业务流程”类表单例如“销售订单SO、采购订单PO、制造工单WO、发票INVOICE”等等，它们有一个共同的特点是参与核心业务流程的运转，是核心业务流程的一个环节、不可或缺。
这一点显然也是和实际的企业业务过程是高度相对应的。
作为业务的原始凭据凭证，它们是如此重要，即使是IT系统化之后，大多数企业可能还是要将它们的纸面形态予以保存、归档。
在ORACLE EBS中，“业务流程”类表单种类其实很少（每个模块一般仅一、两个左右），但每种单据随时间日积月累，业务数据量可能很大。
业务流程类表单是系统中最重要的表单，与纸面单据相比，内容更为丰富和复杂，格式也有很大的变化，它充分利用了数据库技术所提供的可容纳性、可扩展性以及使用便利性。
它来源于业务实践，但经高度抽象并融入最新科技成就后，其功能与作用又远远高于原始的纸面单据。
如图1的PO表单:PO表单是一个典型的“业务流程”类表单，它有“表头与表体行”两大部分组成，这一点与纸面单据仍然类似。
但不同的是系统表单的每一个“表体行”，还可以拥有属于自己的“二级子表行”；而每一个“二级子表行”，也可以拥有属于自己的“三级子表行”，如此类推。
这种表单展现方式，纸面单据是无法实现的，它极大地扩充了单据可以包含的信息容量，具有高度的灵活性与便利性。
在图1中，PO的第一行采购总数量为36，对应到“发运”二级子表拆分为数量分别为20与16的两行（表示发到两个不同收货地点或同一地点但两个不同发货时间）；“发运”二级子表的第一行数量为20，对应到“分配”三级子表拆分为数量分别是10与10的两行（表示对应到两个不同的费用会计科目或费用由两个不同部门分别承担）。
第二类是“数据来源”类表单例如“OM模块中的价目表、PO模块中的报价单、”以及“物料、供应商、客户”数据表单等等，它们的共同特点是不参与核心业务流程的构建，但它们为业务流程表单提供可以参考的数据来源，例如采购订单从物料表单取物料相关信息，从供应商表单取供应商信息、从报价单取价格相关信息等等；这类表单在手工业务模式下大多数都可能也存在，但手工状态下的实际使用与管理可能无法做到很严格规范；在ORACLE EBS中，“数据来源”类表单在每个模块中种类可能很多，每种表单的内容与格式复杂程度，以及单据数量也差别很大。
它们虽然并非不可或缺，但它们体现的专业化分工与协作的管理思想，对于企业的业务流程运作效率有重大影响。
下图2所示订单管理/定价模块中的“价目表”，就是一个典型的“数据来源类”表单，它也可有复杂的结构:第三类是“业务控制”类表单例如“销售的物料可订购性、采购的批准供应商列表、系统参数设定”等等，这类表单在手工业务模式下很少或根本不存在。
事实上，手工方式下实际也很难使用它们对业务进行有效控制。
在ORACLE EBS中，“业务控制”类表单在各模块中的种类也比较少，单据数量也很有限，但它们体现的是企业管理的系统控制机制，对于业务管理控制的效率有重要影响。
如下图3所示采购的批准供应商列表（控制可向哪些供应商采购），就是一个比较典型的“业务控制类”表单，它也同样可有复杂的结构。
尽管在ORACLE EBS中，统计后台数据库中所用到的“表”（Table）数量有一万多个，前台UI中可见的表单也形形色色、数量繁多，乍看令人生畏，但在分析归纳划分为以上三大类之后，事情就会变得简单很多，它使得我们可以把每个模块中种类很有限的“核心的业务流程表单”作为学习研究的“切入点”，通过对每种单据内部业务内涵与技术内涵的分析，以及各种单据之间业务逻辑与技术逻辑的研究，逐步扩展并掌握系统的其它功能与应用。
基于实际工作的需要以及系统设计的简洁方便，ORACLE针对上述三种不同类型的表单分别提供了可供选择使用的不同“查询”方法，归纳起来也可分为三类：功能查询方式所谓“功能查询”方式，在系统中有“查询”功能菜单项（例如PO Summary，采购订单汇总），点击此菜单进入时，系统会首先弹出“查找条件”输入窗口（控件），如下图4所示采购订单功能查询菜单与查询条件控件：然后根据输入的查询条件，给出查询结果LIST。
作为查询功能扩展，系统还在UI界面工具栏进一步提供关联查询（如采购订单的上下游单据“采购申请”和“采购发票”）和细节查询功能，如下图5所示采购订单功能查询方式的输出结果视图：功能查询方式通常只用于核心“业务流程”类单据的查询，查询功能强大。
由于业务流程类表单（以及部分数据来源类表单）的重要性，系统在菜单项中提供了专门的“查询”功能。
快捷查询方式所谓“快捷查询”方式即在打开单据界面后，只需点击UI界面工具栏内的查询“图标”（手电筒），查询条件输入方式有两种：一种是无专用的“查询条件”选择窗口，仅限于在查找界面的“查找栏”输入常用的那些字段（即所谓“模糊查询”），系统在查找界面直接给出所有符合条件的条目LIST，而详细情况需选定条目后，再进入单据界面查看，如下图6所示“采购订单”在单据界面进行“快捷查询”的情况：另一种是在单据界面点击查询图标（手电筒）后，也会出现“查询条件”输入窗口，输入查询条件后，系统也可能会出现一个简单的结果清单LIST界面或视图（某些表单查询则可能没有），通过该LIST视图界面可以再选择打开相关条目的表单。
