系列之五ORACLEEBS系统主数据管理基础介绍.doc

系列之五：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应用产品官方文档（中英文）中也几乎找不到这个词组。因此这里要讨论的所谓“主数据”，主要是基于业务管理与系统应用层面而言，具有全局性、重要性的那些基础业务数据，诸如物料、供应商、客户等等。
之所以会出现上述现象，推测是和ORACLE产品的发展历史有一定关系，或许ORACLE早先确实没有意识到物料、供应商及客户等等业务数据，在系统管理与业务实践方面具有怎样的特殊性，以至于如今许多初学者会觉得奇怪：EBS系统的最初设计，物料是在INV模块中定义的，供应商是在AP模块中定义的，客户是在AR模块中定义的。而不是采取更合理的系统应用架构设计：主数据有专门的定义与管理应用功能，作为“服务”提供给相关应用模块调用（即类似所谓“SOA”架构）。
显然，ORACLE后来意识到了这个问题，并开始逐步在系统的规划设计方面做调整。针对“客户”等主数据管理，于2001年首次提出了所谓“TCA架构”（Trading community Architecture），并首先将“客户数据”独立出来，作为一个向其他相关模块提供调用服务（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”等等。具体类型（Item Type）是根据企业业务管理需要定义的，如下图1所示：

Item Type 的LOV是在Lookup Code 中定义的，访问级别是“用户”，即完全属于“自定义”，只有统计分析功用，并不参与系统流程构建，对业务流程没有影响。如下图2所示：

在EBS系统中，Item一经创建就无法轻易删除（必须使用特定的清理功能才可以。后面再介绍），但可以选择通过改变其“状态（Item Status）”来控制其相关的可用性，如下图3所示：

Item Status 的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”。表面上看来，两者好像是一样的，区别不大，但实际上两者在系统设计理念上已经起了根本性变化。
在ORACLE EBS中，“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数量失去控制，系统业务处理逻辑复杂化而变得难以使用。
上述两条物料编码管理原则，对于许多缺少相关业务经验的人来说，理解起来可能难度较大。不过，对于大多数人来说，只要懂得所谓“Item编码”主要还是ERP核心系统之外的工作，高端的ERP产品（ORACLE/SAP）要求Item编码必须遵循上述两条基本管理原则就可以了。至于这两条编码管理原则如何贯彻执行，则涉及到有一定深度与广度的专业知识，与企业的管理实践密切相关，最近几年高科技电子行业出现一个称为“Commodity管理”的专门岗位，正是与此有关。十多年前，国内的通信企业华为公司开始引进国外的先进管理经验，拜请IBM为师，最初数千万元的咨询顾问费也就仅是围绕所谓“Commodity管理”，这一看起来不起眼、实际展开内容却十分丰富的领域来展开的。详细讨论物料的所谓“Commodity”管理非本文所能胜任，以下仅简单介绍几个比较常见且重要的问题。
关于系统的Item编码长度。经验表明，编码的长度以6-8位为宜，短了则可能容量不够，长了则不方便记忆、影响使用。编码应以数目字为主，必要时辅之以英文字母，不应当出现单词或词组，中文就更不应该出现了。一个编码通常分为前后两部分，前半部分（3-4位）表示物料分类，后半部分（3-4位）则是流水码。
关于系统的Item编码中的分类。首先，不要将Item编码中前半部分的“分类”与EBS系统中的Item Category（类别） 混为一谈，两者有一定联系但差别也很明显。前者代表的是基于“用途”的Item的自然或物理属性，是确定的；后者则更多的是体现企业的“管理”属性，可以根据需要随时作调整。从实际使用角度来看，一般规定Item中的一个“分类组合”只能隶属于一个确定的Category，但一个Category可以包含多个Item编码中的分类组合。
如今大多数人已经认可Item的编码“不包含业务涵义但应适当分类”的原则。过去各企业的物料分类五花八门，没有一定标准，这给电子商务时代的信息交流与互换造成了很大障碍。为此，1998年联合国开发计划署（UNDP）委托邓百氏咨询公司（Dun & Bradstreet）开发并维护全球产品与服务的分类体系，提出了“联合国标准产品与服务分类代码United Nations Standard Products and Services Code”，简称UNSPSC。应全球电子商务发展的要求，2003年5月UNDP正式委托美国统一代码委员会(UCC)全权实时维护和管理UNSPSC。目前已有上百个国家和地区的上万家公司在使用。2003年12月，美国统一代码委员会Uniform Code Council（UCC）正式授权中国物品编码中心Article Numbering Center of China（ANCC）独家负责UNSPSC中文版本的全部工作。ANCC成立了UNSPSC动态维护管理中心（UNSPSC－China）。
l UNSPSC覆盖了国民经济各行各业，共设置了：55个大类，351个中类，2015个小类，19000多个细类产品(V6.0315版本)。分类依据基本上都是根据产品的“用途”进行分类的。即按照使用目的进行分类，每层结构内的顺序，基本是没有任何含义的，和产品与服务类别名称的语序也无关。UNSPSC采用四层八位的数字层次码结构，代码结构如下：　　Ⅹ1Ⅹ2Ⅹ3Ⅹ4Ⅹ5Ⅹ6Ⅹ7Ⅹ8。其中：
　　Ⅹ1Ⅹ2　　第一层，大类（Segment），用于分析商品与服务种类的逻辑组合；
　　Ⅹ3Ⅹ4　　第二层，中类（Family），一种通用的内部互相联系的商品和服务种类；
　　Ⅹ5Ⅹ6　　第三层，小类（Class），具有共同用途和功能的一组商品和服务；
　　Ⅹ7Ⅹ8　　第四层，细类（Commodity），一组可选用的商品和服务。
对于一个确定的物料来说，一定是属于UNSPSC中的一个“大类+中类+小类+细类”的8位数字的组合代码，例如31101501，它的编码的组成如下：
　　大类(Segment) ：制造业部件和用品(Manufacturing Components and Supplies) -- 31
　　中类(Family)： 铸件(Castings) -- 10
　 小类(Class)：压模铸件(Die castings) -- 15
　　细类：(Commodity)：铝压模铸件(Aluminum die castings) -- 01
为了达至全球性的物料分类统一与标准化，方便企业之间的沟通交流与数据交换，一个企业应当对照UNSPSC的分类定义，对涉及到的所有外购物料以及自产部件、半成品或产品进行准确分类。企业如果开发出一种“全新”的部件或产品，且发现不能在UNSPSC中找到合适的分类，则可以按规定程序向相关管理机构（例如UNSPSC—China）提交物料分类编码的新增申请。整个申请过程耗时可能很长，如果被拒绝，UNSPSC会建议使用现有分类，如果被接纳，则最终需要提交美国UCC批准。
但需注意的是上述UNSPSC 的8位分类编码，不应当被企业直接用来放进Item编码中（例如UNSPSC+流水码），这是因为一来UNSPSC细类（Commodity）数量太多，目前已达两万多个，每个企业实际真正能用到的只是其中很少一部分（一般数百个Commodity），例如一个电子制造业不到可能会用到类似“10101512”（兔子）的Commodity。二来8位分类码再加上流水码（一般是4位），Item编码总长度太长，不方便使用。
UNSPSC针对8位分类码也给出了只有6位的“识别码（Unique ID）”，但这个6位识别码（实际也是流水顺序码）仍然过长，不方便使用。如下图（表）5所示：

企业一般需要根据自己会使用到的那些8位UNSPSC分类码，个性化制定企业自己的分类“识别码”。通常取4位，前两位代表“大类”，后两位代表“小类”（注意这里的“大类/小类”与UNSPSC中的“大类/小类”没有对应关系，只是为了方便企业对已选取的UNSPSC的管理）。Item中的前4位分类识别码，即使全使用数目字（不使用英文字母），最多也可有1万种组合（3位有1000种组合，一般中小企业也足够），足以满足单个大企业的物料分类需要。不同企业的Item中的分类识别码尽管不同，但由于它们都对应于同一的UNSPSC分类码，故数据交流与互换不会有问题。
尽管UNSPSC出台及全球推行只是近几年的事，远落后于ORACLE ERP产品的发布时间，但EBS 很早就在其产品安装后的初始化状态预置了物料的“Commodity”概念（例如Item类别弹性域系统预置的“Category—Commodity”结构。尽管这不是系统应用必需，可以改掉）。但ORACLE这样做的目的实际上也就是希望将企业的物料管理运作实务引导到所谓“业界最佳业务实践（Best Practice）”上来。
关于代表广义的Part的系统Item编码与狭义的Material的关系问题。广义的Part编码是指只要符合“规格Form、性能Fit、功能Function”相同的物料，即使某些重要属性不相同（例如颜色、生产厂家、质量指标等等），只要不对3F的一致性有重要影响，均归属于同一个Item。狭义的物料Material编码则是指即使是3F相同，但如果某些重要属性不同（典型的是生产厂家不同），也不能归入同一个Item。
能否分清Part编码与Material编码之间的本质区别，不仅体现在一个企业的Item编码方式的选择上，反映一个企业对物料编码的认识水平，更重要的是它还能反映一个企业的产品研发的技术水平。国内有些电子制造企业（尤其是“代工型”企业）之所以选择的是material型（或曰“工程型”）的Item编码方式，一个很重要的原因是早期企业没有技术能力进行Material的容差设计与分析，为保险起见只好采取“同一物料只要厂家不同”就是不同Item。实际工作中为了使用方便，不得已又将生产厂家等诸多信息放入Item编码中，如此恶性循环，最终使得公司的物料管理陷入十分恶劣的混乱状态而难以自拔。
国内某年产值超千亿RMB规模的大型代工型电子制造企业，由于早年研发技术水平有限，加之不懂所谓“Commodity 管理”，对物料编码的认识水平很低，初期开始采取的就是“不同厂家一物一号”的“工程型”编码方式，待累积到Item的有效数量超过三、四十万，并且每月还在以一万多数量快速增加的时候，才意识到问题的严重性。尽管后来累积投入数亿元的费用试图进行改造，但已经积重难返，还是无法从根本上解决问题。而反观象IBM这样的超大型企业，尽管其产品线十分丰富，年收入达千亿美金（其中硬件收入约占一半），但其全球有效Item数量一直控制在6万左右。几年前，国内的华为公司拜请IBM为师，花费数亿元搞集成产品开发IPD项目，其项目核心目标之一就是要将华为当时9万左右的Item数量下降20%。
目前国内某些ERP产品在其系统物料定义界面出现“生产厂家、型号”字段并且只能唯一赋值，客观上会将企业的物料编码方式引导到“同一部件不同厂家不同Item编码”的低水平道路上去。这说明其在物料编码的系统规划设计方面的认识水平还有待提高。而在ORACLE 系统中，在Item定义界面则明确给出了Item与制造商部件号（MPN）的“一对多”的可能对应关系设置（具体设置下面再谈），这对于有效地避免企业采用错误的编码方式，促进企业Commodity 管理水平的提高将十分有帮助。

（三）Item 的类别（Category）
上面所讲到的Item编码中的分类（UNSPSC），一般来说还不是系统（各应用功能模块）中真正使用到的类别，原因是编码中的分类所基于的分类基准（或用途）主要考虑的是“工程”目的，而各应用模块例如INV、PO等中所需使用的分类更多地是需考虑业务管理目的，这就好比我们将“人员”分类，有时需按“性别”（男、女）分，有时需按“学历”（博士、硕士、学士）分，有时还需按“年龄段”（老年、中年、青年）分等等。
对于EBS中一个确定的Item来说，可以同时具有多个不同的“类别集（Category Set）”，以满足各个应用模块的使用需要。这里之所以称其为“类别集”，源于其中包含若干个LOV值，系统将每个具体的LOV值称之为“类别”（Category）并最终分配给Item。EBS的每个相关应用模块必须设定默认关联一个“类别集”，称之为“默认类别集”。如下图6所示：

不同应用模块所使用的“默认类别集”可以相同也可以不同。用户在进入相关业务模块的“表单”界面时，打开的Item类别的弹性域结构取决于“默认类别集”所关联的类别键弹性域结构定义。在“≤ORACLE系统与实践≥系列之三：EBS的基础设置要点简介”中，关于“Item类别弹性域结构”的介绍已经说过，系统安装初始化时，ORACLE已经基于“业界最佳实践经验”，预设了若干不同的“类别弹性域结构”，这些不同弹性域结构同样也被ORACLE在“默认类别集”定义界面中预设了相应的关联（上述系统安装预设，用户如不满意，均可以修改）。这无疑大大方便了用户的使用，也正是ORACLE产品包含丰富管理思想的体现所在。
对于每一个被使用的“类别集”，需要进行定义或对系统预设进行修改完善，每个类别集关联一个已经预先定义编译的“类别键弹性域结构”。如下图7所示：

上图7中，如果选定“允许存在多个物料类别分配”，则可以将一个物料分配给某个类别集内的多个类别。这主要是用于某些特殊功能的情况，如“装箱”功能中的“创建装箱组”，定义一个“危险”类别集，将某个物料同时分配给“毒药”和“腐蚀物”类别。
上图7中，如果选定“强制使用有效类别列表”，则需要对其下的“类别列表”进行维护，其作用主要是控制PO界面的类别的LOV值（选择组合）只能存在于这里的定义列表中时才有效（否则会报错提示）。
上图7中的“人员类别”窗口的作用，是为了控制某些类别只允许特定“责任/人员”才可以访问（未设定则不做限制）。上图中的“分配”窗口，只是提供一种将多个“类别”快速成批分配给（包括维护）多个Item的工具。在单个Item定义时分配类别的结果，会显示在这里，这里所做的维护改变也会反映在定义Item时的分配类别界面中。如下图8所示为Item定义时的类别分配界面：

此外，为进一步控制上图7与图8中定义或设置时具体类别Category组合的实际可用性（在弹性域定义中可能已经通过值集验证进行设置，这里提供补充控制功能），系统通过专门的定义类别可用性功能，内容包括是否启用、是否为i-Procurement启用（仅适用于R11）、供应商是否可查看（用于i-supplier）、Web申请是否可用，来根据实际业务需要对Category的可能代码组合做更为细致，也更为灵活的限制。如下图9所示：

总之，EBS中的Item 的类别Category非常关键、非常重要，系统的其它相关功能如权限控制、审批设置以及费用账户等等（以后在相关应用功能模块中再详细讨论）均会基于物料定义时的Category设置来进行，它与所谓物料的“Commodity管理”相结合，提供了企业业务管理所需的强大系统功能，是“业界最佳实践经验”的总结与结晶。
（四）Item的单位（UOM）
在“≤ORACLE系统与实践≥系列之三：EBS的基础设置要点简介”中，关于“单位设置”的介绍已经说过，EBS的单位及其换算关系是定义在INV组织之上并且可以与特定物料相关的。在Item定义中，可以为之指定“主要单位”（Primary）与“辅助单位”（Secondary），并且规定两者换算所允许的偏差系数（Deviation Factor）。这主要是为了满足实际工作中某些特殊物料的特殊计量需求，某些液态的化工原料如乙醇、汽油等，计价、储存可能是按吨、公斤或桶来计量的，但实际使用则可能是按“升”来计量，例如国内加油站进货按吨计，给车加油时按升计。由于两者的换算关系可能受不同场合“温度、压力”等因素的影响，实际计量与原先“标准”条件下定义的换算关系存在一定偏差。系统对于所产生的这种偏差必须有明确的规定。
在EBS的Item定义中，在“主要”（Main）标签页（Tab），针对单位（UOM）主要是就库存余额数量的“跟踪”（Tracking）、产品定价（Pricing）的计量，如何进行事务处理做了规定，如下图10所示：

上图10中的几个字段“跟踪、定价、辅助、默认、正负偏差系数、转换”的取值关系颇为复杂，建议参考ORACLE相关官方文档（INV UG）。其中的一个可能结果是，只要手工输入的辅助单位的计量实际值与主要单位的计量值的实际换算关系在规定的偏差范围内，系统均当成标准换算关系进行处理，这对于库存数量余额的准确跟踪及产品正确定价将十分重要。
（五）Item 的制造商部件号（MPN）
前面在讲Item编码时已经提到，EBS中的一个Item可以对应多个制造商的MPN，这是所谓物料的“Commodity管理”的重要内容。要做到这一点，在EBS中首先需定义制造商及其MPN的值。如下图11所示：

注意，不要将制造商（Manufacturer）与系统中的供应商（Supplier）混为一谈。制造商有可能也是供应商，但在系统中两者是分开设置的，没有连接关系。上图11中的制造商列表值是直接手工输入的，每一个制造商在“部件”（Parts）界面需要手工输入该制造商的“部件号”并与系统Item相关联。这里的Item与MPN的关联定义也可以在Item定义显示和维护，如下图12所示：

上图12中MPN设置的制造商取值，不可以手工输入，只能以图11的定义制造商列表作为其LOV，但“部件”字段可以手工维护，其作用与图11中的“部件”设置界面相同。
（六）Item的版本（Revision）
物料的版本管理对于实际业务及系统管理都是一项基础性工作，EBS在Item的定义界面提供了物料的版本维护功能。如下图13所示：

系统使用字母、数字和字符（如 *、& 和 #）来标记版本。其中字母必须大写，数字可以包括小数点。为确保版本正确地排序，小数点后应该使用数字。有效版本包括：A、B、 01、 02、 A1、 B1、1A、1B、0.0、 0.1、A.0、 A.1 等。版本按 ASCII 规则进行排序，每个版本号必须高于它的上一版本。按照 ASCII 排序规则，10 排在 9 的前面，因此在版本 9 之后不能使用版本 10 来定义下一版本。
除了在Item定义窗口维护版本信息外，EBS系统在物料清单（BOM）及工程更改单（ECO）也可以对Item的版本进行维护，维护的结果在三处的最终显示是相同的。
（七）Item的组织控制（Master Org）
前面关于Item的一些基本概念的介绍，均没有涉及Item的组织控制问题。ORACLE的Item定义是基于INV组织的，这是其早期有关“主数据”管理的一个重要特点。以前，另外两个主数据“客户、供应商”也是基于确定的组织（OU）来定义设置的，但从R12开始，客户与供应商的初始定义已经开始独立于组织（OU，上下文环境）来进行，然后再分配给相关组织（OU）使用。
既然客户与供应商的主数据系统管理方式已经做了调整，为什么Item的主数据管理方式却保持不变呢？推测的原因可能是，一来Item的影响面太广，改动太大，不方便进行；二来原Item的主组织（Master Org）定义方式也有其独到的优势，它在处理一些实际与库存事务关系不大的“服务类或费用类”Item的工作过程中比较方便，例如PO在做服务类或费用类Item的接收时，可以直接基于“主组织”（可能是虚拟的，并不与管理实体对应）来进行，可以与库存类的Item的接收方式保持一致，无需另外做特殊考虑。
在ORACLE EBS系统中，系统虽然允许设定多个“主组织”来定义Item，然后再将Item分配给多个INV组织使用，但ORACLE强烈建议系统只设定唯一的主组织，而这一点与实际工作中的“主数据”集中管控的要求也是一致的。当在系统中设置INV组织时，在INV组织参数窗口的“物料主文件组织”字段，可选的LOV值包括当前INV名本身，以及已经被其它INV设定为“主组织”的INV名。一旦用户选定当前INV名作为主组织，则在设置其他INV的组织参数时，也可以在主组织可选LOV值中见到它。
EBS的“主组织”使用是不受帐套（科目弹性域结构）、业务实体的范围限制的，具有不同帐套/业务实体的INV可以具有同样的Item主组织。“主组织”的这一特性为大型企业Item的集中管控工作的开展提供了极大的方便性与高度的灵活性。用户在进入INV模块（或其他基于INV的应用模块）时，均需选择一个确定的INV，以进入确定的INV上下文环境。一旦进入INV，则其Item的主组织就已经唯一确定（由该INV组织的参数定义决定）。被选定作为“主组织”的INV作为“业务功能”组织使用时，与其它INV并无任何区别。唯一的特殊之处在于，定义主组织Item时，在“组织分配”界面无需再向“组织层”的自己作分配（系统已经默认分配），但有关“属性控制”的设置，仍然与其它被分配的INV组织完全一样。如下图14是Item定义中的“组织分配”界面：

所有Item均只能在其“主组织”界面（并非指必须进入主组织所在的上下文）定义后，才能分配给相关的INV组织使用。上图14中可以分配的INV列表取决于每个INV组织参数定义的“主组织”与当前INV（上图14中的第一行）的“主组织”是否相同。除了当前INV组织，其余INV组织的“组织属性”窗口均可以另外打开（当前INV组织的组织属性窗口实际已经打开，在Item定义界面的“组织”与“主组织”间直接切换），以便定义属于本组织的相关属性。
EBS系统在Item的“主组织”（Master Org）与组织（Org）之间，提供了相关“属性”如何控制的机制。如下图15所示：

上图15中，组名字段会显示属性组的名称。属性按功能分组，例如主要、库存和接收。在定义或更新物料、定义模板或查看物料属性时，可以显示特定组的属性，这样可以更容易地查找特定属性。“控制地点”可以在“主层”与“组织层”间选择。主要层：在主要层定义和维护此属性，对于同一物料，此属性的值在所有组织中均相同；组织层：在组织层定义并维护此属性，对于同一物料，每个组织均可为此属性定义一个不同的值（某些属性只能在特定层设置，在这些情况下，只具有一个选项）。
对于某些“状态属性”，系统除提供“主层”与“组织层”的控制地点选择外，还提供“状态设置”控制方式的选择：“默认值、不使用、设置值”。这需要与前文所述“物料状态”的控制方式的设定结合使用。可以设置控制方式的“状态属性”共10个（如图4中所示），包括：允许BOM、在WIP中制造、启用客户订单、启用内部订单、启用开票、启用执行流程（应用于“流程制造”）、启用配方（应用于“流程制造”）、可采购、可储存、可处理。Item的状态属性与其它属性或相互之间可能有一定的制约关系。例如，如果将库存物料设置为否，则不能将可储存设置为是。
（八）Item的属性及相互关系概述
物料Item广泛使用于企业实际工作中的方方面面，为了达致业务流程运作的规范化、标准化、自动化，实现企业“实物流、资金流、信息流”的统一，就必须在系统中对Item的相关流程属性作统一的、预先的设置。它是企业管理实践与业务流程运作如何实现“集中统一”的典型体现，是管理信息系统具有强大功能与高度灵活性的核心基础。因此，它也是系统实施与应用的关键步骤。
EBS的Item可定义（或必需定义）的属性值总数多达300多个，为了方便对这些属性的管理，EBS按属性的“流程功能”进行了分组，目前一共分为17个属性组（即Item定义界面的Tab标签页），包括“主要、库存、物料清单、资产管理、成本计算、采购、接收、物理属性、总计划、MPS/MRP计划、提前期、在制品、订单管理、开票、流程制造、服务”。
这些Item的属性分组（Tab页）大体上与系统的应用模块有一定的对应关系，相关业务模块使用时，有关Item的基础设置主要与相对应的属性Tab页内容有关。
每一个属性组有若干可定义属性值（字段），其中一部分属于“必需项”（一般均有默认值，可修改），另一部分则属于“可选项”（可留空）。一部分是属于“业务控制”属性，可以直接用于控制系统中的相关业务操作，如“可采购、可储存”等等，另一部分则是属于“流程控制”属性，可以直接或间接控制所使用的具体业务流程种类或方式，例如“计划方法、BOM物料模型”等等，还有部分属于“参考引用”属性，主要是向有关单据提供默认的参考值。某些属性之间具有确定的关联性，一旦定义了其中一个值，其余相关属性的值也就随之确定。关于属性间相互关系的具体内容，比较复杂，必须仔细参考ORACLE相关应用文档（如下述各表，仅供参考）。这些特定属性间的特定关系分为四大类：
（1）要求的属性值：
如果某些相关属性具有下表所示的值，则必须输入特定属性的值：
属性
条件
需求时间范围天数
将需求时间范围设置为自定义
保留款帐户
将“冲销保留款”参数设置为是
费用帐户
将库存资产值设置为否并将库存物料设置为是
外协加工单位类型
将外协加工物