Oracle EBS开发

 

学习了相关文章之后，写写：

1. html报表开发

   创建package

   创建 PROCEDURE

   创建 程序

   创建可执行程序。

 

2. 创建客户化开发。

    下载jdeveloper，安装

    创建as或ws

    链接oracle

    创建model

    ....

 

首先需要说明的是，本系列文档假定读者已经具备基本的系统相关使用知识与技能(例如，能够基本领会“ORACLE EBS系统应用基础概述”中的内容)，故所讨论的内容仅限于笔者认为从系统使用与实际业务两方面来看比较重要或者容易存疑的问题，并不能面面俱到，旨在帮助读者掌握核心、抓住要点（详尽内容必须参考ORACLE相关官方文档）。文中为讨论需要所附图文均取自ORACLE EBS 的测试环境（Vision Demo），版本以R12.1.1为主，辅之以版本R11.5.10，界面语言主要为中文（必要时辅之以英文）。两个EBS版本在界面与功能应用方面实际可能有一些差异，必要时会作相关说明，但一般不会影响对基本问题的讨论。
技术是业务的抽象与工具，业务是技术的来源与目的。本系列文档通篇将秉持“从业务的角度去审视技术，从技术的角度去回归业务”的方法论（这里的所谓“技术”，意指“系统实现”），去探讨系统实现与业务实践的融合问题，以求逐步能达到技术与业务的融会贯通。限于笔者的认知水平，有讹误或不正确之处，欢迎批评指正。

一、安全性管理
从系统使用角度来看，系统管理的一项重要的日常工作是关于“用户”及其“权限”的管理，在ORACLE中即所谓“安全性”（Security）管理。“安全性”是一个涵义较之“权限”更为丰富、更为广阔的概念术语，它虽然比较抽象，但顾名思义，它很好地涵盖了于实际业务与系统使用中，有关企业数据与信息管理的某些需要重点保护、控制的内容。
有关用户权限的管理，在ORACLE系统中主要有三个基本要素构成：菜单（Menu）、责任（Responsibility）、以及用户（User）。三者的有机结合构成了系统权限或安全性管理的基础，辅之以参数或“安全性配置文件”等的使用，则进一步对用户的“实体（组织、帐套或分类帐）接入”权限进行细分。此外，系统在各个应用模块中，还将可能基于不同业务特点采取各具特色的系统实现方式，对用户的准入管理或功能权限作更进一步的划分（具体方式与系统设计者的个人偏好也有一定关系，不能一概而论）。
“菜单”（Menu）在今天信息时代的日常生活中已是一个很普通的术语。ORACLE中的“菜单”概念并无甚特别，它也是表示用户的系统应用功能入口。最基本的“菜单”由系统预置的若干“表单功能”所组成，EBS目前大概具有2万个左右的此类表单功能；（基于某些特殊需要，系统还可提供虽不可见但可由表单内包含的逻辑调用的某些非表单“子功能”，需开发后台设置）。用户可以自定义包括若干基本菜单作为“子菜单”的用户菜单，自定义的“用户菜单”也可以作为“子菜单”来使用，这样就形成了一个菜单结构（树形图）。如图1所示菜单定义及可选择使用的系统预置表单功能LIST：

EBS系统在安装好后，针对每个应用模块均已经预定义包括所有功能（或权限）所谓的“超级用户菜单”（Super User Menu），企业（系统管理员）在定义用户“责任”时可利用“排除法”来满足实际的业务管理需要。此外，系统还提供了“仅具查询”功能的预定义菜单，供某些需要限制做业务的用户使用。
相较于“菜单”的耳熟能详，EBS的所谓“责任”（ Responsibility）概念就生涩、抽象得多，通常可以将之与人们相对熟悉的“角色”（Role）概念来参看。在企业管理中通常会将人员按“岗位角色”来划分，例如“计划员、采购员、仓管员”等等，它们通常对应于一定的岗位职责（责任），有真实的业务管理涵义，比较具体。系统预先定义的角色，分配给用户（User）后，该用户就具有该角色的全部应用功能；但EBS未象其它产品（如SAP）使用角色概念，而是使用“责任”概念，则更倾向于抽象地表示某些功能（入口菜单）的组合，可以不具有真实的管理涵义，比如所谓“销售经理”责任之下，尽可以与“采购员”有相同的菜单项，具有完全相同的功能，而这一点如对应到实际的“岗位角色”，显然是不合适的。Role更清楚直接，但使用不够灵活；Responsibility可灵活使用，但容易带来理解上的歧义与误会，使用时要注意区分。如下图2所示的“责任”定义界面：


每个责任必须对应关联一个确定的菜单，但可以使用“排除”功能使之具有不同的菜单结构组合，这里的“排除”功能并不影响菜单原先的结构设置，这方便并简化了系统管理员对“责任”与“菜单”的管理。“责任名”总是从属于某一“应用产品”（模块），不同的模块可定义具有完全相同的“责任名”（包括菜单），但这两个完全相同的责任名在“配置文件”作层次结构设置时，可以具有不同的值，这进一步提供了系统的灵活性。责任一经定义就不可删除，只能通过设置有效期使之失效。为之设置“请求组”则限制了其可以使用的“请求”（并发程序）范围。至于其“可采用”应用产品范围设置（Web、自助等），似乎只起到统计分析的系统管理作用，实际并不影响具体的功能应用。
系统在安装后将具有一个名为“SYSADMIN”（密码sysadmin）且具有“系统管理员”责任的初始用户（该用户有时也被称之为“超级管理员”）。使用此初始用户可设置“菜单、责任及用户”。如下图3所示“用户”的定义界面：


    每个定义的系统“用户”可以关联若干个不同的责任，每个责任也可以设定用户使用的有效日期范围。具有多个责任的用户在登录使用系统时，需要在不同责任间作选择切换，并非可以同时使用。系统初始设置时设定的密码，在用户初次登录时，将被系统提示要求修改。密码可以设定“使用天数”或“访问次数”的限制，系统的预警平台可以设置密码失效的提前预警，以督促用户及时修改。“用户”一经设置也无法删除，只能使用有效期设置使之失效。“用户”不一定必须和HRM模块设置的“人员”关联，但对于有些模块的应用功能，关联已经HRM恰当设置的“人员”则是必须的。而关联“客户”或“供应商”则主要起到统计分析的系统管理作用，并不影响具体的功能应用。用户所关联的“电子邮件”地址，主要是供系统预警平台发送信息使用。
关于EBS 系统使用相关“配置文件”诸如“MO:业务实体、MO:安全配置文件、HR:安全配置文件、GL:数据访问权限集、GL帐套名或GL分类帐名称”等等，进一步对责任或用户的“实体接入”权限进行细分的问题（R12与R11比较，变化较大），将在下面的“组织架构”设置中讨论。
关于具体应用模块中对责任或用户的权限作更进一步划分问题，例如库存模块的“组织进入”（Access）、发运模块的“权限管理”（Grant），容后在相关模块文档中再来讨论。

二、会计科目弹性域结构
在讨论EBS的“组织结构”的设置之前，有必要先讨论会计科目弹性域（Accounting Flexfield）及其帐套（SOB）或分类帐（Ledger）的设置问题。“帐套”是R11及之前系统中的术语，“分类帐”是R12中替代帐套并为有所区别而使用的术语。为表述方便，后文如不特别指明，习惯上的“帐套”术语将等同于“分类帐”术语。在EBS关于“组织实体”的概念范畴中，帐套实际上也是“组织实体”的一种存在形式，之所以如此和ORACLE产品的发展历史有一定关系。
会计科目是企业进行财务数据核算工作的基础，各个国家基于企业监管与税收工作的需要而制定的会计法律法规都对之有相应规定。我国于2006年颁布的新会计准则将会计科目分为六大类：资产类、负债类、共同类、所有者权益、成本类、损益类，共计156个（一级）科目。简单的财务会计软件或单公司规模很小时，类似手工记账的“电算化”系统实现方式问题不大，但当会计业务管理需求复杂，企业从单公司向多公司集团化方向发展时，就必须考虑在系统层面如何方便地对多个公司的会计数据进行集中统一管理的问题。
ORACLE的ERP产品最初也是从财务软件发展起来的，总账GL是其第一个应用模块。事实上，在计算机或管理软件出现以前，企业所谓“集团管控”的需求及实践早已存在。ORACLE财务软件中包含“多公司信息”的独特会计科目弹性域结构设计，使得财务工作的集团管控更加具备技术上的可行性与方便性。一个最基本、最简单的会计科目弹性域结构就是“公司代码+会计科目代码”的组合，它的原始业务需求来源并无多少深奥之处。
在ORACLE的会计科目弹性域结构中，体现国家法律法规要求的“会计科目”成为其中必不可少的一个组成段即“自然账户”段，自然账户所使用的值集，即为通常所说的“科目表”。系统在自然账户之上附加“公司、部门”等多个段信息，大大方便了在公司内及公司间的会计数据的统计分析工作。如图4所示，就是一个典型的5段式会计科目弹性域结构：


图中的“公司段”为“平衡段”（弹性域限定词 Flexfield  Qualifiers，是具有某种特定属性的“识别标记”），表示在“公司段”层面，日记账（Journals，“会计分录”）的“借项等于贷项”，总是平衡的。其值集为包含所有公司的代码LOV，包括法律实体及基于公司管理需要而设定的运营实体；如图5所示会计科目弹性域结构的“公司段”值集定义：


在EBS系统中定义的法律实体LE必须对应于公司段值集中的（至少）一个值（行），但R11与R12的区别是，R11在定义LE时并没有明确告诉系统对应（绑定）哪个段值，只要用户自己清楚并不混淆即可。而在R12定义LE时，需要将其与会计科目弹性域结构中的某个公司段值明确关联，这是R12的改进之处，避免了R11实际使用中当定义的法律实体LE数量较多时可能产生的混淆不清。
“部门段”的弹性域限定词为“成本中心段”，成本中心LOV值可能是企业中的一个具体行政组织，也可能表示共享一个成本中心的多个行政组织的组合，还可能是表示基于统计管理需要而设定的多个成本中心的组合；如下图6所示：


“账户段”的弹性域限定词为“自然账户段”，其LOV值即法定科目表及为统计需要而设置的汇总科目；如图7所示：


注意，图7与图5、6中的“段限定词”的内容有所不同，它具体规定了自然账户的段值所代表的会计科目的类别（资产、负债等），“弹性域限定词”与“段限定词”是两个不同的概念，段限定词的取值受控于弹性域限定词的取值。
会计科目弹性域结构的“子账户段”表示“二级科目或明细科目”，与账户段的一级科目具有汇总与被汇总的关系；“产品段”，则表示基于特定统计分析需要而设置的产品LOV。
系统允许设置最多30个段，但必须至少包含两个段（平衡段、自然账户段）。由于会计科目弹性域结构一经设定并使用之后，以后修改比较困难，故通常会设定一个或多个预留段，如可在上述典型的5段结构之外再增加一个暂时不使用的段（预留段）而成为6段结构。会计科目弹性域结构的设定是系统基础设置的重要工作之一，有关详细设置方法与步骤请参看相关系统设置文档。
此外，EBS系统针对所有弹性域的“段值”的接入权限，提供了“安全性”设置功能，控制“责任”实际可以使用的段值范围，如下图8所示：


  

三、帐套（分类帐）
会计科目弹性域结构（COA）、币种（Currency）、日历（Clander）三者的组合构成EBS R11及之前系统的所谓“帐套”（SOB）。在R12中，再增加一个维度“会计方法或会计惯例”，即成为所谓“分类帐”。所谓“会计方法或惯例”，例如对于