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

（供应商）

4.2供应商（Supplier）

在二十一世纪的今天，人们已经逐步认识到，企业之间的竞争已不完全是单个企业之间的竞争，而是企业所拥有的供应链之间的整体竞争。企业供应链的效率与质量如何，关系到企业在日益残酷的市场游戏中能否取得竞争优势。企业与供应商之间的关系，也不再是过去简单的买卖关系，而是越来越深入、紧密的合作伙伴关系。企业与自己的供应商之间既有不同利益的矛盾，也有共同利益的合作。

在企业的管理实践过程中，涉及“供应商”的管理信息系统的设计主要有两方面内容，一是与供应商在日常业务过程中的商务协同，包括供应商门户、订单协同、计划协同、询报价、招投标等等内容，通常归入狭义SCM产品的范畴；二是供应商的生命周期与关系管理，包括供应商准入管理、资格认证、协议与合同管理、绩效考评等等内容，通常归入SRM产品的范畴。这两方面的内容的连接点就是“供应商主数据”，前者涉及供应商主数据的使用，后者则涉及供应商主数据的创建与维护。

在ORACLE EBS系统中，涉及供应商主数据“使用”的狭义SCM产品目前已经比较完善，而涉及供应商主数据“创建”的SRM产品目前还在发展过程中。R12将供应商主数据的定义与维护从GUI界面变为WEB界面，也是考虑了SRM产品的未来拓展需要。由于R12与R11的供应商主数据相比，除了多组织控制，在内容方面并无本质上的太大变化，考虑到WEB界面不太方便于系统界面截图演示，故以下关于供应商主数据的讨论将以R11的GUI界面为主，然后再辅之以R12的WEB界面以做补充、比较。

4.1.1供应商的分类概述

企业的供应商按所提供产品与服务的用途划分，可分为“生产供应商”与“非生产供应商”两大类。所谓“生产供应商”是指其提供的产品或服务，企业并非终端使用者，而是进入企业销售的产品或服务之中，最终提供给企业的客户使用，例如原辅材料供应商，为企业的产品提供运输、维修等服务的供应商等等；所谓“非生产供应商”，是指企业自身就是终端使用或消费者，例如企业所使用的办公用品、仪器设备供应商，以及为企业的日常运作提供服务的广告公司、软件提供商、咨询顾问公司等等。

按供应商提供的产品与服务的形态划分，则可以划分为“有形”实物类的供应商，与“无形”服务类的供应商；按供应商与所提供产品的关系，可以分为“制造商、代理商”；按供应商的组织形态划分，则可以划分为“公司供应商”与“个人供应商”（在EBS中，公司员工有时需要当作供应商来处理）；按地域范围划分，则可以划分为“国内供应商与国外供应商”；按供应商所处生命周期或合作关系划分，则可以分为“潜在供应商、一次性供应商、试用供应商、长期合作供应商”等等。

在EBS系统中，供应商分类/类型LOV是在Lookup Code进行定义的，如图 4‑49所示。

图 4‑49 供应商类型的设置

尽管上面依据各种属性对供应商做了种种分类的讨论，但实际上在EBS系统中，除“员工”类型之外，其余“供应商类型”实际只是主要起到统计分析的作用，于系统流程角度看并无本质区别。但要注意的是，尽管供应商类型Vendor Type 的访问级别是“用户”，即用户可以完全自定义，其LOV值不参与系统流程构建。但EBS初始安装所预置值中的代码“EMPLOYEE 员工”并不能被删除或修改，因为在定义供应商时，如果找不到“员工”类型，则就无法将员工设置为供应商，而一旦无法将员工设为供应商，则应付AP系统在处理员工费用报表时将无法进行。故Vendor Type的“访问级别”实际上应当是“可扩展”（这可能是系统Bug）。

在EBS系统中，供应商的定义与维护是在AP模块而非PO模块中进行的。在AP模块中定义维护供应商，意味着即使没有或不使用PO模块，也可以在AP模块中对于需要向各种供应商进行付款的业务行为进行有效管理。EBS的AP模块定义的供应商主数据，将同时为PO模块、Asset资产模块、Property财产模块等所共享。

4.1.2供应商名称与编号（Supplier Name/Number）

在EBS系统中，由于实际使用习惯以及早期系统设计考虑欠周详等方面的原因，在PO模块的订单界面中是将“供应商名称”（Supplier Name）作为主要检索字段来使用的（PO界面甚至没有直接显示“供应商编号”字段）；而在AP模块的发票界面虽然有供应商编号字段，但人们在使用习惯上还是以“供应商名称”为主。故如果将“供应商名称”理解成供应商的“组织全称”，则实际使用将很不方便，因为一般来说供应商法律意义上的公司注册“全称”会比较长。

EBS的供应商定义界面有“供应商名称”与“别名”两个字段，考虑到上述因素，实际使用情况可能恰好相反：以“别名”字段记录供应商“全称”，而在“供应商名称”字段输入符合企业命名惯例且便于识别记忆的“短名、别名或简称”。如图 4‑50所示。

图 4‑50 供应商定义

系统要求“供应商名称”具有唯一性，但已经存在的供应商名称可以更改，且并不影响系统已经存在的相关业务数据。供应商一旦定义就无法删除，但可以通过“无效日期”设置使其不能输入发票或采购订单（并不影响已有业务的处理）。上图中“一般”Tab页中的“父供应商名称”及“编号”，表示当前供应商与系统中已经定义的其它供应商具有从属关系，而客户编码字段，则是本企业在该供应商处的标识编号。

“供应商编号”具有唯一性且不可更新（系统的跟踪标识），可以手工输入，也可以由系统自动生成，具体是那种方式由AP系统相关设置控制。这一点，R12与R11相比设置界面虽有所不同，但在多组织（OU）功能支持下，供应商的编号设定都是实现跨OU定义的，故其编号设置与OU无关。如图 4‑51所示的供应商编号设置（R12）。

图 4‑51 供应商编号方式设置

不过，在实际的企业管理实践中，使用“无涵义”的供应商自动编号并不可取，企业通常需要基于前面所讲的供应商分类，统筹考虑制定“有涵义”的手工编号规则，这是因为EBS系统所提供的供应商“分类”控制方式有点简单，缺少层次性，很多时候并不能很方便地满足实际统计分析工作的需要。实际工作中，基于业务管理需要，或者采用手工编号方式，或者在采用自动编号方式的同时，使用“说明性弹性域”作输入符合要求的编号信息。

4.1.3供应商的地点（Site）

 在本书第二章的相关内容中，已经对“Address、Location、Site”的三者关系已作了详细讨论。所谓“Site”的涵义更多的是表示一种比较虚无的管理“属性”，ORACLE借用Site（地点）的这一特性，来表示与同一供应商的合作过程中，可能存在有多种合作状况，例如一个集团公司性质的供应商，以一个整体对外与企业签署合作协议并承担有关法律责任，但实际业务的发生，则希望按不同子公司分别使用不同的银行账户与付款条件等等。

在EBS中，有关供应商的信息或属性被分为两个层次“供应商层”与“供应商地点层”，这两个层次的信息字段绝大部分有重复，少部分可能只在“供应商层”或“地点层”中才有。仅在“供应商层”有的信息如：“一般、分类、接收”Tab页中的相关内容，自动适用于“地点层”，为该供应商的不同Site所共有；在信息字段有重复的部分，“供应商层”的输入信息会被自动默认到Site层，但在Site层可更新维护，允许与供应商层内容不同。

而Site层的某些特有信息如“一般、联系人”Tab页中的相关内容，就只属于该Site，由于这个原因，故系统中每个供应商必须至少有一个Site。某些在供应商层与Site层均有的Tab页如“采购”，其实际字段内容Site层也比供应商层为多。如图 4‑52所示。

图 4‑52 供应商地点设置

R11的供应商层有12个Tab页，而Site层则只有11个Tab页，两相比较，“分类与接收”Tab页只在供应商层有，而“联系人”Tab页只在Site层有，并且“一般与采购”Tab页在供应商层与Site层的实际内容有较大区别，仅一部分有重叠。

Site添加则是在进入Site界面后按“新建”。同一供应商的Site必须具有唯一性（仅指同一OU内，不同OU下可以相同），但不同供应商的Site名称可以相同。已经存在的Site名称可以更改，并不影响其他相关应用。R11中无法同时直接显示创建的多个供应商Site，只能在进入Site界面后，通过“Page Down”键来顺序切换，或利用快捷“查找”功能显示结果后选择切换（这是R11系统设计使用不够方便的地方）。

4.1.4供应商的“分类“属性（Classification）

在供应商层的“分类”Tab页，除了前面供应商分类概述中讲到的“类型”（Type）字段的LOV可选值之外，系统还提供了一些其它的补充字段设置。如“少数民族经营的企业、女性经营的企业”等；其中，“一次性交易与小型企业”，只是一个标识，实际系统并不限制与其的交易次数与交易规模；SIC是Standard Industry Code 的缩写，只能手工输入，并无LOV值。不过，企业可以利用此SIC字段，输入自定义的符合企业某些特殊分类需要的代码，例如以不同代码区别“更可靠的供应商”和“不太可靠的供应商”，或者如“原始设备制造商”和“办公用品供应商”等等。上述字段均只有统计分析的功能，并不参与系统业务流程构建。

唯一比较特殊的是“类型”中取值为“员工Employee”时，才可以选择输入“员工姓名”及“员工编号”字段。在AP系统中，只有已经被创建为供应商的“员工”所建立的“费用报表”，才能成功导入到“发票”中去。不过，AP系统“将员工创建为供应商”参数可以设定“发票导入”功能将费用报表中的员工自动创建为供应商，故通常无需做员工供应商的手工维护。

4.1.5供应商的接收属性（Receiving）

 该属性仅在“供应商层”可设置，为所有的Site层所共用，如图 4‑53所示。

图 4‑53 供应商的接收属性

不过，这里的大多数属性设置，只是给采购订单PO提供默认值，允许手工修改。相关属性在其它地方如Item、系统接收选项等处也有类似设置，系统设计按照某种层次结构向PO默认（具体以后在讨论系统模块的应用功能时再作介绍）。或许正是这个原因，ORACLE觉得没有必要再在Site层作设置。此外，为方便供应商的创建，“财务系统选项、应付系统系统选项、采购系统选项”的有关设置值，均会默认至供应商的相关字段，这有助于提高录入速度。

4.1.6供应商Site层的“一般”属性

如图 4‑54所示，供应商Site层与“供应商层”的“一般”Tab页内容差别较大。Site层的“地点用途”中，“支付”如果未选定，就不能输入该供应商地点的发票；“主要支付地点”如果选定（将同时把“支付”选定），则表示该Site是输入供应商发票时的默认支付地点；“采购”如选定，则表示允许PO使用其向供应商订购产品或服务；“仅限于RFQ”则表示仅可用于下达RFQ（注意：它与“采购”选项在系统设置时虽可同时选定，但一旦选定了它，“采购”选项即行失效）。

图 4‑54 供应商的Site的一般属性设置

要注意的是，图 4‑54中“发运网络地点”（Location）是指为供应商该Site（或对应的实际Address）所分配的系统定义的“内部地点Location”，此字段中输入的地点会显示在采购订单PO窗口“收货地点“字段的值列表中，PO会在接收外协加工物料时使用此信息。在WIP 中，如果某个工艺路线具有两个连续的外协加工工序，则可以使用此“收货地点”以指定第一道外协加工工序的供应商应将完成装配件直接发运至下一道外协加工工序的供应商，故此时它实际上是指另一个供应商的收货地点Location（对应其实际Address）。

此外，在供应商层中输入“父供应商名称”时，仅当当前“供应商名称”是该父供应商名称的“Site”名称，则保存时才会将父供应商的相关信息自动默认过来，即除非子公司是母公司的供应商地点，否则系统不会从母公司自动将信息默认至子公司供应商。

4.1.7供应商Site层的“联系人”属性

该属性仅在Site层设置，为某些单据如PO的联系人字段提供LOV，超过其有效时间设定，引用的LOV中将不可见。如图 4‑55所示。

图 4‑55 供应商Site层的联系人设置

4.1.8供应商的多组织支持（MOAC）

这里所说的多组织是指多OU而言，R11与R12都实现了供应商的多组织功能，即供应商可跨组织（OU）定义与维护。系统通过将供应商Site与OU进行绑定来实现这一点，即任一供应商Site必须属于某一确定的OU（不同OU但名称相同的Site，实际上是两个不同的Site）。在使用多组织支持功能的系统环境下，不能在供应商层输入以下字段：负债帐户、预付款帐户、分配集、发票税税码和远期付款（应付票据）帐户（字段灰显），而只能在供应商地点层输入这些字段。

R11的供应商定义与维护虽然是在确定的OU上下文环境下进行，但为全部OU所共享；而在确定的OU上下文环境下所定义维护的供应商Site，则只能属于当前OU；要定义其它OU的供应商Site，必须将用户或责任先切换到目标OU上下文环境下。

R12实现了“供应商、供应商Site、业务实体OU”在同一Web界面做定义与维护，数据的可视性、集中管理的方便性大大提高，如图 4‑56所示。

图 4‑56 R12的供应商多组织信息设置

注意：R12与R11相比，供应商及供应商Site的属性字段的数量范围、分组方式虽有所变化，但基本的、核心的内容仍然保留一致（详情后面再介绍）。

4.1.9供应商及Site的“采购”属性

供应商层及Site层均有“采购”属性Tab页，但两者内容有所不同，Site层内容更为丰富，如图 4‑57所示。“收货地点Ship-to Location、收单地点Bill-to Location、发运方式ShipVia、FOB、安排的运输工具Transportation Arranged、原产地Coutry of Origin”这些字段主要是用于向PO提供默认值（可以修改）。除了收货地点、收单地点，其余几个属性的作用主要是在PO上体现法律意义上的权责界限。

图 4‑57中，供应商层的“采购订单暂挂”，如果选定并且也启用了“采购系统选项”窗口中“控制”区域的“强制供应商暂挂”选项，则可以为该供应商创建采购订单，但不能审批该采购订单。供应商层的“创建RTS事务处理的借項通知单”，如果选定，表示在采购系统中输入向该供应商的退货 (RTS) 时，系统将自动在AP中创建借项通知单；该字段会默认“采购系统选项”的相关值。

图 4‑57 供应商及Site的采购属性设置

图 4‑57中，在供应商Site层的“自动开票Self-Billing”区域的属性设置，主要是用于控制是否使用“根据采购接收给供应商自动开票”功能，以及相关属性的设定。大多数情况下，企业都是根据供应商提供的发票或应付清单（Bill）来做相关AP的流程处理。但特殊情况下，企业也可能需要根据采购接收直接做AP业务处理（即所谓AP的“自动开票Self Billing”）。“支付依据Pay On”可以有四个值：留空、三个LOV值（接收、接收与使用、使用）。当支付依据Pay On“留空”时，表示该供应商不允许使用“自动开票”功能；当不留空而选择LOV中的任一个如“接收”时，表示允许为该供应商启用“自动开票功能”（注意：供应商“自动开票”功能并不影响原AP的供应商发票录入功能）。

一旦为供应商Site启用“自动开票”功能，则必须为“发票汇总层”赋值。这是因为“自动开票”实际上是个后台并发流程（一般定期运行），需要设置如何为“批量”（接收）事务处理生成发票。“Pay On”为“接收”时，“发票汇总层”的选项包括“付款地点（为具有相同日期的事务处理的此供应商支付地点创建一张发票）、装箱单（为具有相同日期的事务处理的供应商支付地点的每张装箱单创建一张发票）、接收（为此供应商支付地点的每个接收创建一张发票）”；“Pay On”为“使用”时，“发票汇总层”的选项包括“付款地点、冲减通知”；“Pay On”为“接收与使用”时，“发票汇总层”的选项只能是“付款地点”。

“替代支付地点”字段，表示“自动开票”不使用当前供应商Site，而是使用另一个可开票的该供应商Site作为发票字段值。注意，如果当前Site是非开票Site，则必须为之设定“替代支付地点”。如果要使用当前Site自动开票，且当前Site是可开票地点，则将此字段留空（因为LOV中无当前Site选项）；

“连续发票编号”如果选定，表示自动开票的发票编号不允许间断，此时，必须为“卖方公司标识”字段赋值，标识字段将用于构建自动发票的编号。注意，同一供应商的不同Site可以具有同样的“公司标识”，不同供应商则必须互相不同。

4.1.10供应商及Site的“控制”属性（Control）

供应商层与供应商Site层的“控制”Tab页内容基本相同，仅在Site层多了“发票允差”字段。其中的“发票限额”设置，表示如果为该供应商地点输入的某张发票超过了指定的发票限额，则AP系统将在审批期间对该发票应用“金额”暂挂，在释放暂挂之前，将无法支付该发票。注意：“发票限额”的供应商层与Site层并无汇总关系，只是提供默认值。其LOV值是在AP系统专门设置的。“发票匹配选项”，有两个可选值：采购订单PO、收据Receipt。前者即为所谓“二重匹配”，后者即为所谓“三重匹配（接收Receive）或四重匹配（接受Accept）”（一般都是四重匹配，具体取决于企业管理规定）。如图 4‑58所示。

图 4‑58 供应商及Site的控制属性设置

图 4‑58中，供应商层或Site层的“暂挂所有付款、暂挂不匹配发票、暂挂未验证发票”，顾名思义，作用于不同的发票范围。而Site层的“发票允差”的值默认于“AP系统选项”的设定值（可以改写），其LOV值是在AP系统中专门定义的。如图 4‑59所示。

图 4‑59 供应商的发票允差设置

4.1.11供应商及Site的“付款”属性（Payment）

供应商层与供应商Site层的“付款”Tab页内容基本相同，仅“允许利息发票”字段只在供应商层才有。如果启用此选项，则AP系统将为供应商的逾期发票计算利息，并在支付逾期发票时创建相应的利息发票，系统将对供应商的所有地点自动执行此选项。注意：AP系统仅会为其逾期天数不超过 365 天的发票计算利息。启用此选项有一个前提条件是，必须先在“AP系统选项”中启用此项，否则，无法在供应商层启用。如图 4‑60所示。

图 4‑60 供应商及Site的付款属性设置

图 4‑60中，除“从折扣中扣除运费”字段的默认值（它始终为“否”）外，其它字段的默认值来自于在“财务系统”以及“AP系统”选项窗口中输入的默认值。

4.1.12供应商及Site的“会计”属性

在多组织功能环境下，仅在Site层可设置（供应商层相关字段灰显），有关字段的默认值均来自“财务或AP系统选项”的相关设置，如图 4‑61所示。

图 4‑61 供应商及Site层的会计属性设置

4.1.13供应商及Site的“银行账户”属性

供应商层与供应商Site层的内容完全相同。当以电子方式向供应商付款时（如网上银行等），必须严格为每种货币分配一个银行帐户作为主要银行帐户。如图 4‑62所示。

图 4‑62 供应商及Site的银行账户设置

当在AP系统输入发票时，发票币种的“供应商地点”的“主要银行帐户”信息将默认至每个计划付款。如果没有为供应商地点选定主要银行帐户，系统将使用供应商的主要银行帐户，而计划付款的汇入银行帐户将默认至付款。R11银行账户名称的LOV需要事先独立进行定义，而R12与R11的定义方式，有所不同，具体请参见本书（下部）最后章节“EBS R12的全新系统设置过程”的有关内容。

4.1.14供应商及Site的“发票税”属性

供应商层与供应商Site层内容完全相同，所有字段内容的默认值均来自于“财务或AP系统选项”。在多组织功能环境下，供应商层的值不可更新，仅供应商Site层的值可改写，但改写的前提条件是，在“AP系统选项”中已经启用相关设置选项如“自动计算”、“允许改写计算层”等。如图 4‑63所示。

图 4‑63 供应商及Site的发票税属性

R12系统的相关税务设置与R11系统的发票税码设置相比差异比较大，而供应商适用税率的方式也有很大不同。有关详情请参考本书（下部）最后章节“EBS R12的全新系统设置过程”的有关内容。

4.1.15供应商及Site的“预扣税”属性

供应商层与供应商Site层的内容完全相同，但两者之间以及与“应付AP系统选项”的相关设置之间有一定的制约关系。如图 4‑64所示。

图 4‑64 供应商及Site层的预扣税属性

图 4‑64中，如果不在供应商层选定“允许预扣税”，则无法打开供应商Site层的“预扣税”界面；而如果不在“应付AP系统选项”中设定“允许预扣税”，则供应商层的“预扣税”也无法打开。

4.1.16供应商及Site的“纳税申报及EDI”属性

EBS系统供应商的“纳税申报”信息主要适合于美国境内的情况，而“EDI”则随着电子商务信息技术的发展，已经逐步失去应用价值，故这两方面内容略过不提。

4.1.17R12的供应商定义与维护

4.1.17.1供应商属性分组

从大的内容范围角度来看，R12为供应商增加了三个新内容（或Tab“分组”页），包括：产品与服务、信息调查、相互关系。前两者主要应用于i-Supplier供应商门户产品中。在“产品与服务”Tab页中，以“类别Category”来表示供应商可以提供的产品与服务（由供应商在i-Supplier中维护），有关管理员可以“添加、删除、审批或拒绝”。如图 4‑65所示。

图 4‑65 R12的供应商产品与服务属性

在信息“调查”Tab页中，可以创建“调查表”要求供应商填写反馈并复查有关内容，如图 4‑66所示。

图 4‑66 R12 的供应商信息调查属性

而在“相互关系”Tab页，则规定了供应商（Site）在款项支付方面可以使用的替代供应商（Site）情况，如图 4‑67所示。

图 4‑67 R12供应商的相互关系属性

除了上述属性新增内容之外，R12的属性分组方法较之R11也有所变化。R12将属性分为两大块，一是“公司配置文件Company Profile”信息，包括供应商组织、税详细信息、地址簿、联系人、业务分类、产品与服务、银行信息、信息调查。这些信息通常是与组织（OU）无关的，部分内容可以使用i-Suppler 系统由供应商自己直接维护，但由供应商自己提交的任何有关信息更新需要经内部相关管理人员批准后才能生效；二是“条款与控制”信息，包括会计、纳税与申报、采购、接收、付款明细、关系、发票管理。这些信息通常与组织（OU）相关，只能有企业自己根据业务需要自己维护。

4.1.17.2供应商创建的类型

R12在题头层提供了两种供应商类型“标准供应商、用于处理内部员工的费用付款的供应商”选择的不同定义界面，这显然要比R11的处理方式更为合理。如图 4‑68所示的“标准供应商”定义界面。

图 4‑68 R12的标准供应商类型

以及如图 4‑69所示“用于处理内部员工的费用付款的供应商”的定义界面，员工类型的供应商必须属于确定的业务实体（OU）。

图 4‑69 R12的员工供应商类型

标准供应商与员工供应商的题头创建除了上述两种不同之外，其余的属性Tab页与R11相同，仍然是共用的。

4.1.17.3 标准供应商的“组织”属性

该Tab页的内容相当于R11的供应商层“一般”Tab页，但其内容要丰富的多，如图 4‑70所示（部分）。

图 4‑70 R12的供应商组织属性

4.1.17.4供应商的“地址簿”属性

相当于R11的创建供应商地点（Site），但方式与R11有很大不同。R12是先创建实际的地址Address及关联的地址名称，并为此地址分配用途：采购、付款、仅限于询价。如图 4‑71所示。

图 4‑71 R12的供应商地点创建

然后直接为之分配业务实体OU与地点名称Site，系统会列出当前所有业务实体供选择，而每个OU所关联的地点名称Site默认是“地址名称”，但可以更改。如图 4‑72所示。

图 4‑72R12的供应商地点分配

图 4‑72中的“改写默认地点属性”，提供了为所有供应商Site批量更改“采购、付款条件、发票管理”相关属性的便利工具（以后还可以逐个修改更新）。

4.1.17.5供应商的“联系人”属性

R12中的联系人定义与R11的不同之处在于，R12是先定义联系人然后分配给供应商Site及其关联的业务实体OU，同时还可以为供应商联系人分配用于供应链协作的相关应用模块的“责任”，如图 4‑73所示。

图 4‑73 R12的供应商联系人设置

4.1.17.6供应商的业务“分类”属性

R12的业务分类与R11相比也有所变化，原在Lookup Code中定义的供应商类型Type被弃之不用（为供应商题头的“标准与员工供应商”所取代）。如图 4‑74所示。

图 4‑74 R12 的供应商业务分类属性

4.1.17.7供应商的“银行账户”属性

R12的银行账户信息维护方式与R11相比也有较大变化.R11只能引用已经定义好的银行账户信息，而R12只能在定义供应商时，直接为“供应商、地址—地点、地址—地点—业务实体、地点-业务实体”的不同分配层创建银行账户信息，并且上一分配层所创建的银行账户信息可以在下一分配层被“添加”给有关条目。如图 4‑75所示。

图 4‑75 R12的供应商银行账户信息创建

R12在创建供应商银行账户信息的同时，还可以同时创建有关银行信息，如图 4‑76所示。有关R12银行信息及银行账户信息的创建，请参考本书（下部）最后章节“EBS R12全新系统设置及业务测试实例”的有关内容。

图 4‑76 R12的银行信息创建

4.1.17.8供应商的“会计”属性

R12的供应商“会计”信息内容与R11相同，但是在同一个界面列出了所有“Site—OU”组合的设置值，因而比较方便查看。如图 4‑77所示。

图 4‑77 R12的供应商会计属性

4.1.17.9供应商的“采购”属性

R12的供应商“采购”信息内容与R11基本相同，区别仅在于R12只能在供应商层设置“根据RTS事务处理创建借項通知单”，并在同一个界面列出了所有“Site—OU”组合的设置值。如图 4‑78所示。

图 4‑78 R12的供应商采购属性

4.1.17.10供应商的“付款“属性

R12的供应商“付款”属性内容与R11比有所不同，增加了“付款传递、付款规格、单独汇款通知单传递”等内容，并将支付条件等内容移至“发票管理”中，如图 4‑79所示。

图 4‑79 R12 的供应商付款属性

4.1.17.11供应商的“发票管理“属性

R12的“发票管理”Tab页内容实际是R11“付款、发票税”等属性页部分内容的重新组合，如图 4‑80所示。

图 4‑80 R12供应商的发票管理属性

4.1.17.12供应商的接收、纳税与申报属性

R12的“接收”属性内容与R11完全相同，只是换成WEB显示方式，“纳税申报”内容与R11也基本相同。而R11中的EDI属性则被R12略去（因为EDI已经不再是主流数据交换方式）。有关界面略。

4.1.17.13供应商的待办事宜列表

R12在供应商界面提供了对于来自i-Supplier模块的由供应商提交的相关配置文件维护与更新请求的“活动管理”功能。如图 4‑81所示。

图 4‑81 R12的供应商待办事宜列表

该管理功能反映了EBS系统正试图将核心业务的“流程集成”向非核心的外围系统的“活动集成”扩展的趋势。有关系统功能操作的界面。如图 4‑82所示。

图 4‑82 R12 供应商提交请求的管理

事实上，截止目前为止，无论是R11还是R12，有关供应商主数据的管理还基本只是停留在供应商数据最终结果的“录入”这样一个层面（系统还提供供应商数据接口表及导入功能，批量导入数据）。有关供应商数据“最终结果”如何得来，属于供应商关系管理SRM的范畴，涉及企业“供应商准入认证”的复杂过程，EBS目前尚未能提供完善的解决方案，还有待将来进一步发展与完善。

4.1.18供应商的合并

在实际工作中，可能因为某些原因需要将已经存在的两个供应商及其相关业务处理进行合并，例如供应商的多个子公司合并，供应商之间因为并购而合并，或者因为历史原因同一供应商在系统中存在两条记录等等。

EBS的“供应商合并”是一种后台并发程序，可以将重复供应商合并为单个的合并供应商；可以将相同供应商中的事务处理从一个供应商地点合并至不同的供应商地点；也可以选择将供应商的所有事务处理并入目标供应商；也可以选择仅合并未付发票等等。上述不同方式选择，可满足多种实际业务需求，例如可能需要保留包含原始供应商的所有事务处理历史记录，并且只需将未付发票并入现在需要接收付款的目标供应商等等。如图 4‑83所示。

图 4‑83 EBS的供应商合并

如果选定“复制地点”，则会为目标供应商自动创建原Site。如果选定“PO”，则系统将使用目标供应商信息更新所有相关的采购订单信息。包括：接收事务处理、报价单请求、供应商计划、来源补充信息、批准的供应商列表和 MRP 信息等等。作为合并程序的一部分，AP系统会使从中合并所有事务处理的原供应商地点无效。如果选择合并所有地点的所有事务处理，则AP系统还将自动使供应商无效。“供应商合并”不会删除原供应商数据实体（最多使之失效）。