系列之四：ORACLE EBS基础设置要点简介（E）
热度 7已有 1006 次阅读2009/12/23 10:27|关键词:EBS基础设置要点简介ORACLE EBS 基础设置要点简介
七、⼯作流
⼋、系统初始化设置（⼀）关于安全性。（⼆）关于配置⽂件（三）值集与弹性域
（四）分类账（帐套）与组织架构（五）单据编号（六）层次性设置结构九、结语
（注：⽹站批量发图有问题，上传后显⽰不清楚。点击图⽚打开后，质量尚可。七、⼯作流
系统关于⼯作流的设置⼯作包含两部分⼯作，⼀是基于企业的特殊需要，使⽤Workflow Builder软件包⼯具⾃定义⼯作流。详情需参考ORACLE的相关⽂档，这⾥不赘述。⼆是为系统设置⼯作流管理员。系统在安装后的初始化⼯作流管理员是系统超级⽤户SYSADMIN，企业应当⾸先使⽤SYSADMIN进⼊系统，将⼯作流管理员改为⼀个真实的⽤户，或者输⼊“*”，则所有⽤户都“可以”具有⼯作流管理员权限（⽤户实际是否有⼯作流管理权限还必须取决于其被赋予的“责任”或“菜单”功能），如下图48所⽰：
查询出系统所有的“⼯作流类型”，可选择其⼀作具体设置，如下图49所⽰：
的“属性”设置界⾯（具体有哪些属性可设置，不同⼯作流各不相同），如下图50所⽰：
⼯作流管理员在⼯作流管理“状态监控程序”TAB页，可以监控选定⼯作流的具体运⾏情况的若⼲条⽬列表，针对每⼀个条⽬，可以查看其“活动历史记录、状态图、参与者回应、详细资料”等若⼲信息（必要时⼯作流管理员可实施⼲预，如更新属性、倒退、暂停、取消等等）。如下图51所⽰：
系统在各应⽤模块基于业务处理功能，预置有若⼲不同⼯作流，有关详情容以后结合具体业务模块应⽤再来讨论。以下重点介绍⼀个⽐较特殊的⼯作流：在多个业务模块中均需使⽤且系统实施必须事先完善设置的“账户⽣成器流程”。
传统的⼿⼯业务模式下，所有可能涉及会计记账处理的业务处理例如物料接收、发出等等，作为业务处理⼈员在⽇常⼯作过程中是不需要考虑如何记账的，只是需要将有关业务处理记录例如⼊库单、出库单等作为原始凭证提交给会计⼈员去做处理。会计⼈员依据这些原始凭证制作“记账凭证”并⼿⼯为之指定“会计科⽬”或“账户代码”，以便正确地向总账GL实施“过账”。
⼿⼯业务模式或会计电算化模式下，由于作为原始凭证的业务单据不包含准确的记账信息（会计科⽬或账户代码），需要会计⼈员⼿⼯去做处理，这在业务量很⼤，记账科⽬数量设置较多的情况下，会计⼈员的⼯作负担将⼗分繁重。再考虑⼈⼯处理难免有疏漏，可能需要反复“对账”，每⽉⽉底必须及时结账关账、时间紧迫等等因素，故⾮⼈⼯的、⾼度准确的“会计分录（⽇记账）”⾃动⽣成功能（即所谓“⾃动会计”）是系统设计时必须考虑
解决的重要问题。
在EBS系统中，账户代码被扩展为⼀个包含多个段组合的会计科⽬弹性域结构，系统在业务流程类表单例如采购订单、发票等做业务处理时，依赖所谓“账户⽣成器流程”根据业务处理的⾃⾝属性，⾃动⽣成准确的帐户代码组合并记录于业务表单的相关字段中，如下图52所⽰采购申请界⾯每个申请⾏（分配）所对应的“会计账户”（弹性域结构）：
系统周期或⼈⼯启动向总账GL的“过账”流程，对符合条件的“事务处理”成批⽣成会计分录（⽇记账，是否还需复核审批视乎企业规定），⼀般来说⽆需再做繁琐的“对账”⼯作。这就⼤⼤减轻了会计⼈员的⼯作负担，记账科⽬数量的多少⼀般也不再成为障碍。（⼿⼯或电算化模式下，会计⼈员往往不愿意设置某些过渡性的“中间科⽬”，例如物料接收的“应计负债”等等，这对于会计⼯作的准确性有不⼩的影响）
ORACLE系统基于每个新定义的分类帐（帐套）⾃动⽣成所需的“账户⽣成器”，系统预置有14个账户⽣成器（⼯作流类型），对于每个“账户⽣成器”
可以根据需要设置不同的“流程”（每个⼯作流类型有其LOV值，还可以使⽤Workflow Builder⾃定义添加），如下图53所⽰：
“账户⽣成器流程”是基于“会计科⽬弹性域结构”来设置的，弹性域结构不同，流程设置可以不同。对于每个“账户⽣成
器”，ORACLE都提供了默认的流程供使⽤。R11的账户⽣成器⽣成的账户代码被直接⽤之于向总账GL传送，⽽R12由于存在“多账簿”的不同“会计⽅法”因素，各⼦分类帐产品（业务模块）基于事务处理会计科⽬弹性域结构通过账户⽣成器⽽⽣成的帐户代码，在向总账GL传送时，还需结合“会计⽅法”中的“账户推导规则”等设置，才能在总账GL⽣成正确的会计分录（⽇记账）。
⼋、系统初始化设置（⼀）关于安全性。
⼀个全新安装的EBSR12系统（Fresh Database），以SYSADMIN⽤户名登录，密码为sysadmin（注意EBS密码区分⼤⼩写），Home Page 可见系统所初始预
置的10多个“责任”中包含“系统管理员”（System Administrator），如下图54所⽰：
进⼊系统的GUI界⾯后，在“⽤户”定义界⾯，可查询到有30多个初始化的User，⽐较特殊与重要的User 是两个“SYSADMIN、GUEST”，GUEST⽆密码设置，可以作为测试时的特殊⽤户使⽤。如下图55所⽰：
其中有些User是系统残留，并不可⽤，还有些是只有⽤户名，但并未为之分配责任。注意，上图初始的GUI界⾯默认配⾊⽅案，为演⽰⽅便已通过配置⽂件“Java color scheme”做调整。
系统初始预置的“责任”有1500多个，范围涉及所有模块的⼏乎所有“岗位⾓⾊”，企业可基于⾃⾝的管理习惯制定相应的责任“命名规则”，以定义新的“责任”。如下图56所⽰：
系统初始预置的“菜单”有12000多个，基本上覆盖了⼏乎所有可能应⽤的需要，如企业需要“个性化”的菜单显⽰效果（prompt），则可以⾃定义⽤户菜单，形成特定的菜单结构。如下图57所⽰：
本⽂为测试需要，在系统中建⽴⽤户名MFG，并将常⽤模块的超级⽤户责任均与之关联。为测试⽅便，建⼀包含所有常⽤超级⽤户菜单的总菜单，并以此建⼀超级总责任，也与⽤户MFG关联。（⼆）关于配置⽂件
系统配置⽂件总数有6600多个，绝⼤多数有初始化的默认值，可以有需要时再来修改，有关系统配置⽂件的设置情况（初始化时尤其可能希望了解），可以使⽤⼯具栏“File—Export”将它们全部导出，以⽅便的格式如EXCEL集中查看，如下图58所⽰：
有些必须设置且没有默认值的配置⽂件，例如“GL Ledger Name ”、“MO：Operating Unit”等，由于其LOV取决于系统的其它具体设置如分类账（帐套）、业务实体
OU等，故这些特殊的配置⽂件初始进⼊时会报错，如下图59所⽰：
这些少数的特殊配置⽂件是系统初始化参数配置是的重点与难点，在完成相关会计科⽬弹性域结构、分类账、组织架构等等设置后，应及时为这些特殊“配置⽂件”赋值。（三）值集与弹性域
EBS系统初始预置有16000多个值集名（Value Set Name，包括近2000个“验证”类型为“⽆”、⽆需LOV的特殊值集名），基本上都属于系统各表单所使⽤LOV的值集，有着特定的⽤途，这些值集也可以根据需要修改添加新的条⽬⾏。如下图60所⽰。⽽对于系统键弹性域与说明性弹性域所使⽤到的值集，则需要根据企业具体情况，进⾏完善的定义设置（尤其是38个键弹性域所需使⽤的值集）。
关于键弹性域的设置，除了使⽤范围⼴泛的Item类别弹性域（Item Categories），系统已经预置有20个不同结构表⽰其在不同场合的多个应⽤之外（还可根据需
要添加结构，系统预置的结构也可以进⾏更改，如下图61所⽰：）
其它键弹性域如“会计科⽬弹性域”基本只有⼀个结构名称范例，并⽆具体的结构设置，需要企业根据⾃⼰的情况来完成设置。所有的说明性弹性域均⽆预置结构，均需根据需要从值集开始设置。
弹性域结构的段也可以不选择值集⽽留空，则此时，此段就好象使⽤了这样⼀个值集：验证类型为“⽆”，格式类型为“字符”，宽度与基础键弹性域段列相同（即与弹性域系统设计所允许的段最⼤字符长度相同），允许混合⼤⼩写字母字符，⽆右对齐或填零。对于基础列不是“字符”列的任何段，则必须使⽤值集，否则将不能够编译弹性域。但需注意，“会计科⽬弹性域”必需使⽤值集。
已经定义并编译好的弹性域结构（键或说明性），在使⽤时均会打开弹出式窗⼝，以便逐段输⼊数据。但这样输⼊对于⼀些常⽤到的“代码组合”，既不⽅便记忆，也不⽅便输⼊，为此，ORACLE为定义的每⼀弹性域结构的代码组合提供了“别名”（Aliases）定义的功能。例如，实际⼯作使⽤得⽐较多的“账户代码”的“账户别名”就是⼀个典型。其它弹性域结构是否需要使⽤“别名”，取决于实际业务需要。（四）分类账（帐套）与组织架构
这是系统初始化设置最复杂的⼯作。R12较之R11，由于引⼊了“会计⽅法”的新维度，在设置⽅法与顺序⽅⾯有较⼤的变化，其过程也更为复杂。R12的法⼈实体LE的设置与R11相⽐也有很⼤变化，只能在“会计科⽬管理器”中设置，原在GUI组织设置界⾯的LE设置的值不再有效（即使设定也⽆法分配给分类账）。有关多组织、多账簿的接⼊功能还需与“安全性配置⽂件（Security Profile）、数据访问权限集（Data Access Set）”的定义，配置⽂件“BG：安全配置⽂件、MO：安全配置⽂件、GL：数据访问权限集”等等参数的设置进⾏协调配合，包括运⾏“转换为多组织体系结构（仅R11，在AD Utility ⼯具中执⾏；R12安装已经是多组织结构）”以及为新添OU“复制系统初始数据”（在“系统管理员”责任下，运⾏“Replicate Seed Data”请求）公⽤程序等等。有关详情，限于篇幅，这⾥不再赘述。（五）单据编号
新安装的EBS系统初始并未定义单据编号发⽣器，需要全新定义，如下图62所⽰：
需要指出的是，这⾥的“单据编号”仅是“系统内部”使⽤的标识，都是不包含任何业务管理信息的数字代码。某些特殊单据如采购申请、采购订单以及供应商等虽具有⾃⼰专门的编号管理机制，其所⽣成的也是不包含业务信息的数字代码。这些数字代码和实际业务管理中所需使⽤到的“业务标识”可能有⼀定区别，例如对于采购订单、供应商，基于管理的某些特殊需要，除了系统⾃动⽣成（或⼿⼯输⼊）的单据代码标识外，可能还需使⽤单据头的“说明性弹性域”⽣成包含“采购员代码、业务类别代码、⾏业代码、地域代码”等等管理信息的“业务标识”（可能需要打印在纸⾯单据上），以⽅便相关业务信息的统计分析⼯作。（属于GL/AP/AR），系统初始预置有若⼲数量的“单据类别（Document Categories）”
每个单据类别对应数据库中的某个表（Table）。可以根据需要为相关业务模块如INV/PO/OM等等的某些表（Table，是否允
许取决于Table本⾝的设计）添加“单据类别”，以便对表中的相关字段应⽤编号机制。未来在完成系统设置过程中，还会基于某些表单的业务类别设置（例如销售订单类别等）⾃动⽣成新的单据类别。如下图63所⽰：
单据类别与单据编号发⽣器的关联分配是基于分类账（帐套）的，故在每次新定义分类账或帐套后，均需完成有关的单据编号“分配”⼯作。（六）层次性设置结构
不涉及具体应⽤模块或具全局性、属于EBS系统层⾯的初始化设置，还包括⼯作流、预警、⽂件夹、配置⽂件定义、查找代码定义、消息定义、地区维护、打印机等等⼀系列内容，限于篇幅，这⾥不再赘述。下图64所⽰表达了EBS（R11）全系统公共层⾯的基础设置内容与层次结构：Common Applications ProcessHierarchy
EBS核⼼系统习惯上可以划分为四⼤分⽀系统：财务、制造、分销、⼈⼒资源。每⼀⼤分⽀系统也有相关的公⽤层⾯设置，如下图65所⽰是EBS（R11）公共“分销系统”的基础设置内容与层次结构（公共财务、制造、⼈⼒资源的相关层次结构⽐较简单，故略）：
Common Distribution Process Hierarchy
因篇幅问题不能全部显示，请点此查看更多更全内容