ORACLE_EBS_系统设计应用基础概述

系列之三：
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也类似）。

有网友针对国某些厂商声称自己。