《系列之五：ORACLE EBS 系统主数据管理(E).docx》由会员分享，可在线阅读，更多相关《系列之五：ORACLE EBS 系统主数据管理(E).docx（13页珍藏版）》请在三一办公上搜索。
1、系列之五：ORACLE EBS 系统主数据管理（E）热度 12已有 860 次阅读 2010/1/17 14:00 |关键词:EBS ORACLE 数据管理 系统 ORACLE EBS 系统主数据管理三、供应商（Supplier）（一）供应商的分类概述（二）供应商“名称与编号”（Supplier Name/Number）（三）供应商的“地点”（Site）（四）供应商的“分类”属性（Classification）（五）供应商的“接收”属性（Receiving）（六）供应商Site层的“一般”属性（七）供应商Site层的“联系人”属性（八）供应商的多组织支持（MOAC）（九）供应商（Site）的“
2、采购”属性（十）供应商（Site）的“控制”属性（Control）（十一）供应商（Site）的“付款”属性（Payment）（十二）供应商（Site）的“会计”属性（十三）供应商（Site）的“银行账户”属性（十四）供应商（Site）的“发票税”属性（十五）供应商（Site）的“预扣税”属性（十六）供应商（Site）的“纳税申报”及“EDI”属性（十七）R12的供应商定义与维护（十八）供应商的合并四、客户（Customer）（一）客户数据管理概述（二）EBS 交易社区架构（TCA）（三）客户的配置文件分类（Profile Class）（四）客户的创建规则（五）客户的多组织控制（MOAC）（六）
3、客户的交易方层属性及交易方关系（七）客户的账户层与地点层属性（八）客户账户层的“分类”分组属性（九）客户账户层的“市场营销”分组属性（十）客户账户层的“关系”分组属性（十一）客户账户地点层的“特性”分组属性（十二）客户账户与地点层的“通信”分组属性（十三）客户账户与地点层的“联系人”分组属性（十四）客户账户与地点层的“联系人：职责”分组属性（十五）客户账户与地点层的“银行账户”分组属性（十六）客户账户与地点层的“付款方法”分组属性（十七）客户账户与地点层的“配置文件：事务处理”分组属性（十八）客户账户与地点层的“配置文件：单据打印”分组属性（十九）客户账户与地点层的“配置文件：金额”分组属性（
4、二十）客户账户的“地址地点与业务目的”属性（二十一）R12客户的账户层与地点层属性（二十二）客户数据的合并（二十三）客户数据的其它管理功能五、结语三、供应商（Supplier）在二十一世纪的今天，人们已经逐步认识到，企业之间的竞争已不完全是单个企业之间的竞争，而是企业所拥有的供应链之间的整体竞争。企业供应链的效率与质量如何，关系到企业在日益残酷的市场游戏中能否取得竞争优势。企业与供应商之间的关系，也不再是过去简单的买卖关系，而是越来越深入、紧密的合作伙伴关系。企业与自己的供应商之间既有不同利益的矛盾，也有共同利益的合作。在企业的管理实践过程中，涉及“供应商”的管理信息系统的设计主要有两方面内容
5、，一是与供应商在日常业务过程中的商务协同，包括供应商门户、订单协同、计划协同、询报价、招投标等等内容，通常归入SCM产品的范畴；二是供应商的生命周期与关系管理，包括供应商准入管理、资格认证、协议与合同管理、绩效考评等等内容，通常归入SRM产品的范畴。这两方面的内容的连接点就是“供应商主数据”，前者涉及供应商主数据的使用，后者涉及供应商主数据的创建与维护。在ORACLE EBS系统中，涉及供应商主数据“使用”的SCM产品目前已经比较完善，而涉及供应商主数据“创建”的SRM产品目前还在发展过程中。R12将供应商主数据的定义与维护从GUI界面变为WEB界面，也是考虑了SRM产品的未来拓展需要。由于R
6、12与R11的供应商主数据相比，除了多组织控制，在内容方面并无本质上的太大变化，考虑到WEB界面不太方便于系统学习演示，故以下关于供应商主数据的讨论将以R11的GUI界面为主，然后再辅之以R12的WEB界面以做补充、比较。（一）供应商的分类概述企业的供应商按所提供产品与服务的用途划分，可分为“生产供应商”与“非生产供应商”两大类。所谓“生产供应商”是指其提供的产品或服务，企业并非终端使用者，而是进入企业销售的产品或服务之中，最终提供给企业的客户使用，例如原辅材料供应商，为企业的产品提供运输、维修等服务的供应商等等；所谓“非生产供应商”，是指企业自身就是终端使用或消费者，例如企业所使用的办公用品
7、、仪器设备供应商，以及为企业的日常运作提供服务的广告公司、软件提供商、咨询顾问公司等等。按供应商提供的产品与服务的形态划分，则可以划分为“有形”实物类的供应商，与“无形”服务类的供应商；按供应商与所提供产品的关系，可以分为“制造商、代理商”；按供应商的组织形态划分，则可以划分为“公司供应商”与“个人供应商”（在EBS中，公司员工有时需要当作供应商来处理）；按地域范围划分，则可以划分为“国内供应商与国外供应商”；按供应商所处生命周期或合作关系划分，则可以分为“潜在供应商、一次性供应商、试用供应商、长期合作供应商”等等。在EBS系统中，供应商分类/类型LOV是在Lookup Code进行定义的，如
8、下图47所示：要注意的是，尽管供应商类型Vendor Type 的访问级别是“用户”，即用户可以完全自定义，其LOV值不参与系统流程构建。但ORACLE初始安装所预置的值中代码“EMPLOYEE 员工”并不能被删除或修改，因为在供应商定义引用时，如果找不到“员工”类型，则就无法将员工设置为供应商（而一旦无法将员工设为供应商，则AP在处理员工费用报表时将无法进行）。故推测Vendor Type的“访问级别”实际上应当是“可扩展”，这可能是系统设计疏忽。尽管上面依据各种属性对供应商做了种种分类的讨论，但实际上在EBS系统中，除“员工”类型之外，其余只是主要起到统计分析的作用，于系统流程角度看并无本
9、质区别。在EBS系统中，供应商的定义与维护是在AP模块而非PO模块中进行的（之所以如此，与ORACLE的产品发展历程有一定关系）。在AP模块中定义维护供应商，意味着即使没有或不使用PO模块，也可以在AP模块中对于需要向各种供应商进行付款的业务行为进行有效管理。EBS的AP模块定义的供应商主数据，将同时为PO模块、Asset资产模块、Property财产模块等所共享。（二）供应商“名称与编号”（Supplier Name/Number）在EBS系统中，由于实际使用以及早期系统设计考虑欠周详等方面的原因，在PO模块的订单界面中是将“供应商名称”（Supplier Name）作为主要检索字段来使用的
10、（PO界面甚至没有直接显示“供应商编号”字段），在AP模块的发票界面虽然有供应商编号字段，但人们在使用习惯上还是以“供应商名称”为主。故如果将“供应商名称”理解成供应商的“组织全称”，则实际使用将很不方便，因为一般来说供应商法律意义上的公司注册“全称”会比较长。EBS的供应商定义界面有“供应商名称”与“别名”两个字段，考虑到上述因素，实际使用情况可能恰好相反：以“别名”字段记录供应商“全称”，而在“供应商名称”字段输入符合企业命名惯例且便于识别记忆的“短名、别名或简称”。如下图48所示：系统要求“供应商名称”具有唯一性，但已经存在的供应商名称可以更改，且并不影响系统已经存在的相关业务数据。供应
11、商一旦定义就无法轻易删除，可以通过“无效日期”设置使其不能输入发票或采购订单（并不影响已有业务的处理）。上图中“一般”Tab页中的“父供应商名称”及“编号”，表示当前供应商与系统中已经定义的其它供应商具有从属关系，而客户编码字段，则是本企业在该供应商处的标识编号。“供应商编号”具有唯一性且不可更新（系统的跟踪标识），可以手工输入，也可以由系统自动生成，具体是那种方式由AP系统相关设置控制。这一点，R12与R11相比设置界面虽有所不同，但在多组织（OU）功能支持下，供应商的编号设定都是实现跨OU定义的，故其编号设置与OU无关。如图49所示R12的供应商编号设置：不过，在实际的企业管理实践中，使用
12、“无涵义”的供应商自动编号并不可取，企业通常需要基于前面所讲的供应商分类，统筹考虑制定“有涵义”的手工编号规则，这是因为EBS系统所提供的供应商“分类”控制方式有点简单，缺少层次性，很多时候并不能很方便地满足实际统计分析工作的需要（这或许是EBS系统设计方面的不足）。（三）供应商的“地点”（Site） 在“ORACLE EBS基础设置要点简介”一文中，关于“Address、Location、Site”的三者关系已经有详细介绍。Site的涵义更多的是表示一种比较虚无的“属性”，ORACLE借用Site（地点）的这一特性，来表示与同一供应商的合作过程中，供应商可能有多种合作状况，例如一个集团公司性
13、质的的供应商，以一个整体对外与企业签署合作协议并承担有关法律责任，但实际业务的发生，希望按不同子公司分别使用不同的银行账户与付款条件等等。在EBS中，有关供应商的信息或属性被分为两个层次“供应商层”与“供应商地点层”，这两个层次的信息字段绝大部分有重复，少部分可能只在“供应商层”或“地点层”中才有。仅在“供应商层”有的信息如：“一般、分类、接收”Tab页中的相关内容，自动适用于“地点层”，为该供应商的不同Site所共有；在信息字段有重复的部分，“供应商层”的输入信息会被自动默认到Site层，但在Site层可更新维护而允许与供应商层内容不同。而Site层的某些特有信息如“一般、联系人”Tab页中
14、的相关内容，就只属于该Site，由于这个原因，故系统中每个供应商必须至少有一个Site。某些在供应商层与Site层均有的Tab页如“采购”，其实际字段内容Site层也比供应商层为多。如下图50所示： 上图中，R11的供应商层有12个Tab页，而Site层则只有11个Tab页，两相比较，“分类与接收”Tab页只在供应商层有，而“联系人”Tab页只在Site层有，并且“一般与采购”Tab页在供应商层与Site层的实际内容有较大区别，仅一部分有重叠。Site添加则是在进入Site界面后按“新建”。同一供应商的Site必须具有唯一性（仅指同一OU内，不同OU下可以相同），但不同供应商的Site名称可以
15、相同。已经存在的Site名称可以更改，并不影响其他相关应用。R11中无法同时直接显示创建的多个供应商Site，只能在进入Site界面后，通过“Page Down”键来顺序切换，或利用快捷“查找”功能显示结果后选择切换（这是R11系统设计使用不够方便的地方）。（四）供应商的“分类”属性（Classification） 在供应商层的“分类”Tab页，除了前面供应商分类概述中讲到的“类型”（Type）字段的LOV可选值之外，系统还提供了一些其它的补充字段设置。如上图50中所示包括：“少数民族经营的企业、女性经营的企业”（不明白ORACLE预置这两种类型有什么实际意义？）；“一次性交易与小型企业”，只
16、是一个标识，实际系统并不限制与其的交易次数与交易规模；SIC是Standard Industry Code 的缩写，只能手工输入，并无LOV值。不过，企业可以利用此SIC字段，输入自定义的符合企业某些特殊分类需要的代码，例如以不同代码区别“更可靠的供应商”和“不太可靠的供应商”，或者如“原始设备制造商”和“办公用品供应商”等等。上述字段均只有统计分析的功能，并不参与系统业务流程构建。唯一比较特殊的是“类型”中取值为“员工Employee”时，才可以选择输入“员工姓名”及“员工编号”字段。在AP系统中，只有已经被创建为供应商的“员工”所建立的“费用报表”，才能成功导入到“发票”中去。不过，AP系
17、统“将员工创建为供应商”参数可以设定“发票导入”功能将费用报表中的员工自动创建为供应商，故通常无需做员工供应商的手工维护。（五）供应商的“接收”属性（Receiving） 该属性仅在“供应商层”可设置，为所有的Site层所共用，如下图51所示：不过，这里的大多数属性设置，只是给采购订单PO提供默认值，允许手工修改。相关属性在其它地方如Item、系统选项等处也有类似设置，系统设计按照某种层次结构向PO默认（具体以后在讨论系统模块的应用功能时再作介绍）。或许正是这个原因，ORACLE觉得没有必要再在Site层作设置。此外，为方便供应商的创建，有关的“财务系统选项、应付系统系统选项、采购系统选项”的
18、设置，均会默认至供应商的相关字段，这有助于提高录入速度。（六）供应商Site层的“一般”属性如下图52所示，供应商Site层与“供应商层”的“一般”Tab页内容差别较大。Site层的“地点用途”中，“支付”如果未选定，就不能输入该供应商地点的发票；“主要支付地点”如果选定（将同时把“支付”选定），则表示该Site是输入供应商发票时的默认支付地点；“采购”如选定，则表示允许PO使用其向供应商订购产品或服务；“仅限于RFQ”则表示仅可用于下达RFQ（注意：它与“采购”选项在系统设置时虽可同时选定，但实际上一旦选定了它，“采购”选项即行失效）。要注意的是，上图中“发运网络地点”（Location）是
19、指为供应商该Site（或对应的实际Address）所分配的系统定义的“内部地点Location”，此字段中输入的地点会显示在采购订单PO窗口“收货地点“字段的值列表中，PO会在接收外协加工物料时使用此信息。在WIP 中，如果某个工艺路线具有两个连续的外协加工工序，则可以使用此“收货地点”以指定第一道外协加工工序的供应商应将完成装配件直接发运至下一道外协加工工序的供应商，故此时它实际上是指另一个供应商的收货地点Location（对应其实际Address）。此外，“发运网络地点”所使用的“内部地点”，还被用于将“内部组织”与“内部供应商”自动链接。因为每个“内部地点”只能分配给唯一的“供应商（地点
20、）”，故“公司间事务处理流”功能会根据相关业务表单中的“内部地点”，自动寻找并链接到唯一的“（内部）供应商”，以便在公司间开票时使用。上图中，在供应商层的分类中输入“父供应商名称”时，如果当前“供应商名称”是该父供应商名称的“Site”名称，则保存时会将父供应商的相关信息自动默认过来，即除非子公司是母公司的供应商地点，否则系统不会从母公司自动将信息默认至子公司供应商。（七）供应商Site层的“联系人”属性该属性仅在Site层设置，为某些单据如PO的联系人字段提供LOV，超过其有效时间设定，引用的LOV中将不可见。如下图53所示：（八）供应商的多组织支持（MOAC）这里所说的多组织是指多OU而言
21、，R11与R12都实现了供应商的多组织功能，即供应商可跨组织（OU）定义与维护。系统通过将供应商Site与OU进行绑定来实现这一点，即任一供应商Site必须属于某一确定的OU（不同OU但名称相同的Site，实际上是两个不同的Site）。在使用多组织支持功能的系统环境下，不能在供应商层输入以下字段：负债帐户、预付款帐户、分配集、发票税税码和远期付款（应付票据）帐户（字段灰显），而只能在供应商地点层输入这些字段。R11的供应商定义与维护虽然是在确定的OU上下文环境下进行，但为全部OU所共享；而在确定的OU上下文环境下所定义维护的供应商Site，则只能属于当前OU；要定义其它OU的供应商Site，必须将用户或责任先切换到目标OU上下文环境下。R12实现了“供应商、供应商Site、业务实体OU”在同一Web界面做定义与维护，数据的可视性、集中管理的方便性大大提高，如下图54所示：注意：R12与R11相比，供应商及供应商Site的属性字段的数量范围、分组方式虽有所变化，但基本的、核心的内容仍然保留一致（详情后面再介绍）。
