肾阴虚泡什么喝:系列之三：ORACLE EBS系统应用基础概述（C） - season的日志 - 网易博客

系列之三：ORACLE EBS系统应用基础概述（C）

Oracle ERP 2010-08-09 16:29:14 阅读7 评论0   字号：大中小 订阅

ORACLE EBS 系统应用基础概述

 七、值集与查找代码（Value Set and Lookup Code）

 八、配置文件（Profile）

 九、单据编号（Document Sequence）

 十、工作流（Workflow）

 十一、预警（Alert）

 十二、应用开放接口（Open Interface and API）

 十三、结语

七、值集与查找代码（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所示以直观图形方式显示的订单行流程状态。

需要指出的是，并非所有业务流程类表单都要采用类似销售订单的“工作流”处理方式，例如“采购订单”的处理等。系统应用模块是否使用、如何使用“工作流”技术，与具体的业务实践以及采用之的优缺点取舍有很大关系，不能一概而论。从系统开发设计的角度来看，尽管“工作流”于技术层面并不难掌握，但要与业务实践实现很好的结合则并非易事。目前国内主流产品基本都宣称具有“工作流”技术，但真正在系统核心业务流程中用得比较好的并不多见，大多只是在“单据审批”或非核心的事务处理型业务诸如“费用报销”等领域中有所应用。