系列之四：ORACLE-EBS-基础设置要点简介(D).doc

word完整版)系列之四：ORACLE EBS 基础设置要点简介(D)
系列之四：ORACLE EBS 基础设置要点简介(D)
热度 2已有 1015 次阅读 2009/11/27 11：18 ｜关键词:EBS基础设置要点简介
ORACLE EBS 基础设置要点简介

五、基础数据
（一)关于“日历"
（二)关于“币种”
（三）关于“汇率”
（四)关于“单位”
(五)关于“地点"
六、并发管理
七、工作流
八、系统初始化设置
（一)关于安全性.
(二）关于配置文件
（三）值集与弹性域
（四）分类账（帐套）与组织架构
（五）单据编号
（六）层次性设置结构

九、结语

（注:网站批量发图有问题,上传后显示不清楚。点击图片打开后，质量尚可。
五、基础数据
基础数据通常是指与具体业务关系不大且具有全局性、基础性的一些基本数据，例如日历Calendar、币种Currency、汇率Rate、单位UOM、地点Location等等。这些基础数据的系统设置有些比较简单如“币种”，有些与真实世界的情况相似如“日历”,有些则可能比较抽象复杂如“地点”等等，情况多种多样。以下择其要者，作简要说明。
（一）关于“日历”。EBS中的日历设置，实际包括两大类，一类是与会计工作相关的，包括“会计日历”、“会计事务处理日历”等，它们的使用范围较小，有专门用途一般是在总账模块设置（这里不赘述）.一类是工作日日历，它与企业的日常业务工作相关，使用范围广泛，大多数涉及库存组织的业务模块都可能与之相关，如下图35所示：

需要注意的是，在新设置工作日日历或更新已存在工作日日历后,需要通过在工具栏的“建立"功能启动一个后台并发程序,以最终完成设置工作。
（二）关于“币种”。各国或地区的“货币”是一种客观存在,EBS系统已经预置几乎所有企业可能使用到的币种，必要时还可以添加.用户可以决定哪些币种需要启用，以及维护其使用时的“精确度”。如下图36所示：

（三）关于“汇率”。企业对于不同币种汇率转换的管理是一项重要的基础性工作,它对企业的经营结果有重要影响.为方便该项工作的开展，EBS系统专门提供了一个名为“币种管理器”的工具,如下图37所示：

企业可以根据工作需要设定多个“汇率类型”（系统初始预置了Corporate值），并为之维护“每日汇率”或基于帐套的“期间汇率"。汇率的维护可以按一段时间范围来进行，也可以通过外部的“电子表格”导入数据。
(四)关于“单位”.计量单位虽然也可以看作是一种客观存在，但单位与基本单位之间的转换关系，则可能是与具体物料相关的（例如鸡蛋1斤=15个,鸭蛋1斤=10个等，转换系数不同)。由于EBS的物料是定义在库存组织INV上的，故单位及转换关系也是基于INV设置的。如下图38所示：

EBS的单位转换，提供了不考虑具体物料的“标准转换”,例如1米=100厘米等,也提供了基于不同物料的在同一“单位分类”（如长度、重量、体积等）内部的转换,例如牛奶 1箱=20盒，茶叶 1箱=10盒等；以及不同物料在不同“单位分类"之间的转换，例如牛奶 1公斤=4盒，茶叶 1公斤=2盒等。
（五）关于“地点”。EBS中所谓“地点”的概念不仅非常抽象，而且十分重要，因为系统相关业务处理功能如“接收、发运、人员分配”等等都与“地点”密切相关.EBS中的所谓“地点"原意实际上涉及三个词：Location、Address、Site。译成中文都可称“地点”，也是导致其理解困难的重要原因之一。如下图39所示：

Address（地址）比较好理解，它表示一个地理坐标概念，例如“北京市朝阳区安定路甲3号”等，EBS系统以一个“说明性弹性域"来精确描述,非常方便.各个国家的Address表述方式可能不同（如中国与美国有差别)，故系统有所谓“中国式地址"、“美国式地址”之分等等。
Location(地点）的系统涵义则理解比较抽象，系统定义的名称可以看作是与一个具体Address相关联的一个或多个不同“称谓代号"，例如与上述Address“北京市朝阳区安定路甲3号”关联的Location“鸟巢、国家体育场、奥林匹克公园、奥运主会场"等等。也可以是一个不与具体地址Address相关联但大家都明白的称谓代号，例如Location“天安门、首都机场”等等。
EBS系统最初使用比较“简短”的Location代替比较“冗长”的Address,仅仅是为了方便IT“标准化”处理的需要。但在以后的发展过程中，系统设计逐步赋予Location更多与业务处理功能相关的“属性”，为了区分这些不同属性，系统以Site(站点）来加以区分，如图39中所示，一个Location可以具有“发运到Ship—to”、“接收至Receiving”、“开票到Bill-to"、“内部Internal”等等不同系统功用。
更进一步，EBS系统使用“地点"来实现采购申请、接收、运输清单和人员的分配，以及确定内部组织与内部客户、供应商的关联关系；使用同一供应商的不同Site来区分定义供应商所具有的不同“业务控制”属性；使用同一客户所具有的不同Location—Site组合来区分定义客户所具有的不同业务功能（OM的某些业务功能必须将客户的外部Address—Location组合与系统内部Location关联方才有效）等等；详情以后相关模块再进一步讨论.
总之，搞清楚EBS系统Address、Location、Site的三者关系,对于理解掌握系统功能十分重要，其核心与关键是不能将比较抽象的Location或Site与比较具体的Address等量齐观,两者虽有一定关系,但Location或Site更多地是从系统实现的需要出发，而做的某种“形而上”表达.

六、并发管理
ORACLE EBS系统在后台通过运行大量“并发处理程序”的方式保证相关业务功能的实现，系统需要对这些在后台运行的“并发程序”进行有效管理，这是通过所谓“并发管理器”来实现的。系统后台可以有多个不同的“并发管理器”来管理不同的并发程序，“并发管理器”本身实际上也是并发程序，对于这些多个“并发管理器”，系统也要通过“管理并发管理器”功能进行有效管理。
系统内存在的所谓“并发管理器”按功用划分主要有三大类:内部监控程序、并发管理器、事务处理管理器.“内部监控程序”类型的管理器的功用是“监测处于并行并发处理环境下的内部并发管理器”并发管理器"类型的管理器的功用是“启动运行并发程序"；“ 事务处理管理器”类型的管理器的功用是“处理客户端用户发出的同步请求”。
系统在初始安装后，已经预置有若干不同类型的20多个管理器，系统也允许用户根据特殊需要自定义新的管理器。以下重点介绍几个重要的预置管理器的有关内容：
内部管理器。它充当所有其它管理器的“上层管理器"。内部管理器可以对单个管理器进行启动、验证其状态、重置以及关闭等操作。用户不能改变其定义（工作班次、特殊规则）。如下图40所示：

标准管理器。标准管理器可接受任何请求，它无特别的规定。标准管理器始终处于活动状态,即一年 365 天，一天 24 小时全天候工作。标准管理器可作为安全网使用，因为它始终可用于运行任何请求.其定义一般不可轻易更改，否则可能导致某些程序无法正常运行。如下图41所示：

事务处理管理器。常规并发管理器只允许“异步”执行运行时间长、数据密集的应用程序，而事务处理管理器则也支持“同步”处理客户机端发出的特定请求（并发程序请求运行计划的“立即”执行选项，本质上仍属于“异步"方式）。如果客户机程序发出同步运行服务器端程序的请求，则事务处理管理器会立即运行此请求，然后将状态返回至此客户机程序.事务处理管理器会等待由客户机程序发送信号，而不会轮询并发请求表来确定该如何执行操作。如下图42所示：

事务处理管理器（系统内部使用,“同步方式”）管理包括“物料事务处理、移动事务处理、资源成本事务处理、物料成本事务处理"的系统“联机”处理。系统在用户等待时“同步”作相关事务处理的处理,并且在完成后才将系统控制返回给用户。这在业务量较大、系统繁忙时，用户等待的时间可能较长，影响用户的工作效率。
事务处理管理器（请求使用,异步方式），如果相关配置文件“TP：INV 事务处理处理模式”设置为“并发”或“后台”模式，则用户应当启动“物料事务处理、移动事务处理、资源成本事务处理、物料成本事务处理”管理器于适当的“周期”运行状态。通常在事务处理工作量比较大时，应采取这种方式，以节省在库存管理系统锁定事务处理窗口和处理事务处理时所花费的空闲时间，提高用户的工作效率.
由于“事务处理”在整个EBS系统运行中的普遍性与重要性，系统为此提供了一个专门的界面功能(菜单项,非系统管理员也可授权使用）以满足对相关“事务处理”并发程序的管理监控（“启动管理器"的工作方式与提交“请求"类似)，如下图43所示：

上述“事务处理管理器”所管理的事务处理并发程序（成本管理器等),每个系统只运行一个“实体”，为所有组织、用户服务，故系统设置必须对其运行方式进行恰当的“计划”。与之类似的重要系统事务处理并发程序还有“计划管理器”（受“MRP管理器”管理）,“接收事务处理处理器”（受“接收事务处理管理器”管理）。
要注意的是，系统许多业务流程类的事务处理“并发程序” 由于承担的后台任务比较复杂，实际起着某种业务流程运作的管理作用,故习惯上也以“××管理器、××处理器”来命名,例如“计划管理器（控制计划系统有关预测冲减、需求冲减等等事项的自动程序，)、成本管理器(控制数据的自动计算与更新等等事项的自动程序）、接收事务处理处理器(控制PO接收的库存更新等事项的自动程序）”等等,不能与上一层的管理这些并发程序的所谓“并发管理器"相混淆。
“并发管理器"定义时需要用到的“工作班次”（系统初始已经预置值Standard），需要预先设置以作为LOV，工作班次可以同时运行的“流程数”在定义并发管理器时应设置适当值。如下图44所示：

“并发管理器”定义时需用到的“特殊规则”(系统初始无预置值)，可直接输入“包括或排除”类型为“程序、请求类型、用户、ORACLE标识"的具体条目组合.这些条目的组合也可以事先定义为各种“组合规则”，供定义“并发管理器”时作为LOV调用。如下图45所示：

有关“并发程序”的运行计划及其“并发管理器"的定义工作，应当考虑系统的负载均衡,以保证系统的性能与运行效率。对于系统运行的所有“并发管理器”，系统管理员可以在“管理并发管理器"窗口进行干预、管理，如“终止、重新启动”，以及查看“并发管理器”正在管理的“哪些程序”正在运行等等。如下图46所示：

企业在系统使用过程中，基于业务变化发展得需要，不断地自定义开发各种“报表类"并发程序是一项重要的日常工作。这些自定义报表并发程序的系统管理方式没有什么特殊性,它可以使用系统预置的“并发管理器”进行管理,也可以自定义新的“并发管理器”。
对于EBS系统中处于各种运行状态的并发程序,系统管理员可以在“请求”窗口，通过设定不同查询选项(如特定请求之状态、阶段等等），查询监控相关“并发程序”的进程状况，并根据实际情况作出处理(如暂挂、重启、取消、诊断等等)。如下图47所示: