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“合作伙伴功能的存取顺序”（路径：配置>CRM>基本功能>基本功能>合作伙伴处理>定义合伙人确认过程>功能明细），0001的存取顺序，该存取顺序包含两个存取10与20，系统先根据访问数序10从数据源先前凭证的活动合作伙伴中读取，如果未找到，系统就存取20中查找。这里的数据源为COM_PARTNER_A即先前凭证，系统从先前凭证中读取指定合作伙伴功能的数据，然后复制到目标合作伙伴功能（售达方）中。数据源即指定系统如何寻找合作伙伴的具体规则。系统提供了合作伙伴确定的数据源，并且可以通过BADI自定义数据源。
在线索及商机等事务中，可以使用重新确定合作伙伴的功能。例如当用于确定合作伙伴的数据已经修改，这是可以重新手工触发合作伙伴确定的功能。在事务抬头工具栏中，可以点击重新确定合作伙伴，系统即重新运行合作伙伴确定过程确定满足条件的合作伙伴。可以选择添加新合作伙伴、替换已存在的合作伙伴。添加新合作伙伴时，系统保留已确定或已录入的合作伙伴。替换已存在的合作伙伴即清除已确定或录入的合作伙伴，重新确定合作伙伴。在商机的购买中心中，合作伙伴的类别为联系人，重新确定购买中心的合作伙伴时，新增联系人的属性为空，需要设置属性如影响程度以及和其他联系人的关系；替换已有联系人后，系统先删除原有联系人，然后使用新联系人，但原有联系人的属性和关系将被删除。
推荐可替换的合作伙伴：即在事务中可以手工选择其他满足条件的合作伙伴。例如，客户有两个联系人，在凭证中已经确定并选择其中一个，但后来需要修改成另外一个联系人，即可以使用推荐功能，系统列出两个联系人供重新选择。
3.?合作伙伴相关的其他功能
合作伙伴处理与合作伙伴主数据：合作伙伴主数据是合作伙伴处理的重要数据，其中合作伙伴主数据的关系尤为重要。关系分成两类，一类是通用的关系，与销售范围无关；一类是销售范围相关的，设置在具体的销售范围中，该关系仅对设定的销售范围相关（在合作伙伴关系维护中，选择用法，然后在用法中选择销售范围并选择该销售范围下的合作伙伴功能）。在合作伙伴确定过程中这两种类型的客户关系均可以使用。
维护组织模型时，系统为组织单元生成合作伙伴数据，拥有组织单元的角色，可以应用到合作伙伴处理中使用。如在跨公司开票中，组织单元本身可以作为开票方。系统使用组织数据确定的规则确定组织单元所对应的合作伙伴，使用的数据源为CRM_PARTNER_B（根据组织数据确定合作伙伴），需要指定组织结构确定规则。
合作伙伴团队：合作伙伴团队是与特定的商机相关的一组客户或者人员。在商机中称为购买中心，购买中心中的成员均为联系人，合作伙伴功能类别为联系人，承担一定的功能，具有一定的关系，对项目的影响和重要程度也不尽相同。更多关于购买中心的功能可以参考4.2.4.2节的“购买中心”部分。
合作伙伴处理的基本配置路径为：配置>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.?事务类型和业务事务类别
事务类型（Transaction Type），也称为交易类型或业务类型，用于确定业务事务的性质以及相关的事务确定与处理，例如，如何确定合作伙伴、日期、文本及用户状态等。可以根据实际的业务需求，灵活定义各类事务类型。事务类型是事务处理的基础，创建事务时，首先需要选择或确定所用的事务类型，然后系统使用该事务类型的特性和控制功能。事务类型的关键分类是主要事务类别，其决定事务类型的性质和属性。
系统提供诸多标准的事务类型，可以参考标准事务类型新建所需的其他事务类型，如销售订单可分成标准订单、退货订单及寄售订单等各种类型，但都属于销售订单类别；销售合同、报价单也属于销售事务；而服务订单、服务合同、服务确认等为服务类的事务；营销中的线索、费用申索、资金计划及资金等也都属于事务类型。在SAP CRM中也称为统一订单类的凭证（One Order），或者称为订单类凭证类型。
应用举例：
业务活动：出差、拜访客户等使用的业务活动，交互记录，任务及电子邮件等。
销售订单：分成B2B网上订单、标准销售订单、退货订单、销售报价单等。
服务订单：分成常规保养订单、大保养订单、大修订单、中修订单、小修订单。
见图2.35“事务类型的基本配置”（路径：配置>CRM>交易>基本设置>定义业务类型>明细），列出了标准的投诉凭证类型的基本配置信息。事务类型编号为四位字符串，自定义的事务类型通常为Y或Z开始，在描述字段中设定该事务类型的名称。主要事务类别用于确定确定该凭证的业务分类与性质，如销售订单、服务订单、投诉、线索、商机或业务活
动等。
事务类型通过诸多参数确定系务该如何处理该事务，如参数文件中指定相关数据的确定方式。见图2.36“事务类型参数文件”（路径：配置>CRM>交易>基本设置>定义业务类型>明细），为事务类型指定各种参数文件，如：文本确定过程、合作伙伴确定过程、状态参数文件、组织数据确定参数文件、日期参数文件、操作（活动）参数文件及审批确定程序等。
图2.35 事务类型的基本配置 图2.36 事务类型参数文件
事务类型通常是事务的基础，牵引着诸多相关功能，在事务类型定义中，事务类型的主要功能点参见表2.14。
在事务类别分配中，一些常用的事务类别配置参见表2.15。
当然，有很多其他配置与事务类型相关，例如该事务类型所能使用的行项目类别，请参考相关章节的功能。事务类型的配置路径为：配置>
CRM>交易>基本设置>定义业务类型。
3.?行项目类别及行项目对象类型
行项目类别（Item Category）是对行项目属性、分类和控制的定义。行项目类别通常由事务类型及产品主数据的行项目类别组及用法共同确定。行项目类别中可以进行一些行项目的控制配置，如指定合作伙伴、文本、日期及操作等相关参数文件，
见图2.37“行项目类别”（路径：配置>CRM>交易>基本设置>定义项目类别>
明细）。
应用举例：
销售订单行项目类别：分成标准行项目（需要开具发票）、免费行项目、退货行项目。
服务订单行项目类别：标准服务行项目（需要开票）、免费服务、服务计划等服务诊断行项目。
行项目类别的主要配置和功能参见表2.16。
技术指南：
对象子类型：业务事务类别由一系列对象子类型（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“商机中的状态”（路径：销售专员业务角色>销售周期>商机），这是一种类型的商机的用户状态，为打开、处理中、成功、失败、停止及推迟等。
应用举例：
业务活动的用户状态：分成打开、处理中、已完成及已关闭。
服务订单处理的用户状态：打开、已分配、执行中、执行完成及关闭。
备件行项目用户状态：打开、已交货、已开票、已关闭。（同时ERP中交货后设置该项目的用户状态为已交货，ERP中开票或者CRM中对该行项目开票后自动设置用户状态为已开票。）
1.?状态参数文件
状态参数文件将多个用户状态组织在一起，并决定相关的控制参数。事务处理中，事务类型和行项目类别均可以分配一个状态参数文件。然后在该事务或行项目中即可使用对应的用户状态。见图2.39“状态参数文件”（路径：配置>CRM>交易>基本设置>状态管理>定义用户状态的状态参数），状态参数文件CRM ACTIV是CRM业务活动的标准的用户状态。
图2.39 状态参数文件
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（系统状态以及系统状态对业务事务的影响）；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美元。使用简易条件录入功能，可以简化事务中的价格维护。即在事务的行项目表格中直接填写价格，无需进入行项目价格页面中维护。通过系统配置，最多可以设置五个条件类型为简易录入的条件
类型。
可以在事务凭证的抬头或者行项目中维护价格。通常抬头显示的价格由行项目定价加总而成。根据定价过程对条件类型的配置，系统可以自动确定价格条件，也可以由用户手工录入或修改已确定的价格。如果设置为不能手工录入，该条件仅能通过定价条件主数据确定，用户无法修改。如果某条件类型不在已有列表中，可以添加，选择可用的价格条件，录入价格。可以重新执行定价，重新执行时可以选择是否要保留手工录入的价格条件，也可以让系统重新确定所有条件，即重置手工录入或修改的价格。行项目开票以后，行项目的价格即被固定，不能再次修改。
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 定价过程
定价过程的控制有：
每个条件均会指定一个顺序的级别，对于折扣加总、价格加总等可以设置加总条件类型的范围，例如总折扣金额设置了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元；如果是百分比折扣，那么会根据价格乘于这个百分比计算出折扣金额。手工输入表示是否允许手工录入，有一些条件必须通过计算得出，可以表示为不允许手工录入。项目条件表明该条件应用于订单的行项目中。
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 条件表
技术指南：
如果需要在事务中分析定价如何获取，可以在事务代码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。
下面简要介绍日期相关的配置及控制功能。
1.?日期类型及规则
通常根据业务需求定义各种类型的日期，定义日期的计算规则。而日期参数文件将日期类型、持续时间和日期规则组织在一起，实现对日期的控制和管理。下面介绍日期类型、持续时间和日期规则的定义和功能，路径为：配置>CRM>基本功能>日期管理>定义日期类型，持续类型和日期规则。
日期类型。可以定义各种日期类型，指定编号和描述，如开票日期，报价开始日期等。
“日期参数文件”标识：该日期类型是否可以在日期参数文件中使用。
“里程碑”标识：该日期是里程碑日期，用于商机管理中。通常的日期类型包括日期和时间，并且由开始日期和结束日期成对组成，即持续一段时间。而里程碑日期不包含具体时间，同时无法设置持续周期。
持续时间。持续时间（Duration）用来定义两个时间点之间的间隔。持续时间可以用于日期参数文件中，指定持续时间数量和单位，用于计算日期，比如响应时间为接收到客户的服务请求后的四个小时。持续时间配置中仅指定编号和名称，应用到日期参数文件时才需要指定数量和时间单位。
日期规则。用于确定如何计算该日期，可以通过XML定义日期计算公式或者函数计算出来。日期规则中可以使用其他类型的日期、持续时间以及参考对象。日期参数文件中的每个日期类型均可以分配一个日期计算规则，然后系统根据此规则确定日期。
见图2.54（路径：配置>CRM>基本功能>基本功能>日期管理>定义日期类型，持续类型和日期规则>日期规则），日期规则维护的编辑器。这是一种基于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
（路径：配置>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，也称为活动、动作）为满足一定条件时所触发的相关动作，比如创建后续单据、提醒、输出打印及触发工作流等。操作是流程自动化、维持良好的客户关系的重要工具和功能。通过定义各种操作和条件，可以在适当时候触发相关动作，例如通知提醒等。在CRM中，输出确定也使用CRM操作技术。
在实际应用中，操作具有多种表现形式。例如凭证的操作信息块中，可以列出或执行关联的操作；事务抬头或行项目的工具栏按钮可对应于某个操作；在保存或更改时，系统也可以触发相关操作。见图2.58“商机中的销售助理功能”（路径：销售专员业务角色>销售周期>商机），这是商机的销售助理功能，即为系统定义的一系列的操作。不同阶段可以定义不同的工作任务，激活以后，系统即自动为该商机创建后续业务活动，分配相关人员进行处理，可以规范销售的具体过程，规范没有销售环节中需要完成的各种任务。销售助理功能，即通过CRM操作实现。
应用举例：
事务处理：如创建后续事务创建后续的任务、业务活动等相关凭证；合同结束前自动创建合同报价单；投诉中自动创建贷项凭证、退货、发货等行项目；商机中根据销售助理创建工作任务；服务处理中根据时间的响应触发服务升迁处理。
输出和数据发送：如订单释放时，调用操作将订单相关数据通过IDOC方式发送给合作伙伴。
打印和预览：使用智能表格打印单据，同时可以在单据明细中预览打印效果。
通知：服务请求、服务订单、业务活动等的邮件通知，审批通知等。
了解CRM的操作管理，可以从操作、条件以及操作参数文件着手，了解操作在各种业务中的应用及控制。如图2.59“CRM操作定义与执行”所示，操作参数文件中包含一个或者多个自定义的操作，每一个操作均会执行一些功能，通过操作方法指定（如调用业务对象方法、创建后续业务凭证、触发工作流、调用智能表格进行通知或打印等）。满足计划条件时，该操作进入计划阶段，例如可以显示在对话框清单中。满足开始条件时，即可以执行此操作。操作参数文件分配到事务类型或者行项目类别中。
图2.59 CRM操作定义与执行
下面以标准的投诉行项目的操作为例，介绍操作参数文件和操作的控制。
1）全局配置。新建或复制操作参数文件时，首先要设定操作参数文件的全局参数。双击操作参数文件设置全局参数，主要有：
对象类型：活动参数文件用于哪个对象类型中，例如用于投诉行项目的对象类型为BUS2000160。指定对象类型后，在操作条件中能够使用该对象类型的属性。
日期参数文件：如果使用时间相关的条件，可以使用日期参数文件中的日期规则。
上下文类：指定确定上下文属性的程序类，例如订单通常为CL_DOC_CONTEXT_CRM_ORDER。
2）操作。一个操作参数文件中包含一个或者多个操作，每一个动作定义了具体的触发方式，需要完成的功能。动作由编号和描述组成，可以设置显示顺序、是否激活；见图2.60（路径：配置>CRM>基本功能>操作>事务活动>更改操作和条件>定义操作参数文件和操作），这是投诉单中投诉行项目的标准操作参数文件，该参数文件中定义了多个动作，CREDIT是创建贷项凭证子项目，DEBIT是创建借项凭证子项目，RETURN_REQ是创建退货申请子项目，SUBST_DEL是创建替代发货子项目，TASK_ITEM是创建单独的后续处理任务。系统会拷贝投诉行项目，将相关信息、比如产品编号及数量等复制到后续创建的子项目中。
3）动作明细。见图2.61（路径：配置>CRM>基本功能>操作>事务活动>定义操作参数文件和操作>动作定义明细），以RETURN_REQ退货申请行项目为例说明动作的明细控制。
处理时间：包括立即处理、用选择报表处理及保存文档时处理。立即处理即满足条件时即处理，例如点击生成退货或发免费发货行项目时，立即产生子行项目；用选择报表处理即满足计划条件时，操作进入选择报表（事务代码：SPPFP）中，满足执行条件时，可以执行该操作，通常设置后台作业，自动定期执行选择报表中的操作；保存文档时处理，即保存时如果满足条件则执行此操作。
自动计划：即如果满足计划条件时，是否自动执行该操作。如果不选择，计划以后，需要手工触发或者使用选择报表触发才能执行该操作。
处理后删除：指成功处理后删除该操作，如果处理错误，则不会被删除。
显示和执行：是否显示在对话框即操作处理页面中，是否可以在对话框中手工执行，是否可以更改。
合作伙伴确定：即指定操作所用的合作伙伴功能，例如为客户或负责员工发送邮件时通常需要指定发送邮件时所用的合作伙伴功能。
规则类型：用于确定操作条件的设置方式，可以选择使用工作流（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，可以查看、选择和处理操作。系统列出满足计划条件操作，然后可以执行。也可以创建后台作业，定期执行一些满足计划条件的操作；后台作业执行时，系统评估开始条件，满足开始条件则执行此操作。
技术指南：
操作使用了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>基本功能>基本功能>文本管理>定义文本确定过程>文本对象>程序>程序定义）。在文本对象中定义该对象可以使用的文本确定过程。
选择文本确定过程中所包含的为文本类型。从该文本对象的文本类型中选择。
顺序：在文本确定过程中的顺序。
更改控制：是否只读或允许编辑，是否保留日志。如果设置为保留日志，那么每次对该文本的修改都会添加到原有文本中。
传输控制：即从前序对象中复制文本时的控制，允许完整复制文本或仅保存参考文本链接或使用动态读取（即不保存在该对象中，读取时，从原有对象中读取）。
是否必填：该文本类型是否必填。
存取顺序：设定文本确定规则，自动复制或确定相关文本，例如将客户主数据中的交货要求文本复制到销售订单中。
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。