系列之三：ORACLE-EBS-系统应用基础概述(B)

系列之三：ORACLEEBS系统应用基础概述（B）OracleERP2023-08-0916:23:59阅读133评论0

字号：大中小订阅ORACLEEBS系统应用基础概述三、事务处理（Transaction）四、并发流程（CurrentProcess）五、文件夹（Folder）六、弹性域（Flexfield）七、值集与查找代码（ValueSetandLookupCode）八、配置文件（Profile）九、单据编号（DocumentSequence）十、工作流（Workflow）十一、预警（Alert）十二、应用开放接口（OpenInterfaceandAPI）十三、结语（注：网站批量发图有问题，上传后显示不清楚。点击图片打开后，质量尚可）三、事务处理（Transaction）如果说上述EBS的“表单与查询”的系统设计体现的正是“从业务到技术”，比较容易理解与掌握，那么，所谓“事务处理”则是体现系统“从技术再到业务”的一个典范，相对而言，理解起来要困难很多，原因是无法直接在手工业务模式下找到相对应的处理方式与过程。以库房接收采购物料为例，假定公司规定必须严格按PO来接收，并且公司为了严格控制库存水平，接收必须小批量、多批次，则库房人员就可能需要针对同一个PO在短时期内开出N多张的“入库单”，工作量很大。为了减少工作量、提高效率，库房人员可能会在供应商每次送货时，仅在找出来的PO纸面单据上只简单地做一个数量标识，最后累积起来汇总开一张“入库单”。但这种“图省事”的做法显然是一种“很不规范”的处理方式，虽可以提高工作效率，却会因为容易带来很多其它管理问题而在实际工作中不被允许。ORACLE系统通过提供一个“事务处理”工作界面则很简单地解决了上述难题。如下图9所示采购接收的事务处理工作界面：类似于“收货时直接在PO纸面单据上简单地做数量标识”，每次供应商送货来时，库存人员只需在系统中查找出对应的PO，简单地输入送货数量并保存，则系统会在后台自动生成“事务处理记录”(等同于是“入库单”)。对于系统来说，这种处理方式技术上实现非常容易，但却大大减少了操作人员的工作量，有效地解决了由于小批量、多批次所带来的效率问题。ORACLE的各业务模块，大量地采用了上述类似的“事务处理”系统工作方式，不仅保证了系统高度的数据集成性，而且对于系统各业务环节的流程处理也保证了高度的连贯性与集成性。例如OM系统的发货处理、WIP系统的领料与入库处理等等。系统中所提供的事务处理工作界面，有些可能会以“××工作台”（Workbench）来命名之（这取决于不同模块系统设计人员的个人偏好）。更进一步，系统对于某些“业务流程”类表单，例如“销售订单、发票”等，还在表单界面直接提供一个名曰“活动”（Action）的按钮（Button），该按钮包含丰富的业务处理功能（不仅仅是输入数据），以便用户（User）对表单内容作各种操作处理或获取相关信息。如下图10所示，销售订单界面的“活动”按钮：此外，ORACLEEBS在某些业务流程单据之间，也提供了类似的事务处理工作界面，以帮助用户方便地实现业务单据的转换和业务流程的衔接。如下图11所示的采购申请PR到采购订单PO的所谓“自动创建”（Autocreate）功能。对于企业的一个系统用户User（事务处理型用户）来说，掌握了与自己工作相关的表单、表单查询、事务处理，就基本上掌握了EBS的系统使用，系统就不再难懂难用。EBS中的“事务处理”在业务流程表单内部解决了“人与系统”的统一问题，在业务流程表单之间解决了“业务与业务、业务与系统”的统一问题。从“纯技术”的系统实现角度来看，它也没有什么高深莫测的地方。很奇怪也很遗憾的是，迄今国内主流ERP产品的系统中，还很少看到这种系统实现方式。曾有一网友通过MSN向笔者发问：“EBS的WIP事务处理界面是否要手工输入item？”看起来这个问题似乎很“幼稚”，但对于很多刚开始接触EBS或过去用惯国内产品的人来说，由于不了解或不习惯EBS的“事务处理”系统实现方式，会不自觉、想当然地将所有EBS的FORM界面都当成具有“实体”作用、通常可以对应纸面单据的“业务表单”来看待，才会发出这样的疑问。四、并发流程（CurrentProcess）从系统实现角度来看，“并发流程”或“并发处理”是较之“事务处理”技术味更浓的一个概念，它也是业务出身、不太懂“技术”的人学习掌握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系统大量使用后台“并发处理”程序，实现了系统用户的流程操作在“空间与时间”上的分离，免去了操作人员的无效等待时间。操作人员提交的并发请求在后台运行的同时，并不影响其处理其它系统事务，这样可以大大提高用户的工作效率以及使用的方便性。“并发”之于ORACLEEBS系统好比人体内的“心脏”一样重要，它是系统实现高度的数据集成与流程集成的核心工具，是企业依赖计算机系统实现业务运作与管理控制自动化的一个技术体现。五、文件夹（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中所使用到的“弹性域”分为两类：一类是所谓“键弹性域”（KeyFlexfield），一类是所谓“说明性弹性域”（DescriptiveFlexfield）。而上述图15与图16采购申请PR中的“弹性域”就是典型的“说明性弹性域”的范例。系统中几乎所有的重要表单（尤其是业务流程类表单）都具有这种“自定义”功能的说明性弹性域，系统说明性弹性域总数有二、三千之多。称之为“说明性”（Descriptive）取其对标准表单字段作补充说明之意。用户在说明性弹性域中输入的字段信息，通常只能作为统计分析、出报表使用，不参与系统业务流程的构建，系统（应用程序）不对之在表单之间作跟踪、追溯。如下图17所示是采购申请PR表头“说明性弹性域”的系统定义界面：系统所谓“键弹性域”的情况较之“说明性弹性域”就复杂、严格得多，原因是它们参与业务流程的构建，系统的应用程序要对之进行跟踪、追溯，其作用当然非常“关键”（Key），故数量也比较少，