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具有灵活的部署选项。

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

系列之三:ORACLEEBS系统应用基础概述

系列之三:ORACLEEBS系统应用基础概述

系列之三:ORACLE EBS 系统应用基础概述(D)热度 15已有 1021 次阅读2009/11/14 21:18|关键词:EBS ORACLE 系统基础概述ORACLE EBS 系统应用基础概述十一、预警(Alert)十二、应用开放接口(Open Interface and API)十三、结语(注:网站批量发图有问题,上传后显示不清楚。

点击图片打开后,质量尚可)十一、预警(Alert)今天在企业的办公场所或酒店的房间等很多地方,我们都可以见到天花板上装有“烟感报警器”以及“自动喷淋器”,国家对建筑物的消防安全有明确的法律法规,因此这些“报警或灭火”装置几乎已成了建筑物的标准配置。

与之类似,预警平台对于今天的ERP系统来说也几乎是一个标准装备,无论是从系统实现角度还是从业务应用角度来看,它都不是很复杂,比较容易掌握。

ORACLE 的系统预警分两种方式,一是“事件预警”,二是“周期预警”。

两者的基本工作方式均是使用SQL Select语句基于对数据库中的相关值作出条件判定,以决定是否执行某种活动(发出信息,执行并发程序、执行操作系统程序、执行SQL语句)。

更进一步,对于“发出信息”类预警,系统在收到对此信息的符合规定格式的“回复”后,还可以据此自动执行相关活动并完成相关事务处理。

所谓“事件预警”,即当用户在相关数据表中“插入”或“更新”某些值时,系统自动启动已定义的“SQL Select语句”的检查,已确定是否需要发出预警信息或执行某种活动,如下图33所示的一个事件预警定义:在采购管理系统模块中,当出现一个巨大数量的申请行数量被输入时,系统需要向相关责任人发出预警通知(以提醒诸如做好资源准备等)。

所谓“周期预警”,即系统按照事先定义好的周期间隔或频率,自动启动已定义的“SQL Select语句”针对数据库中表的某些值作检查,已确定是否需要发出预警信息或执行某种活动,如下图34所示的一个周期预警定义:在采购管理系统模块中,系统按每两个工作日的间隔频率对所有“一揽子采购协议BPA”的到期情况进行检查,并将需要关注的检查结果(例如某些BPA将在一周之类过期)通知到相关责任人。

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

Oracle EBS基础知识学习情况汇报.ppt
❖ 库存组织 使用库存组织跟踪库存业务和余额。 Oracle库存、Oracle物料清单、Oracle在产品、 Oracle主生产计划/MRP、Oracle能力、Oracle质量、 Oracle成本管理、Oracle采购(接收功能)均按库存 组织设立安全性控制。库存组织可以指定到同一帐 套下的任何经营单位,库存组织与帐套之间的关系 仅限于财务核算目的,库存组织决定了销售和采购 模块可获得的物料(Items)。
ORACLE EBS基本知识 学习汇报
2012.7.12
目录
1.ebs概览 2.财务 3.供应链 4.流程制造
一、模块概览 完整的企业管理系统方案
供应链管理
制造管理
客户关系管理
市场管理 销售管理 服务/客户关怀 Call Center E-Commerce
人力资源管理
人力资源 工薪管理 培训管理
2)定义科目表结构
AVXT_GL_Super:Setup>Financials>Flexfields>Key>Segments 查找出“Accounting Flexfield”键弹性域,添加自己的科目表结构, “AVX_ACCOUNTING_FLEXFIELD”,注意下面的一些单选框,特别是: “Allow Dynamic Inserts”允许动态插入,如果不允许动态组合科目,则需 手工录入科目组合
财务系统重要概念介绍(理解)
❖ 经营单位 使用Oracle应收、Oracle应付、Oracle销 售、Oracle采购、Oracle现金管理和Oracle项目会 计等模块的独立会计核算实体。任何独立核算的组 织均是已指定法人实体的“经营单位”。在以上的 模块中,业务信息按“经营单位”设置安全性,有 些信息是共享的。

ORACLE-EBS-基础设置要点简介

ORACLE-EBS-基础设置要点简介

ORACLE-EBS-基础设置要点简介概述Oracle E-Business Suite(简称EBS)是一款企业级应用软件,它的设计目标是为企业提供全面的业务解决方案,包括财务、人力资源、供应链管理、客户关系管理等多个模块。

在使用EBS之前,需要进行一些基础设置,以确保系统的正常运作和最好的性能效果。

本文将介绍EBS基础设置的要点,包括语言支持、日期和货币、服务器配置、访问控制等。

语言支持EBS支持多种语言,用户可以根据需要进行自由切换。

在设置中,需要将语言设置为“负载均衡(HTTP)”或“标准”的形式。

此外,还可以针对特定用户设置语言,具体方法如下:1.在“用户维护”中进行如下设置用户界面语言:英语报表语言:英语2.在“用户个人设置”中进行如下设置首选语言:英语日期和货币对于日期和货币的设置,需要根据不同的国家和地区进行选择。

在EBS中,可以通过运行“日期和货币设置”的功能来进行设置,具体步骤如下:1.找到“运行窗口”或“应用程序菜单”,输入“日期和货币设置”和相应的国家或地区。

2.选择适当的日期格式和货币符号。

3.点击“提交”按钮,保存设置。

服务器配置针对不同的业务需求和规模,EBS的服务器配置需要进行适当的调整。

其中,包括以下几个方面:1.并发管理:EBS支持多个并发事务的同时运行,但需要进行相关的实时监控和限制。

2.内存和磁盘:对于大型企业,需要将EBS的内存和磁盘空间适当地进行扩展,以确保系统的正常运作和快速响应。

3.网络:在分布式环境中,不同的应用服务器需要进行适当的网络配置,以确保数据的安全传输和高效访问。

访问控制为了保护EBS系统的安全性,必须进行严格的访问控制。

安全策略应包括以下要点:1.密码策略:设置密码长度、复杂度等特性,规定用户更改密码的频率,以尽可能保障系统安全。

2.角色权限:为不同的用户设置不同的应用程序权限、菜单权限、功能权限和数据权限,以确保资源的合理分配和使用。

系列之三:ORACLEEBS系统应用基础概述(C)-season的日志-网易博客

系列之三:ORACLEEBS系统应用基础概述(C)-season的日志-网易博客

系列之三:ORACLEEBS系统应用基础概述(C)-season的日志-网易博客系列之三:ORACLE EBS系统应用基础概述(C)Oracle ERP 2010-08-09 16:29:14 阅读7 评论0 字号:大中小订阅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”等。

系列之五:ORACLE-EBS-系统主数据管理基础介绍

系列之五:ORACLE-EBS-系统主数据管理基础介绍

系列之五:ORACLE EBS 系统主数据管理(A)ORACLE EBS 系统主数据管理一、EBS主数据概述(Master Data)二、物料(Item)(一)Item 的范畴(二)Item 的编码(三)Item 的类别(Category)(四)Item的单位(UOM)(五)Item 的制造商部件号(MPN)(六)Item的版本(Revision)(七)Item的组织控制(Master Org)(八)Item的属性及相互关系概述(九)Item的属性内容简介(Attribute)(十)Item的属性快查(十一)Item的客户与供应商关系(十二)Item的物料关系(Relationship)(十三)Item的交叉参考(Cross Reference)(十四)Item 创建的模板(Template)(十五)Item的目录组(Catalog Groups)(十六)Item的待定状态(Pending Status)(十七)Item 的属性组织间查看与复制(十八)Item的删除(十九)Item的其它来源方式三、供应商(Supplier)(一)供应商的分类概述(二)供应商“名称与编号”(Supplier Name/Number)(三)供应商的“地点”(Site)(四)供应商的“分类”属性(Classification)(五)供应商的“接收”属性(Receiving)(六)供应商Site层的“一般”属性(七)供应商Site层的“联系人”属性(八)供应商的多组织支持(MOAC)(九)供应商(Site)的“采购”属性(十)供应商(Site)的“控制”属性(Control)(十一)供应商(Site)的“付款”属性(Payment)(十二)供应商(Site)的“会计”属性(十三)供应商(Site)的“银行账户”属性(十四)供应商(Site)的“发票税”属性(十五)供应商(Site)的“预扣税”属性(十六)供应商(Site)的“纳税申报”及“EDI”属性(十七)R12的供应商定义与维护(十八)供应商的合并四、客户(Customer)(一)客户数据管理概述(二)EBS 交易社区架构(TCA)(三)客户的配置文件分类(Profile Class)(四)客户的创建规则(五)客户的多组织控制(MOAC)(六)客户的交易方层属性及交易方关系(七)客户的账户层与地点层属性(八)客户账户层的“分类”分组属性(九)客户账户层的“市场营销”分组属性(十)客户账户层的“关系”分组属性(十一)客户账户地点层的“特性”分组属性(十二)客户账户与地点层的“通信”分组属性(十三)客户账户与地点层的“联系人”分组属性(十四)客户账户与地点层的“联系人:职责”分组属性(十五)客户账户与地点层的“银行账户”分组属性(十六)客户账户与地点层的“付款方法”分组属性(十七)客户账户与地点层的“配置文件:事务处理”分组属性(十八)客户账户与地点层的“配置文件:单据打印”分组属性(十九)客户账户与地点层的“配置文件:金额”分组属性(二十)客户账户的“地址地点与业务目的”属性(二十一)R12客户的账户层与地点层属性(二十二)客户数据的合并(二十三)客户数据的其它管理功能五、结语一、EBS主数据概述(Master Data)一个有趣的现象是,与SAP相比不同,ORACLE EBS系统中并没有明确的所谓“主数据”(Master Data)概念,ORACLE应用产品官方文档(中英文)中也几乎找不到这个词组。

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基础设置要点

ORACLE EBS 基础设置要点简介一、安全性管理从系统使用角度来看,系统管理的一项重要的日常工作是关于“用户”及其“权限”的管理,在ORACLE中即所谓“安全性”(Security)管理。

“安全性”是一个涵义较之“权限”更为丰富、更为广阔的概念术语,它虽然比较抽象,但顾名思义,它很好地涵盖了于实际业务与系统使用中,有关企业数据与信息管理的某些需要重点保护、控制的容。

有关用户权限的管理,在ORACLE系统中主要有三个基本要素构成:菜单(Menu)、责任(Responsibility)、以及用户(User)。

三者的有机结合构成了系统权限或安全性管理的基础,辅之以参数或“安全性配置文件”等的使用,则进一步对用户的“实体(组织、帐套或分类帐)接入”权限进行细分。

此外,系统在各个应用模块中,还将可能基于不同业务特点采取各具特色的系统实现方式,对用户的准入管理或功能权限作更进一步的划分(具体方式与系统设计者的个人偏好也有一定关系,不能一概而论)。

“菜单”(Menu)在今天信息时代的日常生活中已是一个很普通的术语。

ORACLE中的“菜单”概念并无甚特别,它也是表示用户的系统应用功能入口。

最基本的“菜单”由系统预置的若干“表单功能”所组成,EBS目前大概具有2万个左右的此类表单功能;(基于某些特殊需要,系统还可提供虽不可见但可由表单包含的逻辑调用的某些非表单“子功能”,需开发后台设置)。

用户可以自定义包括若干基本菜单作为“子菜单”的用户菜单,自定义的“用户菜单”也可以作为“子菜单”来使用,这样就形成了一个菜单结构(树形图)。

如图1所示菜单定义及可选择使用的系统预置表单功能LIST:EBS系统在安装好后,针对每个应用模块均已经预定义包括所有功能(或权限)所谓的“超级用户菜单”(Super User Menu),企业(系统管理员)在定义用户“责任”时可利用“排除法”来满足实际的业务管理需要。

此外,系统还提供了“仅具查询”功能的预定义菜单,供某些需要限制做业务的用户使用。

ORACLE EBS 基础设置要点简介

ORACLE EBS 基础设置要点简介

ORACLE EBS 基础设置要点简介一、安全性管理二、会计科目弹性域结构三、帐套(分类帐)四、组织架构(一)业务组(BG)(二)法律实体(LE)(三)业务实体(OU)(四)库存组织(INV)(五)公司成本中心(Cost Center)(六)HR组织(七)多组织接入控制五、基础数据(一)关于“日历”(二)关于“币种”(三)关于“汇率”(四)关于“单位”(五)关于“地点”六、并发管理七、工作流八、系统初始化设置(一)关于安全性。

(二)关于配置文件(三)值集与弹性域(四)分类账(帐套)与组织架构(五)单据编号(六)层次性设置结构九、结语(注:网站批量发图有问题,上传后显示不清楚。

点击图片打开后,质量尚可)首先需要说明的是,本系列文档假定读者已经具备基本的系统相关使用知识与技能(例如,能够基本领会“ORACLE EBS系统应用基础概述”中的内容),故所讨论的内容仅限于笔者认为从系统使用与实际业务两方面来看比较重要或者容易存疑的问题,并不能面面俱到,旨在帮助读者掌握核心、抓住要点(详尽内容必须参考ORACLE相关官方文档)。

文中为讨论需要所附图文均取自ORACLE EBS 的测试环境(Vision Demo),版本以R12.1.1为主,辅之以版本R11.5.10,界面语言主要为中文(必要时辅之以英文)。

两个EBS版本在界面与功能应用方面实际可能有一些差异,必要时会作相关说明,但一般不会影响对基本问题的讨论。

技术是业务的抽象与工具,业务是技术的来源与目的。

本系列文档通篇将秉持“从业务的角度去审视技术,从技术的角度去回归业务”的方法论(这里的所谓“技术”,意指“系统实现”),去探讨系统实现与业务实践的融合问题,以求逐步能达到技术与业务的融会贯通。

限于笔者的认知水平,有讹误或不正确之处,欢迎批评指正。

一、安全性管理从系统使用角度来看,系统管理的一项重要的日常工作是关于“用户”及其“权限”的管理,在ORACLE中即所谓“安全性”(Security)管理。

系列之三:ORACLE EBS 系统应用基础概述(B)

系列之三:ORACLE EBS 系统应用基础概述(B)

系列之三:ORACLE EBS 系统应用基础概述(B)Oracle ERP 2010-08-09 16:23:59 阅读133 评论0 字号:大中小订阅ORACLE EBS 系统应用基础概述三、事务处理(Transaction)四、并发流程(Current Process)五、文件夹(Folder)六、弹性域(Flex field)七、值集与查找代码(Value Set and Lookup Code)八、配置文件(Profile)九、单据编号(Document Sequence)十、工作流(Workflow)十一、预警(Alert)十二、应用开放接口(Open Interface and API)十三、结语(注:网站批量发图有问题,上传后显示不清楚。

点击图片打开后,质量尚可)三、事务处理(Transaction)如果说上述EBS的“表单与查询”的系统设计体现的正是“从业务到技术”,比较容易理解与掌握,那么,所谓“事务处理”则是体现系统“从技术再到业务”的一个典范,相对而言,理解起来要困难很多,原因是无法直接在手工业务模式下找到相对应的处理方式与过程。

以库房接收采购物料为例,假定公司规定必须严格按PO来接收,并且公司为了严格控制库存水平,接收必须小批量、多批次,则库房人员就可能需要针对同一个PO在短时期内开出N多张的“入库单”,工作量很大。

为了减少工作量、提高效率,库房人员可能会在供应商每次送货时,仅在找出来的PO纸面单据上只简单地做一个数量标识,最后累积起来汇总开一张“入库单”。

但这种“图省事”的做法显然是一种“很不规范”的处理方式,虽可以提高工作效率,却会因为容易带来很多其它管理问题而在实际工作中不被允许。

ORACLE 系统通过提供一个“事务处理”工作界面则很简单地解决了上述难题。

如下图9所示采购接收的事务处理工作界面:类似于“收货时直接在PO纸面单据上简单地做数量标识”,每次供应商送货来时,库存人员只需在系统中查找出对应的PO,简单地输入送货数量并保存,则系统会在后台自动生成“事务处理记录”(等同于是“入库单”)。

oracleebs简介

oracleebs简介

oracleebs简介哎。

现在这年头,只搞db⼈越来越少,dba的地位越来越低。

没办法。

为了⽣存,哥哥决定再跨⼀个新的领域,去oracle的应⽤领域去学oracle ebs去。

开⼯:ebs的内部技术架构:简单概括为如下⼏个部分:多组织、多语⾔、多币种、模块化,集成性、并发处理、多技术混⽤。

我们看⼀下ebs R12的服务器架构组成:2、名词解释ERP系统中有很多职能集成所必需,但⼿⼯管理⽅式下所没有的重要名词。

以下⼀⼀解释这些名词的意义及功能。

1.现存量(On Hand Quantity)即仓库中现有料品(成品、半成品、采购件)的库存数量。

如果按英⽂直译叫做“在⼿量”,所以现存量表⽰⼀个已经拥有的料品的数量。

2.在单量(On Order Quantity)假设本公司向供应商发出⼀张采购订单,采购A料品300个库存单位,这时我们就可以说料品A的“在单量”为300个库存单位。

在单量表⽰“已经计划好了将来要有,但⽬前还未真正拥有的数量”,直观地把它想象成是⼀个“在单据上的”数量。

(1)对采购件⽽⾔:指已下采购订单⽽供应⼚商尚未交货(验收⼊库)的数量。

(2)对⾃制成品、半成品⽽⾔:指已下⽣产订单⽽制造车间尚未完⼯⼊库的数量。

(3)对委外件⽽⾔:指已下达委外单⽽委外⼚商尚未交货(验收⼊库)的数量。

3.预约量(Allocated Quantity)如果客户向本公司下单订购A产品100台,双⽅约定20天后交货。

这时产品A的“预约量”就为100台。

“预约”表⽰⼀种“将来要发⽣⽽现在还没有发⽣的”需求量。

为什么在接到客户订单时,电脑系统要记录客户订购产品的“预约量”呢?因为预约量代表⼀种“待发”的数量,可以让我们事先预估料品将来的现存量是否会不⾜,⽽针对可能发⽣的缺货状况预作准备。

(1)对采购件⽽⾔:已发⽣产订单或委外单,要领⽤⽽车间或委外⼚商尚未领料的数量。

(2)对成品⽽⾔:已接到客户订单⽽尚未交货的数量。

(3)对⾃制半成品⽽⾔:已发⽣产订单或委外单,要领⽤⽽车间或委外⼚商尚未领料的数量。

ORACLE OBS系统应用基础

ORACLE OBS系统应用基础

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工作的人员,若从个人背景角度来看,通常可以划分为“技术出身”与“业务出身”两类。

  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视图界面可以再选择打开相关条目的表单。

相关文档
最新文档