系列三ORACLEEBS系统应用基础概述

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视图界面可以再选择打开相关条目的表单。同时，也可以直接在单据界面按“翻页”键（Page Down或Page Up），在已经查询出的不同条目间按顺序直接切换。如图7所示：物料快捷查询方式的查询条件控件与输出结果视图： 上述（两种）快捷查询方式，适用于大多数业务数据量大的表单数据的查询。而后一种“快捷查询”方式与“功能查询”方式有些近似，只是其查询结果的输出视图的相关“功能”（如上查下查的追溯、汇总与明细的切换等）没有“功能查询”方式那么强大。但对于大多数“数据来源”类表单，由于它们不参与构建核心流程，信息也不如业务流程类表单那样复杂，故“快捷查询”方式已经基本能够满足实际工作需要。如按“功能查询”方式为所有表单设计“查询条件控件”与查询“输出结果视图”（象某些国内产品做的那样），则系统设计工作的复杂性将大大增加，后续系统维护也将十分麻烦，既不经济也无多大实际意义。 所谓“简便查询”方式，即在打开单据界面后直接把“单据”界面的所有字段作为“查找条件输入窗口”。要做到这一点，只需在打开单据界面后，于UI的工具栏“查看”中选择“查询标准-输入”（或按F11键），此时单据界面有关字段即“灰显”，允许输入具体查询值，再在“查看”中选择“查询标准-运行”（或按Ctrl+F11），则单据界面显示查询结果，按“翻页”键（Page Down或Page Up），在已经查询出的不同条目间按顺序直接切换。如下图8所示：物料清单BOM的简便查询方式示意图： 这种查询方式既不需要“查询条件”控件，也不需要查询结果输出视图，系统设计上十分简单节省，适用于几乎所有表单。要注意的是对于系统中某些数据量很少的表单，则有可能系统只提供“简便查询”作为唯一可使用的查询方式。 此外，EBS中的某些表单，在WEB下可能还有基于HTML的展现与查询方式。UI与HTML这两种展现与查询方式的优劣，一方面与使用场合有关，另一方面也与使用习惯有关。总之，了解系统中各类表单的使用并熟练掌握各种查询方式，是进一步学习研究系统的基础，尽管EBS各模块的表单展现与查询方式因不同业务、不同设计者的风格偏好而可能有所不同，但核心本质的东西还是共同一致的。三、事务处理（Transaction）如果说上述EBS的“表单与查询”的系统设计体现的正是“从业务到技术”，比较容易理解与掌握，那么，所谓“事务处理”则是体现系统“从技术再到业务”的一个典范，相对而言，理解起来要困难很多，原因是无法直接在手工业务模式下找到相对应的处理方式与过程。以库房接收采购物料为例，假定公司规定必须严格按PO来接收，并且公司为了严格控制库存水平，接收必须小批量、多批次，则库房人员就可能需要针对同一个PO在短时期内开出N多张的“入库单”，工作量很大。为了减少工作量、提高效率，库房人员可能会在供应商每次送货时，仅在找出来的PO纸面单据上只简单地做一个数量标识，最后累积起来汇总开一张“入库单”。但这种“图省事”的做法显然是一种“很不规范”的处理方式，虽可以提高工作效率，却会因为容易带来很多其它管理问题而在实际工作中不被允许。ORACLE 系统通过提供一个“事务处理”工作界面则很简单地解决了上述难题。如下图9所示采购接收的事务处理工作界面：类似于“收货时直接在PO纸面单据上简单地做数量标识”，每次供应商送货来时，库存人员只需在系统中查找出对应的PO，简单地输入送货数量并保存，则系统会在后台自动生成“事务处理记录”(等同于是“入库单”)。对于系统来说，这种处理方式技术上实现非常容易，但却大大减少了操作人员的工作量，有效地解决了由于小批量、多批次所带来的效率问题。ORACLE的各业务模块，大量地采用了上述类似的“事务处理”系统工作方式，不仅保证了系统高度的数据集成性，而且对于系统各业务环节的流程处理也保证了高度的连贯性与集成性。例如OM系统的发货处理、WIP系统的领料与入库处理等等。系统中所提供的事务处理工作界面，有些可能会以“工作台”（Workbench）来命名之（这取决于不同模块系统设计人员的个人偏好）。更进一步，系统对于某些“业务流程”类表单，例如“销售订单、发票”等，还在表单界面直接提供一个名曰“活动”（Action）的按钮（Button），该按钮包含丰富的业务处理功能（不仅仅是输入数据），以便用户（User）对表单内容作各种操作处理或获取相关信息。如下图10所示，销售订单界面的“活动”按钮：此外，ORACLE EBS在某些业务流程单据之间，也提供了类似的事务处理工作界面，以帮助用户方便地实现业务单据的转换和业务流程的衔接。如下图11所示的采购申请PR到采购订单PO的所谓“自动创建”（Autocreate）功能。 对于企业的一个系统用户User（事务处理型用户）来说，掌握了与自己工作相关的表单、表单查询、事务处理，就基本上掌握了EBS的系统使用，系统就不再难懂难用。EBS中的“事务处理”在业务流程表单内部解决了“人与系统”的统一问题，在业务流程表单之间解决了“业务与业务、业务与系统”的统一问题。从“纯技术”的系统实现角度来看，它也没有什么高深莫测的地方。很奇怪也很遗憾的是，迄今国内主流ERP产品的系统中，还很少看到这种系统实现方式。曾有一网友通过MSN向笔者发问：“EBS的WIP 事务处理界面是否要手工输入item？”看起来这个问题似乎很“幼稚”，但对于很多刚开始接触EBS或过去用惯国内产品的人来说，由于不了解或不习惯EBS的“事务处理”系统实现方式，会不自觉、想当然地将所有EBS的FORM界面都当成具有“实体”作用、通常可以对应纸面单据的“业务表单”来看待，才会发出这样的疑问。四、并发流程（Current Process）从系统实现角度来看，“并发流程”或“并发处理”是较之“事务处理”技术味更浓的一个概念，它也是业务出身、不太懂“技术”的人学习掌握EBS系统的难点之一。但实际上，对于今天的计算机系统而言，“并发”其实是一个再普通不过的应用，例如我们边在电脑上写文章边听音乐等等。ORACLE 弄得有点学究气，相对于“联机事务”或“联机处理”方式，并发处理称为“后台事务”或“后台处理”似乎更好理解一些。以企业的实际业务过程为例，在手工业务模式下，库房接收了物料并开具“入库单”后，库房人员后续必须还要做的一项工作是：“手工”将入库单上的物料接收信息逐份“过账”到“库存物料信息台账”上去，以更新库存物料的余额数量。在EBS系统中，这项枯燥、乏味的工作就完全由系统代劳了，系统通过后台运行的一个名为“接收事务处理处理器”的并发程序，联机立即或成批周期进行处理，在不影响用户做其它工作的同时，高度精确地完成着原本需要人工去做的“过账登记”任务，并且手工模式下过账之后为检查错漏而需经常进行的“对账”工作也变得根本就不再需要。“并发处理”是EBS系统不可或缺的一个重要组成部分，上述“物料接收”的并发处理只是一个很简单的应用。在EBS中，“并发”按处理的对象主要可分为两类：一类是“流程事务”，一类是“报表事务”。系统统一以“提交请求（Request）”的方式提供人机交互。如下图12所示“查询或提交请求”：对于每一个并发“请求”，系统都可以允许输入相关参数，并计划其是按某一周期运行，还是立即或预定在未来某一时刻运行。系统预置了大量的为业务流程服务的“流程事务”类后台事务处理程序，同时还提供了部分可供企业参考的“报表事务”类输出请求。用户使用系统提供的开发工具，也可以很容易地自定义某些“个性化”的后台程序或报表输出，其运行管理和使用方式与系统预置的并发程序几乎完全相同。“并发处理”相对于用户来说，实际上是属于在系统后台运行的相关工作，刚刚开始接触的人可能会对之觉得陌生或使用不顺手，原因主要是手工业务或低档的管理软件根本没有这种工作处理方式。这就好比相对于交通主要还是靠骑车或步行的小城镇，今天对于生活在现代化大城市的人们来说，往来穿梭的地铁、周而复始的公交、招手即停的出租车已经成为全部生活不可或缺的一部分，它们就像城市的“血管”脉动一样，奔流不息，维持着城市生命的运转，生机勃勃。EBS的“并发处理”所承担的角色或所起的作用正与之基本类似。EBS并发处理的另一项重要特性是其“系统级”的可计划、可管理、可控制特性，系统通过定义“并发管理器”、“请求集”等功能应用，对所有需要在后台运行的并发程序进行管理调度，以平衡系统负载，保证系统有高的使用性能。如下图13所示，定义“并发管理器”（包括运行规则、工作班次等等。这类似于城市里的交通调度与控制）关于“流程事务”类的并发请求，因为涉及到系统各业务模块的具体功能应用问题，这里不便多讲。以下主要来谈一谈“报表事务”类的并发请求问题。有网友曾抱怨说，“ORACLE的报表功能不好用，出一个简单的报表都要到后台去提交一个请求，输出的是一个文本，太麻烦。系统提供的标准报表，内容不能满足企业要求，不符合国人的使用习惯”。这种说法可能是因为受某些国内产品的影响而产生的误解。目前国内的主流ERP系统，对于“报表”基本上采取的是类似“查询”的实现方式。这种“查询式报表”虽然方便了用户使用，但却惹出了无穷的麻烦。首先，报表是一种极端“个性化”的东西，不同的企业由于管理层次不一样，关注的管理重点也不同，针对同样的问题所要求的报表也会不同。即使同一个企业在不同的发展阶段，所要求的报表内容也不会相同，因此即使已经使用ERP若干年的企业，不断地开发新的（管理）报表，也是很正常的事情。如果ERP系统将报表功能“显式化”，在系统标准功能中提供查询条件控件及输出结果视图，则意味着系统提供的这个所谓报表功能必须符合所有企业的使用要求，而实际这是不可能实现的。在这种情况下，企业就会理所当然地认为这是ERP厂商的责任，厂商必须负责解决。目前许多国内ERP厂商产品研发的一项重要内容就是穷于应付为企业开发各种查询式管理报表，这简直是等于自掘火坑，陷进去无法自拔，其次，查询式报表如果内容复杂、耗用系统资源比较高，则用户随便自由使用， 而IT系统维护人员对“联机式”查询无法进行有效管理、干预，将可能严重影响系统整体性能，导致其他用户无法进行正常工作。从这个角度来看，目前国内的主流ERP产品实际上还没有真正系统意义上的“报表”功能，只有不加节制、扩大化了的“查询”功能。系统如此处理极不明智。ORACLE 将“报表”功能以并发请求的形式放到后台去处理，不仅有效地解决了“报表”的个性化问题，分清了ERP厂商与企业的责任界面，而且也为企业IT系统维护人员提供了系统可管理、可干预的便利。这实际上正是ORACLE系统的灵活性与功能强大之处（SAP也类似）。有网友针对国内某些厂商声称自己的ERP是“高端”产品时，质疑“连并发都没有，能算高端吗？”实际上是说到了要害。一个连“电梯”都没有的高楼怎能算得上是现代化的大厦呢！ORACLE系统大量使用后台“并发处理”程序，实现了系统用户的流程操作在“空间与时间”上的分离，免去了操作人员的无效等待时间。操作人员提交的并发请求在后台运行的同时，并不影响其处理其它系统事务，这样可以大大提高用户的工作效率以及使用的方便性。“并发”之于ORACLE EBS系统好比人体内的“心脏”一样重要，它是系统实现高度的数据集成与流程集成的核心工具，是企业依赖计算机系统实现业务运作与管理控制自动化的一个技术体现。五、文件夹（Folder） 这又是一个ORACLE弄得有点学究气的概念（可能也有中文翻译不到位的原因）。所谓“文件夹”（Folder）功能，简单来说就是稍有点IT系统使用经验的人都明白的“用户自定义查询输出界面视图”功能。系统（可以）提供的查询条件控件或查询输出结果视图的字段是如此之多，其中有很多可能并不是用户希望显示出来的，每一个系统用户User可以根据个人的工作需要或偏好，使用文件夹功能自由地定义自己可见的UI界面。ORACLE 系统为几乎所有重要的表单、查询条件控件及查询结果输出视图都提供了文件夹功能，这也是ORACLE系统灵活性、易用性、方便性之所在。如下图14所示采购PR的查询： 六、弹性域（Flexfield）所谓“弹性域”技术是人们每当提及ORACLE 产品技术的先进性时总会首先想到的一个东西，也是很多初学者（尤其是“业务出身”的人）开始接触时可能会感到有点“发怵”的东西，原因之一是它的技术味比较浓。但实际上，如果从应用的角度去理解，它也并无多少神秘之处。前面我们已经讲到“表单”是组成EBS系统的最重要基本元素之一，每个表单都由“表头与表体行”组成。系统在UI界面中所展示的是表单的“标准显示”，尽管这个“标准显示”可能已经包含了适合各行各业所使用的那些常用信息字段（Segment），但对于不同企业来说，总可能会出现需要添加一些本企业特殊需要的信息字段的情况，这从系统角度通常称为“自定义表单字段”。EBS的所谓“弹性域”技术实际就是为了解决这一常见的系统应用问题而应运而生，对于初学者来说，把它简单地理解为“自定义表单字段”就容易多了。如下图15与图16所示的采购申请PR表单，在表头部分“标准显示”的UI界面（角落）中有一个“方框”（“【 】”），在表体行部分的末端也有一个“方框”（“【 】”）。系统用户在需要输入有关特殊信息时点击“方框”，系统便会分别弹出一个包含若干个自定义信息行（相当于为表单扩展了若干列的字段）的界面框，以供用户输入某些特殊信息。 图15所示采购申请PR表头的“弹性域”方框与弹出界面。用户可在其中输入关于该PR的某些自定义补充信息，如“申请部门、申请用途”等等。图16所示采购申请PR表体行的“弹性域”方框与弹出界面。用户可在其中输入关于该PR行的某些自定义补充信息，如关于所申购物料的“长宽高、颜色”等等。要注意的是，上述“自定义表单字段”是“系统级”而非“用户级”的，也就是说只有系统管理员才能做相关设置，而普通用户只能在实际工作中使用。EBS中所使用到的“弹性域”分为两类：一类是所谓“键弹性域”（Key Flexfield），一类是所谓“说明性弹性域”（Descriptive Flexfield）。而上述图15与图16采购申请PR中的“弹性域”就是典型的“说明性弹性域”的范例。系统中几乎所有的重要表单（尤其是业务流程类表单）都具有这种“自定义”功能的说明性弹性域，系统说明性弹性域总数有二、三千之多。称之为“说明性”（Descriptive）取其对标准表单字段作补充说明之意。用户在说明性弹性域中输入的字段信息，通常只能作为统计分析、出报表使用，不参与系统业务流程的构建，系统（应用程序）不对之在表单之间作跟踪、追溯。如下图17所示是采购申请PR表头“说明性弹性域”的系统定义界面： 系统所谓“键弹性域”的情况较之“说明性弹性域”就复杂、严格得多，原因是它们参与业务流程的构建，系统的应用程序要对之进行跟踪、追溯，其作用当然非常“关键”（Key），故数量也比较少，在整个EBS系统中总数不过约35个。其中用得最多的例如“物料类别弹性域”、“会计科目弹性域”等等。与“说明性弹性域”属于表单的用户“补充字段”不同的是，“键弹性域”本身就属于表单的系统标准字段，这个表单标准字段用户输入的不是简单的一个信息，而是具有某种可在系统层面“自定义结构”的一组信息。 如下图18所示采购申请PR表单界面中“物料类别”字段，用户输入时将弹出系统已经定义的“物料类别键弹性域”界面，以供用户（选择）输入具体信息：如下图19所示是系统层面定义“键弹性域”的界面。全部35个键弹性域主要集中在库存、总账、资产、人力资源等核心业务模块中定义，其它模块只是应用时调用。键弹性域由于其系统地位与重要性，其定义方式与内容也要比说明性弹性域来得复杂。对于每一个“键弹性域”，系统允许定义若干个不同结构的字段组合，以使用在系统中的不同场合（例如不同组织或帐套等等）。如下图20所示，表达了“会计科目弹性域”可以有若干不同结构（代码）的情况，图中“Vision China”的5段式结构，可以和其它国家或地区的完全不同。 ORACLE的弹性域应用技术作为系统最重要的基础元素之一，历经多年发展，其应用已远非上述所例举的“表单字段信息”那么简单，它事实上已经发展成为一种重要的方法论。系统基于（键）弹性域的某些重要技术特性，逐步发展出了诸多使用灵活、功能强大的应用实现方式。（相关讨论必须结合具体的系统应用来进行，这里不再赘述）。七、值集与查找代码（Value Set and Lookup Code）日常工作中，用户在表单的字段（包括弹性域字段）中输入数据的方式无外乎两种：一种是直接手工键入，例如订单中的数量（数值）或文字说明（字符）等等；另一种就是所谓“LOV”（List of Value），用户只能从某个预先定义的“来源单据”做选择输入（用户如手工输入，系统可能自动针对来源单据进行校验以确定输入值是否允许）。表单字段的“LOV”输入实际占了系统输入操作的大部分情况，之所以如此的重要原因是业务实践与系统实现的“标准化”需要。例如“人力资源管理部”这个官方正式名称，在人们的日常工作与交流中，可能被简化为“人力资源部、人事部、HR”等等，大家都知道它们是一回事，一般不会引起误解。但对于系统来说就完全不同了，细微的差别在系统中都是两个不同的对象，所以说LOV实际上也是系统实现“数据共享与集成”的基础。表单字段LOV的来源单据值种类，有些可能比较复杂，例如象“物料、供应商、客户”等等，这些字段的值被从来源单据带过来时，系统可能还会带过来其它若干相关重要信息到表单的其它相关字段上去。而有些可能就比较简单，例如属于通用基础数据范畴的“单位UOM、币别Currency以及日期Date”等。还有些虽然也比较简单，但通常需要用户预先做好定义，例如企业的“部门名称列表”等，这些LOV在系统中通常称之为“值集”（Value Set）。在系统中定义一个完整的“值集”需要两个相互独立又相互关联的阶段，首先是定义“值集名”，系统中可以定义若干个不同用途的值集名，对于每一个值集（名），在定义界面可以对其相关属性（如“验证类型：无、独立、从属、表”等）做出相应规定，以使其符合实际工作的需要。如图21所示为“部门名称”的“值集名”定义（或查找）界面：其次，就是为已经定义好的“值集名”赋予具体的值（验证类型为“无”的除外），以组成系统可用的LOV。如下图22所示，其中，有些值之间还可以根据需要定义形成某种“层次结构”，“父子值”之间具有“汇总与被汇总”的关系。验证类型为“从属”或“表”的值集定义比较特殊，前者需先定义所从属的“独立”值集。后者则是将某个系统内的“应用表”作为自己的LOV来源（如“定义供应商”表单维护的供应商名称表），值集定义时，需规定使用哪些表，并定义 WHERE 子句来限制值集要使用的值。使用值集LOV的表单字段的值几乎都有一个共同的特性是，一般不直接参与业务流程的构建，或不直接影响业务流程的运行。然而系统表单的某些字段是需要承担“流程构建”工作的，这些表单字段有些需要手工输入，有些则可能是系统流程运行时自动赋值或在不同流程阶段自动改写（例如，表单状态“未完成、已保存、已批准、已拒绝”等等），有些值在表单中通常“可见”，有些则可能是在特殊情况下才可见。 上述这些表单的特殊字段（域）的LOV，一般是由系统在所谓“查找代码”（Lookup Code）功能中定义的。ORACLE在系统层面于一个统一的界面（Form）中按模块、按引用字段进行全部Lookup Code定义。如图23所示库存相关表单中使用到的物料的“需求类型”定义：Lookup Code系统的定义分为三种情况（访问级别），一种是“系统级”，属于ORACLE预定义且不允许用户添加。这种情况下的“代码值”（Code）基本都属于系统的应用程序中需要引用到的，影响或决定着系统业务流程的运行；二种是“用户级”，属于非系统预定义而由用户自己添加，这种情况下的代码值一般不被应用程序所引用，其作用与前述值集LOV值大体相同；三种是“可扩展级”，属于ORACLE预定义但允许用户添加。这种情况下的系统预定义值与“系统级”的定义值作用基本相同，而用户添加的部分，其作用则与“用户级”基本相同。八、配置文件（Profile）ORACLE的所谓“配置文件”实质上就是人们已经耳熟能详的所谓系统“参数”（不明白当初的中文翻译为何弄得如此奇怪）。ORACLE中的配置文件或参数涉及两个过程：一是配置文件的本身定义（Definition）；二是配置文件的应用设置（Setup）。ORACLE系统的预定义配置文件数量虽达七、八千之多，但这些配置文件对于用户来说都是透明可见的，并不神秘。系统提供“配置文件”定义界面，供用户对配置文件的某些属性（甚至应用程序）进行调整或修改，用户也可以根据自己的需要自定义新的配置文件。如下图24所示配置文件的定义：值得指出的是，系统预定义的“配置文件名”有一定命名规则（适用于大多数配置文件，少数例外），例如“MRP：忽略替代BOM/工艺路线”，前面的MRP是模块代码，代表属于哪个应用模块，后面的部分则是代表具体用途。这种“命名规则”使我们很容易查找到针对不同模块的相关参数。尽管系统预定义配置文件或参数的数量是如此之多，令人生畏，但归纳起来，可以发现按用途大致划分为三类：一类是真正起到控制业务流程运作或事务处理方式的部分，这些参数就如人们通常所津津乐道的所谓“流程开关”；二类实际并不直接控制流程运作或事务处理，只是起到一个向表单上默认某些值的作用（这些默认过去的值，有些参与流程构建，有些仅起参考作用。用户在表单上还是可以修改的）；三类是起到某些特殊控制作用，例如改变系统的某些工作方式、控制UI界面的颜色字体等等，通常与具体业务关系不大。所有参数中前两类占了绝大部分数量（其中第一类又占主要部分），第三类数量很少。而系统应用的难点与重点则是“第一类”、属于“流程开关”那部分参数。 ORACLE系统的配置文件的“设置”（Setup）非常方便灵活，组合起来的应用功能十分强大。系统的配置文件设置具有“结构层次性”，对于某一个具体的配置文件，系统允许最多可以在6个层级进行设置并发挥作用：地点层（系统安装）、应用产品（模块）、责任（自定义的责任）、服务器、组织（包括OU/INV等）、用户（自定义的用户）。具体能在上述6个层级中的哪些层级“可见、可设置”，取决于这些配置文件的原始定义的相关属性。并且实际应用程序访问时，将按照从“地点”逐步到“用户”由低到高的“优先级”顺序发挥作用。如下图25所示配置文件的设置： 最高优先级的“用户层”如果留空不赋值，则系统将默认上一层级（责任层）的值作为自己的值。逐级前移直至最低优先级的“地点层”，通常系统在安装后于“地点层”有初始化的默认值。尽管看起来配置文件数量有七八千，设置工作量巨大，但实际系统实施时，对于大部分企业来说，好在使用系统安装时的默认初始值就能基本符合要求，故也并不十分困难可怕。企业在实际工作过程中遇到问题时，如希望系统能实现某种功能或希望系统流程能按某种方式运行等等情况，则通常首先应该基于系统配置文件的不同设置来寻求合适的解决方案。此外，系统对于配置文件提供了“系统”与“用户”两种“安全性”（权限）的控制功能，前者一般由系统维护人员（如管理员）进行控制，后者普通用户就直接可以作设置修改，例如“UI界面的颜色、字体”等。九、单据编号（Document Sequence） 与手工业务模式下做单据一样，系统中的所有业务流程类表单以及大部分的数据来源类表单，由于业务数据量巨大，当然也需要进行编号管理。ORACLE为此提供了单据的编号控制功能：自动编号、人工编号或无间隙（人工编号必须连续不断号）。单据编号具体包括三个既相互独立又相互关联的三个步骤：一是定义“单据序列”（发生器）；二是定义具体的“单据类别”，三是将“单据序列”分配给“单据类别”。如图26所示为定义“单据序列”（发生器） 如图27所示是定义具体的“单据类别”如图28所示，是将单据序列发生器分配给单据类别，使两者关联值得指出的是，事实上系统中的某些业务流程表单（例如销售订单），系统允许其自定义若干数量的“单据类别”（例如销售订单中的“订单类型”或“事务处理类型”），这些自定义的“单据类别”可以拥有（被分配）各自不同的单据序列号发生器（相当于使用时系统对它们各自独立编号），也可以共同拥有同一个单据单据序列号发生器（相当于使用时系统对它们混合共同编号），这为单据编号的实际使用与管理提供了很大的灵活性与方便性。另外要注意的是，系统中的某些单据如采购申请、采购订单以及供应商等也可以有其专门的编号管理机制，不能一概而论。十、工作流（Workflow）在企业的实际管理工作中，一个员工填写好一份“费用报销单”后，后续可能还需要经过多个环节例如直接主管、上级主管、财务主管的审批，才可能到达会计（入账）、出纳（付款）手中，以完成整个工作过程。把这个工作过程“电子化”后放入系统，就形成一个所谓的“工作流”过程。通常这个报销单“工作流”需要经过哪些环节，是系统需要预先设置好的，并且可能不同的费用类别所需经过的审批环节也是不同的。作为流程的参与者，例如“提交人、审批人”等，可以查询、监控单据的工作流处理过程，系统也可以在流程环节移动过程中，向下一环节的处理人发送提醒通知（如邮件等）。单据的“审批流”实际是一个很简单、很直观的“工作流”应用。推而广之到系统中其它业务流程类表单的事务处理过程，所谓系统的“工作流”技术应用就是：根据不同的业务单据类别，事先定义好需要经过的不同业务处理环节，单据在做事务处理时，按规定顺序在相关环节间移动。用户可监控，即普通用户可以查看工作流的处理过程状态；系统可管理，即系统工作流管理员，必要时可以对单据的工作流过程进行干预，例如跳过某些环节、改变参与人等等。ORACLE系统核心业务模块OM中关于销售订单的处理，就是一个典型的“工作流”技术使用范例。系统根据实际业务处理的需要，先定义好不同的销售订单“行类型”。例如“Ship only”，表示发给客户的这个货物免费、不需开票（例如因为货物质量问题而补发等原因）；“Service”，表示这是向客户提供的无形服务，无需发货，但需根据订单行开票向客户收费等等。再给这些订单“行类型”分配一个合适的系统已经定义好的“行工作流”。如图29所示OM销售订单“行类型行流”分配定义：上述系统用于分配给“行类型”的行工作流，ORACLE提供了预定义的多种不同类别供用户在设置系统时做选择。更进一步，ORACLE还提供“Workflow Builder”软件包工具（这个软件可以到ORACLE官网上自由下载使用），以便用户对于系统所有预定义的流程进行复制修改，或自定义符合使用要求的特殊流程。对于具体的每一个销售订单，同一订单中可能包含不同行类型的订单行，这些订单行将循着各自的“行工作流”而进行事务处理。系统在表单界面的工具栏提供“工作流状态查询”的功能，用户可以随时对订单中的每一个订单行的系统处理过程实施监控、查询。如下图30所示销售订单行的工作流监控功能使用界面：在上图中点击“工作流状态”功能，则系统将打开属于订单行1.1的工作流WEB查询页面。系统提供“活动历史记录”与“状态图”两种主要查询方式，分别如下图31与图32所示。图31表示订单行的活动历史记录，系统从用户输入订单开始，对于后续几乎每一步事务处理操作都做了记录。 图32所示以直观图形方式显示的订单行流程状态。需要指出的是，并非所有业务流程类表单都要采用类似销售订单的“工作流”处理方式，例如“采购订单”的处理等。系统应用模块是否使用、如何使用“工作流”技术，与具体的业务实践以及采用之的优缺点取舍有很大关系，不能一概而论。从系统开发设计的角度来看，尽管“工作流”于技术层面并不难掌握，但要与业务实践实现很好的结合则并非易事。目前国内主流产品基本都宣称具有“工作流”技术，但真正在系统核心业务流程中用得比较好的并不多见，大多只是在“单据审批”或非核心的事务处理型业务诸如“费用报销”等领域中有所应用。 此外，在EBS中有关“单据审批”的工作流应用只是“单据审批”的系统实现方式之一。为满足企业的复杂业务环境的需要，结合工作流技术，系统还专门提供了一个审批功能更为强大且相对独立的引擎模块“审批管理”（AME）作为“外围产品”供企业选择使用。十一、预警（Alert） 今天在企业的办公场所或酒店的房间等很多地方，我们都可以见到天花板上装有“烟感报警器”以及“自动喷淋器”，国家对建筑物的消防安全有明确的法律法规，因此这些“报警或灭火”装置几乎已成了建筑物的标准配置。与之类似，预警平台对于今天的ERP系统来说也几乎是一个标准装备，无论是从系统实现角度还是从业务应用角度来看，它都不是很复杂，比较容易掌握。 ORACLE 的系统预警分两种方式，一是“事件预警”，二是“周期预警”。两者的基本工作方式均是使用SQL Select语句基于对数据库中的相关值作出条件判定，以决定是否执行某种活动（发出信息，执行并发程序、执行操作系统程序、执行SQL语句）。更进一步，对于“发出信息”类预警，系统在收到对此信息的符合规定格式的“回复”后，还可以据此自动执行相关活动并完成相关事务处理。所谓“事件预警”，即当用户在相关数据表中“插入”或“更新”某些值时，系统自动启动已定义的“SQL Select语句”的检查，已确定是否需要发出预警信息或执行某种活动，如下图33所示的一个事件预警定义：在采购管理系统模块中，当出现一个1巨大数量的申请行数量被输入时，系统需要向相关责任人发出预警通知（以提醒诸如做好资源准备等）。 所谓“周期预警”，即系统按照事先定义好的周期间隔或频率，自动启动已定义的“SQL Select语句”针对数据库中表的某些值作检查，已确定是否需要发出预警信息或执行某种活动，如下图34所示的一个周期预警定义：在采购管理系统模块中，系统按每两个工作日的间隔频率对所有“一揽子采购协议BPA”的到期情况进行检查，并将需要关注的检查结果（例如某些BPA将在一周之类过期）通知到相关责任人。 十二、应用开放接口（Open Interface and API） 任何ERP系统都无法做到在任何情况下都能满足企业实际使用的各种要求，企业有时可能需要从其它来源向系统中批量输入数据，如从物料的Excel电子数据表格向EBS的INV系统导入Item信息等等，或者需要与其它第三方应用系统建立业务数据的交换机制，如从专用的“费用报销或发票申付”管理系统向EBS的AP系统导入事务处理数据并将事务处理执行结果反馈回来源系统等等。理论上，使用相关数据库工具可以向数据库的数据表中直接批量写入数据，但这样做无法对写入的数据进行正确性、合规性校验，无法保证写入数据的质量以及对存在问题进行有效管理。为此，ORACLE提供了接口表Interface Table作为“中间表”过渡，并在此基础上，根据某些业务需要提供业务视图Business View，以便对导入的数据进行修改、更正、重新导入等等管理。如下图35所示“Open Interface Diagram”：更进一步，ORACLE将某些数据的导入导出功能进行封装，成为一个应用程序可以调用的接口（API），以实现在各模块之间以及内部模块与外部系统之间的数据与流程集成。如下图36所示“Open Application Programmatic Interface（API）Diagram”：开放接口（API）的基本工作模式分为两个阶段：一是先将来源数据装入（Load）接口表。如果是在两个应用系统之间，这通常是由专用的装入程序完成，例如EBS内部采购申请要转成内部销售订单，需先运行“创建内部销售订单流程”，以便将内部采购申请发送并插入订单管理系统的接口表。如果是从某些电子表格如EXCEL等导入，则需要先使用专门的SQL*Load工具将数据格式转换后直接插入相关接口表，例如要通过物料的EXCEL数据表直接批量装入Item数据，必须先通过SQL*Load工具如DataLoad等将来源数据插入Item数据接口表。在将数据插入接口表的过程中是否对数据进行校验（或是在将接口表数据导入正是表时再校验），取决于系统各应用模块的不同设计；二是系统将存在于接口表中的数据导入正式的业务数据表，如EBS订单管理模块的“订单导入”，库存管理模块的“导入Item”等等。在从接口表导入“正式表” 或数据装入“接口表”过程中因数据校验而产生的错误或失败信息，如系统提供专门的业务管理视图，则可以在其中进行查看、更正、重新提交，如EBS的“订单导入更正”窗口等。如系统未提供管理视图，则可以在并发程序请求的“输出”文件中查看结果。下图37所示“应付款管理模块费用报表类发票导入流程图”是一个典型的应用过程示例：十三、结语我们经常见到有些国内产品在宣传中，总是喜欢嘲讽国外产品如SAP已经是“老古董”，刻意强调自己的技术是如何先进、平台是如何创新等等这些于企业应用实践其实相距甚远、华而不实的东西，而在产品研发过程中，却忽略了于企业信息化实践更为重要的基本元素与应用基础的研究。这就好比卖房子的开发商总是卖弄自己造房子的钢筋质量是如何好、水泥标号是如何高、施工所用的机械设备都是进口的等等，问题是这些与买房人真正所关心、所需要的“户型结构、空间适用以及小区配套”等又有多大关系呢？技术的进步无疑会对企业管理实践中的组织形态、业务模式等诸多方面产生重大影响，管理作为一门“科学”而诞生的这近一百年来，企业管理实践从早期的“职能管理”到现代的“流程管理”，从早期主要内向关注“生产效率”到现代重点外向关注“客户需求”，技术的进步尤其是近二十年来信息技术的飞速发展起到了重要的推动作用。但管理科学毕竟是属于“形而上”的范畴，相较于“形而下”的器物层面，技术进步的作用与影响方式总是承前继后、继往开来而非颠覆性的。回顾SAP R3或ORACLE EBS过往十多年的发展历史与演化进程，我们可以发现，系统开发设计人员于早期阶段就融入软件的那些于企业核心业务运作所至关重要的管理思想、业务模式等核心内容并未过时，它们今天依然是支撑企业高效运作的核心与基础，并且它们也在随着时代的发展而与时俱进、不断得到充实与完善。管理软件从三十年前的主机时代，到二十年前C/S架构的客户机/服务器时代，再到十年前开启的B/S架构的互联网时代，软件具体技术的发展较之于信息技术整体进步对企业管理实践的影响，总的来说还是局部的、非决定性的。今天大概不会再有人相信“管理软件从C/S架构进化到B/S架构是企业管理实践的一场革命”这样的夸大其辞，遑论更为等而下之的诸如.NET平台、Java平台、私有的ABAP平台等等这些纯技术领域的开发工具对于管理软件中所蕴含的管理思想、业务流程模式能有多大影响。喜欢看美剧的人或许经常可以在片中看到美国纽约于上世纪三十年代初期所建造的两座美轮美奂的标志性大厦：克莱斯勒大厦（77层）和帝国大厦（102层）。八十年前的技术条件与工具手段和今天简直没法比，但我们今天能说它们已经落后、不是“现代化”的大厦吗？有谁知道克莱斯勒大厦还是世界现存最高的“砖体”建筑呢！ 人类的认识总是从已知的东西逐步推展到未知的领域。如果我们暂且抛开系统具体的业务流程、功能应用以及操作细节不谈，仅针对前述ORACLE EBS系统的11个基本组成元素，从实践来源与系统实现两方面，作并非详细深入但比较直观概要的探讨，我们也许就能获得这样一个总体上的认识，即无论多么庞大、复杂的一个软件应用产品体系，它仍然是由一些使用比较简单、理解并不深奥的基本构件所组成。这些基本构件来源于业务实践或与日常工作息息相关，我们其实并不陌生，它们是“从业务到技术，再从技术回到业务”两者高度融合的结晶体，也是神妙莫测、不可捉摸的代码空间通往纷繁复杂、多姿多彩的真实世界的桥梁。大多数情况下，对于普通的EBS系统用户而言，结合自身的业务，掌握了上述十多个基本元素中前几个，例如表单、查询、事务处理、文件夹以及报表类并发请求等，就足以可应付一般的日常工作；而对于系统实施、维护人员来说，相对而言后几个技术味较浓的基本元素，诸如并发处理、弹性域、配置文件、工作流等则可能是工作的重点与难点。但需