《系列之五-ORACLE-EBS-系统主数据管理基础介绍》由会员分享，可在线阅读，更多相关《系列之五-ORACLE-EBS-系统主数据管理基础介绍（38页珍藏版）》请在金锄头文库上搜索。
1、.系列之五：ORACLE EBS 系统主数据管理AORACLE 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
2、十五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的会
3、计属性十三供应商Site的银行账户属性十四供应商Site的发票税属性十五供应商Site的预扣税属性十六供应商Site的纳税申报及EDI属性十七R12的供应商定义与维护十八供应商的合并四、客户Customer一客户数据管理概述二EBS 交易社区架构TCA三客户的配置文件分类Profile Class四客户的创建规则五客户的多组织控制MOAC六客户的交易方层属性及交易方关系七客户的账户层与地点层属性八客户账户层的分类分组属性九客户账户层的市场营销分组属性十客户账户层的关系分组属性十一客户账户地点层的特性分组属性十二客户账户与地点层的通信分组属性十三客户账户与地点层的联系人分组属性十四客户账户与地点
4、层的联系人：职责分组属性十五客户账户与地点层的银行账户分组属性十六客户账户与地点层的付款方法分组属性十七客户账户与地点层的配置文件：事务处理分组属性十八客户账户与地点层的配置文件：单据打印分组属性十九客户账户与地点层的配置文件：金额分组属性二十客户账户的地址地点与业务目的属性二十一R12客户的账户层与地点层属性二十二客户数据的合并二十三客户数据的其它管理功能五、结语一、EBS主数据概述Master Data一个有趣的现象是,与SAP相比不同,ORACLE EBS系统中并没有明确的所谓主数据Master Data概念,ORACLE应用产品官方文档中英文中也几乎找不到这个词组。因此这里要讨论的所谓
5、主数据,主要是基于业务管理与系统应用层面而言,具有全局性、重要性的那些基础业务数据,诸如物料、供应商、客户等等。之所以会出现上述现象,推测是和ORACLE产品的发展历史有一定关系,或许ORACLE早先确实没有意识到物料、供应商及客户等等业务数据,在系统管理与业务实践方面具有怎样的特殊性,以至于如今许多初学者会觉得奇怪：EBS系统的最初设计,物料是在INV模块中定义的,供应商是在AP模块中定义的,客户是在AR模块中定义的。而不是采取更合理的系统应用架构设计：主数据有专门的定义与管理应用功能,作为服务提供给相关应用模块调用即类似所谓SOA架构。显然,ORACLE后来意识到了这个问题,并开始逐步在系
6、统的规划设计方面做调整。针对客户等主数据管理,于2001年首次提出了所谓TCA架构Trading community Architecture,并首先将客户数据独立出来,作为一个向其他相关模块提供调用服务SOA的基础应用。不过,迄今为止,对于供应商与物料,目前表面看来与过去相比几乎没有什么变化,但相信随着SOA的发展,系统以后也会做出调整完善。从企业管理实践的需求角度来看,对于主数据的范畴,不同企业的理解可能有一定差别,例如有些企业将BOM也包括在主数据之内。本文以下则重点讨论无可争议的三个常用主数据：物料、供应商与客户。这三个主数据都有一个共同的系统使用特点：跨组织的全局性。而对于BOM数据
7、,尽管在企业实际管理工作中,可能具有一定的全局性特点例如不同工厂生产同样产品,但从系统应用角度来看,BOM是严格按INV组织隔离的,不同INV可共用的部分比较少,BOM系统应用的全局性特点并不十分明显,重要性也不是太高。二、物料Item物料Item数据管理以其应用的基础性与影响的广泛性,是EBS系统最重要也是最复杂的基础业务数据。企业尤其是大型企业,物料主数据的管理甚至可以上升到决定企业未来发展乃至生死存亡的高度。为此,ORACLE系统提供了完善的端到端的全流程解决方案。一Item 的范畴EBS系统英文原版中,物料是用Item来表示的,译成中文最初为项目,在文档表述中常常与另一个词Projec
8、t的中文翻译项目混淆,带来诸多不便。这方面XX将Project称之为专案,则非常方便,不会存在混淆的问题。R12中文版大陆将Item改为物料,虽说解决了容易混淆的问题,但却也带来了另一个问题：缩小了Item原先的内涵范畴。为表述方便,本文后续原则上以Item一词代替物料一词在EBS中,Item不仅表示有形的物料,同时还可以指无形的服务,例如表示顾问服务的计量人天、表示一个广告创意的campaign、表示一个售后服务的case等等。具体类型Item Type是根据企业业务管理需要定义的,如下图1所示：Item Type 的LOV是在Lookup Code 中定义的,访问级别是用户,即完全属于自定
9、义,只有统计分析功用,并不参与系统流程构建,对业务流程没有影响。如下图2所示：在EBS系统中,Item一经创建就无法轻易删除必须使用特定的清理功能才可以。后面再介绍,但可以选择通过改变其状态Item Status来控制其相关的可用性,如下图3所示： Item Status 的LOV值,系统提供了专门的表单定义功能,完全可根据企业需要定义每个状态代码对于Item属性起控制作用的具体方式,如下图4所示：图3中,当一个具体的Item值选定一个确定的Status后,其相关属性的修改方式就由图4定义中的控制方式决定,控制方式可能是三种默认值、设置值、不使用之一。默认值：在将状态分配给物料时,系统将默认状
10、态代码定义的属性值,用户可以更改此默认值；不使用：既不使用默认值,也不使用状态控制；设置值：在将状态分配给物料时,系统将默认状态代码定义的属性值。一旦分配了默认值,用户不能对其进行更改。例如图4中,允许BOM ,值：,使用：默认控制,表示具有该Status的Item,其允许BOM属性的值默认为YES,但用户可以更改。至于图4定义中,每个属性的控制方式具体取值即默认值、设置值、不使用中的哪一个,则又是通过Item属性控制定义功能来实现的。复杂了,打住！打住！,后面再来详细讨论这个问题。二Item 的编码几乎人人都知道物料编码的重要性,网上也有不少介绍如何管理物料编码的文章,什么机械行业物料编码、
11、电子行业物料编码等等,诸如此类,不一而足。然而,笔者不得不遗憾地指出来,这些文章大多没有能抓住物料系统编码管理的本质与要义,基本上还都是基于手工编码与管理的电算化系统设计与实现方式而言的。物料编码既是个非常简单的问题,也是个非常复杂的问题。说其简单,是因为所有企业,无论是使用什么样的管理软件,都需要给物料编码；说其复杂,是因为物料编码管理是一门涉及范围广泛,有相当深度的专业学问,远不是编码方式本身的那点内容。我们有时侯说SAP/ORACLE产品包含有丰富的管理思想与业界最佳业务实践,其实,从与Item编码有关的系统设计角度来看,恰恰就能验证这一说法。目前国内主流ERP产品的物料定义,通常都包括
12、两个基本内容物料编码Number、物料名称Name,并基于此引申出物料编码、物料名称不能重复,使用后不允许修改等等系统设计功能。ORACLE或SAP将所谓物料编码Number、物料名称Name变化成物料Item、物料说明Description。表面上看来,两者好像是一样的,区别不大,但实际上两者在系统设计理念上已经起了根本性变化。在ORACLE EBS中,Item被抽象成一个代表物料的具有唯一性的指示符,可以是一个数字或字符的代码,也可以是一个长度限定的短文本在系统内部该字段实际是一个键弹性域结构,不过实际使用多段结构的情况较少,一般设定成单段结构,与普通表单字段使用无异。但它并非是系统内部业
13、务流程所使用的唯一性识别ID,也就是说,当在系统中定义Item时,系统还会在内部自动生成一个用于系统识别的唯一性ID内码,外部所表现的Item外码只是其一个外部指示符不过,系统也要求其具有唯一性。在EBS的使用过程中,系统允许修改已经存在的Item编码,且如果改变了Item编码,并不会影响到该Item原在其它相关模块中的使用状况。例如：先定义一个Item,然后为此Item创建BOM,然后在Item定义界面查找出此Item编码并修改保存,再去查询BOM,则可以发现原Item已经不存在,代之以的是修改后的Item,并完全继承了原BOM定义。至于所谓Item说明Description,与Item本身
14、相比,系统除了不要求具有唯一性之外,其余方面几乎完全相同,它实际就是一个字符长度可更长一些的短文本,一般用之作为包括物料实际名称在内的对Item的简短说明。用涵义广泛的说明Description来取代涵义狭窄的名称Name,无疑使得系统使用具有了更为广泛的自由度。基于涵义比较具体的物料编码Number、物料名称Name的电算化系统设计与实现方式,自然会将企业实际的物料编码工作也引导到比较具体的实现方式上去如上面所提到的网文中介绍的内容。而基于比较抽象的Item的ORACLE系统设计与实现方式,则为企业的Item编码管理提供了更为灵活、更为方便也更为完善的扩展空间。但要理解清楚这一点,首先需要懂得基于业界最佳实践经验而总结出来的有关物料编码的两条重要管理原则：其一是,系统所使用的Item编码与工程上所使用的物料编码,不能混为一谈,两者的目的与用途不同,因而编码与管理方式也有很大不同。实际工作中尤其是在使用某些低端ERP产品时,很容易的犯的一个错误是,以比较好懂的物料工程编码代替比较抽象的系统编码。因而导致在编码数据量较大时,出现系统使用困难,用户深感不便,严重影响工作效率的现象。其二是,系统所使用的Item编码主要是针对工程上广义的部件Part而言,而不是针对狭义的物料Material。一个Part对应一个Item,但一个Part可能包含多个狭义的Material
