系列之五：ORACLE_EBS_系统主数据管理

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