ORACLE EBS 系统主数据管理
（十七）R12的供应商定义与维护
（十八）供应商的合并
（一）客户数据管理概述
（四）客户的创建规则
（七）客户的账户层与地点层属性
（十一）客户账户地点层的“特性”分组属性
（二十一）R12客户的账户层与地点层属性
（二十二）客户数据的合并
（二十三）客户数据的其它管理功能
五、结语
（1）供应商属性“分组”
从大的内容范围角度来看，R12为供应商增加了三个新内容（或Tab“分组”页），包括：产品与服务、信息调查、相互关系。前两者主要应用于i-Supplier供应商门户产品中。在“产品与服务”Tab页中，以“类别Category”来表示供应商可以提供的产品与服务（由供应商在i-Supplier中维护），有关管理员可以“添加、删除、审批或拒绝”。如下图63所示：
在“信息调查”Tab页中，可以创建“调查表”要求供应商填写反馈并复查有关内容，如下图64所示：
在“相互关系”Tab页，则规定了供应商（Site）在款项支付方面可以使用的替代供应商（Site）情况，如下图65所示：
除了上述属性新增内容之外，R12的属性分组方法较之R11也有所变化。R12将属性分为两大块，一是“公司配置文件Company Profile”信息，包括供应商组织、税详细信息、地址簿、联系人、业务分类、产品与服务、银行信息、信息调查。这些信息通常是与组织（OU）无关的。可以使用i-Suppler 系统由供应商自己直接维护，但由供应商自己提交的任何有关信息更新需要经内部相关管理人员批准后才能生效；二是“条款与控制”信息，包括会计、纳税与申报、采购、接收、付款明细、关系、发票管理。这些信息通常与组织（OU）相关，只能有企业根据需要自己维护。
（2）供应商创建的不同“类型”
R12在题头层提供了两种供应商类型“标准供应商、用于处理内部员工的费用付款的供应商”选择的不同定义界面，这显然要比R11的处理方式更为合理。如下图66所示的“标准供应商”定义界面：
以及如下图67所示“用于处理内部员工的费用付款的供应商”的定义界面，员工类型的供应商必须属于确定的业务实体（OU）：
标准供应商与员工供应商的题头创建除了上述两种不同之外，其余的属性Tab页与R11相同，仍然是共用的。
（3）标准供应商的“组织”属性
该Tab页的内容相当于R11的供应商层“一般”Tab页，但其内容要丰富的多，如下图68所示：
（4）供应商的“地址簿”属性
相当于R11的创建供应商地点（Site），但方式与R11有很大不同。R12是先创建实际的地址Address及关联的地址名称，并为此地址分配用途：采购、付款、仅限于询价。如下图69所示：
然后直接为之分配业务实体OU与地点名称Site，系统会列出当前所有业务实体供选择，而每个OU所关联的地点名称Site默认是“地址名称”，但可以更改。如下图70所示：
上图中的“改写默认地点属性”，提供了为所有供应商Site批量更改“采购、付款条件、发票管理”相关属性的便利工具（以后还可以逐个修改更新）。
（5）供应商的“联系人”属性
R12中的联系人定义与R11的不同之处在于，R12是先定义联系人然后分配给供应商Site及其关联的业务实体OU。同时还可以为之分配用于供应链协作的相关应用模块的“责任”，如下图71所示：
（6）供应商的“业务分类”属性
R12的业务分类与R11相比也有所变化，原在Lookup Code中定义的供应商类型Type被弃之不用（为供应商题头的“标准与员工供应商”所取代）。如下图72所示：
（7）供应商的“银行账户”属性
R12的银行账户信息维护方式与R11相比也有较大变化.R11只能引用已经定义好的银行账户信息，而R12只能在定义供应商时，直接为“供应商、地址—地点、地址—地点—业务实体、地点-业务实体”的不同分配层创建银行账户信息，并且上一分配层所创建的银行账户信息可以在下一分配层被“添加”给有关条目。如下图73所示：
R12在创建供应商银行账户信息的同时，还可以同时创建有关银行信息，如下图74所示：
（8）供应商的“会计”属性
R12的供应商“会计”信息内容与R11相同，但是在同一个界面列出了所有“Site—OU”组合的设置值，因而比较方便。如下图75所示：
（9）供应商的“采购”属性
R12的供应商“采购”信息内容与R11基本相同，区别仅在于R12只能在供应商层设置“根据RTS事务处理创建借項通知单”，并在同一个界面列出了所有“Site—OU”组合的设置值。如下图76所示：
（10）供应商的“付款”属性
R12的供应商“付款”属性内容与R11比有所不同，增加了“付款传递、付款规格、单独汇款通知单传递”等内容，而将支付条件等内容移至“发票管理”中，如下图77所示：
（11）供应商的“发票管理”属性
R12的“发票管理”Tab页内容实际是R11“付款、发票税”等属性页部分内容的重新组合，如下图78所示：
（12）供应商的“接收”、“纳税与申报”属性
R12的“接收”属性内容与R11完全相同，只是换成WEB显示方式，“纳税申报”内容与R11也基本相同。而R11中的EDI属性则被R12略去（因为已经不再是主流数据交换方式）。有关界面略。
（13）供应商的“待办事宜列表”
R12在供应商界面提供了对于来自i-Supplier模块的由供应商提交的相关配置文件维护与更新请求的“事务管理”功能。如下图79所示：
该管理功能反映了EBS系统正试图将核心业务的“流程集成”向非核心的外围系统的“管理集成”扩展的趋势。有关管理操作的界面如下图80所示：
事实上，截止目前为止，无论是R11还是R12，有关供应商主数据的管理还基本只是停留在供应商数据最终结果的“录入”这样一个层面（系统还提供供应商数据接口表及导入功能，批量导入数据）。有关供应商数据“最终结果”如何得来，属于供应商关系管理SRM的范畴，涉及企业“供应商准入认证”的复杂过程，EBS目前尚未能提供完善的解决方案，还有待将来进一步发展与完善。
在实际工作中，可能因为某些原因需要将已经存在的两个供应商及其相关业务处理进行合并，例如供应商的多个子公司合并，供应商之间因为并购而合并，或者因为历史原因同一供应商在系统中存在两条记录等等。
EBS的“供应商合并”是一种后台并发程序，可以将重复供应商合并为单个的合并供应商，并可以将相同供应商中的事务处理从一个供应商地点合并至不同的供应商地点。也可以选择将供应商的所有事务处理并入目标供应商，也可以选择仅合并未付发票。上述不同方式选择，可满足多种实际需求，例如可能需要保留包含原始供应商的所有事务处理历史记录，并且只需将未付发票并入现在需要接收付款的目标供应商等等。如下图81所示：
如果选定“复制地点”，则会为目标供应商自动创建原Site。如果选定“PO”，则系统将使用目标供应商信息更新所有相关的采购订单信息。包括：接收事务处理、报价单请求、供应商计划、来源补充信息、批准的供应商列表和 MRP 信息等等。作为合并程序的一部分，AP系统会使从中合并所有事务处理的原供应商地点无效。如果选择合并所有地点的所有事务处理，则AP系统还将自动使供应商无效。“供应商合并”不会删除原供应商数据实体（最多使之失效）。
809
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
