ORACLE EBS 系统主数据管理（客户）

杰夫之产业互联网 2021-07-05

5290

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

4.3客户（Customer）

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

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

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

4.1.1客户数据管理概述

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

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

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

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

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

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

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

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

4.1.2EBS 交易社区架构（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版本在实际应用中，人们都习惯于以“供应商地点、客户地点”来表达“总公司与子公司”的关系或层次结构，但基于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架构的目前使用尚不完善，使用范围有限，但在下面有关客户主数据的具体介绍中，将会不时出现它的身影，故为了帮助理解有关内容，这里有必要对其概念与内涵作简要介绍。

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

尽管在R11中，“客户配置文件分类”的设置并非为创建客户数据的前提条件，但在R12中，由于被改成了必须的前提条件，故这里要首先对之作介绍。如图 4‑84所示。

图 4‑84 客户配置文件设置

所谓“客户配置文件分类”，简单说就是对具有相似信誉、业务量和付款周期（以及滞纳费用制度）的客户（账户Account）进行分组。对于每个配置文件分类，可以定义诸如信用限额、付款条件、对帐单周期、开票和折扣信息之类的信息。也可以为经营业务所用的每种币种定义财务费用、催款和对帐单限额等等信息作为业务实例，可以定义三种“客户配置文件分类”：一种为准时付款客户，他们具有良好的信用限额；一种为延迟付款客户，他们具有较高的财务费用利率；另一种为经常准时付款的客户，可以通过提供折扣来鼓励他们提前付款。

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

图 4‑85 客户配置文件的更新

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

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

4.1.4创建客户

R11与R12的客户数据创建实际都是在“交易社区”模块中完成的，但R11打开的仍是GUI表单页面，而R12打开的则是“交易社区”的Web页面。有关R12（及R11）客户数据的“交易社区”相关内容，请参见下文“4.4.23交易社区系统简介”的有关说明。

无论是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，及其业务目的（收单方、收货方等等）。如图 4‑86所示。

图 4‑86 R12的客户创建

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

图 4‑87 R12的客户地点创建

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

图 4‑88 R11的客户创建

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

图 4‑89 R11的客户账户及地点

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

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

与供应商的多组织控制是在供应商Site层完全相同的是，客户数据的多组织（OU）控制也是在账户地点层Account Site进行的。R11的客户数据新建“交易方Party”及其账户Account信息虽然是在确定的OU下进行的，但实际它们都是跨OU的，但与之同时创建的Account Site 则是属于确定的OU的。如要为不同的OU创建同一Party下的不同Account Site，必须首先切换到目标OU下方可。而R12因为在创建Account与Account Site的同时需要为之分配相应的OU，故其操作要方便、灵活得多。

4.1.6客户的交易方层属性及交易方关系

R12的Party层具有更多可默认作用于下一层的结构化信息，R11的Party层信息则相对比较简单。R11与R12两者均具有查询客户“第三方数据”的功能，如D&B企业数据查询。D&B企业数据就是前面在讲物料分类编码UNSPSC时，提到的邓百氏咨询公司（Dun & Bradstreet）所提供的一项企业基础数据服务。凡在该公司登记注册并接受其认证的企业，均会得到一个全球唯一的9位企业代码标识，称为DUNS编号。其它企业可以向该公司购买并与之在线联网自动更新自己感兴趣的交易方（供应商或客户）的基础信息资料。如图 4‑90所示R12客户Party层信息。

图 4‑90 R12的交易方信息维护

R11与R12均可以在Party层维护交易方关系，R12的维护操作更方便一些。结合前面有关TCA架构的简要介绍，在对上述客户Party层、Account层、Site层的相互关系有了更多理解之后，我们或许可以对于ORACLE强调所强调的，不能用传统的“客户+客户地点”的方式来表达客户的组织层级关系有更进一步的认识。

4.1.7客户的账户层与地点层属性概述

EBS的客户账户层属性与地点（地址）层属性的关系和供应商层与供应商地点层属性的关系类似。R11客户账户层属性共有13个Tab页，包括“地址、分类、订单管理、市场营销、通信、联系人、联系人：职责、银行账户、付款方法、配置文件：事务处理、配置文件：单据打印、配置文件：金额、关系”，而账户地点层属性则也有13个Tab页，包括：业务员目的、特性、通信、联系人、联系人：职责、银行账户、付款方法、配置文件：事务处理、配置文件：单据打印、配置文件：金额，以及对应于每个“业务目的地点层”的“详细资料、账户、订单管理”。抛开账户层的“地址”与地点层的“业务目的”两个有特殊关系的Tab页不论，只属于账户层的Tab属性页只有“分类、市场营销、关系”，只属于地点层的Tab页只有“特性”以及“业务目的地点”的“详细资料、账户”。

4.1.8客户账户层的“分类”属性

“分类”属性只在客户账户层出现，主要是有关客户账户自然属性如“分类、销售关系、税”等方面的内容。如图 4‑91所示。

图 4‑91 客户账户的分类属性

图 4‑91的“分类”Tab页中，“配置文件分类”不可输入，只是显示“配置文件：事务处理”Tab页的相关字段设定值，并随之而变化；分类（Classfication）、类别（Category）的LOV均是可以根据需要在Lookup Code中预先定义的；类型（Type）包括“内部、外部”选项；在多组织环境下，由于只能在账户地点而非账户层分配税码，故“税码”字段只能是“Location”；在多组织环境下，“销售人员”也只能在账户地点定义，故此字段留空；仅当税收方法为 VAT（增值税），且“AR系统选项”窗口中的“允许改写”选项设置为“是”时，才需要（也只有）在这里的“税码”与“税额舍入”字段输入值，不可以在地点层相关字段输入，并且Accont层输入值优先于“AR系统选项”层的输入值；“参考”字段是系统内部的客户账户唯一性标识（内码ID），可以手工输入，也可以由系统自动生成（使用“客户接口”批量导入时，系统也会自动产生），一旦保存后就不可更改。

4.1.9客户账户层的“市场营销”属性

“市场营销”属性只在客户账户层出现，主要是提供一些该客户账户有关财务数据的简单说明，如图 4‑92所示。

图 4‑92 客户账户的市场营销属性

图 4‑92中的“收入”区域，使用“本年度”和“下一年度”字段来估计此客户账户在本年度和下一年度的潜在收入；其余主要表示其所属会计年度的相关设置值。

4.1.10客户账户层的关系属性

客户账户层的“关系”不同于交易方的关系，交易方层的关系仅代表客户的独立的自然属性，如组织层次结构关系等，而客户账户层的关系只是基于当前与己方所具有“买卖关系”而产生的派生关系，如“代为收单、收货或互惠（关联）”等，如图 4‑93所示。

图 4‑93 客户账户的关系设置

客户账户“关系”属性只在账户层出现。图 4‑93中的关系“类型”字段仅供参考，其LOV值可以在Lookup Code中定义。

4.1.11客户账户地点层的“特性”属性

“特性”属性只在客户账户地点层出现，只是用来对客户账户地点提供某些说明信息。如图 4‑94所示。

图 4‑94 客户账户地点的特性属性

其中的“译名”（Translation ，“折算”翻译不恰当）表示使用其它语言输入的客户名称，可用来替换外部文档的客户名称，此字段可与“语言”字段一起使用。“参考”字段系统内部的客户账户地点唯一性标识（内码ID），可以手工输入，也可以由系统自动生成（使用“客户接口”批量导入时，系统也会自动产生），一旦保存后就不可更改。“Geo改写”及“城市内部限制”字段，仅在使用第三方税务软件Vertex Quantum（美国）时才用得到。

4.1.12客户账户与地点层的“通信”属性

客户账户层与账户地点层共有的分组属性，内容几乎完全相同，主要是提供电话、传真、电子邮件等信息。如图 4‑95所示。

图 4‑95 客户账户与地点层的通信属性

4.1.13客户账户与地点层的“联系人”属性

账户层与账户地点层共有的分组属性，内容几乎完全相同，主要是提供有关“联系人”名称、职务等等信息，如图 4‑96所示。

图 4‑96 客户账户与地点层联系人属性

4.1.14客户账户与地点层的“联系人：职责”属性

客户账户层与账户地点层共有的分组属性，内容几乎完全相同，主要是提供有关“联系人”职责的补充信息等，如图 4‑97所示。

图 4‑97 客户账户与地点层的“联系人：职责”属性

4.1.15客户账户与地点层的“银行账户”属性

账户层与账户地点层共有的分组属性，内容几乎完全相同，主要是提供有关“银行账户”的信息等。R11的银行账户只能在AR系统先定义好后，在这里作为LOV值被引用，而R12则可以同时新增银行账户，因而使用也更加方便。如图 4‑98所示。

图 4‑98 客户账户及地点层银行账户属性

4.1.16客户账户与地点层的“付款方法”属性

账户层与账户地点层共有的分组属性，内容几乎完全相同，主要是提供有关“付款方法”的信息等，其“付款方法名称”的LOV值是在AR系统定义后被引用的。如图 4‑99所示。

图 4‑99 客户账户与地点层的付款方法属性

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

账户层与账户地点层共有的分组属性，内容几乎完全相同，主要是提供对所引用的“客户配置文件分类”的某些字段值进行维护更新功能，其所包含的内容（加上“配置文件：单据打印与金额”Tab页）并不是所引用的“客户配置文件分类”的内容全部。这里所进行的更改（前提是必须先引用一个确定的“客户配置文件分类”），也不会影响其他引用该“客户配置文件分类”的客户的相关设置值。如图 4‑100所示。

图 4‑100 客户账户与地点层的“配置文件：事务处理”属性

4.1.18客户账户与地点层的“配置文件：单据打印”属性

账户层与账户地点层共有的分组属性，内容几乎完全相同，情况与上述“配置文件：事务处理”分组属性类似。如图 4‑101所示。

图 4‑101 客户账户与地点层“配置文件：单据打印”属性

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

账户层与账户地点层共有的分组属性，内容几乎完全相同，情况与上述“配置文件：事务处理”分组属性类似。如图 4‑102所示。

图 4‑102 客户账户与地点层“配置文件：金额”属性

4.1.20客户账户的“地址地点与业务目的”属性

每个客户账户Account可以有多个地址地点Site（编号），每个地址地点Site的真实物理地址Address可以相同。每个地点可以有若干个不同的“用途Usage”，每个用途有其对应的“地点Location”（编号）。每个地址地点Site的不同“用途”还可以有其“详细资料、账户、订单管理”的附加属性（具体内容取决于确定的“用途”），如图 4‑103所示。

图 4‑103 客户账户的“地址地点与业务目的”属性

图 4‑103 中的“用途”的LOV值是在AR系统的Lookup Code中定义的（访问级别“可扩展”），系统预置了“收单方Bill To”、“付款人Drawee”、“收货方Deliver To”、“收货方(1) Ship To”、“对账单Statement”、“催款Dunning”、“法定Legal”、“市场营销Marketing”、“购货方Sold To”、“发票 Invoice”、“提单Bills of Lading”、“信用联系人Credit Contact”、“贷项通知单Credit Memos”、“确认Acknowledgments”、“自助用户Self Service User”的常用类型的业务用途。

每个客户Account只能有一个“主要Primary”且“有效Active”的用途Location。并且，每个客户Account只能有一个有效的“对账单Statement”、“催款Dunning”用途Location。当用途为“收单方Bill To”时，可以为之在附加属性窗口“帐户”Tab页中输入“收入、应收”等账户代码（主要供AR的“自动会计”使用）。

当用途为“收货方(1) Ship To”时，可以为之选择一个“收单方Bill To”的Location。并且在附加属性窗口“详细资料”Tab页中输入“内部地点”、“销售人员”等。“内部地点”在定义“发运网络”、“在途时间”以及OM系统计划发运时间时必须存在。如图 4‑104所示。

图 4‑104 收货方（Ship to）的业务目的详细信息

图 4‑104中，每个“内部地点”只能被分配给唯一的“客户（地点）”，它还被用于将“内部组织”与“（内部）客户”自动链接。“内部订单”或“公司间事务流”功能使用相关业务表单中的“内部地点”，自动寻找并将“内部组织”与“内部客户”关联，以便生成内部订单或公司间发票。“税”区域，只有在“用途”为收单方Bill To，且“AR系统选项”窗口“税务”标签区域中的“允许改写”设置为“是”时，才可以在其中输入值。在此处输入的值将优先于在客户或AR系统选项层定义的值。

用途的附加属性Tab页“订单管理”的内容与客户账户层“订单管理”Tab页内容完全相同，如图 4‑105所示。

图 4‑105 收货方（Ship to）的订单管理详细信息

“订单管理”Tab页中输入的值主要用于为OM系统的销售订单提供默认值。在多组织环境下，其中的“订单类型”与“发运方法”字段，只能在客户账户地点层而非客户账户层输入。其中的“仓库”实际是指“库存组织”。

4.1.21R12客户的账户层与地点层属性

R12的账户层与账户地点层属性的内容及关系基本相同，区别仅在于账户地点层与确定的业务实体OU关联。如图 4‑106是R12的客户账户层Web界面。

图 4‑106 R12的客户账户层信息

R12的属性Tab页分组方式与R11略有区别，其中的“附件”Tab页在R11中位于工具栏的“附件”（也是仅在Account层才有，Site层无）。R12的Account Site层的属性Tab页内容也与Account层基本相似，但地点层多出一个专门的“税配置文件”按钮功能，可以打开为当前地点设置“税务信息”。如图 4‑107所示。注意，R12与R11相比，客户的税务信息设置有很大不同，详情请参考本书（下部）最后章节“EBS R12的全新系统设置及业务测试实例”的有关内容。

图 4‑107 R12的客户地点层信息

4.1.22客户数据的合并

包括交易方合并与客户账户合并两方面内容，如图 4‑108所示交易方合并操作界面，建立“合并批”，将需合并的交易方设置好后，先保存再“运行批”启动后台并发请求。

图 4‑108 交易方数据合并

客户账户合并的情况稍复杂（R12还增加了业务实体OU字段），如图 4‑109所示客户账户合并界面。“客户合并”功能可以合并相同客户账户的地点用途，也可以合并两个不同客户账户的所有地点用途。但不管要合并的是不同客户账户还是相同客户账户的两个地点，都只能将收单地点和收单地点合并，将收货地点和收货地点合并。

图 4‑109 客户账户数据的合并

在合并成功完成之后，以前与原有客户账户或地点关联的所有活动，此时将与新的客户账户或地点关联。这些活动包括订单、发票、借项通知单、承付款、贷项、收款、调整和拖欠款项等。在合并流程完成之后，合并的原有客户账户和地点用途将会处于“无效”状态。无效客户账户不能生成新的事务处理，但随时可以在“客户”窗口中查看其信息或将其重新激活。

4.1.23交易社区系统简介

基于TCA应用架构的“交易社区”系统模块，目前主要包括4个功能组成部分：一是客户数据创建与维护；二是交易社区管理；三是内容访问和集成；四是数据质量管理。就供应链业务的运作而言，目前实际工作中的应用主要是“客户数据创建与维护”，以及“数据质量管理”中的“交易方数据合并、客户账户数据合并”功能，而对于R12来说，则还需进一步使用到“交易社区管理”功能中的“分类”管理功能（用于税务设置）。

而所谓交易社区的“内容访问和集成”功能，则主要是指通过导入外部来源的“公司信息数据”（典型的是购买邓白氏公司的D&B 数据库），实现“交易方”数据自动生成与维护。该项功能的实际使用目前还不多见。

实际工作中，必不可少的“交易社区”功能应用是“客户数据的创建与维护”。R11系统客户数据的创建由于仍然是GUI界面，且无需使用到“交易社区管理”的相关功能，故实际应用可能并不会特别感受到“交易社区”系统功能的存在。而在R12系统中，如图 4‑110所示客户数据创建的Web方式，已经很明确地显示是在“交易社区”系统模块之中。

图 4‑110 R12交易社区的创建客户

EBS的核心业务模块OM/AR所使用到的有关客户数据内容只是交易方数据中的一部分，在TCA架构下，为了满足其他应用模块如CRM的需求，交易社区的“管理”功能，还提供了诸如“交易方关系、分类、安全性”管理等诸多应用功能。特别地，由于R12税务系统的特殊要求，需要使用到交易社区“管理”功能之中的“分类”功能。如图 4‑111所示。

图 4‑111 交易社区的管理功能

有关R12税务设置所需使用到的“交易方分类”设置问题，详情请参考本书（下部）最后章节“EBS R12全新系统设置及业务测试实例”中有关“税务设置”的内容，这里不再作详细说明。

4.2结语

物料、供应商、客户这三大系统“主数据”，不仅是本书后续各章将要讨论的供应链核心系统的“业务流程类单据”（如采购订单、销售订单等）的最主要数据来源，而且也是整个EBS系统相关业务功能最重要的数据基础。本书之所以在正式进入有关业务系统模块的业务流程与应用功能的讨论之前，首先将它们提取出来，进行集中的讨论与介绍，目的正是希望能为读者奠定后续各章内容的学习与认识的必要基础。

但是，“物料、供应商、客户”作为内容最广泛、结构最复杂、业务功能最强大的“数据来源类单据”，其全部的、详细的“字段属性”的内容讨论又非本章篇幅所能容纳。此外，主数据的相关字段属性内容通常又与具体的系统业务功能紧密相关，牵连甚广，孤立地进行解释、说明，往往也很难达到很好的学习效果。因此，本书后续各章在讨论有关业务系统的具体应用功能时，还会经常返回到有关“主数据”的内容中来，对特定业务功能所涉及的特定字段属性的设置进行补充讨论。

对于初学者来说，最重要的是通过本章内容的学习，能够基本领会主数据功能的系统设计逻辑，熟悉主数据能够为业务流程类表单提供哪些来源数据，懂得有关主数据内部的字段属性之间、不同主数据相互之间，以及主数据与其它数据来源类单据如“系统参数、配置文件”等之间有怎样的逻辑结构关系，并在以后涉及到具体的系统业务流程与应用功能时，能够准确地定位到相关的主数据字段属性，并进行适当的调整设置。

至于“物料、供应商、客户”数量庞大的每一个字段属性的具体设置与功能细节，并不要求在初始阶段就能做到完全掌握，全面精确，因为事实上每种主数据数量庞大的字段属性之中，必需设置的、常用的字段数量并不多，其余非必需的字段设置通常可以留空，仅当有特定业务功能需要时，才需要对之进行补充完善。必要时，可能需要查阅EBS有关官方文档的详细指南。读者在VIS DEMO系统进行物料、供应商、客户数据的创建、更新的练习测试时，也可参考本书（下部）最后章节“EBS R12全新系统设置及业务测试实例”中有关“主数据创建”的相关内容。

oracle

文章转载自杰夫之产业互联网，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。