文档介绍：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 系统安装好了,进去一看傻眼了, 不知道从哪儿下手?发出惊叹的这位网友所遇到的问题,实际上也是很多人曾经遇到或正在遇到的问题。长期以来,国内的非专业人士(例如媒体)提及 SA P 或 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 ) 企业在手工模式下的业务运作过程中,总有各种各样的用于记录业务数据或管理信息的纸面单据,例如“销售订单、采购订单、入库单、出库单”等等。随着业务量的增加,这些纸面单据的数量是如此之多,以致于企业不得不花费大量人力,将每张单据上的重要信息摘要出来(例如采购订单上的供应商、物料、数量