系列之三ORACLEEBS系统应用基础概述（C）..docVIP

系列之三：ORACLE EBS系统应用基础概述（C） 热度 7已有 1171 次阅读 2009/11/10 21:45 |关键词:EBS ORACLE 系统 基础 概述 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）；二是配置文件的应用设置