《SAP CRM管理与实施指南》一一2.1　SAP CRM基础数据管理

本节书摘来自华章计算机《SAP CRM管理与实施指南》一书中的第2章，第2.1节,作者：邹荫文 著，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

2.1　SAP CRM基础数据管理

本节介绍SAP CRM的基础数据，包括业务合作伙伴、产品、组织结构、服务对象及知识库等。合作伙伴、产品、组织结构可以用于营销、销售及服务管理等模块中；对象、安装点、质保、计数器及知识库一般用于服务管理流程中。定价数据也是重要的基础数据，在2.2.3节中与定价的条件技术一起介绍。
2.1.1　SAP CRM业务合作伙伴管理
和企业的业务相关的任何单位、人员均统称为业务合作伙伴（Business Partner），比如正式的有交易往来的正式客户（也常称为交易客户），还未曾有过业务往来的但是将来可能成为正式客户的潜在客户，客户的联系人、竞争对手、供应商及企业员工等都属于业务合作伙伴。业务合作伙伴是一种重要的基础数据，被广泛应用于交易事务中，并且拥有一个或多个角色，承担不同功能，可以与其他业务合作伙伴或业务对象建立各种关系。对于复杂的合作伙伴可以建立层次结构关系。与业务合作伙伴的交互沟通是企业人员的重要工作，为了满足法律等要求，业务中需要遵守客户的选择，如客户是否愿意接受营销信息等，可以使用营销许可功能。还可以为客户定义各种属性，以便能精确地描述客户。下面简要介绍合作伙伴的一些基础功能，关于合作伙伴更多的功能可以参考4.2.2节。
2.1.1.1　业务合作伙伴的角色
角色（Roles）即该业务合作伙伴在各种业务中所承担的功能与作用，是从业务功能上对客户的一种分类。一个业务合作伙伴可以拥有一个或者多个角色，如一个业务合作伙伴同时拥有售达方和渠道合作伙伴的角色。不同角色可以有不同的信息内容，即可以根据角色设置使用和显示的客户信息块。常用的业务合作伙伴角色参见表2.1。

应用举例：
实际应用中，通常尽量使用标准的角色。也可以根据实际的业务需求定义其他角色，如：
员工通常分成企业内部员工和企业外部的合作伙伴的员工。CRM中提供了员工的角色，通过配置，可以新增外部员工角色。合作伙伴员工拥有这个角色，也可以使用合作伙伴联系人标准角色。
供应商可以分成第三方供应商、服务供应商，除了系统提供的标准的供应商角色外，可以定义第三方供应商和服务供应商的角色。
2.1.1.2　通过中间件进行客户数据分发
通过CRM中间件，客户数据可以在CRM和ERP中双向同步，详细请见11.2.1节“CRM与后台SAP ERP交换数据”。也可以使用XIF接口实现与外部系统的集成。数据复制时需要明确CRM客户数据的销售分类和ERP客户的账户组的映射关系（ERP事务代码：PIDE）。销售分类包括客户、消费者、潜在客户及竞争对手等。销售分类在CRM中由客户所拥有的角色的类别确定，角色类别是对角色的基本性质分类，通常Web UI客户页面中并不显示这些销售分类信息。角色类别和销售分类的映射参见表2.2。

CRM中的消费者可以是个人或组织，如果是组织类型的消费者，销售分类为客户，通常在ERP中使用售达方等客户类别的账户组；如果是个人类型的消费者，销售分类为消费者，在ERP中使用消费者账户组。如果一个客户同时拥有多个角色，系统按照消费者>客户>潜在客户>竞争对手的顺序确定销售分类，即传递到ERP时使用唯一的分类确定生成ERP客户所用的账户组。而ERP的账户组是ERP客户的基础分配，用于确定客户所用的编号范围、可用的属性以及其他业务控制功能。
合作伙伴相关的配置主要分成两个部分，一部分是合作伙伴跨模块的通用配置，路径为：配置>跨应用组件>SAP-商业伙伴，这里对分组、角色、关系等进行配置。第二部分为客户主数据相关的配置，路径为：配置>CRM>主数据>业务伙伴，设置属性、模板及客户层次结构等主数据相关的配置。
应用举例：
企业已使用SAP ERP，其中有客户数据、价格数据和销售订单管理功能。后来引入客户关系管理，管理营销、售前销售和服务管理流程。实际应用中，通常将ERP中已存在的正式客户直接复制到SAP CRM中。同时新的潜在客户在CRM中维护，升级为正式客户以后复制到SAP ERP中。
对于同时实施SAP CRM和ERP的客户，客户管理可以CRM系统为准，即CRM系统为前端系统。CRM中的潜在客户不复制到ERP系统中。潜在客户成为正式客户以后才复制到ERP系统中。如果正式客户需要预先在SAP MDM主数据管理系统中维护，通常是MDM向ERP同步数据，然后从ERP同步到CRM系统中。因为该客户在在成为正式客户之前可能已经在CRM中开展营销和售前业务，已成为潜在客户，在这种情况下，需要将来自ERP的正式客户和CRM中之前创建的潜在客户进行合并，保留ERP正式客户。
2.1.1.3　业务合作伙伴的关系管理
关系是业务合作伙伴中的重要功能，客户关系管理的本意是管理企业和客户的交互以及客户与客户之间的关系。业务合作伙伴关系即指两个业务合作伙伴之间的各种类型的业务联系，见图2.1“业务合作伙伴关系”（路径：销售专员业务角色>客户管理>客户明细>关系）。

图2.1　业务合作伙伴关系
关系举例：客户ABC有联系人张三，联系人张三即属于客户ABC的联系人；客户ABC有负责员工李四，李四是客户ABC的负责员工；某客户有多个送货方等。
关系有关系类别确定，关系类别确定关系的性质，控制关系的功能，如方向性和时
效性。
关系具有方向性，即单向关系和双向关系。联系人、负责员工、员工和企业的关系是单向关系，即如果企业A有员工B，B属于A的员工。不同方向的业务合作伙伴，通常具有不同的角色。而婚姻关系、兄弟关系是典型的双向关系，即如果A和B是婚姻关系，B和A也是婚姻关系，关系的两个方向具有相同的角色和性质、关系描述上，不同方向可以有不同的描述，如“有联系人”、“是某客户的联系人”等。关系具有时效性，即关系存在一段时间之内，可以指定关系的开始日期和结束日期，比如联系人关系，随着客户的员工辞职，这个联系人的关系即终止，即可以设置关系的有效期。
关系有各种属性，通过指定关系的属性，可以进一步描述关系的作用等，也可以避免数据重复。比如联系人所在公司的岗位、部门、地址、电话、手机等联系方式信息。合作伙伴关系中可以指定在某个销售范围中的合作伙伴功能，例如指定某合作伙伴在特定销售范围下的送达方功能。关系和关系中的合作伙伴功能可以用于合作伙伴确定处理中。常见的合作伙伴关系参见表2.3。

应用举例：
实际应用中，尽量使用系统提供的标准关系，当然也可以根据实际的业务需求定义各种关系，例如：
备件供应商：服务站的备件由关联备件供应商提供，服务站和供应商之间可以使用备件供应商关系。
店铺关系：某公司有多个业务合作伙伴公司客户，这些客户各拥有多个店铺，在店铺中销售相关产品。合作伙伴和店铺的关系及可以使用店铺关系。
2.1.1.4　业务合作伙伴的层次结构
大客户往往有复杂的组织层次结构（Account Hierarchies）。业务合作伙伴层次结构（即客户层次结构）用于映射复杂客户的层次结构关系。例如，有些客户按照总部、区域分成多个组织单位；有些客户在多个区域中有诸多终端门店；有些业务上也会把具有相同属性的客户组织在一起，以便进行定价、统计与管理。层次结构为树状结构，业务合作伙伴分配到层次结构节点上。
典型的客户层次结构示例见

图2.2“客户层次结构逻辑关系说明”。客户层次结构的主要目的有两个：
统计分析：可以根据层次结构对客户进行分析。比如可以统计客户在华南区和华北区的销量。
定价：比如华南区促销，给华南区的所有客户都设置5%的折扣。或者设置一定的优惠。可以把定价的数据设置在某个节点上，该节点及下级节点的客户均享受相同的折扣与价格。
SAP CRM中，客户层次结构见图2.3“业务合作伙伴层次结构”（路径：销售专员业务角色>客户管理>客户层次结构），图中列出了示例的客户层次结构，可以建立多层的树型结构，然后为层次结构节点分配具体客户。与ERP不同，CRM中的层次节点不能为客户本身，而ERP中客户本身即可作为层次结构节点。层次节点以及层次节点的客户分配均可以设定有效期。ERP中的客户层次结构可以通过中间件复制到CRM中。CRM中创建的客户层次结构与销售范围无关。创建层次结构时需要所用的层次结构分类。可以定义层次结构，用于确定层次结构的用途，例如01用于定价类层次结构。可以确保一个客户只分配到一个层次节点上。渠道合作伙伴管理中通常使用PH类别。在网络渠道应用中，通常一个客户可以为自己及层次结构中的下级客户递交销售订单、报价单、投诉和退货等事务。

图2.3　业务合作伙伴层次结构
2.1.1.5　营销许可
随着营销的渗透，营销信息无处不在，对一些用户带来了负担和不便。因此有些国家和地区制定了相关的法律和法规，禁止未经客户授权即向客户发送营销信息，如果用户明确不愿意接受信息，企业即不可以向该客户发送信息。营销许可（Marketing Permission）即用于遵守当地的各种法律和法规。启用营销许可功能后，只有客户明确授权允许接收的信息和方式，才可以发送给客户。系统会记录客户是否愿意接收营销信息，并且指定具体的接收渠道。客户对接收设置的更改和历史均会记录到系统中，供可能法律审查使用，比如客户之前允许接收，经过一段时间后不愿意再次接收。可以使用系统的规则或者BADI增强设置营销许可的规则。
营销许可是SAP CRM 7.0 EHP2增强包中开始提供的功能，客户概要中可以设置营销许可信息，记录通信渠道、客户授权方式、授权时间及通信渠道，显示当前的授权以及历次的授权。营销许可设置后不能更改，可以新建或者删除，系统会保存设置的历史。系统可以对客户数据中的每个电话、邮件等通信渠道明细分别设置营销许可。客户搜索中可以使用营销许可相关的搜索条件，如通信渠道及授权情况（允许发送营销信息、不允许或未设置）。外部清单管理、交互中心以及营销活动执行中均可以考虑营销许可功能。在一定的条件下，设置的营销许可为无效，如同意授权日期在将来、通信信息被更改或者删除、通信明细已无效、许可已经过期、同意渠道有更新的许可信**息等。有效和无效的营销许可设置都会显示在“所有营销许可”页面中。
2.1.1.6　其他业务合作伙伴属性和功能**
业务合作伙伴具有丰富的预定义属性和各种功能，例如客户分类、营销属性、销售范围数据等，详细请参考4.2.2.2节“客户信息概要”。
技术指南：
标准系统中，客户的基本数据（名称、搜索项等基本字段）与地址字段（国家、地区、城市、街道及邮编等地址字段）保存在不同的数据表（如BUT000/BUT020/ADRC）中，通过地址关系进行关联，因此在客户数据非常多时，部分条件组合的客户搜索会比较慢。SAP CRM 7.0增强包2中对此进行了增强，将客户基本数据和常用的地址数据放在一个数据表（BUTADRSEARCH）中，以便提升搜索性能。自定义字段也可以拓充到快速搜索表中，提升客户搜索的性能。启用该功能需要激活业务功能（CRM_PERFORMANCE_2），然后执行报表BPADRSEARCH_FILL填充数据。激活该功能后的客户数据编辑和保存，会自动更新相关数据到此数据表中。详见SAP注释595442。
业务增强BADI PARTNER_UPDATE是客户数据更新的常用增强BADI，例如客户数据更新或创建后触发的ACE权限数据更新即使用了这个BADI，实施为PARTNER_ACE_UPDATE。关于客户数据的ACE权限管理请参考11.3.3节“动态权限管理，访问控制引擎ACE”。
可以为组织模型中的组织单元生成合作伙伴数据，这些合作伙伴拥有组织单元的角色。可以在CRM中直接创建员工角色的合作伙伴或者从ERP HCM系统中复制员工数据。员工和组织结构之间通过属于某组织员工的关系实现，为组织单元的岗位分配员工后，即建立该关系。如果使用SAP ERP HCM系统，可以将HCM系统中的员工数据复制到CRM系统中，请参考11.2.1节“CRM与后台SAP ERP交换数据”。
2.1.2　SAP CRM产品管理
产品是企业为客户提供的各种物品与服务。产品可以是有形的物品，比如电脑、汽车、电梯及椅子等；产品也可以是无形的，比如各种服务，咨询服务、技术服务、投资服务及维护服务等。本节首先介绍了产品的基本功能，然后介绍了两种特殊类型的产品，即服务产品和质保，主要用于服务管理模块中，最后介绍了产品相关的一些功能如产品包、产品列表与排除和客户产品范围等。
2.1.2.1　产品基本功能
产品信息包括对产品的描述信息、分类信息以及起流程控制作用的控制信息。基本描述信息有产品编号、产品名称、尺寸大小、规格、净重、毛重及颜色、价格及税信息、分销相关信息等。常见分类和控制信息如产品分类、产品组、产品类型、项目类别组及税分类等。产品主数据被广泛应用到CRM各模块流程中，如营销、销售、服务及渠道管理等。网络渠道产品目录中使用的产品也来自产品主数据。
1.?产品类型
SAP CRM系统中，将产品分成物料（Material）、服务（Service）、质保（Warranty）、融资（Financing）、金融服务（Financial Service）及知识产权（Intellectual Property），共六种。
物料：一般指有形的物品，等同于SAP ERP中的物料主数据。比如电脑、汽车、螺丝等。
服务：企业提供的各种无形的服务，比如咨询服务、技术服务、维护服务等。服务产品中可以设置与服务相关的参数，如可提供服务的时间、服务响应时间等。
质保：一般指有形物品的质量保证，比如主要部件提供一年的质保，车辆提供两年或六万公里内的质保。质保期内，通常可以免费提供规定的质保维修和服务。质保期之外，相应的维护和服务需要付费。
融资与金融服务：融资产品与金融服务是一种特殊的产品，用于CRM的金融服务（行业）模块，比如CRM租赁中。
知识产权：知识产权也是一种产品，用于媒体、高科技等行业的知识产权管理，知识产品可以进行授权使用，根据授权收取费用，获取收入。
2.?产品层次结构
产品层次结构（Product Hierarchy）由多层产品类别（Category）组成的树状结构。可以根据企业的实际业务需求定义多层类别。可以为产品分配一个或多个产品类别，即对产品进行层次型的分类管理，用于控制和产品信息分类。
见图2.4“产品层次结构”（路径：销售专员业务角色>销售运行>产品层次结构），Web UI中可以维护产品层次结构。产品属性集分配到对应的产品类别上，下级层次的产品类别继承上层产品类别的产品类型和属性集。创建产品时指定产品的基本类别，基本类别确定产品类型和属性集。产品层次类别可以用于确定定价条件，例如将某类产品统一设定折扣。在一些产品数量众多的业务中，使用产品层次类别进行定价可以降低价格数据的维护工作量。
应用举例：
比如某石油油品企业中，可以分为高级柴油类润滑油、高级汽油类润滑油、润滑脂、船用油等大类，然后在大类下面设置相应的小分类，形成层次结构。
某汽车企业根据汽车的品牌与型号等设定层次结构，例如，B系列、C系列、E系列等，每个系列可以根据型号进一步细分。
某高科技行业按照产品品牌对产品分成T系列和I系列，每个系列内部又进一步细分，形成多层的层次结构。
技术指南：
ERP中的物料类型、物料组、产品层次结构都可以通过中间件复制到CRM中，CRM中以产品层次结构的形式保存和使用，分别为R3PRODSTYP、R3MATCLASS和R3PRODHIER，其中物料类型R3PRODSTYP为物料的基础层次结构。而服务、质保等其他产品类型，通常需要新建一个专用的基础产品层次结构或使用R3PRODSTYP。在从ERP中复制物料的系统配置信息之前，通常不能为物料分配基础层次结构，复制ERP物料配置信息后，系统自动将基础类别设置为R3PRODSTYP。
层次类别中可以指定一些属性，如所产品类型（物料、服务或质保等）、权限组、对象家族、合作伙伴确定过程以及关系类型等，下层类别从上层类别继承这些属性。一个属性集可以分配给一个产品层次结构中的多个产品类别，但只能分配给一个同产品类型的层次结构。一个产品可以分配多个产品类别，这些产品类别必须属于不同的产品层次结构。即在一个层次结构中，只能分配唯一个类别到产品中。创建产品时需要指定一个基础类别（Base Category），基础类别确定产品类型。事务代码COMM_HIERARCHY可以定义产品层次结构，在菜单环境>应用程序的分配层次结构中可以为每种产品类型指定一个产品层次结构为基础层次结构。
产品层次结构类别可以用于确定定价。需要设定定价相关的层次类别，以及所用的层次类别数量。复制于ERP的产品层次结构R3PRODHIER可以用于定价，相关的定价条件如0PH1和0PH2。产品层次结构定价相关配置详见：配置>CRM>主数据>产品>产品类别>定价。同时在定价配置中需要维护维护定价过程（包括使用的字段、层次结构、定价表、存取过程、定价条件、定价条件组等）。
3.?产品属性集与属性
不同企业和行业的产品有不同的属性，SAP CRM中可以灵活自定义产品的各种属性，用于描述或分类产品。自定义产品属性有日期、文本、数值等各种类型。一个或者多个属性组成属性集。属性集对应数据库表。维护属性集时系统自动生成数据表以及相关函数。将属性集分配到产品层次结构层次节点中，这些层次节点及以下节点的产品即可使用该属性集中的属性。系统提供诸多标准的产品属性，用于物料、服务、质保及金融服务产品中，见

图2.5“产品属性”（路径：销售专员业务角色>销售运行>产品明细）。定义属性时可以指定属性是否可以多重使用，某个属性是否可以选择多个值，属性是否和组织数据相关等。定义属性时，指定属性的类型、长度，可以设置属性值范围或者选择属性值数据表格。
技术指南：
定义产品属性集（事务代码：COMM_ATTRSET）后，需分配到产品层次类别中（事务代码：COMM_HIERARCHY）；需生成属性集的Web UI配置（事务代码：CRMM_UIU_PROD_CONFIG）；需将属性集分配到相关组件页面中（事务代码：CRMM_UIU_PROD_GEN），如产品概要页面、个体对象概要页面。完成这三步后，才能在Web UI页面配置工具中将属性集显示出来。创建属性集Web UI页面和为产品等组件概要页面分配属性集均需要增强相关的Web UI组件，需使用增强集。自定义的产品属性可用于产品高级搜索中，但需要拓展产品搜索的结构、使用产品搜索BADI实现搜索功能，详见SAP注释1026956。通过增强，也可以将自定义属性集中的属性放置到产品抬头明细表单中，以便能够更方便的维护数据，详细实现方式请参考SAP CRM帮助文档。维护集类型和属性的事务代码COMM_ATTRSET中，选择属性集，可以将属性集包含到传输请求中，用于传输到其他系统中。
模板：可以定义迷你数据模板（Mini Template），预先填充相关数据，简化产品属性集数据的维护。使用模板功能的属性集需要标识为“允许模板”。
与BW系统集成：系统提供相关数据源，可以将CRM的产品数据复制到BW中。维护属性集时标识为“BW相关”。
产品的属性通过属性集组织和维护，主要的属性集包括产品的基本数据、产品的销售数据、物料数据和其他信息。
系统提供标准的产品基本属性，对产品进行描述和控制，基本的属性集参见

产品的其他信息包括产品的关系和状态，也是重要的信息。产品与产品、产品与客户可以建立各种关系。比如设定一个产品的相关联的产品、关联的服务及备件等。状态用来表示当前的处理情况以及确定后续允许操作的事务。状态分成系统状态和用户状态。系统状态由系统提供，用来控制和规范各种处理。产品的系统状态主要有：待归档、已锁定（可以使用）；已删除、已归档和可以归档由系统操作设定。用于状态由用户根据实际的业务需求自行定义，可以定义一系列的用户状态。
4.?结构化产品
结构化产品（Structured Product）含有一个抬头产品和一个或者多个组件产品，这样形成两层的产品关系（产品关系类型为“组件”）。抬头产品和组件产品都需要预先维护好。一个抬头产品下面不能再包含另外一个抬头产品，即结构化产品仅支持两层结构。使用结构化产品，可以把某些具有组件的产品组织起来。比如一台电脑由机箱、电源、主板、中央处理器、硬盘、内存、键盘及鼠标等组成，电脑可以设置为一个结构化产品，抬头产品电脑即包含这些组件产品。这些组件也可以单独销售和服务。通过结构化产品，也可以形成一种虚拟产品，其中包含了具体的产品，这样对于临时组合使用，可用于统计及控制用途，即构造虚拟的“产品包”。
技术指南：
如果抬头物料是从ERP复制过来的物料，CRM中不能为其创建结构化产品组件，该结构化物料需要在ERP中维护，CRM中能够查看该类结构化产品组件，但不能编辑。CRM中创建的物料可以作为头物料，并且添加组件。ERP中的销售BOM可以复制到CRM中形成结构化产品（复制对象为BOM），而普通的物料清单以“服务备件-ERP”的关系关联（复制对象为BOM_ERP）。
部分业务流程中不能使用结构化产品，如产品目录中不会显示结构化产品组件信息。系统不支持多层结构化产品。
5.?可配置产品
可配置产品（Configurable Product）是指客户在选购产品时，可以选择相应的配置。比如配置一台计算机，可以选择不同容量的内存、硬盘，可以选择所安装的操作系统和相关备件；对于一些可以根据客户要求定制生产的汽车，用户可以指定车辆的颜色和各种配置，选择以后，厂家根据选中的配置进行生产，根据客户的订单定制。可配置产品常应用于机械工程、高科技电子等行业中。
SAP CRM支持可配置产品，可以在产品维护页面中启动基于Web UI的配置建模应用，维护配置相关的设置，如依赖关系、类、属性、属性值及产品结构，见图2.6“产品模型”（路径：销售专员业务角色>销售运行>产品）。模型是产品配置数据的容器。配置中所用的组件产品均包含到配置模型的产品结构中，然后可以指定使用该组件的规则和条件。组件产品本身也可以是可配置产品，具有自有的产品结构。通过建立依赖关系，可以检查用户所选择的属性组合是否有效，即排除一些不可用的组合；根据选择确定变式条件码，进而影响定价；确定属性值；通过隐藏、显示、设置为必填、只读等，引导客户交互选择配置；定义选择组件的条件。

图2.6　产品模型
可以测试建立的产品模型，激活或取消激活产品模型。可以导出配置模型为配置知识库，然后导入到其他系统中。产品模型建立后，即可以在销售订单、服务订单等事物处理中使用。通过变式条件码可以将产品的配置信息用于定价中，不同的配置，可以确定不同的价格。
对于集成和使用SAP ERP系统的用户来说，通常将ERP中维护的可配置物料复制到CRM，供CRM使用。这样在维护销售订单时，就可以选择物料配置，销售订单复制到ERP后，ERP中该销售订单也有相同的配置。
技术指南：
需要安装和启用CRM JAVA方能使用可配置产品功能，即使用IPC Java应用配置产品和确定价格。
产品模型中可以为添加组件产品，组件产品可以是可配置产品或非可配置产品，通过规则确定组件的选择情况。可以为组件产品创建配置类（Classes）和子类。可以为产品、组件、类和子类定义配置属性（Characteristics），支持字符、数字及日期等多种属性类型。属性可以参考其他数据表字段，即参考属性。可以为产品或类创建变式条件，变式条件码可用于定价，例如根据用户所选择的颜色确定价格。标准的定价条件0VA0即使用了变式条件。
产品模型中可以维护依赖关系，保存成关系表或自定义函数。依赖关系可以定义为公式、表、函数以及组件选择的函数。可以使用依赖关系确定属性和组件。定义依赖关系后，可以执行语法检查。
ERP中使用事务代码CT04定义属性，使用CL02创建类，使用CU41为物料创建配置参数文件，然后在物料维护中将配置类分配给可配置物料。物料的配置信息必须封装成配置知识库才能被CRM使用。因此需要使用CU31事务代码创建配置知识库，用CU34事务代码创建运行版本。然后在CRM中将配置相关的对象如ATTRIBUTE、CLASS、DNL_CUST_SCE、SCE下载到CRM系统（事务代码：R3AS）中，即可在CRM中使用ERP中维护的可配置物料。
6.?产品的数据交换（CRM与ERP）
使用SAP ERP的客户，建议直接将SAP ERP中的物料、服务主数据通过CRM中间件复制到CRM系统中（事务代码R3AS）。SAP CRM中维护的产品数据（包括物料和服务产品）也可以通过上传的方式上传到SAP ERP系统中，以便在两个系统中均可以使用相同的物料，但需要在ERP中拓展工厂、采购及财务等其他视图。
产品及产品相关数据的同步与复制请参考11.2.1节“CRM与后台SAP ERP交换数据”。ERP向CRM复制物料数据前需要复制物料的配置信息，主要有的对象有DNL_CUST_PROD0（物料编码存储格式），DNL_CUST_PROD1（物料类型、物料组和产品层次结构）及DNL_CUST_PROD3（状态）。配置信息复制后，可以复制物料主数据，对象为MATERIAL。如果需要从ERP中复制服务产品数据，需要复制配置对象DNL_CUST_SRVMAS，然后通过对象SERVICE_MASTER复制服务产品数据。
ERP中的物料的销售物料清单（Sales BOM）可以复制到CRM，作为结构化产品管理，复制对象为BOM。此复制有限制条件，如只能使用单层BOM，只有某个特定的工厂的BOM数据会被下载，销售BOM下载到CRM作为结构化产品后组件中只有组件的物料编号和数量，没有其他信息。销售BOM的结构化产品复制可以参考SAP注释1156808。
如果需要将物料清单（BOM）、设备和功能位置复制到CRM中，复制对象为BOM_ERP。CRM中通过产品的关系（服务备件-ERP）实现，可以在CRM产品主数据中的服务备件-ERP信息块中查看，这些组件可以用于产品推荐中。物料复制到CRM中为产品，设备和功能位置为CRM中的对象。BOM的复制也有一些限制，只能复制某个工厂的BOM等。
通过事务代码SDIMA（数据质量管理）可以检查系统之间的产品数据是否一致，可以比较和更正产品数据。更多的关于产品的数据质量管理，可以参考SAP注释642767。
2.1.2.2　服务产品
服务是一种类型的产品，具有服务的专用属性并用于服务流程中，如工作持续时间、资源需求、服务计划间隔模板、服务参数文件和响应参数文件等。服务产品用于各种服务流程中，如在服务合同、服务订单中确定响应时间和可用时间；在服务资源计划中，指定每个单位的服务时间以及如何确定服务组织等。服务产品的主要属性集参见表2.7。

1.?持续时间与资源需求
服务产品一般会指定执行一个服务单位的持续时间。服务计划时需要考虑服务的工作持续时间。
见图2.7“服务产品：持续时间与资源需求”（路径：服务专员业务角色>客户&产品>服务），服务的基本单位为AU，即为作业单位，一个作业单位的工作持续时间为2个小时。在服务订单中，如果需求是2个单位，则需要4个小时才能完成该服务。在资源需求中的对象标识中，可以指定确定服务资源的方式，即如何确定在合适的时间执行服务的服务组织与团队。
2.?服务合同缺省值：服务参数文件以及响应参数文件
服务产品中可以设置服务参数文件以及响应参数文件，确定可用的服务时间以及对服请求的响应速度，即服务级别协议（SLA），
见图2.8“服务产品：服务参数文件及响应参数文件”（路径：服务专员业务角色>客户&产品>服务）。服务处理（服务合同及服务订单等）时，服务产品中的服务级别协议会默认填充到服务事务行项目中。服务参数文件用来表明哪些时间可以提供此服务，如周一到周五工作时间处理，周六周日不处理，或从周一到周六均可以处理，可以定义每天的工作时间。而响应参数文件用来指定接收到客户的服务请求后，在多少时间内需要响应及完成，比如4个小时响应、8个小时响应或立即响应等，可根据服务请求的优先级、问题类别等确定响应时间。
见图2.9“服务参数文件定义”（事务代码：CRMD_SERV_SLA），可以定义多个服务参数文件，可以根据企业提供服务的实际情况灵活确定，比如定义7×24小时，5×8小时的服务参数文件。在右边的时钟按钮中可以定义详细的时间段。
见图2.10“设置服务参数文件规则”（事务代码：CRMD_SERV_SLA），可以对每一个服务参数文件设定具体的时间规则，比如可以根据每周设定，每一天均可以指定哪些时间可以提供服务，可以设置是否排除非工作日等。
而服务响应参数文件中，可以根据服务类别、优先级以及问题分类等确定响应时间。见
图2.11“响应参数文件：标识符”（事务代码：CRMD_SERV_SLA>响应参数文件），标识符中选择基准指标，如类别、优先级或故障代码的主题分类。比如这里按照优先级定义，因此可以为每一个优先级设置响应时间。创建服务请求或订单等事务时，指定类别、优先级及故障代码等分类。
　
　　　
　图2.10　设置服务参数文件规则　　　　　　　　　 图2.11　响应参数文件：标识符

见图2.12“响应参数文件：响应次数”（事务代码：CRMD_SERV_SLA>响应参数文件>响应次数），为优先级3设定了具体的响应参数，比如设置SRV_RF_DURA即首次响应时间为6个小时，SRV_RR_DURA处理完毕时间为6天。即接收到客户的服务请求时，系统将首次响应时间设置为服务请求时间+6个小时，将预计服务处理结束时间设置为服务请求时间+6天。服务处理时，系统会自动根据规则计算相关时间类型的
数值。
2.1.2.3　质保
质保（Warranty，也称担保）是一种产品主数据，用来管理企业所提供的产品或者服务的质量保证和承诺，承诺在一定的期限和条件下，所提供的产品或者服务发生问题时可以根据一定的条件维修或更换（如免费维修和更换）。质保期范围内，客户通常无需为维修和更换付费。日常业务中，所购买的产品多包含质保清单和说明，质保清单中规定了质保期限和范围，以及免责条款。通常规定在一定的使用条件下，所质保的时间长度或使用次数等，以及质保的部件范围。质保期内的相关维修一般免费，如果出现质量问题，甚至可以免费更换或退货等。质保的计算方式可以是基于时间、基于某计数器或者同时基于时间或计数器。最常见的质保是我国规定的零售商业企业的质量三包法，规定销售后，在一定期限内，卖家或厂商负责“包修、包换及包退”，属于一种商品信用保证办法。如果在质保期发现问题，客户可以进行申索，获取免费维修、更换甚至退货。对于因用户使用、保管不当等不属于产品质量问题通常并不在三包范围之内。
应用举例：
基础质保：对企业所提供的产品提供一年的基础质保，规定在质保范围内，可以免费更换和维修。但规定某些易耗件不在质保范围内，或者易耗件的质保时间较短，例如两个月。多数的电子类产品（计算机、相机、家用电器等）均为一年基础质保。
升级质保（2年）：客户在购买产品时，可以选择为期两年的升级质保，比普通的基础质保长一年，通常客户需要额外支付一些费用。按时间和里程的质保：某汽车生产企业提供的汽车为两年或者六万公里质保，即两年内或者行驶六万公里，先到为准。这种质保和某个计数相关。
1.?质保基本属性
质保产品的主要属性集参见表2.8。

质保类型：质保分成客户质保和供应商质保。
见图2.13“质保（1）”（路径：服务专员业务角色>客户&产品>担保），为一年基础质保，类型中可以选择供应商担保或者客户担保。供应商担保，即销售该产品的企业仅是销售商，最终质保由该产品的供应商为客户提供质量保证。发生质保问题后，可由销售商向供应商索赔。客户质保，即销售货物的企业对所销售的产品直接提供质量保证。在供应商质保索赔业务处理中，系统可以为带有效的供应商质保的产品产生供应商质保索赔申请，该申请传输到供应商中，供应商审核该索赔，详见5.2.7节“质保与索赔管理”。
质保基础：即定义质保的计数分类，可选择时间相关、计数器相关或者时间与计数器相关。如果质保仅与时间相关，即为时间相关。如果质保与设备的运行次数、小时、公里数等计数相关，可以选择计数器相关，然后根据计数器读数确定是否在质保期内；通过选择时间和计数器相关即时间与计数器共同决定质保期，如两年或六万公里整车质保。
质保的时间有效期和日期计算规则：质保在多少时间内有效及如何计算质保的开始和结束日期，比如定义设备安装日起一年内质保。可以使用日期规则灵活计算质保的有效期，比如是开始日期加上质保期，系统计算出质保结束日期。
会计标识：通过会计标识，质保可以参与并影响定价及影响成本分配。例如设置为基础质保100%免费，某些质保折扣为50%，质保外折扣为零即需要100%收费等。
服务限制：
见图2.14“质保（2）”（路径同上图）规定质保范围和规则，规定质保所覆盖的服务、服务备件及条件。担保服务类型可以选择具体的（服务）产品、产品组，或者指定项目类别（订单的行项目类别，例如投诉、服务、维修等）或者项目对象类型。同时可以设定是包含或者排除，即包含这个服务或者排除这个服务。
代码限制：确定质保范围，例如哪些损坏在质保范围内，哪些损坏不在质保范围内，通常人为损坏不在质保范围内。在进行维修服务时指定此次维修的具体原因代码，然后核对单据所关联的质保数据，检查该原因代码是否在质保范围之内。见图2.14“质保（2）”，目录中可以选择系统中定义的原因、故障目录树，然后选择具体代码组中的具体代码。模式中可以选择排除或包含。注意这里只能同时选择排除或者包含模式，即如果使用排除，此表格中所有代码都为排除，如果选择包含关系，此表格所有代码都为包含。
计数器：对于与计数器相关的质保，可以设置计数器读数及质保读数。见图2.14“质保（2）”设置复印机质保为5000份复印件，对于汽车，可以设置质保为6万公里。
质保附件：质保中指定使用的各种附件，如文本、表格、图形及链接等。
2.?质保的分配
质保可以分配给产品主数据：用户购买产品后注册该产品，获取产品的个体对象编号，该对象参考产品主数据而创建，产品主数据中的质保信息会被传递到对象中。对于一些日常消费品，当无法对每个客户购买的产品设置对象时，可以在产品主数据中关联质保信息。
质保可以分配到对象中：可以定义根据用户所购买的产品的安装日期或者交付日期开始计算质保开始日期。
质保可以分配给安装点的组件：质保可以分配给安装点的任何组件，可以根据规则或者手工分配质保的开始日期。
3.?质保的确定
服务订单、维修订单和投诉处理中，系统自动确定并分配质保，确定会计标识，进而影响定价，如质保期内免费服务，质保期外的服务需要付费等。质保确定的主要步骤为：
自动检查和验证质保情况：系统根据事务中所参考的对象（如所维修的机器），确定是否存在有效的客户质保（供应商质保用于质保索赔流程中）。
系统会检查相关质保的主数据，检查质保主数据中所包含或排除的服务限制和代码限制，以便确定事务中的服务和备件是否在质保范围内。
如果存在满足条件的质保，如果有多个有效质保分配给参考对象，系统自动分配第一个质保，用户可以在质保确定中选择任意满足条件的质保。质保分配后，相关的质保信息即保存在该事务中。如果用户选择“固定分配”，则参考对象等条件变化后，已经分配的质保不会被再次改变。分配的质保确定会计标识，而会计标识影响定价，因此能确定服务和备件是否需要收取费用。比如可配置会计标识，选项为A（质保外）和B（质保内）。然后设置价格主数据条件，当标识为A时没有折扣，即客户需支付服务费用；标识为B时，折扣为100%，即客户无需支付服务费用。
质保的成本分配：可以使用规则，将质保发生的费用分配到对应的成本对象中。
技术指南：
质保确定中，需要定义担保检查的参数文件（配置>CRM>交易>服务交易的设置>定义担保检查的参数文件）。该参数文件中确定质保的检查范围（供应商质保或客户质保）、质保检查的参考日期类型（如接收到客户服务请求的时间、服务请求开始时间等），可以设置服务释放或结束后，固定已经分配的质保。对于投诉，可以指定质保确定顺序，即从投诉的参考对象或投诉行项目产品中获取关联的质保及顺序。定义检查参数文件后，在事务类型的配置的服务处理类别视图中，指定该事务类型所用的质保检查参数文件。
服务确认完成后可以自动为服务的参考对象创建质保并将安装日期设置为质保开始日期。请参考5.2.3.3节“服务确认”。
2.1.2.4　销售产品包
把不同的产品打包销售，形成销售产品包（Sales Package）。产品包可以包含一个或者多个产品，可以是有形的物料产品，也可以是无形的服务等产品。为客户提供整体的解决方案，满足客户的特定需求。产品包中的产品销售通常具有更为优惠的价格条件。产品包广泛应用于服务模块的产品包报价单、提供商订单（Provider Orders）和提供商合同中。电信行业中，可以使用产品包构建各种通信套餐，套餐中需要制定资费计划，CRM中称为资费计划和产品包。通过业务规则，确定具体的产品，实现物料的分组、配置选择、定价，可以实现交叉销售和向上销售。
应用举例：
一个固定电话号码、光纤宽带硬件设备，以及一年的光纤宽带服务。
一台计算机和三年的质保服务。电厂设备一套及一年的免费现场服务20天。
销售产品包可以包含的主要组件类型参见表2.9。

使用业务规则，可以随时根据规则确定产品包中可以使用的组件，以及确定不同的价格。销售产品包中的不同子行项目可以由后续不同类型的事务实现相关功能。例如：激励产品和使能产品通常是一次性产品，后续直接通过销售订单发货；安装服务通过服务订单执行；定期的维护服务通过服务合同或服务计划执行；核心产品通过销售发货提供，而资费计划可以通过合同提供服务。
2.1.2.5　产品列表与排除
产品列表（Listings）和排除（Exclusion）是一种获取产品的约束，即对特定的客户在特定的时间在特定的业务场景中允许或不允许获取该产品。例如某个客户在特定时间不能购买特定产品，其他产品都可以购买，即无法购买产品排除清单中的产品，可以购买产品列表中的产品。产品列表和排除功能特点有：
和特定客户相关：只有设定的客户才会受到产品列表和产品排除的购买约束。
时间相关：设定的购买约束只有在特定的时间范围内有效。
业务相关：设定的购买约束只能在特定的场景中使用，即不是在所有能够使用产品的流程中系统均会检查产品约束。
1.?产品列表的结构

见图2.15“产品列表”（路径：销售专员业务角色>销售运行>产品列表），产品列表由抬头和行项目两部分组成。抬头中指定清单编号、名称、条件类型（列表或排除）、客户、状态和有效期。产品列表的行项目包含具体的产品。行项目可以是具体产品、产品类别、产品层次结构、产品目录或者其他用户定义的产品信息。在技术实现上，抬头是一种客户相关的条件记录，而行项目即为客户/产品范围（PPR），包含产品清单信息。因此行项目的维护可以参考2.1.2.6节“客户产品范围管理”。

图2.15　产品列表
2.?产品列表的维护
Web UI中可以维护产品列表，编辑产品行项目，设置产品行项目的属性，同时提供搜索、过滤以及打印等功能。在贸易促进管理中，可以使用CSV数据文件，整理产品列表数据，然后使用后台作业导入到系统中，自动生成产品列表（路径：TPM业务角色>主数据>创建作业>上载产品列表）。系统还提供按客户层次结构和产品层次结构管理产品列表的功能，即在客户层次结构或产品层次结构节点上能够查看或维护关联的产品列表。
3.?产品列表的检查
事务处理中可以进行产品列表检查，检查是否可以使用指定的产品。产品列表检查的主要业务场景有：销售订单中检查、投诉与退货中检查、贸易促进管理中检查、客户计划中检查，以及在活动日志中可以使用产品列表推荐产品。
在销售事务中，系统根据客户、销售组织等数据确定有效的产品列表。如果没有找到该客户的产品列表或产品排除清单，那么该客户可以购买该产品，即可以购买所有产品。如果系统找到该客户的产品列表，系统检查所所订购的产品是否在产品列表中，如果在产品列表中，即可销售，否则即不可以销售。如果所订购的产品包含在产品排除列表中，该客户即不能购买此产品。如果产品同时出现在产品列表和产品排除列表中，产品排除具有优先权，即该客户无法购买此产品。
2.1.2.6　客户产品范围管理
客户产品范围（Partner Product Range，PPR）为在一段时间内、对特定的业务应用所定义的客户和产品组合。通过PPR能够为客户提供适当的、相关的产品，客户只能购买在指定清单范围内的产品。这是一种客户与产品的组织和限制方式，比产品清单更为灵活。一些业务场景中，可以使用产品列表替代客户产品范围功能，如销售订单及贸易促进中的产品检查。客户产品范围中的客户可以是客户、客户层次结构、营销目标组分段及PPR客户等。产品也可以是产品、产品类型、产品层次结构、对象、安装点及产品目录等。PPR广泛应用于营销管理的产品推荐及销售合同中。客户产品范围的主要功能特点有：
和特定客户相关：只有指定的客户才会受产品列表和产品排除的购买约束。
时间相关：设定的购买约束只在特定的时间范围内有效。
和销售属性相关：比如销售组织、事务类型等相关。
客户产品范围的主要功能有两个：
产品购买限制：维护订单时检查，是否允许该客户购买这个产品，即一些产品只有在特定的业务应用、在特定的时间段中针对特定的客户有效。
产品推荐：客户在产品浏览、维护订单时，推荐相关产品，提升销量。
见图2.16“客户产品范围”（路径：销售专员业务角色>销售运行>合作伙伴/产品范围），PPR由抬头和行项目组成。抬头包括编号、PPR类型、是否排除及状态等，行项目中指定客户产品范围的规则，可以是其他PPR或为客户、产品及有效期的组合。PPR类型确定PPR抬头和行项目的属性和功能控制，例如所适用的应用（销售合同、营销项目等等）、组织数据、允许使用的产品参考类型（如产品、产品类别、对象及其他PPR等）。

图2.16　客户产品范围
见图2.17“客户产品范围中的客户与产品”（路径同上图），该行项目中指定了具体的客户并在产品表格维护了产品列表，可以根据产品结构、分类等直接确定产品。

图2.17　客户产品范围中的客户与产品
1.?客户产品范围规则
PPR规则用来确定PPR中的客户、产品和有效期时间期限，包括客户确定规则、产品确定规则以及时间期间确定规则。PPR规则即为一个函数，通过函数确定系统根据函数中指定的业务规则找到满足条件的客户、产品，确定有效期。比如通过规则可以根据产品类别、产品属性确定PPR所包含的产品；可以根据客户的年龄、类别、收入等各种属性确定满足条件的客户。
2.?客户产品范围相关功能
销售订单、ERP销售订单及贸易促进中的产品检查：销售事务及贸易促进业务中可以使用PPR或产品清单检查该客户是否可以购买指定的产品。ERP销售订单中可以使用前N个畅销产品清单，即为一种PPR。
销售合同和销售协议中，可以指定客户可以释放的产品清单，即后续销售订单中仅可以释放合同中规定的产品，才能享受合同规定的价格和条件。具体产品、产品类别和PPR均可以维护在可释放的产品清单中。使用PPR时，创建合同释放的订单时，系统自动展开PPR中的产品，供选择。
PPR的等级管理：可以为PPR设置等级（Rank），如果事务中发现多个满足条件的PPR时，系统可以采用等级较高的PPR。使用事务代码CRMM_PPR_CHANGE_RANK可以批量更改等级。
PPR的状态管理：可以使用处理中、已激活、待删除、待归档及已删除状态。使用事务代码CRMM_PPR_CHNG_STATUS可以批量更改客户产品范围的状态。
技术指南：
PPR类型起着重要的控制作用（路径：配置>CRM>主数据>产品/合作伙伴范围>基本设置>定义合伙人/产品范围类型），确定是否可以在产品检查或产品推荐中使用，指定应用业务场景（如销售合同、销售订单、前N个畅销产品清单等），指定组织数据参考类型（销售组织、服务组织、事务类型及合作伙伴功能，选中的字段会出现在PPR组织数据中），设定允许的产品参考类型（即是否允许产品、产品类别、产品层次结构、安装点、PPR产品规则等）和客户参考类型（业务合作伙伴、BP层次结构、市场营销分段、PPR BP规则等），设定有效期参考类型，设定允许的PPR行项目参考类型。在“定义事务类型和应用程序相关检查”中设定哪些事务类型需要启用PPR产品检查功能以及检查哪些PPR类型；在应用程序中指定需要进行PPR检查的应用，如MKPT营销计划、客户计划等。
PPR规则配置函数的指定见配置>CRM>主数据>产品/合作伙伴范围>规则>定义合作伙伴/产品范围的规则。可以定义客户、产品和有效期的规则，并且指定规则函数，指定规则所用的应用。其他配置如BADI、等级等可以参考配置>CRM>主数据>产品/合作伙伴范围。
2.1.3　SAP CRM组织结构管理
组织结构是重要的基础数据，是企业的营销、销售和服务等各种业务功能单位的映射。业务处理中通常都需要指定相关的组织数据。本节首先介绍组织结构的基本功能与维护，然后介绍事务中组织数据的确定方法，即通过组织模型或负责区域确定负责的组织单元。
2.1.3.1　组织结构基本功能与维护
SAP CRM的组织结构管理可以灵活的映射企业的各组织结构，包括各功能部门的层次结构，比如销售部门、服务部门及市场营销部门。可以把企业的分子公司、事业部、业务部门、维修点、办事处等维护成组织单元。CRM组织管理结构由组织单元、岗位和人员组成，即组织单元之间建立层次关系，一个组织单元可以有多个下属岗位，一个岗位可以有多个人员。
见图2.18“组织结构”（路径：销售专员业务角色>销售运行>组织模型），这里显示了组织单元IDES USA看下面有区域营销和区域销售两个组织单元，区域销售组织单元下分成东北部销售区域和西北部等销售区域；东北部销售区域中设置了销售经理和客户经理两个岗位，在经理中分配了两个用户，即员工。
根据CRM组织单元所承担的不同的业务功能，组织单元分成营销组织、销售组织以及服务组织。销售组织单元可以与ERP销售组织关联，并可以分配ERP销售办公室和销售组。服务组织可以与ERP计划工厂关联。组织单元和岗位可以设置多种的属性，详细描述该对象并可用于后续组织数据确定、审批岗位确定等业务中，
见图2.19“组织单元”（路径：销售专员业务角色>销售运行>组织模型>基础信息）。
SAP CRM的组织结构比SAP ERP的SD企业结构更为灵活但联系紧密，与SAP ERP HCM的组织管理具有诸多相同的功能和特点。如果SAP CRM的销售模块集成后端SAP ERP系统，以便CRM中维护的销售订单能够复制到ERP中，进行后续的发货等后勤执行业务处理，则需要将CRM组织单元映射为ERP的销售组织、销售办公室和销售组。
ERP中的组织结构（主要是销售范围、销售组和销售办公室）可以同步到CRM中，在CRM中自动创建对应的组织单元并设置映射关系，销售办公室和销售组为组织单元的下属组织单元。CRM中的组织单元可以和ERP中的销售组织、销售办公室和销售组建立映射关系。而ERP中的分销渠道和产品组是CRM组织单元的属性，因此，一个CRM组织单元可以对应到ERP中的多个销售范围。
SAP ERP HR模块中的组织结构、岗位和人员，可以通过ALE数据交换的方式同步到SAP CRM组织结构中。这对于使用了SAP ERP HCM模块，并且企业的组织结构比较复杂的企业来说，集成HR模块的组织结构会减少维护的工作量，并使两个系统组织结构一致。当然要分析实际的业务需求，判断ERP HR模块的组织结构是否可以供CRM的业务流程使用，如果差别比较大，就可以直接在CRM中搭建组织层次结构。
1.?CRM组织结构对象和组织单元的业务功能
CRM组织结构的对象有三种，即组织单元、岗位、员工或用户。其中组织单元和组织单元之间可以构建多层的层次结构关系。一个组织单元下可以维护多个岗位，一个岗位只能属于一个组织单元，一个员工或者用户可以分配到一个或者多个岗位中。相关功能如下：
组织单元：类型为O，一般表示一个单位或者某个层级的企业组织及部门。组织单元可以映射ERP的销售组织、销售办公室和销售组，而分销渠道和产品组是组织单元的属性。
岗位：根据企业的工作职能设定的岗位，比如服务岗、销售岗、营销岗及交互中心座席岗等。
员工或用户：岗位中可以直接分配系统用户，也可以分配CRM员工，即分配带有员工角色的业务合作伙伴，员工角色中关联具体的系统用户。通过分配CRM员工，可以使用业务合作伙伴功能维护更多信息，使用更为灵活。
组织单元可以承担不同的业务功能，即销售组织单元、服务组织单元和市场营销组织单元。在巴西和韩国等地，为了税务的需要，还有业务地点（Business Places）功能。在销售组织单元中可以指定映射到ERP的销售组织、销售办事处和销售组，用于销售业务中。在服务组织单元中，可以映射ERP的计划工厂，同时需要标识为服务组织，用于服务计划和服务执行等服务业务中。在市场营销组织中，选择营销组织后该组织单元即可成为营销组织，以便能够在营销计划和营销活动等营销业务对象中使用。在组织模型中可维护组织单元的业务功能。
2.?组织单元属性
CRM组织结构中的组织单元和岗位可以有很多属性，系统也提供诸多标准属性。用户可以根据实际的业务需求灵活定义各种自定义属性，以便对组织单元和岗位进行分类和描述。组织数据确定、工作流中的岗位确定及权限管理均可以使用组织单元或岗位的属性。需要用于组织数据确定的组织单元，需要标识为“在确定中已允许的对象”，即允许该组织单元在组织数据确定中使用。CRM提供了一些常用属性，其中部分属性在流程中有着重要的作用。常用属性见表2.10。

应用举例：
将岗位分成座席经理、一线座席、二线座席、英语座席、管理组等。
将营销的岗位分成日常管理员、市场人员、协议维护员、费用管理员、信用管理员、销售副经理及销售经理等。
3.?组织结构的增强模式和普通模式
根据与后台ERP系统集成的方式不同，CRM的组织结构有两种版本，即普通后台集成版本和增强后台集成版本。标准系统使用普通后台集成版本。在该版本中，一个销售组织、销售办事处和销售组均对应一个CRM组织单元，即一个ERP销售组织、销售办事处、销售组只能分配给一个组织单元，下级组织单元继承上级组织的销售组织。
但是在ERP中，一个销售组可以分配给多个销售办事处。在这种情况下，需要使用增强后台集成版本。增强模式中，销售办公室和销售组成为组织单元的表格属性，即一个组织单元属性中可以维护多个销售办公室和销售组，而在普通版本中，一个组织单元只能指定一个销售办事处或销售组。
2.1.3.2　组织数据确定
维护事务数据时，系统根据业务场景或单据类型、客户及用户等各种背景信息，自动确定所用的组织数据（销售组织、服务组织、营销组织、分销渠道及产品组等）。如果找到多个满足条件的组织单元，系统就弹出对话框供用户选择；如果能够唯一确定，系统就直接采用。如果系统无法自动确定或者系统未设置自动确定，就需要手工指定对应的组织结构数据。可以在各种业务流程中使用组织结构确定功能，例如：销售类业务（销售订单、报价单、商机等），服务类业务（服务报价单、服务订单、服务确认等），市场营销活动中。
组织数据在销售和服务业务处理中常常是必要信息，组织结构是处理单据的负责组织，起着关键的作用。比如销售单据中，销售组织、分销渠道、产品组一般都是必要信息，因为这些信息与定价等功能有着直接的关系，并且订单复制到ERP时，必须指定订单的销售范围（销售组织＋分销渠道＋产品组）。在服务单据中，服务组织是必需的，表示该服务是由哪个服务组织负责处理或者在这个服务组织范围内的。
组织数据的确定有以下两种方式：
通过组织模型确定组织数据：即通过评估组织模型中各组织单元的属性确定满足条件的组织单元。维护事务时，根据事务维护人员、事务凭证信息以及客户、产品等信息，系统将一些用于评估的信息传递给组织数据确定规则，由组织确定规则评估组织模型中的各组织单元，找到满足条件的组织单元。组织确定规则中指定需要用于评估组织模型的字段，例如客户编号、事务类型、邮政编码等信息，规则程序即使用这些属性搜索组织中所有满足条件的组织单元。因此需要维护相关组织单元的属性，如果组织结构比较庞大，遍历搜索组织单元需要一些处理时间，因此性能比按负责区域直接指定组织单元的方式要差一些。但这通常是最常用的组织数据确定方式，如果能够维护需要确定的组织单元属性即可使用。
通过负责区域（Responsibility）确定组织数据：即通过预先定义的规则直接确定负责区域的组织单元，比如客户编号从范围1到范围2的客户，由销售办公室A负责；国家为阿根廷的事务由南美服务部门负责。在规则维护上，指定规则后，直接指定负责的组织单元。因此确定组织数据时，系统无需遍历整个组织模型中的所有组织单元，也无需为组织单元设定查询属性。创建事务时，自动自动根据客户、产品、用户及事务等信息，评估负责区域的规则，直接使用该规则指定的组织单元。因此性能通常好于按组织模型确定组织数据的方式。该模式适合于组织单元众多但所维护的属性较少或者未维护的情况。

见图2.20“服务订单中的组织数据”（路径：服务专员业务角色>服务订单>组织数据），列出了该服务订单中的销售组织与服务组织。系统可以根据组织数据确定规则自动确定组织单位，也可以由用户手工选择或录入（即可以设置为不自动确定组织数据）。如果该事务类型分配了服务方案的组织参数文件，则可以使用服务组织数据；如果分配了销售方案的组织参数文件，则可以使用销售组织数据。如果该事务类型未分配组织数据确定参数文件，则无法维护组织
数据。
在事务维护中，销售组织单位或服务组织单位由确定规则确定，用户可以在规则确定的组织单位结果清单中选择。确定或选择组织单位以后，系统读取该组织单位的属性，如关联的销售组织、服务组织，以及分销渠道、产品组、销售办事处和销售组。例如某个销售组织分配了分销渠道01和分销渠道02，则对于该销售组织，用户只能选择01或02分销渠道。如果用户直接录入组织数据，系统检查这些属性的组合是否在组织模型中维护，即检查组合是否有效。组织数据维护完成后，修改客户等相关数据后，系统不再重新确定组织数据，但用户可以手工重新选择满足条件的组织数据。
1.?组织数据参数文件
组织数据参数文件用来控制单据的组织数据确定及设置。组织数据确定可以应用于销售和服务业务场景（方案）中，同一个参数文件可以同时用在销售方案和服务方案中。确认规则可以是组织模型确定规则或基于责任区域的确定规则，通常仅使用其中之一。例如图2.21“组织结构参数文件”（路径：配置>CRM>主数据>组织管理>组织数据确定>更改规则和参数文件>维护组织数据参数文件>明细）该组织结构参数文件使用了组织模型确定规则10000280（客户邮编确定）。该参数文件中，将销售组织、分销渠道设置为必填。如果在确认规则中填写责任确定规则，即按照定义的责任规则确定。
2.?按组织模型确定规则
即根据客户、用户、产品及事务等相关信息评估组织模型中组织单元的属性，找到符合条件的组织单元的一段程序。见

图2.22“组织结构确定规则”（路径：配置>CRM>主数据>组织管理>组织数据确定>更改规则和参数文件>维护确定规则，或事务代码PFAC），系统显示了组织数据确定规则10000280类别为组织模型确定，用于销售方案中。该规则使用了客户的邮政编码作为确定属性，即维护事务时需要录入客户，然后系统将该客户地址中的邮政编码传递给规则函数，规则函数搜索组织模型，逐个比较组织单元的属性，将属性满足该客户邮政编码的组织单元均列出来。函数模块中指定搜索组织模型的ABAP程序函数，这里为CRM_ORGMAN_ORGOBJECTS_FIND_1。该函数可以自行定义，其使用容器中规定的属性，匹配和搜索满足条件的组织单元。当然在程序中可以根据其他条件过滤组织模型的评估结果。系统提供诸多标准的组织数据确定规则和函数。用户可以根据实际业务需求，复制系统标准的组织数据确定函数，进行修改，如增加过滤条件等，只要保持输入与输出等参数结构一致即可在组织规则中使用。

见图2.23“组织结构确定规则：容器”（路径同上图>容器），容器中规定了用于评估组织模型的属性。如这里使用了邮政编码字段，该字段属性的具体来源数据表ADRC的字段POST_CODE1，即事务中录入的客户的标准地址中的邮政编码。创建订单时，系统读取所录入的客户数据中的邮政编码，然后根据确定规则函数到组织模型中搜索，列出组织单元属性中满足这个邮政编码的组织单元。确定组织单元后，系统列出该组织单元所关联的销售组织和分销渠道和产品组等属性，列出销售范围及其他属性，供用户选择。
3.?按责任区域确定组织数据
按责任确定组织数据，需要在组织结构参数文件的规则中指定责任规则。责任规则的类别为按责任确定，根据规则直接确定满足条件的组织单元，无需评估组织模型。
见图2.24“为责任规则分配负责组织”（路径：配置>CRM>主数据>组织管理>组织数据确定>更改规则和参数文件>维护确定规则），这里使用的规则为10000157，即直接根据合作伙伴编号确定组织数据，类别为“代理确定：责任”。在容器中选择责任规则所用的属性，例如客户地址、产品及事务等信息字段，这里选择了合作伙伴编号为确定属性。在职责中，可以查看和分配该规则对应的组织单元，即哪些编号范围的客户数据由哪个组织单元负责。如果容器中选择客户所在的国家，则可以根据国家直接确定组织单元（职责中指定）。
图中定义责任组织规则后，可以为该规则创建一个或多个职责范围（Responsibility）。每个职责根据容器中规定的属性界定范围。例如这里容器中使用了客户编号范围，可以将编号为1到10000的客户设置为职责范围1，而10001到20000的客户设置为职责范围2，在插入代理分配中，即可以直接为职责范围指定负责的组织单元，例如职责范围由北京销售组织负责，而职责范围2由上海销售组织负责。如果容器中设置为国家，则根据国家创建职责范围，设定职责范围对应的负责组织单元。
4.?组织数据确定过程的分配
在事务单据配置中，组织数据确定过程分配给事务类型或行项目类别。一个事务类型只能拥有一个组织数据确定过程。然后维护事务凭证时即根据此组织数据确定过程确定负责的销售组织单元或服务组织单元。
技术指南：
组织结构的ERP标准集成模式可以通过程序CRMC_ORGMAN_SWITCH_TO_ENH_MODEL转换成增强模式，注意该转换不可逆，需要谨慎操作。通常情况下，如果ERP不存在一个销售组分配给多个销售办事处的情况，则无需转换成增强版本。
在网络渠道应用中，系统确定组织结构的方式和普通Web UI应用中不尽相同，系统根据产品目录和产品目录变式中的分销链（销售组织和分销渠道）数据确定网络渠道销售订单的组织结构。营销组织由当前营销项目的负责员工所在的营销组织确定。Web UI中可以维护组织模型，如创建组织单元、岗位、分配员工，为组织单元或岗位维护属性及分配业务角色，但功能比SAP客户端中要简单一些（事务代码PPOMA_CRM），请参考SAP注释1404805。
为了提升组织结构的性能，可以通过程序HRBCI_ATTRIBUTES_BUFFER_UPDATE对组织模型和属性进行缓存设置。该程序可以设置为定期运行的后台作业，如每天凌晨执行一次。组织模型变更后也可以手工执行一次。通过SM30维护视图T77OMATTR可以维护或自定义组织单元或岗位的属性，可以设置属性是否加入到缓存中，加入缓存的属性可以提升性能。在组织数据确定中，使用责任范围的规则能提升性能，因为责任范围规则无需评估整个组织模型，而是由规则直接指定负责的组织单元。在组织单元属性中，如果不设置标识“在确定中已允许的对象”，组织数据确定程序即不考虑此组织单元。因此，建议仅将需要用于组织确定的才打上此标识，减少带此标识的组织单元数量，这样能提升组织确定的性能。编辑组织单元保存时，系统默认清除此标识，因此如果的确需要此标识，需要重新勾选上。
关于行项目的组织数据：通常事务抬头中的部门（Division，也称为产品组）决定行项目的部门，即使用抬头部门（Header Division），抬头组织数据确定后，其选中的组织数据（包括部门）被复制到行项目中（行项目中无法选择部门），即一个事务凭证拥有同一个部门，此时需要在行项目类别设置中分配一个无确定规则的组织确定参数文件。如果不使用抬头部门，则抬头中无部门，而每个行项目可以有不同的部门并从行项目产品中获取，行项目的其他组织数据如销售组织和渠道复制自事务抬头，即一个事务凭证中，不同行项目可以有不同的部门，这时候也需要为行项目类别分配一个无确定规则的组织确定参数文件。如果不为行项目类别分配组织数据确定参数文件，则行项目无组织结构数据。CRM中也可以不使用部门，但ERP中必须使用部门处理主数据和事务数据，因此在这种情况下，需要在CRM中指定一个默认的虚拟的部门，传递到ERP中时即默认填充此虚拟部门。关于部门的配置请参考配置>CRM>主数据>组织管理>部门设置。
组织结构的确定与配置路径为：配置>CRM>主数据>组织管理，“部门设置”中设置部门参数、维护部门清单，如使用抬头部门或不使用部门，在不使用部门的情况下需要执行虚拟部门。在“销售方案组织数据”中维护分销渠道、分销渠道和产品的组合，以及维护销售地区、在“组织模型”可以创建组织模型根节点，然后维护组织模型，即事务代码PPOMA_CRM。在“组织数据确定”中可以使用向导或直接维护组织模型的组织数据确认规则及责任区域的确认规则，维护组织数据参数文件并分配到事务类型及行项目中。“工具”中提供一些翻译、检查等功能。“从SAP ECC 组织单位的分配”，可以维护CRM的组织单元和ERP销售组织、销售办公室、销售组合和计划功能的映射关系。“数据传输”中可以将ERP组织数据复制到CRM中（事务代码CRMC_R3_ORG_GENERATE），此程序通常在配置系统初期一次性下载，仅使用一次。复制前不能在CRM中手工创建组织结构，否则可能会被覆盖。“组织单位的跨系统分配”中可以设定开票、业务范围、服务的工厂和库存地点、服务的成本中心、指定销售组织的信用控制范围等跨系统的
配置。
2.1.4　SAP CRM服务对象管理
本节讲述对象、安装点、计数器及读数，这些数据主要用于服务模块和服务相关流程中。在一些行业流程中，比如水电气公共服务行业（Utilities）、金融行业、公共服务行业及汽车中也会使用到这些用到这些基础数据。
2.1.4.1　对象管理
对象（Objects）能够唯一标识企业所提供的有形或者无形的产品。对象通常是企业所提供的产品的实例化，有唯一的标识号，比如序列号等。对象主要用于后续的服务管理中，比如后续保养、维护或维修，通常需要指定具体的服务对象。
例如，某种型号的硬盘存储器，从产品的角度看，系统只有一个产品编号，生产、采购及销售等均以产品编号为基础。而每个硬盘都有唯一的序列号，通常因为客户的购买日期不同，质保开始和结束时间也会不同。维修服务中如果需要更换硬盘，通常需要指定有问题的硬盘序列号。
应用举例：
计算机设备、软件：笔记本、台式机、中央存储器、服务器及网络设备等都是对象。软件的每一个序列号的拷贝，也可以看成是一个对象。
车辆运输设备、机械设备：汽车、轮船及飞机；车床、电梯、叉车及各种工业设备等。
测量设备：比如电表、煤气表、水表及里程表等，而小区、楼宇通常维护为安装点。
通常将企业根据服务对象将企业所提供的主要设备维护成对象，例如计算机、汽车、机械设备等。如果需要管理到具体的部件并且建立层次结构关系，可以使用安装点的功能，搭建安装点和组件层次结构关系。
1.?对象和产品
SAP CRM系统中，对象使用CRM产品结构和功能进行管理，
见图2.25“对象”（路径：服务专员业务角色>客户&产品>对象）。因此从技术上看，对象是一种产品主数据，具有与产品主数据相同的存储表和结构，使用相同的工具维护和管理对象属性。但是对象和普通的产品不同，通常不能用来销售，但可以在服务等业务流程中使用。对象与产品的相同点和关系主要有：
对象和产品一样使用产品分类和层次结构；可以为对象分配一个或者多个产品类别，对象的产品类型为物料，因此基本产品类别的类型必须是物料，对象族（Object Family）通常为0401。创建对象时必须选择对象族。
对象和产品一样使用属性和属性集，因此可以定义产品属性与属性集拓充对象的各种信息；所用的属性集由基本类别中所分配的属性决定。
对象和产品一样可以使用关系功能：对象可以和其他对象、产品、客户、计数器、质保和资质需求等对象建立关系。
与产品主数据一样，对象支持备用编号（Alternative ID），比如设定车辆标识号、序列号、ISBN等标识客户的编号。
对象族用于分类，把具有相同一定属性的对象组成对象族，维护对象时，每一个对象都必须属于一个对象族。关于产品层次结构和产品属性集的更多信息，请参考本章的2.1.2节“SAP CRM产品管理”。
2.?对象的基本信息
参见表2.11。

3.?对象位置及合作伙伴信息
记录对象的当前位置。地址信息可以包含国家、地区、城市和街道等信息，使用了标准的地址服务功能。而地理位置信息包含了经度和纬度信息，可以手工录入，根据配置，也可以从所录入的地址中确定。
对象中可以指定与对象相关的合作伙及所承担的功能，例如售达方、送达方、供应商等。其中供应商合作伙伴功能为该组件的供应方，在发生供应商质保索赔时，确定质保索赔单的供应商。分配合作伙伴时可以指定具体的合作伙伴功能，指定关系的有效期。如果有多个合作伙伴，其中一个为主要合作伙伴。
4.?对象关系和结构
对象可以与其他数据建立关系。对象关联的主要关系有：相关附件、相关服务、相关的服务备件、对资质的需求（服务时对服务人员的资质需求）、质保、计数器及其他相关对象。在对象中，系统使用不同的信息块显示相关的关系。对象和其他对象也可以建立关系，并且系统中可以自定义此关系。例如服务器和工作站、IP都维护成对象，工作站W1连接了服务器S1，某IP为服务器S1的IP，可以使用关系“连接”、“是主机”等关系。
对象可以由多个部件组成，比如一辆车是一个对象，由引擎、车架及轮子等组件组成。对象的结构使用了安装点的功能，通过为对象分配下层组件，搭建层次化的结构关系。对象的“组件”信息块中可以添加、移除、卸载或安装组件，可以显示所有相关的组件。在“对象结构”信息块中，可以查看和维护完整的对象结构。可以卸载（Dismantle）某个对象组件，卸载后该组件所在的位置为一个缺口组件（GAP），所有的下层组件均被保留。然后可以在这个位置上重新安装组件。复制带有结构的对象时，相关的结构也会复制到新对象中。标识“在结构中使用”表示该对象在安装点中使用。服务业务中，可以指定具体的组件，可以更换和更新组件。
可以为对象指定一个参考产品，相关的技术和业务数据即从所参考的产品中获取，如型号、生产商等对该产品的所有的对象均相同的数据可以维护在参考产品上，这样能够减少数据的冗余，而对于序列号、购买日期等对象特定信息，还是需要直接维护在对象上。产品类别中可以指定该类别产品可以在哪些对象类别中使用，设定哪些属性集从参考产品中获取。
5.?对象事实表
事实表提供对象的各种概要信息，这些信息可以来自多种数据源，包括对象主数据及相关事务数据。事实表可以集成来自BW、数据查询信息集等数据源的信息。系统提供的标准的事实表信息块有：对象明细信息、相关方、未清的产品服务通知单、案例、服务合同、未清服务项目、已关闭的最近一个服务订单、计数器及读数及关联的质保信息等。
6.?对象的历史信息
系统记录对象的各种变更和使用的历史信息，包括更改历史、合作伙伴历史以及事件历史。更改历史为对对象关键字段的更改，系统记录更改时间、更改人、字段和更改前后的数值。合作伙伴历史指相关方更改后会记录相关变更历史，如车辆拥有人的变更等。事件变更是可以来自业务事务处理、交互中心或外部系统（如ERP系统中的采购），系统使用对象集成框架（OTIF）自动记录对象的使用情况。
7.?对象的数据交换与应用集成
ERP中未生成设备信息的纯序列号可以下载到CRM中，序列号相关的合作伙伴以及产品的配置信息也会复制到CRM中。
对象集成框架（Object Integration Framework，OTIF）用来管理对象的完整生命周期，即外部各种应用系统收集到对象的变化信息后如何反馈到CRM系统的对象中。对象集成框架可以简化对象相关业务的集成开发。外部应用程序通过预定义的协议与CRM系统的对象交互，允许对象影响具体的事务处理，允许通过集成的状态管理跟踪对象的生命周期，确保对象数据的一致性，可以集中定义影响对象的业务规则。对象的重要信息变化或者发生某些事件后，系统可以向对象集成框架触发相关事件（Event），事件进而会触发相关流程操作，比如设置对象的状态、更改对象的相关信息等。系统提供的标准的一些事件为：软件授权下载、软件维护合同延展、软件维护过期、采购软件维护、软件注册、软件升级及软件退回等。不同的事件会触发不同的流程和对相关数据进行更新。
技术指南：
使用ERP集成时，通常在ERP物料类型所在的层次结构R3PRODSTYP中创建MAT_EQUI产品类别，供对象使用（事务代码：COMM_HIERARCHY），将该类别的产品类型设置为物料，对象族设置为0401；在合作伙伴确定过程中选择所用的合作伙伴确定过程，以便在对象中使用合作伙伴功能及确定方式。为该产品类别分配对象所用的标准属性集和自定义产品属性集。在关系类型中，分配可以使用的关系类型，如产品的组件、担保、资格需求等。如果要使用定义的关系类型，需要使用关系类型IOBRL（对象关系），对象之间的关系配置请参考：配置>CRM>主数据>产品>对象>服务管理的对象设置>定义对象关系。
产品类别中，PRREF关系为“允许的对象类别”，即设定产品类别所能用于哪些对象类别中。在对象中录入参考产品时，该对象的类别必须在这个产品所允许的对象类别清单中，如果不允许，即不能参考此产品。参考产品和对象的产品类型必须相同，参考属性集必须分配到产品和对象的类别中，并且在对象类别的属性集分配中标识为“参考”。在系统配置中，需要激活对象的产品参考功能，请参考：配置>跨应用程序组件>SAP 产品>基本设置>允许单独对象的产品参考。
序列号的对象为SERIALNUMBER（在ERP中尚未生成设备主数据的序列号）。对于可配置物料的序列号，可以通过对象SERNR_CONFIG下载到CRM中。序列号下载到CRM中后自动生成对应的对象，物料、设备类型等数据保存在信息集COM_TA_R3_ID中。通过CRM中间件的XIF接口，可以使用XML/SOAP技术与基于SAP ERP的车辆管理系统（VMS，DI）交换车辆的对象数据。XIF的对象接口主要有CRMXIF_PRODUCT_INDOBJ_SAVE（对象的属性集）、CRMXIF_PRODUCT_INDOBJ_REL_SAVE（对象的关系）、CRMXIF_PRODUCT_INDOBJ_EH_SAVE（对象的事件历史）。
使用事务代码COMCMATERIALID可以为产品或对象的基础类别定义编号范围，并为产品类别分配编号范围。产品的编号范围、类别等基础配置，请参考：配置>跨应用程序组件>SAP产品。
对象事实表信息与产品事实表信息共用Web UI组件PRD_FACTSHEET，可以通过事务代码BSP_WD_CMPWB配置事实表视图，确定显示布局（如几行几列等），或增加自定义视图。
2.1.4.2　安装点管理
安装点（Installed Base）用来结构化组织和管理安装于客户处的各种对象，这些服务对象通常是后续服务的基础。而这些设备往往有层级关系，服务时可以指定具体的服务对象，了解设备的结构和组件。企业内部的设备也可以维护成安装点，例如在IT管理中，将企业的IT设备维护成安装点。安装点可以在CRM的各种应用中使用，如Web UI服务管理、交互中心、移动服务以及电子服务中。安装点广泛应用于服务合同以及各类服务事务中。
应用举例：
电梯设备：电梯生产商生产并为客户提供电梯。维护过程中，需要了解电梯的基本情况，需要了解电梯安装的位置、环境、所属客户、所属物业、所属小区及所属幢楼宇等。通常以客户为基础，构建电梯的层次结构，即安装点，比如第一层是客户、第二层是小区、第三层是楼房号码、第四层是楼层单元、第五层是电梯位置、第六层是具体的电梯。
机械设备：机床、起重器等大型工业设备，可根据客户、工厂、车间、位置及机床等来构建层次关系。
计算机设备：可以按照客户、机房及计算机来组织。可以维护计算机的主要备件。
安装点可以设置任意的层次结构，可根据企业的具体业务流程和管理能力确定需要维护的层级。一般来说维护到服务订单中能够指定的主要部件为止，或者再深入细化一层。比如可以把一个设备的主要部件或者部件组做成最底层，比如一个设备主要有五个部件组成，这五个部件都可以维护成一个对象或者直接指定产品，而部件由一系列更细的零部件组成。因此可以将安装节点维护到主要部件层面，而不是将所有细微零部件都维护在安装点中，以减少安装点层级和节点数，提升性能。通常，安装点层级越多、所维护的组件级别越细，则数据量越大，服务订单中指定到组件的工作量就越大，所以不一定是越细层次越多越好，要视企业的具体业务和情况而定。
见图2.26“安装点”（路径：服务专员业务角色>客户&产品>安装点），安装点由多层的层次结构组成，一个安装点可以有一个根节点，每个节点都称为组件（Component），组件可以维护下级组件，构成层次结构关系。每个组件均有系统内部编号、字符串标识号及描述等信息。同时组件可以关联合作伙伴和地址、质保、资历需求、计数器和计数器读数。组件有四种类型：

图2.26　安装点
文本组件：用文本填写的组件，可以用于描述，便于搭建层次结构。
对象组件：使用个体对象、设备主数据；可以直接在安装点页面中创建对象，或选择已维护的对象。
产品组件：使用系统中的产品作为组件。
安装点组件：使用其他安装点作为组件。
1.?安装点常用功能
安装点的一些常用功能说明参见表2.12。

2.?ERP设备与功能位置的复制
ERP客户服务CS模块中的设备可以通过CRM中间件复制到CRM，CRM中为安装点中的对象组件。如果设备有下级结构，则在CRM中建立安装点层次结构。如果该设备在ERP中是构造类型（construction type，即为一种物料），则此物料将作为CRM对象的参考产品。如果ERP中的设备存在质保开始和结束日期，复制到CRM时，系统检查该对象的参考产品是否关联质保，如果存在，则根据ERP的质保开始和结束日期创建质保关联。如果激活数据上载功能，CRM中对设备数据的更改会自动同步到ERP中，以保持数据一致。
同步设备数据前，需要将相关的客户和物料数据复制到CRM。可以复制设备的描述、文本、层次结构、关联的合作伙伴、地址、状态、配置信息制造商以及ERP标识信息（如序列号、设备编号等）。
与设备功能类似，ERP中的功能位置也可以复制到CRM中。功能位置复制到CRM后成为CRM的对象，并通过安装点构建功能位置层次结构。CRM中对功能位置的修改可以同步回ERP系统中，确保两个系统具有相同的数据。ERP的功能位置中如果有下属对象，则复制到CRM后，功能位置、设备和层次结构关系均会体现在CRM的安装点中。
技术指南：
从ERP复制设备数据，需要激活BADI CRM_EQUI_LOAD的实施，该BADI可以灵活定义数据的映射关系。通过中间件对象EQUIPMENT可以从ERP中复制设备数据到CRM系统中（初始复制）。初始复制后系统自动进行增量复制，即ERP中更改的数据会复制到CRM系统中，设备的增量复制请参考SAP注释637173。通过激活中间件对象DNL_EQUIPMENT（设备）及DNL_EQUI_HIER（设备层次结构）可以将设备信息上载到ERP中（事务代码R3AC1）。如果不需要，可以取消这些对象的激活状态。上载设备数据同时需要设置：配置>CRM>主数据>产品>对象>指定上载各对象的适配器对象，将相关的对象族如0401映射为数据交换适配器对象DNL_EQUIPMENT。同步功能位置的中间件对象为FUNCLOC，可以通过BADI CRM_FUNCLOC_LOAD设定数据映射关系。
通过中间件的XIF接口，可以实现安装点与外部系统的数据交换，处理接口函数为CRMXIF_IBASE_SAVE，通过业务增强CRMXIF_IBASE_MAP，可以对数据交换进行数据映射CRMXIF_IBASE_MAP。
部分企业拥有众多的对象或安装点数据，甚至还需要考虑组件信息，对于数据条目数超过千万的，需要特别注意数据存取的性能优化，建立适当的索引，甚至将单据中的部分信息例如序列号等保存到订单索引表（CRMD_ORDER_INDEX）中。服务订单中根据对象序列号搜索需要关联多个数据表（CRMD_ORDER_INDEX/CRMD_LINK/ CRMD_SRV_OSSET/CRMD_SRV_REFOBJ），查询较慢，如果一个服务单仅有一个序列号，可以将序列号增强到订单索引表中。
通过启用索引表IBPART_IDX，能够提升按照合作伙伴搜索安装点的性能。使用报表IBPART_IDX_CREATE_INDEX可以建立索引，安装点保存时系统自动将安装点合作伙伴的关系写入到索引表中。通过报表程序IBPART_IDX_DELETE_INDEX可以删除所建立的“安装点-合作伙伴”的索引。
2.1.4.3　计数器和读数管理
计数器（Counters）用来测量和记录对象的使用情况或损耗情况，是物理测量设备的系统体现。日常生活及企业业务中经常需要多种类型的计数器用于记录事务情况。对计数器的数值记录即为读数，读数是在某时刻对某个计数器的计量数值的记录，记录计数器当时的情况。
应用举例：
汽车行驶里程表、温度计、煤气表、水表、电表及复印机计数器。
车辆保养中，车辆行驶里程数、行驶时间，到了一定的行驶时间和行驶里程数就需要进行保养；或者质保期在一定的时间或者行驶里程数，比如两年六万公里，整车的质保期为两年六万公里，以先到的为准。然后每10000公里进行一次常规保养，每三万公里进行一次大保养。每笔保养均有相关的保养操作规范和内容。
在电梯保养中，要求每四周保养一次，一年有13个保养周期，每次都有例行的检查表。

计数器的维护见图2.27“计数器”（路径：服务专员业务角色>客户&产品>计数器），类别可以是公里、纸张数量或体积等各种分类；类型为向前计数的计数器、向后计数的计数器或任意数值的测量点；单位为该计数器读数的单位，以及列出该计数器分配在哪个安装点的组件中。
计数器有两种类型，一种是只能往前或者往后计数的计数器（前向计数器和后向计数器）；另外一种是可以是任意值的测量点。前向计数器即计数的数量不断增加，比如汽车里程数，电梯的运行时间。后向计数器即计数器的数量从一定的设置值不断减少，比如预先购买的IC卡电费，电费充入电表系统以后，随着用电会逐步减少；手机充值卡余额也是如此。而测量点读数并没有一定的规律。比如房间的湿度和温度，可能增加也可能减少，随时间在一定的范围内波动。
计数器可以有各种属性，用于描述和对计数器进行分类及控制。常见的属性有：
计数器描述：支持多语言。
用途：计数器的用途分类。
计数器类型：向前计数的计数器、向后计数的计数器或任意读数测量点。
测量单位：公里、小时、立方米或度等。
最大值、最小值及溢出值：允许的最大数值、最小数值和溢出值。
状态：计数器可以激活或者取消激活，未激活的计数器不能录入读数。
计数器可以单独创建和存在，但通常计数器维护后都分配到相关对象中。计数器可以分配到安装点的组件、个体对象以及产品中。可以为组件、对象和产品分配多个计数器，但是一个计数器只能在一个地方使用，如一个计数器不能分配给多个安装点组件。
读数指采集计数器的数值。历次读数均会记录在系统中，供收费计算或维护计划等业务流程使用。计数器中的读数见图2.28“计数器的读数”（路径：服务专员业务角色>客户&产品>读数），每次读数都有唯一的编号、读数编号、数值、单位及读数日期。读数保存后即不能再次修改，但可以取消录入的读数。可以重新激活已取消的读数，重新变成未取消的正常状态。读数历史中显示计数器相关的所有读数历史记录。

图2.28　计数器的读数
计数器的读数可以在以下环节采集和录入：
可以在计数器或者读数页面中直接录入计数器读数。
可以在计数器分配的对象中录入计数器读数，如安装点组件、对象和产品。
可以在服务报价单、服务订单、服务确认报工、服务合同、投诉与退货、内部维修等凭证中录入计数器读数。
可以通过外部接口自动采集和导入计数器读数。
计数器可以在多种服务事务中使用，如服务报价单、服务订单、服务确认报工、服务合同、投诉与退货、内部维修。在基于用量开票的服务合同中可以使用计数器记录实际用量，然后根据用量开票收款。在服务计划中，可以使用基于计数器的读数确定服务的计划日期，监控实际用量。计数器的应用和集成详细内容请参考第5章相关应用流程章节。
技术指南：
需要使用计数器的事务，需要在事务类型及行项目配置中设置启用计数器，请参考：配置>CRM>交易>基本设置>定义业务类型，服务处理的业务事务类别中选择“激活计数器”。
计数器和读数的配置请参考：配置>CRM>主数据>计数器和读数，可以定义计数器类别及检查BADI等。
2.1.5　SAP CRM知识库管理
企业总结业务经验形成知识，知识被各员工重复使用，减少培训和再次摸索的时间，提高工作效率。SAP CRM知识库管理就是为了管理企业的各种知识的。系统支持各种知识文本，然后进行索引，系统根据中文语义进行知识检索。
知识库可以用于交互中心中。客户来电，座席根据客户的问题搜索知识，向客户提供方案。通过知识库辅助，有助于加快问题处理、规范化问题处理及提高问题处理效率。知识库在企业内部信息技术支持、人力资源支持及财务支持上也有重要的作用，可以把相关的常见问题等都维护成知识文档，供相关服务人员随时查找、解答。SAP CRM中，可以使用知识文章或解决方案数据库维护和管理知识，两者具有相似的功能。
2.1.5.1　知识文章
知识文章（Knowledge Articles）用来记录业务中积累的各种有助于解决问题的信息。知识文章中可以进行多层次的分类，可以设置描述、关键词以及具体内容。知识文章的详细内容可以分类存放，比如问题描述及解决方案等。知识文章支持多语言，详细的内容可以维护成多种语言的版本。知识文章可以和系统中的对象、产品和各种交易事务建立关联关系，以表示该知识文章和对象、产品及哪些业务单据相关。
知识文章广泛应用于交互中心和服务处理中。交互中心的服务处理过程中，可以根据服务单据中选择的分类或者内容，系统自动搜索及推荐相关联的知识文章，以便提高问题处理效率。也可以在知识搜索中直接根据关键字进行搜索。知识文章与事件（Incident）、问题（Problem）、更改请求、服务请求、服务订单及投诉单等紧密集成。
知识文章使用SAP搜索和分类引擎（TREX）进行索引编译和知识检索。
见图2.29“知识文章”（路径：服务专员业务角色>客户&产品>知识文章），维护中可以选择知识文章的语言、简要描述及关键字，在文本内容中可以填写知识文章的内容、问题描述及方案描述等；在主题中，可以使用多层的分类。

图2.29　知识文章
2.1.5.2　解决方案数据库管理
解决方案数据库（Solution Database）是用来存储问题及解决方案的数据库，解决方案数据库和知识文章具有诸多相似功能，可以定义关键字、属性、自由文本内容及搜索及索引等。但知识文章在结构上使用了通用订单单据类型，具有通用订单的一些基本功能，可以和各种事务，特别是服务类事务连接在一起。而解决方案数据库相对来说是一种独立的知识数据库对象。
解决方案数据库在CRM早期版本即开始使用，可以用于SAP CRM GUI客户端应用中，可以应用于交互中心Webclient中，用于搜索知识库。而SAP CRM知识文章是在CRM 7.0才引入的对象。通常应用中，基本上知识文章可以替代解决方案数据库。
解决方案数据库可以作为单独的应用，在SAP GUI客户端中，可以使用事务代码CRMM_SEARCH搜索知识库；使用事务代码IS01/IS02/IS03维护知识库，见图2.30“解决方案数据库”（事务代码：IS01）。建立知识库的问题和解决方案，可解决方案和问题关联，并且可以和具体的业务对象关联。在基于互联网的客户自助服务（ICSS）中，用户可以自助搜索知识库和常见问题（FAQ）。知识库也使用TREX索引服务器对知识内容进行索引。

图2.30　解决方案数据库
技术指南：
在技术实现上，知识文章使用了统一订单结构，即具有类似服务订单的结构功能，例如能够使用多层分类、使用文本确定过程、定义用户状态等。同时能够与其他事务凭证建立凭证流关系，能够使用同一的事务凭证读取函数读取（如函数CRM_ORDER_READ）知识文章的相关内容。
可以通过XIF接口从外部系统导入到CRM解决方案数据库中，参考函数CRMXIF_SYMPTOM_SAVE及CRMXIF_SOLUTION_SAVE。