ORACLE-EBS-系统主数据管理(一)

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