ORACLEEBS系统应用基础概述

合集下载

Oracle EBS基础知识学习情况汇报 2

Oracle EBS基础知识学习情况汇报 2

Balance segment: (此段必须进行设定)(指定Company)总账所有的在平 衡段内的处理过程借贷必须平衡。每一个平衡段对应一个你所确立的实体, 对于这个实体,你可以获得次实体的平衡表和收益表 Management Segment:此段主要与数据访问集用来控制数据的读写权限 Intercompany Segment 此段用于追溯公司之间的数据交互和业务处理 Secondary Tracking用于重估,汇兑损益、关闭财年内的凭证、数据调整、 未实现的汇兑损益(不理解)
3)定义累计组(不理解) 这里会用到累计组的包括Department、 Account 、 Product
4)输入值 为刚才定义的弹性域结构的每一段添加值。 对段内的Value set 赋值
划绿圈处为我们刚刚创建的累计组。Level 处可 以根据需求填写。一般没有子项的默认即可。
定义03 的子项,注意父项的属性 设置posting 要设定为NO
Cost center segment。(指定department)成本 中心段,用于对不同的部门或是成本中心,生成对 应的损益表或是管理报告(Income Statements or Management Reports)
Natural Account segment: (此段必须进行设定) (指定account)这个段 是账目架构的核心段,此段用来确定每一次账目处理过程数据应该传送到得科 目。并且此段还要对科目进行合并和分类确定资产、负债、所有者权益、收益和 费用;确定哪些项目进留存损益科目,哪些项目需要转到下一年。
Security Type:
No security:表示没有任何安全控制。 Hierarchy:将父层的安全特性全部传递到 这个项目的子层 No-Hierarchy:安全特性只对当前项有效

ORACLE EBS系统应用基础概述

ORACLE EBS系统应用基础概述

ORACLE EBS系统应用基础概述一、前言二、表单与查询(Form and Summary)三、事务处理(Transaction)四、并发流程(Current Process)五、文件夹(Folder)六、弹性域(Flex field)七、值集与查找代码(Value Set and Lookup Code)八、配置文件(Profile)九、单据编号(Document Sequence)十、工作流(Workflow)十一、预警(Alert)十二、应用开放接口(Open Interface and API)十三、结语(注:网站批量发图有问题,上传后显示不清楚。

点击图片打开后,质量尚可)一、前言有网友在论坛发帖惊呼:好不容易把EBS系统安装好了,进去一看傻眼了,不知道从哪儿下手?发出惊叹的这位网友所遇到的问题,实际上也是很多人曾经遇到或正在遇到的问题。

长期以来,国内的非专业人士(例如媒体)提及SAP 或ORACLE的时候,有不少人喜欢用“超级难懂”来形容。

那么,国内专业人士的看法又如何呢?笔者所听到过的最“雷”的说法来自一位国内软件研发的高层主管:SAP/ORACLE太复杂了,其背后的东西、深层次的东西,我们永远不可能搞懂!真是太不可思议。

一方面,国内的业内人士几乎众口一词,我们与SAP/ORACLE相比,技术上没有多大差距,平台工具都是公开的,也没有什么奥秘可言。

SAP/ORACLE由于产品做得早,我们在技术上甚至还有后发优势。

另一方面,我们也常常听到国内有些人将SAP/ORACLE神秘化,认为其包含“复杂的、深刻的管理思想”,是德国人/美国人的东西,我们中国人的企业管理水平低,用不了是正常的。

国情不同,模式不同,中国人应该寻找一条适合自己的道路!真的是这样吗?SAP/ORACLE产品真的是那么神秘、高不可攀?今天专业从事ERP工作的人员,若从个人背景角度来看,通常可以划分为“技术出身”与“业务出身”两类。

EBS系统知识介绍

EBS系统知识介绍

13
客户简称 汉得公司 版权所有
14
客户简称 汉得公司 版权所有
上海汉得信息技术有限公司
HAND Enterprise Solutions Company Ltd. 15
客户简称 汉得公司 版权所有

7
客户简称 汉得公司 版权所有
PATCH TYPE
8
客户简称 汉得公司 版权所有
PATCH FORMAT
9
客户简称 汉得公司 版权所有
PATCH之间的联系 PATCH之间的联系
PATCH与其他 与其他PATCH的包含关系,可以通过metalink patch查询界面获得信息. 的包含关系,可以通过 查询界面获得信息. 与其他 的包含关系 查询界面获得信息 PATCH与其他 与其他PATCH的前后关系,可以通过 的前后关系, 描述获得信息. 与其他 的前后关系 可以通过readme描述获得信息. 描述获得信息
12
客户简称 汉得公司 版权所有
Autoconfig原理 Autoconfig原理
autoconfig操作是产生 操作是产生EBS所有系统 所有系统configuration文件,并替换原所有系统 文件, 文件. 操作是产生 所有系统 文件 并替换原所有系统configuration文件. 文件
10
客户简称 汉得公司 版权所有
查询系统PATCH历史 查询系统PATCH历史 PATCH
一,通过OAM查询系统 通过 查询系统PATCH历史. 历史. 查询系统 历史 如左图: 如左图:
查询, 二,通过sql查询,如下: 通过 查询 如下: SELECT DD.PATCH_NAME, PP.CREATION_DATE, PP.DRIVER_FILE_NAME, NGUAGE FROM AD_PATCH_DRIVERS PP, AD_APPLIED_PATCHES DD, AD_PATCH_DRIVER_LANGS LANG WHERE PP.APPLIED_PATCH_ID = DD.APPLIED_PATCH_ID AND LANG.PATCH_DRIVER_ID = PP.PATCH_DRIVER_ID AND DD.PATCH_NAME='123456'

ORACLE_EBS_系统设计应用基础概述

ORACLE_EBS_系统设计应用基础概述

系列之三:ORACLE EBS系统应用基础概述一、前言二、表单与查询(Form and Summary)三、事务处理(Transaction)四、并发流程(Current Process)五、文件夹(Folder)六、弹性域(Flex field)七、值集与查找代码(Value Set and Lookup Code)八、配置文件(Profile)九、单据编号(Document Sequence)十、工作流(Workflow)十一、预警(Alert)十二、应用开放接口(Open Interface and API)十三、结语一、前言有网友在论坛发帖惊呼:好不容易把EBS系统安装好了,进去一看傻眼了,不知道从哪儿下手?发出惊叹的这位网友所遇到的问题,实际上也是很多人曾经遇到或正在遇到的问题。

长期以来,国的非专业人士(例如媒体)提及SAP或ORACLE的时候,有不少人喜欢用“超级难懂”来形容。

那么,国专业人士的看法又如何呢?笔者所听到过的最“雷”的说法来自一位国软件研发的高层主管:SAP/ORACLE太复杂了,其背后的东西、深层次的东西,我们永远不可能搞懂!真是太不可思议。

一方面,国的业人士几乎众口一词,我们与SAP/ORACLE 相比,技术上没有多大差距,平台工具都是公开的,也没有什么奥秘可言。

SAP/ORACLE由于产品做得早,我们在技术上甚至还有后发优势。

另一方面,我们也常常听到国有些人将SAP/ORACLE神秘化,认为其包含“复杂的、深刻的管理思想”,是德国人/美国人的东西,我们中国人的企业管理水平低,用不了是正常的。

国情不同,模式不同,中国人应该寻找一条适合自己的道路!真的是这样吗?SAP/ORACLE产品真的是那么神秘、高不可攀?今天专业从事ERP工作的人员,若从个人背景角度来看,通常可以划分为“技术出身”与“业务出身”两类。

“技术出身”的人在学习熟悉系统方面可能有一定优势,但与用户沟通交流的过程中,在迅速准确把握业务本质要领方面可能存在一定困难;而“业务出身”的人,对于与用户的业务沟通交流可能感觉比较容易,但在研究掌握系统方面则可能相对困难一些。

EBS基础要点简介-帐套分类帐

EBS基础要点简介-帐套分类帐

ORACLE EBS 基础设置要点简介三、帐套(分类帐)会计科目弹性域结构(COA)、币种(Currency)、日历(Clander)三者的组合构成EBS R11及之前系统的所谓“帐套”(SOB)。

在R12中,再增加一个维度“会计方法或会计惯例”,即成为所谓“分类帐”。

所谓“会计方法或惯例”,例如对于不同国家或地区、不同企业,会计法规可能规定物品单价5000元是作为“固定资产”还是“期间费用”处理的判定标准,也可能规定这个判定标准是1万元。

标准不同,记账的会计科目也就不同,企业报告的经营结果也就会有差别。

一个诸如在香港注册的企业,一方面需要向香港政府机关提交符合本地法规的财务报告,另一方面可能还需要向在国内的总公司提供符合国内法规的财务报告(便于考核管理),这就出现所谓“多账簿”(对应R12中的主辅分类帐)的系统功能问题。

如下图9是EBS R11中“帐套”的定义接口:如下图10所示是EBS R12中使用“会计科目管理器AMB”设置“主要分类帐(Primary Ledger)”与“辅助分类帐(Second Ledger)”的定义接口:R12中定义的一个“主要分类帐”可以附带定义与之关联的多个“辅助分类帐”,如下图11所示:等等,其事务处理默认是基于“主要分类帐”的会计科目表(COA),所以,如果主辅分类帐的科目表不同,则必须在两者之间建立“映射(Mapping)”关系(1对1或多对1的关系)。

如下图12所示为主辅分类帐的映射定义界面,如果两者科目表相同(币种不同),则该定义界面将有所不同,没有“科目表”映射的内容,只有后面部分(币种转换及日记账转换等):下图13所示为当主辅分类帐的科目表不同时,系统科目表映射的定义界面,账户规则定义中可见,源账户可以是一个范围,而目标账户只能是一个:ORACLE EBS R12中四维(4C)定义的“分类帐Ledger”构成了ORACLE系统“多账簿”功能的处理基础。

EBS基础要点简介-帐套(分类帐)

EBS基础要点简介-帐套(分类帐)

EBS基础要点简介-帐套(分类帐)ORACLE EBS 基础设置要点简介三、帐套(分类帐)会计科目弹性域结构(COA)、币种(Currency)、日历(Clander)三者的组合构成EBS R11及之前系统的所谓“帐套”(SOB)。

在R12中,再增加一个维度“会计方法或会计惯例”,即成为所谓“分类帐”。

所谓“会计方法或惯例”,例如对于不同国家或地区、不同企业,会计法规可能规定物品单价5000元是作为“固定资产”还是“期间费用”处理的判定标准,也可能规定这个判定标准是1万元。

标准不同,记账的会计科目也就不同,企业报告的经营结果也就会有差别。

一个诸如在香港注册的企业,一方面需要向香港政府机关提交符合本地法规的财务报告,另一方面可能还需要向在国内的总公司提供符合国内法规的财务报告(便于考核管理),这就出现所谓“多账簿”(对应R12中的主辅分类帐)的系统功能问题。

如下图9是EBS R11中“帐套”的定义接口:如下图10所示是EBS R12中使用“会计科目管理器AMB”设置“主要分类帐(Primary Ledger)”与“辅助分类帐(Second Ledger)”的定义接口:R12中定义的一个“主要分类帐”可以附带定义与之关联的多个“辅助分类帐”,如下图11所示:等等,其事务处理默认是基于“主要分类帐”的会计科目表(COA),所以,如果主辅分类帐的科目表不同,则必须在两者之间建立“映射(Mapping)”关系(1对1或多对1的关系)。

如下图12所示为主辅分类帐的映射定义界面,如果两者科目表相同(币种不同),则该定义界面将有所不同,没有“科目表”映射的内容,只有后面部分(币种转换及日记账转换等):下图13所示为当主辅分类帐的科目表不同时,系统科目表映射的定义界面,账户规则定义中可见,源账户可以是一个范围,而目标账户只能是一个:ORACLE EBS R12中四维(4C)定义的“分类帐Ledger”构成了ORACLE系统“多账簿”功能的处理基础。

ORACLE EBS 用户、职责、菜单和预制文件等系统基本概念

ORACLE EBS 用户、职责、菜单和预制文件等系统基本概念
主要字段说明: 责任名称:用户责任名称。 应用:用户责任所在应用。从值列表中选择. 主要责任:对用户责任实现的主要功能的说明。 说明:用户责任的描述。 有效日期:用户责任的生效日期范围。 菜单:用责任登录系统时,选用的主菜单,从值列表中选择. 数据组:ORACLE应用集。使用系统缺省定义‘标准’。从值列表中择. 数据组应用:选择数据组中某一应用,同责任对应应用。从值列选择. 请求组:选择责任对应的ORACLE标准请求、报表的集合。从值列表 中选择. 请求组应用:请求集对应的应用,和请求集一同选出。 排除功能及菜单:责任主菜单中需排除的功能或菜单 类型:功能或菜单 名称:需要排除的功能名或菜单名,从值列表中选择. 如果需排除菜 单中某些功能和菜单,则排除功能及菜单块中输入选择功能或菜单类 型,并输入需排除的功能和菜单名 说明:需要排除的功能或菜单描述。 三:用户概念和定义 security ---user --- define: 新加用户界面:
注:一个用户可以拥有一个或多个责任 二:责任的定义:
ORACLE应用产品中每个应用用户至少具有一个指定的责任。责 任确定了用户是否可以访问 Oracle 应用产品,用户可以运行哪些应 用功能,用户可以运行哪些报表和并发程序,以及这些报表和并发程 序可以访问哪些数据
System administrator职责下 security --- responsibility --- define
六:并发程序和请求管理 相关概念的介绍如下: 并发程序 并发程序就是可执行特定任务的非交互式程序。例如,在 Oracle 应 用产品中,过帐日记帐程序或后台生成报表的程序。 可执行程序 并发程序使用的各种程序文件。 并发进程 并发进程就是运行并发程序。并发管理器每收到一个请求并且开始运 行相应并发程序后就创建一个新的并发进程。并发进程可以同时与其 它并发进程(和您计算机中的其它活动)一起运行。 并发请求 并发请求是为运行并发程序所提交的请求。在您使用“标准请求提交” 提交供运行的报表或程序时,或者在特定产品提交窗口选择“活动”按 钮时,会发出并发请求。 并发管理器

ORACLE_EBS_系统应用基础概述

ORACLE_EBS_系统应用基础概述

ORACLE_EBS_系统应用基础概述ORACLE EBS(Enterprise Business Suite)是由ORACLE公司开发的一套集成化的企业应用系统,用于管理企业的关键业务流程。

它包括了财务、人力资源、供应链管理、供应商关系管理、生产制造、销售和客户关系管理等多个模块,帮助企业实现业务处理的自动化和优化。

首先,ORACLEEBS的核心模块包括财务管理、人力资源管理和供应链管理。

财务管理模块包括总账、应付账款、应收账款等功能,用于管理企业的财务状况和流动资金。

人力资源管理模块包括员工档案、薪资管理、绩效评估等功能,用于管理企业人力资源。

供应链管理模块包括采购、仓库管理、物流等功能,用于优化企业的供应链流程。

其次,ORACLEEBS还提供了供应商关系管理和生产制造模块。

供应商关系管理模块包括供应商评估、合同管理、供应商支付等功能,用于优化企业与供应商之间的合作关系。

生产制造模块包括生产计划、物料需求计划、生产执行等功能,用于提高企业的生产效率和产品质量。

除了核心模块外,ORACLEEBS还提供了销售和客户关系管理模块。

销售模块包括销售订单管理、合同管理、销售报价等功能,用于管理企业的销售过程和客户关系。

客户关系管理模块包括客户档案、客户服务、市场营销等功能,用于提高企业的客户满意度和市场竞争力。

首先,ORACLEEBS具有高度的集成性。

它可以与其他企业应用系统(如CRM系统、SCM系统)进行无缝集成,实现信息的共享和流转,提高企业的业务效率。

同时,它还可以与ORACLE数据库进行集成,实现数据的共享和存储。

其次,ORACLEEBS拥有丰富的功能和强大的定制能力。

它提供了大量的功能模块和标准业务流程,可以满足不同企业的需求。

同时,它还允许企业进行定制开发,根据自身的业务特点和需求来进行个性化配置。

再次,ORACLEEBS具有灵活的部署选项。

它可以在企业内部部署,也可以通过云服务进行部署。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

系列之三:ORACLE EBS系统应用基础概述一、前言二、表单与查询(Form and Summary)三、事务处理(Transaction)四、并发流程(Current Process)五、文件夹(Folder)六、弹性域(Flex field)七、值集与查找代码(Value Set and Lookup Code)八、配置文件(Profile)九、单据编号(Document Sequence)十、工作流(Workflow)十一、预警(Alert)十二、应用开放接口(Open Interface and API)十三、结语一、前言有网友在论坛发帖惊呼:好不容易把EBS系统安装好了,进去一看傻眼了,不知道从哪儿下手?发出惊叹的这位网友所遇到的问题,实际上也是很多人曾经遇到或正在遇到的问题。

长期以来,国内的非专业人士(例如媒体)提及SAP 或ORACLE的时候,有不少人喜欢用“超级难懂”来形容。

那么,国内专业人士的看法又如何呢?笔者所听到过的最“雷”的说法来自一位国内软件研发的高层主管:SAP/ORACLE太复杂了,其背后的东西、深层次的东西,我们永远不可能搞懂!真是太不可思议。

一方面,国内的业内人士几乎众口一词,我们与SAP/ORACLE相比,技术上没有多大差距,平台工具都是公开的,也没有什么奥秘可言。

SAP/ORACLE由于产品做得早,我们在技术上甚至还有后发优势。

另一方面,我们也常常听到国内有些人将SAP/ORACLE神秘化,认为其包含“复杂的、深刻的管理思想”,是德国人/美国人的东西,我们中国人的企业管理水平低,用不了是正常的。

国情不同,模式不同,中国人应该寻找一条适合自己的道路!真的是这样吗?SAP/ORACLE产品真的是那么神秘、高不可攀?今天专业从事ERP工作的人员,若从个人背景角度来看,通常可以划分为“技术出身”与“业务出身”两类。

“技术出身”的人在学习熟悉系统方面可能有一定优势,但与用户沟通交流的过程中,在迅速准确把握业务本质要领方面可能存在一定困难;而“业务出身”的人,对于与用户的业务沟通交流可能感觉比较容易,但在研究掌握系统方面则可能相对困难一些。

根据笔者曾经做过的调查统计,国内ERP从业人员中“技术出身”的人似乎占了绝大多数。

ORACLE EBS 作为一个有百多个业务应用模块、高度集成的企业管理软件系统,它是现代计算机技术与企业管理实践的高度融合。

它不是模仿企业手工业务过程的“电算化”简单再现,或许正是让很多人感到其“难懂难用”的根本原因所在。

因此,“从实践中来,再到实践中去”,或曰“从业务透视技术,再从技术回归业务”也许正是我们一步一步叩开ORACLE EBS的大门,徜徉其间并游刃有余的方法论。

(这里的所谓“技术”意指“系统实现”)。

业内对于专业从事ERP工作的人员,大致有以下三种分类:一类是所谓“技术顾问”,对于这些人来说,掌握相应的软件开发技能是必要条件,其工作领域的重点一般主要是在系统后台,类似开发系统接口、业务报表,解决一些系统的技术问题等等;二类是所谓“功能顾问”,这些人对于系统的相关模块有不同程度的熟悉,通常是在指导企业使用系统,或努力地在把企业的业务要求变为系统的实现方案;三类是所谓“管理顾问”,这些人通常有比较丰富的企业管理实战经验积累,同时对ERP系统也有比较深刻的认识,能够从企业管理业务流程的整体高度给出咨询建议,最大限度地发掘出ERP系统对于企业管理水平提高的重要作用(这里的“管理顾问”是特指,有别于市面上众多不懂系统、只会“纸上谈兵”的忽悠型“管理顾问”)。

实际工作中,上述三类人员前后之间可能并无明确的划分界线,但大体上有一个随着系统认识水平的提高以及业务运作经验的积累,由低到高发展的过程。

因此,如何实现“从业务角度去透视技术,从技术角度去回归业务”是业内人员所面对的永恒命题,能达到业务与技术的“融会贯通”则是追求的最高境界。

为此,本篇将从博大精深的ORACLE EBS系统最基本的应用基础组成元素开始,从业务—技术—业务,探讨让有些人高深莫测、妄自菲薄的所谓“其背后的东西、深层次的东西”到底是些什么,以便能够最终寻找到帮助我们登堂入室的钥匙与途径。

二、表单与查询(Form and Summary)企业在手工模式下的业务运作过程中,总有各种各样的用于记录业务数据或管理信息的纸面单据,例如“销售订单、采购订单、入库单、出库单”等等。

随着业务量的增加,这些纸面单据的数量是如此之多,以致于企业不得不花费大量人力,将每张单据上的重要信息摘要出来(例如采购订单上的供应商、物料、数量、价格、金额、日期等),另外建立一个数据记录的“索引、清单或台账”等,以方便能在需要时对它们进行查询或统计。

一个最简单的软件管理系统,就是把上述纸面单据“电子化”后放入系统,然后再提供一个在系统里查找这些单据的“查询”功能。

如果你去研究一下目前国内的主流ERP产品,你就会发现这些主要用于中低端市场的国内ERP产品,其每个模块中的应用功能实际主要就是“单据新增与单据查询”这两项。

其单据在系统中的格式和内容与纸面单据是如此近似相像,以致于大多数企业人员学习掌握它们不会感觉有多大困难。

在ORACLE EBS的每个模块中,同样也是要用到各种单据(Form)来录入或保存数据(对应于后台数据库中的“表”),并为之提供相应的查询功能,但ORACLE中的系统单据已经不是纸面单据的简单再现。

系统的UI界面中可以见到各种“表单”(据统计约有3000多种),它们不仅不同于纸面单据,相互之间的性质及查询方式差别也可能很大。

归纳起来,ORACLE各模块中的“表单”按性质与作用大体可分为三大类:第一类是“业务流程”类表单例如“销售订单SO、采购订单PO、制造工单WO、发票INVOICE”等等,它们有一个共同的特点是参与核心业务流程的运转,是核心业务流程的一个环节、不可或缺。

这一点显然也是和实际的企业业务过程是高度相对应的。

作为业务的原始凭据凭证,它们是如此重要,即使是IT系统化之后,大多数企业可能还是要将它们的纸面形态予以保存、归档。

在ORACLE EBS中,“业务流程”类表单种类其实很少(每个模块一般仅一、两个左右),但每种单据随时间日积月累,业务数据量可能很大。

业务流程类表单是系统中最重要的表单,与纸面单据相比,内容更为丰富和复杂,格式也有很大的变化,它充分利用了数据库技术所提供的可容纳性、可扩展性以及使用便利性。

它来源于业务实践,但经高度抽象并融入最新科技成就后,其功能与作用又远远高于原始的纸面单据。

如图1的PO表单:PO表单是一个典型的“业务流程”类表单,它有“表头与表体行”两大部分组成,这一点与纸面单据仍然类似。

但不同的是系统表单的每一个“表体行”,还可以拥有属于自己的“二级子表行”;而每一个“二级子表行”,也可以拥有属于自己的“三级子表行”,如此类推。

这种表单展现方式,纸面单据是无法实现的,它极大地扩充了单据可以包含的信息容量,具有高度的灵活性与便利性。

在图1中,PO的第一行采购总数量为36,对应到“发运”二级子表拆分为数量分别为20与16的两行(表示发到两个不同收货地点或同一地点但两个不同发货时间);“发运”二级子表的第一行数量为20,对应到“分配”三级子表拆分为数量分别是10与10的两行(表示对应到两个不同的费用会计科目或费用由两个不同部门分别承担)。

第二类是“数据来源”类表单例如“OM模块中的价目表、PO模块中的报价单、”以及“物料、供应商、客户”数据表单等等,它们的共同特点是不参与核心业务流程的构建,但它们为业务流程表单提供可以参考的数据来源,例如采购订单从物料表单取物料相关信息,从供应商表单取供应商信息、从报价单取价格相关信息等等;这类表单在手工业务模式下大多数都可能也存在,但手工状态下的实际使用与管理可能无法做到很严格规范;在ORACLE EBS中,“数据来源”类表单在每个模块中种类可能很多,每种表单的内容与格式复杂程度,以及单据数量也差别很大。

它们虽然并非不可或缺,但它们体现的专业化分工与协作的管理思想,对于企业的业务流程运作效率有重大影响。

下图2所示订单管理/定价模块中的“价目表”,就是一个典型的“数据来源类”表单,它也可有复杂的结构:第三类是“业务控制”类表单例如“销售的物料可订购性、采购的批准供应商列表、系统参数设定”等等,这类表单在手工业务模式下很少或根本不存在。

事实上,手工方式下实际也很难使用它们对业务进行有效控制。

在ORACLE EBS中,“业务控制”类表单在各模块中的种类也比较少,单据数量也很有限,但它们体现的是企业管理的系统控制机制,对于业务管理控制的效率有重要影响。

如下图3所示采购的批准供应商列表(控制可向哪些供应商采购),就是一个比较典型的“业务控制类”表单,它也同样可有复杂的结构。

尽管在ORACLE EBS中,统计后台数据库中所用到的“表”(Table)数量有一万多个,前台UI中可见的表单也形形色色、数量繁多,乍看令人生畏,但在分析归纳划分为以上三大类之后,事情就会变得简单很多,它使得我们可以把每个模块中种类很有限的“核心的业务流程表单”作为学习研究的“切入点”,通过对每种单据内部业务内涵与技术内涵的分析,以及各种单据之间业务逻辑与技术逻辑的研究,逐步扩展并掌握系统的其它功能与应用。

基于实际工作的需要以及系统设计的简洁方便,ORACLE针对上述三种不同类型的表单分别提供了可供选择使用的不同“查询”方法,归纳起来也可分为三类:功能查询方式所谓“功能查询”方式,在系统中有“查询”功能菜单项(例如PO Summary,采购订单汇总),点击此菜单进入时,系统会首先弹出“查找条件”输入窗口(控件),如下图4所示采购订单功能查询菜单与查询条件控件:然后根据输入的查询条件,给出查询结果LIST。

作为查询功能扩展,系统还在UI界面工具栏进一步提供关联查询(如采购订单的上下游单据“采购申请”和“采购发票”)和细节查询功能,如下图5所示采购订单功能查询方式的输出结果视图:功能查询方式通常只用于核心“业务流程”类单据的查询,查询功能强大。

由于业务流程类表单(以及部分数据来源类表单)的重要性,系统在菜单项中提供了专门的“查询”功能。

快捷查询方式所谓“快捷查询”方式即在打开单据界面后,只需点击UI界面工具栏内的查询“图标”(手电筒),查询条件输入方式有两种:一种是无专用的“查询条件”选择窗口,仅限于在查找界面的“查找栏”输入常用的那些字段(即所谓“模糊查询”),系统在查找界面直接给出所有符合条件的条目LIST,而详细情况需选定条目后,再进入单据界面查看,如下图6所示“采购订单”在单据界面进行“快捷查询”的情况:另一种是在单据界面点击查询图标(手电筒)后,也会出现“查询条件”输入窗口,输入查询条件后,系统也可能会出现一个简单的结果清单LIST界面或视图(某些表单查询则可能没有),通过该LIST视图界面可以再选择打开相关条目的表单。

相关文档
最新文档