sap crm 基础数据与基础功能 - baidu

第 2 章

SAP CRM 基础数据与基础功能

基础数据也称主数据，是整个 CRM 系统的基础，是系统运行的基石，被多个模块共同

使用。基础数据中有诸多信息对流程和功能起着决定性的控制作用，比如合作伙伴关系、角

色、销售视图数据及服务类数据均在相关流程中体现和应用。而在诸多流程和应用中均会用

到一些基础功能，如业务合作伙伴处理、业务事务处理、定价、日期管理、操作及文本等。

本章介绍 SAP CRM 中常用的基础数据和基础功能。

项目实施中，主数据有时未受到足够的重视，这会导致一些问题，比如应用后未达成理

想的效果、使用不够方便及额外开发工作量大等。通常要充分使用基础数据和基础功能，标

准功能能够满足的，尽量使用标准功能，以降低系统开发所带来的工作量和维护成本，确保

系统的稳定性。通过基础数据和基本功能介绍，可以为后续章节的流程和功能介绍打下坚实

的基础。

2.1　SAP CRM 基础数据管理本节介绍 SAP CRM 的基础数据，包括业务合作伙伴、产品、组织结构、服务对象及知

识库等。合作伙伴、产品、组织结构可以用于营销、销售及服务管理等模块中；对象、安

装点、质保、计数器及知识库一般用于服务管理流程中。定价数据也是重要的基础数据，在

2.2.3 节中与定价的条件技术一起介绍。

2.1.1　SAP CRM 业务合作伙伴管理和企业的业务相关的任何单位、人员均统称为业务合作伙伴（Business Partner），比如正

式的有交易往来的正式客户（也常称为交易客户），还未曾有过业务往来的但是将来可能成

为正式客户的潜在客户，客户的联系人、竞争对手、供应商及企业员工等都属于业务合作伙

Chapter 2

第 2 章　SAP CRM 基础数据与基础功能　　15

伴。业务合作伙伴是一种重要的基础数据，被广泛应用于交易事务中，并且拥有一个或多个

角色，承担不同功能，可以与其他业务合作伙伴或业务对象建立各种关系。对于复杂的合作

伙伴可以建立层次结构关系。与业务合作伙伴的交互沟通是企业人员的重要工作，为了满足

法律等要求，业务中需要遵守客户的选择，如客户是否愿意接受营销信息等，可以使用营销

许可功能。还可以为客户定义各种属性，以便能精确地描述客户。下面简要介绍合作伙伴的

一些基础功能，关于合作伙伴更多的功能可以参考 4.2.2 节。

2.1.1.1　业务合作伙伴的角色

角色（Roles）即该业务合作伙伴在各种业务中所承担的功能与作用，是从业务功能上对

客户的一种分类。一个业务合作伙伴可以拥有一个或者多个角色，如一个业务合作伙伴同时

拥有售达方和渠道合作伙伴的角色。不同角色可以有不同的信息内容，即可以根据角色设置

使用和显示的客户信息块。常用的业务合作伙伴角色参见表 2.1。

表 2.1　常用业务合作伙伴角色

角　　色功能说明

潜在客户指还未有正式业务往来的、将来可能有业务往来的客户。通常用于线索、业务活动及机

会管理中

售达方同 SAP ERP 中的售达方，即销售给谁，销售订单中指定的客户

送达方

同 ERP 的送达方，即货物发送给谁，可以和售达方不一样。因为一个售达方可以有一

个或者多个的送达方，送达方和售达方之间建立关联关系；比如客户的总公司统一采购，

送货到不同的分公司或者不同的工厂、门店

收票方同 ERP 的收票方，即发票出具给谁，即接收发票的客户；可以和售达方不同

付款方同 ERP 的付款方，即销售后由谁付款

消费者最后消费产品的个人或者用户，消费者区别与经销商、店铺等，消费者不再转售产品，

为最终消费和使用产品的人员

联系人人员的一种，客户所关联的各岗位的联系人员，一个客户可以有多个联系人

员工即企业的内部员工。员工可以分配到组织结构岗位中，一个员工可以分配一个系统用

户。通过系统集成，SAP ERP HCM 模块的员工数据可以同步到 CRM 中

组织单位组织单位是 CRM 特殊的一种业务合作伙伴。CRM 组织模型中建立的组织单元可以生

成相应的业务合作伙伴，该类业务合作伙伴拥有组织单位的角色

互联网用户用于网络渠道电子商务应用中，登录网上电子商务、电子服务及电子营销系统的用户需

要使用互联网用户角色

公司渠道合作伙伴用于渠道管理中大型的渠道合作伙伴，通常可以拥有一个或者多个渠道合作伙伴

渠道合作伙伴用于渠道管理中，与企业渠道营销、渠道销售及渠道服务等业务相关的合作伙伴

合作伙伴联系人渠道合作伙伴相关的联系人

忠诚度合作伙伴参与忠诚度营销项目的合作伙伴

竞争对手与企业业务相竞争的组织或者人员

工厂企业内生产产品、提供服务的工厂

开票单位用于 CRM 开票，可以确定对应的公司代码等

16　　SAP CRM 管理与实施指南

应用举例：

实际应用中，通常尽量使用标准的角色。也可以根据实际的业务需求定义其他角色，如：

● 员工通常分成企业内部员工和企业外部的合作伙伴的员工。CRM 中提供了员工的角色，通过配置，

可以新增外部员工角色。合作伙伴员工拥有这个角色，也可以使用合作伙伴联系人标准角色。

● 供应商可以分成第三方供应商、服务供应商，除了系统提供的标准的供应商角色外，可以定义第

三方供应商和服务供应商的角色。

2.1.1.2　通过中间件进行客户数据分发

通过 CRM 中间件，客户数据可以在 CRM 和 ERP 中双向同步，详细请见 11.2.1 节

“ CRM 与后台 SAP ERP 交换数据”。也可以使用 XIF 接口实现与外部系统的集成。数据复

制时需要明确 CRM 客户数据的销售分类和 ERP 客户的账户组的映射关系（ERP 事务代码：

PIDE）。销售分类包括客户、消费者、潜在客户及竞争对手等。销售分类在 CRM 中由客户

所拥有的角色的类别确定，角色类别是对角色的基本性质分类，通常 Web UI 客户页面中并

不显示这些销售分类信息。角色类别和销售分类的映射参见表 2.2。

表 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.3　常见合作伙伴关系

关系类别用　　途

BUR001 联系人，正式客户、潜在客户及渠道合作伙伴通常拥有一个或多个联系人

BUR010 企业和员工的关系。将员工分配到组织结构岗位中，建立员工关系

BUR011 负责客户的员工，由指定的员工负责处理该客户相关的销售或服务事务


关系类别用　　途

CRMH02 送达方关系（Ship to），一个售达方可以有一个或多个送达方

CRMH03 付款方关系（Payer），一个售达方可以有一个或多个付款方

CRMH04 开票方关系（Bill to），一个售达方可以有一个或多个开票方

BUR013 客户合并时被替代的关系，即一个客户被另外一个客户替换，被替换的客户通常会被归档删除

CHM001 渠道合作伙伴内部负责员工，合作伙伴负责人

CHM002 渠道合作伙伴的送达方

CHM003 渠道合作伙伴的上级公司

CHM004 渠道合作伙伴的第三方

CRME02 经销商所管理的最终客户

应用举例：

实际应用中，尽量使用系统提供的标准关系，当然也可以根据实际的业务需求定义各种关系，

例如：

● 备件供应商：服务站的备件由关联备件供应商提供，服务站和供应商之间可以使用备件供应商关系。

● 店铺关系：某公司有多个业务合作伙伴公司客户，这些客户各拥有多个店铺，在店铺中销售相关

产品。合作伙伴和店铺的关系及可以使用店铺关系。

2.1.1.4　业务合作伙伴的层次结构

大客户往往有复杂的组织层次结构（Account Hierarchies）。业务合作伙伴层次结构（即

客户层次结构）用于映射复杂客户的层次结构关系。例如，有些客户按照总部、区域分成多

个组织单位；有些客户在多个区域中有诸多终端门店；有些业务上也会把具有相同属性的客

户组织在一起，以便进行定价、统计与管理。层次结构为树状结构，业务合作伙伴分配到层

次结构节点上。

典型的客户层次结构示例见图 2.2“客户层次结构逻辑关系说明”。

客户层次结构的主要目的有两个：

● 统计分析：可以根据层次结构对

客户进行分析。比如可以统计客

户在华南区和华北区的销量。

● 定价：比如华南区促销，给华

南区的所有客户都设置 5% 的

折扣。或者设置一定的优惠。

可以把定价的数据设置在某个

节点上，该节点及下级节点的

客户均享受相同的折扣与价格。

（续）

4321

5 6

A

图 2.2　客户层次结构逻辑关系说明


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 中可以维

护产品层次结构。产品属性集分

配到对应的产品类别上，下级层

次的产品类别继承上层产品类别

的产品类型和属性集。创建产品

时指定产品的基本类别，基本类

别确定产品类型和属性集。产品

层次类别可以用于确定定价条件，

例如将某类产品统一设定折扣。

在一些产品数量众多的业务中，

使用产品层次类别进行定价可以

降低价格数据的维护工作量。图 2.4　产品层次结构


应用举例：

● 比如某石油油品企业中，可以分为高级柴油类润滑油、高级汽油类润滑油、润滑脂、船用油等大

类，然后在大类下面设置相应的小分类，形成层次结构。

● 某汽车企业根据汽车的品牌与型号等设定层次结构，例如，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“产品属性”（路径：销售专员业务角色 > 图 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 相关”。

产品的属性通过属性集组织和维护，主要的属性集包括产品的基本数据、产品的销售数

据、物料数据和其他信息。

系统提供标准的产品基本属性，对产品进行描述和控制，基本的属性集参见表 2.4。

表 2.4　产品基本属性

属　性　集名称与用途

COMM_PR_SHTEXT 产品短描述

COMM_PR_UNIT 计量单位，注意除了基本单位外，还可以设置多个备选单位及转换比例

CRMM_PR_TAX用于确定产品的税，比如全部计税为 FULL，不计税为 NONE 等，可通过国家、税

类型、税收组、税费代码来确定税

COMM_PR_LGTEXT 长文本备注和销售备注，添加文件等附件

产品的销售数据由分销链（销售组织和分销渠道，即 ERP 中的销售视图数据）页面信

息中设定。

表 2.5　产品销售数据


CRMM_PR_SALESA

● 销售控制字段、数量字段，如销售单位、最小订购数量、发货单位

● 销售状态：锁定后销售时会提示警告信息；冻结后不能用于销售，使用时系统

会报错

● 项目类别组：用于确定事务行项目类别；以及定价参考产品、是否可享受现金

定价、交货位置等



CRMM_PR_SUCCESS用来显示来自 BW 系统中的产品转换成功概率（报价单转化成订单的概率），不

能直接修改。可以通过报表 CRM_MAINTAIN_SUCCESS_RATE 在 CRM 中修改转

换率

CRMM_PR_SALESG

销售分组信息，包括：产品组（通常用于定价）、佣金组（用于销售佣金返利）、数

量返利组（用于返利）、账户分配组（用于确定收入和销售扣减的会计账户）、销售类

别（用于部分销售业务的产品类别，如定价和贸易促进中）、产品组 1 ～产品组 5（用

于对产品进行分组）

物料数据包含物料相关的信息，如基础数据、全球贸易编号等，主要的属性集参见表 2.6。

表 2.6　物料数据


COMM_PR_MAT物料的基本数据，主要是行项目类别组（用于确定行项目类别）、部门（如果事务单

据抬头中不指定部门，行项目中的部门由产品主数据中确定）

COMM_PR_GTIN 14 位的唯一的全球贸易物料编号（GTIN），可以指定多个 GTIN 编号

CRM_PR_RESIDVL 融资相关属性。用于租赁业务中，包括残值策略、残值曲线及设备类型等

产品的其他信息包括产品的关系和状态，也是重要的信息。产品与产品、产品与客户

可以建立各种关系。比如设定一个产品的相关联的产品、关联的服务及备件等。状态用来表

示当前的处理情况以及确定后续允许操作的事务。状态分成系统状态和用户状态。系统状态

由系统提供，用来控制和规范各种处理。产品的系统状态主要有：待归档、已锁定（可以使

用）；已删除、已归档和可以归档由系统操作设定。用于状态由用户根据实际的业务需求自行

定义，可以定义一系列的用户状态。

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。

表 2.7　服务产品的主要属性

属性集名称与用途

CRMM_PR_SRVDUR 指定工作持续时间和单位，用于资源计划

CRMM_PR_SRVRR 对资源的需求

CRMM_PR_SRVENT服务合同默认值，包括服务参数文件（哪些时间可以提供此服务）和响应参数文件

（多少时间响应客户的服务请求）

SERVICEPLAN 服务计划，指定间隔模板和间隔类型

CRMM_PR_BTR事务控制字段，如项目类别组，用于确定服务事务的行项目类别。标准的服务产品

项目类别组为 SRVPCRM_SERIALNUM 服务处理中的序列号控制标识

1. 持续时间与资源需求

服务产品一般会指定执行一个服务单位的持续时间。服务计划时需要考虑服务的工作持

续时间。见图 2.7“服务产品：持续时间与

资源需求”（路径：服务专员业务角色 > 客户

& 产品 > 服务），服务的基本单位为 AU，即

为作业单位，一个作业单位的工作持续时间

为 2 个小时。在服务订单中，如果需求是 2个单位，则需要 4 个小时才能完成该服务。

在资源需求中的对象标识中，可以指定确定

服务资源的方式，即如何确定在合适的时间

执行服务的服务组织与团队。

2. 服务合同缺省值：服务参数文件以及

响应参数文件

服务产品中可以设置服务参数文件以及

响应参数文件，确定可用的服务时间以及对

服请求的响应速度，即服务级别协议（SLA），见图 2.8“服务产品：服务参数文件及响应参

数文件”（路径：服务专员业务角色 > 客户 & 产品 > 服务）。服务处理（服务合同及服务订单

图 2.7　服务产品：持续时间与资源需求


等）时，服务产品中的服务级别协议会默认填充到服务事务行项目中。服务参数文件用来表

明哪些时间可以提供此服务，如周一到周五

工作时间处理，周六周日不处理，或从周一

到周六均可以处理，可以定义每天的工作时

间。而响应参数文件用来指定接收到客户的

服务请求后，在多少时间内需要响应及完

成，比如 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 天。即接收到客

图 2.9　服务参数文件定义

图 2.12　响应参数文件：响应次数

图 2.8　服务产品：服务参数文件及响应参数文件


户的服务请求时，系统将首次响应时间设置为服务请求时间 +6 个小时，将预计服务处理结

束时间设置为服务请求时间 +6 天。服务处理时，系统会自动根据规则计算相关时间类型的数值。

2.1.2.3　质保

质保（Warranty，也称担保）是一种产品主数据，用来管理企业所提供的产品或者服务

的质量保证和承诺，承诺在一定的期限和条件下，所提供的产品或者服务发生问题时可以根

据一定的条件维修或更换（如免费维修和更换）。质保期范围内，客户通常无需为维修和更换

付费。日常业务中，所购买的产品多包含质保清单和说明，质保清单中规定了质保期限和范

围，以及免责条款。通常规定在一定的使用条件下，所质保的时间长度或使用次数等，以及

质保的部件范围。质保期内的相关维修一般免费，如果出现质量问题，甚至可以免费更换或

退货等。质保的计算方式可以是基于时间、基于某计数器或者同时基于时间或计数器。最常

见的质保是我国规定的零售商业企业的质量三包法，规定销售后，在一定期限内，卖家或厂

商负责“包修、包换及包退”，属于一种商品信用保证办法。如果在质保期发现问题，客户

可以进行申索，获取免费维修、更换甚至退货。对于因用户使用、保管不当等不属于产品质

量问题通常并不在三包范围之内。

应用举例：

● 基础质保：对企业所提供的产品提供一年的基础质保，规定在质保范围内，可以免费更换和维修。

但规定某些易耗件不在质保范围内，或者易耗件的质保时间较短，例如两个月。多数的电子类产

品（计算机、相机、家用电器等）均为一年基础质保。

● 升级质保（2 年）：客户在购买产品时，可以选择为期两年的升级质保，比普通的基础质保长一年，

通常客户需要额外支付一些费用。按时间和里程的质保：某汽车生产企业提供的汽车为两年或者

六万公里质保，即两年内或者行驶六万公里，先到为准。这种质保和某个计数相关。

1. 质保基本属性

质保产品的主要属性集参见表 2.8。

表 2.8　质保产品的主要属性集


CRMM_PRWTY包含质保通用的基础信息，如质保类型（客户质保与供应商质保）、质保基础（基于时间、

计数器或者两者），基于时间的质保的日期确定；会计标识用于定价和成本控制集成分配

CRMM_PRWTY_CAT质保类别数据，指定质保所覆盖的投诉、损坏和缺陷类别。可以指定一系列的代码，确定

质保范围

CRMM_PRWTY_SRV 质保的服务数据，指定质保所覆盖或者部分覆盖的服务、服务备件及特殊主题原因（Subject）CRMM_PRWTY_CNT 质保计数器数据，指定计数器类型、限值等

● 质保类型：质保分成客户质保和供应商质保。见图 2.13“质保（1）”（路径：服务专

员业务角色 > 客户 & 产品 > 担保），为一年基础质保，类型中可以选择供应商担保或

者客户担保。供应商担保，即销售该产品的企业仅是销售商，最终质保由该产品的

供应商为客户提供质量保证。发生质保问题后，可由销售商向供应商索赔。客户质


保，即销售货物的企业对所销售的产品直接提供质量保证。在供应商质保索赔业务处

理中，系统可以为带有效的供应

商质保的产品产生供应商质保索

赔申请，该申请传输到供应商中，

供应商审核该索赔，详见 5.2.7 节

“质保与索赔管理”。

● 质保基础：即定义质保的计数分

类，可选择时间相关、计数器相关

或者时间与计数器相关。如果质保

仅与时间相关，即为时间相关。如

果质保与设备的运行次数、小时、公里数等计数相关，可以选择计数器相关，然后根据

计数器读数确定是否在质保期内；通过选择时间和计数器相关即时间与计数器共同决定

质保期，如两年或六万公里整车质保。

● 质保的时间有效期和日期计算规则：质保在多少时间内有效及如何计算质保的开始和

结束日期，比如定义设备安装日起一年内质保。可以使用日期规则灵活计算质保的有

效期，比如是开始日期加上质保期，系统计算出质保结束日期。

● 会计标识：通过会计标识，质保可以参与并影响定价及影响成本分配。例如设置为基

础质保 100% 免费，某些质保折扣为 50%，质保外折扣为零即需要 100% 收费等。

● 服务限制：见图 2.14“质保（2）”（路径同上图）规定质保范围和规则，规定质保所覆

盖的服务、服务备件及条件。担

保服务类型可以选择具体的（服

务）产品、产品组，或者指定项目

类别（订单的行项目类别，例如投

诉、服务、维修等）或者项目对象

类型。同时可以设定是包含或者排

除，即包含这个服务或者排除这个

服务。

● 代码限制：确定质保范围，例如哪

些损坏在质保范围内，哪些损坏不在质保范围内，通常人为损坏不在质保范围内。在

进行维修服务时指定此次维修的具体原因代码，然后核对单据所关联的质保数据，检

查该原因代码是否在质保范围之内。见图 2.14“质保（2）”，目录中可以选择系统中

定义的原因、故障目录树，然后选择具体代码组中的具体代码。模式中可以选择排除

或包含。注意这里只能同时选择排除或者包含模式，即如果使用排除，此表格中所有

代码都为排除，如果选择包含关系，此表格所有代码都为包含。

● 计数器：对于与计数器相关的质保，可以设置计数器读数及质保读数。见图 2.14“质

保（2）”设置复印机质保为 5000 份复印件，对于汽车，可以设置质保为 6 万公里。

● 质保附件：质保中指定使用的各种附件，如文本、表格、图形及链接等。

图 2.13　质保（1）

图 2.14　质保（2）


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.9　销售产品包的组件类型及用途

类　　型用　　途

核心产品企业提供的有形的核心产品，例如某种配置的设备。该设备是提供后续服务的关键产品

资费计划资费计划（Rate Plan）是服务提供商的核心业务，为客户在一定时间内提供服务，通常

按月结算费用或客户需要预付款获取资费计划中的服务

激励产品激励产品（Incentive）通常是可选组件，通常为客户提供最新的高级设备，并且以优惠

的价格提供，如可优惠购买的专供智能机

使能产品

使能产品（Enabling）可以是一种有形的实物或服务，可以是可选组件或必选组件。使

能产品通常不是企业的核心业务，但通常与资费计划捆绑销售，作为一种特殊的优势。例

如安装服务、激活服务、移动服务中的专供智能手机，网上书城所提供的电子阅读器等

服务可以包含一次性或者周期性重复性的服务，例如安装服务及定期维护

一次性费用或折扣如激活或取消时一次性收取的费用，通常在购买或终止服务时收取

其他产品包销售产品包可以包含其他产品包

使用业务规则，可以随时根据规则确定产品包中可以使用的组件，以及确定不同的价

格。销售产品包中的不同子行项目可以由后续不同类型的事务实现相关功能。例如：激励产

品和使能产品通常是一次性产品，后续直接通过销售订单发货；安装服务通过服务订单执行；

定期的维护服务通过服务合同或服务计划执行；核心产品通过销售发货提供，而资费计划可

以通过合同提供服务。

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“组织单元”（路径：销售专员业务角色 >销售运行 > 组织模型 > 基础信息）。

图 2.18　组织结构


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 员工，可

以使用业务合作伙伴功能维护更多信息，使用更为灵活。

组织单元可以承担不同的业务功能，即销售组织单元、服务组织单元和市场营销组织单

图 2.19　组织单元


元。在巴西和韩国等地，为了税务的需要，还有业务地点（Business Places）功能。在销售组

织单元中可以指定映射到 ERP 的销售组织、销售办事处和销售组，用于销售业务中。在服务

组织单元中，可以映射 ERP 的计划工厂，同时需要标识为服务组织，用于服务计划和服务执

行等服务业务中。在市场营销组织中，选择营销组织后该组织单元即可成为营销组织，以便能

够在营销计划和营销活动等营销业务对象中使用。在组织模型中可维护组织单元的业务功能。

2. 组织单元属性

CRM 组织结构中的组织单元和岗位可以有很多属性，系统也提供诸多标准属性。用户

可以根据实际的业务需求灵活定义各种自定义属性，以便对组织单元和岗位进行分类和描

述。组织数据确定、工作流中的岗位确定及权限管理均可以使用组织单元或岗位的属性。需

要用于组织数据确定的组织单元，需要标识为“在确定中已允许的对象”，即允许该组织单

元在组织数据确定中使用。CRM 提供了一些常用属性，其中部分属性在流程中有着重要的

作用。常用属性见表 2.10。

表 2.10　组织单元及属性

属　　性用　　途

分销渠道指定允许使用的分销渠道

产品组允许使用的产品组（即部门，Division）分销渠道和产品组组合分销渠道和产品组的组合

参考货币单据中使用的默认货币，创建事务凭证时，系统根据组织单位确定凭证的基本货币

国家和地区国家、地区、省份

销售地区负责的销售地区（Districts）合作伙伴编号可以设置所管辖的客户编号或范围

产品类别、产品设定负责的产品类别或产品

应用举例：

● 将岗位分成座席经理、一线座席、二线座席、英语座席、管理组等。

● 将营销的岗位分成日常管理员、市场人员、协议维护员、费用管理员、信用管理员、销售副经理

及销售经理等。

3. 组织结构的增强模式和普通模式

根据与后台 ERP 系统集成的方式不同，CRM 的组织结构有两种版本，即普通后台集成

版本和增强后台集成版本。标准系统使用普通后台集成版本。在该版本中，一个销售组织、

销售办事处和销售组均对应一个 CRM 组织单元，即一个 ERP 销售组织、销售办事处、销售

组只能分配给一个组织单元，下级组织单元继承上级组织的销售组织。

但是在 ERP 中，一个销售组可以分配给多个销售办事处。在这种情况下，需要使用增

强后台集成版本。增强模式中，销售办公室和销售组成为组织单元的表格属性，即一个组织

单元属性中可以维护多个销售办公室和销售组，而在普通版本中，一个组织单元只能指定一

个销售办事处或销售组。


2.1.3.2　组织数据确定

维护事务数据时，系统根据业务场景或单据类型、客户及用户等各种背景信息，自动确

定所用的组织数据（销售组织、服务组织、营销组织、分销渠道及产品组等）。如果找到多个

满足条件的组织单元，系统就弹出对话框供用户选择；如果能够唯一确定，系统就直接采用。

如果系统无法自动确定或者系统未设置自动确定，就需要手工指定对应的组织结构数据。可

以在各种业务流程中使用组织结构确定功能，例如：销售类业务（销售订单、报价单、商机

等），服务类业务（服务报价单、服务订单、服务确认等），市场营销活动中。

组织数据在销售和服务业务处理中常常是必要信息，组织结构是处理单据的负责组织，

起着关键的作用。比如销售单据中，销售组织、分销渠道、产品组一般都是必要信息，因为

这些信息与定价等功能有着直接的关系，并且订单复制到 ERP 时，必须指定订单的销售范围

（销售组织＋分销渠道＋产品组）。在服务单据中，服务组织是必需的，表示该服务是由哪个

服务组织负责处理或者在这个服务组织范围内的。

组织数据的确定有以下两种方式：

● 通过组织模型确定组织数据：即通过评估组织模型中各组织单元的属性确定满足条件

的组织单元。维护事务时，根据事务维护人员、事务凭证信息以及客户、产品等信

息，系统将一些用于评估的信息传递给组织数据确定规则，由组织确定规则评估组织

模型中的各组织单元，找到满足条件的组织单元。组织确定规则中指定需要用于评估

组织模型的字段，例如客户编号、事务类型、邮政编码等信息，规则程序即使用这些

属性搜索组织中所有满足条件的组织单元。因此需要维护相关组织单元的属性，如果

组织结构比较庞大，遍历搜索组织单元需要一些处理时间，因此性能比按负责区域直

接指定组织单元的方式要差一些。但这通常是最常用的组织数据确定方式，如果能够

维护需要确定的组织单元属性即可使用。

● 通过负责区域（Responsibility）确定组织数据：即通过预先定义的规则直接确定负责

区域的组织单元，比如客户编号从范围 1 到范围 2 的客户，由销售办公室 A 负责；国

家为阿根廷的事务由南美服务部门负责。在规则维护上，指定规则后，直接指定负责

的组织单元。因此确定组织数据时，系统无需遍历整个组织模型中的所有组织单元，

也无需为组织单元设定查询属性。创建事务时，自动自动根据客户、产品、用户及事

务等信息，评估负责区域的规则，直接使用该规则指定的组织单元。因此性能通常好

于按组织模型确定组织数据的方

式。该模式适合于组织单元众多

但所维护的属性较少或者未维护

的情况。

见图 2.20“服务订单中的组织数

据”（路径：服务专员业务角色 > 服务订

单 > 组织数据），列出了该服务订单中的

销售组织与服务组织。系统可以根据组

织数据确定规则自动确定组织单位，也图 2.20　服务订单中的组织数据


可以由用户手工选择或录入（即可以设置为不自动确定组织数据）。如果该事务类型分配了服

务方案的组织参数文件，则可以使用服务组织数据；如果分配了销售方案的组织参数文件，

则可以使用销售组织数据。如果该事务类型未分配组织数据确定参数文件，则无法维护组织数据。

在事务维护中，销售组织单位或服务组织单位由确定规则确定，用户可以在规则确定的

组织单位结果清单中选择。确定或选择组织单位以后，系统读取该组织单位的属性，如关联

的销售组织、服务组织，以及分销渠道、产品组、销售办事处和销售组。例如某个销售组织

分配了分销渠道 01 和分销渠道 02，则对于该销售组织，用户只能选择 01 或 02 分销渠道。

如果用户直接录入组织数据，系统检查这些属性的组合是否在组织模型中维护，即检查组合

是否有效。组织数据维护完成后，修改客户等相关数据后，系统不再重新确定组织数据，但

用户可以手工重新选择满足条件的组织数据。

1. 组织数据参数文件

组织数据参数文件用来控制单据的组织数据确定及设置。组织数据确定可以应用于销售

和服务业务场景（方案）中，同一个参数文

件可以同时用在销售方案和服务方案中。确

认规则可以是组织模型确定规则或基于责任

区域的确定规则，通常仅使用其中之一。例

如图 2.21“组织结构参数文件”（路径：配

置 >CRM> 主数据 > 组织管理 > 组织数据确

定 > 更改规则和参数文件 > 维护组织数据

参数文件 > 明细）该组织结构参数文件使

用了组织模型确定规则 10000280（客户邮

编确定）。该参数文件中，将销售组织、分

销渠道设置为必填。如果在确认规则中填

写责任确定规则，即按照定义的责任规则

确定。

2. 按组织模型确定规则

即根据客户、用户、产品及事务等相

关信息评估组织模型中组织单元的属性，

找到符合条件的组织单元的一段程序。见图 2.22“组织结构确定规则”（路径：配

置 >CRM> 主数据 > 组织管理 > 组织数据

确定 > 更改规则和参数文件 > 维护确定规

则，或事务代码 PFAC），系统显示了组织

数据确定规则 10000280 类别为组织模型

确定，用于销售方案中。该规则使用了客

图 2.21　组织结构参数文件

图 2.22　组织结构确定规则


户的邮政编码作为确定属性，即维护事务时需要录入客户，然后系统将该客户地址中的邮政

编码传递给规则函数，规则函数搜索组织模型，逐个比较组织单元的属性，将属性满足该客

户邮政编码的组织单元均列出来。函数模块中指定搜索组织模型的 ABAP 程序函数，这里

为 CRM_ORGMAN_ORGOBJECTS_FIND_1。该函数可以自行定义，其使用容器中规定的属

性，匹配和搜索满足条件的组织单元。当然在程序中可以根据其他条件过滤组织模型的评估

结果。系统提供诸多标准的组织数据确定规则和函数。用户可以根据实际业务需求，复制系

统标准的组织数据确定函数，进行修改，如增加过滤条件等，只要保持输入与输出等参数结

构一致即可在组织规则中使用。

见图 2.23“组织结构确定规则：容器”（路径同上图 > 容器），容器中规定了用于评估组

织模型的属性。如这里使用了邮政编码字段，该

字段属性的具体来源数据表 ADRC 的字段 POST_CODE1，即事务中录入的客户的标准地址中的邮

政编码。创建订单时，系统读取所录入的客户数

据中的邮政编码，然后根据确定规则函数到组织

模型中搜索，列出组织单元属性中满足这个邮政

编码的组织单元。确定组织单元后，系统列出该

组织单元所关联的销售组织和分销渠道和产品组等属性，列出销售范围及其他属性，供用户

选择。

3. 按责任区域确定组织数据

按责任确定组织数据，需要在组织结构参数文件的规则中指定责任规则。责任规则的类

别为按责任确定，根据规则直接确定满足条件的组

织单元，无需评估组织模型。见图 2.24“为责任规则

分配负责组织”（路径：配置 >CRM> 主数据 > 组织管

理 > 组织数据确定 > 更改规则和参数文件 > 维护确

定规则），这里使用的规则为 10000157，即直接根据

合作伙伴编号确定组织数据，类别为“代理确定：

责任”。在容器中选择责任规则所用的属性，例如客

户地址、产品及事务等信息字段，这里选择了合作

伙伴编号为确定属性。在职责中，可以查看和分配

该规则对应的组织单元，即哪些编号范围的客户数

据由哪个组织单元负责。如果容器中选择客户所在

的国家，则可以根据国家直接确定组织单元（职责

中指定）。

图中定义责任组织规则后，可以为该规则创建

一个或多个职责范围（Responsibility）。每个职责根据容器中规定的属性界定范围。例如这里

容器中使用了客户编号范围，可以将编号为 1 到 10000 的客户设置为职责范围 1，而 10001

图 2.23　组织结构确定规则：容器

图 2.24　为责任规则分配负责组织


到 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。

表 2.11　对象的基本信息

属　　性用途说明

类别指定基础类别和其他产品类别，决定对象族和能使用的属性集

描述和计量单位对象的描述，设定计量单位

ERP 标识信息

属性集为 COM_TA_R3_ID，即设备明细信息，包括技术资产编号（ERP 设备编号）、技术资产类别（设备类别 Category）、技术资产类型（设备编号的对象类型 Object Type）、物料、序列号及批次等。SAP ERP CS/PM（客户服务 / 工厂设备管理）中的设备，可以同步到 SAP CRM中，CRM 中使用安装点和对象存储设备，因为一个设备还可能有下级子设备，所以系统使用安装点组织设置的层次结构关系

制造信息

属性集为 COM_TA_MANUFAC，记录对象的制造信息，主要包括：生产商、产地国家、产地地区、型号（Model）、厂商物料号、厂商序列号以及生产日期。SAP ERP 中的序列号（ERP SD 模块中的序列号）可以同步到 SAP CRM 中，CRM 中即为对象。即 ERP 中的一个序列号对应 CRM 中的一个对象。通常从 ERP 复制设备数据后填充

资产会计参考属性集为 CRM_ANLA_REF，用于租赁业务中，记录产品的资产会计信息，如公司代码、

ERP 资产编号等。直接录入记录，不从 ERP 中复制

业务数据

属性集为 COM_COMMERCIAL，包括采购地点、采购日期及时区等。记录对象的采购信息，如在互联网客户自助服务的产品注册中，用户可以自己填写。这些信息通常是计算质保开始和结束日期的依据。可以使用状态标识对象的当前状态和变化，如初始状态、已创建、可销售及已销售等

销售信息同产品主数据，对象中可以使用分销链数据（销售组织 - 渠道下维护的数据），即属性集

CRMM_PR_SALESA 和 CRMM_PR_SALESG

对象配置信息如果为对象分配一个参考的可配置产品，对象即可使用该参考产品的产品配置，选择相应的

配置，保存后成为该对象的配置变式

图 2.25　对象


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.12　安装点的常用功能

功　能　点功能描述

安装点维护

● 编辑和查看安装点的完整结构，展开可以查看各组件信息即组件的关联信息。可以在一

个页面中并排显示两个安装点，便于安装点的比较，同时可以复制并粘贴安装点组件。

可以显示安装点的历史版本，选择过去的日期，系统会显示对应的历史版本。

● 显示安装点中的缺口（Gap）位置。缺口是将已有的组件移除但保留原有信息，后续可以

往缺口中安装相同或者不同的组件，在未重新安装之前即为缺口。

● 跟踪对安装点的变更信息：字段的更改历史，组件变化历史（组件变化时系统会带有时

间戳，因此可以查看之前的版本）。

● 为安装点或者组件分配地址、组织和合作伙伴。通过系统配置，下层组件可以继承上层

组件的地址与合作伙伴信息。“相关方”中可以维护不同功能的伙伴，例如售达方、送

达方、供应商等。其中供应商合作伙伴功能为该组件的供应方，在发生供应商质保索赔

时，确定质保索赔单的供应商。

● 状态管理：如设置为不激活，不再提供服务；可以设置删除和归档状态。

● 使用组件搜索安装点：使用组件信息搜索安装点，比如搜索某个产品或者对象在哪个安

装点中使用过。

● 为安装点组件分配计数器：可以为安装点组件分配一个或者多个计数器，记录各种数值。

● 为安装点和组件分配质保，可以分配多个质保，设置质保的开始和结束日期。

● 为安装点组件分配资格要求，即后续工程师对此组件提供服务时所需的资格。

安装点的服务处理

安装点通常是服务处理中的基础信息，确定服务的具体对象。服务处理（服务报价单、服务

订单、服务确认、服务请求等业务单据）中，可以指定安装点或者安装点组件作为参考对象。

如果启动了服务合同确定功能，系统会自动搜索该安装点所关联的有效的服务合同，并将合同

信息应用到服务处理中

服务合同的对象清单中可以指定一个或者多个安装点或者安装点组件，界定服务合同的服务

对象范围

权限管理安装点通用信息中可以维护一个权限组，可以通过权限组 CRM_IBASE 管理安装点权限，设

定安装点以及安装点类别进行权限管理。实际应用中，可以使用 ACE 管理对象和安装点的权限

事实表

事实表的数据可以来自多种数据源，如 BW 系统、CRM 系统，形成安装点的关键的概览信

息。系统提供了一些事实表的信息块，包括安装点的详细基础信息、合作伙伴、计数器、质

保、未清服务项目、服务合同及最近关闭的服务订单。通过组件工作台事务代码 BSP_WD_CMPWB 可以对安装点的组件 IBFACTSHEET 进行增强和页面配置

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.27　计数器


能再次修改，但可以取消录入的读数。可以重新激活已取消的读数，重新变成未取消的正常

状态。读数历史中显示计数器相关的所有读数历史记录。

图 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。

2.2　SAP CRM 基础功能本节介绍 SAP CRM 的一些基础的通用功能，主要包括合作伙伴处理、业务事务处理、

定价与条件技术、日期管理、CRM 的操作管理、文本管理及调查问卷管理等。这些功能在

销售、服务及营销等各种业务流程中均被广泛使用，具有很强的通用性。

2.2.1　合作伙伴处理业务处理中，通常有多种类型的合作伙伴参与各类业务，并承担着不同的功能，如负责

员工、销售经理、潜在客户及联系人等。合作伙伴处理指确定事务处理中可用的合作伙伴职

责功能、确定参与的合作伙伴以及设定对合作伙伴的控制。

1. 合作伙伴功能

合作伙伴功能用于描述参与事务的业务合作伙伴所承担的功能角色。例如售达方、送达

方、开票方、收票方、负责员工、联系人、销售经理及渠道合作伙伴等都可以是合作伙伴功

能。系统提供诸多标准的合作伙伴功能，可以根据业务需求通过配置自行定义。合作伙伴功

能有一个编号、描述、缩写，选择功能类别，比如员工类或联系人类等。


合作伙伴功能类别用来指定合作伙伴功能的分类和性质，由系统程序代码中固定，如售

达方、送达方及服务接受方、活动伙伴及员工等。在定义合作伙伴功能时可以指定一个关系

类别，该类别可以用与合作伙伴确定。例如销售经理和负责员工都属于员工类别，而潜在客

户和活动合作伙伴（Activity Partner）均属于活动合作伙伴。

见图 2.31“商机中的合作伙伴功能”（路径：销售专员业务角色 > 销售周期 > 商机），列

出了商机中的业务合作伙伴功能，其中联系人、销售小组及相关方都属于合作伙伴功能，比

如这里列出了销售代表、负责人及活动伙伴（潜在客户）。销售代表和负责人通常创建商机时

根据一定的规则自动确定。

图 2.31　商机中的合作伙伴功能

在合作伙伴主数据中，可以设置该合作伙伴不能使用的合作伙伴功能（即被排除的合作

伙伴功能）。例如某个合作伙伴不能作为开票方和收票方，因为其只能作为售达方使用；竞

争对手不能作为售达方等。在事务维护中，指定合作伙伴时，系统检查该合作伙伴是否可以

用在该合作伙伴功能上，如果不能使用，则可以提示错误信息，阻止事务的开展。

2. 合作伙伴的自动确定

在事务处理中，系统可以根据系统中所定义的业务规则自动确定合作伙伴。合作伙伴确

定中可以使用多种来源的信息，如合作伙伴主数据、组织结构数据及相关业务背景信息，如

事务类型等。例如创建销售订单时，用户录入售达方，系统即自动读取该售达方的主数据及

关系数据确定该售达方相关的送达方、开票方、联系人及负责员工等合作伙伴。

合伙人确定过程：合作伙伴确定过程中包含了一个或者多个合作伙伴功能以及对每个

合作伙伴功能的确定设置和控制，例如图 2.32“合作伙伴确定过程”（路径：配置 >CRM>基本功能 > 基本功能 > 合作伙伴处理 > 定义合伙人确认过程），这是标准的销售订单中

的合作伙伴确定过程，包括的合作伙伴功能有售达方、收货方、收票方、付款方及负责员工。

图 2.32　合作伙伴确定过程


合作伙伴确定过程中的主要设置和控制功能有：

● 全局设置：该确定过程是否不启用自动确定功能，即“冻结确定”，冻结后系统不执

行自动确定的程序；是否记录合作伙伴确定过程的日志；允许使用仅在合作伙伴确定

过程中指定的合作伙伴功能，还是可以使用系统中所有的合作伙伴功能。这些全局配

置在合作伙伴过程的抬头中设置。

● 在“程序中的合作伙伴功能”中，选择可用的合作伙伴功能，可以选择能在事务中使

用的合作伙伴功能。

● 最大最小数量：可以设置合作伙伴功能的最大最小值，即对该合作伙伴功能，最大或

最小可以录入多少个合作伙伴。如果最小值设置为 1，则该合作伙伴必须填写。

● 是否可以更改：即确定或录入后，是否可以将该合作伙伴修改成其他合作伙伴。

● 可变地址：事务处理中，是否可以修改该合作伙伴的地址。例如在销售订单中，通常

可以在订单中修改送达方的地址（即默认从送达方主数据中获取送货地址信息，如果

需要，可以在订单中修改，成为订单特定的合作伙伴功能地址）。

● 日历：是否将此事务放置到该合作伙伴的日历中，通常用于业务活动处理中。

● 存取顺序：系统根据什么规则确定合作伙伴。

● 确认时间：系统什么时候触发自动确定合作伙伴的功能。

● 用户程序：指定该合作伙伴程序所使用的事务类别和行项目类别，例如用于销售、服

务合同等业务中。

● 界面设置：可以设置显示合作伙伴的字符串顺序，例如编号和地址顺序。

合作伙伴确定过程可以分配给订单类凭证抬头，即事务类型，也可以分配给凭证的行项

目。合作伙伴确定也可以分配到营销对象及产品类别等业务中，以便在营销计划、营销项

目、对象和产品中使用合作伙伴功能。

见图 2.33“合作伙伴功能确定设置”（路

径：配置 >CRM> 基本功能 > 合作伙伴处理 >定义合伙人确认过程 > 功能明细），设置售达

方功能的控制参数，即录入后，不可更改，必

须填写或确定售达方，可以修改地址，使用

了 0001 先前凭证作为存取顺序，确认时间为经常。

合作伙伴确定存取顺序：通过存取顺序为

系统确定合作伙伴的顺序和策略，即在事务凭

证中，根据何种数据源（前序凭证、合作伙

伴、组织数据、用户及岗位等数据）自动寻找

并确定满足条件的业务合作伙伴。如果多个合

作伙伴满足条件，系统会列出供选择。见图 2.34“合作伙伴功能的存取顺序”（路径：配图 2.33　合作伙伴功能确定设置


置 >CRM> 基本功能 > 基本功能 > 合作伙伴处理 > 定义合伙人确认过程 > 功能明细），0001的存取顺序，该存取顺序包含两个存取

10 与 20，系统先根据访问数序 10 从数

据源先前凭证的活动合作伙伴中读取，

如果未找到，系统就存取 20 中查找。这

里的数据源为 COM_PARTNER_A 即先

前凭证，系统从先前凭证中读取指定合

作伙伴功能的数据，然后复制到目标合

作伙伴功能（售达方）中。数据源即指定

系统如何寻找合作伙伴的具体规则。系

统提供了合作伙伴确定的数据源，并且

可以通过 BADI 自定义数据源。

在线索及商机等事务中，可以使用重新确定合作伙伴的功能。例如当用于确定合作伙

伴的数据已经修改，这是可以重新手工触发合作伙伴确定的功能。在事务抬头工具栏中，可

以点击重新确定合作伙伴，系统即重新运行合作伙伴确定过程确定满足条件的合作伙伴。可

以选择添加新合作伙伴、替换已存在的合作伙伴。添加新合作伙伴时，系统保留已确定或已

录入的合作伙伴。替换已存在的合作伙伴即清除已确定或录入的合作伙伴，重新确定合作伙

伴。在商机的购买中心中，合作伙伴的类别为联系人，重新确定购买中心的合作伙伴时，新

增联系人的属性为空，需要设置属性如影响程度以及和其他联系人的关系；替换已有联系人

后，系统先删除原有联系人，然后使用新联系人，但原有联系人的属性和关系将被删除。

推荐可替换的合作伙伴：即在事务中可以手工选择其他满足条件的合作伙伴。例如，客

户有两个联系人，在凭证中已经确定并选择其中一个，但后来需要修改成另外一个联系人，

即可以使用推荐功能，系统列出两个联系人供重新选择。

3. 合作伙伴相关的其他功能

● 合作伙伴处理与合作伙伴主数据：合作伙伴主数据是合作伙伴处理的重要数据，其中

合作伙伴主数据的关系尤为重要。关系分成两类，一类是通用的关系，与销售范围无

关；一类是销售范围相关的，设置在具体的销售范围中，该关系仅对设定的销售范围

相关（在合作伙伴关系维护中，选择用法，然后在用法中选择销售范围并选择该销售

范围下的合作伙伴功能）。在合作伙伴确定过程中这两种类型的客户关系均可以使用。

● 维护组织模型时，系统为组织单元生成合作伙伴数据，拥有组织单元的角色，可以应

用到合作伙伴处理中使用。如在跨公司开票中，组织单元本身可以作为开票方。系

统使用组织数据确定的规则确定组织单元所对应的合作伙伴，使用的数据源为 CRM_PARTNER_B（根据组织数据确定合作伙伴），需要指定组织结构确定规则。

● 合作伙伴团队：合作伙伴团队是与特定的商机相关的一组客户或者人员。在商机中称

为购买中心，购买中心中的成员均为联系人，合作伙伴功能类别为联系人，承担一定

的功能，具有一定的关系，对项目的影响和重要程度也不尽相同。更多关于购买中心

的功能可以参考 4.2.4.2 节的“购买中心”部分。

图 2.34　合作伙伴功能的存取顺序


合作伙伴处理的基本配置路径为：配置 >CRM> 基本功能 > 合作伙伴处理，可以定义合

作伙伴功能、存取顺序及合作伙伴确定过程等。

技术指南：

● 线索和商机等事务中使用合作伙伴重新确定功能时，需要：启用 BADI ES_CRM_PARTNER_REDETERMIN 的实施 ES_CRM_SET_ACTIVE ；在系统用户参数中，需要将参数 CRM_REDETERMINATION 设置为 X（事务代码 SU3），事务对象必须维护在表格 COMS_PARTNER_DET中，例如线索、商机、申索（Claim）及预付款申请。在合作伙伴功能定义中，可以设置是否冻结重

新确定，如果选择冻结，则该合作伙伴功能确定或录入后，不会被重新确定（路径：配置 >CRM>基本功能 > 合作伙伴处理 > 定义合伙人功能）。

● 合作伙伴确定的关键函数为 COM_PARTNER_DETERM_STEP_ONE_OW，从中可以了解合作伙

伴确定过程逻辑。合作伙伴确定数据源 COM_PARTNER_A（先前凭证）、COM_PARTNER_B（分

配到用户的合作伙伴）以及 COM_PARTNER_C（当前合作伙伴 _C）等通过参数配置实现，即

在存取过程中使用这些来源时可以指定一些参数，例如使用的源合作伙伴功能和功能类别，由

COM_PARTNER_DETERM_STEP_ONE_OW 中直接获取。来源 COM_PARTNER_X、COM_PARTNER_Y、COM_PARTNER_Z 由 BADI COM_PARTNER_BADI 实现；其他来源通常通过增

强 BADI COM_PARTNER_DETERM 自行定义。系统使用该业务增强实现了诸多合作伙伴确定逻

辑，可以根据实际情况灵活采用。例如来源 CRM_PARTNER_C 使用的合作伙伴中通用的关系，

而 CRM_PARTNER_A 使用了合作伙伴的销售范围相关的关系。

● SAP CRM 和 SAP ERP 在合作伙伴处理各有特点，并且通常需要做一定的映射关系，以便能正确

的交换客户及订单等数据。ERP 中，员工、客户和供应商属于不同类型的合作伙伴，需要在不同

的应用中维护，使用不同的数据表；而 CRM 中的合作伙伴使用相同的数据表，通过角色区分，

只需维护一次即可以在多个应用中使用。ERP 中使用账户组，而 CRM 通过角色确定分类；ERP和 CRM 交换客户数据时，需要在 ERP 事务代码 PIDE 中进行映射；CRM 中使用搜索策略搜索和

确定合作伙伴，而 ERP 确定数据来源较少，通常使用客户主数据、用户、客户层次结构、T024P及用户出口进行确认，而 CRM 中可以使用合作伙伴、合作伙伴关系、前序凭证、事务中已有的

合作伙伴、组织结构、定价层次结构、用户及 BADI 等多种方式确定合作伙伴。

2.2.2　业务事务处理CRM 中的诸多业务和功能均以事务为基础。事务通常是构成业务流程的基础。本节首

先介绍业务处理的基本结构和功能，然后介绍业务处理中的状态管理功能。

2.2.2.1　基本结构和功能

业务事务（Business Transaction）是与客户交互的核心对象，对客户开展的营销、销售及

服务业务均可以通过事务凭证体现。事务代表着与客户在一定时间之内的各种业务交互，记

录相关信息与结果。在营销管理中，线索也属于业务事务；在销售业务中，报价单、销售订

单、销售合同、销售协议及商机等都为业务事务；在服务管理中，服务合同、服务请求、服

务订单、投诉、退货、服务确认等都为业务事务。

业务事务具有相同的框架结构，具有相类似的基础功能和数据确定方式。业务事务通常


由抬头和行项目组成，事务的抬头由事务类型进行标识和控制，而行项目由行项目类别进行

标识和控制。抬头信息对整个事务起作用，如事务类型、创建时间及人员、抬头合作伙伴、

状态、组织及抬头日期等信息。行项目由产品组成，可以进一步设置行项目的分类、状态及

合作伙伴等信息。业务活动和线索通常没有行项目。在业务事务配置上，主要需要考虑事务

类型、业务事务类别、行项目类别及行项目对象类型。

1. 事务处理的基本功能

业务事务基于统一的框架和结构，具有一致的处理规范和方法。业务事务中集成了其他

多种基础功能，如定价、合作伙伴确定、日期确定、文本确定及操作确定等。事务处理的基

本功能点参见表 2.13。

表 2.13　事务处理的基本功能点


维护产品事务中通常可以录入产品编号创建行项目；通过设置也可以录入产品描述，系统自动搜索满

足条件的产品编号

确定应用参数

根据系统对事务类型的参数配置，确定一些可用信息并设定控制方式，主要有：

● 确定可用的文本类型以及文本确定方式

● 确定可用的状态及对状态的控制方式

● 确定可用的合作伙伴功能及对合作伙伴功能的控制

● 确定可用的日期类型和对日期的控制

● 确定可用的操作以及对操作的控制

● 确定组织数据和对组织数据的控制

● 确定审批过程

权限检查可以从多种层级对事务的操作进行权限检查。请参考 11.3 节“SAP CRM 权限管理”

状态管理可以使用系统状态和灵活定义各种用户状态。参考 2.2.2.2 节“状态管理”

不完整性检查定义事务中所必须填写的数据，这些数据填写后，凭证才完整。如果未填写，根据设置，系

统可产生警告或错误信息

审批定义和确定事务的审批流程

后续事务

通过事务类型和事务类型的复制控制，一个事务往往可以创建后续相关类型的事务，如从线

索创建商机，从商机创建报价单，从报价单创建后续订单等。创建事务时，相关信息可以复制

到后续事务中。通过“后续事务”创建新事务凭证，新凭证和所参考创建的原有凭证之间有前

后的事务关系，可以在凭证流中查看。根据事务类型配置中指定的对象关系参数文件（Object Relationship Profile），可以定义可以进行后续分配的对象，即两个凭证均已创建，后续手工关联

起来，关联后能够在凭证流中查看，但是前后凭证并没有实质的前后事务关联，后续凭证的相

关信息不会反馈到前序凭证中，因此建议慎用。如后续订单通常会更新前序报价单的状态和数

量，在后关联中就不会更新

复制事务简化操作，从已有的一个事务凭证复制为另外一个同事务类型的凭证。信息会被复制到新凭

证中，但两凭证之间并没有连接关系

更改历史记录事务的抬头及行项目的变更，记录到各字段、时间、更改人、更改前后的数值等。可以

在事务凭证的更改历史页面中查看

数据结构增强通过 EEW 和 AET 等工具对事务进行增强，增加自定义字段或者表

事务处理的增强

和修改可以通过事件（Events）和业务增强 BADI 对事务处理进行增强和修改，满足各种业务需求


2. 事务类型和业务事务类别

事务类型（Transaction Type），也称为交易类型或业务类型，用于确定业务事务的性质以

及相关的事务确定与处理，例如，如何确定合作伙伴、日期、文本及用户状态等。可以根据

实际的业务需求，灵活定义各类事务类型。事务类型是事务处理的基础，创建事务时，首先

需要选择或确定所用的事务类型，然后系统使用该事务类型的特性和控制功能。事务类型的

关键分类是主要事务类别，其决定事务类型的性质和属性。

系统提供诸多标准的事务类型，可以参考标准事务类型新建所需的其他事务类型，如销

售订单可分成标准订单、退货订单及寄售订单等各种类型，但都属于销售订单类别；销售合

同、报价单也属于销售事务；而服务订单、服务合同、服务确认等为服务类的事务；营销中

的线索、费用申索、资金计划及资金等也都属于事务类型。在 SAP CRM 中也称为统一订单

类的凭证（One Order），或者称为订单类凭证类型。

应用举例：

● 业务活动：出差、拜访客户等使用的业务活动，交互记录，任务及电子邮件等。

● 销售订单：分成 B2B 网上订单、标准销售订单、退货订单、销售报价单等。

● 服务订单：分成常规保养订单、大保养订单、大修订单、中修订单、小修订单。

见图 2.35“事务类型的基本配置”（路径：配置 >CRM> 交易 > 基本设置 > 定义业务类

型 > 明细），列出了标准的投诉凭证类型的基本配置信息。事务类型编号为四位字符串，自

定义的事务类型通常为 Y 或 Z 开始，在描述字段中设定该事务类型的名称。主要事务类别用

于确定确定该凭证的业务分类与性质，如销售订单、服务订单、投诉、线索、商机或业务活动等。

事务类型通过诸多参数确定系务该如何处理该事务，如参数文件中指定相关数据的确定方

式。见图 2.36“事务类型参数文件”（路径：配置 >CRM> 交易 > 基本设置 > 定义业务类型 > 明

细），为事务类型指定各种参数文件，如：文本确定过程、合作伙伴确定过程、状态参数文件、

组织数据确定参数文件、日期参数文件、操作（活动）参数文件及审批确定程序等。

　　　

　　　　图 2.35　事务类型的基本配置　　　　　　　　　　图 2.36　事务类型参数文件

事务类型通常是事务的基础，牵引着诸多相关功能，在事务类型定义中，事务类型的主

要功能点参见表 2.14。


表 2.14　事务类型的主要功能点


编码和描述事务类型由四位编码组成，用户自定义的事务类型有 Z 或 Y 开始。描述支持多语言

主要事务类别

一个事务类型可以分配一个或者多个业务事务类别，其中指定一个为主要事务类别，主要事务类别决定该事务类型的性质，确定可以使用的子对象（Sub-Objects）。常用的业务事务类别如：业务活动为 BUS2000126，销售为 BUS2000115，服务为 BUS2000116，商机为BUS2000111，投诉为 BUS2000120，线索为 BUS2000108、申索为 BUS2000311。业务事务类别由 SAP 提供，为系统内置的功能，随着新版本新功能的引入，可能会提供新的事务类别。

选中主要事务类别以后，可以分配该事务类别允许的其他事务类别，即只有一定的组合才可以使用，并不是所有的事务类别都可以在一个事务类型中使用。针对每一个事务类别，均可能进行一定的设置。如销售订单所分配的主要事务类别为 BUS2000115，但同时分配了业务活动BUS2000126 的事务类别，因为订单中也可以使用业务活动的相关功能，如记录分类、优先级、目标等。而销售订单的信用检查、定价类型等配置需要在销售事务类别 BUS2000115 中进行配置

协议及合同确定即是否启动（销售、服务）协议或合同确定功能

报价单确定即“数量确定”选项，创建销售订单时，是否自动搜索并分配报价单

确定授权的合作伙伴

“搜索已授权合作伙伴”：确定合同中确定合作伙伴的方式，即只考虑合同中的售达方、

合作伙伴层次结构中的所有客户、合同中列出的授权的合作伙伴。这些范围的合作伙伴

为合同的授权合作伙伴，允许参考合同创建销售订单，享受合同条款

激活与否“未激活”：设定该事务类型未激活后，用户即无法在 Web UI 等应用中创建该事务类型的

凭证；也可以设置为无法在线创建该事务，但可以通过 IDOC 等后台事务处理时创建该事务

更改历史 “没有更改凭证”：是否启动凭证的更改历史功能

产品确定是否可以录入 GTIN 编号、合作伙伴产品编号、产品订购编号（PON）、根据产品描述

自动搜索产品、备选产品参数文件以及产品替换参数文件，是否展开产品包

文本确定过程可以在事务中使用的文本类型、确定方式和控制参数

合作伙伴确定可以在事务中使用的合作伙伴功能、确定方式及控制参数

状态参数文件可以在事务中使用的用户状态及控制参数

组织数据参数文件事务中对组织的确定和控制参数。在“合作伙伴功能类别”中指定用于组织数据确定的

合作伙伴的所属类别

日期参数文件可以在事务中使用的日期类型及控制参数

活动参数文件可以在事务中使用的操作以及控制参数。在“操作参数文件确定过程中”可以指定用于

确定活动参数文件的确定过程，即根据确定过程动态确所用的活动参数文件

对象参数文件即事务与其他对象的关系，如在商机中可以指定可进行后关联的凭证和对象类型

外部参考文件事务中可以参考哪些外部凭证

审批确定程序指定事务的审批确定过程，确定审批步骤

编号范围

可以指定事务的内部编号范围和外部编号范围。通常在线创建事务时，使用内部编号

范围，而 ERP 中创建的销售订单，复制到 CRM 时，CRM 中使用对应的外部编号范围，

以便 CRM 和 ERP 具有相同的订单编号。可以指定是否提前分配编号，以及指定行项目

编号的增量

事务类别的分配为事务类型分配需要的业务事务类别，然后对这些业务事务类别进行相关配置。一个

事务类型中可以使用的业务事务类别由该事务类型的主业务事务类别决定

分配冻结原因分配可用于该事务的冻结原因

渠道该事务可用于哪些渠道，例如 CRM Web UI、IC、ISA 等，如未分配 CRM Web UI 渠道，

则该事务类型无法在 Web UI 应用中使用

行项目类别确定确定该事务类型允许使用哪些行项目类别。行项目类别决定行项目的性质和功能


在事务类别分配中，一些常用的事务类别配置参见表 2.15。

表 2.15　在事务类别分配中的常用事务类别

事务类别主要配置

销售是否检查 PO 号是否重复、是否启用信用检查；指定凭证定价过程以及付款参数等

服务处理设定主题参数文件、用于服务确认的事务类型、调查问卷、担保参数文件以及是否激活抬头计数器等

业务活动指定业务活动的所属类别，是否集成日历，是否允许设置私人约会，是否可以发送电子邮件；以

及可以设置一些默认值，例如优先级、目标、方向和主题参数文件

机会设定与机会相关的配置，如销售周期、机会组，指定凭证定价过程；设定销售方法的参数，如评

估商机所用的问卷，文本配置；设定计划参数文件，以及竞争对手设置在抬头还是行项目产品中

当然，有很多其他配置与事务类型相关，例

如该事务类型所能使用的行项目类别，请参考相

关章节的功能。事务类型的配置路径为：配置 > CRM> 交易 > 基本设置 > 定义业务类型。

3. 行项目类别及行项目对象类型

行项目类别（Item Category）是对行项目属

性、分类和控制的定义。行项目类别通常由事务

类型及产品主数据的行项目类别组及用法共同确

定。行项目类别中可以进行一些行项目的控制配

置，如指定合作伙伴、文本、日期及操作等相关

参数文件，见图 2.37“行项目类别”（路径：配

置 >CRM> 交易 > 基本设置 > 定义项目类别 > 明细）。

应用举例：

● 销售订单行项目类别：分成标准行项目（需要开具发票）、免费行项目、退货行项目。

● 服务订单行项目类别：标准服务行项目（需要开票）、免费服务、服务计划等服务诊断行项目。

行项目类别的主要配置和功能参见表 2.16。

表 2.16　行项目类别的主要配置


编码和描述项目类别由四位编码组成，用户自定义的事务类型有 Z 或 Y 开始。描述支持多语言

对象类型

对象类型（Object Type）确定了一个项目类别的性质和功能。如 BUS2000131 为销售行项

目、BUS2000140 为服务产品行项目等。行项目类别与事务类型类似，可以分配可组合使用

的一个或者多个事务类别。选中对象类型后，系统确定可以使用哪些类型的事务类别

BW/CO 分配

在销售、投诉、退货、借贷项、免费发货等行项目类型中可以设置 BW/CO 分配，用于在

BW 和 CO 中进行分类和控制。例如将服务中的行项目归入到不同的控制对象中（在成本控制

时，归入到销售业务还是服务业务中）

图 2.37　行项目类别

图 2.37　行项目类别



一些常规配置

● 未激活：不激活该行项目类别； ● 重量和体积相关：该行项目的产品是否与重量和体积相关 ● 固定日期和数量：经过可用性检查后，是否固定交货日期和订购数量 ● 使用对象：行项目中是否可以允许使用个体对象 ● 参考：设定先前参考对象类型，是否必须参考前序凭证才能创建该类行项目 ● 区域检查：是否执行区域检查功能 ● 包展开：是否自动展开销售产品包

参数文件与事务类型控制相同，行项目中可以指定多种参数文件，包括：文本确定过程、合作伙伴

确定过程、行项目状态参数文件、组织数据参数文件、日期参数文件、活动参数文件及操作参数文件的确定过程；在行项目中，可以设置 ATP 参数文件

结构控制是否自动展开销售 BOM，如何控制交货组

配置数据是否允许使用可配置产品及相关配置

业务类别的分配

分配可用的业务类别，并且设定相关参数，如：开票、信用、定价和报价相关的参数。销售、服务及服务确认等行项目类别通常均有这些配置。

● 发票和信用控制 { 开票相关性：外部开票、根据订单数量开票、交货相关的开票等。 { 外部开票、里程碑计费、公司间开票。 { 信用组和信用评级参数文件。

● 定价控制：是否激活定价，是否启用免费货物功能，设定定价控制。 ● 报价相关：行项目初始系统状态为询价单或报价单，报价单 ATP 控制等。

技术指南：

● 对象子类型：业务事务类别由一系列对象子类型（Subobjects）组成，子对象包含了具体的功能，

如订单抬头、行项目、状态、日期、活动抬头及凭证流等一系列对象及处理，可以被多种事务重

用。子类型可以分成多种类型，如抬头、行项目、拓展（Extension）及数据集（Set）。系统中子

对象的数据表为 CRMC_OBJECTS。一个事务类型所能使用哪些子对象，由系统配置表 CRMC_OBJECT_ASSI 决定，而对象类型决定一个行项目类别所能使用的子对象类型，由数据表 CRMC_OBJ_ASSI_I 确定。事务类型的主要事务类别数据表为 CRMC_SUBOB_CAT。一个主要事务类别

只能与部分事务类别组合，例如销售事务类别可以与业务活动事务类别组合，但不能与服务处理

事务类别组合，这种组合关系由数据表 CRMC_BUS_SUBOB_C 决定。行项目类别可用的对象类

型存储在数据表 CRMC_SUBOB_CAT_I 中。事务类别决定该事务分配了哪些行项目对象类型，这

由数据表 CRMC_BT_BTI_ASSI 控制，数据表 CRMC_BUS_SUBOB_I 确定行项目对象类型可以在

哪些主要事务类别中使用。行项目对象类型可使用的子对象类型由表 CRMC_OBJ_ASSI_I 决定。

● 事务处理事件：事务的子对象与子对象之间是相对独立的、低耦合度组织在一起的，系统通过事

务的事件（Event）实现子对象之间的通信和相互影响。相关业务操作中会触发相关的事件，通过

事件的发布与订阅机制启动相关处理函数调用，即子对象之间不直接通信。系统提供了诸多预定

义的事件及调用函数（Callbacks），同时可以自定义事件及调用。通过事务代码 CRMV_EVENT 可

以管理事务对象的事件，如抬头状态变更时，调用某个函数，执行一些操作等。事件管理中，可

以对事务类型和行项目类别，确定相关的事件调用。在设计自定义事件函数调用时，需要考虑系

统性能，最好限定特定的事务类别，减少调用的范围，提升系统性能。CRM 的事件具有一个完整

（续）


的技术框架。有应用程序在适当的时点触发事件（函数 CRM_EVENT_PUBLISH_OW），通知事件处

理句柄（Event Handler），事件处理句柄即注册该事件并确定需要的调用（Callbacks），然后系统根据

处理时间设置处理相关调用（如立即处理或事务处理后执行）。一个事件的触发和执行可能会产生一

系列其他事件的执行，因此在事件响应函数开发时需要限制数据处理的范围，指定具体的事务类别、

对象和参数，减少对系统性能的影响，请仔细阅读事务代码 CRMV_EVENT 的说明文档。应用举例：

服务订单中，添加备件行项目时，调用自定义事件，检查是否需要自动添加相关的服务行项目；订

单处理中，创建或者修改行项目时，立即调用自定义事件，对相关数据进行检查并且提示相关信息。

● 业务事务的增强：通过简易增强工作台 EEW（Easy Enhancement Workbench）可以对事务进行增强，

为抬头、行项目等对象添加自定义字段和自定义表。也可以通过应用增强工具 AET（Application Enhancement Tool）对事务进行增强，提供了 EEW 之外的一些补充功能。可以通过业务插件

BADI 对事务进行增强，如抬头变更、行项目变更及订单保存时的检查等。部分 BADI 如果使用

不好，会对系统性能产生较大的影响，例如权限检查、字段选择、中间件自定义字段、复制控制

及对象控制，因此实际应用时需要考虑这些 BADI 的性能问题，如果能够指定具体事务类型的，

建议指定具体事务类型，以提升效率。另外在多行项目的业务场景中，需要特别注意性能影响。

● 事务处理的性能优化：性能优化的定价功能，见 SAP 注释 1436942，优化了定价执行的接口，跨

行项目的延迟定价等功能；使用开票请求行（Billing Request Lines）能够提升合同维护的效率（性

能比使用开票请求行项目 Billing Request Items 要好，但有一些限制）。事务的异步更新，即保存

时系统在后台异步更新数据，如果有错误，系统通过邮件等通知用户，因此，用户点击保存后即

可继续使用其他功能，无需等待事务的保存处理。多行项目的事务中，系统针对行项目的显示、

搜索等处理进行了优化。

2.2.2.2　状态管理

业务流程中，同一个凭证在不同时期可以处于不同的状态。比如一个业务活动，开始时

为打开（Open）或处理中，处理完成以后关闭。状态表示当前该事务的处理情况，每个状态

均代表两种功能，一是标识当前所处的特定状态，如订单已审批、服务单已释放等，二是确

定后续可以或者不可以执行的事务。系统执行一个事务时，系统可能会设置或者删除该对象

的一系列状态。

事务状态分两种类型：系统状态和用户状态，系统状态由系统自有流程确定，执行相关

事务时系统会自动触发设置相关的系统状态，通常无法手工直接修改，通常也无法自行定

义。系统状态起着对流程的系统控制作用，比如订单释放后复制到 ERP 系统，营销执行项目

中释放以后才能创建后续的费用申索单等。而用户状态是可以根据实际业务需求自行配置设

定，这样系统就具有很强的灵活性，不同的业务流程可以使用不同的用户状态序列来实现流

程管理与控制。用户状态由用户状态参数文件定义和决定，

用户状态参数文件分配到事务类型或者行项目类别中。同时

用户状态和系统状态可以相互影响，比如用户状态设置为审

批通过时自动设置系统为已释放，将销售订单复制到 ERP，即设置系统状态为分销到 ERP。见图 2.38“商机中的状态”（路

径：销售专员业务角色 > 销售周期 > 商机），这是一种类型的图 2.38　商机中的状态


商机的用户状态，为打开、处理中、成功、失败、停止及推迟等。

应用举例：

● 业务活动的用户状态：分成打开、处理中、已完成及已关闭。

● 服务订单处理的用户状态：打开、已分配、执行中、执行完成及关闭。

● 备件行项目用户状态：打开、已交货、已开票、已关闭。（同时 ERP 中交货后设置该项目的用户

状态为已交货，ERP 中开票或者 CRM 中对该行项目开票后自动设置用户状态为已开票。）

1. 状态参数文件

状态参数文件将多个用户状态组织在一起，并决定相关的控制参数。事务处理中，事务

类型和行项目类别均可以分配一个状态参数文件。然后在该事务或行项目中即可使用对应的

用户状态。见图 2.39“状态参数文件”（路径：配置 >CRM> 交易 > 基本设置 > 状态管理 > 定

义用户状态的状态参数），状态参数文件 CRM ACTIV 是 CRM 业务活动的标准的用户状态。

图 2.39　状态参数文件

表 2.17 以此为例介绍状态参数文件的设置。

表 2.17　状态参数文件配置


用户状态定义

● 可以定义一个或多个用户状态，状态由四位的编码和短文本组成。例如这里定义了四个状

态：打开、处理中、正完成、取消。

● 状态可以设置状态编号，也可以不设置编号。带编号的用户状态在同一时刻只能设置一个；

不带编号的可以并行使用，不带编号的用户状态可以和带编号的用户状态同时使用。

● 初始状态：指定一个为初始状态，即默认时的初始状态。

状态顺序

通过指定一个状态的最低状态编号和最高状态编号，可以控制状态的操作顺序。最低状态为该

状态能够返回的最低编号的状态，最高状态为该状态能够设置的最高编号状态。比如这里，已完

成的状态编号 3，最低状态为 1，最高状态为 10，即可以随意设置，无顺序

授权代码

控制该状态的操作控制权限，通过状态的权限对象（B_USERSTAT）可以设置对凭证状态的权

限控制。如果无权修改该状态，则用户无法将凭证设置到该状态。（注意，此时整个事务可能仍

有权限编辑，即事务整体的权限有其他权限控制。用户状态授权码仅控制该用户是否能操作该用

户状态）。权限设置中根据状态参数文件和状态权限码共同确定该用户对该对象的操作权限，详

细请参考 11.3.2 节“基本权限对象实施指南”

事务事务为系统定义的一些操作，例如完成、释放等。用户状态中可以指定其所触发的事务，而事

务执行时可以触发一系列相关的系统状态更新

对象类型状态参数维护工具栏中，可以为状态参数文件设定允许使用的对象类型。状态参数文件可以用

于一个或多个业务对象类型中，如订单抬头、订单行项目及业务合作伙伴等



事务控制

见图 2.39，打开或新建一个状态参数文件，选择一个状态，然后点击“明细”，可以设置该状

态的事务控制，即可以设置该用户状态对业务事务的影响，“影响”中可以选择“无影响、已允

许、警告、禁止”。凭证达到该用户状态时对业务事务的影响，是否允许、禁止某些业务事务。

如可以设置在订单处理中、审批中的状态时，禁止分发复制到 ERP 的事务，即订单在这些状态

时，不会传递到 ERP 中。“下一个操作”指如果系统执行这个事务，对当前的用户状态有何操作，

包括无后续作用、设置及删除。例如，如果成功分发复制到 ERP 的事务被执行，设置用户状态

为“用户接受”（即 CRM 中的销售订单被成功复制到 ERP 后，才设置为用户接受；如果因为未

审批释放或订单错误导致未复制到 ERP 中，则该订单状态就不属于用户接受状态。），如果 ERP中采购订单已生成，设置用户状态为“已生成采购单”等

2. 业务事务与系统状态

用户状态配置中可以设定允许操作或不允许操作的事务。系统状态也可以控制允许或禁

止使用的事务。见图 2.40“系统状态”（事务代码：BS22），为系统状态已完成（I1005）的对

事务处理的控制表，如允许、警告、禁止的事

务。禁止即为该系统状态下禁止执行该业务事务。

业务事务由相关业务操作操作和事件触发，例

如释放、关闭、设置为已完成等。系统状态和

用户状态可以相互影响。而在事务代码 BS33中，可以查看业务事务以及业务事务对系统状

态的影响（执行事务时对系统状态无影响或者

设置、删除相关的系统状态）。

业务事务具有一定的生命周期，系统通过

五个状态进行关键的生命周期控制，主要有：

1）打开（Open）：事务已经创建，但还未处理。

2）处理中（In Process）：事务正在处理中。

3）已释放（Released）：释放后，相关的后续事务可以触发，如分发、开票、打印等。

4）已完成（Completed）：所有直接关联的操作均以完成。

5）已关闭（Closed）：所有间接关联的操作均已完成，整个事务结束。

事务处理中，可以在事务抬头或行项目中设定拒绝或冻结原因，拒绝该事务或行项目，

冻结交货或冻结开票。

技术指南：

● 通过函数 CRM_STATUS_CHANGE_FOR_ACTIV_OW 可以执行相关业务事务或检查一个对象是

否可以执行某个业务事务。CRM_STATUS_SET_INTERN_OW 可以修改系统状态。部分修改状态

的函数不会触发状态变化的事件，需要了解相关函数的功能。程序 CRM_STATUS_CON 中定义

了系统状态和业务事务的全局变量，可以从变量定义中了解相关意义。

● 常用事务代码：BS33（事务及事务对后续系统状态的影响）；BS22（系统状态以及系统状态对业

（续）

图 2.40　系统状态


务事务的影响）；BS13（状态参数文件中指定所用的对象类型，对象类型中包含了可用的业务事

务）；BS03（状态参数文件）。部分系统状态可以通过工具栏按钮等相关操作设置，表格 CRMC_STATUS_PROC 中维护的系统状态可以在应用中手工触发。

● 常用数据表：TJ30（状态参数文件）、CRM_JEST（对象的状态表）、CRM_JCDS（状态更改历史表）。

其中 CRM_JEST 中记录了事务抬头及行项目所经历的各种状态以及标识了当前激活的状态，包括

系统状态和用户状态。而 CRM_JCDS 中记录了状态的变更历史，从中可以找到某个状态变化时

的具体时间。这两个表数据量通常都很大，在大批量读取时需要考虑性能问题。例如如果某个状

态变更的时间非常重要，可以考虑在订单保存时加入到日期或扩展字段中，这样能够方便查看，

读取该状态的时间时，性能通常会更好。

2.2.3　定价与条件技术营销、销售和服务等业务中通常都会使用到定价，包括价格、折扣、运费及税等各种类

型。不同企业对不同的业务通常有不同的定价模式并且差别较大，要求定价引擎能够具有足

够的灵活性和拓展性，以便能够通过配置实现和适应企业的各类需求。SAP CRM 具有灵活

的定价机制，具有完整的定价引擎，基本功能与 SAP ERP 的定价引擎相同，能够灵活的实现

各类定价需求。本节首先介绍定价的维护和应用，然后介绍定价条件技术和配置，最后介绍

使用定价条件相关的一些功能，如免费货物。

2.2.3.1　定价的维护和应用

定价条件类型表示一种类型的价格，常用的价格条件类型有销售价格、税、运费及折扣

等。定价条件类型可以根据实际的业务情况进行灵活配置，即根据一定的属性组合，如销售

组织、产品、客户、客户组、产品组及定价组等定价字段，设定价格数据。在业务处理中，

系统根据业务的具体信息自动确定价格数据。

1. 价格维护

可以在 SAP CRM 使用价格维护应用直接维护价格，也可以在其他多个应用和功能中维

护价格数据，例如合同中的价格协议、产品、产品层次结构、合作伙伴、合作伙伴层次结

构、营销计划、交易税引擎、服务管理以及 XIF 接口中均可以维护条件。维护前需要选择应

用范围，然后选择定价条件，系统显示该定价条件可用的字段组合，按照固定的定价字段组

合维护价格数据。

见图 2.41“价格主数据”（路径：销售专员业务角色 > 销售运行 > 价格），维护了客户特

定产品的价格，即价格和客户、产品及销售区域相关，选择销售组织、分销渠道、产品和客

户，维护具体的价格，同时设定价格的有效期。在价格维护中，可以创建等级（Scale），即不

同数量范围段可以设置不同的价格，以实现阶梯定价功能。

在（销售 / 服务）合同和框架协议中，系统使用价格协议确定用户可以享受的折扣或

优惠价格。SAP ERP 零售解决方案中的促销价格也可以同步到 CRM 中，供 CRM 销售订

单使用。


图 2.41　价格主数据

2. 价格清单

价格清单（Price List）为在一定有效期内向客户出具的针对一定范围产品的价格列表。

价格清单使用已维护的价格条件主数据，以清单列表的形式展示。可以从客户、产品及客户

产品范围等主数据中创建价格清单。可以将价格清单输出为 PDF 文件，可以打印预览、打印

及通过邮件发送给客户。价格清单还应用于产品推荐、贸易促进管理中，即推荐产品时系统

会列出产品的价格，计算贸易促进的价格。

3. 价格应用

价格主数据维护后，事务处理中即可自动确定相关价格。见图 2.42“订单中的定价”（路

径：服务专员业务角色 > 服务订单 > 明细），为服务订单行项目中的定价，价格中列出各种

价格要素（即为条件类型），价格与货币中列

出该产品每个单位的基本价格，这里价格为

499 美元，共订购了 3 个，所以结果值是

499×3 ＝ 1497 美元。使用简易条件录入功

能，可以简化事务中的价格维护。即在事务

的行项目表格中直接填写价格，无需进入行

项目价格页面中维护。通过系统配置，最多

可以设置五个条件类型为简易录入的条件类型。

可以在事务凭证的抬头或者行项目中

维护价格。通常抬头显示的价格由行项目定

价加总而成。根据定价过程对条件类型的配

置，系统可以自动确定价格条件，也可以由

用户手工录入或修改已确定的价格。如果设置为不能手工录入，该条件仅能通过定价条件主

数据确定，用户无法修改。如果某条件类型不在已有列表中，可以添加，选择可用的价格条

图 2.42　订单中的定价


件，录入价格。可以重新执行定价，重新执行时可以选择是否要保留手工录入的价格条件，

也可以让系统重新确定所有条件，即重置手工录入或修改的价格。行项目开票以后，行项目

的价格即被固定，不能再次修改。

4. 价格变更的审批

通过定价数据维护的权限和工作流设置，可以实现价格变更审批功能。即当用户没有权

限修改事务凭证中的价格时，用户仍然可以在凭证中修改价格，但该价格处于未激活状态，同

时系统启动价格维护审批工作流，审批人员对该价格的修改进行审批。审批通过后，该价格条

件才生效，设置为激活状态，如果审批不通过，则该价格条件无效，不参与凭证的价格计算。

技术指南：

● 在营销活动、产品、客户以及价格维护应用本身能够维护哪些条件类型的价格数据，由条件维护

组决定。价格数据最终保存在条件数据表中。条件维护组中指定了可供维护的条件表和条件类型

的组合，即如果一个条件类型由多个条件表组成，可以在条件维护组中维护多条记录，维护时即

可选择对应的条件表和条件类型组合。例如条件类型 0PR0（价格），可以使用 SAP004（产品价格）

和 SAP005（客户产品价格）条件表。不同的应用场景可以使用不同的条件维护组，例如客户、产

品和价格维护应用中，可以指定可用的条件维护组。配置路径为：配置 > 主数据 > 条件和条件技

术 > 条件技术：基础 > 创建条件维护组以及定义上下文的维护组。

● 标准的价格清单所用的定价过程为 0NPL01，包含 0PR0 价格和客户或物料相关的折扣价格条件。价

格清单类型确定价格清单的属性和操作，包括所用的定价过程（因此能使用该定价过程中的条件类

型所对应的价格），输出所用的活动参数文件等，价格清单的配置请参考：配置 > 主数据 > 价格清单。

通过事务代码 SMARTFORMS 编辑智能表单 BEA_CNPL_BILLING_SF，调整价格清单 PDF 文件的

格式和内容。通过程序 BEAR_CNPL_PDL_PROCESS 可以创建价格清单，而程序 BEAR_CNPL_PL_PROCESS 可以重新计算价格清单中的价格。这两个报表程序均可以设置成后台作业定期运行。

● 系统配置中可以为定价过程设置五个用于简易价格录入的条件类型，即在事务行项目表格中直接维护

这些条件类型的价格，参考：配置 >CRM> 基本功能 > 定价 > 业务交易中的定价 > 设置轻松条件条目。

● 价格变更审批的工作流模板为 CND_APPR（WS52600001），业务增强 /SAPCND/DBA_SAVE_WS的实施 CRM_CND_APPROVE 中检查是否有满足条件的未激活的条件需要触发审批，而通过增

强 BADI CRM_CNDCHG_APPROVAL_WF 可以触发价格审批的工作流。关于审批功能，可以参

考 SAP 注释 986344。 ● 价格相关的性能优化：在行项目多、数据量大的应用中，为尽可能提升系统性能，系统修改了一

些价格存取方法，启用相关的业务功能和配置后，能有效地提升定价的系统性能。SAP CRM 7.0 EHP1 之前，对于有大量行项目的合同和订单，更改单据时（即使是定价无关的字段编辑）系统均

会将相关定价信息传递到定价引擎 IPC 中进行重新计算，如果行项目多，系统性能会受到影响。

EHP1 中（启用业务功能 CRM_PERFORMANCE），可以指定哪些字段变更才需调用定价引擎，同

时可以使用延迟的跨行项目定价功能（Delayed Cross-Item Pricing）。对销售类单据、服务类单据、

销售合同等有显著影响，详细可以参考 SAP 注释 1436942。SAP CRM 7.0 EHP2 起（启用业务功能

CRM_PERFORMANCE_2），可以使用快速组条件（Fast Group Condition）来加快事务中的定价处理，

定价引擎会识别需要进行价格重新计算的行项目并仅对这些行项目及相关行项目进行价格重新计算，

无需对所有行项目进行重新计算。可以参考 SAP 注释 1487240 查看相关用户出口等信息。定价性能


提升的相关配置见：配置 >CRM> 基本功能 > 定价 > 业务交易中的定价 > 性能优化条件处理和定价。

● 合同中的价格协议即使用条件记录技术，在合同的价格协议中维护价格时，系统自动将合同的抬

头或行项目内部编号（GUID）作为价格组成字段之一，即条件表中使用了合同行项目 GUID 作

为定价字段之一，例如定价表 SAP00090。在合同中维护价格协议时，此字段为隐藏字段，自动

填充。启用合同中的价格协议需要配置所用的条件维护组，并分配给合同事务类型或行项目类别

（行项目类别配置的参数文件中，可以指定条件组），路径：配置 >CRM> 交易 > 合同的设置 > 价

格协议和配置。

2.2.3.2　定价条件技术

本节首先介绍在事务凭证中，系统确定价格的过程步骤，然后介绍定价技术和配置，从

而了解 SAPCRM 的定价引擎是如何工作的。

1. 定价确定步骤

SAP CRM 的定价处理的，系统自动确定可用的条件类型和价格，主要过程为：

1）维护事务凭证（如销售订单或服务订单）时，系统根据录入的客户、组织数据（销售

范围）及事务类型等数据，确定系统所用的定价过程。

2）定价过程包含了多个定价类型，设定了条件类型的控制方式和计算方式，如是否必

填、是否允许手工录入、所满足的条件、计算公式以及记账控制等。

3）在条件类型配置中指定了所用的价格的访问顺序。价格访问顺序中可以包含一个或

者多个定价数据表。定价数据表中保存了价格主数据。

4）定价表包含了用于维护定价的多个属性，如客户、物料、销售组织等。

5）最后系统就把当前业务场景中的相关属性传递给这些定价数据表，搜索价格数据，

如果能读取到价格数据，系统即把价格填充到对应单据的条件类型中。

2. 定价过程的确定

定价过程即用来确定事务凭证中可用的价格条件、计算方法，控制价格的计算和功能，

是价格确定的核心参数文件，起到统领定价的作用。因此，在事务处理中，首先要根据各

种信息确定正确的定价过程。见图 2.43“定价过程确定”（路径：配置 >CRM> 基本功能 >定价 > 业务交易中的定价 > 确认定价过程），定价过程的确定由五个参数决定，即销售组

织、分销渠道、部门、凭证定价过程和客户定价过程，这五个参数能够唯一确定一个定价

程序。

其中销售组织、分销渠道、部门由事务凭证中的组织数据决定，即创建事务时，自动确

定或录入的组织数据后，即被确定。

凭证定价过程由事务类型唯一确定，每一个单据类型都可以分配一个凭证定价过程，见

图 2.44“事务类型中的凭证定价过程”（路径：配置 >CRM> 交易 > 基本设置 > 定义业务类

型 > 明细 > 业务事物类别分配 > 销售）。创建事务凭证，选择事务类型时，即确定了凭证定

价过程。


　　

　　　　　图 2.43　定价过程确定　　　　　　　　　　　图 2.44　事务类型中的凭证定价过程

而客户定价过程由客户主数据的销

售范围数据中的客户定价过程确定，见图 2.45“客户主数据中的客户定价过程”（路

径：销售专员业务角色 > 客户管理 > 客户 >销售区域数据），客户主数据中，选择一个销

售范围，然后在开票数据中可维护客户定价

过程，如这里为标准。因此，事务处理中，

录入客户后，确定组织数据后，客户的定价

过程即被确定。

定价过程确定后，系统即使用该定价过

程中的定价条件、公式等配置信息，读取访问顺序和条件表获取定价数据，或根据定价公式

计算出相关价格数值。

3. 定价过程

定价过程（Pricing Procedure，也称定价程序）包含多个定价条件类型，指定了各条件类型

的顺序、满足计算的条件、计算公式、累计方式及条件的记账方式等。见图 2.46“定价过程”

（路径：配置 >CRM> 基本功能 > 定价 > 定义定价的设置 > 创建定价程序），0CRM01 是 CRM中的一个标准定价过程，该定价过程中使用了 0PR0 价格、折扣以及 0TTE 税计算等诸多条件

类型。如果使用 ERP 中定价条件和过程，可以将 ERP 中的定价配置和价格主数据复制到 CRM系统中。初始复制后，SAP ERP 中修改和新增的价格数据会自动同步到 CRM 系统中。“源系统”

中确定该定价程序来自 ERP 或本地 CRM。CRM 中创建的定价过程来源为本地 CRM。

图 2.46　定价过程

图 2.45　客户主数据中的客户定价过程


定价过程的控制有：

● 每个条件均会指定一个顺序的级别，对于折扣加总、价格加总等可以设置加总条件类

型的范围，例如总折扣金额设置了 100 到 299，即将级别为 100 到 299 的条件（为各

类折扣）加总成本行的“总折扣金额”。

● 手工条件、强制条件和统计条件：即是否允许手工录入该条件类型，该条件类型是否必

填，该条件是否为统计类条件，统计类条件仅供显示和查看使用，不改变凭证的定价值。

● 小计：将该条件类型的结果值小计到某个指标中，如果多个条件均小计到同一指标中，

该指标即包含这些条件的累计值。小计通常用于定价计算。

● 公式：条件公式用来计算该条件类型的数值；基本公式用来计算基础条件值，例如在

折扣中，折扣会扣减条件值，而额外的价格会增加条件值；要求中设置该条件类型启

用时所满足的条件。

● 其他：对于必填条件，可以设置提示信息类型为错误或警告。可以设置打印输出控制

和权限控制级别。

4. 条件类型

一个条件类型（Condition Type）表示一类定价，如销售价格、折扣、运费及税等。系统

根据一定的输入参数自动找到或计算价格条件值。

见图 2.47“条件类型（1）”（路径：配置 >CRM> 基本功能 > 定价 > 定义定价的设置 >创建条件类型），条件类型 0PR0 为 CRM 的标准销售价格；源系统为本地，说明该条件类型

是在 CRM 中创建，如果是从 ERP 复制过来的，数据源为 ERP 系统；访问顺序中，使用了

0PR0 的访问顺序，访问顺序决定使用哪

些定价条件数据表。

见图 2.48“条件类型（2）”（路径同

上图），列出了部分的条件类型控制数

据，首先条件类别可以为价格、折扣或

运费等，表示条件类型的基本分类，这

里 0PR0 的条件类别为普通价格；计算

类型可以有数量、百分比或固定值等，

这里与数量相关，说明如果 1 个单位的

产品是 100 元，那么订购 2 个单位的产

品，价格为 100×2 ＝ 200 元；如果是百

分比折扣，那么会根据价格乘于这个百

分比计算出折扣金额。手工输入表示是

否允许手工录入，有一些条件必须通过

计算得出，可以表示为不允许手工录入。

项目条件表明该条件应用于订单的行项

目中。

图 2.47　条件类型（1）

图 2.48　条件类型（2）


5. 访问顺序

访问顺序（Access Sequence）确定定价所用的价格数据表。一个访问顺序可以有一个或多

个访问（即存取序列），每一个访问都对应一个定价表。系统运行定价时，对于一个定价条件，

系统找到该定价条件的访问顺序，根据业务参数（如客户、物料等）依次读取访问顺序的数据

表，找到满足条件的定价数据，并应用到单据中。例如先根据客户及产品共同确定价格，如

果没有确定，就根据产品确定价格。

见图 2.49“访问顺序”（路径：配

置 >CRM> 基本功能 > 定价 > 定义定

价的设置 > 创建访问顺序 > 访问顺序 > 访问），0PR0 访问顺序有访问序列 5、10、20、30、40 及 50，第二列为具体

的数据条件表；第三列为是否排除，即

如果选中，找到该条件后即不再执行后

续访问顺序；第四列为满足的条件，只

有满足这些个条件才使用该访问序列。

见图 2.50“访问顺序所用的字段”（路

径：配置 >CRM> 基本功能 > 定价 > 定义

定价的设置 > 创建访问顺序 > 访问顺序

> 访问 > 字段），即访问顺序 0PR0 所使用

的一个表 SAP005，这个表使用了字段有

销售组织、分销渠道、客户及物料，即价格是根据定价表的这四个属性确定，即不同客户对

同一产品可以设置不同的销售价格，即客户物料价格。

6. 条件表

用于保存定价数据。不同数据表可以有不同的定价字段组合，比如根据客户、产品设定

销售价格，或者直接根据产品设定价格。可以选用定价字段定义各种价格条件表。

见图 2.51“条件表”（路径：配置 >CRM> 基本功能 > 定价 > 定义定价的设置 > 创建条

件表），显示了 SAP005 的价格条件表，右边列出了所使用的字段，销售组织、分销渠道、售

达方及产品。最终的价格主数据即保存在这些数据表中。如果标准的定价表不能满足业务需

求，可以自定义数据表。

图 2.51　条件表

图 2.49　访问顺序

图 2.50　访问顺序所用的字段


技术指南：

● 如果需要在事务中分析定价如何获取，可以在事务代码 SU3 中设置用户参数 PRC_TRACE ＝

X，这样能够跟踪单据中的定价确定。定价在 VMC 虚拟机容器中的 IPC 中执行，如果查看 IPC的 RFC 调用，可以设置用户参数 PRC_RFC ＝ X，然后计算定价时系统会在调用 IPC RFC 函

数前设置调试断点。IPC 中的定价计算公式通过 Java 实现，可以执行报表 RSVMCRT_MINI_DEBUGGER 查看相关源代码，参数为 dbsources。如果使用 ERP 的定价配置，对于 ERP 自定义

的计算公式，需要在 IPC Java 中重新实现后才能在 CRM 中使用。事务代码 SM53 为 VMC 系统

管理，可以查看定价的计算日志。

● SAP 注释 1746584 中能找到有关定价、条件技术和计税的常见问题。VPRS 成本价格可以通过自

定义定价条件的方式复制到 CRM 中，但是有一定的限制，如成本更新不如 ERP 中及时等，可参

考 SAP 注释 653046。CRM_COND_COM_BADI 是定价中常用的增强，通过修改和确定 ITEM_COMMUNICATION_STRUCTURE 结构中的数值，影响定价。

● CRM 定价和 ERP 定价的差异：CRM 使用 ERP 中相同定价技术。但 ERP 中使用的部分条件类

型在 CRM 中不能使用，如 EK01 及 EK02 的价格计算、AZWR 预付费处理、RL00 及 MW15的发票清单因素折扣、EDI1 及 EDI2 的 EDI 客户期望价格以及从物料成本中确定的 VPRS 成

本。CRM 中的价格数据变化并没有凭证的历史记录功能，无法批量复制定价条件。在数据模型

上，CRM 定价与 ERP 定价也有差异。CRM 定价技术应用于多种应用程序和用途中，是一个集

成的条件技术应用，并且 CRM 的产品数据、价格数据、组织结构等数据模型均与 ERP 对应功

能的数据模型不同，因此在数据模型上存在较大差异。CRM 中定价表的数据表组成为：前缀

（CNC）＋应用程序（CRM 及 TTE 等）＋用途（如 PR 为销售与服务、FG 为免费货物）＋表名

（SAP 开始的表为标准表或者 CUS 开始的表为自定会议表）。例如 ERP 中的标准定价表 004 的价

格数据表为 A004，对应 CRM 中为 CNCCRMPRSAP004，ERP 中 A910 的自定义价格表在 CRM中为 CNCCRMPRCUS910。CRM 中价格数据的级别设置保存在 CNL 为前缀的数据表中，如

CNLCRMPRSCALEDIM 为级别和定价值的关系表。

2.2.3.3　免费货物

免费货物（Free Goods）使用与定价相同的条件技术，客户购买一定数量的产品后，可

以获取一定数量的免费产品，以激励客户购买更多产品。

免费货物分包含性免费货物（Inclusive）和排除性免费货物（Exclusive）。包含性免费货

物指客户购买一定数量的产品中有一定数量的货物是免费赠送的，即如果客户购买十个产

品，只需要支付九个产品的价格，其中一个为免费提供。而排除行免费货物中，客户购买十

个产品以后，支付十个产品的价格，然后能够额外获得一个免费货物，因此客户支付十个产

品的价格得到了十一个产品。

CRM 中所用的免费货物功能及技术与 ERP 中的免费货物相同。可以将 ERP 中的免费货

物配置和条件主数据复制到 CRM 中，供 CRM 使用。创建订单时，系统自动读取免费货物的

条件数据，满足条件时，系统会自动添加免费货物行项目，该行项目与定价无关，免费提供。

在系统配置方面，免费货物使用了与定价相同的条件技术，系统提供标准的 0NA001 的

免费货物确定程序，其中使用了 0NA0 的条件类型，访问顺序为 0NA0。


见图 2.52“免费货物条件类型”（路径：配置 >CRM> 基本功能 > 免税货物 > 设置自由货

物 > 创建条件类型），免费货物条件类型 0NA0 的应用程序为

CRM、用法为 FG。

免费货物的确定过程与定价程序的确定过程类似，由销

售范围、客户定价程序、凭证定价程序组合确定。免费货物条

件主数据可以在 Web UI 主数据中维护。

1. 免费货物的等级及计算类型用法

可以使用条件的等级功能（Scale），定义不同订购数量所

获取的不同比例的免费货物，如订购数量为 10，免费货物数量

为 1，订单数量为 20 及以上则免费货物为 2 个。通过计算类型

用法，可以控制客户订购数量不等于（大于或小于）免费货物规则中定义的数量时如何取值。

例如免费货物的规则为订购 100 个，其中 10 个免费，如果客户订购 150 个，系统根据计算类

型确定所能获取的免费货物数量。如果设置为类型 1，即按比例兑现，那么可以获取 15 个免

费货物，因为比例是十比一；如果设置为类型 2，即单位相关，即每 100 的单位能够获取 10个免费货物，150 个不满足两个单位条件，因此能够获取 10 个免费货物；如果设置类型为 3，只有满足条件确定数量时才赠送，因此购买 150 个，客户不能获取免费货物，当然在这种模式

下，如果使用两个订单，其中一个为 100 个，另外一个为 50 个，就能够享受 10 个免费货物。

2. 免费货物的配置

免费货物的基本配置可以参考配置 >CRM> 基本功能 > 免费货物，可以定义免费货物所

用的条件表、访问顺序以及条件类型，定义免费货物的确定过程，分配免费货物确定过程。

2.2.4　日期管理日期管理是 SAP CRM 系统重要的基础功能。业务处理中，往往需要多种类型的日期，

根据一定的规则计算和确定日期；在全球跨时区的业务应用中，通常还需要考虑时区转换问

题。在 SAP CRM 系统中，可以灵活定义各种类型的日期、周期和日期计算规则，同时可以

考虑时区转换。见图 2.53“投诉单中的日

期”（路径：服务专员业务角色 > 投诉和退

货 > 投诉 > 明细），为投诉单中的日期，

点击“编辑清单”，可以列出该凭证类型允

许的日期类型，可以进行填写或者系统在

流程操作中自动填充。在操作管理中，也需要使用日期管理功能，设定基于时间的操作条件。

应用举例：

● 业务活动：计划开始日期、计划结束日期、实际开始日期与实际结束日期。

● 商机：演示日期、评估日期、招标日期、投标日期、商务谈判日期、技术谈判日期等。

● 服务：服务请求开始日期、计划执行日期、实际执行日期、任务分配日期。

日期管理的基本功能参见表 2.18。

图 2.52　免费货物条件类型

图 2.53　投诉单中的日期


表 2.18　日期管理的功能点及说明


定义“日期类型”和

“持续时间”可以灵活定义各种类型的日期和持续时间（Duration），灵活命名，以实现各种日期功能

日期规则

可以定义日期计算规则，然后系统根据此规则自动计算日期。在合同取消等业务中，可

以使用日期规则确定取消日期。可以使用 XML 编辑器定义日期的计算方法，也可以通过

ABAP 函数计算日期

定义日期参数文件及

分配

定义日期参数文件，包含可以使用的日期类型，以及指定日期计算的规则，设定日期计

算的参考基准。日期管理中支持时区和所用的日历，如使用工厂日历。可以使用系统、用

户或客户所在的时区

将日期参数文件分配到事务凭证抬头或行项目中维护凭证时，系统根据日期参数文件确

定可用的日期类型，并根据日期规则计算日期和时间

下面简要介绍日期相关的配置及控制功能。

1. 日期类型及规则

通常根据业务需求定义各种类型的日期，定义日期的计算规则。而日期参数文件将日期

类型、持续时间和日期规则组织在一起，实现对日期的控制和管理。下面介绍日期类型、持

续时间和日期规则的定义和功能，路径为：配置 >CRM> 基本功能 > 日期管理 > 定义日期类

型，持续类型和日期规则。

● 日期类型。可以定义各种日期类型，指定编号和描述，如开票日期，报价开始日期等。 { “日期参数文件”标识：该日期类型是否可以在日期参数文件中使用。 { “里程碑”标识：该日期是里程碑日期，用于商机管理中。通常的日期类型包括日

期和时间，并且由开始日期和结束日期成对组成，即持续一段时间。而里程碑日

期不包含具体时间，同时无法设置持续周期。

● 持续时间。持续时间（Duration）用来定义两个时间点之间的间隔。持续时间可以用于

日期参数文件中，指定持续时间数量和单位，用于计算日期，比如响应时间为接收到

客户的服务请求后的四个小时。持续时间配置中仅指定编号和名称，应用到日期参数

文件时才需要指定数量和时间单位。

● 日期规则。用于确定如何计算该日期，

可以通过 XML 定义日期计算公式或者

函数计算出来。日期规则中可以使用其

他类型的日期、持续时间以及参考对象。

日期参数文件中的每个日期类型均可以

分配一个日期计算规则，然后系统根据

此规则确定日期。

见图 2.54（路径：配置 >CRM> 基本功能 >基本功能 > 日期管理 > 定义日期类型，持续类

型和日期规则 > 日期规则），日期规则维护的编图 2.54　日期规则编辑器（1）


辑器。这是一种基于 XML 的日期规则编辑工具。比如这里 SRV_0001 的计算规则，首次响

应时间为 SRV_START 开始日期加上 SRV_RF_DURA 持续时间。

图 2.55 中（路径同上图），系统通

过 ABAP 函数 CRM_SERVICEPLAN _I _PLANDATE 计算该日期。该日期用于周期

性的预防性维护中，根据服务计划，每隔

一定时间自动产生某种服务订单，包含相

关的服务任务。系统运行时直接根据这个

函数，根据上一次的计划时间、服务执行

周期，计算出下一次的服计划服务日期。

日期计算规则应用举例：

● 在服务管理中，企业可以根据产品可用性、产品的采购周期，及与客户的合同约定（如假期、服

务等级等）等条件，自定确定服务的开始时间。而在商机管理中，也可以根据一定的条件计算销

售项目预计结案时间。

● 在服务计划中，根据计数器读数、时间以及企业的其他业务规则，确定下次服务时间。

2. 日期参数文件及分配

日期参数文件将日期类型、持续时间、日期规则以及日期相关的控制组织在一起。日

期参数文件可以分配给事务类型或行项目类别中，以便在事务中使用。下面介绍日期参

数文件的配置和功能，配置路径为：配置 >CRM> 基本功能 > 日期管理 > 定义日期参数文件。

● 参考对象。选择可以在该日期参考文件中使用的参考对象。参考对应用于确定日期计

算时所使用的时区和日历。参考对象由系统提供，不同对象有不同的确定过程，有以

下对象： { 系统（SYSTEM）：SAP 服务器的系统时区，如果未指定，就使用操作系统的时区。 { 用户（USER）：用户主数据中指定的时区。 { 业务合作伙伴（CUSTOMER）：通过凭证抬头中的合作伙伴确定。在任务和业务合

作伙伴中，系统系统“联系合作伙伴”的合作伙伴功能类别确定所用的合作伙伴，

其他凭证中使用售达方功能类别。 { 运达方（SHIP_TO）：使用凭证抬头中送达方类别的合作伙伴。 { 作业位置的时间区（ACTIVITY）：使用业务活动中指定的时区和日历。 { 服务参数文件（SERWI）：使用合同行项目中的时区。

通常，如果时区无法确定，则读取用户所在的时区，然后读取系统所在的时区。

● 日期规则。选择可以在日期参数文件中使用的日期规则。

● 持续期间。选择可以在日期参数文件中使用的持续时间，并且指定持续时间的数量和

单位，同时指定参考对象，例如提前期为 3 天。

● 日期类型。选择可以在日期参数文件中使用的日期类型并设定相关参数。见图 2.56

图 2.55　日期规则编辑器（2）


（路径：配置 >CRM> 基本功能 > 日期管理 > 定义日期参数文件 > 日期类型），显示了投

诉 COMPLAINT 的日期参数文件，包含了

开票日期、发票创建日期、要求开始日期

及要求结束日期等各种日期。日期参数文

件中，每一个日期均可以进一步指定控制

参数，比如要求的开始日期 SRV_CUST_BEG 的日期参数文件为 SRV_0001 首次响

应，见图 2.57（路径：配置 >CRM> 基本

功能 > 基本功能 > 日期管理 > 定义日期参

数文件 > 日期类型 > 明细）。日期规则确

定如何计算该日期。如果选择只确定一次

日期，日期成功确定一次后，如果相关条

件发生变化，该日期不会再次被确定。显

示格式中，可以指定是否显示日期、时间

及区域。如果不显示时间，那么就只有日

期，显示时间时系统会显示具体的时分

秒。如果设定为当前时间，系统会直接用

系统的当前时间填充该日期类型。参考对

象是确定时区的重要参数，在多时区业务

中，可以根据系统时区、用户时区或者送

达方等客户数据时区确定时间和日期。系

统保存时均会保存为 UTC 格林威治标准

时间，同时会记录时间的时区。不同时区的用户可以得到一致的正确的时间显示。

● 日期参数文件的分配。在订单类凭证中，日期参数文件分配给事务类型。一个事务类

型拥有一个日期确定过程。日期参数文件也可以分配给行项目类别，在行项目中使用

日期。见本章业务事务处理 2.2.2.1 基本结构和功能部分。

技术指南：

● 通过查询数据表 CRMD_LINK（OBJTYPE_SET=30）和 SCAPPTSEG 可以从数据表中查询对象的

各种日期。

● 如果在多个国家中开展业务，在日期类型配置和数据导入时通常需要考虑时区。系统根据日期规则

所用的参考对象确定时区，可以参考函数 CRM_DATES_TIMEZONE_BY_OBJ_OW，了解各种参考

对象时区的确定顺序和方式。同时可以使用 BADI CRM_TIMEZONE_BADI 自定义时区的确定方式。

● 日期规则使用了 XML 编辑器，具有一定格式的语句，可以使用时间语句、持续时间语句和参考对

象语句，具体用法可以参考文章 http://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=326600223。

2.2.5　操作管理CRM 中的操作（Action，也称为活动、动作）为满足一定条件时所触发的相关动作，比

图 2.56　日期参数文件

图 2.57　日期参数文件中的日期控制参数


如创建后续单据、提醒、输出打印及触发工作流等。操作是流程自动化、维持良好的客户关

系的重要工具和功能。通过定义各种操作和条件，可以在适当时候触发相关动作，例如通知

提醒等。在 CRM 中，输出确定也使用 CRM 操作技术。

在实际应用中，操作具有多种表现形式。例如凭证的操作信息块中，可以列出或执行关

联的操作；事务抬头或行项目的工具栏按钮可对应于某个操作；在保存或更改时，系统也可

以触发相关操作。见图 2.58“商机中的销售助理功能”（路径：销售专员业务角色 > 销售周期 >商机），这是商机的销售助理功能，即为系统

定义的一系列的操作。不同阶段可以定义不同

的工作任务，激活以后，系统即自动为该商机

创建后续业务活动，分配相关人员进行处理，

可以规范销售的具体过程，规范没有销售环

节中需要完成的各种任务。销售助理功能，

即通过 CRM 操作实现。

应用举例：

● 事务处理：如创建后续事务创建后续的任务、业务活动等相关凭证；合同结束前自动创建合同报

价单；投诉中自动创建贷项凭证、退货、发货等行项目；商机中根据销售助理创建工作任务；服

务处理中根据时间的响应触发服务升迁处理。

● 输出和数据发送：如订单释放时，调用操作将订单相关数据通过 IDOC 方式发送给合作伙伴。

● 打印和预览：使用智能表格打印单据，同时可以在单据明细中预览打印效果。

● 通知：服务请求、服务订单、业务活动等的邮件通知，审批通知等。

了解 CRM 的操作管理，可以从操作、条件以及操作参数文件着手，了解操作在各种业

务中的应用及控制。如图 2.59“ CRM 操作定义与执行”所示，操作参数文件中包含一个或

者多个自定义的操作，每一个操作均会执行一些功能，通过操作方法指定（如调用业务对象

方法、创建后续业务凭证、触发工作流、调用智能表格进行通知或打印等）。满足计划条件

时，该操作进入计划阶段，例如可以显示在对话框清单中。满足开始条件时，即可以执行此

操作。操作参数文件分配到事务类型或者行项目类别中。

1

N

图 2.59　CRM 操作定义与执行

下面以标准的投诉行项目的操作为例，介绍操作参数文件和操作的控制。

1）全局配置。新建或复制操作参数文件时，首先要设定操作参数文件的全局参数。双

图 2.58　商机中的销售助理功能


击操作参数文件设置全局参数，主要有：

● 对象类型：活动参数文件用于哪个对象类型中，例如用于投诉行项目的对象类型为

BUS2000160。指定对象类型后，在操作条件中能够使用该对象类型的属性。

● 日期参数文件：如果使用时间相关的条件，可以使用日期参数文件中的日期规则。

● 上下文类：指定确定上下文属性的程序类，例如订单通常为 CL_DOC_CONTEXT_CRM_ORDER。

2）操作。一个操作参数文件中包含一个或者多个操作，每一个动作定义了具体的触发

方式，需要完成的功能。动作由编号和描述组成，可以设置显示顺序、是否激活；见图 2.60（路径：配置 >CRM> 基本功能 > 操作 > 事务

活动 > 更改操作和条件 > 定义操作参数文件

和操作），这是投诉单中投诉行项目的标准操

作参数文件，该参数文件中定义了多个动作，

CREDIT 是创建贷项凭证子项目，DEBIT 是

创建借项凭证子项目，RETURN_REQ 是创建

退货申请子项目，SUBST_DEL 是创建替代发

货子项目，TASK_ITEM 是创建单独的后续处

理任务。系统会拷贝投诉行项目，将相关信息、比如产品编号及数量等复制到后续创建的子

项目中。

3）动作明细。见图 2 . 6 1（路径：配置 >CRM> 基本功能 > 操作 > 事务活动 > 定义

操作参数文件和操作 > 动作定义明细），以 RETURN_REQ 退货申请行项目为例说明动作的明

细控制。

● 处理时间：包括立即处理、用选择报

表处理及保存文档时处理。立即处理

即满足条件时即处理，例如点击生成

退货或发免费发货行项目时，立即产

生子行项目；用选择报表处理即满足

计划条件时，操作进入选择报表（事

务代码：SPPFP）中，满足执行条件

时，可以执行该操作，通常设置后台

作业，自动定期执行选择报表中的操

作；保存文档时处理，即保存时如果

满足条件则执行此操作。

● 自动计划：即如果满足计划条件时，

是否自动执行该操作。如果不选择，

计划以后，需要手工触发或者使用选

择报表触发才能执行该操作。

● 处理后删除：指成功处理后删除该操作，如果处理错误，则不会被删除。

图 2.60　操作参数文件

图 2.61　操作定义


● 显示和执行：是否显示在对话框即操作处理页面中，是否可以在对话框中手工执行，

是否可以更改。

● 合作伙伴确定：即指定操作所用的合作伙伴功能，例如为客户或负责员工发送邮件时

通常需要指定发送邮件时所用的合作伙伴功能。

● 规则类型：用于确定操作条件的设置方式，可以选择使用工作流（WF）或 BADI 增强

（COD）。如果使用工作流，即在计划条件和开始条件中使用规则编辑器，选择相关字

段，构造出条件公式。如果使用 BADI 增强则通过 BADI 实现。

● 操作合并：如何合并多个操作，例如一个操作定义最多有一个未处理的操作，或者一

种处理类型最多有一个未处理的操作等。

4）处理类型。即为该操作的底层执行方式，支持的类型有：

● 方法调用：调用某方法；方法调用中可以指定一些参数，如状态、事务类型等。

● 工作流：触发工作流。

● 外部通信：调用外部函数。

● 智能表单打印、传真：打印、传真智能表单。

● 智能表单邮件：将智能表单通过邮件的方式发送，比如业务活动的提醒通知，即为智

能表邮件。

见图 2.62（路径：配置 >CRM> 基本功能 > 操作 > 事务活动 > 定义操作参数文件和操作

> 动作定义 > 处理类型），退货申请行项目允许的动作处理类型为方法调用，即直调用某个类

的函数。退货请求申请操作（RETURN_REQ）中调用的方法为 RETURN_REQ。这里的方法调

用是一种 BADI 业务增强，即通过 BADI EXEC_METHDCALL _PPF 创建自定义的调用方法。在

这个 BADI 实施中，用户可以自定义业务处理

逻辑，例如自动创建后续凭证、生成 IDOC 向外部系统发送数据等。

5）条件。设定操作参数文件中的每个操作的计划条件和开始条件。根据规则类型的不同

对于工作流类型，可以使用工作流的条件编辑器，使用上下文属性构造各种复杂的条件，例

如状态、时间或日期规则等。如果使用 BADI 增强，则创建 BADI 实施，这里指定 BADI 实施的过滤值。在邮件智能表单发送中，可以设置处理参数，如接收人的邮件地址、邮件清单

或组织单元岗位等。（路径：配置 >CRM> 基本功能 > 操作 > 事务活动 > 更改操作和条件 > 定

义条件。）

6）操作参数文件确定。对于复杂的操作，可以使用条件技术确定所用的操作参数文件。

路径：配置 >CRM> 基本功能 > 操作 > 事务活动 > 设置操作参数文件确定。

7）分配。见本章 2.2.2.1 节。操作参数文件可以分配给订单类单据抬头，即事务类型，

也可以分配给单据的行项目类别。

8）操作监控。通过事务代码 SPPFP，可以查看、选择和处理操作。系统列出满足计划

条件操作，然后可以执行。也可以创建后台作业，定期执行一些满足计划条件的操作；后台

作业执行时，系统评估开始条件，满足开始条件则执行此操作。

图 2.62　操作类型


技术指南：

● 操作使用了 SAP 的后处理框架（Post Processing Framework，PPF），PPF 是 SAP 底层技术。操作定义

中，如果规则类型使用 BADI 实现，则操作的计划条件可以通过 BADI EVAL_SCHEDCOND_PPF 实

现，开始条件通过 BADI EVAL_STARTCOND_PPF 实现；而执行通过 BADI EXEC_METHODCALL_PPF 实现。例如实施 COPY_DOCUMENT 创建后续凭证，COMPLETE_DOCUMENT 设置凭证为完

成，CREDIT_MEMO 创建贷项凭证等，可以在 SE18 中查看该 BADI 的实施。

● 操作的配置可以参考：配置 >CRM> 基本功能 > 操作。除了业务事务以外，营销计划、开票、返

利、客户计划等应用中也使用操作，需要在对应的配置菜单中配置，配置步骤和方法与事务的操

作配置类似。

● 如果操作的处理时间选择通过报表选择处理，那么可以使用事务代码 SPPFP 启动该报表，在选择

条件中，可以指定对应的操作参数文件、操作、激活状态及时间范围等，然后系统列出满足条件

的操作，可以手工执行，也可以通过后台作业批量处理。但这时候需要考虑所后台作业所执行的

操作数量，如果数量过多，需要对操作的数据表 PPFTTRIGG 建立适当的索引，对于无法成功执

行的操作，需要注意，如果累计过多，并且每次都执行，会浪费系统资源（例如在状态中选择未

执行和未成功执行的操作，但因为有很多操作无法成功执行，这样每次都会执行这些操作）。

2.2.6　文本管理文本管理是 CRM 跨应用的基础功能。通过文本类型管理，可以为业务凭证、各种对象

和应用设置多种类型的文本注释。与普通的文本字段不同，文本注释是一种长文本，没有字

数限制，用于对事务及各种对象进行详细描述和说明。在不同的文本类型中维护不同的内

容，这样可以对说明文字进行分类、规范。文本管理的核心配置是文本确定过程，需要分配

到相关应用中，例如客户主数据、产品主数据、营销对象及订单凭证等应用。

应用举例：

● 投诉中，可以设置投诉内容、内部说明、解决方案。

● 在订单中可以设置交货说明；在业务活动中，可以设置客户拜访日程及拜访报告总结。

见图 2.63“商机中的文本类型”（路径：销售专员业务角色 > 销售周期 > 商机 > 注释），

显示了商机中的文本类型，一种单据类型（对象）可以分配一个或者多个文本类型，维护备

注时选择文本类型及语言，然后填写内容。

图 2.63　商机中的文本类型

下面介绍文本管理的功能和配置。


1. 文本编辑器

支持简易文本编辑器和 HTML 文本编辑器，HTML 文本编辑器中可以设置文本格式。

简易文本编辑器，仅支持文本内容，没有格式。自 SAP CRM 7.0 EHP1 增强包 1，可以使用

HTML 的文本编辑器，可以为文本设置字体、颜色等格式。同时可以在 HTML 模式和结果

显示模式中切换，即可以直接编辑文本的原始 HTML 内容。对于增强的 HTML 文本，需要

在定义文本类型时选择“带格式”的标识。

2. 文本类型

SAP CRM 系统中，文本对象为文本的实际应用对象，比如客户主数据（BUT000）、产

品主数据（Product）、单据抬头（CRM_ORDERH）、单据行项目（CRM_ORDERI）及营销项

目（CGPL_TEXT）等。每个文本对象中，可以定义一个或多个文本类型，文本类型即为对各

种备注长文本说明的分类。见图 2.64（路径：配置 >CRM> 基本功能 > 基本

功能 > 文本管理 > 定义文本对象和文

本类型 > 文本对象和标识），单据类订

单抬头（文本对象为 CRM_ ORDERH）中列出了部分使用的文本类型。比如

C001 到 C003 用户投诉单，C001 为投

诉内容，C002 为内部处理意见，而

C003 为解决方案。

3. 文本确定过程

文本确定过程包含可用的文本类型以及对文本的确定和控制，见图 2.65（路径：配置 > CRM> 基本功能 > 基本功能 > 文本管理 > 定义文本确定过程 > 文本对象 > 程序 > 程序定义）。

在文本对象中定义该对象可以使用的文

本确定过程。

● 选择文本确定过程中所包含的

为文本类型。从该文本对象的

文本类型中选择。

● 顺序：在文本确定过程中的顺序。

● 更改控制：是否只读或允许编

辑，是否保留日志。如果设置

为保留日志，那么每次对该文本的修改都会添加到原有文本中。

● 传输控制：即从前序对象中复制文本时的控制，允许完整复制文本或仅保存参考文本

链接或使用动态读取（即不保存在该对象中，读取时，从原有对象中读取）。

● 是否必填：该文本类型是否必填。

● 存取顺序：设定文本确定规则，自动复制或确定相关文本，例如将客户主数据中的交

货要求文本复制到销售订单中。

图 2.64　文本类型

图 2.65　文本确定过程中的文本


4. 存取顺序

文本的存取顺序用来确定文本。比如将客户主数据中的发货备注复制到销售订单抬头中

的发货备注中。见图 2.66（路径：配置 >CRM> 基本功能 > 基本功能 > 文本管理 > 定义文本确

定过程 > 文本对象 > 存取顺序），01 的存取顺序，表示从售达方客户主数据 BUT000 中的 0001发货备述文本类型复制到销售订单抬头中的发货备注中。

图 2.66　文本的存取顺序

5. 文本确定过程的分配

文本确定过程可以分配给订单类单据抬头，即事务类型，也可以分配给单据的行项

目。对于客户数据和营销对象，直接通过文本对象合作伙伴（BUT000）、营销项目（CPGL_TEXT）等确定。在订单类单据中，文本确定过程分配给对应的事务类型。一个事务类型拥有

一个文本确定过程，见本章 2.2.2.1 节。

6. 标准文本

可以定义标准文本（事务代码：SO10），填写文本名称，文本编号为 ST，选择语言，可

以维护标准文本内容。在应用的文本编辑器中，可以直接插入定义的标准文本。通过这种方

式，可以重复使用固定的文本，规范标准文本的应用。

技术指南：

● 定义文本类型时，如果需要将文本类型翻译成其他语言，需要用对应的语言登录系统，然后设定

文本类型描述。

● 在文本存取顺序中，如果通过指定数据源不能满足文本复制和确定要求，可以指定文本确定过程

的函数自行确定文本，有固定的输入和输出结构，可参考函数 CRM_TEXT_DETERMINE_TEXT。

2.2.7　调查问卷管理问卷（Survey）是 SAP CRM 的一种通用功能，可以用问卷工具设计与维护问卷，问卷维

护后可以通过配置分配给事务类型，这样在该类事务中即可使用。通过问卷可以收集各种数

据，对业务进行分析和评估。问卷在 CRM 的各种模块和业务流程中均可以使用，比如：

● 业务活动与外呼活动；


● 线索；

● 商机、报价单与订单；

● 服务订单。

应用举例：

● 服务完成后，例如购买机器、设备安装后，外呼业务活动中使用问卷对客户进行满意度调查，了

解客户满意度信息。

● 营销活动执行过程中，产生业务活动，并关联调查问卷，收集客户购买意向和市场信息。

● 线索中，通过调查问卷，收集客户购买意向程度，然后综合线索的其他信息对线索自动计算评

分，评分达到一定程度的，分配销售资源，进入商机跟踪处理阶段。

● 商机中，通过调查问卷对商机进行评估或收集商机相关信息。

商机中的评估即为该商机关联的调查问卷，可以关联一个或者多个调查问卷。见图 2.67“商机中填写调查问卷”（路径：销售专员业务角色 > 销售周期 > 商机 > 评估 > 明细），

商机中编辑该问卷，可以查看该问卷的内容，可以更改与填写。系统对填写的内容产生不同

的版本，同时记录处理时间与人员。

图 2.67　商机中填写调查问卷

1. 问卷的维护

调查问卷可以在 SAP GUI 中进行维护，也可以在 Web UI 中直接维护。SAP GUI 中，通

过事务代码 CRM_SURVEY_SUITE 维护问卷。

在 Web UI 中，问卷维护与 SAP GUI 中类似，界面更为友好与直观，见图 2.68“调查问

卷设计工具：Web UI”（路径：销售专员业务角色 > 销售运行 > 调查）。应用程序为该问卷所

属的应用，如业务活动、交互中心、营销、商机、服务及销售等各种应用，每个应用下面可

以创建多个问卷；问卷有版本管理，每次激活均产生一个新的版本；问卷具有状态（激活 /不激活），激活后方可使用；问卷支持多语言管理。打开问卷以后，可以预览。


图 2.68　调查问卷设计工具：Web UI

在 Web UI 中编辑问卷，即可以进入该问卷的设计模式，见图 2.69“调查问卷设计工具：

答案类型”（路径：销售专员业务角色 > 销售运行 > 调查 > 调查预览 > 编辑），这里对于每一

个问题，可以设置多个答案。答案有各种类型，比如是多选、单选或日期等。

图 2.69　调查问卷设计工具：答案类型

答案类型的种类主要有：输入字段、长文本、复选框、日期、时间、编号、单选、复选、

带多选的列表框、单选列表框、动态带多选的列表框或动态单选列表框等。

2. 问卷的确定

问卷的确定一般分配给事务类型或者事务类型的行项目类别，在维护该类型单据时，系

统即显示满足条件的问卷，可能有多个问卷。

图 2.70“业务活动中的问卷确定”（路径：配置 >CRM> 交易 > 活动设置 > 调查问卷 >定义调查问卷的确定：业务活动）为业务活动的问卷确定方法，即问卷确定过程。


图 2.70　业务活动中的问卷确定

问卷确定的主要配置是指定某个交易类型及行项目类别在一定的时间段所能使用的调查

问卷。配置参数说明如见表 2.19。

表 2.19　问卷的确定配置参数及说明

配置字段说　　明

确定和描述为任意设置的字符串，用于对问卷确定进行编号。描述即为该确定的名称

有效期设定有效期，即该确定在这个有效期之内才起作用

交易类型和项目

类别

交易类型为对应的单据类型，项目类别为行项目类别，因业务活动中通常没有行项目类别，

所以一般为空。通过指定项目类型，可以为项目类型分配问卷，问卷确定通常放在事务抬头中

调查标识每个确定指定一个调查问卷编号

必选 / 激活必填表示单据中该问卷是否必填；激活表示该确定是否激活，如果不激活，即不考虑这一个

问卷确定过程

2.3　小结本章介绍了 SAP CRM 中的基础数据（主数据）与一些常用的基础功能。介绍了业务合

作伙伴主数据管理，介绍了产品主数据管理，组织结构管理及组织数据确定，以及多种服务

数据（包括服务对象、安装点、计数器和读数、合同对象），介绍了知识文章与解决方案知识

管理数据。在基础功能中，本章节介绍了合作伙伴管理、业务事务及状态管理、定价与条件

技术、日期管理、操作、文本管理及调查问卷管理等基本功能。基本功能中也介绍了这些基

础功能的逻辑和配置，介绍了事务类型的基础配置，如何在事务类型中使用这些基础功能。

通过本章学习，可以了解 SAP CRM 的基础数据与基础功能，数据是整个系统的基石。

搭建良好的数据结构与基础功能是搭建企业流程的基础与关键。

sap crm 基础数据与基础功能 - baidu

Documents