二次函数考试注意点:系列之五：ORACLE EBS 系统主数据管理（H） - season的日志 - 网易博客

系列之五：ORACLE EBS 系统主数据管理（H）

Oracle ERP 2010-08-11 10:22:47 阅读13 评论0   字号：大中小 订阅

ORACLE EBS 系统主数据管理

四、客户（Customer）

（一）客户数据管理概述

（二）EBS 交易社区架构（TCA）

（三）客户的配置文件分类（Profile Class）

（四）客户的创建规则

（五）客户的多组织控制（MOAC）

（六）客户的交易方层属性及交易方关系

（七）客户的账户层与地点层属性

（八）客户账户层的“分类”分组属性

（九）客户账户层的“市场营销”分组属性

（十）客户账户层的“关系”分组属性

（十一）客户账户地点层的“特性”分组属性

（十二）客户账户与地点层的“通信”分组属性

（十三）客户账户与地点层的“联系人”分组属性

（十四）客户账户与地点层的“联系人：职责”分组属性

（十五）客户账户与地点层的“银行账户”分组属性

（十六）客户账户与地点层的“付款方法”分组属性

（十七）客户账户与地点层的“配置文件：事务处理”分组属性

（十八）客户账户与地点层的“配置文件：单据打印”分组属性

（十九）客户账户与地点层的“配置文件：金额”分组属性

（二十）客户账户的“地址地点与业务目的”属性

（二十一）R12客户的账户层与地点层属性

（二十二）客户数据的合并

（二十三）客户数据的其它管理功能

三、客户（Customer）

    客户是企业提供产品与服务的对象，是企业的衣食父母，是企业存在的前提条件。在当今世界经济全球化、一体化，市场竞争日益充分、激烈的大背景下，如何满足客户需求，为客户提供周到、细致的服务，是企业经营管理活动的头等大事。因此，在企业信息化实践方面，相较于最近几年才逐渐得到更多重视的供应商关系管理系统SRM，企业的客户关系管理系统CRM的发展历史渊源要早得多，产品的发展现状也丰富、完善得多。习惯上，人们很早就已经将CRM与传统的ERP看作是属于前后台（Front-Office、Back-Office）范畴，可以相提并论，具有一定独立性的两大产品。

     任何企业在市场环境中总是同时扮演着“供应商与客户”两种角色，作为“客户”角色，要管理好自己的“供应商”，这属于SRM产品的范畴；作为“供应商”，要对自己的“客户”进行有效管理，这属于CRM产品的范畴。无论属于哪种角色，都存在着所谓“供应商与客户”的竞争关系，但是在市场竞争的环境中，作为“供应商的客户”与作为“客户的供应商”两者所处的竞争地位与竞争优势是截然不同的，存在着明显的强弱差距。这一差距反映到企业管理实践与SRM/CRM产品的系统设计上，也会表现出鲜明的特点。

在企业管理实践中，企业对于供应商的管理，通常会采取“严进宽出”的总体策略，管理的重点放在供应商的“准入”资格认证过程管理，以及使用中的绩效考核管理上。而企业对于客户的管理，则通常会采取“宽进严出”的总体策略，管理的重点放在客户的信息收集与挖掘管理，以及使用中的风险控制管理上。企业管理实践这一根本性的策略差别，使得系统在供应商与客户的主数据管理的内容方面差别较大，客户主数据管理的复杂性与灵活性要求要明显高于供应商主数据。推而广之，使用供应商主数据的业务模块如PO系统，使用客户主数据的业务模块如OM系统，其复杂性也会有很大不同。有经验数据表明，PO与OM在系统实施上的相对困难程度比较是120：170。

（一）客户数据管理概述

     尽管对于一个确定的企业来说，其所具有的客户范畴可能并不复杂，例如有些生产专业仪器设备的企业，其客户面可能很窄，客户数量也很有限，但作为一个通用的、需要适应各行各业需要的CRM/ERP产品，其客户主数据所要考虑的因素，其所必须具有的灵活性与适应性就异常复杂了。有些企业的客户可能是政府机关、公用事业单位、生产制造企业、服务业、分销商、零售商、个人消费者等等，情况千差万别。若从信息系统设计与管理的角度去考察，客户主数据需要重点考虑以下几种情况：

一是“潜在客户”与“当前客户”。我们通常所说的“客户”（Customer）实际上是个广义的概念，它包括了两种情况，一种即所谓“售前客户”（Prospect），还未达成销售，企业正针对其展开营销活动（Marketing），或者正在向其提供报价，等待最终结果；一种是所谓“当前客户”（Account），已经与之达成过交易，正在继续为之提供产品或服务，希望未来能达成更多销售。

二是“集团客户”（Headquarter）与“子公司客户”（Subsidiary）。有些企业采取的集中采购的管理策略，由总部统一执行采购下单，但由各下述企业收货付款，或者由总部统一议定采购条款、签订框架合作协议，但由下属各企业执行具体采购过程。系统必须考虑这些企业之间的复杂关系，考虑销售策略、价格与条款政策、信用风险管控活动等等在它们之间如何协调问题。

三是“组织客户”与“个人客户”。有些企业产品或服务的对象，既可能是组织或单位，也可能个人，需要进行差别化的管理；

四是“直销”与“分销”。有些企业的产品由销售部门直接卖给终端客户（组织或个人），但有些则可能需要通过“中间商或渠道伙伴”（一级代理、二级代理等）才能最终到达最终用户手上；

五是“集中销售”与“分散销售”。有些企业的产品线可能比较复杂，不同产品可能由不同的销售团队，执行不同的销售政策销售给同一个客户，企业必须考虑相互间如何协调等问题。

六是“客商关系”。即有些企业的客户可能同时还是企业的供应商，存在互为买卖的关系，客观上需要在买卖政策、款项结算等方面做特殊考虑。

总之，外部客户的复杂性（个人与组织、组织与组织间关系）、销售过程的复杂性（售前、售中、售后）、企业内部的复杂性（不同产品、不同销售团队、不同销售地域）等等因素的综合作用，要求企业的客户主数据管理必须满足不同业务模块（诸如Marketing、Sales、Quote、Contract、i-Store等等）的不同功能使用的具体要求。

（二）EBS 交易社区架构（TCA）

      早期的ERP产品对于供应商与客户主数据的管理要求相对比较简单，主要是满足PO/AP模块、OM/AR模块等核心业务系统的要求。随着企业信息系统集成从核心业务系统向外围支持系统如SRM/CRM的扩展，以及企业管理的数据信息逐步由过去单个企业的“分散”应用向未来企业集团化、全球化的“集中统一”过渡，系统对于客户及供应商的主数据管理在完善性、灵活性、可扩展性等方面提出了更高的要求。正是在这一需求的大背景之下，ORACLE于2000年提出了有关主数据管理（当时主要是针对客户）的所谓“交易社区架构（Trading Community Architeture，TCA）”的概念。

     所谓交易社区架构TCA的概念，主要包含两层涵义，一层是从“技术架构”角度的主数据如何共享去讲的，系统中的各业务模块被看作是“社区成员”，相互之间使用统一的主数据，系统只需集中维护单一的数据来源。有关这一层涵义，今天人们已经很熟悉，无需多讲；二层涵义是从“业务应用”角度的主数据如何“模型化”角度去讲的，正如前文已经提到，任何企业在市场环境中，都同时承担着既是供应商又是客户的双重角色，作为每一独立存在的企业个体，在系统中也仿佛组成了一个“社区”，“社区成员”相互之间有时也存在着复杂的交易连接关系。以下重点介绍ORACLE客户数据“业务应用”层面的TCA架构模型化问题。

既然每一个企业作为“商业实体”是一种客观存在，那么其在系统中首先也可以被看作是一个具有身份标识、独立存在的“交易方”（Party），该“交易方”可以是组织，也可以是个人，拥有自己的、不依赖于其他方的数据信息，如组织、人员、产品、物理地址等等。在未与这些“交易方”产生真实的买卖活动之前，或曰“售前”阶段，这些“交易方”同样属于广义的“客户”概念范畴（Prospect），需要在系统中对它们相关的市场活动进行有效管理。

一旦与交易方（Party）达成买卖协议或开始下单，则可能需要与交易方达成一种或多种“买卖关系”，对于每一种“买卖关系”，EBS系统将之称为“账户（Account）”，注意，不要将这里的账户Account与所谓的“银行账号Bank Account”相混淆；在每一个账户Account之下，为了进一步区分某些交易属性（例如收单地点、银行账号等），可以再分为多个“账户地点”（Account Site）；一个“交易方”与“账户”的组合（Party+Account）称之为“客户Customer”（而不是Prospect）。我们通常所说的“客户经理”，其英译“Account Manager”，正是很好地体现了这里的所谓“交易方账户”的概念。

在EBS系统中所谓的“客户间关系”，主要是指“交易方关系”而言的，由于交易方Party是独立的存在，Party之间所建立的关系也是一种客观存在，不依赖于与己方所建立的某种买卖关系（Account），故而，这种“交易方关系”可以适应于所有业务系统（而不仅仅是传统的OM/AR系统）的使用需要。

早期的EBS版本（以及很多其它品牌的ERP产品）在实际应用中，人们都习惯于以“供应商地点、客户地点”来表达“总公司与子公司”的关系或层次结构，但基于EBS的TCA架构，对于客户的“层次结构”关系，ORACLE强烈建议不要使用“客户地点”来表达，因为相关CRM模块的诸多应用（例如“商机管理”等）是建立在Party而不是Site之上的。对于一个总公司附带若干分公司、子公司的客户情形，只要客观上需要将某一个分、子公司在市场营销、客户管理方面重点对待，ORACLE的建议倾向于为之建立单独的“Party”实体（细粒度管理），而不是降格为Site。

关于TCA的一个账户Account可以有多个“账户地点Account Site”的问题，其含义类似于原来的“一个供应商或客户可以有多个地点Site”。而一个交易方Party 具有多个账户Account的问题，主要是为了满足己方（而不是交易方或客户）内部业务管理复杂性的需要，例如公司有性质迥异的两种不同产品（如电视机和X光机），有不同的销售团队、商务策略以及生产厂家，但可能具有同一个客户（交易方），为了在内部管理上加以区分，则可以在一个Party之下建立多个Account。这有点类似你去同一个银行的不同支行开了多个户头，银行（一般是分行级）的业务管理系统第一次会根据你的身份证信息建立一个统一的“客户号”（类似Party Number），以后你在任一支行所开的户头均属于此客户号之下的Account。

按照ORACLE在多年以前的有关设想，最终包括供应商数据在内，所有有关客户的系统应用都要逐步迁移并适应于TCA架构。但遗憾的是，近十年时间过去，或许不可见的“技术架构”层面的TCA工作早已完成，但可见的、业务应用层面的TCA工作的进展还是比较缓慢：供应商主数据的TCA似乎尚未启动，客户主数据的TCA才开了一个头，核心业务系统如OM/AR的改造尚有很长的路要走，目前还无法实现“Party”层与“Account”层的数据分离，还无法实现按“Party”（或Account）实现业务数据与活动的“卷积”（Roll-Up）。

甚至于用“交易方Party+账户Account”这个概念取代传统的“Cunstomer”概念都有一定困难。原先在R11后期版本中出现的Party术语，在R12版本中甚至被改回用Customer术语代替，原先的Party Number则被改称为Registry ID。在系统中创建Party（Customer）的同时，必须同时为之创建Account，Party或Customer与Account被捆在了一起（原先的设想是根据需要再创建Account）。看来，ORACLE的主数据TCA架构适应性改造还任重道远，是一项艰巨的长期任务。

尽管TCA架构的目前使用尚不完善，使用范围有限，但在下面有关客户主数据的具体介绍中，将会不时出现它的身影，故为了帮助理解有关内容，这里有必要对其概念与内涵作简要介绍。

（三）客户的配置文件分类（Profile Class）

尽管在R11中，“客户配置文件分类”的设置并非为创建客户数据的前提条件，但在R12中，由于被改成了必须的前提条件，故这里要首先对之作介绍。所谓“客户配置文件分类”，简单说就是对具有相似信誉、业务量和付款周期（以及滞纳费用制度）的客户（账户Account）进行分组。对于每个配置文件分类，可以定义诸如信用限额、付款条件、对帐单周期、开票和折扣信息之类的信息。也可以为经营业务所用的每种币种定义财务费用、催款和对帐单限额等等信息。如下图82所示：

作为业务实例，可以定义三种“客户配置文件分类”：一种为准时付款客户，他们具有良好的信用限额；一种为延迟付款客户，他们具有较高的财务费用利率；另一种为经常准时付款的客户，可以通过提供折扣来鼓励他们提前付款。

定义的“客户配置文件分类”被客户（Account）所引用后，则该客户就具有了配置文件中所定义的所有相关属性。对于已经定义的配置文件相关字段进行修改，在保存时系统会询问对于已经引用该配置文件的客户的相关字段如何处理，如下图83所示：

具体包括：“不更新现有配置文件”，即配置文件分类的更改只对新增客户数据有效；“更新所有配置文件”，即配置文件分类的更改对包括已存在的所有客户数据有效；“更新所有未自定义的配置文件”，即只更新与当前被更改值具有相同值的客户数据。显然，系统的这种控制方式，对于批量定义、维护客户数据的某些字段内容将十分方便、灵活。

R12与R11的客户配置文件相比，内容及Tab页分组有一定变化，如下图84所示：

总的来说，客户配置文件的字段属性主要是应用于AR系统中（个别与OM系统有关，如信用检查等），为AR系统相关字段提供默认值或控制有关业务行为。“客户配置文件分类”因为只作用于客户的Account层或Account Site层（被引用），故称之为“账户配置文件”可能更合适。有关客户配置文件字段详情，请参考ORACLE相关文档，这里不赘述。

（四）客户的创建规则

目前，无论是R11还是R12，当在其中创建新客户（Customer）时，系统均需要同时创建一个账户Account及其账户地点Site。R11与R12的共同之处是，Acount与Site均可由系统自动生成（或手工输入）的编号Number作为唯一性标识，Site必须具有真实的物理地址Address；R11与R12的不同之处在于，R11的账户名Account Name变成了R12的账户说明Account Description，R12的Account Site还可以为之给定一个地点名Site Name。系统同时还会给客户自动创建（或手工输入）一个“顶层”的唯一性编号Number，在R11中称为交易方编号Party Number，在R12中称为注册号Registry ID。

     在R12中创建新客户时，首先需确定客户类型是“组织”还是“个人”，然后在“账户信息”区域选择账户类型是“外部”还是“内部”。“内部”表示公司内部客户的账户，“外部”表示公司外部客户账户。必须为账户赋予一个账户地点的物理地址，并同时为该“账户地点”指定其所属的业务实体OU，及其业务目的（收单方、收货方等等）。如下图85所示：

系统会为新创建的客户自动生成（或手工输入）注册标识号（亦即Party Number）、客户账户号（Account Number）以及账户地点编号（Account Site Number）。然后可以根据业务需要，为该客户添加新的账户Account（及其Site，所属的OU以及业务目的等），也可以为当前账户Account 添加新的地点Site信息。如下图86所示：

R11的新客户及其所属账户的创建过程略为抽象，在输入新客户名称后，系统如果未发现有重名，则会弹出是否“新建”的询问界面，如下图87所示：

在新建客户名及其账户、账户地址后，系统会自动为之生成两行记录，一行是交易方编号和地址信息，一行是该交易方所属账户编号（Account）及其地点编号（Site）。如要为该交易方添加新的账户Account，需要定位到“交易方编号和地址信息”行，再按“确定”方可。如要为已经存在的账户编号（Account）新增地点Site，必须先定位到“账户编号（Account）及其地点编号（Site）”行，再按“确定”方可。如下图88所示：

与供应商名称必须唯一不同，新建的客户名称（Party Name）并不要求唯一，可以重复。已经存在的客户名称也可以更改。与供应商只包含一个编号不同，每个客户数据至少包含“交易方编号Party Number”、“地点编号Site Number”、“账户编号Account Number”以及“业务目的地点编号Usage Location Number”（多个，具体下面介绍）等等。这些编号是自动生成还是手工输入，取决于如下设置：Party Number与Site Number分别由系统配置文件“HZ：自动生成交易方编号、HZ：自动生成交易方地点编号”控制，Account Number与Usage Location Number 则分别由AR系统选项的“自动客户（账户）编号”与“自动地点编号”来控制