EBS ：系统功能的应用基础

原文链接：https://www.modb.pro/db/78616

2.1引言

ORACLE EBS 作为一个有150多个业务应用模块、高度集成的企业管理软件系统，它是现代计算机技术与企业管理实践高度融合的产物。相比较于市场上某些“好学易懂”的ERP产品，==ORACLE EBS不是模仿企业手工业务过程的“电算化”简单再现==，或许正是让很多人感到其“难懂难学”的根本原因所在。 对于初学者来说，了解并掌握ORACLE 系统的基本组成“元素”与“构件”，是进一步学习系统功能的前提与基础。这些基本的“元素与构件”虽然可能有着复杂、抽象的外表，但透过现象看本质，它们仍然是来自于对具体企业管理实践的总结与归纳。“从实践中来，再到实践中去”，或曰“从业务透视技术，再从技术回归业务”，将是我们学习ORACLE ERP系统并掌握其精髓的重要方法论。

2.2表单（Form ）

企业在手工模式下的业务运作过程中，总有各种各样的用于记录业务数据或管理信息的纸面单据，例如“销售订单、采购订单、入库单、出库单”等等。随着业务量的增加，这些纸面单据的数量是如此之多，以致于企业不得不花费大量人力，将每张单据上的重要信息摘要出来（例如采购订单上的供应商、物料、数量、价格、金额、日期等），另外建立一个数据记录的“索引、清单或台账”等， 以方便能在需要时对它们进行查询或统计。 一个最简单的软件管理系统，就是把上述纸面单据“电子化”后放入系统，然后再提供一个在系统里查找这些单据的“查询”功能。如果研究一下目前国内众多“电算化”级别的ERP产品，就会发现这些ERP产品其每个模块中的应用功能，实际主要就是“单据新增与单据查询”这两项。其单据在系统中的格式和内容与纸面单据是如此近似相像，以致于大多数企业人员学习掌握它们不会感觉有多大困难。 在ORACLE EBS的每个模块中，同样也是要用到各种单据（Form）来录入或保存数据（对应于后台数据库中的“表”），并为之提供相应的查询功能，但ORACLE中的系统单据已经不是纸面单据的简单再现。系统的UI界面中可以见到各种“表单”（据统计约有3000多种），它们不仅不同于纸面单据，相互之间的性质及查询方式差别也可能很大。归纳起来，ORACLE各模块中的“表单”按性质与作用大体可分为“==业务流程、数据来源、业务控制==”三大类。

2.2.1业务流程类表单

例如“销售订单SO、采购订单PO、制造工单WO、发票INVOICE”等等，它们有一个共同的特点是==参与核心业务流程的运转，是核心业务流程的一个环节、不可或缺==。这一点显然也是和实际的企业业务过程是高度相对应的。作为业务的原始凭据凭证，它们是如此重要，即使是IT系统化之后，大多数企业可能还是要将它们的纸面形态予以保存、归档。 在ORACLE EBS中，“业务流程”类表单种类其实很少（每个模块一般仅一、两个左右），但每种单据随时间日积月累，业务数据量可能很大。业务流程类表单是系统中最重要的表单，与纸面单据相比，内容更为丰富和复杂，格式也有很大的变化，它充分利用了数据库技术所提供的可容纳性、可扩展性以及使用便利性。它来源于业务实践，但经高度抽象并融入最新科技成就后，其功能与作用又远远高于原始的纸面单据。如图 2‑1所示的PO表单。 图 2‑1 PO 表单 PO表单是一个典型的“业务流程”类表单，它有“表头与表体行”两大部分组成，这一点与纸面单据仍然类似。但不同的是系统表单的每一个“表体行”，还可以拥有属于自己的“二级子表行”；而每一个“二级子表行”，也可以拥有属于自己的“三级子表行”，如此类推。这种表单展现方式，纸面单据是无法实现的，但对于关系型数据库技术来说则并不复杂，它极大地扩充了单据可以包含的信息容量，具有高度的灵活性与便利性。 在图2-1中，PO的第一行采购总数量为36，对应到“发运”二级子表可拆分为数量分别为20与16的两行，表示需发运到两个不同收货地点，或同一收货地点但两个不同发货时间；对于“发运”二级子表的第一行数量20，对应到“分配”三级子表可拆分为数量分别是10与10的两行，表示需对应到两个不同的费用会计科目，或费用需由两个不同部门分别承担。

2.2.2数据来源类表单

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

2.2.3业务控制类表单

例如“销售的物料可订购性、采购的批准供应商列表、系统参数设定”等等，这类表单在手工业务模式下很少或根本不存在。事实上，手工方式下实际也很难使用它们对业务进行有效控制。 在ORACLE EBS中，“业务控制”类表单在各模块中的种类也比较少，单据数量也很有限，但它们==体现的是企业管理的系统控制机制，对于业务管理控制的效率有重要影响==。 如图 2‑3所示采购的“批准供应商列表”（控制可向哪些供应商采购），就是一个比较典型的“业务控制类”表单，它也同样可有复杂的结构。 图 2‑3 批准的供应商列表（ASL） 尽管在ORACLE EBS中，统计后台数据库中所用到的“表”（Table）数量有==一万多个==，前台UI中可见的表单也形形色色、数量繁多，乍看令人生畏，但在分析归纳划分为以上三大类之后， 事情就会变得简单很多，它使得我们可以把每个模块中种类很有限的“核心的业务流程表单”作为学习研究的“切入点”，通过对每种单据内部业务内涵与技术内涵的分析，以及各种单据之间业务逻辑与技术逻辑的研究，逐步扩展并掌握系统的其它功能与应用。

2.3查询（Summary）

基于实际工作的需要以及系统设计的简洁方便，ORACLE针对上述三种不同类型的表单分别提供了可供选择使用的不同“查询”方法，归纳起来也可分为三类：==功能查询方式、快捷查询方式、简便查询方式==。

2.3.1功能查询方式

所谓“功能查询”方式，是指在系统中有相关“查询”功能菜单项可用，例如“采购订单汇总”（PO Summary）。点击相关“查询”菜单功能进入时，系统会首先弹出“查找条件”输入窗口（控件），如图 2‑4所示“采购订单功能查询菜单与查询条件控件”。 图 2‑4 “采购订单汇总”菜单功能查询 然后根据用户输入的查询条件，系统给出查询结果列表。作为查询功能扩展，系统还可在UI界面工具栏进一步提供“关联”查询，如采购订单的上下游单据“采购申请”和“采购发票”，及其相关细节的关联查询功能。如图 2‑5所示采购订单功能查询方式的输出结果视图。 表单的菜单功能查询方式一般查询功能都比较强大，可以进行复杂的查询条件组合，并给出信息丰富的查询结果，但系统设计、使用也比较复杂，故通常只应用于数量较少但地位重要的核心“业务流程”类表单，以及部分比较重要或特殊的数据来源类表单数据的查询。 图 2‑5 采购订单菜单功能查询结果视图

2.3.2快捷查询方式

所谓“快捷查询”方式，即是指在打开单据界面后，只需点击UI界面工具栏内的查询“图标”（手电筒），再输入查询条件。查询条件输入方式有两种。一种方式是无专用的“查询条件”选择窗口（即所谓“模糊查询”），仅限于在查找界面的“查找栏”输入“最常用”字段（可逐层输入以缩小搜索范围），系统在查找界面直接给出所有符合条件的条目列表，而详细情况需选定条目后，再进入单据界面查看，如图 2‑6所示“采购订单”在单据界面进行“快捷查询”的情况。 图 2‑6 采购订单的快捷查询 另一种方式则是在单据界面点击查询图标（手电筒）后，也会出现“查询条件”输入窗口，输入查询条件后，系统也可能会出现一个简单的结果清单列表界面或视图（某些表单查询则可能没有），通过该列表视图界面可以再选择打开相关条目的表单。同时，也可以直接在单据界面按“翻页”键（Page Down或Page Up），在已经查询出的不同条目间按顺序直接切换。如图 2‑7所示“物料快捷查询方式的查询条件控件与输出结果视图”。 图 2‑7 物料的快捷查询 上述两种快捷查询方式，适用于大多数业务数据量大的表单数据的查询，而后一种“快捷查询”方式与“功能查询”方式有些近似，只是其查询结果的输出视图的相关“功能”（如上查下查的追溯、汇总与明细的切换等）没有“功能查询”方式那么强大。但对于大多数“数据来源”类表单，由于它们不参与构建核心流程，信息也不如业务流程类表单那样复杂，故“快捷查询”方式已经基本能够满足实际工作需要。如按“功能查询”方式为所有表单设计“查询条件控件”与查询“输出结果视图”，则系统设计工作的复杂性将大大增加，后续系统维护也将十分麻烦，既不经济也无多大实际意义。

2.3.3简便查询方式

所谓“简便查询”方式，即是指在打开单据界面后直接把“单据”界面的所有字段作为“查找条件输入窗口”。要做到这一点，只需在打开单据界面后，于UI的工具栏“查看”中选择“查询标准-输入”（或按F11键），此时单据界面有关字段即“灰显”，允许输入具体查询值；再在“查看”中选择“查询标准-运行”（或按Ctrl+F11），则单据界面显示查询结果，按“翻页”键（Page Down或Page Up），在已经查询出的不同条目间按顺序直接切换。如图 2‑8示“物料清单BOM的简便查询”。 图 2‑8 物料清单的简便查询 这种查询方式既不需要“查询条件”控件，也不需要查询结果输出视图，系统设计上十分简单节省，适用于几乎所有类型的表单查询。要注意的是，对于系统中某些数据量很少的表单，则有可能系统只提供“简便查询”作为唯一可使用的查询方式。 此外，EBS中的某些表单，在WEB下可能还有基于HTML的展现与查询方式。UI与HTML这两种展现与查询方式的优劣，一方面与使用场合有关，另一方面也与使用习惯有关。总之，了解系统中各类表单的使用并熟练掌握各种查询方式，是进一步学习研究系统的基础，尽管EBS各模块的表单展现与查询方式因不同业务、不同设计者的风格偏好而可能有所不同，但核心本质的东西还是共同一致的。

2.4事务处理（Transaction）

如果说上述EBS的“表单与查询”的系统功能设计体现的正是“从业务到技术”，比较容易理解与掌握，那么，所谓“事务处理”则是体现系统“从技术回到业务”的一个典范，相对而言，理解起来要困难很多，原因是无法直接在手工业务模式下找到相对应的处理方式与过程。在EBS系统中，所谓的“事务处理”概括起来可大致分为三种主要类型：==完成任务类事务处理、数据维护类事务处理、单据转换类事务处理==。它们一般都有一个共同的特点，即均围绕作为系统数据核心载体的“业务流程类”单据实体进行，通过用户的有关系统功能操作活动，衍生出或附加上相关的新数据。

2.4.1完成任务类事务处理

所谓“完成任务类事务处理”，是==指用户针对某类型的一个或多个“业务流程单据”数据，基于实际的有关工作任务的执行或完成情况，生成某些重要的相关工作记录==。实际工作中，完成任务类事务处理，通常与“物料”的实际处理过程相关。以库房接收采购到货的物料为例，假定公司规定必须严格按PO来接收，并且公司为了严格控制库存水平，接收必须小批量、多批次，则库房人员就可能需要针对同一个PO在短时期内开出N多张的“入库单”，工作量很大。为了减少工作量、提高效率，库房人员可能会在供应商每次送货时，仅在找出来的PO纸面单据上只简单地做一个数量标识，最后累积起来汇总开一张“入库单”。但这种“图省事”的做法显然是一种“很不规范”的处理方式，虽可以提高工作效率，却会因为容易带来很多其它管理问题而在实际工作中不被允许。 EBS系统通过提供一个“接收事务处理”工作界面则很简单地解决了上述难题。如图 2‑9所示采购接收的“事务处理”工作界面。 图 2‑9 采购接收的事务处理工作界面 类似于收货时直接在PO纸面单据上简单地做接收数量标识，每次供应商送货来时，库存人员只需在系统中查找出对应的PO，简单地输入送货数量并保存，则系统会在后台自动生成“事务处理记录”（等同于是“入库单”）。对于系统来说，这种处理方式技术上实现非常容易，但却大大减少了操作人员的工作量，有效地解决了由于小批量、多批次所带来的工作效率问题。 EBS系统的各业务模块，大量地采用了上述类似的“事务处理”系统工作方式，不仅保证了系统高度的数据集成性，而且对于系统各业务环节的流程处理也保证了高度的连贯性与集成性。例如订单管理OM系统的发货处理、在制品管理WIP系统的领料与入库处理等等。系统中所提供的有关事务处理工作界面，有些可能会以“××工作台”（Workbench）来命名之（这取决于不同模块系统设计人员的个人偏好）。

2.4.2数据维护类事务处理

所谓“数据维护类事务处理”，是==指系统对于某些重要的“业务流程”类表单，例如“销售订单、发票”等，系统设计在表单界面直接提供一个名曰“活动”（Action）的按钮功能，该“按钮”包含丰富的业务处理功能（不仅仅是输入数据），以便用户对当前表单内容作各种操作处理或获取相关信息==。与“完成任务类事务处理”通常可以对同类型的多个“单据数据”同时作处理，且可能有专门的操作界面不同的是，“数据维护类事务处理”通常只能针对一个（当前）单据数据作处理，且通常是在单据内的弹出窗口而非专用操作界面中输入数据。如图 2‑10所示销售订单界面的“活动”按钮功能。 图 2‑10 销售订单的“活动”功能 除了单据之中的“活动”按钮功能之外，系统设计常常也在界面题头“工具”的可选用功能中，提供类似的针对当前表单数据的“数据维护类事务处理”相关功能。

2.4.3单据转换类事务处理

所谓“单据转换类事务处理”，是==指在两个不同类型的“业务流程”单据之间，用户通过系统提供的相关专用操作界面或弹出窗口，实现业务数据在不同类型单据间的转换和业务流程的衔接==。如图 2‑11所示的采购申请PR到采购订单PO的所谓“自动创建”（Autocreate）功能。 图 2‑11采购PR到PO的“自动创建”事务处理功能 尽管“完成任务类事务处理”与“单据转换类事务处理”都会产生下游新数据，但前者通常产生的是不具“单据实体”性质的“记录”，故系统处理起来比较简单、容易；而后者因产生的是不同类型的新单据实体，系统处理可能因包含诸多数据复制、校验工作，处理起来往往比较复杂，有些可能还需专门的后台“并发流程”协助。例如“计划数据（MPS/MRP）”转换成“采购PR/WIP工单”，“销售订单”转换生成“应收发票”等等。 另外，需注意的是，EBS系统将创建或输入业务流程类表单数据的活动，习惯上有时也称之谓“事务处理”。对于企业的一个普通系统用户User（事务处理型用户）来说，掌握了与自己工作相关的表单、表单查询、事务处理，就基本上掌握了EBS的相关系统功能使用，系统就不再难懂难用。EBS中的“事务处理”在业务流程表单内部解决了“人与系统”的统一问题，在业务流程表单之间解决了“业务与业务、业务与系统”的统一问题。从“纯技术”的系统实现角度来看，它也没有什么高深莫测的地方。

2.5并发流程（Current Process）

从系统实现角度来看，“并发流程”或“并发处理”是较之“事务处理”技术味更浓的一个概念，它也是业务出身、不太懂“技术”的人学习掌握EBS系统的难点之一。但实际上，对于今天的计算机系统而言，“并发”其实是一个再普通不过的应用，例如我们边在电脑上写文章边听音乐等等。相对于系统所谓“联机事务”或“联机处理”方式，++将“并发处理”称为“后台事务”或“后台处理”可能更好理解一些++。 在EBS系统中，“并发流程”功能按处理的对象与所起的作用主要可分为两类：==一类是“流程类并发”，一类是“报表类并发”。系统统一以“提交请求（Request）”的方式提供人机交互==。如图 2‑12所示“查询或提交请求”。 图 2‑12 系统查询或提交并发请求功能

2.5.1流程类并发请求

所谓“流程类并发请求”，是==指系统依赖其完成相关业务流程的构建与运转，或对相关数据的处理功能==。以企业的实际物料接收业务过程为例，在手工业务模式下，库房接收了物料并开具“入库单”后，库房人员后续必须还要做的一项工作是，“手工”将入库单上的物料接收信息逐份“过账”到“库存物料信息台账”上去，以更新库存物料的余额数量。在EBS系统中，这项枯燥、乏味的工作就完全由系统代劳了，系统通过后台运行的一个名为“接收事务处理处理器”的并发程序，联机立即或成批周期进行处理，在不影响用户做其它工作的同时，高度精确地完成着原本需要人工去做的“过账登记”任务，并且手工模式下过账之后为检查错漏而需经常进行的“对账”工作也变得根本就不再需要。如图 2‑13所示。 图 2‑13 接收事务处理并发流程 “流程类并发程序”是EBS系统不可或缺的一个重要组成部分，系统预置了大量的为相关业务流程服务的“流程”类后台事务处理程序，上述“物料接收”的并发处理只是一个比较典型的应用。对于每一个并发“请求”，系统都可以允许或需要输入相关参数，并设置其按某一“周期”自动运行，或“立即”或“预定”在未来某一时刻自动运行。 “并发处理”相对于用户来说，由于是属于在系统后台自动运行的相关工作，刚刚开始接触的人可能会对之觉得陌生或不习惯使用，原因主要是手工业务或低端的管理软件基本没有这种系统工作方式。EBS系统大量使用后台“并发处理”程序，实现了系统用户的流程操作在“空间与时间”上的分离，免去了操作人员的无效等待时间。操作人员提交的并发请求在后台运行的同时，并不影响其处理其它系统事务，这样可以大大提高用户的工作效率以及使用的方便性。“流程类并发程序”之于EBS系统好比人体内的“心脏”一样重要，它是系统实现高度的数据集成与流程集成的核心工具，是企业依赖计算机系统实现业务运作与管理控制自动化的一个典型技术体现。

2.5.2报表类并发请求

所谓“报表类并发请求”，是==指用户可以通过提交相关并发请求，以报表输出的方式查询有关数据==。相对于系统的数据查询功能以确定的“视图”显示查询结果的“显式”查询方式，“报表输出”实际是一种“隐式”数据结果查询方式，它无需系统设计专门的“查询视图”，仅需在报表程序中设计数据输出格式，系统会以“文件”的形式保存每一次的报表输出“结果”，以供查看或打印输出。如图 2‑14所示系统预置的“供应商采购汇总报表”。 图 2‑14 供应商采购汇总报表 尽管系统设计已经预置了数量众多的相关数据“报表输出”并发程序，但通常用户都需==根据企业自身的业务管理要求，使用系统提供的开发工具，“个性化”修改调整系统预置的报表类请求程序，或自定义若干有关报表输出程序==。用户自定义的“报表程序”其运行管理和使用方式与系统预置的报表程序几乎完全相同。 EBS的这种报表功能实现方式，用户在刚开始接触和使用时，可能会感到有些不适应。例如有人曾发出抱怨：“ORACLE的报表功能不好用，出一个简单的报表都要到后台去提交一个请求，输出的是一个文本，太麻烦。系统提供的标准报表，内容不能满足企业要求，不符合国人的使用习惯”。这种说法很可能是因为受某些低端ERP产品的“报表”功能实现方式的影响而产生的误解。因为低端ERP产品对于“报表”功能的设计基本上采取的是类似系统“数据查询”功能的实现方式，这种“查询式报表”虽有用户使用简单的便利，但实际无法从根本上满足企业管理发展的复杂需要。 首先，报表是一种非常“个性化”的东西，不同的企业由于管理层次不一样，关注的管理重点也不同，针对同样的问题所要求的报表也会不同。即使同一个企业在不同的发展阶段，所要求的报表内容也不会相同，因此，即使已经使用ERP若干年的企业，不断地开发新的（管理）报表，也是很正常的事情。如果ERP系统将报表功能“显式化”，在系统标准功能中提供查询条件控件及输出结果视图，则意味着系统提供的这个所谓“报表”功能必须符合所有企业的使用要求，而实际这是不可能实现的。在这种情况下，企业就会理所当然地认为这是ERP厂商的责任，厂商必须负责解决。目前许多低端ERP厂商产品研发的一项重要内容就是穷于应付为企业开发各种查询式管理报表，陷进去恶性循环而无法自拔，其原因正在于此。 其次，“查询式报表”如果内容复杂、耗用系统资源比较高，如任由普通用户随便使用， 而系统管理与维护人员对这种“联机式”查询无法进行有效管理、干预，将可能严重影响系统整体性能，甚而导致其他用户无法进行正常工作。从这个角度来看，目前众多的低端ERP产品实际上还没有真正系统意义上的“报表”功能，只有不加节制、扩大化了的“查询”功能。 EBS系统将“报表”功能以并发请求的形式放到后台去处理，不仅有效地解决了报表的“个性化”问题，分清了ERP厂商与企业的责任界面，而且也为企业IT系统维护人员提供了系统可管理、可干预的便利。这实际上正是ORACLE系统的灵活性与功能强大之处。有人针对国内某些厂商声称自己的ERP是“高端”产品时，质疑“连并发都没有，能算高端吗？”实际上是说到了要害。

2.6文件夹（Folder）

这是一个系统“名称”与实际涵义令人感到有一定“差异”的概念术语（可能也有中文翻译不到位的原因）。系统所谓“文件夹”（Folder）功能，简单来说就是稍有点IT系统使用经验的人都明白的“用户自定义查询输出界面视图”功能。由于系统（可以）提供的查询条件控件或查询输出结果视图的字段是如此之多，基于数据查看或使用的方便性，其中有很多字段可能并不是用户希望显示出来的。 ++每一个系统用户都可以根据个人的工作需要或偏好，使用文件夹功能自由地定义相关单据UI界面的可见或需要显示的“字段”++。EBS 系统为几乎所有重要的表单、查询条件控件及查询结果输出视图都提供了文件夹功能，这也是EBS系统灵活性、易用性、方便性之所在。如图 2‑15所示的采购PR的查询输出视图。 图 2‑15 采购PR查询视图的文件夹功能

2.7弹性域（Flexfield）

所谓“弹性域”是人们每当提及ORACLE EBS 产品的技术先进性时总会首先想到的一个东西，也是很多初学者尤其是不太懂技术的人，刚开始接触时可能会感到有点“深奥”的内容，原因之一是它的“技术味”比较浓。但实际上，如果是首先从系统应用的角度（而不是技术实现的角度）去理解，它也并无多少高深之处。 前面我们已经讲到“表单”是组成EBS系统的最重要基本元素之一，每个表单都由“表头与表体行”组成。系统在UI界面中所展示的是表单的“标准显示”，尽管这个“标准显示”可能已经包含了适合各行各业所使用的那些常用信息字段（Segment），但==对于不同企业来说，总可能会出现需要添加一些本企业特殊需要的信息字段的情况。这种情况从系统应用角度来看，通常又称为“自定义表单字段”。EBS的所谓“弹性域”技术实际上就是为了解决这一常见的系统应用问题==而应运而生的，对于初学者来说，把它简单地理解为“自定义设置表单字段”就容易多了。 系统“自定义设置表单字段”是“系统级”而非“用户级”的，也就是说，只有系统管理员才能做相关设置，而普通用户只能在实际工作中使用。EBS中所使用到的“弹性域”分为两类：==一类是所谓“说明性弹性域”（Descriptive Flexfield），一类是所谓“键弹性域”（Key Flexfield）==。

2.7.1说明性弹性域（Descriptive Flexfield）

EBS系统设计在相关单据的“表头”显示的标准UI界面（角落）中，或在“表体行”的末端，均有一个“方框”（“【 】”）。==用户在需要输入有关特殊信息时点击该“方框”，系统便会分别弹出一个包含若干个自定义信息行（相当于为表单扩展了若干列的字段）的界面框，以供用户输入某些特殊信息==。如图 2‑16所示采购申请PR表头的“弹性域”方框与弹出界面。用户可在其中输入关于该PR的某些自定义补充信息，如“申请部门、申请用途”等等。 图 2‑16 采购PR表头的说明性弹性域 而在图 2‑17所示采购申请PR表体行的“弹性域”方框与弹出界面中，用户也可在其中输入关于该PR行的某些自定义补充信息，如关于所申购物料的“长宽高、颜色”等等。 图 2‑17采购PR表体行的说明性弹性域 EBS系统中几乎所有的重要表单（尤其是业务流程类表单）都具有这种可“自定义”的说明性弹性域字段。系统“说明性弹性域”总数实际有二、三千之多，称之为“说明性”（Descriptive）取其对标准表单字段作补充说明之意。用户在==说明性弹性域中输入的字段信息，通常只能作为统计分析、出报表使用，不参与系统业务流程的构建，系统（应用程序）也不对之在表单之间作跟踪、追溯==。 系统相关单据表头或表体的“说明性弹性域”，在可以使用之前，均必须进行相关设置。如图 2‑18所示采购申请PR表头“说明性弹性域”的系统设置界面。 图 2‑18采购PR表头说明性弹性域的设置

2.7.2键弹性域（Key Flexfield）

系统所谓“键弹性域”的使用较之“说明性弹性域”要复杂、严格很多，原因是它们==参与业务流程的构建，系统的应用程序需要对之进行跟踪、追溯，其作用当然非常“关键”（Key）==。系统可使用的“键弹性域”数量也比较少，在整个EBS系统中总数不过35个。其中使用比较多的有“会计科目弹性域”、“物料类别弹性域”等。 如图 2‑19所示采购PR表单界面中“物料类别”字段，用户作数据输入时，系统将自动弹出已经定义的“物料类别键弹性域”界面，以供用户（选择）输入具体信息。 图 2‑19 采购PR的物料类别键弹性域 与“说明性弹性域”属于表单的用户“补充字段”不同的是，“键弹性域”本身就属于系统表单“不可或缺”的标准字段，这++个特殊的表单标准字段用户输入的不是简单的一个信息，而是具有某种可在系统层面“自定义结构”的一组信息++。如图 2‑20所示“物料类别弹性域”的设置。 图 2‑20 物料类别弹性域设置 系统全部的35个键弹性域主要集中在库存、总账、资产、人力资源等核心业务模块中定义，其它系统模块只是应用时调用。键弹性域由于其在系统中的特殊地位与重要性，其组成信息结构的定义及实际的使用方式要比说明性弹性域来得复杂，且不同的键弹性域也各有其特点。 最后需指出的是，ORACLE EBS的弹性域应用技术作为系统最重要的基础元素之一，历经多年发展，其系统应用已远非上述所例举的“表单字段信息”那么简单，它事实上已经发展成为一种重要的方法论。系统基于（键）弹性域的某些重要技术特性，逐步发展出了诸多使用灵活、功能强大的系统应用实现方式，它在EBS系统功能的设计中具有举足轻重的重要地位。

2.8值集（Value Set）

实际工作中，用户在表单的字段（包括弹性域字段）中输入数据的方式无外乎两种：一种是直接手工键入，例如订单中的数量（数值）或文字说明（字符）等等；另一种就是使用所谓“值列表LOV”（List of Value），用户只能从某个预先定义的“来源单据”中做选择输入（用户如手工输入，系统会自动针对来源单据进行校验以确定输入值是否允许）。 表单字段的“LOV”输入方式实际占了系统数据输入操作的大部分情况，之所以如此的重要原因是==基于系统实现的“标准化”需要==。例如“人力资源管理部”这个官方正式名称，在人们的日常工作与交流中，可能被简化为“人力资源部、人事部、HR”等等，虽然“名称”不同，但大家都知道它们是一回事，一般不会引起误解。但对于系统来说就完全不同了，细微的差别在系统中都是两个不同的对象，所以说“==LOV”实际上也是系统实现“数据共享与集成”的基础==。 表单字段LOV的来源单据值种类，有些可能比较复杂，例如象“物料、供应商、客户”等等，这些字段的值被从来源单据带过来时，系统可能还会带过来其它若干相关重要信息到表单的其它相关字段上去。而有些虽然可能比较简单，但通常需要用户预先做好定义，例如企业的“部门名称列表”等，这些LOV中通称之为“值集”（Value Set）。 在系统中定义一个完整的“值集”需要两个相互独立又相互关联的阶段，首先是定义“==值集名==”，系统中可以定义若干个不同用途的值集名，对于每一个值集（名），在定义界面可以对其相关属性（如“验证类型：无、独立、从属、表”等）做出相应规定，以使其符合实际工作的需要。如图 2‑21所示为“部门名称”的“值集名”定义界面。 图 2‑21 定义值集名 其次是为已经定义好的“==值集名”赋予具体的值==（验证类型为“无”的除外），以组成系统可用的LOV。如图 2‑22所示，其中，有些值之间还可以根据需要定义形成某种“层次结构”，“父子值”之间具有“汇总与被汇总”的关系。 图 2‑22 为值集名定义值列表 用户定义的“值集”实际主要使用在表单的“键弹性域或说明性弹性域”字段，以及并发程序的“参数”字段之中，用途不同则定义值列表LOV的具体方式也不相同。需注意的是，验证类型为“从属”或“表”的值集定义与赋值方式比较特殊，前者需先定义所从属的“独立”值集，后者则是将某个系统内的“应用表”作为自己的LOV来源（如“定义供应商”表单维护的供应商名称表），值集定义时，需规定使用哪些表，并定义 WHERE 子句来限制值集要使用的值。

2.9查找代码（Lookup Code）

使用值集LOV的表单字段的值几乎都有一个共同的特性是，一般不直接参与业务流程的构建，或不直接影响业务流程的运行。然而系统表单的某些字段是需要承担“流程构建”工作的，这些表单字段有些需要手工输入，有些则可能是系统流程运行时自动赋值或在不同流程阶段自动改写（例如，表单状态“未完成、已保存、已批准、已拒绝”等等），有些值在表单中通常“可见”，有些则可能是在特殊情况下才可见。 上述这些表单的特殊字段（域）的LOV，==一般是由系统在所谓“查找代码”（Lookup Code）功能中定义的。EBS 在系统层面于一个统一的界面（Form）中按系统模块、按引用字段进行全部Lookup Code定义==。如图 2‑23所示库存相关表单中使用到的物料的“需求类型”定义。 图 2‑23 系统查找代码的定义 Lookup Code系统的定义分为三种情况（访问级别），一种是“==系统级==”，属于ORACLE预定义且不允许用户添加。这种情况下的“代码值”（Code）基本都属于系统的应用程序中需要引用到的，影响或决定着系统业务流程的运行；二种是“==用户级==”，属于非系统预定义而由用户自己添加，这种情况下的代码值一般不被应用程序所引用，其作用与前述值集LOV值大体相同；三种是“==可扩展级==”，属于ORACLE预定义但允许用户添加。这种情况下的系统预定义值与“系统级”的定义值作用基本相同，而用户添加的部分，其作用则与“用户级”基本相同。

2.10配置文件（Profile）

EBS的所谓“配置文件”实际就是人们所经常提到的“==系统参数==”的一种。系统“配置文件”功能的应用涉及两个方面的内容：==一是配置文件的本身定义（Definition）；二是配置文件的应用设置（Setup）==。

2.10.1系统配置文件的定义

EBS系统预定义的配置文件数量十分庞大，达七、八千个之多，==系统的相关应用程序通过调用预设的配置文件（及其设置值），来实现不同的系统业务功能==。尽管系统预置的配置文件对于应用程序的运行至关重要，但这些配置文件对于系统用户来说都是透明可见的，并不神秘。系统提供“配置文件”定义界面，供系统管理员对配置文件的某些属性（甚至应用程序）进行调整或修改，例如设置控制相关配置文件在何种情况下，普通用户“既可查看也可更新其应用设置值”，或“可查看但不可更新其应用设置值”等等。如图 2‑24所示系统配置文件的定义。 图 2‑24系统配置文件的定义 需指出的是，系统预定义的“配置文件名”有一定命名规则（适用于大多数配置文件，少数例外），例如“MRP：冲减MDS”，前面的MRP是系统代码，代表属于哪个应用模块，后面的部分则是代表具体用途。这种“命名规则”使我们很容易查找到针对不同模块的相关参数。 实际工作中，如有必要，系统开发人员也可以自定义系统配置文件，并应用于自行开发的个性化应用程序中。尽管系统预定义配置文件（参数）数量是如此之多，令人生畏，但归纳起来，可以发现所有“配置文件”按用途大致可划分为三类： 一类是真正起到控制业务流程运作或事务处理方式的部分，这些参数就是人们通常所津津乐道的所谓“流程开关”；二类实际并不直接控制流程运作或事务处理，只是起到一个向表单上默认某些值的作用（这些默认过去的值，有些参与流程构建，有些仅起参考作用。用户在表单上还可以对默认值进行修改）；三类是起到某些特殊控制作用，例如改变系统的某些工作方式、控制UI界面的颜色字体等等，通常与具体业务关系不大。所有系统预置的“配置文件”中前两类占了绝大部分数量（其中第一类又占主要部分），第三类数量很少。而系统应用的难点与重点则是“第一类”、属于“流程开关”那部分参数。

2.10.2系统配置文件的应用设置

EBS 系统的配置文件的“应用设置”（Setup）非常方便灵活，组合起来的应用功能十分强大。==系统的配置文件设置具有“结构层次性”，对于某一个具体的配置文件，系统允许最多可以在6个层级进行设置并发挥作用：地点层（系统安装）、应用产品（模块）、责任（自定义的责任）、服务器、组织（包括OU/INV等）、用户（自定义的用户）==。而具体能在上述6个层级中的哪些层级“可见、可设置”，则取决于这些配置文件的原始定义的相关属性。如图 2‑25所示配置文件的应用设置。 图 2‑25 系统配置文件的应用设置 实际应用程序访问“配置文件”时，将按照从“地点”到“用户”，由低到高的“优先级”顺序发挥作用。最高优先级的“用户层”如果留空不赋值，则系统将默认上一层级（责任层）的设置值作为自己的值，如果上一层级留空，系统将逐级前移直至最低优先级的“地点层”。通常系统在安装后于“地点层”有初始化的默认设置值（或虽留空，但系统程序仍然会自动默认一个值）。 尽管看起来系统配置文件数量有七八千，设置工作量巨大，但实际系统实施时，对于大部分企业来说，通常使用系统安装时的默认初始值就能基本符合要求，故也并不十分困难可怕。企业在实际工作过程中，如出现希望系统能实现某种指定的业务功能，或希望系统流程能按某种方式运行等等情况，则通常应该首先基于系统配置文件的不同设置来寻求合适的解决方案。 此外，==系统对于配置文件还提供了“系统”与“用户”两种“安全性”（权限）控制的设置“菜单功能”==。“配置文件”的“系统级设置”菜单功能一般由系统维护人员（如系统管理员）进行设置控制，相关设置修改的影响面可能很大（地点级、应用模块级、责任级）；而配置文件的“用户级设置”菜单功能则可提供给普通用户使用，其相关修改仅作用于用户自身，不会对其它人的系统使用产生影响。

2.11单据编号（Document Sequence）

与手工业务模式下新增单据一样，系统中的绝大多数“表单”或“记录”，由于业务数据量巨大，也需要进行编号管理。基于系统有关“表单”或“记录”的不同性质与用途，系统“单据编号”的方式也有所不同。归纳起来主要有三类：一类是==自定义单据类别及编号方式==；二类是==系统参数设置编号方式==；三类是==数据库编号方式==。

2.11.1自定义单据类别及编号方式

系统中的某些业务流程类表单如“销售订单、应收发票”等等，可以根据业务需要（分模块）自定义不同的“单据类别”，并为“单据类别”分配相关的编号方式。这种单据编号方式的使用包括既相互独立又相互关联的三个步骤：一是定义“==单据序列”（发生器）==；二是定义具体的“==单据类别==”，三是将“==单据序列”分配给“单据类别==”。如图 2‑26所示的定义“单据序列”（发生器）。 图 2‑26 定义单据序列（发生器） “单据序列（发生器）”的编号方式也分为三种：==自动编号、人工编号或无间隙（人工编号必须连续不断号）==。这里需注意的是，实际工作中创建相关单据时，即使要采用人工输入编号的方式，也必须事先设置所谓“人工编号或无间隙”的“单据序列（发生器）”并分配给相关“单据类别”。此外，系统在初始安装时，无初始预置的“单据序列”可用，必须为相关业务模块分别定义可用的“单据序列”。 有关业务系统模块具体的“单据类别”的定义则情况比较复杂，它们通常并不是在“单据类别”菜单功能中定义的，而是在有关业务模块（如订单管理、应收账款等）中使用所谓“事务处理类型或单据类别”菜单功能定义后，自动添加并出现在“单据类别”的显示中（包括系统预置的相关事务处理类型或单据类别，主要是总账与应收账款系统的相关预置值）。如图 2‑27所示。 图 2‑27 查看有关业务模块中已定义的单据类别 无论是系统安装时预置的“单据类别”，还是用户在有关业务模块中自定义的“单据类别”，均必须使用“分配”菜单功能，将“单据序列（发生器）”分配给“单据类别“，使两者关联。如图 2‑28所示。 图 2‑28 将单据序列分配给单据类别 注意，图 2‑28中“方法”字段的涵义是表示该“单据类别”已分配“单据序列”的使用条件（不要与单据编号方式的“自动、人工”相混淆）。“自动”表示仅限系统自动创建单据时使用（如从第三方系统导入时自动创建单据）；“人工”表示仅限人工创建单据时使用；“空”表示不限制，任意情况均可。

2.11.2系统参数设置编号方式

所谓“系统参数编号方式”与上述“自定义单据类别及编号方式”的区别在于，无需设置单据类别，且也无需设置“单据序列（发生器）”，通常仅需在有关业务系统模块的“系统参数”中设置相关单据（实体）的编号方式（自动/人工）。如图 2‑29所示的“采购选项”中对询价单、报价单、PO、PR的编号方式的设置。 图 2‑29 采购单据的系统参数设置编号方式 类似采购单据编号方式，还有在库存系统的“接收选项”中设置“接收编号方式”，在“财务系统选项”中设置“供应商编号方式、员工编号方式”，在“应收系统选项”中设置“客户编号方式”等。 注意，“系统参数设置编号方式”虽然比“自定义单据类别及编号方式”来得简单，但应用与管理的灵活性则要差一些。系统设计用何种方式对相关种类的单据进行编号，主要取决于单据本身的性质用途及管理的复杂性要求（也可能与系统设计人员的偏好有一定关系），典型的对比就是“采购订单与销售订单”、“AP应付发票与AR应收发票”的不同编号设置方式。因为实际工作中企业作为“买方”与作为“卖方”角色的不同，其所可能采取的相关单据编号管理方式也不会相同

2.11.3数据库编号方式

系统中的某些单据或记录的管理复杂性要求比较低，系统在初始安装时，在数据库的相关表中已经预置了确定的“编号方式”，无需专门的设置。如图 2‑30所示的库存系统“物料搬运单”的编号方式。 图 2‑30 物料搬运单的数据库编号方式 图2-30中的物料搬运单在创建时，如果不作手工输入，则系统会自动为之编号，如果作手工输入，则系统会检查是否与已存在的编号重复。类似的数据库编号方式，还有如“发运执行系统”中的“交货行或交货”的编号等等。系统之所以采用这种比较简单、直接的数据库编号方式，是因为相关单据或记录虽然也需要编号，但编号的作用仅是一个普通的区分“标识”，通常并不具有业务管理上的特定作用与要求。

2.12附件（Attachment）

实际工作中，用于记录数据的表单的信息容量总是有限的，同时受表单数据具有“结构化”特征的格式限制，有些信息如图片、文本等所谓“非结构化数据”并不适合直接纳入表单之中，例如设备部门提交一份需采购仪器的清单列表（采购PR）给采购部门，通常可能还需要附带提交“申购评审报告”以及相关技术参数说明等参考文档，以满足公司相关管理制度要求并方便采购部门获取必要信息。数据记录表单能够附加参考文档信息就是最基本的“单据附件”功能。 在EBS系统中，除了上述基本的、也是容易理解的所谓“单据附件”功能之外，++系统还为几乎所有操作界面（功能）、查询视图也提供了“附件”查询功能；对于（实体）单据，则不仅能为单据头，而且还能为单据行提供不同的附件；对于具有流程关系的上下游单据，还能够提供附件在单据之间进行传递的功能；此外，基于管理控制的需要，附件还可以有不同的查询、修改权限控制等功能++。如图 2‑31所示的“采购订单题头”附件功能： 图 2‑31 采购订单的题头附件功能 图2-31中，对于特定的“表单块（Block）”或“字段”如供应商，倘若其对应的相关实体（实例）也定义有附件，则也可以在当前表单（功能）中进行查看，如图 2‑32所示： 图 2‑32 采购订单题头供应商字段的附件查看功能 相应地，在该采购PO的“接收”功能操作界面，不仅可以查看由采购PO带过来的附件，而且还可以同时为该“接收”添加新的附件（以便传递到付款部门作相关信息提示），如图 2‑33所示。 图 2‑33 采购接收的附件功能 此外，EBS系统还允许用户根据实际工作需要定义不同的附件“类别”，并将之分配给不同的“表单”或“功能”，以及在不同的表单块及其相关单据实体上的设置附件的使用控制方式。

2.13工作流（Workflow）

在企业的实际管理工作中，若一个员工填写好一份“费用报销单”后，通常后续可能还需要经过多个环节例如直接主管、上级主管、财务主管的审批，才可能最终到达会计（入账）、出纳（付款）手中，以便完成整个处理过程。把这个工作处理过程“电子化”后放入系统，就形成一个所谓的“工作流”过程。通常这个报销单“工作流”需要经过哪些环节，是系统需要预先设置好的，并且不同的费用类别所需经过的审批环节可能也并不相同。系统工作流功能通常在流程环节移动过程中，会向下一环节的处理人发送提醒通知；作为工作流的流程参与者，例如“提交人、审批人”等，也可以查询、监控单据的工作流处理过程；。 上述单据的“审批流”实际是一个很简单、很直观的“工作流”应用。推而广之到系统中其它业务流程类表单的事务处理过程，所谓系统的“工作流”技术应用就是：==根据不同的业务单据类别，事先定义好需要经过的不同业务处理环节，单据在做事务处理时，按规定顺序在相关环节间移动==。用户可监控，即普通用户可以查看工作流的处理过程状态；系统可管理，即系统工作流管理员，必要时可以对单据的工作流过程进行干预，例如跳过某些环节、改变参与人等等。 EBS 系统核心业务模块OM中关于销售订单的处理，就是一个典型的“工作流”技术使用范例。 对于具体的每一个销售订单，同一订单中可能包含不同行类型的订单行，这些订单行将循着各自的“行工作流”而进行事务处理。系统在表单界面的工具栏提供“工作流状态”的查看功能，用户可以随时对订单中的每一个订单行的系统处理过程实施监控、查看。如图 2‑34所示销售订单行的工作流监控功能使用界面。 图 2‑34 销售订单的工作流状态查看功能 图 2‑34中，点击“工作流状态”查看功能，则系统将打开属于当前订单行1.1的工作流WEB查看页面。系统提供“活动历史记录”与“状态图”两种主要查看方式，分别如图 2‑35与图 2‑36所示。 图 2‑35 销售订单行的工作流活动历史记录 图 2‑35中所示订单行的活动历史记录，系统从用户输入订单开始，对于后续几乎每一步事务处理操作都做了记录。而图 2‑36中所示则以直观的图形方式显示了订单行流程状态。 图 2‑36 销售订单行的工作流状态 系统用于分配给销售订单“行类型”的行工作流，ORACLE提供了预定义的多种不同类别供用户在设置系统时做选择。更进一步，ORACLE还提供“Workflow Builder”软件包工具（这个软件可以到ORACLE官网上自由下载使用），以便用户对于系统所有预定义的流程进行复制修改，或自定义符合使用要求的特殊流程。 需要指出的是，并非所有业务流程类表单都要采用类似销售订单的“工作流”处理方式；不同种类的业务流程类表单使用“工作流”的方式也不完全相同，例如“采购订单”的“工作流”使用方式就比“销售订单”来得简单。系统各应用模块是否使用、如何使用“工作流”技术，与具体的业务需求特点，以及采用工作流技术的优缺点等因素有很大关系，不能一概而论。

2.14预警（Alert）

实际工作中，当出现某些异常情况或异常事件时，总是希望系统能给相关用户发出提醒或警示，以便用户能对异常进行及时的处理。EBS的系统预警分两种方式，一是“==事件预警==”，二是“==周期预警==”。两者的基本工作方式均是使用SQL Select语句，基于对数据库中的相关值作出条件判定，以决定是否执行某种活动，如“发出信息，执行并发程序、执行操作系统程序、执行SQL语句”等等。更进一步，对于“发出信息”类预警，EBS系统在收到对此信息的符合规定格式的“回复”后，还可以据此自动执行相关活动并完成相关事务处理。

2.14.1事件预警

所谓“事件预警”，即==当用户在相关数据表中“插入”或“更新”某些值时，系统自动启动已定义的“SQL Select语句”的检查，已确定是否需要发出预警信息或执行某种活动==，如图 2‑37所示的一个事件预警定义：在采购管理系统模块中，当出现一个巨大数量的申请行数量被输入时，系统将向相关责任人发出预警通知（以提醒诸如做好资源准备等）。 图 2‑37 采购系统的相关事件预警设置

2.14.2周期预警

所谓“周期预警”，即系==统按照事先定义好的周期间隔或频率，自动启动已定义的“SQL Select语句”针对数据库中表的某些值作检查，已确定是否需要发出预警信息或执行某种活动==，如图 2‑38所示的一个周期预警定义：在采购管理系统模块中，系统按每两个工作日的间隔频率对所有“一揽子采购协议BPA”的到期情况进行检查，并将需要关注的检查结果（例如某些BPA将在一周之类过期）通知到相关责任人。 图 2‑38 采购系统的相关周期预警设置

2.15应用开放接口（Open Interface and API）

任何ERP系统都无法做到在任何情况下都能满足企业实际使用的各种要求，企业有时可能需要从其它来源向系统中批量输入数据，如从物料的Excel电子数据表格向EBS的库存系统导入物料Item信息等等，或者需要与其它第三方应用系统建立业务数据的交换机制，如从专用的“费用报销或发票申付”管理系统向EBS的应付AP系统导入事务处理数据并将事务处理执行结果反馈回来源系统等等。 理论上，使用相关数据库工具可以向数据库的数据表中直接批量写入数据，但这样做无法对写入的数据进行正确性、合规性校验，无法保证写入数据的质量以及对存在问题进行有效管理。为此，==ORACLE提供了接口表Interface Table作为“中间表”过渡，并在此基础上，根据某些业务需要提供业务视图Business View，以便对导入的数据进行修改、更正、重新导入等等管理==。如图 2‑39所示“开放接口框架（Open Interface Diagram）”。 图 2‑39 系统的开放接口框架 更进一步，ORACLE将某些数据的导入导出功能进行封装，成为一个应用程序可以调用的接口（API），==以实现在各模块之间以及内部模块与外部系统之间的数据与流程集成==。如图 2‑40所示“应用开放接口程序框架Open Application Programmatic Interface（API）Diagram”。 图 2‑40系统的应用开放程序接口API 开放接口（API）的基本工作模式分为两个阶段：一是先==将来源数据装入（Load）接口表==。如果是在两个应用系统之间，这通常是由专用的装入程序完成，例如EBS内部采购申请要转成内部销售订单，需先运行“创建内部销售订单流程”，以便将内部采购申请发送并插入订单管理系统的接口表。如果是从某些电子表格如EXCEL等导入，则需要先使用专门的SQLLoad工具将数据格式转换后直接插入相关接口表，例如要通过物料的EXCEL数据表直接批量装入Item数据，必须先通过SQLLoad工具将来源数据插入Item数据接口表。在将数据插入接口表的过程中是否对数据进行校验（或是在将接口表数据导入正式表时再校验），取决于系统各应用模块的不同设计； 二是==系统将存在于接口表中的数据导入正式的业务数据表==。如EBS订单管理模块的“订单导入”，库存管理模块的“导入Item”等等。在从接口表导入“正式表” 或数据装入“接口表”过程中因数据校验而产生的错误或失败信息，如系统提供专门的业务管理视图，则可以在其中进行查看、更正、重新提交，如EBS的“订单导入更正”窗口等。如系统未提供管理视图，则可以在并发程序请求的“输出”文件中查看结果。如图 2‑41所示“应付款管理模块费用报表类发票导入流程图”是就是一个典型的API应用过程示例。 图 2‑41应付款管理模块费用报表类发票导入流程图

2.16结语

人类的认识总是从已知的东西逐步推展到未知的领域。如果我们暂且抛开系统具体的业务流程、功能应用以及操作细节不谈，仅针对前述ORACLE EBS系统的前述十多个基本组成构件元素，从实践来源与系统实现两方面，作虽非详细深入但比较直观简要的探讨，我们也许就能获得这样一个总体上的认识，即：无论多么庞大、复杂的一个软件应用产品体系，它仍然是由一些使用比较简单、理解并不深奥的基本构件元素所组成；这些基本构件来源于业务实践，或与日常工作息息相关，我们其实并不陌生，它们是“从业务到技术，再从技术回到业务”两者高度融合的结果，也是我们学习与使用EBS系统所必需掌握的钥匙。 我们经常见到有些国内产品在宣传中，总是喜欢嘲讽国外产品如SAP已经是“老古董”，刻意强调自己的技术是如何先进、平台是如何创新等等。这些于企业应用实践其实相距甚远、华而不实的东西，而在产品研发过程中，却忽略了于企业信息化实践更为重要的基本元素与应用基础的研究。这就好比卖房子的开发商总是卖弄自己造房子的钢筋质量是如何好、水泥标号是如何高、施工所用的机械设备都是进口的等等，问题是这些与买房人真正所关心、所需要的“户型结构、空间适用以及小区配套”等又有多大关系呢？ 技术的进步无疑会对企业管理实践中的组织形态、业务模式等诸多方面产生重大影响，管理作为一门“科学”而诞生的这近一百年来，企业管理实践从早期的“职能管理”到现代的“流程管理”，从早期主要内向关注“生产效率”到现代重点外向关注“客户需求”，技术的进步尤其是近二十年来信息技术的飞速发展起到了重要的推动作用。但管理科学毕竟是属于“形而上”的范畴，相较于“形而下”的器物层面，技术进步的作用与影响方式总是承前继后、继往开来而非颠覆性的。 管理软件从三十年前的主机时代，到二十年前C/S架构的客户机/服务器时代，再到十年前开启的B/S架构的互联网时代，软件具体技术的发展较之于信息技术整体进步对企业管理实践的影响，总的来说还是局部的、非决定性的。今天大概不会再有人相信“管理软件从C/S架构进化到B/S架构是企业管理实践的一场革命”这样的夸大其辞，遑论更为等而下之的诸如.NET平台、Java平台、私有的ABAP平台等等这些纯技术领域的开发工具对于管理软件中所蕴含的管理思想、业务流程模式等能有多大影响。 实际工作中，对于普通的EBS系统用户而言，结合自身的具体业务特点，大多数情况下掌握了上述十多个基本元素中前几个，例如表单、查询、事务处理、文件夹以及报表类并发请求等，就足以可应付一般的日常工作；而对于系统维护、顾问实施人员来说，相对而言后几个“技术味”较浓的基本构件元素，诸如“并发处理、弹性域、配置文件、工作流”等则是需要学习研究的重点与难点。 不过需指出的是，尽管本章有关系统功能应用基础的基本组成构件元素的介绍，只能起到一个帮助初学者打破神秘、入门引路的作用，但由于这些基础性的构件元素是后续进一步学习与研究系统应用功能的基础，能否熟练掌握事关后续的学习过程是否能有效率地顺利进行，故对于广大初学者来说，应当首先在ORACLE EBS的测试环境中，参考本书有关章节的具体内容，进行耐心细致的系统研究与操作演练，直至能够应用自如。