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

〔九〕Item的属性内容简介〔Attribute〕关于每一个Item属性具有怎样的业务功能、具体如何设置问题，由于与具体的各业务模块功能以及企业的管理实践及业务需求紧密相关，这里无法展开详述〔以后结合各模块流程与功能再来讨论〕。以下仅针对各“属性组〞〔Tab页〕的主要内容作简单介绍：〔1〕主要〔Main〕。这个属性组内容相对简单，如前面的图1所示。主要包括Item的“单位〔UOM〕及其转换关系〔Conversion〕〞、“用户物料类型〔UserItemType〕〞、“物料状态〔ItemStatus〕〞以及Item的“详细说明〞〔LongDescription〕。有关Item的单位、类型、状态等内容前文已经有相关介绍，这里不再赘述。定义新的Item时，“单位及物料状态〞会有默认值〔Default〕，默然值是由配置文件：“INV：默认主要单位〞和“INV：默认物料状态〞的设定值决定的。系统初始安装时，ORACLE为“单位与物料状态〞均预置了LOV值，并且表达在相关配置文件的初始赋值之中，用户可根据需要修改。关于Item的“详细说明〞〔LongDescription〕，顾名思义，就是给用户提供一个比“Item说明〔类似物料名称〕〞字段更为详细说明该Item某些特性与功用的地方，本质上两者涵义相同〔SAP中干脆将之译成“短文本、长文本〞，就更形象了〕。另外，Item定义界面题头的“说明性弹性域〞也可以用来担当类似用途。更进一步，还可以为Item添加“附件〔Attachments〕〞〔可以多个并具有多种形式〕来为Item提供更为丰富与详尽的数据支持。如以下图16所示：有关“单据实体〞的附件的使用方式与特性，请参见“≤ORACLE系统与实践≥系列之三：EBS的根底设置要点简介〞的有关内容。顺便说明一下，当用户在上图中“显示属性〞的“主层、组织、全部〞将切换时，各“属性组〞〔Tab页〕的显示方式与内容可能会发生变化，具体变化取决于前面所述的Item“属性组〞控制方式设置。当某个“属性〞定义为“主要层〞控制时，切换到“组织〞属性显示时，该属性字段将被灰显而不可更新。当某个“属性〞定义为“组织层〞控制时，切换到“组织〞属性显示时，该属性字段一般允许更改更新，可以具有与“主层〞属性显示状态时不同的赋值。〔2〕物理属性。这个属性组的内容比拟简单，主要包括Item的自然属性“重量、体积以及几何尺度〔长宽高〕〞的数据，这些数据在系统有关仓储、包装、发运等功能中会用到。如以下图17所示：此外，该Item如被用作为“容器〔Container〕〞、“运载工具〔Vehicle〕〞，那么必须首先在这里进行定义。其余在“类型〞区域，如果该Item需要被用作“市场宣传促销品〞〔用于OracleSalesandMarketing〕，被用作WMS中的“事件、设备〞，也需要在这里预先进行定义。而“OM整数〞，那么表述是否可将此物料分成多个局部进行订购。〔3〕库存。此属性组内容比拟复杂，包括“批次过期、批次号、序列号、盘点、子库存〞等等控制内容，根本属于控制有关物料事务处理〔如进出库、转移〕的功能应用范畴，某些属性对于具体的事务处理有决定性影响。如以下图18所示〔4〕物料清单。此属性组与系统的BOM功能以及OM订单处理功能相关。其中“BOM物料类型“字段比拟关键，取值不同影响到OM的订单处理方式与过程。如以下图19所示：〔5〕资产管理。只有当前INV组织参数定义中，该组织启用eAM功能，那么才可以访问该Tab页，其中资产Item类型〔AssetItemType〕的设置比拟关键，影响到其它字段如“资产活动〔AssetActivity〕〞的设置。如以下图20所示：〔6〕本钱计算。此属性组用于控制与本钱计算相关的系统功能，如以下图21所示：要注意的是，“销货本钱账户〞只能在组织层设置，如当前INV组织与主组织属于不同帐套且会计科目弹性域结构不同时，这里的账户代码结构是可以不相同的。〔7〕采购。此属性组用于控制有关采购的系统功能，如以下图22所示：其中的“允许更新物料说明〞，表示在采购订单行中可以改写类似“物料名称〞，这对于某些特殊情况非常有用；“使用批准的供给商〞，表示采购订单的可选择供给商仅限于ASL；“外协加工类型物料〞，并不表示该物料需要外协加工，而是说该Item本身是一个非实物的“外协效劳〞，需要与真实的需外协加工Item配合使用；“默认采购员〞，那么用于采购员业务量分配与管理。〔8〕接收。此属性组主要用于采购接收的控制功能，如以下图23所示：其中的“接收方式〞用于控制采购接收的默认路径。但这里的属性定义大局部在采购PO中可以更改。〔9〕总方案〔GeneralPlanning〕。中文翻译不是太准确，实际是相对于“MPS/MRP〞而言的一般或普通“库存方案〞方式，通常是应用于非制造型的商业企业的库存方案场合，或无需BOM分解的物料的库存方案。如以下图24所示：〔10〕MPS/MRP方案。此属性组用于控制Item的MPS/MRP方案功能，只有在这里设定了MPS/MRP方案方式才在做MPS/MRP时可见，这缩小了Item的可用范围，如以下图25所示：〔11〕提前期〔LeadTimes〕。此属性组用于控制BOM中的工艺路线及方案功能中的有关时间计算问题，有关累计数〔累计制造、累计总额〕实际是通过BOM中的相关计算功能来自动更新的。如以下图26所示：〔12〕在制品〔WIP〕。此属性组控制WIP中的相关功能，其中的“供给类型〞比拟关键，直接控制物料的事务处理方式。如以下图27所示：〔13〕订单管理。此属性组主要用于控制订单管理OM、发运执行Shipping以及采购PO内部订购应用方面的相关功能，此外，ATP相关设置对于某些方案功能亦是前提条件。如以下图28所示：〔14〕开票〔Invoicing〕。此属性组主要与AR模块的相关功能有关。其中“销售账户〞只能在组织层设置，帐户代码的弹性域结构可能与“主组织〞的不同。如以下图29所示：〔15〕效劳。此属性组与订单管理OM及效劳Service管理模块的相关功能有关，如以下图30所示：〔16〕Web选项。主要是与销售订单网上订购〔i-Store〕功能有关，如以下图31所示：〔17〕流程制造〔ProcessManufacturing〕。主要是与“流程制造〞系统模块相关，R12中新增的Tab页。如以下图32所示：〔十〕Item的属性快查EBS为了方便用户对Item诸多属性的查找与管理，在Item定义维护界面的“工具栏〞提供了快速“查找属性〞功能，如以下图33所示：一旦选择其中的一个“属性〞，那么系统快速定位到其所在的Tab页，以方便用户查看或维护。〔十一〕Item的客户与供给商关系企业在对外交往过程中，尤其是与客户或供给商的供给链电子商务协作过程中，需要将自己的Item〔编码〕与客户或供给商的Item〔编码〕建立某种对应关系，以提高供给链的协同效率。例如，作为客户，一般会要求自己的供给商在送货时，在相关送货单据或实物上提供己方的Item编码，以方便己方的收货部门能进行快速处理。在EBS系统的Item管理中，提供了有关客户Item的完善定义与维护功能，即将己方的销售产品按不同客户〔客户地址Address、地址类别AddressCategory〕与客户Item建立交叉参考关系。具体包括两个步骤。一是建立或维护客户Item〔客户Item相关信息如编码等由客户负责提供〕，如以下图34所示：二是将公司Item〔主要指用于销售的产品〕与已经建立的客户Item建立交叉参考关系。如以下图35所示：一个客户Item可以对应公司多个Item〔需要定义“优先级〞〕，这主要是满足实际工作中客户订购的Item可以对应公司的产品系列、允许替代的情况。例如公司生产的某种产品有不同颜色，公司内部为之定义了不同的Item。客户订购Item所要求的颜色，在缺货的特殊情况下，客户也允许以另一种颜色替代。Item的客户产品交叉参考的定义维护工作，需要花费一定的人力、物力，本质上它相当于企业向自己的客户提供了一种额外的增值效劳，主要满足的是客户的相关业务管理需求。对于作为供给商的企业角色来说，在为自己的客户提供增值效劳的同时，也可以作为客户角色，向自己的供给商要求提供类似效劳。故此，在EBS系统中，并未提供类似“客户Item〞的“供给商Item交叉参考关系〞定义或维护。系统不提供类似功能，一来是因为相较于销售Item的有限数量〔几十、上百就算多了〕，采购Item的数量要高得多〔成千上万很正常〕，类似客户Item的定义与维护工作量太大；二来是供给商Item交叉参考关系的定义维护，于实际工作的意义不是太大，完全可以由供给商的相关工作〔向己方提供增值效劳〕所取代。在EBS系统中，虽没有定义Item的供给商产品交叉参考关系，但在采购的相关业务过程中，例如下达采购订单时，可以手工输入“供给商Item〞作为给对方的参考。系统为此提供了对于历史业务数据中的手工输入的供给商Item的查询检索功能，查询范围包括PO、询报价、来源补充规那么等区域，如以下图36所示：

ORACLEEBS系统主数据管理二、物料〔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客户的账户层与地点层属性〔二十二〕客户数据的合并〔二十三〕客户数据的其它管理功能五、结语

〔十二〕Item的物料关系〔Relationship〕对于已经在系统中定义的Item，EBS可以定义和维护某些Item相互之间的特殊关系，这些所谓“特殊关系〞的类型包括采购接收替代、方案替代、交叉销售、向上销售、促销升级、免费赠送、冲突等等近二十种关系〔还可以自定义〕。上述定义的Item关系除采购接收替代在PO模块中具有流程功能，允许替代接受之外，其它主要是在相关应用模块中用于查询与报告功能。具有“方案替代〞的关系定义时，可以在“方案详细资料〞窗口，进一步定义所适用的客户范围等信息。如以下图37所示：〔十三〕Item的交叉参考〔CrossReference〕除了上面所述的Item的“客户产品交叉参考〞关系的专门定义与维护之外，EBS系统还基于实际工作需要，提供通用的Item交叉参考关系的定义维护，例如，在旧Item编码与新Item之间建立对应关系，将某些费用类Item与财务部门使用的费用类别代码关联等等。上面的“客户与供给商的Item交叉参考〞是两类比拟特殊的情况，在这里也可以建立通用的交叉参考，即不按具体的客户或供给商区分，仅按参考交叉类型“客户〞或“供给商〞类型笼统划分。如以下图38所示：上图中的交叉参考类型的LOV值是直接手工输入的，只是起到一个分类查询的作用，Item所对应的值也是手工输入维护的，并且与Item之间没有“一对一〞的关系。一个Item可以对应多个参考值，反之亦然。〔十四〕Item创立的模板〔Template〕用户在EBS系统中创立Item的方法有多种，其中最简单也是最直接的方法就是直接录入。为了帮助提高Item录入的效率以及减少录入错误，系统提供了定义Item模板及从模板或其它已存在Item复制创立新Item的功能。如以下图39所示是定义Item的界面：EBS系统在安装初始状态，已经预置了假设干数量的Item模板，这些预置的模板可以划分为三大类〔模板集〕。以下三个表显示了不同模板集的具体内容：模板集#1属性ATO模型ATO选件类ATO物料成品套件按订单装配是是是否否BOM物料类型模型选件类标准标准标准允许BOM是是是是是在WIP中制造

是是

启用本钱计算是是是是是客户订购物料是是是是是启用客户订单是是是是是预测控制冲减和衍生冲减和衍生冲减和衍生冲减和衍生冲减和衍生纳入累计是是是是是库存资产估价是是是是是库存物料是是是是是可开票物料是

是是是启用开票是

是是是MRP方案方法MPS方案MRP方案MRP方案MPS方案未方案制造或采购制造制造制造制造制造OE可处理是是是是是外协加工物料-----挑库组件否否否否是外购否否否否否可采购-----保存控制--可保存可保存-舍入控制--舍入订货量舍入订货量-发运完整模型是----可发运--是是-可储存--是是-可处理--是是-用户物料类型ATO模型ATO选件类ATO物料FGKWIP供给类型装配拉式虚拟件推式推式装配拉式模板集#2属性外协加工物料PTO模型PTO选件类虚拟物料方案物料按订单装配否否否否否BOM物料类型标准模型选件类标准方案允许BOM-是是是是在WIP中制造----是启用本钱计算

是是是-客户订购物料否是是否-启用客户订单-是是--预测控制-冲减和衍生冲减和衍生--纳入累计-是是是-库存资产估价-是是是-库存物料否是是是是可开票物料-是---启用开票-是---MRP方案方法MRP方案未方案未方案MRP方案未方案制造或采购-制造制造制造-OE可处理-是是是-外协加工物料是----挑库组件否是是否否外购是否否否否可采购是----保存控制-----舍入控制-----发运完整模型-是---可发运-----可储存-----可处理-----用户物料类型OPPTO模型PTO选件类PHPLWIP供给类型供给商-虚拟件虚拟件-模板集#3属性外购物料引用物料子装配件供给物料运费产品系列按订单装配否否否否-否ATP组件-----否BOM物料类型标准标准标准标准-产品系列允许BOM是-是是-是在WIP中制造--是--否检查ATP-----无启用本钱计算是-是--是客户订购物料是是否否否否启用客户订单是---是否启用周期盘点-----否工程物料-----否预测控制冲减和衍生-冲减和衍生---纳入累计是-是--否内部订购物料-----否启用内部订单-----否库存资产估价是-是--是库存物料是否是是-是可开票物料是---是否启用开票是-是-是否制造或采购采购-制造采购

制造MRP方案方法MRP方案不方案MRP方案不方案

不方案OE可处理是-是--否外协加工物料-----否挑库组件否否否否-否主要单位-----每个可采购是--是-否外购是否否是-否发放时间范围-----请勿自动发放保存控制可保存-----舍入控制舍入订货量-舍入订货量---可效劳产品-----否发运完整模型------可发运物料是--

是否可储存是-是是-否支持效劳-----否可处理是-是是是否使用批准的供给商-----否用户物料类型PREFSASI运费产品系列保修-----否WIP供给类型装配拉式-工序拉式批量--注意，当将模板应用于现有Item时，此模板将改写现有属性。用户可以按需要将任意数目的模板应用于现有物料。较新的属性值〔来自上次应用的模板〕将改写以前应用的模板值，除非后者是不可更新的〔例如，主要单位即是一个永远不可更新的值〕。〔十五〕Item的目录组〔CatalogGroups〕前面在讲到EBS的Item〔物料编码〕时，已经讲到习惯上的“物料名称〔Name〕〞被“说明〞字段〔短文本〕所代替。实际工作中，为了方便对于同类物料的查询检索与数据管理以及企业之间的沟通交流等目的，有必要对Item的类似Name的“说明〞字段也进行标准化、标准化。具体方式就是将同类物料“说明〞的具体内容划分为多个标准的“组成段〞，按特定的次序〔称之为“级连〞〕有选择地组成某个Item的实际“说明〞。例如小汽车的Item“说明〞：车型〔帕萨特〕—功率〔75马力〕—排量〔升〕—座位数〔5座〕；或者：“车型〔帕萨特〕—排量〔升〕〞等等。其中的每一个“组成段〞称之为一个“说明性要素〞，所有“说明性要素〞的组合称之为一个“目录组〞〔CatalogGroups〕。目录组在应用于Item创立前，需预先定义维护以备用，如以下图40所示：注意：“目录组〞名称字段本身也是一个可以自定义的键弹性域结构，不过实际很少使用多段结构，一般都取单个段，实际使用与普通表单字段无异。在具体定义或维护Item时，通过“目录〞功能，选择一个目录组，然后在说明性要素中输入具体值，以后那么可以随时根据需要自动更新Item的说明字段〔生成不同级连组合〕。不同的Item只要具有同一目录组，那么虽然“说明性要素〞的输入值可能不同，但由于有明确的位置关系可以一一对应，故方便了查询与比拟。这实际上也等同于提供了某种特殊的物料分类方式，对于某些特殊场合〔如药品或汽车，Item名称长且同类Item名称相似度高〕的名称检索管理将十分有帮助。如以下图41所示：〔十六〕Item的待定状态〔PendingStatus〕在实际工作中，基于管理的方便性需要，对于某些Item可能需要由系统自动控制其未来某一时刻开始〔或在某个期间〕处于某个特定“物料状态〞〔如失效等〕。这项功能可以通过在Item定义维护界面为其设置“待定状态〞来完成。如以下图42所示：已经设定的Item待定状态需要通过“实施〞提交并发流程来完成，也可以在“请求〞里直接提交周期性运行的后台流程。〔十七〕Item的属性组织间查看与复制在大型组织机构中，同一Item在不同组织〔INVOrg〕有不同的属性设置，EBS提供了属性的跨组织查询与复制功能〔详细内容，请参考ORACLE相关文档〕。如以下图43所示：〔十八〕Item的删除这里所讲的删除是指从数据库中真正清空掉Item有关信息实体，这些实体可以包括物料、物料清单、组件、工艺路线或工序。这是个很少用到的功能，应用于某些特殊场合，例如垃圾数据太多等等。EBS系统预置有假设干初始的“删除约束条件〞与“删除语句〞〔SQL〕，只能查看，不能修改。但用户可以自定义删除“约束〞和“语句〞。实际的删除是通过运行“删除物料信息〞的后台并发流程来进行的。为了方便删除工作的开展与管理，EBS系统提供了所谓“删除组〞功能，以检查、实施、监控批量删除过程。如以下图44所示：〔十九〕Item的其它来源方式除了上述在EBS的Item定义维护界面直接创立方式之外，系统还提供了从外部来源的Item数据导入接口〔API〕方式。此外，作为系统外围的高级应用功能，EBS还提供属于PLM范畴的AdvancedProductCatalog应用模块来管理Item来源创立及维护更新的复杂事务过程。如以下图45所示：在INV、BOM、ENG模块中的Item、Bom、ECO实际上主要只是提供了相关结果数据的录入功能，并未涉及具体的数据来源过程。对于业务复杂、管理完善的企业来说，相关Item主数据的来源，必然是需要经历一个创立、讨论、审批等环节的“准入〞认证事务管理过程。如以下图46所示有关参与讨论人员的“认证〞意见提交：EBS系统除了有AdvancedProductCatalog应用模块的功能为此提供“端到端〞的全流程管理之外，另一属于PDM范畴的产品Agile也提供更为强大、更为完善的过程管理功能，以适应不同企业、不同层次的业务管理需要。正如笔者在“ORACLEEBS系统架构与应用实践〞一文中所述，INV/BOM/ENG有关原始业务数据的录入，更多地是表达核心业务系统在“数据集成性、流程集成性〞方面的要求，而这些系统外围产品的功能设计，那么更多地是表达在非核心系统事务“管理集成性〞方面的要求，两者的有机结合，构成了ORACLE产品系统架构的高度可伸缩性与完善而强大的业务功能。〔有关AdvancedProductCatalog产品及Agile产品的具体内容，以后有时机再来讨论〕。ORACLEEBS系统主数据管理三、供给商〔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客户的账户层与地点层属性〔二十二〕客户数据的合并〔二十三〕客户数据的其它管理功能五、结语

三、供给商〔Supplier〕在二十一世纪的今天，人们已经逐步认识到，企业之间的竞争已不完全是单个企业之间的竞争，而是企业所拥有的供给链之间的整体竞争。企业供给链的效率与质量如何，关系到企业在日益残酷的市场游戏中能否取得竞争优势。企业与供给商之间的关系，也不再是过去简单的买卖关系，而是越来越深入、紧密的合作伙伴关系。企业与自己的供给商之间既有不同利益的矛盾，也有共同利益的合作。在企业的管理实践过程中，涉及“供给商〞的管理信息系统的设计主要有两方面内容，一是与供给商在日常业务过程中的商务协同，包括供给商门户、订单协同、方案协同、询报价、招投标等等内容，通常归入SCM产品的范畴；二是供给商的生命周期与关系管理，包括供给商准入管理、资格认证、协议与合同管理、绩效考评等等内容，通常归入SRM产品的范畴。这两方面的内容的连接点就是“供给商主数据〞，前者涉及供给商主数据的使用，后者涉及供给商主数据的创立与维护。在ORACLEEBS系统中，涉及供给商主数据“使用〞的SCM产品目前已经比拟完善，而涉及供给商主数据“创立〞的SRM产品目前还在开展过程中。R12将供给商主数据的定义与维护从GUI界面变为WEB界面，也是考虑了SRM产品的未来拓展需要。由于R12与R11的供给商主数据相比，除了多组织控制，在内容方面并无本质上的太大变化，考虑到WEB界面不太方便于系统学习演示，故以下关于供给商主数据的讨论将以R11的GUI界面为主，然后再辅之以R12的WEB界面以做补充、比拟。〔一〕供给商的分类概述企业的供给商按所提供产品与效劳的用途划分，可分为“生产供给商〞与“非生产供给商〞两大类。所谓“生产供给商〞是指其提供的产品或效劳，企业并非终端使用者，而是进入企业销售的产品或效劳之中，最终提供给企业的客户使用，例如原辅材料供给商，为企业的产品提供运输、维修等效劳的供给商等等；所谓“非生产供给商〞，是指企业自身就是终端使用或消费者，例如企业所使用的办公用品、仪器设备供给商，以及为企业的日常运作提供效劳的广告公司、软件提供商、咨询参谋公司等等。按供给商提供的产品与效劳的形态划分，那么可以划分为“有形〞实物类的供给商，与“无形〞效劳类的供给商；按供给商与所提供产品的关系，可以分为“制造商、代理商〞；按供给商的组织形态划分，那么可以划分为“公司供给商〞与“个人供给商〞〔在EBS中，公司员工有时需要当作供给商来处理〕；按地域范围划分，那么可以划分为“国内供给商与国外供给商〞；按供给商所处生命周期或合作关系划分，那么可以分为“潜在供给商、一次性供给商、试用供给商、长期合作供给商〞等等。在EBS系统中，供给商分类/类型LOV是在LookupCode进行定义的，如以下图47所示：要注意的是，尽管供给商类型VendorType的访问级别是“用户〞，即用户可以完全自定义，其LOV值不参与系统流程构建。但ORACLE初始安装所预置的值中代码“EMPLOYEE员工〞并不能被删除或修改，因为在供给商定义引用时，如果找不到“员工〞类型，那么就无法将员工设置为供给商〔而一旦无法将员工设为供给商，那么AP在处理员工费用报表时将无法进行〕。故推测VendorType的“访问级别〞实际上应当是“可扩展〞，这可能是系统设计疏忽。尽管上面依据各种属性对供给商做了种种分类的讨论，但实际上在EBS系统中，除“员工〞类型之外，其余只是主要起到统计分析的作用，于系统流程角度看并无本质区别。在EBS系统中，供给商的定义与维护是在AP模块而非PO模块中进行的〔之所以如此，与ORACLE的产品开展历程有一定关系〕。在AP模块中定义维护供给商，意味着即使没有或不使用PO模块，也可以在AP模块中对于需要向各种供给商进行付款的业务行为进行有效管理。EBS的AP模块定义的供给商主数据，将同时为PO模块、Asset资产模块、Property财产模块等所共享。〔二〕供给商“名称与编号〞〔SupplierName/Number〕在EBS系统中，由于实际使用以及早期系统设计考虑欠周详等方面的原因，在PO模块的订单界面中是将“供给商名称〞〔SupplierName〕作为主要检索字段来使用的〔PO界面甚至没有直接显示“供给商编号〞字段〕，在AP模块的发票界面虽然有供给商编号字段，但人们在使用习惯上还是以“供给商名称〞为主。故如果将“供给商名称〞理解成供给商的“组织全称〞，那么实际使用将很不方便，因为一般来说供给商法律意义上的公司注册“全称〞会比拟长。EBS的供给商定义界面有“供给商名称〞与“别名〞两个字段，考虑到上述因素，实际使用情况可能恰好相反：以“别名〞字段记录供给商“全称〞，而在“供给商名称〞字段输入符合企业命名惯例且便于识别记忆的“短名、别名或简称〞。如以下图48所示：系统要求“供给商名称〞具有唯一性，但已经存在的供给商名称可以更改，且并不影响系统已经存在的相关业务数据。供给商一旦定义就无法轻易删除，可以通过“无效日期〞设置使其不能输入发票或采购订单〔并不影响已有业务的处理〕。上图中“一般〞Tab页中的“父供给商名称〞及“编号〞，表示当前供给商与系统中已经定义的其它供给商具有附属关系，而客户编码字段，那么是本企业在该供给商处的标识编号。“供给商编号〞具有唯一性且不可更新〔系统的跟踪标识〕，可以手工输入，也可以由系统自动生成，具体是那种方式由AP系统相关设置控制。这一点，R12与R11相比设置界面虽有所不同，但在多组织〔OU〕功能支持下，供给商的编号设定都是实现跨OU定义的，故其编号设置与OU无关。如图49所示R12的供给商编号设置：不过，在实际的企业管理实践中，使用“无涵义〞的供给商自动编号并不可取，企业通常需要基于前面所讲的供给商分类，统筹考虑制定“有涵义〞的手工编号规那么，这是因为EBS系统所提供的供给商“分类〞控制方式有点简单，缺少层次性，很多时候并不能很方便地满足实际统计分析工作的需要〔这或许是EBS系统设计方面的缺乏〕。〔三〕供给商的“地点〞〔Site〕在“ORACLEEBS根底设置要点简介〞一文中，关于“Address、Location、Site〞的三者关系已经有详细介绍。Site的涵义更多的是表示一种比拟虚无的“属性〞，ORACLE借用Site〔地点〕的这一特性，来表示与同一供给商的合作过程中，供给商可能有多种合作状况，例如一个集团公司性质的的供给商，以一个整体对外与企业签署合作协议并承当有关法律责任，但实际业务的发生，希望按不同子公司分别使用不同的银行账户