ORACLE EBS 系统主数据管理（物料，上）

杰夫之产业互联网 2021-07-05

6201

第4章ORACLE EBS 系统主数据管理

（物料，上）

4.1引言

所谓“主数据（Master Data）”，是指基于业务管理与系统应用层面而言，具有基础性、全局性、不可或缺的“主要”数据，诸如物料、供应商、客户等。对于一个企业来说，有了业务经营的“对象”（产品或物料），知道从哪里（供应商）购买，卖给谁（客户），就意味着已经具备了基本的业务经营条件；而对于一个信息管理系统来说，有了这些“主要的”核心数据，则表示系统据此可以衍生出各种与具体业务活动（事务处理）相关的业务数据信息，诸如采购订单、应付发票、销售订单、应收发票等等。

一个有趣的现象是，与SAP系统相比不同，ORACLE EBS系统中并没有明确的所谓“主数据”概念，ORACLE应用产品官方文档（中英文）中也几乎找不到这个词组。之所以会出现现象，推测是和ORACLE产品的发展历史有一定关系，或许ORACLE早先确实没有意识到物料、供应商及客户等核心数据，在系统设计的整体架构中具有怎样的特殊性，以至于如今许多初学者会觉得奇怪：EBS系统功能的最初设计，物料是在库存INV模块中定义的，供应商是在应付AP模块中定义的，客户是在应收AR模块中定义的。而不是采取如今流行的、更合理的系统应用架构设计：相关主数据有专门的定义与管理应用功能，可以作为“服务”提供给相关应用模块调用（即类似所谓“SOA”架构）。

显然，ORACLE后来意识到了这个问题，并开始逐步在系统功能的规划设计方面做调整。针对“客户”等主数据管理，于2001年首次提出了所谓“TCA架构”（Trading community Architecture），并首先将“客户数据”独立出来，作为一个向其他相关模块提供调用服务的基础应用。不过，对于相关“主数据”的这种系统应用架构设计的调整，由于“牵一发而动全身”的特殊性，ORACLE后来也曾在相关文档中无奈地承认，难度很大，进展很慢。以至于我们今天在EBS系统中会发现，不同主数据的系统实现方式往往有其不同的特点，这一定程度上增加了系统学习的难度。

此外，从业务管理与系统需求两方面来看，对于所谓“主数据”的内容范畴，不同企业、不同系统对之的理解可能有一定差别，例如“BOM数据、银行信息、税务信息、地址信息”等等，有时也可能被包括在所谓“主数据”的范畴之内。本书以下将重点讨论最常用的三个主数据：物料、供应商与客户。这三个主数据都有一个共同的系统应用特点：跨系统、跨组织的全局性。

4.2物料（Item）

物料（Item）数据管理以其应用的基础性与影响的广泛性，是EBS系统最重要也是最复杂的基础业务数据。对于物料种类繁多、产品结构非常复杂的企业，物料主数据的管理水平甚至可以上升到决定企业未来发展乃至生死存亡的高度。

4.2.1物料的类型与状态

EBS系统的英文原版中，物料是用“Item”来表示的，译成中文最初为“项目”，在文档表述中常因与另一个词“Project”的中文翻译“项目”混淆，而带来诸多不便。（这方面台湾习惯上将Project称之为“专案”，则不会存在混淆的问题）。R12中文版（大陆）将Item改为“物料”，虽说解决了容易混淆的问题，但却也带来了另一个问题“似乎缩小了Item原先的内涵范畴”。在EBS系统中，Item实际上不仅表示有形的“物料”，同时还可以指无形的“服务”，例如表示顾问服务的计量“人天”、表示一个广告创意的“Campaign”、表示一个售后服务的“Case”等等。为表述方便，本书中今后如不作特别说明，则原则上将“物料”等同于“Item”一词的内涵。

在EBS系统中，所谓“物料类型（Item Type）”，实际是可以根据企业业务管理需要而自定义的，但系统在初始安装时，已经预置了若干常用的值LOV。如图 4‑1所示。

图 4‑1 物料定义中的用户物料类型

物料类型的LOV是在Lookup Code 中定义的，访问级别是“用户”，即完全可以“自定义修改”，只有统计分析功用，并不参与系统流程构建，对业务流程几乎没有影响。如图 4‑2所示。

图 4‑2 物料类型的用户自定义

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

图 4‑3 物料定义的物料状态

物料状态的LOV值，系统提供了专门的表单定义功能，完全可根据企业需要设置每个“状态代码”对于相关物料属性起控制作用的具体方式，如图 4‑4所示：

图 4‑4 物料状态的设置

图 4‑3中，当一个具体的物料选定一个确定的“物料状态”后，其相关属性的修改方式就由图 4‑4设置中的“控制方式”决定，控制方式可能是三种“默认值、设置值、不使用”之一。默认值：在将状态分配给物料时，系统将默认状态代码定义的属性值，用户可以更改此默认值；不使用：既不使用默认值，也不使用状态控制；设置值：在将状态分配给物料时，系统将默认状态代码定义的属性值。一旦分配了默认值，用户不能对其进行更改。如图 4‑4中，“允许BOM ，值：√，使用：默认控制”，表示具有该状态的物料，其“允许BOM”属性的值默认为“YES（√）”，但用户可以更改。

4.2.2系统物料编码（Item）

4.2.2.1编码的功能设计

系统的“物料编码”既是个非常“简单”的问题，也是个非常“复杂”的问题。说其简单，是因为所有企业，无论是使用什么样的管理软件，都在使用某种方式在给物料编码；说其“复杂”，是因为物料编码管理是一门涉及范围广泛，有相当深度的专业学问，远不是“编码方式”本身的那点内容。我们有时侯说SAP/ORACLE产品包含有“丰富的管理思想与业界最佳业务实践”，其实，从与“Item（编码）”有关的系统设计角度来看，恰恰就能验证这一说法。

目前国内诸多ERP产品的“物料”定义，通常都包括两个基本内容“物料编码（Number）”、“物料名称（Name）”，并基于此引申出“物料编码、物料名称不能重复，使用后不允许修改”等等系统设计功能。ORACLE（或SAP）将所谓“物料编码Number、物料名称Name”变化成“物料（Item）、物料说明（Description）”。表面上看来好像是一样的，区别不大，但实际上两者在系统设计理念上已经起了根本性变化。

在EBS系统中，“物料（Item）”被抽象成一个代表物料的具有唯一性的“指示符”，可以是一个数字或字符的代码，也可以是一个长度限定的“短文本”。在系统内部该字段实际是一个“键弹性域”结构，不过实际使用多段结构的情况较少，一般设定成单段结构，与普通表单字段使用无异。但它并非是系统内部业务流程所使用的“唯一性识别ID”，也就是说，当在系统中定义物料（Item）时，系统还会在内部自动生成一个用于系统识别的唯一性ID（内码），外部所表现的Item（外码）只是其一个外部指示符（不过，系统也要求其具有唯一性）。

在EBS系统中，物料（Item）本身就是“编码”。系统允许修改已经存在的Item（编码），且如果改变了Item（编码），并不会影响到该Item原在其它相关模块中的使用状况。例如：先定义一个Item，然后为此Item创建BOM，然后在Item定义界面查找出此Item（编码）并修改保存，再去查询BOM，则可以发现原Item已经不存在，代之以的是修改后的Item，并完全继承了原BOM定义。至于所谓“Item说明（Description）”，与Item本身相比，系统除了不要求具有唯一性之外，其余方面几乎完全相同，它实际就是一个字符长度可更长一些的“短文本”，一般用之作为包括物料实际名称在内的对Item的简短说明。

EBS用涵义广泛的“说明Description”来取代涵义狭窄的“名称Name”，无疑使得系统使用具有了更为广泛的自由度。注意：如果需要使用“可修改已经存在的Item（编码）”功能，则需要将系统配置文件“INV：Updateable Item Name”设定为“Yes”。

4.2.2.2编码的应用原则

基于涵义比较“具体”的“物料编码Number、物料名称Name”的“电算化”系统设计与实现方式，自然会将企业实际的物料编码工作也引导到比较“具体”的实现方式上去。而基于比较“抽象”的“Item”的EBS系统设计与实现方式，则为企业的Item（编码）管理提供了更为灵活、更为方便也更为完善的扩展空间。但要理解清楚这一点，首先需要懂得基于“业界最佳实践经验”而总结出来的一条有关物料编码应用的重要原则：系统所使用的Item编码主要是针对广义的“部件”（Part）而言，而不是针对狭义的“工程物料”（Material）。

广义的Part编码是指只要符合“规格Form、性能Fit、功能Function”相同的物料，即使某些重要属性不相同（例如颜色、生产厂家、质量指标等等），只要不对3F的一致性有重要影响，均归属于同一个Item。而狭义的工程物料Material编码则是指即使是3F相同，但如果某些重要属性不同（典型的是生产厂家不同），也不能归入同一个编码。在EBS系统中，一个Part对应一个Item，但一个Part可能“包括”多个狭义的Material，如何“包括”则涉及到复杂的工程容差设计与材料认证问题。实际工作中，比较容易犯的错误是，以狭义的物料Material编码代替广义的Part编码，从而导致系统编码数据量成倍增加，不仅妨碍系统业务功能的实现，，而且对工作效率的提高也有严重影响。

上述物料编码管理原则，对于许多缺少相关业务经验的人来说，理解起来可能难度较大。不过，对于大多数人来说，只要懂得所谓“系统物料编码Item”主要还是ERP系统之外的工作，系统实施要求物料编码Item必须遵循上述基本管理原则就可以了。至于该系统物料编码的应用管理原则如何贯彻执行，则涉及到有一定深度与广度的专业知识，与企业的管理实践密切相关，管理要求比较高的企业可能需要设置所谓“Commodity管理”专门岗位，原因正在于此。实际工作中，能否分清Part编码与Material编码之间的本质区别，不仅体现在一个企业的Item编码方式的选择上，反映一个企业基本的业务运作管理水平，更重要的是它还能反映一个企业的产品研发与技术管理水平的高低。

4.2.2.3编码的典型方法

在遵循上述物料编码应用原则的基础之上，对于不同的企业来说，具体的编码方式可能各不相同，但基于业界最佳实践经验的总结，有下述比较典型的物料编码方法可供有关企业参考。它主要包括两方面内容：

一是系统Item编码的长度。经验表明，Item编码的长度以6-8位为宜，短了则可能容量不够，长了则不方便记忆、影响使用。编码应以数目字为主，必要时辅之以英文字母，不应当出现单词或词组，中文就更不应该出现了。一个编码通常分为前后两部分，前半部分（3-4位）表示物料分类，后半部分（3-4位）则是流水码。

二是系统Item编码中的分类。要注意的是，不要将Item编码中前半部分的“分类”与EBS系统中的Item Category（类别）混为一谈，两者有一定联系但差别也很明显。前者代表的是基于“用途”的Item的自然或物理属性的分类，是确定的；后者则更多的是体现企业的“管理”属性分类，可以根据需要随时作调整。从实际使用角度来看，一般规定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）。

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位识别码（实际也是流水顺序码）仍然过长，不方便使用。如图 4‑5所示。

图 4‑5 UNSPSC 物料分类编码

企业一般需要根据自己会使用到的那些8位UNSPSC分类码，个性化制定企业自己的分类“识别码”。通常取4位，前两位代表“大类”，后两位代表“小类”。注意，这里的“大类/小类”与UNSPSC中的“大类/小类”没有对应关系，只是为了方便企业对已选取的UNSPSC的管理。Item中的前4位分类识别码，即使全使用数目字（不使用英文字母），最多也可有1万种组合（3位则有1000种组合），足以满足单个大企业的物料分类需要。不同企业的Item中的分类识别码尽管不同，但由于它们都对应于同一的UNSPSC分类码，故企业间的数据交流与互换不会有问题。

4.2.3物料的类别（Category）

上面所讲到的Item编码中的UNSPSC分类，一般来说还不是系统（各应用功能模块）中真正使用到的物料类别，原因是Item编码中的UNSPSC分类所基于的分类基准（或用途）主要考虑的是“工程”目的，而各应用模块如库存INV、采购PO等中所需使用的分类更多地是需考虑不同的业务管理目的，这就好比我们将“人员”分类，有时需按“性别”（男、女）分，有时需按“学历”（博士、硕士、学士）分，有时还需按“年龄段”（老年、中年、青年）分等等。

对于EBS中一个确定的Item来说，可以同时具有多个代表不同分类维度的“类别集（Category Set）”，以满足各个应用模块的使用需要。这里之所以称其为“类别集”，源于其中包含若干个LOV值，系统将每个具体的LOV值称之为“类别”（Category）并最终分配给Item。EBS的每个相关应用模块必须设定默认关联一个“类别集”，称之为“默认类别集”。如图 4‑6所示。

图 4‑6 系统物料默认类别集设置

不同应用模块所使用的“默认类别集”可以相同也可以不同。用户在进入相关业务模块的“表单”界面时，打开的Item类别的弹性域结构取决于“默认类别集”中所关联的“类别集”设置。

系统初始安装时，EBS已经预设了若干不同的“类别集”并与系统预设的“类别弹性域结构名”（段结构还需完善设置）进行了关联。用户在“类别集”定义界面中可根据业务需要对预设值进行修改调整，或自定义新的类别集，以用于“默认类别集”的自定义设置。如图 4‑7所示。

图 4‑7中，如果选定“允许存在多个物料类别分配”，则可以将一个物料分配给某个类别集内的多个类别。这主要是用于某些特殊功能的情况，如“装箱”功能中的“创建装箱组”，定义一个“危险”类别集，将某个物料同时分配给“毒药”和“腐蚀物”类别。如果选定“强制使用有效类别列表”，则需要对其下的“类别列表”进行维护，其作用主要是控制PO界面的类别的LOV值（选择组合）只能存在于这里的定义列表中时才有效（否则会报错提示）。

图 4‑7 系统物料类别集设置

图 4‑7中的“人员类别”窗口的作用，是为了控制某些类别只允许特定“责任/人员”才可以访问（未设定则不做限制）。“分配”窗口，则是提供一种将多个“类别”快速成批分配给（包括维护）多个Item的工具。在单个Item定义时分配类别的结果，会显示在这里，这里所做的维护改变也会反映在定义Item时的分配类别界面中。如图 4‑8所示为Item定义时的类别分配界面。

图 4‑8 物料定义的类别分配

此外，为进一步控制上物料定义时具体类别Category组合代码的实际可用性，系统通过专门的定义类别可用性功能，内容包括是否启用、是否为i-Procurement启用（仅适用于R11）、供应商是否可查看（用于i-supplier）、Web申请是否可用，来根据实际业务需要对Category的可用代码组合做更为细致，也更为灵活的限制。如图 4‑9所示。

图 4‑9 物料类别可用代码组合设置

总之，EBS中的Item 的类别Category非常关键、非常重要，系统的其它相关功能如权限控制、审批设置以及费用账户等等，均会基于物料定义时的Category设置来进行，它与所谓物料的“Commodity管理”相结合，提供了企业业务管理所需的强大系统功能，是“业界最佳实践经验”的总结与结晶。

4.2.4物料的单位（UOM）

在物料Item定义中，可以为之指定“主要单位”（Primary）与“辅助单位”（Secondary），并且规定两者换算所允许的偏差系数（Deviation Factor）。物料的“主、辅单位”主要是为了满足实际工作中某些特殊物料的特殊计量需求。某些液态的化工原料如乙醇、汽油等，计价、储存可能是按吨、公斤或桶来计量的，但实际使用则可能是按“升”来计量，例如国内加油站进货按吨计，给车加油时按升计。而换算的“偏差系数”则是由于两者的换算关系可能受不同场合“温度、压力”等因素的影响，实际计量与原先“标准”条件下定义的换算关系存在一定偏差，故系统对于所产生的这种偏差必须有明确的规定。如图 4‑10所示。

图 4‑10 物料定义的单位设置

图 4‑10中的几个字段“跟踪、定价、辅助、默认、正负偏差系数、转换”的取值关系颇为复杂（详细内容请参考ORACLE相关文档说明），其中的一个可能结果是，只要手工输入的辅助单位的计量实际值与主要单位的计量值的实际换算关系在规定的偏差范围内，系统均当成标准换算关系进行处理，这对于库存数量余额的准确跟踪及产品正确定价将十分重要。

4.2.5物料的制造商部件号（MPN）

EBS中的一个Item可以对应多个制造商的“部件号”（MPN），而要做到这一点，在EBS中需使用“制造商部件号”菜单功能定义制造商及其MPN的值。如图 4‑11所示。

图 4‑11 物料的制造商及制造商部件号设置

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

图 4‑12 物料定义时的制造商及其部件号设置

注意，图 4‑12中物料定义的MPN设置的制造商取值，不可以手工输入，只能以图 4‑11中定义的制造商列表作为其LOV，但“部件”字段则可以手工维护，其功能与图 4‑11中的“部件”设置界面相同。

4.2.6物料的版本（Revision）

物料的版本管理对于实际业务及系统管理都是一项基础性工作。EBS在物料的定义界面使用“工具”栏中的“版本”功能可以维护物料的版本信息。如图 4‑13所示。

图 4‑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、BOM、ECO）的最终显示是相同。

4.2.7物料的组织控制（Master Org）

前面关于物料Item的一些基本概念的介绍，均没有涉及Item的组织控制问题。EBS的物料定义实际是基于库存INV组织的，这是其早期有关“主数据”管理的一个重要特点。早前，另外两个主数据“客户、供应商”也是基于确定的组织（OU）来定义设置的，但后来的EBS版本，客户与供应商的初始定义已经开始独立于组织（OU，上下文环境）来进行，然后再分配给相关组织（OU）使用。但物料的定义方式则几乎没有发生变化。

在EBS系统中，系统虽然允许设定多个所谓“主组织”来定义物料，然后再将物料分配给多个库存INV组织使用，但ORACLE强烈建议系统只设定唯一的主组织，而这一点与实际工作中的“主数据”集中管控的要求也是一致的。当在系统中设置库存INV组织时，在INV组织参数窗口的“物料主文件组织”字段，可选的LOV值包括当前INV名本身，以及已经被其它INV设定为“主组织”的INV名。一旦用户选定当前INV名作为主组织，则在设置其他INV的组织参数时，也可以在主组织可选LOV值中见到它。

EBS的“主组织”使用是不受帐套（科目弹性域结构）、业务实体的范围限制的，具有不同帐套/业务实体的库存INV可以具有同样的物料主组织。“主组织”的这一特性为大型企业物料的集中管控工作的开展提供了极大的方便性与高度的灵活性。用户在进入库存模块（或其他基于库存的应用模块）时，均需选择一个确定的库存组织，以进入确定的库存组织上下文环境。一旦进入确定的库存组织，则物料的主组织就已经唯一确定（由该库存组织的参数定义决定）。

被选定作为“主组织”的库存组织作为“业务功能”组织使用时，与其它库存组织并无任何区别。唯一的特殊之处在于，定义主组织物料时，在“组织分配”界面无需再向“组织层”的自己作分配（系统已经默认分配），但有关“属性控制”的设置，仍然与其它被分配的库存组织完全一样。如图 4‑14所示是物料Item定义中的“组织分配”界面。

图 4‑14 主组织物料的组织分配

所有物料Item均只能在其“主组织”界面（并非指必须进入主组织所在的上下文）定义后，才能分配给相关的库存INV组织使用。图 4‑14中可以分配的库存INV组织列表取决于每个INV组织参数定义的“主组织”与当前INV（图 4‑14中的第一行）的“主组织”是否相同。除了当前INV组织，其余INV组织的“组织属性”窗口均可以另外打开，以便定义属于本组织的相关属性。（当前INV组织的组织属性窗口实际已经打开，可在物料Item定义界面的“组织”与“主组织”间直接切换）

EBS系统在物料的“主组织”（Master Org）与组织（Org）之间，提供了相关“属性”如何控制的机制。如图 4‑15所示。

图 4‑15中，组名字段会显示属性组的名称。属性按功能分组，例如主要、库存和接收。在定义或更新物料、定义模板或查看物料属性时，可以显示特定组的属性，这样可以更容易地查找特定属性。“控制地点”可以在“主层”与“组织层”间选择。主要层：在主要层定义和维护此属性，对于同一物料，此属性的值在所有组织中均相同；组织层：在组织层定义并维护此属性，对于同一物料，每个组织均可为此属性定义一个不同的值（某些属性只能在特定层设置，在这种情况下，只具有一个选项）。

图 4‑15 物料的属性控制设置

对于某些“状态属性”，系统除提供“主层”与“组织层”的控制地点选择外，还提供“状态设置”控制方式的选择：“默认值、不使用、设置值”。这需要与前文所述“物料状态”的控制方式的设定结合使用。可以设置控制方式的“状态属性”共10个，包括：允许BOM、在WIP中制造、启用客户订单、启用内部订单、启用开票、启用执行流程（应用于“流程制造”）、启用配方（应用于“流程制造”）、可采购、可储存、可处理。物料的状态属性与其它属性之间或相互之间可能有一定的制约关系。例如，如果将库存物料设置为否，则不能将可储存设置为是。

4.2.8物料的属性及相互关系

物料Item广泛使用于企业实际工作中的方方面面，为了达致业务流程运作的规范化、标准化、自动化，实现企业“实物流、资金流、信息流”的统一，就必须在系统中对Item的相关流程属性作统一的、预先的设置，以便被相关业务流程所调用或起到某种控制作用。它是企业管理实践与业务流程运作如何实现“集中统一”的典型体现，是管理信息系统具有强大功能与高度灵活性的核心基础。因此，它也是系统实施与应用的关键步骤。

EBS的物料Item可定义（或必需定义）的属性值总数多达300多个，为了方便对这些属性的管理，EBS按属性的“流程功能”进行了分组，目前一共分为17个属性组（即Item定义界面的Tab标签页），包括“主要、库存、物料清单、资产管理、成本计算、采购、接收、物理属性、总计划、MPS/MRP计划、提前期、在制品、订单管理、开票、流程制造、服务”。这些Item的属性分组（Tab页）大体上与系统的应用模块有一定的对应关系，相关业务模块使用时，有关Item的基础设置主要是与相对应的属性Tab页内容有关。

每一个属性组有若干可定义属性值（字段），其中一部分属于“必需项”（一般均有默认值，可修改），另一部分则属于“可选项”（可留空）。一部分是属于“业务控制”属性，可以直接用于控制系统中的相关业务操作，如“可采购、可储存”等等，另一部分则是属于“流程控制”属性，可以直接或间接控制所使用的具体业务流程种类或方式，例如“计划方法、BOM物料模型”等等，还有部分属于“参考引用”属性，主要是向有关单据提供默认的参考值。某些属性之间具有确定的关联性，一旦定义了其中一个值，其余相关属性的值也就随之确定。

关于物料属性间相互关系的具体内容，比较复杂，必须仔细参考ORACLE相关应用文档（如下述各表，仅供参考）。这些特定属性间的特定关系分为下述四大类：

4.2.8.1要求的属性值

如果物料的某些相关属性具有下表所示的值，则必须输入相关的特定属性的值。如下表4-1所示：

属性	条件
需求时间范围天数	将需求时间范围设置为自定义
保留款帐户	将“冲销保留款”参数设置为是
费用帐户	将库存资产值设置为否并将库存物料设置为是
外协加工单位类型	将外协加工物料设置为是
计划时间范围天数	将计划时间范围设置为自定义
发放时间范围天数	将发放时间范围设置为自定义
重复性计划	将 MRP 计划方法设置为 MPS 计划或 MRP 计划
服务期限	服务延续期间不为 NULL
储存期限天数	将批次到期（储存期限）控制设置为物料储存期限天数
来源组织	将补充来源类型设置为库存
起始批号	将批次控制设置为全部批次控制
起始批前缀	将批次控制设置为全部批次控制
起始序列号	将序列号控制设置为预定义序列号
起始序列前缀	将序列号控制设置为预定义序列号

4.2.8.2相互关联的属性

物料的某些特定属性值取决于其它属性值。例如，如果挑库组件设置为是，则计划方法必须是未计划。物料特定属性之间的相互关联关系，如下表4-2所示：

属性	必须为	条件
按订单装配	否	将挑库组件设置为是或将 BOM 物料类型设置为计划
按订单装配或挑库组件	是	将 BOM 物料类型设置为模型或选件类
ATP 组件	否	“挑库组件”为否、“按订单装配”为否但“WIP 供应类型”不为虚拟件
基本模型	NULL	“BOM 物料类型”不为标准或将“挑库组件”设置为是。
允许 BOM	否	将“库存物料”设置为否
在 WIP 中制造	否	将“库存物料”设置为否或 BOM 物料类型不为标准
容器类型	NULL	将“容器”设置为否
启用成本计算	是	将“库存资产”设置为是
客户订购	否	将“BOM 物料类型”设置为计划
启用客户订单	否	将“客户订购”设置为否
需求时间范围天数	NULL	“需求时间范围”不为自定义
内部订购	否	“BOM 物料类型”不为标准
启用内部订单	否	将“内部订购”设置为否
内容积	NULL	将“容器”和“运载工具”均设置为否
启用开票	否	将“可开票物料”设置为否
提前期批量	1	将“重复性计划”设置为是
最大装载重量	NULL	将“容器”和“运载工具”均设置为否
最小装载百分比	NULL	将“容器”和“运载工具”均设置为否
挑选组件	否	将“按订单装配”设置为是或将“BOM 物料类型”设置为计划或“计划方法”不为未计划
挑选组件	是	将“模型完工发运”设置为是
计划时间范围天数	NULL	“计划时间范围”不为自定义
计划方法	未计划	将“挑库组件”设置为是
后加工提前期	0（零）	将“制造或采购”设置为制造
可采购	否	将“采购物料”设置为否
发放时间范围天数	NULL	“发放时间范围”不为自定义
限制货位	未将货位限制在预定义列表中	将“限制子库存”设置为未将子库存限制在预定义列表中
限制货位	未将货位限制在预定义列表中	将“库存货位控制”设置为动态输入货位控制
限制子库存	将子库存限制在预定义列表中	将“限制货位”设置为将货位限制在预定义列表中
可服务产品	否	将“支持服务”设置为是
可发运	否	将“BOM 物料类型”设置为计划
可储存	否	将“库存物料”设置为否
库存货位控制	无货位控制或未预指定货位控制	将“限制货位”设置为将货位限制在预定义列表中
支持服务	否	将“可服务产品”设置为是
可处理	否	将“可储存”设置为否

4.2.8.3可更新的属性

系统仅允许在特殊情况下更改某些属性值，可更新的属性和更改这些属性值时应具备的条件，如下表4-3所示：

属性	可更新	条件
ATP 组件	自否至是	“按订单装配”为是，或“挑库组件”为是或“WIP 供应类型”为虚拟件
BOM 物料类型	否	“物料清单”存在或作为 BOM 的组件存在，或作为标准 BOM 的替代组件存在。例外：可根据组件和替代组件的产品系列进行更改。
启用成本计算	是	不存在现有量
需求时间范围天数	是	“需求时间范围”为自定义时间范围
库存资产值	是	不存在现有量
批次控制	是	不存在现有量
可处理 OE	自是至否	不存在需求
	显示警告	未完成销售订单行包含一个不同于新值的值
外协加工部件	是	“采购物料”为是
计划时间范围天数	是	“计划时间范围”为自定义时间范围
发放时间范围天数	是	“发放时间范围”为自定义时间范围
重复性计划	是	未按 MRP 计划
保留控制	是	不存在需求
版本控制	是	不存在现有量
	显示警告	未完成销售订单行包含一个不同于新值的值
序列号控制	是	不存在现有量
储存期限控制	是	不存在现有量
可发运	显示警告	未完成销售订单行包含一个不同于新值的值

4.2.8.4控制层的相关性

系统只允许在特殊情况下更改某些属性的控制层，否则会产生特定结果。某些属性和在特定条件下可更新的控制层以及更改控制层所产生的结果，如下表4-4所示：

属性	可更新为	条件	结果
物料状态	主层	任何子组织中都不存在待定状态	将更新状态控制或默认控制下的所有状态属性
库存资产值或启用成本计算	主层	具有已定义 WIP 参数的组织将使用其本身作为成本计算的主组织（在定义 WIP 参数时不能与成本计算的不同组织相关联）	--
--	--	物料成本在组织间是相同的	--
库存资产值	主层或组织层	--	“启用成本计算”将更新为同一层
所有物料定义属性	组织层	在“组织层”维护功能区域的默认类别集	--

oracle

文章转载自杰夫之产业互联网，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。