ORACLEOBS系统应用基础

1、.：.；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系统

2、安装好了，进去一看傻眼了，不知道从哪儿下手？发出惊叹的这位网友所遇到的问题，实践上也是很多人曾经遇到或正在遇到的问题。长期以来，国内的非专业人士例如媒体提及SAP或ORACLE的时候，有不少人喜欢用“超级难懂来描画。那么，国内专业人士的看法又如何呢？笔者所听到过的最“雷的说法一位国内软件研发的高层主管：SAP/ORACLE太复杂了，其背后的东西、深层次的东西，我们永远不能够搞懂！ 真是太不可思议。一方面，国内的业内人士几乎众口一词，我们与SAP/ORACLE相比，技术上没有多大差距，平台工具都是公开的，也没有什么奥妙可言。SAP/ORACLE由于产品做得早，我们在技术上甚至还有后发优势。另一方

3、面，我们也经常听到国内有些人将SAP/ORACLE奥秘化，以为其包含“复杂的、深化的管理思想，是德国人/美国人的东西，我们中国人的企业管理程度低，用不了是正常的。国情不同，方式不同，中国人应该寻觅一条适宜本人的道路！真的是这样吗？SAP/ORACLE产品真的是那么奥秘、高不可攀？今天专业从事ERP任务的人员，假设从个人背景角度来看，通常可以划分为“技术出身与“业务出身两类。“技术出身的人在学习熟习系统方面能够有一定优势，但与用户沟通交流的过程中，在迅速准确把握业务虚质要领方面能够存在一定困难；而“业务出身的人，对于与用户的业务沟通交流能够觉得比较容易，但在研讨掌握系统方面那么能够相对困难一些。

4、根据笔者曾经做过的调查统计，国内ERP从业人员中“技术出身的人似乎占了绝大多数。ORACLE EBS 作为一个有百多个业务运用模块、高度集成的企业管理软件系统，它是现代计算机技术与企业管理实际的高度交融。它不是模拟企业手工业务过程的“电算化简单再现，或许正是让很多人感到其“难懂难用的根本缘由所在。因此，“从实际中来，再到实际中去，或曰“从业务透视技术，再从技术回归业务也许正是我们一步一步叩开ORACLE EBS的大门，徜徉其间并游刃有余的方法论。这里的所谓“技术意指“系统实现。业内对于专业从事ERP任务的人员，大致有以下三种分类：一类是所谓“技术顾问，对于这些人来说，掌握相应的软件开发技艺是必

5、要条件，其任务领域的重点普通主要是在系统后台，类似开发系统接口、业务报表，处理一些系统的技术问题等等；二类是所谓“功能顾问，这些人对于系统的相关模块有不同程度的熟习，通常是在指点企业运用系统，或努力地在把企业的业务要求变为系统的实现方案；三类是所谓“管理顾问，这些人通常有比较丰富的企业管理实战阅历积累，同时对ERP系统也有比较深化的认识，可以从企业管理业务流程的整体高度给出咨询建议，最大限制地开掘出ERP系统对于企业管理程度提高的重要作用这里的“管理顾问是特指，有别于市面上众多不懂系统、只会“纸上谈兵的忽悠型“管理顾问。实践任务中，上述三类人员前后之间能够并无明确的划分界限，但大体上有一个随着

6、系统认识程度的提高以及业务运作阅历的积累，由低到高开展的过程。因此，如何实现“从业务角度去透视技术，从技术角度去回归业务是业内人员所面对的永久命题，能到达业务与技术的“融会贯穿那么是追求的最高境界。为此，本篇将从博大精深的ORACLE EBS系统最根本的运用根底组成元素开场，从业务技术业务，讨论让有些人高深莫测、妄自菲薄的所谓“其背后的东西、深层次的东西究竟是些什么，以便可以最终寻觅到协助 我们登堂入室的钥匙与途径。二、表单与查询Form and Summary企业在手工方式下的业务运作过程中，总有各种各样的用于记录业务数据或管理信息的纸面单据，例如“销售订单、采购订单、入库单、出库单等等。随

7、着业务量的添加，这些纸面单据的数量是如此之多，以致于企业不得不破费大量人力，将每张单据上的重要信息摘要出来例如采购订单上的供应商、物料、数量、价钱、金额、日期等，另外建立一个数据记录的“索引、清单或台账等， 以方便能在需求时对它们进展查询或统计。一个最简单的软件管理系统，就是把上述纸面单据“电子化后放入系统，然后再提供一个在系统里查找这些单据的“查询功能。假设他去研讨一下目前国内的主流ERP产品，他就会发现这些主要用于中低端市场的国内ERP产品，其每个模块中的运用功能实践主要就是“单据新增与单据查询这两项。其单据在系统中的格式和内容与纸面单据是如此近似相像，以致于大多数企业人员学习掌握它们不会

8、觉得有多大困难。在ORACLE EBS的每个模块中，同样也是要用到各种单据Form来录入或保管数据对应于后台数据库中的“表，并为之提供相应的查询功能，但ORACLE中的系统单据曾经不是纸面单据的简单再现。系统的UI界面中可以见到各种“表单据统计约有3000多种，它们不仅不同于纸面单据，相互之间的性质及查询方式差别也能够很大。归纳起来，ORACLE各模块中的“表单按性质与作用大体可分为三大类：第一类是“业务流程类表单，例如“销售订单SO、采购订单PO、制造工单WO、发票INVOICE等等，它们有一个共同的特点是参与中心业务流程的运转，是中心业务流程的一个环节、不可或缺。这一点显然也是和实践的企业

9、业务过程是高度相对应的。作为业务的原始凭据凭证，它们是如此重要，即使是IT系统化之后，大多数企业能够还是要将它们的纸面形状予以保管、归档。 在ORACLE EBS中，“业务流程类表单种类其实很少每个模块普通仅一、两个左右，但每种单据随时间日积月累，业务数据量能够很大。业务流程类表单是系统中最重要的表单，与纸面单据相比，内容更为丰富和复杂，格式也有很大的变化，它充分利用了数据库技术所提供的可包容性、可扩展性以及运用便利性。它来源于业务虚践，但经高度笼统并融入最新科技成就后，其功能与作用又远远高于原始的纸面单据。如图1的PO表单:PO表单是一个典型的“业务流程类表单，它有“表头与表体行两大部分组成

10、，这一点与纸面单据依然类似。但不同的是系统表单的每一个“表体行，还可以拥有属于本人的“二级子表行；而每一个“二级子表行，也可以拥有属于本人的“三级子表行，如此类推。这种表单展现方式，纸面单据是无法实现的，它极大地扩展了单据可以包含的信息容量，具有高度的灵敏性与便利性。在图1中，PO的第一行采购总数量为36，对应到“发运二级子表拆分为数量分别为20与16的两行表示发到两个不同收货地点或同一地点但两个不同发货时间；“发运二级子表的第一行数量为20，对应到“分配三级子表拆分为数量分别是10与10的两行表示对应到两个不同的费用会计科目或费用由两个不同部门分别承当。第二类是“数据来源类表单，例如“OM模

11、块中的价目表、PO模块中的报价单、以及“物料、供应商、客户数据表单等等，它们的共同特点是不参与中心业务流程的构建，但它们为业务流程表单提供可以参考的数据来源，例如采购订单从物料表单取物料相关信息，从供应商表单取供应商信息、从报价单取价钱相关信息等等；这类表单在手工业务方式下大多数都能够也存在，但手工形状下的实践运用与管理能够无法做到很严厉规范；在ORACLE EBS中，“数据来源类表单在每个模块中种类能够很多，每种表单的内容与格式复杂程度，以及单据数量也差别很大。它们虽然并非不可或缺，但它们表达的专业化分工与协作的管理思想，对于企业的业务流程运作效率有艰苦影响。 以下图2所示订单管理/定价模块

12、中的“价目表，就是一个典型的“数据来源类表单，它也可有复杂的构造:第三类是“业务控制类表单，例如“销售的物料可订购性、采购的同意供应商列表、系统参数设定等等，这类表单在手工业务方式下很少或根本不存在。现实上，手工方式下实践也很难运用它们对业务进展有效控制。在ORACLE EBS中，“业务控制类表单在各模块中的种类也比较少，单据数量也很有限，但它们表达的是企业管理的系统控制机制，对于业务管理控制的效率有重要影响。如以下图3所示采购的同意供应商列表控制可向哪些供应商采购，就是一个比较典型的“业务控制类表单，它也同样可有复杂的构造。虽然在ORACLE EBS中，统计后台数据库中所用到的“表Table

13、数量有一万多个，前台UI中可见的表单也形形色色、数量繁多，乍看令人生畏，但在分析归纳划分为以上三大类之后， 事情就会变得简单很多，它使得我们可以把每个模块中种类很有限的“中心的业务流程表单作为学习研讨的“切入点，经过对每种单据内部业务内涵与技术内涵的分析，以及各种单据之间业务逻辑与技术逻辑的研讨，逐渐扩展并掌握系统的其它功能与运用。基于实践任务的需求以及系统设计的简约方便，ORACLE针对上述三种不同类型的表单分别提供了可供选择运用的不同“查询方法，归纳起来也可分为三类：功能查询方式、快捷查询方式、简便查询方式。所谓“功能查询方式，在系统中有“查询功能菜单项例如PO Summary，采购订单汇

14、总，点击此菜单进入时，系统会首先弹出“查找条件输入窗口控件，如以下图4所示采购订单功能查询菜单与查询条件控件：然后根据输入的查询条件，给出查询结果LIST。作为查询功能扩展，系统还在UI界面工具栏进一步提供关联查询如采购订单的上下游单据“采购恳求和“采购发票和细节查询功能，如以下图5所示采购订单功能查询方式的输出结果视图：功能查询方式通常只用于中心“业务流程类单据的查询，查询功能强大。由于业务流程类表单以及部分数据来源类表单的重要性，系统在菜单项中提供了专门的“查询功能。 所谓“快捷查询方式即在翻开单据界面后，只需点击UI界面工具栏内的查询“图标手电筒，查询条件输入方式有两种：一种是无公用的“

15、查询条件选择窗口，仅限于在查找界面的“查找栏输入常用的那些字段即所谓“模糊查询，系统在查找界面直接给出一切符合条件的条目LIST，而详细情况需选定条目后，再进入单据界面查看，如以下图6所示“采购订单在单据界面进展“快捷查询的情况：另一种是在单据界面点击查询图标手电筒后，也会出现“查询条件输入窗口，输入查询条件后，系统也能够会出现一个简单的结果清单LIST界面或视图某些表单查询那么能够没有，经过该LIST视图界面可以再选择翻开相关条目的表单。同时，也可以直接在单据界面按“翻页键Page Down或Page Up，在曾经查询出的不同条目间按顺序直接切换。如图7所示：物料快捷查询方式的查询条件控件与

16、输出结果视图：述两种快捷查询方式，适用于大多数业务数据量大的表单数据的查询。而后一种“快捷查询方式与“功能查询方式有些近似，只是其查询结果的输出视图的相关“功能如上查下查的追溯、汇总与明细的切换等没有“功能查询方式那么强大。但对于大多数“数据来源类表单，由于它们不参与构建中心流程，信息也不如业务流程类表单那样复杂，故“快捷查询方式曾经根本可以满足实践任务需求。如按“功能查询方式为一切表单设计“查询条件控件与查询“输出结果视图象某些国内产品做的那样，那么系统设计任务的复杂性将大大添加，后续系统维护也将非常费事，既不经济也无多大实践意义。 所谓“简便查询方式，即在翻开单据界面后直接把“单据界面的一

17、切字段作为“查找条件输入窗口。要做到这一点，只需在翻开单据界面后，于UI的工具栏“查看中选择“查询规范-输入或按F11键，此时单据界面有关字段即“灰显，允许输入详细查询值，再在“查看中选择“查询规范-运转或按Ctrl+F11，那么单据界面显示查询结果，按“翻页键Page Down或Page Up，在曾经查询出的不同条目间按顺序直接切换。如以下图8所示：物料清单BOM的简便查询方式表示图：这种查询方式既不需求“查询条件控件，也不需求查询结果输出视图，系统设计上非常简单节省，适用于几乎一切表单。要留意的是对于系统中某些数据量很少的表单，那么有能够系统只提供“简便查询作为独一可运用的查询方式。此外，

18、EBS中的某些表单，在WEB下能够还有基于HTML的展现与查询方式。UI与HTML这两种展现与查询方式的优劣，一方面与运用场一切关，另一方面也与运用习惯有关。总之，了解系统中各类表单的运用并熟练掌握各种查询方式，是进一步学习研讨系统的根底，虽然EBS各模块的表单展现与查询方式因不同业务、不同设计者的风格偏好而能够有所不同，但中心本质的东西还是共同一致的。ORACLE EBS 系统运用根底概述三、事务处置Transaction四、并发流程Current Process五、文件夹Folder六、弹性域Flex field七、值集与查找代码Value Set and Lookup Code八、配置文

19、件Profile九、单据编号Document Sequence十、任务流Workflow十一、预警Alert十二、运用开放接口Open Interface and API十三、结语注：网站批量发图有问题，上传后显示不清楚。点击图片翻开后，质量尚可三、事务处置Transaction假设说上述EBS的“表单与查询的系统设计表达的正是“从业务到技术，比较容易了解与掌握，那么，所谓“事务处置那么是表达系统“从技术再到业务的一个典范，相对而言，了解起来要困难很多，缘由是无法直接在手工业务方式下找到相对应的处置方式与过程。以库房接纳采购物料为例，假定公司规定必需严厉按PO来接纳，并且公司为了严厉控制库存程

20、度，接纳必需小批量、多批次，那么库房人员就能够需求针对同一个PO在短时期内开出N多张的“入库单，任务量很大。为了减少任务量、提高效率，库房人员能够会在供应商每次送货时，仅在找出来的PO纸面单据上只简单地做一个数量标识，最后累积起来汇总开一张“入库单。但这种“图省事的做法显然是一种“很不规范的处置方式，虽可以提高任务效率，却会由于容易带来很多其它管理问题而在实践任务中不被允许。ORACLE 系统经过提供一个“事务处置任务界面那么很简单地处理了上述难题。如以下图9所示采购接纳的事务处置任务界面：类似于“收货时直接在PO纸面单据上简单地做数量标识，每次供应商送货来时，库存人员只需在系统中查找出对应的

21、PO，简单地输入送货数量并保管，那么系统会在后台自动生成“事务处置记录(等同于是“入库单)。对于系统来说，这种处置方式技术上实现非常容易，但却大大减少了操作人员的任务量，有效地处理了由于小批量、多批次所带来的效率问题。ORACLE的各业务模块，大量地采用了上述类似的“事务处置系统任务方式，不仅保证了系统高度的数据集成性，而且对于系统各业务环节的流程处置也保证了高度的衔接性与集成性。例如OM系统的发货处置、WIP系统的领料与入库处置等等。系统中所提供的事务处置任务界面，有些能够会以“任务台Workbench来命名之这取决于不同模块系统设计人员的个人偏好。更进一步，系统对于某些“业务流程类表单，例

22、如“销售订单、发票等，还在表单界面直接提供一个名曰“活动Action的按钮Button，该按钮包含丰富的业务处置功能不仅仅是输入数据，以便用户User对表单内容作各种操作处置或获取相关信息。如以下图10所示，销售订单界面的“活动按钮：此外，ORACLE EBS在某些业务流程单据之间，也提供了类似的事务处置任务界面，以协助 用户方便地实现业务单据的转换和业务流程的衔接。如以下图11所示的采购恳求PR到采购订单PO的所谓“自动创建Autocreate功能。对于企业的一个系统用户User事务处置型用户来说，掌握了与本人任务相关的表单、表单查询、事务处置，就根本上掌握了EBS的系统运用，系统就不再难懂

23、难用。EBS中的“事务处置在业务流程表单内部处理了“人与系统的一致问题，在业务流程表单之间处理了“业务与业务、业务与系统的一致问题。从“纯技术的系统实现角度来看，它也没有什么高深莫测的地方。很奇异也很遗憾的是，迄今国内主流ERP产品的系统中，还很少看到这种系统实现方式。曾有一网友经过MSN向笔者发问：“EBS的WIP 事务处置界面能否要手工输入item？看起来这个问题似乎很“幼稚，但对于很多刚开场接触EBS或过去用惯国内产品的人来说，由于不了解或不习惯EBS的“事务处置系统实现方式，会不自觉、想当然地将一切EBS的FORM界面都当成具有“实体作用、通常可以对应纸面单据的“业务表单来对待，才会发

24、出这样的疑问。四、并发流程Current Process从系统实现角度来看，“并发流程或“并发处置是较之“事务处置技术味更浓的一个概念，它也是业务出身、不太懂“技术的人学习掌握EBS系统的难点之一。但实践上，对于今天的计算机系统而言，“并发其实是一个再普通不过的运用，例如我们边在电脑上写文章边听音乐等等。ORACLE 弄得有点学究气，相对于“联机事务或“联机处置方式，并发处置称为“后台事务或“后台处置似乎更好了解一些。以企业的实践业务过程为例，在手工业务方式下，库房接纳了物料并开具“入库单后，库房人员后续必需还要做的一项任务是：“手工将入库单上的物料接纳信息逐份“过账到“库存物料信息台账上去，

25、以更新库存物料的余额数量。在EBS系统中，这项枯燥、乏味的任务就完全由系统代劳了，系统经过后台运转的一个名为“接纳事务处置处置器的并发程序，联机立刻或成批周期进展处置，在不影响用户做其它任务的同时，高度准确地完成着本来需求人工去做的“过账登记义务，并且手工方式下过账之后为检查错漏而需经常进展的“对账任务也变得根本就不再需求。“并发处置是EBS系统不可或缺的一个重要组成部分，上述“物料接纳的并发处置只是一个很简单的运用。在EBS中，“并发按处置的对象主要可分为两类：一类是“流程事务，一类是“报表事务。系统一致以“提交恳求Request的方式提供人机交互。如以下图12所示“查询或提交恳求：对于每一

26、个并发“恳求，系统都可以允许输入相关参数，并方案其是按某一周期运转，还是立刻或预定在未来某一时辰运转。系统预置了大量的为业务流程效力的“流程事务类后台事务处置程序，同时还提供了部分可供企业参考的“报表事务类输出恳求。用户运用系统提供的开发工具，也可以很容易地自定义某些“个性化的后台程序或报表输出，其运转管理和运用方式与系统预置的并发程序几乎完全一样。“并发处置相对于用户来说，实践上是属于在系统后台运转的相关任务，刚刚开场接触的人能够会对之觉得陌生或运用不随手，缘由主要是手工业务或低档的管理软件根本没有这种任务处置方式。这就好比相对于交通主要还是靠骑车或步行的小城镇，今天对于生活在现代化大城市的

27、人们来说，往来穿越的地铁、周而复始的公交、招手即停的出租车曾经成为全部生活不可或缺的一部分，它们就像城市的“血管脉动一样，奔腾不息，维持着城市生命的运转，活力勃勃。EBS的“并发处置所承当的角色或所起的作用正与之根本类似。EBS并发处置的另一项重要特性是其“系统级的可方案、可管理、可控制特性，系统经过定义“并发管理器、“恳求集等功能运用，对一切需求在后台运转的并发程序进展管理调度，以平衡系统负载，保证系统有高的运用性能。如以下图13所示，定义“并发管理器包括运转规那么、任务班次等等。这类似于城市里的交通调度与控制关于“流程事务类的并发恳求，由于涉及到系统各业务模块的详细功能运用问题，这里不便多

28、讲。以下主要来谈一谈“报表事务类的并发恳求问题。有网友曾埋怨说，“ORACLE的报表功能不好用，出一个简单的报表都要到后台去提交一个恳求，输出的是一个文本，太费事。系统提供的规范报表，内容不能满足企业要求，不符合国人的运用习惯。这种说法能够是由于受某些国内产品的影响而产生的误解。目前国内的主流ERP系统，对于“报表根本上采取的是类似“查询的实现方式。这种“查询式报表虽然方便了用户运用，但却惹出了无穷的费事。首先，报表是一种极端“个性化的东西，不同的企业由于管理层次不一样，关注的管理重点也不同，针对同样的问题所要求的报表也会不同。即使同一个企业在不同的开展阶段，所要求的报表内容也不会一样，因此即

29、使曾经运用ERP假设干年的企业，不断地开发新的管理报表，也是很正常的事情。假设ERP系统将报表功能“显式化，在系统规范功能中提供查询条件控件及输出结果视图，那么意味着系统提供的这个所谓报表功能必需符合一切企业的运用要求，而实践这是不能够实现的。在这种情况下，企业就会理所当然地以为这是ERP厂商的责任，厂商必需担任处理。目前许多国内ERP厂商产品研发的一项重要内容就是穷于应付为企业开发各种查询式管理报表，这几乎是等于自掘火坑，陷进去无法自拔，其次，查询式报表假设内容复杂、耗用系统资源比较高，那么用户随意自在运用， 而IT系统维护人员对“联机式查询无法进展有效管理、干涉，将能够严重影响系统整体性能

30、，导致其他用户无法进展正常任务。从这个角度来看，目前国内的主流ERP产品实践上还没有真正系统意义上的“报表功能，只需不加节制、扩展化了的“查询功能。系统如此处置极不明智。ORACLE 将“报表功能以并发恳求的方式放到后台去处置，不仅有效地处理了“报表的个性化问题，分清了ERP厂商与企业的责任界面，而且也为企业IT系统维护人员提供了系统可管理、可干涉的便利。这实践上正是ORACLE系统的灵敏性与功能强大之处SAP也类似。有网友针对国内某些厂商声称本人的ERP是“高端产品时，质疑“连并发都没有，能算高端吗？实践上是说到了关键。一个连“电梯都没有的高楼怎能算得上是现代化的大厦呢！ORACLE系统大量

31、运用后台“并发处置程序，实现了系统用户的流程操作在“空间与时间上的分别，免去了操作人员的无效等待时间。操作人员提交的并发恳求在后台运转的同时，并不影响其处置其它系统事务，这样可以大大提高用户的任务效率以及运用的方便性。“并发之于ORACLE EBS系统好比人体内的“心脏一样重要，它是系统实现高度的数据集成与流程集成的中心工具，是企业依赖计算机系统实现业务运作与管理控制自动化的一个技术表达。五、文件夹Folder 这又是一个ORACLE弄得有点学究气的概念能够也有中文翻译不到位的缘由。所谓“文件夹Folder功能，简单来说就是稍有点IT系统运用阅历的人都明白的“用户自定义查询输出界面视图功能。系

32、统可以提供的查询条件控件或查询输出结果视图的字段是如此之多，其中有很多能够并不是用户希望显示出来的，每一个系统用户User可以根据个人的任务需求或偏好，运用文件夹功能自在地定义本人可见的UI界面。ORACLE 系统为几乎一切重要的表单、查询条件控件及查询结果输出视图都提供了文件夹功能，这也是ORACLE系统灵敏性、易用性、方便性之所在。如以下图14所示采购PR的查询：六、弹性域Flexfield所谓“弹性域技术是人们每当提及ORACLE 产品技术的先进性时总会首先想到的一个东西，也是很多初学者尤其是“业务出身的人开场接触时能够会感到有点“发怵的东西，缘由之一是它的技术味比较浓。但实践上，假设从

33、运用的角度去了解，它也并无多少奥秘之处。前面我们曾经讲到“表单是组成EBS系统的最重要根本元素之一，每个表单都由“表头与表体行组成。系统在UI界面中所展现的是表单的“规范显示，虽然这个“规范显示能够曾经包含了适宜各行各业所运用的那些常用信息字段Segment，但对于不同企业来说，总能够会出现需求添加一些本企业特殊需求的信息字段的情况，这从系统角度通常称为“自定义表单字段。EBS的所谓“弹性域技术实践就是为理处理这一常见的系统运用问题而应运而生，对于初学者来说，把它简单地了解为“自定义表单字段就容易多了。如以下图15与图16所示的采购恳求PR表单，在表头部分“规范显示的UI界面角落中有一个“方框

34、“【 】，在表体行部分的末端也有一个“方框“【 】。系统用户在需求输入有关特殊信息时点击“方框，系统便会分别弹出一个包含假设干个自定义信息行相当于为表单扩展了假设干列的字段的界面框，以供用户输入某些特殊信息。 图15所示采购恳求PR表头的“弹性域方框与弹出界面。用户可在其中输入关于该PR的某些自定义补充信息，如“恳求部门、恳求用途等等。图16所示采购恳求PR表体行的“弹性域方框与弹出界面。用户可在其中输入关于该PR行的某些自定义补充信息，如关于所申购物料的“长宽高、颜色等等。要留意的是，上述“自定义表单字段是“系统级而非“用户级的，也就是说只需系统管理员才干做相关设置，而普通用户只能在实践任务

35、中运用。EBS中所运用到的“弹性域分为两类：一类是所谓“键弹性域Key Flexfield，一类是所谓“阐明性弹性域Descriptive Flexfield。而上述图15与图16采购恳求PR中的“弹性域就是典型的“阐明性弹性域的范例。系统中几乎一切的重要表单尤其是业务流程类表单都具有这种“自定义功能的阐明性弹性域，系统阐明性弹性域总数有二、三千之多。称之为“阐明性Descriptive取其对规范表单字段作补充阐明之意。用户在阐明性弹性域中输入的字段信息，通常只能作为统计分析、出报表运用，不参与系统业务流程的构建，系统运用程序不对之在表单之间作跟踪、追溯。如以下图17所示是采购恳求PR表头“阐

36、明性弹性域的系统定义界面：系统所谓“键弹性域的情况较之“阐明性弹性域就复杂、严厉得多，缘由是它们参与业务流程的构建，系统的运用程序要对之进展跟踪、追溯，其作用当然非常“关键Key，故数量也比较少，在整个EBS系统中总数不过约35个。其中用得最多的例如“物料类别弹性域、“会计科目弹性域等等。与“阐明性弹性域属于表单的用户“补充字段不同的是，“键弹性域本身就属于表单的系统规范字段，这个表单规范字段用户输入的不是简单的一个信息，而是具有某种可在系统层面“自定义构造的一组信息。 如以下图18所示采购恳求PR表单界面中“物料类别字段，用户输入时将弹出系统曾经定义的“物料类别键弹性域界面，以供用户选择输入

37、详细信息：如以下图19所示是系统层面定义“键弹性域的界面。全部35个键弹性域主要集中在库存、总账、资产、人力资源等中心业务模块中定义，其它模块只是运用时调用。键弹性域由于其系统位置与重要性，其定义方式与内容也要比阐明性弹性域来得复杂。对于每一个“键弹性域，系统允许定义假设干个不同构造的字段组合，以运用在系统中的不同场所例如不同组织或帐套等等。如以下图20所示，表达了“会计科目弹性域可以有假设干不同构造代码的情况，图中“Vision China的5段式构造，可以和其它国家或地域的完全不同。ORACLE的弹性域运用技术作为系统最重要的根底元素之一，历经多年开展，其运用已远非上述所例举的“表单字段信

38、息那么简单，它现实上曾经开展成为一种重要的方法论。系统基于键弹性域的某些重要技术特性，逐渐开展出了诸多运用灵敏、功能强大的运用实现方式。相关讨论必需结合详细的系统运用来进展，这里不再赘述。ORACLE EBS 系统运用根底概述七、值集与查找代码Value Set and Lookup Code八、配置文件Profile九、单据编号Document Sequence十、任务流Workflow十一、预警Alert十二、运用开放接口Open Interface and API十三、结语注：网站批量发图有问题，上传后显示不清楚。点击图片翻开后，质量尚可七、值集与查找代码Value Set and Lo

39、okup Code日常任务中，用户在表单的字段包括弹性域字段中输入数据的方式无外乎两种：一种是直接手工键入，例如订单中的数量数值或文字阐明字符等等；另一种就是所谓“LOVList of Value，用户只能从某个预先定义的“来源单据做选择输入用户如手工输入，系统能够自动针对来源单据进展校验以确定输入值能否允许。表单字段的“LOV输入实践占了系统输入操作的大部分情况，之所以如此的重要缘由是业务虚践与系统实现的“规范化需求。例如“人力资源管理部这个官方正式称号，在人们的日常任务与交流中，能够被简化为“人力资源部、人事部、HR等等，大家都知道它们是一回事，普通不会引起误解。但对于系统来说就完全不同了

40、，细微的差别在系统中都是两个不同的对象，所以说LOV实践上也是系统实现“数据共享与集成的根底。表单字段LOV的来源单据值种类，有些能够比较复杂，例如象“物料、供应商、客户等等，这些字段的值被从来源单据带过来时，系统能够还会带过来其它假设干相关重要信息到表单的其它相关字段上去。而有些能够就比较简单，例如属于通用根底数据范畴的“单位UOM、币别Currency以及日期Date等。还有些虽然也比较简单，但通常需求用户预先做好定义，例如企业的“部门称号列表等，这些LOV在系统中通常称之为“值集Value Set。在系统中定义一个完好的“值集需求两个相互独立又相互关联的阶段，首先是定义“值集名，系统中可

41、以定义假设干个不同用途的值集名，对于每一个值集名，在定义界面可以对其相关属性如“验证类型：无、独立、从属、表等做出相应规定，以使其符合实践任务的需求。如图21所示为“部门称号的“值集名定义或查找界面：其次，就是为曾经定义好的“值集名赋予详细的值验证类型为“无的除外，以组成系统可用的LOV。如以下图22所示，其中，有些值之间还可以根据需求定义构成某种“层次构造，“父子值之间具有“汇总与被汇总的关系。验证类型为“从属或“表的值集定义比较特殊，前者需先定义所从属的“独立值集。后者那么是将某个系统内的“运用表作为本人的LOV来源如“定义供应商表单维护的供应商称号表，值集定义时，需规定运用哪些表，并定义

42、 WHERE 子句来限制值集要运用的值。运用值集LOV的表单字段的值几乎都有一个共同的特性是，普通不直接参与业务流程的构建，或不直接影响业务流程的运转。然而系统表单的某些字段是需求承当“流程构建任务的，这些表单字段有些需求手工输入，有些那么能够是系统流程运转时自动赋值或在不同流程阶段自动改写例如，表单形状“未完成、已保管、已同意、已回绝等等，有些值在表单中通常“可见，有些那么能够是在特殊情况下才可见。 上述这些表单的特殊字段域的LOV，普通是由系统在所谓“查找代码Lookup Code功能中定义的。ORACLE在系统层面于一个一致的界面Form中按模块、按援用字段进展全部Lookup Code

43、定义。如图23所示库存相关表单中运用到的物料的“需求类型定义：Lookup Code系统的定义分为三种情况访问级别，一种是“系统级，属于ORACLE预定义且不允许用户添加。这种情况下的“代码值Code根本都属于系统的运用程序中需求援用到的，影响或决议着系统业务流程的运转；二种是“用户级，属于非系统预定义而由用户本人添加，这种情况下的代码值普通不被运用程序所援用，其作用与前述值集LOV值大体一样；三种是“可扩展级，属于ORACLE预定义但允许用户添加。这种情况下的系统预定义值与“系统级的定义值作用根本一样，而用户添加的部分，其作用那么与“用户级根本一样。八、配置文件ProfileORACLE的所

44、谓“配置文件本质上就是人们曾经耳熟能详的所谓系统“参数不明白当初的中文翻译为何弄得如此奇异。ORACLE中的配置文件或参数涉及两个过程：一是配置文件的本身定义Definition；二是配置文件的运用设置Setup。ORACLE系统的预定义配置文件数量虽达七、八千之多，但这些配置文件对于用户来说都是透明可见的，并不奥秘。系统提供“配置文件定义界面，供用户对配置文件的某些属性甚至运用程序进展调整或修正，用户也可以根据本人的需求自定义新的配置文件。如以下图24所示配置文件的定义：值得指出的是，系统预定义的“配置文件名有一定命名规那么适用于大多数配置文件，少数例外，例如“MRP：忽略替代BOM/工艺道

45、路，前面的MRP是模块代码，代表属于哪个运用模块，后面的部分那么是代表详细用途。这种“命名规那么使我们很容易查找到针对不同模块的相关参数。虽然系统预定义配置文件或参数的数量是如此之多，令人生畏，但归纳起来，可以发现按用途大致划分为三类：一类是真正起到控制业务流程运作或事务处置方式的部分，这些参数就如人们通常所津津乐道的所谓“流程开关；二类实践并不直接控制流程运作或事务处置，只是起到一个向表单上默许某些值的作用这些默许过去的值，有些参与流程构建，有些仅起参考作用。用户在表单上还是可以修正的；三类是起到某些特殊控制造用，例如改动系统的某些任务方式、控制UI界面的颜色字体等等，通常与详细业务关系不大

46、。一切参数中前两类占了绝大部分数量其中第一类又占主要部分，第三类数量很少。而系统运用的难点与重点那么是“第一类、属于“流程开关那部分参数。 ORACLE系统的配置文件的“设置Setup非常方便灵敏，组合起来的运用功能非常强大。系统的配置文件设置具有“构造层次性，对于某一个详细的配置文件，系统允许最多可以在6个层级进展设置并发扬作用：地点层系统安装、运用产品模块、责任自定义的责任、效力器、组织包括OU/INV等、用户自定义的用户。详细能在上述6个层级中的哪些层级“可见、可设置，取决于这些配置文件的原始定义的相关属性。并且实践运用程序访问时，将按照从“地点逐渐到“用户由低到高的“优先级顺序发扬作用

47、。如以下图25所示配置文件的设置：最高优先级的“用户层假设留空不赋值，那么系统将默许上一层级责任层的值作为本人的值。逐级前移直至最低优先级的“地点层，通常系统在安装后于“地点层有初始化的默许值。虽然看起来配置文件数量有七八千，设置任务量宏大，但实践系统实施时，对于大部分企业来说，好在运用系统安装时的默许初始值就能根本符合要求，故也并不非常困难可怕。企业在实践任务过程中遇到问题时，如希望系统能实现某种功能或希望系统流程能按某种方式运转等等情况，那么通常首先应该基于系统配置文件的不同设置来寻求适宜的处理方案。此外，系统对于配置文件提供了“系统与“用户两种“平安性权限的控制功能，前者普通由系统维护人

48、员如管理员进展控制，后者普通用户就直接可以作设置修正，例如“UI界面的颜色、字体等。九、单据编号Document Sequence 与手工业务方式下做单据一样，系统中的一切业务流程类表单以及大部分的数据来源类表单，由于业务数据量宏大，当然也需求进展编号管理。ORACLE为此提供了单据的编号控制功能：自动编号、人工编号或无间隙人工编号必需延续不断号。单据编号详细包括三个既相互独立又相互关联的三个步骤：一是定义“单据序列发生器；二是定义详细的“单据类别，三是将“单据序列分配给“单据类别。如图26所示为定义“单据序列发生器如图27所示是定义详细的“单据类别如图28所示，是将单据序列发生器分配给单据类

49、别，使两者关联值得指出的是，现实上系统中的某些业务流程表单例如销售订单，系统允许其自定义假设干数量的“单据类别例如销售订单中的“订单类型或“事务处置类型，这些自定义的“单据类别可以拥有被分配各自不同的单据序列号发生器相当于运用时系统对它们各自独立编号，也可以共同拥有同一个单据单据序列号发生器相当于运用时系统对它们混合共同编号，这为单据编号的实践运用与管理提供了很大的灵敏性与方便性。另外要留意的是，系统中的某些单据如采购恳求、采购订单以及供应商等也可以有其专门的编号管理机制，不能一概而论。十、任务流Workflow在企业的实践管理任务中，一个员工填写好一份“费用报销单后，后续能够还需求经过多个环

50、节例如直接主管、上级主管、财务主管的审批，才能够到达会计入账、出纳付款手中，以完成整个任务过程。把这个任务过程“电子化后放入系统，就构成一个所谓的“任务流过程。通常这个报销单“任务流需求经过哪些环节，是系统需求预先设置好的，并且能够不同的费用类别所需经过的审批环节也是不同的。作为流程的参与者，例如“提交人、审批人等，可以查询、监控单据的任务流处置过程，系统也可以在流程环节挪动过程中，向下一环节的处置人发送提示通知如邮件等。单据的“审批流实践是一个很简单、很直观的“任务流运用。推而广之到系统中其它业务流程类表单的事务处置过程，所谓系统的“任务流技术运用就是：根据不同的业务单据类别，事先定义好需求

51、经过的不同业务处置环节，单据在做事务处置时，按规定顺序在相关环节间挪动。用户可监控，即普通用户可以查看任务流的处置过程形状；系统可管理，即系统任务流管理员，必要时可以对单据的任务流过程进展干涉，例如跳过某些环节、改动参与人等等。ORACLE系统中心业务模块OM中关于销售订单的处置，就是一个典型的“任务流技术运用范例。系统根据实践业务处置的需求，先定义好不同的销售订单“行类型。例如“Ship only，表示发给客户的这个货物免费、不需开票例如由于货物质量问题而补发等缘由；“Service，表示这是向客户提供的无形效力，无需发货，但需根据订单行开票向客户收费等等。再给这些订单“行类型分配一个适宜的

52、系统曾经定义好的“行任务流。如图29所示OM销售订单“行类型行流分配定义：上述系统用于分配给“行类型的行任务流，ORACLE提供了预定义的多种不同类别供用户在设置系统时做选择。更进一步，ORACLE还提供“Workflow Builder软件包工具这个软件可以到ORACLE官网上自在下载运用，以便用户对于系统一切预定义的流程进展复制修正，或自定义符合运用要求的特殊流程。对于详细的每一个销售订单，同一订单中能够包含不同行类型的订单行，这些订单行将循着各自的“行任务流而进展事务处置。系统在表单界面的工具栏提供“任务流形状查询的功能，用户可以随时对订单中的每一个订单行的系统处置过程实施监控、查询。如

53、以下图30所示销售订单行的任务流监控功能运用界面：在上图中点击“任务流形状功能，那么系统将翻开属于订单行1.1的任务流WEB查询页面。系统提供“活动历史记录与“形状图两种主要查询方式，分别如以下图31与图32所示。图31表示订单行的活动历史记录，系统从用户输入订单开场，对于后续几乎每一步事务处置操作都做了记录。图32所示以直观图形方式显示的订单行流程形状。需求指出的是，并非一切业务流程类表单都要采用类似销售订单的“任务流处置方式，例如“采购订单的处置等。系统运用模块能否运用、如何运用“任务流技术，与详细的业务虚践以及采用之的优缺陷取舍有很大关系，不能一概而论。从系统开发设计的角度来看，虽然“任

54、务流于技术层面并不难掌握，但要与业务虚践实现很好的结合那么并非易事。目前国内主流产品根本都声称具有“任务流技术，但真正在系统中心业务流程中用得比较好的并不多见，大多只是在“单据审批或非中心的事务处置型业务诸如“费用报销等领域中有所运用。 此外，在EBS中有关“单据审批的任务流运用只是“单据审批的系统实现方式之一。为满足企业的复杂业务环境的需求，结合任务流技术，系统还专门提供了一个审批功能更为强大且相对独立的引擎模块“审批管理AME作为“外围产品供企业选择运用。ORACLE EBS 系统运用根底概述十一、预警Alert十二、运用开放接口Open Interface and API十三、结语注：网

55、站批量发图有问题，上传后显示不清楚。点击图片翻开后，质量尚可十一、预警Alert 今天在企业的办公场所或酒店的房间等很多地方，我们都可以见到天花板上装有“烟感报警器以及“自动喷淋器，国家对建筑物的消防平安有明确的法律法规，因此这些“报警或灭火安装几乎已成了建筑物的规范配置。与之类似，预警平台对于今天的ERP系统来说也几乎是一个规范配备，无论是从系统实现角度还是从业务运用角度来看，它都不是很复杂，比较容易掌握。 ORACLE 的系统预警分两种方式，一是“事件预警，二是“周期预警。两者的根本任务方式均是运用SQL Select语句基于对数据库中的相关值作出条件断定，以决议能否执行某种活动发出信息，

56、执行并发程序、执行操作系统程序、执行SQL语句。更进一步，对于“发出信息类预警，系统在收到对此信息的符合规定格式的“回复后，还可以据此自动执行相关活动并完成相关事务处置。所谓“事件预警，即当用户在相关数据表中“插入或“更新某些值时，系统自动启动已定义的“SQL Select语句的检查，已确定能否需求发出预警信息或执行某种活动，如以下图33所示的一个事件预警定义：在采购管理系统模块中，当出现一个宏大数量的恳求行数量被输入时，系统需求向相关责任人发出预警通知以提示诸如做好资源预备等。所谓“周期预警，即系统按照事先定义好的周期间隔或频率，自动启动已定义的“SQL Select语句针对数据库中表的某些

57、值作检查，已确定能否需求发出预警信息或执行某种活动，如以下图34所示的一个周期预警定义：在采购管理系统模块中，系统按每两个任务日的间隔频率对一切“一揽子采购协议BPA的到期情况进展检查，并将需求关注的检查结果例如某些BPA将在一周之类过期通知到相关责任人。十二、运用开放接口Open Interface and API 任何ERP系统都无法做到在任何情况下都能满足企业实践运用的各种要求，企业有时能够需求从其它来源向系统中批量输入数据，如从物料的Excel电子数据表格向EBS的INV系统导入Item信息等等，或者需求与其它第三方运用系统建立业务数据的交换机制，如从公用的“费用报销或发票申付管理系统

58、向EBS的AP系统导入事务处置数据并将事务处置执行结果反响回来源系统等等。实际上，运用相关数据库工具可以向数据库的数据表中直接批量写入数据，但这样做无法对写入的数据进展正确性、合规性校验，无法保证写入数据的质量以及对存在问题进展有效管理。为此，ORACLE提供了接口表Interface Table作为“中间表过渡，并在此根底上，根据某些业务需求提供业务视图Business View，以便对导入的数据进展修正、更正、重新导入等等管理。如以下图35所示“Open Interface Diagram：更进一步，ORACLE将某些数据的导入导出功能进展封装，成为一个运用程序可以调用的接口API，以实如

59、今各模块之间以及内部模块与外部系统之间的数据与流程集成。如以下图36所示“Open Application Programmatic InterfaceAPIDiagram：放接口API的根本任务方式分为两个阶段：一是先未来源数据装入Load接口表。假设是在两个运用系统之间，这通常是由公用的装入程序完成，例如EBS内部采购恳求要转成内部销售订单，需先运转“创建内部销售订单流程，以便将内部采购恳求发送并插入订单管理系统的接口表。假设是从某些电子表格如EXCEL等导入，那么需求先运用专门的SQL*Load工具将数据格式转换后直接插入相关接口表，例如要经过物料的EXCEL数据表直接批量装入Item数据，必需先经过SQL*Load工具如DataLoad等未来源数据插入Item数据接口表。在将数据插入接口表的过程中能否对数据进展校验或是在将接口表数据导入正是表时再校验，取决于系统各运用模块的不同设计；二是系统将存在于接口表中的数据导入正式的业务数据表，如EBS订单管理模块