Business Scenario

Configuration Guide

Sales and Order

Management
using SAP CRM 7.0
Enhancement Package 3

Document Version 3.1 – April 2014

1
Configuration Guide

Contents
1 BASIC SETTINGS FOR SALES ............................................................................................................... 7
1.1 SETTING U P ORGANIZATIONAL UNITS .................................................................................................. 7
1.1.1 Use ................................................................................................................................................. 7
1.1.2 Procedure ...................................................................................................................................... 8
1.1.3 Result ............................................................................................................................................. 8
1.2 CREATING A ROOT ORGANIZATIONAL UNIT .......................................................................................... 8
1.2.1 Procedure ...................................................................................................................................... 8
1.3 MAINTAINING THE SALES ORGANIZATION ............................................................................................. 8
1.3.1 Procedure ...................................................................................................................................... 9
1.4 DETERMINING ORGANIZATIONAL DATA ................................................................................................. 9
1.4.1 Use ................................................................................................................................................. 9
1.4.2 Prerequisites ...............................................................................................................................10
1.4.3 Features.......................................................................................................................................10
1.5 ORGANIZATIONAL D ATA AT ITEM LEVEL..............................................................................................11
1.5.1 Settings for Organizational Data at Item Level .........................................................................11
1.6 SETTING UP BUSINESS PARTNER .......................................................................................................12
1.6.1 Creating Business Partner .........................................................................................................12
1.6.2 Replication of Business Partners ...............................................................................................12
1.7 SETTING UP BUSINESS AGREEMENTS ................................................................................................13
1.7.1 Creating Business Agreements .................................................................................................13
1.8 BUSINESS RULE FRAMEWORK IN SAP CRM FOR T ELECOMMUNICATIONS .........................................16
1.8.1 General Information ....................................................................................................................16
1.8.2 Preparatory step: Copy BRF Objects from source client 000 ..................................................17
1.8.3 Tags .............................................................................................................................................17
1.8.4 Tag Groupings, Hierarchies and Criteria ...................................................................................18
1.8.5 Configure Business Rule Framework ........................................................................................21
1.8.6 Simulation of BRF-Events ..........................................................................................................23
1.9 ACCESS TO CRM W EB UI..................................................................................................................24
1.9.1 Prerequisites ...............................................................................................................................24
1.9.2 Business Roles ...........................................................................................................................24
1.10 IMPORT OF KNOWLEDGE BASE ...........................................................................................................24
1.10.1 Purpose ...................................................................................................................................24
1.10.2 Prerequisites ...........................................................................................................................25
1.10.3 Customizing of Knowledge Base Exchange.........................................................................25
1.10.4 Start Knowledge Base Transport (In Source System) .........................................................26
1.10.5 Check if Knowledge Base has arrived ..................................................................................27
1.11 SETTINGS FOR PARTNER DETERMINATION PROCEDURE ....................................................................27
1.11.1 Partner Processing .................................................................................................................27
1.12 SETTING U P CARD PAYMENT .............................................................................................................29

2
Configuration Guide

1.12.1 Use ..........................................................................................................................................29

1.12.2 Procedure................................................................................................................................29
1.13 DISTRIBUTION TO SAP PI ..................................................................................................................33
1.13.1 Use ..........................................................................................................................................33
1.14 ORDER DISTRIBUTION INFRASTRUCTURE ...........................................................................................34
1.14.1 Comparison of Distribution Models in SAP CRM 7.0 EHP3 and SAP CRM 7.0................34
1.14.2 Framework ..............................................................................................................................35
1.14.3 Distribution Schema and Settings .........................................................................................38
1.14.4 User Interface .........................................................................................................................42
1.14.5 Batch Report ...........................................................................................................................49
1.15 DISTRIBUTION OF ONE-OFF-CHARGES TO SAP ERP ........................................................................50
1.16 DISTRIBUTION OF DATA TO SAP ERP USING ODI..............................................................................50
1.16.1 Use ..........................................................................................................................................50
1.16.2 Procedure................................................................................................................................50
1.16.3 Class CL_CRM_ISX_ORDER_MD_ERP .............................................................................50
1.16.4 Prerequisites ...........................................................................................................................51
1.16.5 Schema Definition ..................................................................................................................51
1.16.6 BAdI .........................................................................................................................................52
1.16.7 ODI Customizing Setting........................................................................................................52
1.16.8 RFC Destination .....................................................................................................................52
1.16.9 Optional ODI-Step for Activation of Provider Contracts in SAP Convergent Charging .....53
1.16.10 Handling of Technically Failed ODI Steps ............................................................................53
2 BASIC SETTINGS FOR BUSINESS SCENARIOS USING PROVIDER CONTRACT
MANAGEMENT .................................................................................................................................................54
2.1 INDUSTRY-SPECIFIC PRODUCT TERMS ...............................................................................................54
2.2 RECOMMENDATIONS FOR SETTING UP PRODUCT MASTER DATA .......................................................56
2.2.1 Sales Package vs. Configurable Products ................................................................................57
2.2.2 Modeling of Configurable Products ...........................................................................................58
2.2.3 Recommendations on Product Structure for Usage in Provider Web Shop ...........................59
2.2.4 Recommendations on Product Structure using Lean Customizing .........................................60
2.2.5 Product Purpose .........................................................................................................................62
2.3 RECOMMENDATIONS FOR SETTING UP INTEGRATION WITH SAP CONVERGENT CHARGING................62
2.3.1 Cross Catalog Mapping in Documents ......................................................................................62
2.3.2 Enhancement Concept ...............................................................................................................63
2.3.3 Price Versions .............................................................................................................................69
2.4 SETTING U P W EB SERVICES FOR C OMMUNICATION TO SAP CC .......................................................70
2.5 PRODUCT MAINTENANCE ...................................................................................................................70
2.5.1 Business Roles for Maintaining Product Master Data ..............................................................70
2.5.2 Roles for Defining Packages ......................................................................................................71
2.5.3 Customer-specific Roles for Defining Packages ......................................................................71
2.5.4 Define Rate Plans .......................................................................................................................71
2.5.5 Define Combined Rate Plans .....................................................................................................71
2.5.6 Define Sales Packages ..............................................................................................................72
3
Configuration Guide

2.5.7 Define Dependent Components ................................................................................................73

2.5.8 Triggering Solution Configurator Decomposition ......................................................................74
2.5.9 Integration of Recurring Charges with SAP CC........................................................................75
2.5.10 Billing Discount Assignment ..................................................................................................79
2.6 ITEM CATEGORIES AND TRANSACTION TYPES ....................................................................................80
2.6.1 Overview Item Categories and Transaction Types ..................................................................80
2.6.2 Lean Items in Provider Orders ...................................................................................................81
2.6.3 Display of Lean Items .................................................................................................................82
2.6.4 Settings for Item Category Determination Procedure ..............................................................83
2.6.5 Settings for Provider Item Categories .......................................................................................84
2.6.6 Replication of Provider Orders to SAP ECC .............................................................................85
2.6.7 Use ...............................................................................................................................................85
2.6.8 Prerequisites ...............................................................................................................................85
2.6.9 Procedure ....................................................................................................................................85
2.6.10 Bill Period Management in SAP CRM ..................................................................................86
2.7 PRICING .............................................................................................................................................91
2.7.1 Document Pricing Procedures for Provider Order ....................................................................91
2.7.2 Condition Group for Price Maintenance ....................................................................................91
2.7.3 Pricing Procedures and Condition Types..................................................................................91
2.7.4 Further requirements for condition types ..................................................................................93
2.7.5 Process-dependent Pricing ........................................................................................................95
2.7.6 Billing Plan ...................................................................................................................................97
2.7.7 Define Price Dependencies........................................................................................................98
2.7.8 Condition Exclusion ....................................................................................................................98
2.7.9 “0,00” Prices ..............................................................................................................................100
2.7.10 Variant Conditions ................................................................................................................101
2.7.11 Activation Date in Pricing .....................................................................................................104
2.8 PREPAID ACCOUNT ..........................................................................................................................105
2.8.1 Use .............................................................................................................................................105
2.8.2 Prerequisites .............................................................................................................................106
2.8.3 UI Configuration ........................................................................................................................107
2.8.4 Integration with SAP ERP ........................................................................................................107
2.8.5 Integration with SAP CC ...........................................................................................................108
2.8.6 Archiving ....................................................................................................................................109
2.8.7 BAdIs .........................................................................................................................................109
2.8.8 Prepaid Data in Business Agreement .....................................................................................109
2.8.9 Change Indicator: Prepaid Data in Business Agreement ......................................................110
2.9 SERVICE D ATA DISTRIBUTION TO SAP RM-CA ...............................................................................110
2.9.2 Configure Dunning Activities ....................................................................................................112
2.9.3 Configure Dunning Procedure .................................................................................................112
2.10 TECHNICAL RESOURCE MANAGEMENT .............................................................................................113
2.10.1 Technical Resource Management With a Contract Extension .........................................113
2.10.2 Technical Resource Management with Individual Object .................................................114

4
Configuration Guide

2.11 TECHNICAL RESOURCES AND BRF ..................................................................................................118

2.11.1 Delivery Customizing Switched with CRM_PROV_EHP2 .................................................118
2.11.2 Example Customizing ..........................................................................................................120
2.11.3 New Criterion for Additional Item Information ....................................................................121
2.12 SETTINGS FOR THE VISIBILITY OF THE RISK CLASS ............................................................................121
2.13 SETTINGS FOR INTEGRATION OF CREDIT MANAGEMENT ...................................................................122
2.14 DATE PROFILES FOR SAP CRM ......................................................................................................122
2.14.1 Contract Change Based on a Correct Time .......................................................................124
2.15 CONTRACT C REATION AND PROCESSING .........................................................................................126
2.15.1 Asynchronous Creation of Provider Contracts ...................................................................126
2.15.2 Status of Provider Orders and Contracts............................................................................127
2.15.3 Copy of Order Items in the Contract ...................................................................................128
2.15.4 Manual Activation of Provider Contracts ............................................................................128
2.16 SETTINGS FOR CHANGE PROCESSES ...............................................................................................132
2.16.1 General and Important Information about Change Processes..........................................132
2.16.2 Settings for Change Process ”Product Change” ................................................................134
2.16.3 Revoke Processes ...............................................................................................................135
2.16.4 Settings for Change Process Move ....................................................................................135
2.16.5 Settings for Change Process “Cancellation” ......................................................................135
2.16.6 Example: Settings for Telecommunications-Specific Lock Processing ............................136
2.16.7 Customer Specific Change Processes ...............................................................................144
2.16.8 Definition and Implementation of ISTB Change Processes ..............................................147
2.16.9 Freeze of Activation Date During Product Change Process .............................................148
2.16.10 Billing Cycle Changes During Product Change Process ...................................................149
2.16.11 Business Agreement Change Process ...............................................................................149
2.17 WORKFLOWS FOR PROVIDER TRANSACTIONS ..................................................................................149
2.18 SETTINGS FOR THE ANALYSIS OF T ELECOMMUNICATIONS CONTRACTS ............................................152
2.19 API PROVIDER .................................................................................................................................153
2.19.1 Interface for Order Creation.................................................................................................153
2.19.2 Interface for Creating a Contract .........................................................................................159
2.19.3 Interface for Contract Change .............................................................................................161
3. INTERACTION CENTER............................................................................................................................164
3.1 BASIC SETTINGS FOR INTERACTION C ENTER ...................................................................................164
3.1.1 Define Business Role ...............................................................................................................164
3.1.2 Define BRF Events for the Contract History ...........................................................................165
3.1.3 Define Identification Type for Verification Word .....................................................................166
3.1.4 Create and Assign Reference Business Partner ....................................................................166
3.2 PRICING SETTINGS FOR INTERACTION C ENTER ................................................................................167
3.2.1 Price List ....................................................................................................................................167
3.2.2 Discounts ...................................................................................................................................168
3.2.3 Discount Status .........................................................................................................................169
3.3 SETTING U P PRODUCT SEARCH.......................................................................................................170
3.3.1 Activate Product Search in Product Master Data ...................................................................170
5
Configuration Guide

3.3.2 Define Catalog Profiles for Product Search ............................................................................170

3.4 TAX CALCULATION IN PRODUCT SEARCH .........................................................................................171
3.4.1 See Also ....................................................................................................................................171
3.5 DISPLAY OF USER STATUS AND ORGANIZATIONAL DATA ..................................................................171
3.6 ORGANIZATIONAL U NITS AND THE INTERACTION CENTER .................................................................172
3.6.1 Assignment of Users in the Organizational Model .................................................................172
3.6.2 Organizational Unit Selection in the Interaction Center .........................................................173
3.7 INTEGRATION WITH REAL TIME OFFER MANAGEMENT ......................................................................173
3.7.1 General Information ..................................................................................................................173
3.7.2 Settings for Interaction Center .................................................................................................173
3.7.3 Configuration of Web Services ................................................................................................184
3.7.4 Additional Information ...............................................................................................................186
3.8 INFORMATION SECURITY ..................................................................................................................189
3.9 MAINTAINING INFORMATION SECURITY PROFILES ............................................................................190
3.10 ASSIGNING INFORMATION SECURITY PROFILES TO USERS ...............................................................190
3.11 BROWSER SETTINGS .......................................................................................................................191
3.12 BUSINESS PARTNER SEARCH ..........................................................................................................191
3.13 INTEGRATED COMMUNICATION INTERFACE ......................................................................................192
3.14 SAP BUSINESS C OMMUNICATIONS MANAGEMENT ...........................................................................194

6
Configuration Guide

This configuration guide contains information about the settings that are required for the Business
Scenario Sales and Order Management. Information about the basic settings for SAP CRM 7.0
Enhancement Package 3 can be found in the Solution Manager - Basic Settings for SAP CRM 7.0 EHP3
(SAP CRM 7.0 Enhancement Package 3).
This configuration guide is divided into the following main chapters
Basic Settings for Sales
This part covers basis system configuration such as making settings related to the sales
organization or master data. It also describes the Sales and Order Management interfaces in
SAP CRM with other systems and the way in which systems can be connected, for example for
general order distribution. Additional information about integration with SAP Convergent Charging
and SAP Convergent Invoicing is provided. Information about the specific settings for intergration
with SAP Convergent Charging and/or SAP Convergent Invoicing in SAP ERP is also provided
here.
Basic Settings for the SAP for Telecommunications business scenario
This chapter deals with specific settings are mainly used within the telecommunications industry.
It mainly focuses on the settings and configuration to be made for product modeling and order
capturing for these products.
If you are using SAP CRM Sales and Order Management as an integrated scenario with SAP
Convergent Charging, SAP Convergent Invoicing and/or SAP Credit Management and not as a
standalone scenario, you have to make additional settings. These settings are either highlighted
by a comment for Integration with* or are collected in separate subchapters.
Integration with SAP Convergent Charging and SAP Convergent Invoicing gives you the option of
handling contracts with prepaid products. If you want to use this option, you need to make
specific settings that only apply to the prepaid scenario. These settings are highlighted with the
comment relevant for prepaid.
In a prepaid scenario, you can use the prepaid account as additional master data. The settings
for maintaining and replicating prepaid accounts are also described here.
Interaction Center
This configuration guide focuses on the business scenario Sales and Order Management. This
chapter contains relevant information about the configuration and set up of the Interaction Center
for the SAP Sales and Order Management functions.

1 Basic Settings for Sales

1.1 Setting Up Organizational Units
1.1.1 Use
Organizational Management in SAP CRM offers a flexible tool that you can use to represent your
company’s task-related, functional organizational structure as a current organizational plan.
The representation of your sales structure is at the forefront of SAP CRM. Therefore, to work in the SAP
CRM system, you only have to map the organizational units that are relevant for your sales-related
transactions.

7
Configuration Guide

You can find more information about Organizational Management in the SAP Library for Customer
Relationship Management under http://help.sap.com SAP Business Suite SAP Customer
Relationship Mgmt. SAP CRM 7.0 Enhancement Package 2 SAP Customer Relationship
Management Master Data Organizational Management in CRM.

1.1.2 Procedure
In the following process steps, you make the settings for Organizational Management and the automatic
determination of organizational data in the transaction. In Customizing, choose Customer Relationship
Management Master Data Organizational Management Organizational Model Create
Organizational Model.

1.1.3 Result
You have created an organizational model with customer-specific organizational units that are permitted
for the sales scenarios. The assignment of the organizational data profile and determination rule to the
standard transaction type PRVO (Provider Order) means that the relevant organizational data is now
retrieved (for example, using the postal code from the Internet user’s address data) when a service
request is created in SAP CRM.

1.2 Creating a Root Organizational Unit

As described in the SAP Library for Customer Relationship Management under http://help.sap.com
SAP Business Suite SAP Customer Relationship Mgmt. SAP CRM 7.0 Enhancement Package
3 SAP Customer Relationship Management Master Data Organizational Management in CRM
Data Exchange for Organizational Data Copying the Sales Structure from SAP ECC to CRM, you
can replicate organizational structures from the SAP ECC system to the CRM system. However, this is
only valid for sales structures. You must create service structures in the CRM system manually.

1.2.1 Procedure
If you have chosen not to replicate the sales structure from SAP ECC or if you are operating the SAP
CRM system as a standalone system and thus the organizational model of your enterprise is not yet
mapped, proceed as follows:
...

1. In Customizing, choose Customer Relationship Management Master Data Organizational

Management Organizational Model Create Organizational Model.
2. Create an organizational structure beginning with a root organizational unit and staff assignments.
3. Confirm the dates suggested by the system, or select another validity period.
4. Choose Continue. The system creates the root organizational unit and assigns to it an ID.
5. On the tab Basic Data enter an abbreviation and a name for the automatically created
organizational unit. You can also enter a description.
6. Save the data. By saving the data the system automatically creates a business partner number for
the root organizational unit.

1.3 Maintaining the Sales Organization

You can carry out these activities to create a sales organization for the first time, or to maintain sales
organizations replicated from the SAP ECC system.

8
Configuration Guide

1.3.1 Procedure
...

1. In Customizing, choose Customer Relationship Management Master Data Organizational

Management Organizational Model Change Organizational Model.
2. Choose the root organizational unit in the view Assignment Plan (CRM).

If your previously created root organizational unit is not automatically displayed, look for it with the locator.
3. Select the organizational unit and choose Create in the context menu.
4. Choose Is Line Supervisor of Organizational Unit.
5. Enter an abbreviation and a name for the newly created organizational unit.
6. On the tab Address, enter the address of the organizational unit.
7. On the tab Attributes, choose Sales in the field Attribute Maintenance Scenario.
8. Set the Sales Organization indicator.

If the higher-level organizational unit is a sales organization, this indicator is set automatically, as it is
inherited. This means that you only need to set it if you create an organizational unit directly under the
root organizational unit.
9. Enter the key of the corresponding SAP ECC sales organization in the field R/3 sales org.

If the CRM system is a standalone system, leave the field empty.

10. Enter values for all relevant attributes on the tab page Attributes (you must enter a value for the
attribute Country/Land and should maintain a currency. For CRM Telco, no special attributes are
needed). If not all attributes are visible, choose All Attributes.
11. Choose Check in the line Status of Consistency Check. The message monitor turns green. If this
does not happen, choose Display Search Results for Details.
12. Perform these steps for each individual sales organization.

Below the root organizational unit you can include organizational units that are not marked as sales
organizations in your sales organization (for example, sales offices). This can be useful with respect to
structuring the organizational model. You do not assign any attributes to these organizational units.

1.4 Determining Organizational Data

1.4.1 Use
When processing a business transaction, certain organizational data is mandatory depending on the
transaction type. In a service order, for example, the service organization that is responsible for
processing is a determining factor. The distribution channel in a sales order is as important as the
responsible sales organization, as price and delivery data can depend on the distribution channel.
In the CRM system you have the following options for determining organizational data in the document.
You can set these in customizing depending on the transaction type:

no determination
In this case, enter the organizational data (for example, sales area) manually in the document.

9
Configuration Guide

automatic determination
The system determines organizational data using the data available in the document, for example, the
business partner number, region, product, or using the user assignments for the organizational unit (using
the position).

1.4.2 Prerequisites
1.4.2.1 No automatic determination
You have created an organizational data profile in customizing, in which no determination rules have
been entered.
You have assigned this organizational data profile to the required transaction type.
1.4.2.2 Automatic determination
You have created a determination rule in customizing for each determination path with the corresponding
rule type.
You have defined one or two determination rules in the organizational data profile for evaluating the
organizational data profile of a transaction.
You have assigned the organizational data profile to a transaction type.
You carry out the settings in Customizing under Customer Relationship Management -> Master Data
Organizational Management Organizational Data Determination. You can find further information in the
documentation there.

1.4.3 Features
When determining organizational data, the system takes the organizational data profile defined in
Customizing and the determination rules from this profile. These determination rules specify which fields
are taken into account when the system determines organizational data from the document data (for
example, business partner number or telephone number). Determining organizational data can be set by
assigning the organizational data profile for the business process type so that it is dependent on the
transaction type.
There are two determination paths provided in the SAP CRM system that have been characterized for the
two rule types:
Rule type Responsibilities
For more information, see SAP Library for Customer Relationship Management under http://help.sap.com
SAP Business Suite SAP Customer Relationship Mgmt. SAP CRM 7.0 Enhancement Package
2 SAP Customer Relationship Management Master Data Organizational Management in CRM
Determining Organizational Data Rule Resolution Using Responsibilities
Rule type Organizational Model
For more information see SAP Library for Customer Relationship Management under http://help.sap.com
SAP Business Suite SAP Customer Relationship Mgmt. SAP CRM 7.0 Enhancement Package
2 SAP Customer Relationship Management Master Data Organizational Management in CRM
Determining Organizational Data Rule Resolution Using Organizational Model
The basis rule types Organizational Data and Function Module are available in SAP CRM, but to use
them you must have ABAP/4 knowledge. You can find information on these rule types in the basis
documentation.
Defining rules using organizational data
Defining rules using function to be executed
If you define two determination rules in the organizational data profile, the system creates the intersection
of the results delivered by each of the two rule resolutions.

10
Configuration Guide

Determining organizational data can differ according to the scenario, because an organizational unit in
the Sales scenario can have different attributes with different values from an organizational unit in the
Service scenario.

1.5 Organizational Data at Item Level

If you do not use a header division in business transactions, the Division attribute only exists at item level.
In this case the division is derived from the product and all of the organizational data at item level of a
document, except for the division, may not differ from those on the header level. There is therefore no
individual organizational data determination at item level. The following options for organizational data at
item level are possible. You can make these settings in Customizing. They are dependent on the item
category.

1.5.1 Settings for Organizational Data at Item Level

Organizational data at item level Settings you must make in Customizing
Without header division: Assign an organizational data profile without a
The organizational data is copied from the determination rule to the item category.
document header. The division is derived from
the product.
With header division: Assign an organizational data profile without a
The organizational data is copied from the determination rule to the item category.
document header. The division is derived from
the document header.
There is no organizational data at item level Do not assign the organizational data profile to
(no organizational data screen) the item category.

You can find more information about the header division in Customizing under Customer Relationship
Management Master Data Organizational Management Division Settings.
1.5.1.1 Activities
...

1. The system determines the responsible organizational unit.

2. The system reads the other attribute values for this organizational unit, and, if necessary, uses
them to determine other data, for example, the distribution channel.
If the system determines more than one responsible organizational unit or determines several
attribute values for the responsible organizational unit, a selection screen appears.

In Customizing, select Customer Relationship Management Master Data Organizational

Management Organizational Data Determination Change Rules and Profiles:
-> Maintain Determination Rules
-> Maintain Organizational Data Profile
-> Assign Organizational Data Profile To Transaction Type
-> Assign Organizational Data Profile to the Item Category

11
Configuration Guide

1.6 Setting up Business Partner

1.6.1 Creating Business Partner
1.6.1.1 Use
You need business partners in order to represent in the system all the parties involved in business
transactions, that is, persons, groups of persons and organizations (for example customer, debitor,
creditor, supplier).
Basically, you can either download business partners from SAP ECC or create them in SAP CRM. Also
have a look at Replication of Business Partners.
1.6.1.2 Procedure
Create your business partners in the SAP CRM application on the Corporate Account and Individual
Account pages. Assign the appropriate role to the account.
Create a Business Partner with role Employee using transaction BP and assign your user to it on tab
Identification (field User Name).

1.6.2 Replication of Business Partners

In case that business partners are created in the SAP CRM system and replicated to an SAP ERP
system, it is important that Customizing settings are identical. In SAP CRM, it is possible to define a
verification word for every customer, which is based on a specific identification category (IST001). This
category must be created in the SAP ERP system as well, so that replication is working.
If the customer creates other verification types in the SAP CRM system, they must also be created in the
SAP ERP system.
1.6.2.1 Procedure
To enable replication of business partners, create BP identification category IST001 (IS Telco Password)
in the SAP ERP system. Also create BP identification type IST001 for category IST001 in the SAP ERP
system. In case you create customer-specific identification types in SAP CRM, you have to ensure that
they are also available in the SAP ERP system.
You must perform an initial data transfer before the new business partner data is replicated from
SAP CRM to SAP RM-CA. Use the transaction R3AS to transfer the business partner data to SAP CRM.
You must use the BUPA_MAIN business object (and not CUSTOMER_MAIN) to exchange business
partner data in a telecommunications system landscape (with SAP FI-CA as a back-end system).
During the initial download of business objects, note that you cannot load dependent objects, such as the
business partner relationship (BUPA_REL), into SAP CRM until you have successfully imported the
business partner (BUPA_MAIN).
1.6.2.2 See also
For more information on identification categories in SAP ERP, also have a look at the configurations
guides of the SAP ERP system, which you can find on the service market place under:
http://service.sap.com/instguides.
For more information on how to replicate business partner, see also http://service.sap.com/utilities SAP
for Utilities - Product Information SAP CRM for Utilities Cookbooks & Guidelines IS-U-specific
Set-up and Load Guide for Business Partner

12
Configuration Guide

1.7 Setting up Business Agreements

1.7.1 Creating Business Agreements
1.7.1.1 Use
In the business agreement, you can store controlling data for long-term business relationships with a
business partner that can be used for exactly these purposes:
This data controls processes in invoicing, contract accounts receivable and payable, taxation, and
correspondence processing. You can define several business agreements for each business partner.
You can activate the business agreement function in Customizing. The function allows you to connect the
SAP ERP component FI-CA in the SAP system with SAP CRM.
1.7.1.2 Implicit/Explicit Business Agreement Handling
Although the business agreement is required as master data for the integrated scenario that uses SAP
CRM and FI-CA in the SAP ERP system, in certain cases a configuration in which the business
agreement is not visible on the UI may be required. In this situation the agent only selects or assigns
payment data without explicitly deciding on the dependent processes that relate to the business
agreement. For other processes the business agreement needs to be visible, for example, to put a
contract together for one invoice. In this case, the agent has to select a specific business agreement and
requires views that display the business agreement explicitly.
In Customizing for Customer Relationship Management under Cross Industry Functions -> Provider
Contract Management -> Transactions -> Define Settings for Transaction Types you can define whether
you want to use the explicit logic for business agreement handling during order capture (business
agreement is visible and can be chosen by the agent) or the implicit logic (business agreement is hidden;
business agreements are created or selected automatically based on restricted criteria).
1.7.1.2.1 Implicit Business Agreement Handling
When creating a provider order within the Sales and Order Management business scenario, the user
enters payment data for the order. At this point the user can enter alternative payment data that should
only be valid for certain items.
When saving the order, the system creates a business agreement for the payment data entered and
assigns it to the order items. The system creates a maximum of two business agreements (one for
standard payment and one for alternative payment). After the agreements have been created, they are
assigned to each item in the contract/order. If a business agreement has been already used for another
order, it is possible to re-use this business agreement (see below). Using BADI
CRM_BUAG_DOUBLE_CHECK, you can influence the conditions that allow business agreements to be
re-used.
To determine the items for which you can enter alternative payment data, you must define a usage type
for each item category in Customizing for Customer Relationship Management under Cross Industry
Functions -> Provider Contract Management -> Transactions ->Define Settings for Item Categories.
This usage type is used to determine the business agreement class; the business agreement class
specifies the values for the business agreement that is to be created. The usage types are as follows:
Item uses standard payment data
Item uses alternative payment data
The usage type item uses alternative payment data is relevant only if alternative payment data is actually
entered during order entry.

1.7.1.2.2 Explicit Business Agreement Handling

When you create a provider order using the Sales and Order Management scenario, two options are
available to you:

13
Configuration Guide

Create a new business agreement with payment data used for all orders or contracts to which the
business agreement is assigned.
Select from a business agreement that already exists according to the payment data for
thebusiness agreement.

To activate the functions for creating the business agreement for implicit and explicit business agreement
handling you must make settings in Customizing under Customer Relationship Management Master
Data Business Partner Business Agreement Define Basic Settings. In this activity, you define
which form of open item accounting is active in a connected SAP ERP backend system. You must
choose FI-CA as the active open item accounting. This automatically activates the business agreement
functionality.
To create the business agreement, you have to maintain additional Customizing settings. Choose
Customer Relationship Management Master Data Business Partner Business Agreement. For
detailed information, see the documentation in Customizing.
1.7.1.3 Assignment of Business Agreements to Provider Orders and Provider
Order Items
This chapter has been removed from this document and added to the Application Help Documentation.
To access this documentation, choose https://help.sap.com -> SAP for Industries -> SAP for
Telecommunications.

1.7.1.4 Example
Assignment of payment groups to products
payment group
tariff 01 (individual assignment allowed)
free SMS option 03 (individual assignment allowed)
hardware (mobile phone) 02 (no individual assignment allowed)
SIM card 02 (no individual assignment allowed)
activation fee 02 (no individual assignment allowed)

Items in the provider contract

Position payment group
10 package
20 tariff 01
30 free SMS option 01
40 hardware (mobile phone) 02
50 SIM card 02
60 activation fee 02
The payment group for the tariff is inherited to the free SMS option, the payment group for the free SMS
option is not considered since it is sub item for the tariff.

Display grouping for business agreement assignment

14
Configuration Guide

sales order
payment group 01
tariff
free SMS option
payment group 02
hardware (mobile phone)
SIM card
activation fee

All items can be assigned to one business agreement only, but the settings also enable you to assign all
items in payment group 02 to a different business agreement than the items in payment group 01. In
payment group 01, you can also assign each item to a different business agreement since the settings of
the payment group 01 allow individual assignment.
You must make the following settings to create the business agreement:

1. Allocate business agreement (In this Customizing activity you assign a defined business
agreement class to various scenarios (the default business agreement class is ‘IST01’). This
business agreement class is used when creating a business agreement). Example settings:

Here you can also define

whether a business agreement
of another order/contract is re-
used by selecting the duplicate
checkbox.

2. Allocate general
parameters to new
business agreements
(In this Customizing
activity you assign
general parameters
such as
correspondence
variants, payment
methods and shipping control, as well as tax categories and control characteristics, to the
business agreement class).
3. Allocate payment-relevant parameters to new business agreement (In this Customizing activity,
you assign parameters such as payment methods and payment conditions to the business
agreement class). Example settings:

15
Configuration Guide

These settings are country-dependent.

1.8 Business Rule Framework in SAP CRM for

Telecommunications
1.8.1 General Information
1.8.1.1 Use
The Business Rule Framework (BRF) is a rule engine available in all SAP systems. In SAP CRM it can be
used, among others, to implement business rules within industry-specific scenarios. These business rules
make it possible to influence and control processes and orders automatically based on rules that can be
set up without coding via a rules editor.
In the SAP CRM 7.0 scenarios, BRF is a central and important tool used for:
Change Processes: which contract-related change processes are available for a given contract
under which conditions?
Process History: the level of detail when displaying contracts and order within the contract
overview in the IC (cf. chapter ‘Define BRF Events for the Contract History’)
Prices (cf. chapter ‘Process-Dependent Pricing’)
Dependent Components of products: under which conditions shall a dependent component, for
example such as a cancellation fee or a SIM Card be created during a contract-related process?
(cf. chapter ‘Dependent Components’)
Up- and Cross-Selling: as explained in the chapter on Hierarchies and Categories, products can
be linked to a given product as up- or cross-selling products via interlinkages. Whether such a
product shall indeed be proposed can depend on business rules, for example: ‘only propose up-
selling products if the current contract is not locked’. These business rules can be implemented in
BRF and maintained together with the up- and cross-selling interlinkages in the product master
record.
1.8.1.2 See also
The BRF has been adjusted and enhanced for use in SAP CRM and for the scenarios delivered for
industries in SAP CRM.
It is also possible to use BRF in a generic way by implementing BRF events directly, for example in user
exits or custom programs.
Furthermore, the general documentation for the BRF forms the foundation for this document and should
be read first. See the SAP Library under SAP ERP SAP ERP Central Component Cross-Application
Components General Application Functions (CA-GTF) Business Rule Framework (BRF).

16
Configuration Guide

See also Customizing under Customer Relationship Management Transactions Settings for
Provider Contracts Business Rule Framework (BRF).
1.8.1.3 Procedure
To create BRF events in SAP CRM, the following steps are necessary (will be explained in the following
chapters):
1. Define Tags
2. Define Tag Groupings (optional)
3. Define Tag Hierarchies
4. Define Tag Criteria (optional)
5. Configure BRF

1.8.2 Preparatory step: Copy BRF Objects from source client 000
If BRF is supposed to be used in any client apart from the ‘000’ client, it is necessary to copy the relevant
objects to each of these clients. This can be done in Customizing under Customer Relationship
Management Transactions Settings for Provider Contracts Business Rule Framework (BRF)
Prepare BRF for first startup

1.8.3 Tags
Tags are essentially variables or data containers that can be used within business rules. These variables’
values can be constants or be derived from the context of an event (e.g. the product entered in a sales
order). A tag can represent a single field, for example the ID of a product within an order item, but can
also represent a SAP CRM object, i.e. a more complex structure, such as the order item itself or the
appointments belonging to an order item. (Remark: all potential SAP CRM objects are comprised in table
CRMC_OBJECTS and can be looked at with the data browser transaction se16.) Tags representing
single fields are used as variables within the logic of actual BRF rules.
Please note that the concept of tags is specific to SAP CRM: tags are not a feature of the generic BRF.
A wide selection of useful tags are delivered by SAP, which means that SAP is responsible of providing
the correct tag value by means of an appropriate ABAP OO class and the related configuration of tags,
their groupings, hierarchies and their criteria. But it is also possible to implement customer-specific tags.
1.8.3.1 Tag classes
SAP provides specific ABAP OO classes for defining the required tags. Determining a single-field tag’s
result value is determined and controlled via the tag's hierarchical relationship in Customizing (see ‘Define
Tag Hierarchies’) and by assigning suitable runtime attributes. The tag’s ABAP OO class can be regarded
as tool to descend one step in the tag hierarchy. For example, class CL_CRM_BRF_BP_TAG ‘descends’
from an order item to the business partners associated to this item.
A certain knowledge about the SAP CRM data model as well as ABAP OO programming language is
needed to define new, customer-specific tags. SAP recommends to look for similar tags already delivered
in standard when attempting to define a new tag, as these can serve as a template and guidance towards
the correct definition of the runtime attribute and the tag hierarchy (see below).
1.8.3.2 Runtime attributes
Tags whose classes return a structure, again: for example CL_CRM_BRF_BP_TAG for business partners
and not fields as a result are a special case. In addition, for tag expressions that use these classes, you
can employ tag criteria or the formula editor to restrict specific results from a structure.
Runtime attributes are the name of the object to be read (for example ORDERADM_I for the object ‘Item
Data’ of an order item) or the name of the actual field to be read within a structure or a CRM object (for
example PRODUCT for the GUID of a product within an item).

17
Configuration Guide

In order to find out what the correct runtime attribute for a tag should be, the method ‘EVALUATE’
provided by the tag’s class has to be examined, as it is always this method that performs the actual
selection of the data for a given class Within the EVALUATE-methods, there are structures that contain
the selected data. A runtime attribute gets its name from such a structure or a field within such a
structure. This is illustrated in the example for the tag ‘business partner type’ below.

Two alternative options to retrieve single values from tags that contain complex structures or objects is
using a tag of the class CL_CRM_BRF_TAG_READ_FIELD or the formula editor within the actual
maintenance of a BRF expression.

1.8.4 Tag Groupings, Hierarchies and Criteria

A tag grouping is a view of the tag hierarchy in which you can group tags logically. A tag grouping can be
used in several tag hierarchies.
When a tag expression is created (see below), a grouping has to be chosen, and only hierarchies
belonging to that group are presented to choose the actual tag from.
Tag hierarchies define the way in which tags are arranged hierarchically and where they can be found in
the structure of a transactions’ context data. A tag hierarchy can have a maximum of six levels.
Hierarchies are essential to the use of tags in SAP CRM scenarios for industries, as they provide the path
from the order item to the actual value of a tag, for example finding a business partner associated to an
order item, and then to determine this business partner’s type (see example below).
Tag criteria are required for determining single tag values from transaction segment data (for example,
appointments, pricing, partner data, and statuses) by means of the class
CL_CRM_BRF_TAG_STACK_1O_OBJ. The criterion can be used for the key field of the relevant data
only; that is date type for dates, partner function category or partner function for partner data, condition
type for price document, and so on.
When you create tag expressions in the Business Rule Framework, you assign the required criteria to the
tags. As an alternative to using tag criteria, you can also define a tag expression in more detail using the
formula editor. In the formula editor, you can select from all of the fields available for a tag with their
technical attribute key to define the formula.
1.8.4.1 Tag classes delivered by SAP
SAP recommends using the following classes in SAP CRM scenarios industries. As mentioned above,
each class represents a step within a tag hierarchy. Therefore the position of a class within the implicit
hierarchy delivered by SAP is indicated to facilitate an easy understanding of the structure.
Hierarchy Level
# Parent Class Description
Root 1 2 3

Read identification (GUID)

of the items for a business
transaction. This is the
class representing the root
1 x n/a CL_CRM_BRF_TAG_STACK_ITEM node in the most important
hierarchy for Telco-specific
tags, as CRM processes
for industries are based on
the order item.
Read segment data and
2 x 1 CL_CRM_BRF_TAG_STACK_1O_OBJ
extensions of an item
Read attributes of an item
3 x 2 CL_CRM_BRF_TAG_STACK_1O_ATTR segment or an item
extension

18
Configuration Guide

Read business partner

4 x 1 CL_CRM_BRF_BP_TAG
master data
5 x 1 CL_CRM_IST_BRF_TAG_ITEM_ADD Additional Item Information
6 x 1 CL_CRM_IST_BRF_TAG_ORDERADM_H Header Data
The technical object
(‚service’) associated to the
item. The relevant data
7 x 1 CL_CRM_IST_BRF_TAG_SRV_DATA structure for the
EVALUATE method is
ECRM_ISU_NAV_COMPL
ETE
The technical object’s /
8 x 7 CL_CRM_IST_BRF_TAG_SRV_ATTR
service’s attributes
Data Source for
9 x CL_CRM_SC_BRF_TAG_CFG_SRC
Configurable Product
Configurable Product that
1 shall be evaluated by BRF
x 9 CL_CRM_SC_BRF_TAG_CFG_PROD
0 in combination with 11 and
12 (see below).
Characteristic of the
1
x 10 CL_CRM_SC_BRF_TAG_CFG_CSTIC configurable product that
1
shall be evaluated by BRF.
Characteristic Value of the
1
x 11 CL_CRM_SC_BRF_TAG_CFG_CSTICVAL above characteristic that
2
has to be evaluated.

Other relevant classes can be found in the class builder transaction se24 by looking for other classes
implementing the interface IF_CRM_BRF_TAG_STACK.
1.8.4.2 Step-by-step definition of tags
To define a tag, perform the following steps:
1. Maintain the tag’s CRM-specific configuration in Customizing under Customer Relatgionship
Management Transactions Settings for Provider Contracts Business Rule Framework
(BRF) Define Tags
Enter a suitable name and description for the tag.
Choose the class or interface that returns the value required for your tag.
Enter the runtime attribute for your tag. Note that the entry in this field must have the
same name as the object to be read in the transaction or the field in the structure.
2. If needed, define tag groupings, hierarchies and criteria in the neighboring IMG nodes.
3. Maintain the tag as a BRF expression within the generic BRF maintenance in Customizing
under Customer Relatgionship Management Transactions Settings for Provider Contracts
(…) Business Rule Framework (BRF) Configure Business Rule Framework. This is
explained in more detail below.
1.8.4.3 Examples:
(1) A tag that determines terms of payment. They are stored in field PMNTTRMS in object PRICING. To
determine the terms of payment at item level you need the following hierarchies:

Tag Parent Tag Comment

ITEM n/a (ITEM is the root!) read the current item

19
Configuration Guide

PRICING ITEM read the item’s price data

retrieve field Terms of
PMNTTRMS PRICING
Payment from pricing data

(2) A tag that determines the sold-to-party’s business partner type (e.g. ‘person’, ‘organization’ or ‘group’).
In the selection of SAP tag classes above, the appropriate class for our example is the one that reads a
business partner’s master data, CL_CRM_BRF_BP_TAG.
In order to find out what the appropriate runtime attribute is, the method EVALUATE of the tag’s class has
to be examined in the class builder transaction se24. It shows that this method reads, among others,
table BUT000 containing important business partner master data. The field in this table relevant for the
business partner type is ‘TYPE’. This is the runtime attribute needed:

However, these settings are not sufficient to provide the tag ‘business partner type’ with the correct value
to be used in BRF expressions, because it is not clear for which business partner the value has to be
read: the sold-to party, the shipped-to-party or any other business partner determined for a particular
transaction?
This derivation makes use of two additional features of BRF in SAP CRM: tag hierarchies and tag criteria:
The hierarchy represents the path through the data structure that leads from the current transaction
via its item to the business partner associated to this item and this partner’s number. Thus, the
PARTNER_NO is the appropriate parent tag for the new tag TYPE:

The criterion helps choosing the right data object on a particular level of the hierarchy in case this is
not unique. In our example of the business partner type, the partner associated to an item could be,
for example, the Sold-to Party, the Ship-To Party, the Bill-To Party, or the Payer. These various
partners roles are maintained as criteria in the system:

20
Configuration Guide

The criterion required to determine the type of the sold-to-party is later on used in the definition of the
expression that makes the tag available as input to a BRF rule. This is explained in the continuation
of this example below.

(3) Tags that retrieve information about the lock and lock levels on a contract item need to retrieve this
information from the technical object’s attributes via class CL_CRM_IST_BRF_TAG_SRV_ATTR, which
is linked to the hierarchy’s root node ITEM via the technical object (class
CL_CRM_IST_BRF_TAG_SRV_DATA). The relevant runtime attributes are PD_SERVICE1,
PD_SERVICE2, and PD_SERVICE3 from structure ECRM_ISU_NAV_COMPLETE.

1.8.5 Configure Business Rule Framework

After you have defined your own tags and tag hierarchies, you have to make all settings for the Business
Rule Framework (BRF) so that you can use it in SAP CRM in Customizing under Customer
Relationship Management Transactions Settings for Provider Contracts Business Rule
Framework (BRF) Configure Business Rule Framework
1.8.5.1 Procedure
In order to define your own BRF event, you have to execute the following steps:
1. Choose the application class CRM_CFG_SC to define or adjust the related BRF objects.
2. You can change all events known to the BRF, or make the required settings for each event. In
addition, you can register your own events with the BRF in this activity.
3. You can define expressions for the BRF. You can also use existing expressions, and adjust them to
suit your needs. You can assign tags to an expression if you have chosen the corresponding
implementing class. Implementing class 0CRM_TAG_EXP is provided by default for tag
expressions.
4. You can define rules for a BRF event. Using these rules you can fill BRF events with business
content. The starting point is, therefore, a BRF event for which you define rules.
a) Select the event that you would like to define rules for.
b) Define your rule, and if necessary, assign parameters to it for your particular business use.
5. You can optionally define rule sets for the BRF.
6. You can optionally define groups for the BRF.

SAP delivers several default expressions that you could also use for the definition of your event. An
example would be expression 0ORD_DATE_DURATION, which is used for determining the contract
duration. You could use this one to create an expression with a formula and an event based on the
contract duration. For example: ‘is the chosen contract duration is 24 months?’, and use this expression
in an event that controls whether the dependent component ‘incentive: expensive cell phone XY’ is
offered or not.
1.8.5.2 Example (continued example (2) from above):
To make the tag ‘business partner type’ available for actual BRF events, proceed as follows:
7. Choose the application class to define or adjust the related BRF objects, i.e. CRM_CFG_SC.
8. Create a new expression ZZ_TYPE of type 0CRM_TAG and enter an ID and a description. In the
tag expression part, use ‘Result of Tag’ as purpose and assign your previously created tag via drag
and drop. Make sure to use the criterion ‘Sold-to Party’ on the hierarchy level ‘Partner’ to determine
the correct partner role.

21
Configuration Guide

You find the tag on the hierarchy level you assigned it to during the definition of the tag hierarchy

9. Create a new expression of type 0FB001 that acts as a formula. Specify the result type (B =
Boolean), Fld/Struct. Lngth (= 1) and Output Length (= 1). The result type is of type Boolean, as
you only would like to know if the condition is fulfilled or not (is customer of type organization or
not). Once this is done, you can use the Formula Editor to design the formula. In this example, it is
set to: TYPE = '0001'. I.e. the event is applied to all business partners that are of type ‘PERSON’.
Thus, you could define the explosion of dependent components for certain customer groups only
(cf. the chapter ‘Define Dependent Components’), for instance. The settings would look as follows:

22
Configuration Guide

10. Finally, the event itself can be created. For doing so, create the event with class 0EVENT. In the
assignment block, assign the previously created formula as an expression. It is also important to
activate the single and multiple instance mode (otherwise, the BRF event would not be triggered):

Once the BRF event is created, it can be used in all areas the five areas mentioned above (pricing,
dependent components, order history, process control, up- and cross-selling). Furthermore, it is possible
to call such an event from within customer-specific programs or extensions.

1.8.6 Simulation of BRF Events

It is possible to simulate and ‘debug’ BRF events in order to make sure that they are working correctly by
analyzing their trace. To execute the simulation, use report CRM_CFG_SC_BRF_SIMULATE in se38.
The report calls the function module CRM_CFG_SC_RAISE_BRF_EVENTS for selected BRF events of
the application class CRM_CFG_SC.
The application class supports the processing of one order item data and the characteristic values of
configured products. Therefore the report provides several selection parameters to supply item and
configuration data.

23
Configuration Guide

1.9 Access to CRM Web UI

As of CRM 7.0, the Web UI can be accessed by transaction CRM_UI for technical users/consultants. All
other users should access Web UI directly.

1.9.1 Prerequisites
A precondition to access the new Web UI is that you are either assigned to a suitable position in the
organizational model or that user parameter CRM_UI_PROFILE is defined for your user profile.

When you are assigned to a position in the organizational model and a user parameter
CRM_UI_PROFILE is assigned to you, per default, the business role defined for the user parameter is
taken when you log on to the CRM Web UI.

1.9.2 Business Roles

Business roles are needed in SAP CRM 7.0 Enhancement Package 3 to access the new Web UI. These
business roles define several objects, among others: the information displayed to the user and the
processes he can execute. Once a business role is defined, it can be either assigned to user parameter
CRM_UI_PROFILE or to a position within the organizational model.
SAP delivers several business roles out of the box. Below find an excerpt of the roles, the bold ones
being specific to the telecommunications solution:
ANALYTICSPRO Analytics Professional
DEFAULT Default
ECO-MANAGER E-Commerce Manager (can be used for creating products and services)
FCC Financial IC Agent
FCC_PSCD Financial IC Agent PS
IC_AGENT InteractionCenter Agent
IC_MANAGER IC Manager
MARKETINGPRO Marketing Professional
TELCO-IC Telco IC Agent (default role for Telco Interaction Center)
PROVIDER_DL Provider Dealer (default role for Dealer Channel; only used for sales)
TEL-PM Telco Partner Manager (default role for Dealer Channel with Partner
Channel Integration)
TEL-CM Telco Channel Manager
SALESPRO Sales Professional (can be used to create products and services and to
create/change the organizational model)

1.10 Import of Knowledge Base

1.10.1 Purpose
A knowledge base (kb) is an object stat contains all configuration related data (e.g. characteristics,
values, dependencies) of a configurable product. If a knowledge base is already configured in an existing
SAP CRM system, it is possible to import this knowledge base so that you do not have to create a
complete product model again.

24
Configuration Guide

1.10.2 Prerequisites
All products of the kb (also parts) need to be present in the destination system product master. Note that
transport of a knowledge base will change its key. The transport assigns the logical system name of the
destination system to the logical system part of the triple key (logsys, name, version) as if the KB was
created in the destination system. The transport will overwrite existing knowledge bases that you may
have created in the destination system with the same key (logsys, name, version). We recommend that
you maintain knowledge bases in the quality system and transport them to the production system. You
should not maintain in both systems and only transport some knowledge bases.
You need to release and activate the knowledge base prior to transport (Apply pending changes).
Note that the same steps are to be performed when you transport knowledge bases between clients of
the same system.

1.10.3 Customizing of Knowledge Base Exchange

1. Start transaction SPRO
2. Choose SAP Reference IMG
3. Navigate to SAP Implementation Guide -> Customer Relationship Management -> CRM
Middleware and Related Components Communication Setup Set Up Logical Systems
4. Run Activity Define Logical System. If not existing, add the name of the logical system of the
destination to the table. The logical system typically has the following form: 3 digits system +
CLNT + client, e.g. A6GCLNT700
5. Navigate to SAP Implementation Guide -> Customer Relationship Management -> CRM
Middleware and Related Components -> Communication Setup
6. Choose Define RFC-Destinations
a. Choose HTTP Connection to ABAP System
b. Create new destination
c. Enter a name and description for the destination
d. Enter Target Host and Service No. in order to determine the values for these two fields.
Navigate to the destination system and open transaction SMICM. Then choose Goto ->
Services. Enter the host name and the service name/port of the HTTP-service
e. Enter the Path Prefix; In order to determine the values for this field, open transaction
SICF (alternatively open transaction SPRO, then choose SAP Implementation Guide ->
SAP Web Application Server -> General Settings -> Application Server -> Internet
Communication Framework -> Configure and Activate HTTP Services Individually)
i. Run the query with default parameters (Hierarchy Type = SERVICE)
ii. Navigate to default_host -> sap -> bc -> soap -> rfc
iii. Display Service
iv. Note the path of the service without the host (e.g. /default_host/sap/bc/soap
results in /sap/bc/soap)
v. The path prefix for the http destination is the service path + service name (e.g.
(/sap/bc/soap/rfc)
f. Navigate to the Logon & Security Tab
g. Choose Basic Authentication
h. Set the Status of Secure Protocol to Inactive, as the XIF SOAP Framework does not
support https.
i. Enter the logon data for the destination system
j. Save the destination

25
Configuration Guide

k. Test the destination

l. The test should ask you to accept cookies
m. Select Accept all further cookies
i. The test returns status http response: 200 if it was successful. It returns
ICM_HTTP_CONNECTION_FAILED if not
ii. The message Soap document processing failed as the test did not contain a valid
soap document is not relevant
7. Return to transaction SPRO in the SAP Implementation Guide and choose Customer
Relationship Management -> CRM Middleware and Related Components -> Exchanging Data
With External Components -> XIF Adapter Setup -> Outbound Direction
8. Start the Customizing activity Create Sites and Subscriptions
a. Create a site and give it a name and description (free)
b. Choose the type External Interface for XML
c. Within the tab Site attributes, assign the RFC-destination from step 2.6 (type H) to your
site
d. Within the admin console, choose Create to create a subscription
e. Enter a name
f. Select the publication Product Configuration (MESG)
g. Assign a site to the subscription (choose create and select the site you created in the
previous step)
9. Return to transaction SPRO
10. Choose the Customizing activity Assign Site and BDoc Type to Interface Type
a. Switch to edit mode
b. Choose New Entries
c. Enter your site name
d. Enter CRM_CFG_MBDOC as BDoc type
e. Enter CRMXIF_KNOWLEDGE_BASE_SAVE as interface name
f. Save your entries

1.10.4 Start Knowledge Base Transport (In Source System)

1. Define a request object
a. Start transaction R3AR2 (Middleware -> Data Exchange -> Synchronization -> Define
Requests)
b. Switch from the display- to the change-mode
c. Enter New entries (In case you already created a request object, you may reuse and
change this request object)
d. Enter a request name
e. Enter CONFIGURATION into the field Adapter Object
f. Choose Request Detail
g. Choose New Entries
h. Enter the criteria that selects the knowledge base that you want to transport
Possible entries:
Table Name: COMM_CFGKB
Field Name(s): LOGSYS; KBOBJNAME; VERSION; ACTIONFLAG; ACTIVE;
CHANGEDATE; CHANGER; CLASSICDEP; CREADATE; CREATOR; ECMNR;

26
Configuration Guide

FROMDATE; KB_TYPE; KB_USAGE; KLART_DOWN; LANG_DOWN; ORGID;

ORGTYPE; STATUSID; STORAGE; TODATE
For each field, make an entry:

i. Check with transaction se16 in the table COMM_CFGKB in your source system if you are
uncertain about the contents some fields for your knowledge base

Typically you enter LOGSYS; KBOBJNAME and VERSION as those are the key fields

j. Save your request object

2. Run your request
a. Start transaction r3ar4 (Middleware -> Data Exchange -> Synchronization -> Start
Requests)
b. Enter the name of your request into the field Request Name
c. Enter CRM into Source Site Name
d. Enter the name of the site that you created in the previous steps or select from the list
into Target Site Name
e. Run the download
3. You may check the success of the request using transaction R3AR3 (Middleware -> Data
Exchange -> Synchronization -> Monitor Requests).

1.10.5 Check if Knowledge Base has arrived

1. Start transaction SE16 in source system and destination system
2. Display entries of tables COMM_CFGHIER and COMM_CFGKB and compare the entries in
source and destination systems

1.11 Settings for Partner Determination Procedure

1.11.1 Partner Processing
1.11.1.1 Use
Partner processing controls how the system works with business partners in transactions. It ensures the
accuracy of partner data in transactions by applying rules you specify in Customizing, and it makes users
work easier by automatically entering certain partners and related information, like addresses.

27
Configuration Guide

One of the most important aspects of partner processing is partner determination, the system’s ability to
automatically find and enter the partners involved in a transaction. In most transactions, the user
manually enters one or more partners, and the system enters the others through partner determination.
Various sources of information make partner determination possible; two of the most important are
business partner master data and organizational data.
For example, a user creates a sales order, and enters the name of the sold-to party. Immediately, by
checking the sold-to party's master data, the system enters other required partners, such as the bill-to
party, payer and ship-to party. By checking the organization data, the system enters the employee
responsible for the region where this sold-to party is located.
The following illustration shows this combination of the user’s entry and automatic partner determination.

1.11.1.2 Features
With Partner Functions, you define partners with the terminology used in your area of business and in
your company.
In Access Sequences, you specify the sources of data the system uses for automatic partner
determination, and the order in which it checks those sources.
In Partner Determination Procedures, you specify which partner functions are involved in a transaction,
assign access sequences to the functions the system should determine automatically, and set other rules
for working with partners in transactions.
With Partner Teams, you define groups of partners involved in an individual project, or even in a single
transaction. Partner teams are used only in Opportunity Management.
1.11.1.3 Prerequisites
You have maintained business partner master data, organizational data, transaction types and item
categories.

28
Configuration Guide

For information on business partner master data see under http://help.sap.com SAP Business
Suite SAP Customer Relationship Mgmt. SAP CRM 7.0 Enhancement Package 3 SAP
Customer Relationship Management Master Data Business Partners.
To define transaction types and item categories in Customizing, choose Customer Relationship
Management Transactions Basic Settings Define Transaction Types and Define Item
Categories
1.11.1.4 Activities
...

In Customizing, choose Customer Relationship Management Basic Functions Partner Processing:

Define Partner Functions
Define Access Sequences
Define Partner Determination Procedure
1.11.1.5 Possible settings
In some cases (for instance order in the Web Channel), it might be relevant for some customers to add a
responsible employee, as soon as a contract is created. Some customers might assign a responsible
employee to every contract depending on the regions where it was created. To do so, the partner
determination procedure can be modified by adding a responsible employee.
In the definition of the partner determination procedure select the relevant procedure and choose ‘Partner
Functions in Procedure’. Here, you can add the ‘Responsible Employee’:

Maintaining ‘Minimum’ results in the fact that a least one responsible employee as to be entered.

1.12 Setting Up Card Payment

1.12.1 Use
It is possible to use credit cards as a method of payment in all channels. In order to do enable card
payment, several steps are necessary:

1.12.2 Procedure
1. Assign Checking Rules
In Customizing navigate to Customer Relationship Management Basic Functions Payment
Cards Basic Settings and execute Assign Checking Rule. Here, you can enter checking rules.

29
Configuration Guide

These rules are used for entering the payment card number. In order to avoid possible errors when you
make entries, the checking rules allows you to check, whether certain conditions of the relevant payment
card types are met.

2. Maintain Payment Card Type

In Customizing navigate to Customer Relationship Management Basic Functions Payment
Cards Basic Settings and execute Maintain Payment card type. In this step, you can define new
payment card types and assign a defined checking rule (refer to 1) to the payment card types. To
ensure that a payment card is not ambiguous, you should define only one payment card type per
credit card institution.

Using the indicator, encryption, you control whether external encryption should be used for a payment
card. If you have set this indicator, external encryption is called up when you create payment cards. You
need an external security product for the encryption of the payment card type and payment card number.
If, for example, you have not installed an external product, encryption cannot be carried out. In this case,
the data is saved without being encrypted.

3. Assign Payment Card Category

In Customizing navigate to Customer Relationship Management Basic Functions Payment
Cards Basic Settings and execute Assign Payment card category to payment card type. In this
step, you assign payment card categories to payment card types. This category used for controlling
the payment card master.

4. Maintain Payment Card Category

30
Configuration Guide

In Customizing navigate to Customer Relationship Management Basic Functions Payment

Cards Basic Settings and execute Assign Payment card category to payment card type. In this
step, you can define credit card categories, which you can assign as described in 3.

5. Define Checking Group

In Customizing navigate to Customer Relationship Management Basic Functions Payment
Cards Settings for Transactions and execute Define checking group. In this step, you can define
checking groups. The checking groups determine how and when the system carries out
authorization checks and whether authorization includes checks on the address verification system
(AVS) and card verification value (CVV).

6. Assign Payment Type to the Business Transaction

In Customizing navigate to Customer Realtionship Management Basic Functions Payment
Cards Settings for Transactions and execute Assign payment plan type and checking group to
transaction. In this step, you can assign the payment plan type payment card plan and checking
groups (refer to 5.) to business transaction types for which you will use payment cards, for instance
to the provider order PROV.
You assign payment card plan as the payment plan and checking groups on the third level of this
function. This setting is relevant if you are carrying out header customizing in the application area
Sales.

31
Configuration Guide

7. Define Merchant ID
In Customizing navigate to Customer Relationship Management Basic Functions Payment
Cards Settings for authorization and execute Define Merchant ID. In this step, you define
merchant IDs by entering the merchant ID and a short description, such as to which clearing house
or card type this ID corresponds.

8. Assign Merchant ID
In Customizing navigate to Customer Relationship Management Basic Functions Payment
Cards Settings for authorization and execute Assign Merchant ID. In this step, you assign a
merchant ID to the card type and organizational unit (shown here as Org. Management Object).
Based on these settings, the system determines merchant IDs during transaction processing.

9. Determine Organizational Unit for Clearing

In Customizing navigate to Customer Relationship Management Basic Functions Payment
Cards Settings for authorization and execute Determine Organizational Unit for Clearing. In this
step, you assign the Clearing role to one or more organizational units. This assignment, among
other factors, allows these organizational units to process payment card transactions.

32
Configuration Guide

1.13 Distribution to SAP PI

1.13.1 Use
A distinction should be made between the following object types during object distribution from SAP CRM
to SAP PI:
Business agreement
Business partner
Contracts
Orders

Make the settings for the objects that you want to distribute to SAP PI.
1.13.1.1 Business Agreement
...

1. Use the transaction Partner Agreements (transaction WE20) to create a partner agreement (partner
type LS) for the PI System.
2. Use the transaction Administration Console (transactionSMOEAC) to create a site, similarly to
standard distribution. This site must have the type External Interface for IDoc.
3. Use the transaction Assign Site and BDoc Type to Interface Type (transaction CRMXIF_C1) to
assign the site to the BDoc type BUAG_MAIN and the interface CRMXIF_IST_BUAG_SA
1.13.1.2 Business Partner
...

1. Use the transaction Partner Agreements (transaction WE20) to create a partner agreement (partner
type LS).
2. Use the transaction Administration Console (transaction SMOEAC) to create a site, similarly to
standard distribution, if this is not already available. This site must have the type External Interface
for IDoc.
3. Use the transaction Assign Site and BDoc Type to Interface Type (transaction CRMXIF_C1) to
assign the site to the BDoc type BUPA_MAIN and the interface CRMXIF_PARTNER_SAVE.
1.13.1.3 Contracts
Prerequisite: You have made the basic settings for the connection between SAP CRM and SAP PI.
...

1. Use the transaction Administration Console (transaction SMOEAC) to create a site, similarly to
standard distribution, if this is not already available. This site must have the type External Interface
for PI.
2. Use the transaction Assign Site and BDoc Type to Interface Type (transaction CRMXIF_C1) to
assign the site to the BDoc type BUS_TRANS_MSG and the interface
CRMXIF_IST_SERVICE_REQ_SAVE.
1.13.1.4 Orders
If you want to distribute additional items from the order to SAP PI, make this setting for item categories
(Customizing activity Make Settings for Item Categories).
The system distributes changes to contracts from the telecommunications contract to PI using the BDoc
XIF-adapter. Since charges from a change request must also be distributed, you can use the settings for
item categories to choose which items from the order are also to be distributed to PI.
The following interfaces are used in PI (configuration takes place in PI):
Outbound Message Interface: TelcoServiceRequest_Out
Inbound Message Interface for confirmation: TelcoServiceConfirmation_In

33
Configuration Guide

1.13.1.5 Settings
Transactions:
Partner Profiles (transaction WE20)
Administration Console (transaction SMOEAC)
Assignment Site ID Interface Type (transaction CRMXIF_C1)
In Customizing, choose Customer Relationship Management Cross Industry Functions Provider
Contract Management Transactions Define Settings for Item Categories.

If no PI system is connected to the SAP CRM 7.0 Enhancement Package 3 system, it is

necessary to create a dummy PI entry so that contracts can still be activated. This dummy entry must also
be maintained in transaction CRMXIF_C1, for example:

For further information, see SAP note 1077640.

1.14 Order Distribution Infrastructure

1.14.1 Comparison of Distribution Models in SAP CRM 7.0 EHP3 and
SAP CRM 7.0

Comparison of distribution model

CRM Telco Service

Message XI Billing,
MW
rating,
…

Provider CRM 7.0

Contract CRM 7.01

Telco Service
Message

Customer specific
Customer specific
messages
Customer specific
messages
ODI messages

Email
Wait steps
Update of Provider Contract
…
Order Distribution
Infrastructure

© SAP AG 2009. All rights reserved. / Page 1 Confidential

In releases prior to CRM 7.0 Enhancement Package 3, provider contracts were bound to a single PI
message that was used to provide all connected systems with information about new or changed
34
Configuration Guide

contracts. In this scenario, the SAP CRM system does not know the systems that are interested in
contract-related data. As a result, SAP CRM cannot control or display the current state of the distribution.
With the Order Distribution Infrastructure (ODI), SAP CRM is enriched by a layer that lets users define
what actions need to be taken in which sequence in order to fulfill or deliver services according to the
definition in the provider contract. The necessary steps can differ depending on various criteria, for
example:
The executed process (sales, product change, cancellation, change of technical details, and so
on)
The kind of service (for example, GSM, data, and IP)
The result of other steps (for example, only if step 1 is succesful, execute step 2)
The requested activation date
From the perspective of the triggering document (= provider contract), it does not matter which distribution
model is used. The ODI is only registered for status changes in the same way as the SAP CRM MW is.
The order distribution framework only becomes active if this is determined by the contract status.
Also the same statuses are set, once the distribution is finished. The distribution is finished when there
are no steps left with status Open, Waiting, Scheduled or Technically Failed. The system then analyzes
the status of the steps and if no steps have the status failed, the contract is set to active. Otherwise it sets
the status to activation failed.
While the ODI is processing the document, it is locked for manual processing in the transaction UIs. Once
the distribution is finished, control is passed back to the document. Depending on the final status, either a
new process can be executed or, if errors occurr, data can be corrected. By resubmitting the order, the
contract triggers the new distribution steps.

1.14.2 Framework
1.14.2.1 Introduction
The distribution of SAP CRM documents is a basic requirement in certain scenarios. The document
distribution framework offers a flexible way to setup a document-specific customizable distribution that
can be influenced by custom exits and scheduling mechanisms. The distribution framework is based on
the CRM document framework and uses the existing event-based infrastructure for its own processing
logic.
The scheduling feature allows fast processing for the end user and postpones the actual execution of the
distribution to a delayed batch process.
You can use transaction CRMC_ISX_MSG_DIST to access all Customizing settings for the document
distribution framework. The configuration is offered within a view cluster which allows you to define the
main objects for the distribution of SAP CRM documents.
The central Customizing object is the distribution schema. The distribution schema defines the distribution
steps to be executed whenever a SAP CRM document with the assigned distrubution schema is saved.
You can use the settings within this view cluster to control the document distribution.
The basic steps to enable the document distribution are as follows:
Definition of document distribution categories
Definition of document distribution types
Definition of a document distribution schema
The document distribution schema contains document distribution steps that are each linked to a document
distribution type. The document distribution schema has to be assigned to the document process type and
document item category for which the distribution is to be executed. The schema determination is executed
when the document is saved.

35
Configuration Guide

1.14.2.2 Document Distribution Category

The document distribution category is a general categorization of distribution types. It is used to group a
bundle of single distribution steps that have to be processed together when the document has a certain
status.
An example for a distribution category is contract activation. All steps related to contract activation are
linked to one distribution category. As a result, it is possible to implement necessary status changes
within the document for the whole distribution category by assigning a suitable implementation class.
The implementation class, which can be assigned to a document distribution category, is used to control
the execution of distribution steps of the corresponding distribution category. The implementation class
has to implement interface IF_CRM_ISX_ORDER_MSG_DIST_CAT. The methods of this interface are
called at runtime and allow the distribution-category-dependent implementation to react at a dedicated
point of time and influence the execution of the distribution steps assigned to the category. It is also
possible to influence the determination of the distribution steps.
We recommend that you inherit the implementation class from the abstract base class
CL_CRM_ISX_ORDER_MSG_DIST_CAT, which already implements the interface and offers an
appropriate class instance constructor that imports necessary data. By redefining the methods in the
distribution-category-dependent implementation class, specific coding can be added if needed.
If no implementation class is assigned to the distribution category, the default implementation class
CL_CRM_ISX_ORDER_MD_CAT_DFLT is chosen at runtime.
1.14.2.3 Document Distribution Type
A document distribution type defines a single distribution step within document distribution. The
distribution type describes a single distribution function, for example sending a notification message to
one external system.
The document distribution type has to be assigned to a document distribution category. With this link, the
distribution type becomes part of group of distribution types with the same distribution category.
The distribution type can be defined as an asynchronous distribution type. This setting prevents the direct
execution of the distribution step with this distribution type. The distribution step is registered and the
distribution status is Open. The distribution step is executed with the next batch run (see program
CRM_ISX_MSG_START_PLANNED).
The implementation class at document distribution type level is used to implement the actual distribution
step execution logic. The class has to implement interface IF_CRM_ISX_ORDER_MSG_DIST_TYPE.
The methods of this interface are called at runtime and allow the distribution-type-dependent
implementation to react at a dedicated point of time and influence the execution of the distribution step.
There are also methods to cancel the execution and to handle changes of the external status triggered
from the distribution monitor application.
We recommend that you inherit the implementation class from the abstract base class
CL_CRM_ISX_ORDER_MSG_DIST_TYPE, which already implements the interface and offers an
appropriate class instance constructor, which imports necessary data. By redefining the methods in the
distribution-type-dependent implementation class, specific coding can be added if needed.
If no implementation class is assigned to the distribution type, the default implementation class
CL_CRM_ISX_ORDER_MD_TYPE_DFLT is chosen at runtime.
1.14.2.4 Document Distribution Schema
The document distribution schema bundles several distribution types into document distribution schema
steps. Each distribution step within a schema can have an individual description (which is displayed in the
end user UI) and is linked to a distribution type. It is possible to define the same distribution type multiple
times within a schema using different distribution step IDs.
Within the distribution schema, the execution sequence of the different distribution steps can be defined
using the Step field. It is also possible to define dependencies between distribution steps using the

36
Configuration Guide

Prerequisite Step field. The distribution step is then only executed, if the distribution step(s) with the
distribution step sequence defined in the “Prerequisite Step” field have all been executed completely.
Distribution steps can be marked as inactive to enable the deactivation of distribution steps for a certain
time period or for testing purposes. If the distribution step is marked as inactive, it is ignored at runtime. If
the step is used as a prerequisite step for another distribution step, this step is also ignored.
If the assigned distribution type of a distribution type is defined as an asynchronous (batch) step, the
Asynchronous field is also marked at distribution step level and the field is disabled. It is not possible to
mark a distribution step as synchronous if the corresponding distribution type is already marked for
asynchronous execution. Nevertheless, it is possible to mark a distribution step as asynchronous if its
distribution type is marked for asynchronous execution. With this mechanism, distribution types can be
registered for batch processing for certain distribution schemas only.
The distribution schema contains all potential distribution steps for a document item. The assignment to a
document item at runtime is made using the document process category and/or document item category.
The actual execution of the single distribution steps can be controlled using the distribution category
implementation class or the distribution schema implementation class. For example, it is possible to
exclude some steps depending on the document status and to reschedule them later when the document
status has changed.
The implementation class for the document distribution schema is used to implement logic similar to the
distribution category but for the whole distribution schema. This means it is possible to set a document
status that is dependent on all distribution steps, or to influence the distribution in addition to the
distribution type or category implementations.
The class has to implement interface IF_CRM_ISX_ORDER_MSG_DIST_SCH. The methods of this
interface are called at runtime and allow the distribution-schema-dependent implementation to react at a
dedicated point of time and influence the execution of the distribution steps. It is also possible to control
the determination of the distribution steps.
We recommend that you inherit the implementation class from the abstract base class
CL_CRM_ISX_ORDER_MSG_DIST_SCH, which already implements the interface and offers an
appropriate class instance constructor that imports necessary data. By redefining the methods in the
distribution-schema-dependent implementation class, specific coding can be added if needed.
If no implementation class is assigned to the distribution schema, the default implementation class
CL_CRM_ISX_ORDER_MD_SCH_DFLT is chosen at runtime.
1.14.2.5 Document Distribution Schema Determination
After defining a distribution schema, its determination at runtime can be controlled using the document
process type and/or document item category. If a document is saved, the distribution step registration
procedure checks the Customizing settings for each document item and checks if it is relevant for
distribution.
For each document item, the header process type and item category are determined and the Customizing
settings are evaluated. If no matching entry is found for the exact combination of process type and item
category, the entries for the empty process type and the exact item type are determined. This means it is
possible to define default process-type- independent entries.
The item category has to be maintained for every item category for which a distribution schema is to be
determined. It is not possible to define a default distribution schema determination using an initial item
category.
For every combination of process type and item category it is possible to assign a distribution schema
determination implementation class. With this class, the distribution schema determination can be
influenced at runtime.
The class has to implement interface IF_CRM_ISX_ORDER_MSG_DIST_DET.
SAP recommends that you inherit the implementation class from the abstract base class
CL_CRM_ISX_ORDER_MSG_DIST_DET, which already implements the interface and offers an

37
Configuration Guide

appropriate class instance constructor, which imports necessary data. By redefining the methods in the
distribution schema determination implementation class, specific coding can be added if needed. A
possible use case for a distribution schema determination implementation class is the product-specific
determination of the distribution schema.
If no implementation class is assigned, the default implementation class
CL_CRM_ISX_ORDER_MD_DET_DFLT is chosen at runtime.
The distribution schema assignment allows multiple entries. One of the assigned distribution schemas
has to be marked as default if no determination implementation class is defined. The default distribution
schema is determined at runtime if no implementation class is defined. If no default distribution schema is
chosen, the implementation class has to evaluate the actual distribution schema at runtime.
For each assigned distribution schema, it is possible to deactivate single steps of the distribution schema
or to activate asynchronous (batch) execution for the specific process type and item category
combination. The same distribution schema can be used for different combinations but can be handled
differently depending on the individual assignment settings.
The asynchronous execution can be scheduled using an appointment type of the document item. If an
appointment type is assigned to the distribution schema step, this appointment is determined at runtime
from the document item and the batch report only executes the distribution step if the actual date and
time is reached. The determination of the scheduled date and time can also be handled within the
distribution-type-dependent implementation class.
1.14.2.6 Distribution Status
The document distribution status defines the status of a single distribution step within a distribution
schema. It is used to control the execution of the distribution schema. The status provides information
about the current phase of distribution, which can be Open or Executed. The distribution step sequence
can be used to create dependencies between single distribution steps within a distribution schema, so
that it is possible to execute steps depending on the status of other distribution steps.
There are 8 different distribution steps:
Status ID Status Description Meaning

A Scheduled Step is scheduled by Customizing.

B Executed Step successfully completed. Final status.

C Failed Step execution failed. Final status.

D Irrelevant Step is not relevant for current schema execution. Step is ignored.

E Waiting Step is waiting for an external response (for example, from an external system).

F Cancelled Step cancelled due to rerun of step or schema.

G Technically failed Step execution temporarily failed. Retry possible.

H Open Step registered and ready for execution.

1.14.3 Distribution Schema and Settings

1.14.3.1 Determination of Distribution Schema
The distribution schema is determined based on the transaction category and the item type.
If you do not want different kinds of products to share the same transaction category or item type, this
default setting can be overruled by assigning a class at schema determination level. You can assign
classes that implement the interface IF_CRM_ISX_ORDER_MSG_DIST_DET which mainly contains the

38
Configuration Guide

method DETERMINE_SCHEMA.
As a result, different products can trigger different distribution steps, for example, different steps for a
GSM service compared to a fixed line service.

The sample implementation CL_CRM_ISX_ORDER_MD_DET_PRDGR1 can serve as a template for

storing the distribution schema at product level. This implementation checks whether a schema
assignment exists within the product master field PRC_GROUP1. This schema then overrules the
distribution schema marked as default in Customizing.
Prerequisites and limitations of this sample class are:
Schema exists and is assigned to the combination of transaction type/item category of the current
item without marking it as default.
PRC_GROUP1 can only serve as storage for schemas with IDs not longer than 3 characters.
The assignment schema has to be added to the allowed values for PRC_GROUP1 in
Customizing for Customer Relationship Management under Master Data Products Special
Settings for Sales Operations Define Product Groups.
If this example is not sufficient, the recommendation is to create a customer-specific set type at product
level and to evaluate the settings within a customer-specific implementation of
IF_CRM_ISX_ORDER_MSG_DIST_DET.

1.14.3.2 Schema and Categories for Provider Documents

The standard schema definition for the provider contract is PC01. This schema condition contains the
categories and steps that lead to the same system behavior occurs if you do not use the ODI.
Even if categories can be defined freely in the ODI, there are 4 categories that are mandatory for use with
provider contracts. Each schema that is used with provider orders needs steps of these categories in
order to work correctly in terms of status handling.

Categroy Description Implementation Class

P0 Provider contract waiting for CL_CRM_ISX_ORDER_MD_CAT_PRV_P0
activation

39
Configuration Guide

P1 Provider contract activation CL_CRM_ISX_ORDER_MD_CAT_PRV_P1

P5 Provider contract wait for CL_CRM_ISX_ORDER_MD_CAT_PRV_P5
deactivation
P6 Provider contract CL_CRM_ISX_ORDER_MD_CAT_PRV_P6
deactivation
P0 and P1 are for the activation part of the order while P5 and P6 are for the deactivation part. The
deactivation is only scheduled if the contract end date is already set.

The following list describes the document statuses that trigger the ODI to become active:
Status Description Use case
I2320 TS Start Delayed Deferred activation
Distrib.(XI)
I2321 Distribute at TS Start Immediate activation
(XI)
I2335 TS Start Advance Immediate activation (forced by
Dist. (XI) customizing)
I2325 Delayed Distributn Deferred deactivation
TS End (XI)
I2326 Distribute at TS End Immediate deactivation
(XI)

1.14.3.3 Use Case – Immediate Activation

If a provider contract is created with an activation date of today’s date or earlier, the system skips
category P0.
The system schedules the steps assigned to category P1 directly. In the default settings, the XI Message
is created in step PCXI. The corresponding step has the status Waiting because a confirmation is
expected.

1.14.3.4 Use Case – Deferred Activation

If a provider contract is created with an activation date in the future, the system first processes the steps
of category P0. The other steps are not scheduled before the wait step is finished. Directly after creation,
only the step PCWA (Wait for activation) is scheduled. The default setting is scheduled date = contract
activation date (ISTCONTSRTTS).

This step is processed by the batch report CRM_ISX_MSG_START_PLANNED. After execution of the
status of the step, the contract is set to status In activation and the execution of steps assigned to
category P1 is triggered. This is comparable to the immediate activation described above.

40
Configuration Guide

1.14.3.5 Use Case – Activation and Deactivation at the Same Time

If you want a running contract to be deactivated immediately, the system does not execute the activation
logic, but only the deactivation steps.
This is different from the situation where the deactivation is scheduled for a specific date in the future. In
this case, once the new timeslice has been created, it is activated. The deactivation steps are only
executed once the deactivation date is reached.
1.14.3.6 Standard Steps
Type Description
CL_CRM_ISX_MD_EXAMPLE_MAIL Simple example: Send welcome e-mail
Takes e-mail address from sold-to party
If an e-mail address is maintained an example e-
mail message is sent via SAPconnect
infrastructure
CL_CRM_ISX_MD_EXAMPLE_TRUE Simple example: Always true
CL_CRM_ISX_ORDER_MD_WAIT_P Message Distribution Wait for Activation (P0)
0 Set status To be Distributed for contract item
The corresponding order is then locked for
processing as the status In Distribution is
assigned to the order item.
Additionally, the determination of possible steps is
triggered again so that steps of other categories
can now start. Mostly intended for category P1 at
this stage.
CL_CRM_ISX_ORDER_MD_WAIT_P Message Distribution Wait for Deactivation (P5)
5 This step waits until the contract end date is
reached. After that it assigns the status To be
Distributed at Contract End to the contract item.
Additionally the determination of possible steps is
triggered again so that steps of other categories
can now start. Mostly intended for category P6 at
this stage.
CL_CRM_ISX_ORDER_MD_XI_MSG Message Distribution Send XI Message
Creates a Telco Service Message (TSM) in the
same way as in prior releases via the IST XIF
adapter. The message GUID is both stored in the
distribution log and in the MSG_REFERENCE
field of table CRMD_ISX_MSG.
CL_CRM_ISX_ORDER_MD_ERP Call SAP ERP message contract (de)activation
P1(P6)
Provides the Common Object Layer (COL) with
the current contract status to create or update the
contract in SAP Convergent Invoicing (SAP CI)

41
Configuration Guide

and SAP Convergent Charging (SAP CC).

CL_CRM_ISX_ORDER_MD_ALLOW Call allowance activation (P1)
Activates SAP CC allowances that have been
marked to be automatically activated in an
allowance definition group for the current
distribution reason (sales or change). This step
should be scheduled once contract activation has
been completed successfully.

1.14.3.7 Further Hints

The workflow that is normally triggered to handle deferred distribution is not called if a distribution
schema is entered. This is done by the asynchronous wait steps within the ODI.
Usage of the distribution in the ODI is only possible if no ISTB processes are used. ISTB
processes are not supported. The same is true for ISTC processes (lock) where lock fees are
included.
If the TSM is used in class CL_CRM_ISX_ORDER_MD_XI_MSG, the GUID of the distribution
step is stored at item level in field STEP_GUID.
If confirmations are sent from external systems using the interface Telco Service Request
Confirmation, there are two options for providing data to identify which items need to be updated:
o Item Guid + Step Guid
o Telco contract number + Step Guid (this option is only valid for main items)
If a complex item hierarchy is distributed using CL_CRM_ISX_ORDER_MD_XI_MSG, only the
status of the main item should have the step assigned using the distribution schema. Subitems
should not be assigned the step. In this case, the main item ensures that the subitem is also
distributed. Therefore, the confirmation is only requested at main item level.
In customer-specific implementations of distribution steps, the status Technically Failed can be
used to mark a step as temporarily failed. Such steps can be restarted within the ODI and can
prevent the system from returning the control to the processing of the document or process UI.

1.14.4 User Interface

1.14.4.1 Provider Contract displayed in PROVIDER_IC Business Role
When displaying a provider contract using the business role PROVIDER_IC or any similar business role,
the new tab Fulfillment Status is available. Depending on the underlying view, this tab displays all active
distribution messages that have been sent or will be sent for the chosen provider contract.
This view only supports display mode and includes the following columns:
Step
The distribution step sequence allows a serialization of distribution steps within a distribution schema.
It is possible to control the execution sequence and to build dependencies using the prerequisite step
sequence field.
Distribution Type
The document distribution type defines a single executable distribution step. The main distribution
implementation has to be implemented in the assigned class methods.
Distribution Category
The message distribution category defines the basic category of a message distribution type. The
implementation classes can program on the category to define a group of types that have to be
handled in a certain status of the order document.

42
Configuration Guide

Distribution Status
The document distribution status defines the state of a single distribution step within a distribution
schema. It is used to control the execution of the distribution schema. The status provides information
about the current phase within the distribution, from Open to Executed. The distribution step sequence
can be used to create dependencies between single distribution steps within a distribution schema so
that it is possible to execute steps based on the distribution status of other distribution steps.
Status Icon
The distribution status icon symbolizes the status of a single distribution step within a distribution
schema in the form of an icon.
Distribution Schema
The distribution schema defines a set of distribution steps that are registered for a certain combination
of document process type and item category. Only one active distribution schema can be assigned to
a document item at runtime. The distribution schema is determined when a document is saved.
Completion Date
Execution Date
Planned Date
The planned date of a distribution step is filled with a future date if the step is to be executed in the
future, or it is filled with the current date if the step is to be executed immediately.
Reference Type
The message distribution reference type defines the type of the sent message. There are XML
messages or undefined messages.

43
Configuration Guide

44
Configuration Guide

1.14.4.2 Distribution Monitor

The distribution monitor is an application where distribution steps for provider contracts can be found,
displayed, changed, rescheduled, restarted, or rerun. The UI of the distribution monitor consists of a
search page und and an overview page.
1.14.4.2.1 Distribution monitor search page
On the search page, you can use the following parameters to search for distribution records:
provider contract number
Transaction ID
Product ID
Fulfillment Status
(possible statuses: Open, Scheduled, Executed, Failed, Irrelevant, Waiting, Cancelled,
Technically failed)
Fulfillment Type ID
Changed By Name
Creation Time Frame
Update Time Frame
All parameters can be combined with each other.
The distribution record is data aggregated from all distribution steps of an provider contract. It contains
some attributes of the related contract, a cumulated overall status of the distribution, and some important
dates:
contract number (e.g. SAP for Telecommunications)
Transaction ID
Item number
Product ID/Text
Created At Date
Fulfillment Schema ID/Description
Cumulated Fulfillment Status Text/Icon
(possible statuses: Finished, In process, Failed)
Fulfillment Type ID
Planned At Date
Executed At Date
45
Configuration Guide

Completed At Date

The distribution overview page consists of following views:

Header view displaying distribution record
Below the header view there is a list of fulfillment steps for the related provider contract. Each
step contains:
o Fulfillment step ID/Sequence
o Batch step flag
o Fulfillment Type/category
o Fulfillment Status
o Planned At Date
o Executed At Date
o Completed At Date
In the last view below the steps, fulfillment messages are displayed. Each message contains:
o Reference
o Message Type/Text
o Message Date/Time
The displayed steps are all steps related to the IS-T contract or directly to one of the related
steps. If only one step is marked, then only messages for this particular step are displayed.

46
Configuration Guide

By default, only active steps (that is steps which do not have the status cancelled) are displayed.
Cancelled steps can be displayed as well if requested.

If some provider contracts have subcontract(s), the Related items button becomes enabled and provides
navigation directly to the subcontract.

47
Configuration Guide

Depending on what statuses all the related steps have, the overall status is set to Finished, In process or
Failed.
Overall status Finished

Overall status In process

48
Configuration Guide

Overall status Failed

The status of a single step can be changed. This status change not only sets the status; related contract
processes are also executed.

A single batch step can be rescheduled or a single non-batch step can be reprocessed. Alternatively, all
the steps can be re-run at once.

1.14.5 Batch Report

The scheduled records are executed using report CRM_ISX_MSG_START_PLANNED. This report is to be
included in a job and started periodically. Usually the report can be started with the default parameters.
With default values, the report executes all planned entries with status open (H), techfailed (G) or
scheduled (A).
The records are executed asynchronously. The queues can be found in the inbound queue of the SAP
CRM system using transaction SMQ2.
The queue name is CSA_ISX_ACTIVATE with a rolling number at the end.
The report has the following import parameters:
Date (From) and Date (To)
These dates are defaulted automatically to executed past and present records. You may change
the filter - that is, if you want to execute future activations even if the time is not reached.
Number of queues 5
49
Configuration Guide

Change this number to influence the number of parallel queues executing the records. A lower
number will result in fewer queues and therefore blocks less resources on the server but
increases runtime. Increasing the number results in the opposite.
Block size 50
This parameter controls how much records are executed in one commit work. During execution,
this value can vary slightly, as records of one single order document are always executed in a
commit work step.

1.15 Distribution of One-Off-Charges to SAP ERP

This chapter has been removed from this document and added to the Application Help Documentation.
To access this documentation, choose https://help.sap.com -> SAP for Industries -> SAP for
Telecommunications.

1.16 Distribution of Data to SAP ERP using ODI

1.16.1 Use
A set of Customizing settings is provided with the implementation of the Order Distribution Infrastructure
(ODI) step types for the distribution to SAP ERP. You can use these to set up a typical scenario when you
implement the distribution of contracts in a system landscape with a SAP Convergent Charging System
for rating and a SAP Convergent Invoicing System for billing/invoicing.
For more information about ODI Customizing in general, see the chapter Order Distribution Infrastructure
in this document.

1.16.2 Procedure

The distribution of contract data to SAP ERP is relevant for the create, change and cancellation
processes. When these processes are executed, the corresponding document then trigger the ODI.
Creating and changing contract data is relevant for the activation process (distribution category P1). The
cancellation of contract data is relevant for the deactivation process (distribution category P6).
The step type class CL_CRM_ISX_ORDER_MD_ERP implements the following steps which are used for
the activation and deactivation:
Step type PCEA is assigned to category P1 and is executed when contract activation is
performed.
Step type PCED is assigned to category P6 and is executed when the contract is deactivated.

1.16.3 Class CL_CRM_ISX_ORDER_MD_ERP

The parts of the implementation of the class CL_CRM_ISX_ORDER_MD_ERP are described in the
following chapters.

1.16.3.1 Validation
During validation the system checks whether the current item is relevant for distribution. The system only
creates a message for main items. Sub items are distributed with their corresponding main items.

1.16.3.2 Data Mapping

Data mapping consists of SAP FI-CA data and SAP CC data.
50
Configuration Guide

The SAP FI-CA data consist of the contract data (business partner, sales organization, appointments).
During SAP CC data mapping, the current cross catalog mapping version of the product is evaluated first.
Following this, the system selects the data for all active charge plans (parameters, technical resources,
account assignments and shared counters) and maps this to the corresponding SAP ERP structures.
During the mapping procedure, the system performs some consistency checks. If the data is not
consistent, the ODI execution status is set to Failed and the message is not sent to the SAP ERP system.

1.16.3.3 Send Data to ERP

The mapped data is sent to the Common Object Layer (COL) in SAP ERP by calling a RFC function
module.
In the COL, data is forwarded to FI-CA and to the SAP CC system. If an error occurs during this process,
an error message is sent to the SAP CRM system.
An error categorization is entered in the PARAMETER field in the error message. According to this
categorization, the ODI distribution status is set as follows:
ERP Error Category ODI Status ID Status Description
'alreadyExists' C Failed

'doesNotExist' C Failed

'invalid' C Failed

'prerequisiteMissing' G Technically failed

'incompatibleConfiguration' G Technically failed

'illegalState' C Failed

'temporaryIllegalState' G Technically failed

1.16.4 Prerequisites
The following preconditions are required:
The Cross Catalog Mapping (CCM) version in the product master data must be maintained
The product has to be replicated to the SAP ERP system
The business partner, business agreement and prepaid account have to be replicated to the SAP
ERP system

1.16.5 Schema Definition

The distribution categories P0, P1, P5, P6 are mandatory for use with provider contracts. Distribution
steps for each of these categories are assigned to the new distribution schema PERP as follows:
PCEA - new step type PCEA, executed during contract activation (category P1).
PCED - new step type PCED, executed during contract deactivation (category P6).
PCWA - step type PCWA, executed if the contract has deferred activation (category P0).
PCWD - step type PCWD, executed if the contract has deferred deactivation (P5).

51
Configuration Guide

1.16.6 BAdI
The enhancement spot CRM_ISX_ERP_CONTRACT is used during distribution to SAP ERP to
determine processes and to map the relevant data.
The enhancement includes the BAdI CRM_ISX_ERP_CONTRACT, which you can use to control how
data is replicated to SAP ERP. The BAdI is called when you execute the distribution step to SAP ERP
using the Order Distribution Infrastructure (ODI).
The interface IF_CRM_ISX_ERP_CONTRACT contains the following methods:
MAP_CREATE: implements customer-specific mapping logic for the create process. You can
also read the necessary data and forward it to SAP ERP.
MAP_CHANGE: implements customer-specific mapping logic for the Change process. You can
also read the necessary data and forward it to SAP ERP.

1.16.7 ODI Customizing Setting

If you want to use the ODI for distribution to SAP ERP, you need to make the following Customizing
settings:
Schema Determination
Assign the distribution schema to the relevant combination of transaction type/item category,
which is used to capture the provider contract.
1. Call transaction CRMC_ISX_MSG_DIST
2. Choose Schema Determination in the dialog structure on the left hand side of the screen.
3. Create entries for the transaction type PRVC (Provider) with different item categories for the
items that have to be distributed. For example, define two entries with transaction type PRVC
for the main item with item category PRCP and one entry for the subitem with the category
PRCO.
4. Select the new entry created, choose Schema Assignment in the dialog structure, and create
a new entry using the schema PERP and set it as the default schema.
5. Save your entries.
Scheduling
Step types PCWA and PCWD both implement wait steps. The date on which execution is
scheduled is defined by the Scheduled App Type assigned to the respective step.
Step PCWA is executed when the contract start date is reached. This is defined by assigning
date type ISTCONTSRTTS (Start of Contract Time Slice) to the step.
Step PCWD is executed when the contract end date is reached. This is defined by assigning
date type CONTEND (Contract End) to the step.

1.16.8 RFC Destination

Since the contract is replicated to the SAP ERP system by Remote Function Control (RFC), the RFC
destination of the SAP ERP system has to be determined.
You can make these settings in the default implementation of the BAdI method CRM_IU_IL_SYSTEMS ->
GET_BACKEND_CONNECTION, which takes the RFC destination for the business partner replication.
52
Configuration Guide

You can see the RFC destination of the business partner replication in the middleware transaction
SMOEAG (object type site -> R/3)
If no RFC destination could be determined in the BadI, you must maintain it in the Customizing table
CRMC_FICA_SYST.

1.16.9 Optional ODI-Step for Activation of Provider Contracts in SAP

Convergent Charging
There is an optional step after replicating contract data to SAP CC. After creating or changing a prepaid
contract, several further activities can be executed, for example performing the initial refill based on the
assigned refill plan. Those activities are not directly processed after new contract data is passed to SAP
CC, butperiodically a scheduler in SAP CC checks open tasks and executes them. If it is necessary to
execute these tasks immediately after a contract is created or changed, the service has to be triggered
explicitly.
You can do this by adding relevant steps to ODI Customizingleverating class
CL_CRM_ISX_MD_CCONTR_ACTIVATE which implements the required functionality. The system
checks whether the contract was changed or updated and whether the payment method is prepaid. If the
payment method is prepaid, contract activation is triggered for this contract number.
You should assign this ODI step to category P1 and add it to the ODI distribution schema after the step
PCEA (replication to SAP ERP) has been executed. Define the step PCEA as prerequisite for this step in
the schema.

1.16.10 Handling of Technically Failed ODI Steps

If the connection to the SAP ERP System is temporarily interrupted or a new business agreement created
is not replicated to the SAP ERP System when the contract replication starts, the ODI steps is assigned
the status technically failed.
We recommend the following procedure:
Start contract replication again using the batch report CRM_ISX_MSG_START_PLANNED.
1. Create a variant of the report with the following selection parameters:
Date (From): current date
Date (To): current date
Time (From): for example, 20 minutes in the past (select the latest contracts only)
Time (To): current time
Since you must determine the data and time parameters dynamically when the job starts, you must define
them as variant attributes.
Select the flag only technically failed
Select the flag only start if queues are empty to prevent the report using existing queues from other batch
processes.
2. Schedule the report with the new variant created to run as a batch job, for example, every 10
minutes. It collects all messages with the status technically failed and executes them again.
Unlock the report during the batch job.

A new batch job for the report CRM_ISX_MSG_START_PLANNED is run to perform contract activation
and cancellation. This job is only run once a day with the default selection fields (execution without a
variant).

53
Configuration Guide

2 Basic Settings for Business Scenarios using

Provider Contract Management
2.1 Industry-specific Product Terms
In order to better meet requirements of industries using Provider Contract Management, SAP CRM offers
several concepts that support the creation of product master data, for instance sales packages, rate plans
and combined rate plans. A definition of all product related definitions can be found here:

Term Definition
Package A package is an umbrella term for the rule-governed combination of rate plan(s),
enabling products and incentive products and services.
Selling packages enables the service provider to better target their offering for
particular customer groups/along marketing campaigns to win and retain customers.
Selling multiple rate plans and other products in one package enables the service
provider to offer a more complete and unique solution to match customers’
requirements and addresses the needs of customers to get more services from less
providers.
Technically, a package has one top level product to which components are assigned
via Interlinkages (see below) or product configuration. The result can be a multi-level
structure.
Examples:
All-in-one communication package
DSL Internet connection
ISDN Phone lines
Discounted hardware
Installation Service for free

Important note: Packages in CRM 7.0 Enhancement Package 3 are essentially

‘Sales Packages’. This means that they can be used for the initial sale of a product to
a new customer or selling an additional product to an existing customer. Packages
cannot be used for product changes. This means: it is not possible to change from an
existing rate plan / contract to a new package. The target of such a product change
has to be another rate plan. Incentives and penalties and other items generated by
such a change need to be implemented as dependent components of the
targetrateplan product. Details are explained below.
Rate Plan A rate plan is an agreement between the service provider and the customer that runs
over a certain time period. On the basis of this rate plan, services are provided and
billed to the customer based on service usage, device usage and other fees.
Rate plans have options that the customer can choose to select or deselect to match
his service usage.
Selling rate plans is core to a service provider’s business. Recurring fees from rate
plans and margins from services provided are the basis for a service provider’s ability
to maintain and invest in extending his service provisioning infrastructure (e.g. a data
network).
Interlinkage Rate Plan Combinations:
Types (=
54
Configuration Guide

Relationship scrpc - Rate Plan Combinations

Type)
Sales Components:
scslc - Sales Components (SC)
scp2g - Product Groups for SC
sctxs - Explanations for SC

Dependent Components:
scdec - Dependent Components (DC)
scp2d - Product Groups for DC
sctxd - Explanations for DC
sccfd - Value Propagation for DC

Cross-Selling:
sccrs - Cross-Selling (C-S)
sctxc - Explanations for C-S

Up-Selling:
scups - Up-Selling (U-S)
sctxu - Explanations for U-S
sccfu - Value Propagation for U-S
Dependent Dependent components enable the combination of a superordinate product and
Components subordinate products via the Dependent Component interlinkage type. The
superordinate product is in most of the cases a rate plan.
Examples:
Activation Fee
Early Cancellation Fee

In a given situation, such as the creation of a new contract, a product change, a

contract extension or a cancellation, the system checks which (if any) dependent
components should be generated during the creation of an order.
It is possible to control the behavior of dependent components in several ways:
- depending on the process type
- depending on the existence of other products in the order,
- via the BRF business rules engine (see Business Rule Framework in SAP
CRM).
For example, it is possible to generate an activation fee for the initial sale of a
contract, an incentive credit for a contract extension or an upgrade to a more valuable
product, and a fee for a downgrade or a cancellation during the binding period.
A dependent component, for instance part of a rate plane, would be added to the
order in case the rate plan alone is sold, but also in case the rate plan is sold withing
a sales package.
There are no restrictions to assignment of dependent components, but the product to
which you want to assign dependent components must be defined as a material.
Dependent components can be flagged as optional, and can be grouped. If the group
55
Configuration Guide

itself is not flagged as optional, the user has to choose one component within this
group. Example for telecommuncations: during an up selling process, a cell phone out
of a certain group of cell phones can be chosen as a dependent component of a
superordinate rate plan.
Sales Sales components are products that are part of a sales package and hence are the
Components subordinate products of the sales package itself. Sales components can be rate
plans, combined rate plans and one-time products offered for sales such as a cell
phone.
Sales components are maintained at the superordinate product, i.e. at the level of the
sales package product.
Sales components can be made optional, enabling the user to choose the component
during the sales process or not.
Sales components can also be grouped. If the group itself is not flagged as ‘optional’,
the user has to choose one component within this group. An example would be that a
cell phone out of a certain group of cell phones can be chosen as a sales component
together with a rate plan (the other sales component within the package) upon the
initial sales of a package.
Combined A combined rate plan (CRP) enables the combination of different rate plans under a
Rate Plan new superordinate product and establishes a very strong link between the contract
items created by selling the CRP. Only products of the type rate plan can be used in a
CRP. There are no optional components in a CRP, i.e. all products that are assigned
automatically appear in the order, in case the superordinate product, i.e. the
combined rate plan, is ordered.
Example:
CRP ‘Double Play’ consisting of components
ADSL 6MBIT Rate Plan
Wireline Rate Plan

With SAP CRM 7.0 Enhancement Package 3, combined rate plan functionality is
mainly limited to sales processes. Combined rate plans should therefore only be used
if no other concept can be taken.

2.2 Recommendations for Setting Up Product Master Data

With CRM 7.0 Enhancement Package 3, customers can use different concepts to implement their
products in the system. Among others, customers can use sales packages, rate plans, combined rate
plans, dependent components and configurable products. In many cases, a combination of these
concepts is likely to be required to meet all requirements.
Setting up the product master data is a central process for each industry project using Provider Contract
Management. The main reason for this is that the products cannot just be seen as mere master data, but
they also drive the way the change processes work and the way communication is done with 3 rd party
systems, for instance billing systems or provisioning systems. It is often not sufficient to define a product
structure based on what is initially sold, but many other implications have to be considered.
The main challenge is to find out which of the above-mentioned concepts can be used in the best way
and how they can be combined, especially when products are bundled and have different optionsAn
industry-specific offer could look as follows:

56
Configuration Guide

To come up with an adequate product structure for such a requirement, it is important to analyze the
following items more closely:
Sales Package vs. Configurable Products vs. Combined Rate Plans
Modeling of Configurable Products
The contract life-cycle from initial sales to extension, up- and downgrades to a potential early
cancellation or termination at the end of the contract period.

2.2.1 Sales Package vs. Configurable Products

Apart from sales packages, CRM 7.0 Enhancement Package 3 also offers the possibility to create
configurable products using SAP CRM’s Product Modeling Environment (PME). Configurable products,
and in most of the cases configurable rate plans, could be used to create bundle-like products using Bills
of Material (BOM). The functionality, however, is slightly different and the differences can be found here:

Packaging with Interlinkages Product configuration

Builds a structure of several independent Specifies the characteristics (options) of a single
products. products (and it‘s components)
Relationships are transient and do not exist in Relationships are persistent, i.e. the result can only
follow-up processes (disassembling of package). be changed by the configurator.
Loose coupling Tight coupling
Dependencies are top-down (unidirectional) and Dependencies can also exist bottom-up and include

57
Configuration Guide

focused on selection or proposal of a product domain restrictions and value inferences.

(“smart order BOM”).
No or limited interaction (optional and alternative Decoupled interactive UI with rich interaction.
components) required when capturing in the
order.
„Outer layer“ with or without configurable „Inner layer“ you may use product configuration
components. inside packages

All these factors should be considered when taking the decision whether to use sales packages or
configurable products (configurable rate plans) to bundle products. In a lot of cases it is a combination of
both concepts.

2.2.2 Modeling of Configurable Products

Once a decision has been made to use configurable products, for instance configurable rate plans, there
are several points that have to be considered. Among others, it is important to model products in the most
efficient way.
As already mentioned earlier, the product modeling environment (PME) is used to create the
configuration. PME functionality is also tightly integrated into telecommunications specific processes. It
provides a number of reference characteristics, for instance, that can be used in order to influence certain
data. The following references are available:
http://help.sap.com/saphelp_crm60/helpdata/en/47/68c3aedc6e17f9e10000000a42189c/frameset.htm

In addition to that, it is also possible to influence the setting of characteristics/values by means of a BADI,
namely CRM_CONFIG_BADI. Using the method set_values, characteristics could automatically be
pre-populated before a user actually configures a product. This is required if custom fields which cannot
be found in the list of standard reference characteristics need to be set prior to the configuration.
Example: The availability of certain product options depends on technical requirements. Before the
configurator is launched, the service level is determined and passed to the configurator using the method
above. Thus, options which are not available can be hidden.

Another critical point with regard to configurable products is the decision, whether options of the
configuration should be represented as own products (as part of the BOM) or as characteristics/values
within the product model.
To give an example: A rate plan is set up for an ADSL product. As an option, this ADSL rate plan offers a
virus protection. For this simple scenario, different options are possible, among others:
1. ADSL is set up as a configurable product, virus protection is considered as an
option/characteristic of the according product model
2. ADSL is set up as a configurable product, virus protection is another product that is added to
the order by as part of the sales BOM of the ADSL product (i.e. when the option for virus
protection is chosen, the according product is added to the order)
From the sales point of view, both concepts are similar; the user would not see a big difference. For
integration purposes, however, the difference is notable.
In most of the cases, the following points favor the creation of an own product for options:
The option requires its own date fields as the duration or cancellation rules as they are different
from the main item
The option requires its own technical object
The option requires its own status management
58
Configuration Guide

rd
A separate product is required for integration with 3 party systems
Below, you find a comparison between the two possible options:
Using Sub items All information is in the main item
Sub items can be used as a container to store All information needs to be stored on the main item
technical data, status, dates and partner (rate plan). This might require additional
information which relates to this option. development.
Sub items are performance intensive. Response Response times independent of the rate plan
times grow with the amount of sub items (note complexity.
1140234).
Provider order can get pretty “cluttered” if many sub Cleaner order with fewer items.
items exist.
If pricing is done on sub item level, a clear Billing (variant pricing) and activation
distinction between activation and billing relevance (configuration) are distinct by definition.
becomes difficult.
Products are CRM global and easy to reuse. Characteristics can be reused only within a
knowledge base.
Telco providers are more familiar with products Options depend on a rate plan and should
than with the concept of product configuration. therefore not be treated as individual products.

Taking these points into consideration, a decision can be carefully made. While doing so, it is also
important to mention that this decision has an impact on pricing. Representing options as
characteristics/values generally enables the use of variant conditions. If sub items are used, pricing could
also be done on sub item (i.e. product) level, but still variant conditions could be used (i.e. the sub items
are only containers for date/status/technical object).
The advantage of doing pricing with variant conditions is the bigger flexibility. In essence it allows
separating the commercial side (pricing) from the technical side (triggering the provisioning). Prices can,
but do not need to be tied 1:1 to an option, but instead can depend on other parameters. For example, a
voice mail option could have a surcharge with analogue lines, but none or a lower one with ISDN. In other
cases, a group of options can have a "package price" or an option is free of charge for a particular main
item.
Drawbacks are that the full pricing overview requires the configuration UI. With the new pricing view of
SAP CRM 7.0 Enhancement Package 1, the individual pricing conditions can also be seen in the item
overview page. Whether variant conditions can be used also depends on how the integration to the billing
system is realized.

2.2.3 Recommendations on Product Structure for Usage in Provider

Web Shop
Note that specific recommendations must be considered when modeling industry-specific products for
usage in the Sales Order Processing B2C in CRM Web Channel:
1. A product must not be modeled in a way that it contains a component that is a sales package.
The display of a sales package as a component of a super-ordinated product is not supported in
the Web shop.
2. A product that is a configurable material (e.g. a configurable rate plan) or contains a configurable
material (e.g. a sales package that has a configurable rate plan assigned via a sales component
interlinkage) must not be modeled in a way that due to a selected configuration option a sub-item
is generated, that itself has components maintained via interlinkages. Instead these components
59
Configuration Guide

should be assigned directly to the configurable material (e.g. to the configurable rate plan) or to
the superordinated product (e.g. to the sales package) via an interlinkage type.
3. When assigning a grouping of components to a product (e.g. assigning the grouping ‘rate Plans’
to a sales package) the grouping can either be mandatory (a component of the grouping must be
selected for ordering the superordinated product) or optional (no component from the grouping
needs to be selected for ordering the superordinated product).
In case the grouping is marked as mandatory, it must be assured in the product modeling that at
least one component is assigned to the grouping and that in any case at least one component
can be selected for the grouping by the customer in the Web shop.
If the grouping is optional the grouping will only be displayed in the Web shop if at least one
component can be selected by the customer in the Web shop.

2.2.4 Recommendations on Product Structure using Lean

Customizing
With SAP CRM 7.0 Enhancement Package 3, customers can make use of configurable products that
have a BOM structure or different options in a very efficient way. Lean customizing of item categories
offers a way of high usability and performance for creating telco products.
In order to make full use of high performance lean customizing, the following recommendations should be
considered:
Rate Plans should find a lean item category
Options of a rate plan (e.g. virus protection) should only be set up as products in the sales BOM if
rd
the options are relevant for 3 party systems. In case they are not relevant, they should just be
represented by means of characteristics/values of the product model
Options of rate plans (e.g. virus protection), if needed as sales BOM products, should be find
extra lean item category. Pricing should be done by means of variant conditions on rate plan level
Activation fees should be set up as products and be part of dependent components/sales
components
In case a sales package with several rate plans that have different options is sold, one main
configurable rate plan should be created (similar to a combined rate plan), from which all
configuration is done. The other rate plans would be part of the sales BOM of this main rate plan.
This main rate plan can be seen as an auxiliary product and should also be copied into the
contract.

60
Configuration Guide

Example of how to set up a sales package using lean customizing:

The main rate plan (Wireless + Internet + IPTV Triple Play) is a configurable product. All other rate plans
(IPTV, Wireline RP, ADSL 6MBIT) are configurable products as well. Configuration can be initiated from
the main rate plan. For all rate plans, the lean item category should be found, whereas for the
components (Virus Protection), the extra lean item category should be found.
The example looks as follows in the system:
Order Overview in the Interaction Center:

Component View of Rate Plans ADSL 6MBIT in the Interaction Center:

61
Configuration Guide

The above recommendations are general recommendations. It might not be applicable to each customer
or meet all business requirements. Note also that functionality of lean and extra lean items is limited for
performance reasons.
For more information about the set up for lean items, see chapter Lean Items in Provider Orders.

2.2.5 Product Purpose

To be able to define products that are used for different puropose, you can classify products for different
purposes. You do this by creating different product categories and then assigning the product purpose in
Customizing under Customer Relationship Management -> Cross Industry Functions -> Master Data ->
Products -> Define Settings for Product Categories
The following product purposes are supported:
Standard Product
Standard product for usage in provider orders/contracts. Products are also used as standard products
if no definition is made for a certain product category.
Standard products cannot be used in revenue distribution contracts or master agreements to redefine
products so they are suitable for customer-specific requirements.
A Master Agreement Product
Master agreement products can only be used in master agreements to define customer-specific items
that for example store customer-specific prices. These master agreement items are later used as a
reference for provider orders.
You cannot use master agreement products directly in provider orders without referring to a master
agreement item that uses the same product
B Revenue Distribution Product
Revenue distribution products define the rules for distribution of revenue for third-party companies or
partners if customers buy or consume services that these partners are involved in providing .
Revenue distribution products can only be used in revenue distribution orders/contracts.
If you use products in a manner that does not conform to the purpose derived from the product category,
the system displays an error during document processing.

2.3 Recommendations for Setting Up Integration with SAP

Convergent Charging
2.3.1 Cross Catalog Mapping in Documents
When you create a sales order, the current CCM version ID of the product is copied into the sales order
document. The determination of the version ID is done as follows:
Only CCM versions with the status Released are considered by the determination. The date of the
appointment type “IST_BOM_EXPL” is compared with the Valid From date of the released CCM versions.
If the order is copied to the contract, the CCM version of the sales order is also copied to the contract.
If a change process is executed, the CCM version is copied from the contract to the change order.
However, if a product change process is executed, the CCM version is determined by the new product
and will not be copied from the contract.

62
Configuration Guide

2.3.1.1 Cross-System Item ID

Relevant processes – for example the billing of consumptions (phone call) – require the identification of
contract line items across system borders, for example, which CC contract item is related to a line item in
an SAP ERP contract.
In contrast to document objects, a new concept for identification of line items is required. Changing a
contract in SAP CRM leads to new time slices for the contract document. Each time slice is implemented
by a line item in a contract. These line items are linked by a predecessor/successor relationship.
The system creates a cross-system item ID for each line item in the SAP CRM contract. When a contract
is changed, the crosssystem item ID is transferred from the predecessor line item to the new time slice in
the new one.
If a product change process is executed, the cross-system item ID from the line item in the “old” product is
transferred to the time slice in the new one.

2.3.2 Enhancement Concept

You can enhance the Cross Catalog Mapping if you want to incorporate another product view or enrich
the existing charge plan mapping. You can add set types which are suitable for the the existing hierarchy
of set types, you can enter a corresponding logic to fill these set types or you can create a corresponding
UI to be included to the existing CCM version maintenance views.
2.3.2.1 Enhancing the Set Type Hierarchy for Cross Catalog Mapping
2.3.2.1.1 Set Type Hierarchy Concept
You can use the set types for products to maintain additional data by defining a set of attributes and
combining them in a set type definition. The activation of the set type triggers the generation of the
database table and all structures and function modules that are needed to maintain this set type. Any kind
of set type will result in a database table that has the client and the product GUID as a key and the
selected attributes (in addition to some administration attributes).
If you want to store several lines for each product (as required for the set types used in CCM), you must
define additional key fields in the set type. For the set type CRM_ISX_VERSN, which contains the CCM
versions, the additional key field has the attribute CRM_ISX_VERSION.
The field version is a key field in the set type CRM_ISX_VERSN (transaction COMM_ATTRSET)

63
Configuration Guide

The field version is part of the key of database table CRM_ISX_VERSN (transaction SE11)

The set type CRM_ISX_VERSN is the top level set type of the hierarchy of set types. You can implement
one set type for each object, that can be maintained in a version, and inherit the table key field VERSION
to facilitate drill down access.
Depending on the cardinality between the enhanced level (in this case the CCM version) and the next
level entity (in this case the charge plan assignment) an additional key field may be required. Since you
can assign several charges to one version (cardinality 1:n), the following additional key field has been
introduced: Charge plan assignment GUID ASSI_GUID.
Using this concept and the structure of the SAP CC entities charge plan and refill plan as a basis, creates
the following set type hierarchy with the corresponding key:
Set Type Description Additional Key Field
CRM_ISX_VERSN CCM Version VERSION
CRM_ISX_VERSNT Version Description LANGU
CRM_ISX_CPASSI Charge Plan Assignment ASSI_GUID
CRM_ISX_CPASST Assignment Description LANGU
CRM_ISX_PARAM Charge Plan Parameters PAR_ID
64
Configuration Guide

CRM_ISX_COUNTR Counter Sharing CCCNT_ID

CRM_ISX_ACASSI Account Assignments CCACAS_ID
CRM_ISX_TECRES Technical Data CCTD_ID
CRM_ISX_SERVIC Service IDs CCST_ID

As a result, the set type CRM_ISX_SERVIC has the longest key in the hierarchy (in addition to the client
and product guid) VERSION, ASSI_GUID, CCTD_ID and CCST_ID.
To implement generic functions for CC versions, this hierarchy information is stored in the Customizing
table CRMC_ISX_VRS_STT.
Delivered content of Customizing table CRMC_ISX_VRS_STT

The entries in this table are similar to the entries in the set type hierarchy and define the higher level set
type. The system automatically determines the additional key field for each level by comparing it with the
higher level set type, starting from CRM_ISX_VERSN at the top level.
Deleting open and copying CCM versions (during the creation of a new CCM version or when copying a
product) generically processes this set type hierarchy and can therefore be adapted to consider additional
set types by adding them to the Customizing table CRMC_ISX_VRS_STT. When copying versions, the
column Key Field is a GUID is selected. This field is related to the additional key field of a set type and
has to be selected if this key field is a GUID field that needs to be determined again when it is copied.
Key Handling in Copy Process
Versions are copied by copying the corresponding entries to an entry with the new version ID and the
new product GUID if a product is copied. The additional key fields of the lower level set types remain
unchanged.
If the additional key field of a set type is a GUID and needs to be generated again, the flag has to be
selected in the Customizing table CRMC_ISX_VRS_STT. The system exchanges the GUID with a new
GUID and maps the old GUID to the new GUID for all lower level set types.
2.3.2.1.2 Adding Set Types to the Hierarchy
Before you create or add a set type for CCM, you must clarify, how the new data fits the existing hierarchy
of set types.
If you want to add information to an existing entity in the hierarchy, you can create a new set type with the
same key as the enhanced object. This requires a set type with the key fields VERSION, ASSI_GUID and

65
Configuration Guide

PAR_ID. The entry for this set type is then entered with the higher level set type CRM_ISX_CPASSI in
the set type hierarchy on the same level as the parameter set type.
If you want to add new objects to CCM that allow the cardinality 1:n (similar to charge plan mappings), a
set type with the key fields VERSION and a new key field, that identifies the assigned object, are
required. The entry for this set type is then entered with the higher level set type CRM_ISX_VERSN in the
set type hierarchy. If the additional key field is a GUID and needs to be regenerated when the versions
are copied, you must select the flag Key Field is GUID for this Customizing entry.
Customizing covers the following functions:
Copy mapping data when creating a new version and a version already exists
Copy mapping data when copying a product that contains a mapping version
Deleting an open version

You have to implement the filling of set types on the UI and then define, which one you want to include to
the product maintenance UI.
Hints for New Set Types
To improve performance during product maintenance you can implement a context dependent reading in
the generated function module COM_<settype_name>_READ_W_P
Check the examples in COM_CRM_ISX_PARAM_READ_W_P or
COM_CRM_ISX_CPASSI_READ_W_P.
2.3.2.2 UI Enhancements
When you have added set types to the hierarchy, you need to enhance the CCM UI to make your set type
visible. The CCM UI is implemented in the UI component ISX_PRD_MAPPING.
Cross Catalog UI Concept
CCM is part of the product maintenance. The product overview only contains the mapping version list:

66
Configuration Guide

Choose an entry in the column Mapping Version to navigate to the subscreen Mapping Version Details.

The subscreen is implemented on the overview page: ISX_PRD_MAPPING/VersionOV and displays all
views found at VERSION hierarchy level:

The example above displays the views:

ISX_PRD_MAPPING/VersionDetail that contains the version detail fields
ISX_PRD_MAPPING/AssignmentList that contains all charge plans for the current version as a
list
ISX_PRD_MAPPING/RefillPlanList that contains the refill plan of the current version as a list

67
Configuration Guide

Charge plans have one more hierarchy, because more data has to be displayed. You can navigate to the
next level down to display the subscreen for the charge plan:

The charge plan subscreen is implemented on the overview page ISX_PRD_MAPPING/ChargePlanOV,

which contains all dependent data for the ASSI_GUID (charge plan assignment) hierarchy level.
2.3.2.2.1 Create/Enhance the UI at VERSION Hierarchy Level
If you want to create or enhance the UI at VERSION hierarchy level, proceed as follows:
Create an enhancement set and enhance the ISX_PRD_MAPPING UI component. For more information
about the enhancement of a SAP CRM UI component, see Framework Enhancement on the SAP Help
Portal.
1. Create a node in the custom controller ISX_PRD_MAPPING/ChargePlanCuco for the new set
type (enhance the custom controller). This node should be dependent on the existing VERSION
node (like the node ASSIGN is dependent on the node VERSION)
2. Create a view in the enhancement of the component ISX_PRD_MAPPING that contains data for
the new set type. The implemented view contains the node for the new set type. This node should
be bound to the previously created node in the custom controller.
3. Enhance the overview page ISX_PRD_MAPPING/VersionOV and add the new created view to
the overview page in the runtime repository editor. Adjust the configuration of the overview page
(add the new available assignment block to the list Displayed Assignment Blocks and define a
title for it).

2.3.2.2.2 Create/Enhance the UI at Sub Level

If data that is dependent on the new set type exists (like charge plan parameter is dependent on charge
plan), you must create a new sub overview page (like the charge plan overview page
ISX_PRD_MAPPING/ChargePlanOV). To do this, proceed as follows:
1. Add the new overview page to the window ISX_PRD_MAPPING/VersionEditWindow in the
runtime repository:

68
Configuration Guide

2. Create all dependent views (for dependent set types) and add them to the new overview page
3. Implement the navigation from your new set type view to the new sub overview page (like
ISX_PRD_MAPPING/AssignmentList to ISX_PRD_MAPPING/ChargePlanOV). The sub overview
page should contain the back button as a minimum.
4. All nodes in the charge plan detail views are bound to nodes in a charge plan detail-specific
custom controller (ISX_PRD_MAPPING/ChargePlanDetailsCuco). All dependencies are
implemented in this custom controller (see the ON_NEW_FOCUS methods in the node classes).

SAP recommends implementing a similar custom controller for the new dependent set types.

2.3.3 Price Versions

When you model a cross catalog product, the data in SAP CRM is mapped to the charge plan data in the
SAP Convergent Charging System. Each mapping version has a validity period and is identified by a
unique mapping ID. Recurring charges are relevant for each mapping version. Typically, one price is valid
for multiple mapping versions. The price version can therefore be used as a reference within mapping.
You can maintain recurring charges in SAP CRM by using pricing condition records. The price version
field is part of the variable key for the condition record.

2.3.3.1 Process

If you want to create condition records, add a price to the pricing assignment block of the product. The
available price versions are restricted to the data already available in Cross Catalog Mapping for the
relevant product. You can only enter a price version that has been defined in mapping.
2.3.3.2 Customizing Settings
The first step of the access sequence 0PPA uses the price version field. The following attributes are used
during the access:
SALES_ORG sales organization
DIS_CHANNEL distribution channel
PRODUCT current product to be priced
69
Configuration Guide

PROV_PRICE_VRS price version of the cross catalog product mapping used

When working with packages, the attribute PARENT_PRC_PRODUCT is also used.

The default condition type 0PMR (recurrent fee) is available in the condition group PROD_PROV, using
the attributes for the access. The assigned text is Monthly Fee dep. Price Version and Month. Fee dep.
pack./vers. for packages.

2.4 Setting Up Web Services for Communication to SAP CC

Integration between SAP CRM and SAP CC is provided using set of Web services from SAP CC Server.
SAP CRM acts as the consumer of these Web services. Several steps have to be executed to make
these services available in CRM.
A generated consumer proxy has already been provided for each service in CRM. Detailed
communication aspects, such as the destination server, transport protocol, access credentials and so on
have to be set up according to the specific system landscape involved. You use the transaction
SOAMANAGER to make these settings. SOAMANAGER can be used to create several ‘logical ports’ with
different configurations for each service. Integration between SAP CRM and SAP CC uses the logical port
defined as the default port for communication between the systems. For more information, see the
SOAMANAGER documentation.
You can currently set up the following services in CRM for communication with SAP CRM:
Catalog service: used to access relevant objects from the product catalog in SAP CC (charge
plans, refill plans, mapping tables)
External name: CO_CRM_ISX_CC_CATALOG_SERVICES
Internal name: CatalogServices
Rating service: used to trigger activation of charges in SAP CC
External name: CO_CRM_ISX_CC_RATING_SERVICES
Internal name: RatingServices
To maintain logical ports for the SAP CC services in SOAMANAGER, select the link ‘Web Service
Configuration’ from the tab ‘Service Administration’ and search the services according to the ‘Consumer
Proxy’ and use the external or internal name as the search pattern.
Note that the PING feature in SOAMANAGER does not work for the services listed above since SAP CC
does not support this feature.
For information about the following,
Access WSDL
Setup security layer (Authentication, SSL)
General technical settings
see the SAP CC documentation.

2.5 Product Maintenance

2.5.1 Business Roles for Maintaining Product Master Data
For industries using Provider Contract Management, there is no business role provided in the standard
that is exclusively dedicated for maintaining products. Thus, depending on the requirements, it could be
recommendable to create such a business role. Still, there are some business roles provided which
enable the maintenance of products, for instance the ECO-MANAGER roles. On the basic of this role, the
creation of product, packages and so on will be explained – the mentioned paths of navigation will
consequently depend on this.
For creating business roles, refer also to Define Business Roles in this document.

70
Configuration Guide

2.5.2 Roles for Defining Packages

CRM 7.0 Enhancement Package 1 contains a special role (SAP_CRM_PROVIDER_PACKAGES) that
should be assigned to all users maintaining provider packages.
To assign this role, use transaction /su01 and assign this role to each user.
Note that previously, customer has to generate the profiles for this role via transaction pfcg.

2.5.3 Customer-specific Roles for Defining Packages

Some customers might need roles, apart from SAP_CRM_PROVIDER_PACKAGES, which will limit
user’s authorizations with regards to the creation of packages, combined rate plans and so on. In some
cases it might be necessary that users are only allowed to display packages in the product master, but
not to create them. For this purpose, it is possible to define customer specific roles by copying for
instance SAP_CRM_PROVIDER_PACKAGES (transaction pfcg).
The limitation of users’ authorizations is possible on interlinkage level. For each interlinkage type (e.g.
combined rate plan, sales package and so on), customer can decide, what shall be "display only" and
what can be changed. Note that the settings are done by means of the main relationship type of the
according interlinkage. If you want to set authorizations for sales packages, you can do it via relationship
type scslc - Sales Components, which is the main relationship type for interlinakge sales packages
(compare chapter Product Terms).

2.5.4 Define Rate Plans

...

1. Define rate plans in SAP CRM UI (role of ECO-MANAGER): Catalog Management Products
New Products.
2. Provide Base Category ID and Item Cat. Group ID
A. If you use CRM in connection with SAP ERP, you have to ensure that the system can find the
object type for the order item. To do so, include item Base Category ID ‘MAT_HAWA’ and ITEM
Cat Group ID ‘PRRP’ in the rate plan. Click the Back button and go to the box Category. Click
Edit and select the Hierarchy ID Provider. You get a result list and you pick the category CRM
Rate Plan. Now you can save it with the Back and Save button (only valid if you keep to the
recommendations for categories and hierarchies earlier mentioned in this guide).
B. If you use SAP CRM standalone, you have to ensure that the system can find the corresponding
object type for the order item can. To do so, include item Base Category ID ‘CRM_RATEPLAN’
and ITEM Cat Group ID ‘PRRP’ in the rate plan (only valid if you keep to the recommendations
for categories and hierarchies earlier mentioned in this guide).
3. Define the components in tab Dependent Components (optional).
4. Add anything needed for the rate plan.

2.5.5 Define Combined Rate Plans

...

1. Define combined rate plans in SAP CRM UI (role of ECO-MANAGER): Catalog Management
Products New Products.
2. Provide Base Category ID and Item Cat. Group ID
A. If you use CRM in connection with SAP ERP, you have to ensure that the system can find the
object type for the order item. To do so, include item Base Category ID ‘MAT_HAWA’ and ITEM
Cat Group ID ‘PRNP’ in the combined rate plan. Click the Back button and go to the box
Category. Choose Edit and select the Hierarchy ID Provider. You get a result list and you pick the
category CRM Combined Rate Plan. Now you can save it with the Back and Save button (only
valid if you keep to the recommendations for categories and hierarchies earlier mentioned in this
guide).
B. If you use SAP CRM standalone, you have to ensure that the system can find the corresponding
object type for the order item. To do so, include item Base Category ID ‘CRM_CRP’ and ITEM

71
Configuration Guide

Cat Group ID ‘PRNP’ in the rate plan (only valid if you keep to the recommendations for
categories and hierarchies earlier mentioned in this guide).
3. Define the components in tab Rate Plan Combinations.
4. Add anything else needed for the combined rate plan.

2.5.6 Define Sales Packages

...

1. Define sales packages in SAP CRM UI (role of ECO-MANAGER): Catalog Management

Products New Products.
2. Even though sales packages do not usually have any commercial significance, you require the
assignment to a distribution chain and information on this distribution chain (set type
CRMM_PR_SALESA).as a minimum.

SAP advises you to create an assignment to a category created for material types, such as MAT_HAWA
(if SAP CRM is used with SAP ERP) or CRM_SALES_PACKAGE alone (if CRM is used standalone), as
they contain all of the set types required.

3. Provide Base Category ID and Item Cat. Group ID

C. If you use SAP CRM in connection with SAP ERP, you have to ensure that the system can
explode the sales packages in the telecommunications order so that the system can find the
corresponding object type for the order item. To do so, include item Base Category ID
‘MAT_HAWA’ and ITEM Cat Group ID ‘LUMF’ in the sales package. Click the Back button and go
to the box Category. Click Edit and select the Hierarchy ID Provider. You get a result list and you
pick the category CRM Sales Package. Now you can save it with the Back and Save button (only
valid if you keep to the recommendations for categories and hierarchies earlier mentioned in this
guide).
D. If you use SAP CRM standalone, you have to ensure that the system can explode the sales
packages in the order so that the corresponding object type for the order item can be found. To
do so, include item Base Category ID ‘CRM_SALES_PACKAGE’ and ITEM Cat Group ID ‘LUMF’
in the sales package (only valid if you keep to the recommendations for categories and
hierarchies earlier mentioned in this guide).
4. Enter all sales products in tab Sales Components. You can use additional attributes to influence
explosion of the package during order entry.
Group:
The system offers you products with the same group entry as a selection list during order entry,
so that you can only select one product from a group. This can be used to define alternative
products the user can choose between.
Optional:
You can select or deselect the product during order entry. Products that are not defined as being
optional are mandatory, which means that in the order screen, the selection check box is
grayed out.
Default:
If a product is optional, the "default" setting determines whether it is selected in the initial
explosion. For products in a group, the meaning is different: the "default" product shows up in
the dropdown list box of the alternative products.
Explosion Type:
The explosion type can be either Sales Document or Object List. The first one should be used for
all sales processes, whereas the latter one is only used for the CRM service scenario.
Valid from/to:
72
Configuration Guide

The product is only valid with the specified time period.

Note: If a product is not valid at the current date, you might not see it in the maintenance screen.
To also see obsolete products, choose More -> Show All in the menu.
Price Level:
Abstract value, which is transferred to price determination using the pricing structure. It could
either be used as an additional criterion (e.g. the same product appears twice in the package
with different prerequisites. The price is different depending on the prerequisite) or to model
prices for multiple products with just one condition record (e.g. one price for 11 different entry-
level phones).
Prerequisite:
The sales component is only part of the order, if the product or group specified here is also in the
same order.
Sorting:
The items will exploded in the order according to the sequence they are added in tab Sales
Components.

2.5.7 Define Dependent Components

You define dependent components in SAP CRM in the SAP CRM Web UI (role of ECO-MANAGER):
Catalog Management Products on the block Dependent components directly in the product to which
you want to assign them.
Attributes for the product relationship mainly consist of requirements that control the explosion of products
in the telecommunications order. The system only creates the product in the order if all requirements
formulated have been met.
You can define the following attributes:
Group:
The system offers you products with the same grouping entry as a selection list during order entry.
This means you can only select one product from a grouping.
Optional:
You can select or deselect the product during order entry. Products that are not defined as being
optional are mandatory, which means that in the order screen, the selection check box is grayed out.
Default:
If a product is optional, the "default" setting determines whether it is selected in the initial explosion.
For products in a group, the meaning is different: the "default" product shows up in the dropdown list
box of the alternative products.
Explosion Type:
The explosion type can be either Sales Document or Object List. The first one should be used for all
sales processes, whereas the latter one is only used for the CRM service scenario.
Valid from/to:
The product is only valid with the specified time period.
Note: If a product is not valid at the current date, you might not see it in the maintenance screen.
To also see obsolete products, choose More -> Show All in the menu.
BRF Event:
The system only explodes the product if the assigned BRF event was triggered successfully and returned
the result "true". In the package maintenance, you can only enter the name of the event. The actual rule is
maintained in the transaction BRF in SAP GUI (see Business Rule Framework in SAP CRM). It is
possible, for instance, to add a dependent component that is only exploded to the order when contract
duration of 24 months is chosen. This can be realized by the assignment of an adequate BRF event

73
Configuration Guide

Process Type:
The system only explodes the product if you have created the order for the corresponding process type. If
you do not make an entry in this field, the system uses the product in all processes.
Prerequisite:
The dependent component is only part of the order, if the product or group specified here is also in the
same order.
Source, Value Characteristic, UOM, Fixed Quantity:
The Quantity of dependent products can be set and may depend on configuration of parent product. Note:
the determined quantity cannot be changed manually in the order. Editable quantities require an implicit
enhancement in method PREP_ITM_UPDATE.
Source: Number of dependent components to be added to the order can be set to
a Fixed Value or can be copied (Copy Value) from a numeric characteristic of the
parent product.
Value: If source is set to Fixed Value, the value can be entered here.
Characteristic: If source is set to Copy Value, a numeric characteristic from the
parent product can be specified here, from which the quantity for the dependent
components is derived.
UOM: Unit of Measure for the dependent component.
Fixed Quantity: The component quantity defined above will be multiplied with the
quantity of the header material unless this flag is set. A fixed quantity is
independent of the header.
Example: your campaign promises 2 digital receivers per household. For one
apartment building, three cable connections are ordered and thus, 3*2 =6 receivers
are shipped. However, there is only 1 onsite installation service regardless of the
number of households.
Value Propagation:
See chapter Value Propagation.
Sorting:
The items will exploded in the order according to the sequence they are added in tab Dependent
Components.

2.5.8 Triggering Solution Configurator Decomposition

Business Rule Framework (BRF) rules can be used for the product decomposition via Solution
Configurator (SC). In general, all order fields can be used in BRF rules. Normally it would be expected
that the SC is triggered after any order change to take the changes into account if they are processed by
the BRF. This has a negative impact on the performance of the order application.
On the other hand, it cannot be foreseen which fields customers want to use in the BRF rules. A
prominent example is the contract duration.
First you should get familiar with event handler table available in SAP CRM implementation guide. See
documentation of Transaction CRMV_EVENT. Business transaction (e.g. provider order) processing is
controlled by the event handler. Using event handler table customer may add additional processing
triggered by events as required.
Processing of SC decomposition is executed in function module CRM_SC_EXPLOSION_EC.
Instead of calling function module directly, triggering is done via event available from transaction
framework. This event driven approach leads to improved performance, preventing validation to be run
too often.
Function module is registered for event “SC_VALIDATION”. Triggering of this event is done as follows:

CALL FUNCTION 'CRM_EVENT_PUBLISH_OW'

EXPORTING
74
Configuration Guide

iv_obj_name = gc_object_name-orderadm_i
iv_guid_hi = iv_object_guid
iv_kind_hi = gc_object_kind-orderadm_i
iv_event = gc_event-trigger_function
iv_attri1 = 'SC_VALIDATION'.

Variable IV_OBJECT_GUID points to the current line item,

Since validation shall be dependent on changes of certain provider orders, you have to add additional
functions to the event table registered to changes of relevant fields. The following entry, for example, is
done when changes of contract duration shall be handled.

Function module CRM_ISX_CONTR_DURATION is available as exemplary implementation.

2.5.9 Integration of Recurring Charges with SAP CC

In the consume to cash scenario, condition records for recurring charges need to be replicated from SAP
CRM to SAP CC. Price conditions are maintained in the product master in SAP CRM. Some price
conditions represent recurring charges.
SAP CRM pricing determines the (gross or net) prices, discounts and surcharges based on the condition
technique. The condition technique allows prices to be defined according to marketing requirements.
These marketing requirements are controlled by SAP CRM and do not need to be modeled in SAP CC.
Marketing-driven pricing criteria are campaigns or customer groups, which can determine the price
conditions of a product. All master data can be used for price determination in SAP CRM pricing. Since
not all master data is available in SAP CC, pricing takes place in SAP CRM and not in SAP CC. The
pricing conditions need to be replicated from SAP CRM to SAP CC, since the charging of the recurring
charges takes place in SAP CC.
A limitation of the current implementation is that you must maintain pricing master data using the same
currency as that used in sales order documents.

75
Configuration Guide

2.5.9.1 Concept of Price Key in Recurring Charges

All fields in a condition table, which influence a price condition, are grouped using an ID known as the
price key. This price key ID is used to replicate the condition records from SAP CRM to SAP CC. A new
Customizing activity is provided in SAP CRM, which can be used to define the relevant condition types
that represent the recurring charges.
The price key is available in the OBJECT_ID field for each condition record to be replicated to SAP CC.

Recurring charges – Definition of condition

records
CRM: Condition table

key1 key2 key… ID From To Amount …

Price conditions are
A A A 1234 1.1.09 31.12.09 9,90 €
maintained in CRM.
A A A 1234 1.1.10 31.12.99 11,90 €
Replication of ID, validity
A A B 5678 1.1.09 31.12.99 19,99 € and amount to SAP CC.
Price changes are
maintained as new condition
records with reference to the
same ID.
SAP CC: Mapping table
Assumption: Only prices
ID From To Amount … on product level supported.
1234 1.1.09 31.12.09 9,90 €
Assumption: Mapping
1234 1.1.10 31.12.99 11,90 € tables will be defined on
5678 1.1.09 31.12.99 19,99 €
SAP CC offer level. -> Table
will not become too big.

© SAP 2008 / Page 9 internal

The condition record (access fields) are not replicated, only the price key, validity, amount and currency
are transferred to SAP CC. Even if you have defined specific condition tables in SAP CRM, you do not
have to modify the integration for recurring charges.
When changing the price for a specific key combination starting from a specific date, the SAP CRM
System creates a new condition record. The system automatically assigns the price key used in the
prvious record to the new condition record.
2.5.9.2 Define Relevant Condition Types
To replicate the records to SAP Convergent Charging correctly, the system first generates the price key ID.
Make the relevant settings in Customizing under Customer Relationship Management -> Cross Industry
Functions -> Master Data -> Price Conditions -> Define Price Conditions for Distribution to SAP Convergent
Charging.
You can now generate the price key IDs and transfer them with the corresponding data to SAP CC.
2.5.9.3 UI for Price Changes
The price change function is an input help used to facilitate the process of making date-dependent price
changes to existing condition records. It is only available for Provider Rate Plans. This is identified by the
product role Rate Plan.
76
Configuration Guide

The button is available during list maintenance for prices only. Choose Edit List from the Prices
assignment block to switch to list maintenance.
Select a single condition record and press Price Change. The system then asks for the new price and the
validity start date. Choose a new validity start that is found between the validity start and the end of the
original condition record. Press Change Price to save the settings.
When the system has accepted the new price and validity start date, it creates a copy of the selected
condition record. The validity of the original record ends the day before the validity start of the new record.
The new price is stored in the new condition record.

The validity end date of the new record remains unchanged. If you change the price of a record for which
the validity end has already been defined, the validity of the new record is also limited. The system
displays a message accordingly.
2.5.9.4 Recurring Charges in Cross Catalog Mapping
The definition of recurring charges is also part of the commercial view of rate plan products that is
maintained in SAP CRM. When you assign a charge plan handling with recurring charges, you can link a
price key parameter to the condition type of variant alias to define, which condition record is referenced
during contract creation. The referenced condition records are maintained in assignment block for prices
in the product. You can use price versions to retain identical prices across multiple mapping versions.
2.5.9.5 Replication of Master Data with SAP CC
When you model product master data in SAP CRM, you also have to maintain pricing data.
In contrast to one-off charges, recurring charges have to be replicated to the SAP CC system since this is
where these charges are rated. In SAP CRM, pricing master data is stored as condition records.
The condition records relevant for rating/pricing are only transferred to SAP CC. You can control this by
defining condition types in Customizing.
Technically, replication is based on SAP CRM middleware and Web service technology. When you
maintain pricing master data in SAP CRM, the system generates a BDoc that is handled by SAP CRM
middleware containing updated data. To transfer BDoc data to SAP CC a new middleware site type has
been introduced. The new site type uses an outbound adapter that transfers the BDoc data to SAP CC
using Web services.
2.5.9.6 Setup Site of Site Type CC
To enable the system to replicate pricing data to SAP CC, you must add a site with the site type CC using
the SAP CRM Middleware Administration Console (Tx SOMEAC):
1. Select the object type Site and press Display Objects. A list of all the available sites grouped by
site type is displayed.
2. Choose Create Object to create a new site.
3. Enter object information for the new site:
o Name: Enter any name to identify the SAP CC System, for example hostcc1
o Description: Enter a descriptive text for the site, for example SAP CC Test System
o Type: Select SAP Convergent Charging
A site has to subscribe to a publication of a BDoc type to trigger the outbound adapter when processing a
BDoc in the message flow of the middleware. Create a new publication or use an existing one for BDoc
type CND_M_SUP and add a subscription to new site.
Using Queues in Outbound Processing
The sequence of transferred BDoc messages cannot be guaranteed by the SAP CRM middleware. Each
BDoc is processed individually. This can cause inconsistencies in the receiving SAP CC System. When
you activate queue handling in outbound processing, the content of the BDoc message is transferred to a
local queue in the SAP CRM System. The data in the queue is processed according to the sequence of
entries (FIFO). If a call fails, processing of the entire queue is terminated.
77
Configuration Guide

Usage of the queue is activated in the site attributes. This is available in the Administration console for
the middleware. Choose Site Attributes to display details about the site.
2.5.9.7 Monitor Communication
You can monitor BDoc messages using the transaction SMW1. The BDoc type of condition records is
CND_M_SUP. The column State indicates whether the processing of the BDoc was successful. To see
details about error messages, choose Show BDoc Msg Errors/Receivers. To process failed BDocs again,
choose Reprocess BDoc Message.
You can monitor the queue using transaction SMQ2 when queue processing is activated for a site. Since
queues are used here for serialization only, even if you use a queue to execute an outbound call, the
system uses an inbound queue to perform the call. You do not need to perform transports using RFC.
Data is transferred here using Web services. CC outbound calls are entered in the queue
CC_COND_OUTBOUND.
Failed entries can be removed from the queue using the delete function. The status of an executed queue
transaction is stored in a related BDoc. Error messages are available for BDocs. If an entry in queue is
waiting to be executed, the state of the BDoc is Sent to Receivers (not all have confirmed), as shown by a
yellow light in the column State of the result list in transaction SMW01.
Transition of BDoc Status:

78
Configuration Guide

2.5.10 Billing Discount Assignment

In this assignment block, you can assign billing discounts, which are defined in SAP Convergent
Invoicing, to CRM products. As a result of this assignment, the billing discounts are transferred to provider
orders and the corresponding contracts. The assignments are replicated to Convergent Invoicing with the
contract. The discounts are then observed during the billing and invoicing steps for this contract in SAP
Convergent Invoicing.
2.5.10.1 Prerequisites
SAP CRM stores a buffer for Convergent Invoicing billing discounts and their descriptions that are
replicated with the Customizing objects. Start an initial load for the object dnl_cust_disco to replicate the
descriptions. Look up the replicated billing discounts and descriptions in Customizing under Customer
relationship Management -> Cross Industry Functions -> Transactions ->Billing Discounts -> Display
Billing Discounts.

Billing Discount Display View

Note: You do not need to replicate billing discounts and their descriptions if you want to use them in
CRM. However, billing discount descriptions might not be displayed correctly if the corresponding entry in
the CRM table is missing.
2.5.10.2 Maintenance of Billing Discount Assignments
Select the billing discounts using the input help in the column Discount Key. The search function is
processed directly in SAP Convergent Invoicing and therefore always provides current results,
independently of the status of the replicated billing discounts in CRM.
Choose Contract Relevance for the selected billing discount.
Choose Mandatory for billing discounts that are added to contracts and cannot be deselected
during order processing.
Choose Optional for billing discounts that are available to be added during order processing.
Choose a condition for the discount assignment.
Choose Always in the column ‘Activate’ to make the assignment unconditional.
Choose Dependent on Characteristic and enter a configuration characteristic and a characteristic
value in columns to make the assignment dependent on a specific configuration value.
Choose Dependent on BRF Event and enter an event to make the assignment dependent on the
result of a Boolean BRF event.
The following combinations are possible and lead to different handling in order processing:

Condition Unconditional
79
Configuration Guide

Contract Relevance or Condition is false

Condition is true
Mandatory The billing discount is added to The billing discount cannot be added
contracts to contracts
Optional The billing discount can be added to the The billing discount cannot be added
contract during order processing to contracts

Billing Discount Assignment in Product Maintenance

Notes:
- A billing discount can only be selected once for each product.
- A condition is true, if
o The selected characteristic has the selected characteristic value
o The selected BRF event returns ‘true’
- A condition can only be dependent on a single characteristic and a single value. Use dependent
characteristics or BRF events to represent more complex dependencies.

2.6 Item Categories and Transaction Types

2.6.1 Overview Item Categories and Transaction Types
SAP delivers the following transaction types, item category groups and item categories as a standard for
the telecommunications solution:

Transaction Types:
PRVC Provider Contract
PRLC Provider Contract Lean
PRVO Provider Order
PRLO Provider Order Lean
PRVR Provider Partner Order
PRLR Provider Partner Order Lean
ISPR E-Commerce Provider Order

Item Category Groups:

PRSV Fee
PRNP Provider Rate not pricing relevant
PRRO Prov. Rate Plan Opt.
PRRP Provider Rate Plan
LUMF Structure below (e.g. Sales Packages)

80
Configuration Guide

NORM Sales Items

Item Categories:
PRCN Prov. Contract Item free
PRCP Provider Contract Item
PRCL Provider Contract Item Lean
PRCO Provider Contract Item Option
PRON Prov. Order Item free
PROP Provider Order Item
PRPL Provider Order Item Lean
PRPO Provider Order Item Option
TAP Standard (for Sales Packages)
TAPL Sales With Scope of Supply at Item Lean
TAL Sales Item Lean

2.6.2 Lean Items in Provider Orders

2.6.2.1 Use
With SAP CRM 7.0 Enhancement Package 3, you can use lean items in provider orders and provider
contracts for the telecommunications industry.
Lean items are items that have reduced functionality, which optimizes system performance:
For lean items, the text determination, partner determination, action profile, and status
profile are switched off.
For extra lean items, the text determination, partner determination, action profile, and
status profile, and, in addition, the pricing relevance is switched off.
Using lean items allows call center agents and dealers to work more efficiently in the order capture
process during customer interaction.
SAP has provided several new objects to support lean items and extra lean items:
Define Item Category Group
A new item category group has been created: PRRO Prov. Rate Plan Opt.
Define Transaction Types
Three new transaction types have been created:
PRLO Provider Order Lean
PRLC Provider Contract Lean
PRLR Provider Partner Order Lean (for the dealer application)
For the transaction types PRLO und PRLP, contracts are created asynchronously. For
more information, see release information Asynchronous Creation of Provider Contracts
Define Item Categories
The following new item categories have been created:
o PRPL Provider Order Item Lean
o PRPO Provider Order Item Extra Lean
o TNL Sales Item Lean

81
Configuration Guide

o TAPL Sales With Scope of Supply at Item Lean

o PRCL Provider Contract Item Lean
o PRCO Provider Contract Item
2.6.2.2 Procedure
To use the lean transaction types, you have to assign the new transaction types to the relevant
application profiles in Customizing under Customer Relationship Management Cross-Industry
Functions Interaction Center WebClient Define Application Profile. For the Interaction Center,
assign transaction type PRLO, and for the dealer application, assign transaction type PRLR.
If you have defined Customizing settings for item categories, you have to define these settings also for
the new item categories in Customizing for Customer Relationship Management under Cross-Industry
Functions Provider Contract Management Transactions Define Settings for Item Categories.
2.6.2.3 See Also
For more information, see SAP Note 1295370. For more information on customizing for the dealer
application, see SAP Note 1320112.

2.6.3 Display of Lean Items

2.6.3.1 Use
As of SAP CRM 7.0, Enhancement Package 3, you can benefit from a more user-friendly user interface in
the provider order in the Interaction Center and Dealer Application for industries using Provider Contract
Management to display lean items.
The user interface has now the following 2 new views in the dealer application and the interaction center:
Pricing View
A list of the prices for a rate plan and its variant conditions is displayed below the order
items tree view on the item tab. This table contains the basic rate plan and the variant
conditions maintained in the configuration. By default, the recurring price column
represents the gross price as in the Order Items table. You can personalize the table to
show also the net recurring price.
Components View
If you have defined lean line items in customizing (see below under Procedure), this table
displays lean items. If you have not defined lean items, the table remains empty. If a start
date is required (for example, if a contractual item contains duration information) for a
component within the component view, by default, the start date is the same as for the
main item. If no start date is required, the start date column is empty and not editable. The
duration is set to the default value as specified in the product master data. Changing the
duration adjusts the respective price in the Pricing table and the price in the Order Items
table.

82
Configuration Guide

Example:

2.6.3.2 Procedure
You make the settings for this function in Customizing under Customer Relationship Management
Cross-Industry Functions Provider Contract Management Transactions Define Lean Items.
Specify all item categories (usually extra lean items) and its transaction types, which should appear as
components in the component view, for instance:

Only items for which the above maintained item categories are found, will be part of the component view.

Lean and extra lean item categories can be used for web orders as well, but no component or price views
exist in the web shop, which means that all items are fully displayed in the standard view and not in a
separate view.

2.6.4 Settings for Item Category Determination Procedure

2.6.4.1 Use
For groups within interlinkages (e.g. group ROUTERS in interlinkage Sales Components of a sales
package), which do not have a default selection (i.e. none of the members of group ROUTER is marked
is default), positions within the order are created, although no product is assigned to this position. For this
reason, special settings have to be done for the item category determination procedure so that also for
this case an item category can be determined.
2.6.4.2 Procedure
...

83
Configuration Guide

In Customizing, choose Customer Relationship Management Transactions Basic Settings Define

Item Category Determination:
1. Create a new entry with and provide the following settings:
Transaction Type (e.g. PRVO for provider order in IC)
Item Category Group: must be kept blank
Main Item Category (e.g. TAP, if the main product is a sales package as mentioned above)
Item Category (e.g. TAN if the item is a router)

2.6.5 Settings for Provider Item Categories

2.6.5.1 Use
For each item category used within provider orders, several settings can be done. For each individual
item category, it can be decided:
1. Whether an item from a provider order is to be distributed with the contract items to an external
system via PI. Order items, which have item categories, which are selected for distribution, are
added to the PI service message automatically.
Please note that contract relevant item categories are automatically distributed. These settings
would apply to provider fees or sales items, for instance.
2. Whether an item is distributed via PI immediately, or whether this does not take place until the
activation date.
3. Whether an item uses the standard payment data or can be paid for using alternative payment
data.

2.6.5.2 Procedure
...

In Customizing, choose Customer Relationship Management Cross Industry Functions Provider

Contract Management Transactions Define Settings for Item Categories.

84
Configuration Guide

2.6.6 Replication of Provider Orders to SAP ECC

2.6.7 Use
SAP CRM Provider Orders can be replicated to SAP ECC. Usually, the replication only takes place for
delivery relevant items, i.e. only for certain item categories. It does normally not make sense to replicate
rate plans, for instance for a ADSL tariff, to SAP ECC, as this item would not need to be fulfilled. Also for
billing, there is not necessarily the need to replicate recurring charges.
Delivery relevant items, for instance cell phones, however, should be replicated so that delivery etc. can
be executed.

2.6.8 Prerequisites
To be able to replicate sales orders, the following objects have to be identical in SAP CRM and SAP
ECC:
1. Business Partners
2. Products and Materials
3. Sales Organizations
4. Number Ranges

In addition to that item categories that shall be replicated must be billing relevant.

2.6.9 Procedure
In order to replicate delivery relevant items of provider orders to SAP ECC, several basic steps are
necessary, which can be found in notes 490932 and 529653. All basic steps (e.g. Middleware settings,
settings for divisions) that have to be executed for standard sales orders are the same for provider orders.
For provider orders, it is necessary to explicitly define which item categories are delivery relevant. You
can make these settings in Customizing under Customer Relationship Management Cross Industry
Functions Provider Contract Management Transactions Define Settings for Item Categories.
Mark all item categories that shall be replicated as type Item Uses Alternative Payment.

Only item categories that use alternative payment are considered as delivery relevant are hence
replicated.

85
Configuration Guide

2.6.10 Bill Period Management in SAP CRM

2.6.10.1 Overview
Bill Period Management (BPM) in SAP CRM is used to determine bill cycles that are dependent on the
SAP CRM product sold. BPM informs the customer about the bill period of their contract before it is
submitted for replication to SAP Convergent Invoicing and SAP Convergent Charging.
To make this possible, SAP CI replicates the list of available bill cycles to SAP CRM. This list contains
basic information about the bill cycles only, such as the bill cycle key and the bill cycle description. Whilst
the bill cycle key is exchanged during contract replication, the bill cycle description is the only criterion
used to select bill cycles in SAP CRM since bill cycle details, such as periodicity and start date, are not
known to SAP CRM.
SAP CRM product maintenance captures bill cycles or determination rules for bill cycles with a product.
The product setting is evaluated during order creation and the bill cycle is stored with the contract.
During contract replication, the bill cycle is sent to SAP CI to trigger the processing of the correct bill
period.
2.6.10.2 Customizing
2.6.10.2.1 Bill Cycles
Replication
The list of bill cycles is replicated from SAP CI (table TFK2607) to the SAP CRM table
CRMC_ISX_CYCLE. You must trigger the replication manually to a complete initial load. It is designed for
delta loads.
You can start an initial load of bill cycles in transaction R3AS. The load object is DNL_CUST_BCYCLE.
Start Initial Load, transaction R3AS:

Monitor the replication process in transaction R3AM1 by selecting the load object DNL_CUST_BCYCLE.

86
Configuration Guide

Monitor objects, transaction R3AM1:

Successful replication in load object monitor, transaction R3AM1:

Display Bill Cycles

You can check the result of the replication in Customizing under Customer Relationship Management->
Cross-Industry Functions -> Provider Contract Management -> Transactions -> Billing Cycle -> Display
Billing Cycle.
You cannot change the bill cycle list in SAP CRM.

87
Configuration Guide

List of Bill Cycles:

Bill Cycle Details

The list of bill cycles in SAP CRM contains the following fields that are transferred from the SAP ERP
table:
Cycle - bill cycle key that is replicated to SAP CI with a contract
Description - description of the bill cycle that is shown during maintenance of bill cycles in product
maintenance, determining rule maintenance and order capturing.
Frequency - billing frequency. Possible values, including monthly, bi-monthly, weekly or annually.
This is for reference purposes only, the field is used in SAP CRM.
Usable to - expiry date. The system does not assign this bill cycle to contracts after this date.
Day - start of the billing period. This can be a weekday for weekly periods or a day of the month.
The day is defined for reference purposes only.The field is not used in SAP CRM.
Month - start of the billing period for bill cycles that have longer periods than a month. The month
is set for reference only. The field is not used in SAP CRM.
2.6.10.2.2 Determination Rules
The definition of bill cycle determination rules has three main purposes:
1. You can define a default rule that applies to all products that require a bill cycle, but do not have
one specified.
2. You can assign a determination rule to a group of products and change the bill cycle without
maintaining the products.
3. You can apply complex rules instead of simple assignments to the determination by implementing
a determination logic.
88
Configuration Guide

You can make these settings in Customizing under Customer Relationship Management -> Cross-
Industry Functions -> Provider Contract Management -> Transactions -> Billing Cycle -> Define Billing
Cycle Determination Rules.

Bill Cycle Determination Rules Maintenance

2.6.10.2.3 Maintaining a Determination Rule

There are two general kinds of determination rules
Rules that assign a single bill cycle:
Enter an ID, a description and a bill cycle. When you assign a rule to a product, you can maintain
it centrally..
Rules that assign a billing cycle determination class:
An implementation class using the interface IF_CRM_ISX_CYCLE_DETERMINATN is required.
Enter an ID and description for the rule and select your implementation class using the F4 Help in
the column Billing Cycle Determination Class. The F4 Help returns classes that implement the
required interface.

2.6.10.2.4 Billing Cycle Determination Class.

Implement the method GET_CYCLE_LIST for the interface IF_CRM_ISX_CYCLE_DETERMINATN in a
new implementation class to dynamically determine a bill cycle.
The method interface incorporates following fields:
IV_RULE_ID:
Use this ID if you want to use the same implementation in several determination rules.
IV_ITEM_GUID:
Use this GUID to read the appropriate information, for example product or appointments,
if the available billing cycles depend on an order attribute.
ET_CYCLES:
Add the determined billing cycle to this table. You can return several bill cycles, but the system
the one that you have selected as a default in the first one from the list.
ET_MESSAGES: Add error or warning messages if problems occur.

89
Configuration Guide

For more details, see the example implementation CL_CRM_ISX_BC_DETERM_EXAMPLE.

2.6.10.2.5 Default Determination Rule
You can define one of the determination rules as the default rule. The default rule is evaluated when no
bill cycle settings have been maintained for a product, that requires a bill cycle. You can only define one
entry as a default.
2.6.10.3 Product Maintenance
Bill cycles or bill cycle rules are maintained in the assignment block Payment and Billing Settings.
Assign the set type CRM_ISX_PAYMNT to the corresponding product category to make the assignment
block available.
Enter either a bill cycle determination rule or a single bill cycle
2.6.10.4 Bill Cycle in Contracts
During order capturing, a bill cycle is determined, stored with the contract and replicated to SAP CI. This
happens at order item level. Only main items have their own bill cycle. Sub items inherit the bill cycle from
their corresponding main item, but the bill cycle is not stored in sub-items.
If a contract change process is executed, the bill cycle is copied from the contract into the change order
and is not determined again.
2.6.10.5 Determination triggers
During order capturing, the bill cycle determination is carried out twice:
Directly after entering a product
Before the order is releassed

This is done because the bill cycle determined may change due to attribute changes in the order (if a
determination rule with a bill cycle determination class implementation is used).
2.6.10.6 Determination Logic
In SAP CRM, the system searches for a bill cycle determination method using a certain pattern. Once a
determination method (or a fixed bill cycle) is found, the system does not continue to search, even if the
determination method did not return a bill cycle or the bill cycle found is no longer valid (usable to field).
The following search patterns are available for the determination logic:
1. Bill cycle determination rule for the product. The rule is evaluated in the following order:
Implementation class
Bill cycle
2. Fixed bill cycle on the product
3. Default bill cycle determination rule in Customizing. The rule is evaluated in the following order:
Implementation class
Bill cycle

The default determination rule is only used if data is not maintained for the product.

2.6.10.7 Bill Cycle Storage

The bill cycle is stored in the Telco extension table CRMD_IST_ITA3, field CYCLE.
2.6.10.8 Bill Cycle in Contract Processes
The general objective in the shipped processes is to keep the bill cycle stable. One reason for this is that
bill cycle changes are not allowed during the middle of the bill period. Therefore the bill cycle is
transferred when contracts are copied to change orders and vice versa - or if no process implements a
redetermination of the bill cycle.
90
Configuration Guide

2.7 Pricing
2.7.1 Document Pricing Procedures for Provider Order
SAP CRM 7.0 Enhancement Package 3 is shipped without any document pricing procedure specific for
all provider transaction types. For pricing procedure determination, “blank” document pricing procedure
has to be maintained.
If several transaction types are required and conflicts within pricing procedure determination arise, a new
document pricing procedure should be created for all provider transaction types and assigned
accordingly.
2.7.1.1 Procedure
1. Define a new document pricing procedure for provider transactions. In Customizing, choose
Customer Relationship Management Basic Functions Pricing Pricing in the Business
Transaction and execute Define Document Pricing Procedures.
2. Assign the newly created document pricing procedure to all relevant transaction types. In
Customizing, choose Customer Relationship Management Basic Functions Pricing Pricing
in the Business Transaction and execute Assign Document Pricing Procedure to Transaction.
3. Adapt determination for pricing procedures. In Customizing, choose Customer Relationship
Management Basic Functions Pricing Pricing in the Business Transaction and execute
Determine Pricing Procedures.

2.7.2 Condition Group for Price Maintenance

In order to maintain prices in the product master in SAP CRM 7.0 Enhancement Package 3, a condition
group has to be defined and maintained. In standard, condition group PRODUCTCRM is shipped. For
most telecommunication specific condition types, it is however better to use condition group
PROD_PROV, which automatically contains all relevant conditions types.
2.7.2.1 Procedure
In order to assign condition group PROD_PROV for price maintenance in product master, in Customizing,
choose Customer Relationship Management Master Data Products Special Settings for Sales
Operations and execute Assign Condition Group to Application CRM.

2.7.3 Pricing Procedures and Condition Types

Per Default, two different pricing procedures with its according condition types are available with CRM 7.0
Enhancement Package 3.

91
Configuration Guide

2.7.3.1 Pricing Procedure for net price: 0PROV1

This pricing procedure contains standard condition types for onetime fee and recurrent charges. The
following standard condition types for the pricing procedure 0PROV1 are available:
0PRT: One time fee (ex: devices)
Access sequence 0PPA: price by hardware or by hardware and parent product (e.g. package)
0PMR: Recurrent fee
Access sequence 0PPA: price by rate plan or by rate plan and parent product (e.g. combined
rate plan and package)
0PMP: Recurrent fee
Access sequence 0PDU: allow to have price by rate plan and contract duration or package/rate
plan and contract duration
1200: campaign specific price
1201: campaign specific discount exist also as standard condition type, can be easily added to the PP
0PSV: service price. It is used to define activation fee or cancellation fee
Access sequence 0PSV: by package or independently
0PLC : Lock / Unlock
Access sequence (0PLO): by product and lock reason
2.7.3.2 Pricing Procedure for gross price: 0PROV2
This pricing procedure contains standard condition types for onetime fee and recurrent charges. The
following standard condition types for the pricing procedure 0PROV2 are available:
0PR1 : One time fee gross (ex: devices)
Access sequence 0PPA: price by hardware or by hardware and parent product (e.g. package)
0PM1: recurrent fee gross
Access sequence 0PPA: price by rate plan or by rate plan and parent product (e.g. combined
rate plan and package)
Access sequence delivered in standard (0PPT): by product and pricing process.
It is used in change order processes
It is not presently linked to a standard condition type
Delivered to speed up pricing customizing in projects
The pricing process is determined using the BRF (Business Rules Framework)
Example:
The change event extension leads to the pricing process 0001, whilst the combination of change events
extension and product change leads to pricing process 0002. For further information, have a look at
chapter Process-Dependent Pricing.
Note:
For all telecommunications-specific pricing procedures, i.e. for 0PROV1 and 0PROV2, the standard rule
for competing prices applies:
If more than one price in a pricing procedure is valid (as described in the above mentioned example), the
last active and not statistical price is taken. All other prices become inactive. This applies to all condition
types, which condition class is B (Price).

92
Configuration Guide

If we have a look at 0PROV1 for instance, and assume that prices have been found for condition types
0PRT and 0PMP, only 0PMP will become active as it is the last active price in the procedure!

2.7.4 Further requirements for condition types

For the telecommunications industry, there are 2 more specialties to meet all requirements, namely prices
in accordance with packages (parent-parent products) and with other items in the order.
2.7.4.1 Pricing with reference to parent-parent product
If you use condition type 0PRT for instance, you can assign a price to a product dependent on its parent
product. However, in a sales package, it is also possible that a rate plan is integrated into a combined
rate plan which is part of the package. If you want to have a price for the rate plan dependent on the
package, you will have to assign a parent-parent price, which is not supported by 0PRT.
2.7.4.2 Pricing with reference to specific order items
A further necessity with regard to packages is to depend the price of a sales package component on
another item in the order. If you order a sales package which consists of a wireless rate plan and cell
phone, the cell phone can be sold at a lower price when you order a router at the same time.
To enable this, you have to add the cell phone twice as a sales package component, however defining a
different price level for both of them. This price level will be used as a reference when defining the price in
the product master data.

Note that for both specialties no condition types or access sequences are shipped.
Condition types, access sequences and condition tables have to be built on you own, as well as the
integration of the condition types into the according pricing procedure.
2.7.4.3 Procedure
As for both above mentioned specialties no condition types exist, they have to be built. For doing so, a
condition table, access sequence and a condition type have to be built. Taking pricing with reference to
order items as an example, you have to proceed as follows:
4. The first step is to create a new condition table. In Customizing, choose Customer Relationship
Management Basic Functions Pricing Define Settings for Pricing and execute Create
Condition Tables
b. Enter a name for the condition table, e.g. CUS8000 so that the condition table is created
c. Highlight all fields you would like to use for the condition table and use the arrows to bring
them over to the condition table

93
Configuration Guide

d. As configuration fields, you could add the following ones to realize the example
i. SALES_ORG
ii. DIS_CHANNEL
iii. PROV_PRICE_LEVEL
iv. Product

For pricing with reference to order items, field PROV_PRICE_LEVEL is shipped and for pricing with
regard to parent-parent products, use field PAR_PAR_PRC_LEVEL.

e. The last step is to activate the condition table

2. The next step is to create an access sequence which uses the previously created condition table. In
Customizing, choose Customer Relationship Management Basic Functions Pricing Define
Settings for Pricing and execute Create Access Sequences
a. Create a new entry and provide the following information:
i. Access Sequence ID, for instance ZPRL
ii. Description

b. Highlight the created access sequence and click on ACCESSES. Here, you can now add
the previously created condition table. You could provide the following information:
94
Configuration Guide

i. ID for the access, for instance 10

ii. Table (the previously created condition table
iii. Indicate Exclusive Condition Access (Controls that no further record is searched for
after the first access from a record to a condition type in an access sequence has been
successful)

c. Save your settings

3. The last step is to create a new condition type and add the access sequence you just created, to it.
The easiest way of doing so would be to copy an existing condition type, for instance OPRT, and
replace the access sequence by the one you created before. Do not forget to integrate the condition
type into your pricing procedure.

2.7.5 Process-dependent Pricing

2.7.5.1 Use
Process-dependent prices can be used to calculate prices in connection with change processes when
making contract changes in provider orders, using the events of the Business Rules Framework (BRF).
The use of the BRF makes it possible to merge multiple events (such as product change and contract
extension) and transfer them as the single-value attribute "pricing process" to pricing.
2.7.5.2 Procedure
You define pricing processes that will have an effect on pricing and use these pricing processes in your
condition tables. The field IST_PROCESS - Process is contained in the pricing field catalog for this
purpose, which you can include in your own condition tables.
You define a BRF event by implementing the check of the pricing processes.
In the truth table of the BRF event you determine that, when the event (cancellation, for example) is
carried out, the previously defined pricing process is found. For this purpose, you enter the pricing
process in the truth table field Result.
Settings for the BRF event could look as follows (example):

95
Configuration Guide

SAP delivers the event 0PRC_01, which you can use as a reference for your own BRF events. The
delivered event contains the events cancellation, extension and product change.

Example
You can operate the standard event 0PRC_01 as follows:
A contract extension should have an effect on the price of product "A":
1. You define the pricing process "Extension"
2. You create a condition table with the field Pricing Process.
3. You use this condition table as part of the maintenance of product "A" and the maintenance of the
corresponding condition.
4. You define a BRF event for the pricing process. Maintain the rule (in the form of the truth table)
accordingly within the BRF event. This means that when an extension has taken place (when the
event for the extension is carried out), the previously defined pricing process is found in all cases,
no matter which other processes are being carried out in parallel.
Result

The provider order automatically includes the BRF event for the pricing process.
2.7.5.3 See also
Find more information in Customizing under Customer Relationship Management Transactions
Settings for Provider Contracts Define Pricing Processes for Provider Orders

96
Configuration Guide

2.7.6 Billing Plan

2.7.6.1 Use
The billing plan enables you to bill for a product or service, independently of a delivery. You can either bill
the same amount at regular intervals (periodic billing plan) or bill different amounts at specified dates that
have been pre-defined (milestone billing plan).
The billing plan is a detailed billing schedule that can either be valid for all the items in the business
transaction, or for each item in the business transaction.
For the provider order, a special billing plan is provided which supports the necessities of the
telecommunications industry, for instance monthly, recurrent billing. For the provider order, the billing
schedule is valid for all items in the business transaction.
The billing plan for the provider order offers basic functionalities. However, this standard might not be
sufficient for all customers. An example would be a different billing date: per default, the billing plan for
the provider order is set up in the way that the billing date is always the first of each month.
Yet, for some customers, this might not be the right date. Therefore, a change of the billing plan provided
by the standard will be needed.
2.7.6.2 Procedure
To create a new billing plan (type), the standard one (53 – Provider Billing Plan) will be copied and
modified. In order to do so, execute the following steps:
1. In Customizing, choose Customer Relationship Management Transactions Basic Settings
Billing and execute Define Billing Types
a. Highlight billing plan type 53 (Provider Rate Plan), which is shipped by standard.
b. Copy this billing plan type, which is used for recurrent prices, for instance to 99 (Test
Provider Rate Plan).
c. Under Plan Lines, you can change the Billing Date in accordance with customers’
requirements, for instance to “15th Day of Month”.

Always ensure that no bill request items are created so that no positions are generated.

97
Configuration Guide

2. After the new billing plan type has been created, it must be assigned to the item categories of the
provider order via Customizing. You can make these settings in Customizing under Customer
Relationship Management Transactions Basic Settings Billing Plan and execute Assign
Billing Plan Type to Item Category
Navigate to all relevant Item Categories, for which you would like to use the newly created billing
plan (billing plan type). Most likely, it will be done for PRCP and PROP. Here, enter the Billing Plan
Type ID of the previously created Billing Plan Type, for instance 99.

Ensure here that the indicator for “Billing Plan at Item Level Only” is not set. Thus, a billing plan is
only created for the header billing plan. The billing plan becomes valid for all items of one order.

2.7.7 Define Price Dependencies

If you want to define surcharges or discounts for combined products, you can define dependencies
between the product combination and price. If you want to define a different price for each rate for the
“Cell with Rate x” combination, or want to define special prices for products for the combination of change
processes (Contract and Order Management business scenario), you can define prices for
telecommunications products according to the following attributes:
Sales component
Rate plan product
Contract runtime
Product scoring value
Change processes
2.7.7.1 Customizing
In Customizing, choose Customer Relationship Management Basic Functions Pricing Define
Settings for Pricing Create Condition Types.
In Customizing, choose Customer Relationship Management Transactions Settings for Provider
Contracts Define Pricing Processes for Provider Orders.

2.7.8 Condition Exclusion

2.7.8.1 Use
If several condition records are valid for pricing in the document item, you can define rules that determine
which condition records are selected and which are not taken into consideration. To do this, we use
condition exclusion.
Imagine the following example: for a DSL rate plan, 2 different prices have been maintained:
OPMR: 10,00€ if you buy it in a package
OMPM: 15,00€ for a contract duration of 2 years
If you order this DSL product in a package with a contract duration of 2 years, 2 prices would be valid at
the same time. To define that the lowest price is taken is realized by means of condition exclusion.

98
Configuration Guide

2.7.8.2 Procedure
The first step to enable condition exclusions is to define condition exclusion groups. An exclusion group is
a list of condition types that are compared to each other in pricing and can be used to exclude a whole
group or individual condition types in a group. Once this is done, the behavior of this group must be
defined
1. In Customizing, choose Customer Relationship Management Basic Functions Pricing
Define Settings for Pricing and execute Create Condition Exclusion.
a. Choose Condition Exclusion Groups: Condition Types
b. Create a new condition exclusion group. Create a new entry and enter a name, e.g.
ZPRO, and a description.

c. Under Condition Types, add all condition types that shall be integrated into the condition
exclusion group, e.g. 0PMP and 0PMR.

2. In Customizing, choose Customer Relationship Management Basic Functions Pricing

Define Settings for Pricing and execute Create Condition Exclusion.
a. Choose Condition Exclusion: Procedure Assignment
b. Highlight the pricing procedure for which you would like to enable condition exclusions,
usually 0PROV1.
c. Define the condition exclusion. For doing so, you have to enter the following information:
• Sequence number
• Condition Exclusion Procedure (in this example: best condition between condition
types)
• Condition Exclusion Group (ZPRO – the one you previously created).

Generally speaking, the procedure for selecting in a condition exclusion group or

between groups is defined in the pricing procedure. You have the following options:
• Selecting the best condition type in a condition exclusion group
• Selecting the most suitable (or unsuitable) condition record for a condition type, if
there are several valid condition records (for example, several condition records of
condition type PR00)

99
Configuration Guide

• Selecting the most suitable (or unsuitable) of two condition exclusion groups (in this
case, all condition types of both groups are cumulated and the two totals are
compared)
• Exclusive procedure: If a condition type from the first group is available in the
document, all condition types that are contained in the second group are set to
inactive.

2.7.9 “0,00” Prices

2.7.9.1 Use
All pricing procedures handle a 0,00 price as a price that is not maintained. This might cause some error.
Imagine the following scenario:
For DSL rate plans (dsl_1000, dsl_6000), an activation fee is maintained. This activation fee is 10,00 for
dsl_1000, and 0,00 for dsl_6000. However, for all other products it is 12,00. If no condition exclusion is
configured here, the activation fee for dsl_6000 is set to 12,00 as the pricing procedure cannot determine
that a special price is maintained for dsl_6000, namely 0,00. To avoid this problem and ensure that the
pricing procedure works correctly, proceed as described in procedure.
2.7.9.2 Procedure
In Customizing, choose Customer Relationship Management Basic Functions Pricing Define
Settings for Pricing and execute Create Pricing Procedure.
Here choose the relevant pricing procedure and choose control data. For each condition type, you would
like to enable a 0,00 price (condition exclusion), maintain calculation formula 38 (Exclusion with Zero
Values).

2.7.9.3 “0,00” on main item level prices when using options with prices
For situations where the basic rate plan does not have a recurring price, but customers can sign up for
additional options that have a price assigned, a special set up is needed if you want to model this in the
context of lean items. (link to 2.6.2)

Example:
Prepaid basic plan 0.00 EUR
Option “100 free min” 9.90 EUR
Option “20 free sms” 3.90 EUR
----------------------------------------------------
Sum 13.80 EUR

Standard behavior in pricing is, that prices with value 0,00 are counted as “inactive”. This block the
processing of the surcharge prices of the options.

100
Configuration Guide

To achieve the behavior described in the example above, you need to set up the pricing procedure
accordingly:
Maintain a condition with value 0 EUR as basic price
Additionally add a statistic condition of type price. For this condition type you need to maintain a
price greater 0.00 EUR
Use a normal discount/surcharge condition for modeling the option prices

2.7.10 Variant Conditions

2.7.10.1 Use
Variant conditions are pricing conditions that depend on characteristic values. You enable pricing for a
configurable product during the configuration process. You use variant condition keys to create relations
between characteristic values and the price of the configurable product.
An example for a variant condition would be a configurable DSL product. Depending on the speed of the
line, the price for the monthly fee of the rate plan would change. I.e. if you choose 1MBIT speed the
monthly fee is 10,00USD, whereas the fee for 6MBIT is 16,00USD.
2.7.10.2 Procedure
1. Create or adopt condition type for variant conditions
With CRM 7.0 Enhancement Package 2 for Telecommunications, a standard condition type for variant
conditions is shipped, namely 0VA0. This condition type, however, can only be used in connection with
non-recurrent prices.
If you want to use variant conditions also for configurable products with recurrent prices, an according
condition type should be created.
The creation of this condition type is a precondition for the use of variant conditions. This condition type
can be created as follows:
a. As a standard condition type for variant conditions is shipped with CRM 7.0
Enhancement Package 2, namely 0VA0, it is recommendable to copy this condition type
and change it in that way that it can be used for recurrent prices as well. In Customizing,
choose Customer Relationship Management Basic Functions Pricing Define
Settings for Pricing Create Condition Types
Here, highlight condition type 0VA0 and copy it, for instance to 0ZVA.
b. When the condition type is copied, change condition class to B (Prices), sign to A
(Positive) and Condition type to M,N,O or P depending on the time period for the
recurrent price. In this example it is set to M (monthly price).

101
Configuration Guide

c.After the creation of the new condition type, it must be integrated in the pricing procedure,
access sequence and so on.
2. Create variant condition keys (PME)
a. In the PME choose entry Add characteristic from the context menu of the product for
which you want to define a variant condition key.
b. Choose the characteristic VARCOND.
c. Maintain the characteristic values for the variant condition key. It is important to assign
‘VARIANT_CONDITION’ as Reference

3. Reference to variant condition keys in your model

To use the created variant condition keys in your model, they must be referenced to the according
values of the characteristic. This can be done in two different ways:
Use Modeling Example
One-to-one Use the 1:1 The characteristic value Color: Red includes a
assignment to a variant condition surcharge for the product, which is represented
characteristic key assignment by the variant condition key ColorRed.
value in the Select the key ColorRed for the characteristic
characteristic
102
Configuration Guide

maintenance of value red in the characteristic maintenance

the relevant area.
characteristic.
Use in Use the variant The characteristic value Color: Blue in
dependencies condition key in combination with the characteristic value
(setting a key formula Finishing: Metallic includes a surcharge for a
depending on dependencies. product, which is represented by the variant
several condition key BlueMetallic.
characteristic Maintain the formula:
values)
Formula:
VARIANT_CONDITION_KEY='BLUEMETALLIC'
Condition:
COLOR='BLUE' and FINISHING='METALLIC'

a. The first possibility for referencing the characteristic values to the variant condition key is
the one-to-one assignment. Example:

In this example, characteristic value 6MBIT is directly referenced to the variant condition
key.

b. The second possibility for referencing the characteristic values to the variant condition
key is the use of dependencies in the product model. These dependencies have to be
defined for every value of the characteristic on class level in the following way:
Create a Dependency of type Formula
Define its formula, for instance:

In this example, the variant condition key will have value 6MBIT, when characteristic
DSL_SPEED has the value 6MBIT.

103
Configuration Guide

4. Create variant condition records (product maintenance)

a. In Master Data, edit the product for which you defined variant condition keys.
b. Navigate to ‘Show Prices’.
c. Enter the necessary data (condition type 0VA0 or the 0ZVA (variant price), sales
organization, distribution channel, value for the variant condition key maintained in the
product modeling environment, amount, currency, price unit, unit of measure).

2.7.11 Activation Date in Pricing

2.7.11.1 Purpose
Per default, the activation date of a product/service is not taken into account by pricing.
If a Telco company, for instance, is offering a rate plan at a special price for only a period of time, the
activation date would not be considered. Thus, a customer would get this special price, even if the
activation date is outside of this special period.
2.7.11.2 Procedure
It is possible to define on condition type level, which date should be taken into account when determining
the right price. For this purpose, in Customizing, choose Customer Relationship Management Basic
Functions Pricing Define Settings for Pricing and execute Create Condition Types.
Here, chose the relevant condition type and maintain the ‘Access Date’:

104
Configuration Guide

2.8 Prepaid Account

2.8.1 Use
When a prepaid product in a sales order is selected, a business agreement of the type prepaid is
requested by the system (a product is assigned the type prepaid as a result of the assignment of a
prepaid payment group in the payment settings). This type of business agreement has a special
appendix, the prepaid account.
In the current standard solution, it is assumed that every prepaid account is assigned to a single business
agreement of the prepaid type.
A prepaid business agreement of the type prepaid should be assigned to one prepaid contract only, but
can be re-used for contracts with postpaid product(s). The system ignores the prepaid data here and only
uses the data in the business agreement. A business agreement of the type prepaid can be reused
several times for postpaid products (such as a postpaid business agreement).
Prepaid accounts are created in SAP CRM with the business agreement and replicated (using the
middleware) to the SAP ERP System.
The prepaid account defines some information for prepaid usage:
Prepaid Schema
Part of the prepaid account is a reference to a prepaid schema. This reference is used to
determine certain default values and define value checks. For some views, the prepaid schema is
part of the UI configuration determination
Currency
Minimum Balance
Determine the minimum existing balance to consume services (such as telephone calls).
Payment Data
The payment data is used to charge the refill amount. You can reference a bank ID or a credit
card here. If no alternative payer is specified, the payment data refers to the sold-to-party
determined in the corresponding business agreement.
Notifications Limits
Possible amounts for limits are defined according to the prepaid schema selected.

105
Configuration Guide

Users are able to top up their credit either on an individual basis, or automatically based on an agreement
with the service provider. Automatic refills take place on previously scheduled dates or when the credit of
the prepaid account falls below an agreed limit.
The parameters that control an automatic or periodical refill (for example trigger amount of automatic refill,
period for periodical refill) are part of the refill plan. The refill plan also contains a parameter that defines
the refill type (manual or automatic). If the type is automatic, payment data (bank or credit card) has to be
provided in the prepaid account. You also have the option of changing the payment data (from the
business agreement detail view).
If an alternative payer is specified, the payment data refers to the alternative payer.

2.8.2 Prerequisites
2.8.2.1 Number Range
Number range object for SAP CRM : BUAG_PPACC
Example: Range 01: 000000000001 - 999999999999 for the internal number range
Range 02: A - ZZZZZZZZZZZZ for the external number range
The number range object for SAP ERP: FKK_PPACC
The intervals for the number ranges for replicated prepaid accounts in SAP ERP and in SAP CRM need
to match. Whereas a replication from SAP ERP to SAP CRM requires an internal number range 01 in
SAP ERP but an external number range in SAP CRM. The replication from SAP CRM to SAP ERP is the
reverse of this: It uses an internal number range in SAP CRM and an external number range 02 in SAP
ERP.

If a single number range for prepaid account creation in SAP CRM is not sufficient and you want to
differentiate prepaid account IDs, for example according to the prepaid schema, you can create additional
internal number ranges and assign them to the according prepaid schema in Customizing under
Customer Relationship Management -> Master Data- > Prepaid Account -> Define Prepaid Schema (see
also next chapter).
Nevertheless, for the replication to SAP ERP, the numbers of the internal number ranges all need to
match the external number range in the SAP ERP System.
2.8.2.2 Prepaid Schema
The prepaid account contains a reference link to the prepaid schema. The prepaid schema defines:
Currency
Minimum balance
Up to 3 limits for notification alerts
Rules: Rules can be provided to define the allowed values for the minimum balance field and the
limit fields
Defaults: Default amounts can be defined, which are entered in the prepaid account automatically
as defaults, when the Notify by default flag is set.
Number ranges to be used when creating a prepaid account within SAP CRM (internal number
range) as well as when prepaid account is been replicated to SAP CRM from SAP ERP (external
number range)
The prepaid schema is defined in Customizing under Customer Relationship Management -> Master
Data- > Prepaid Account -> Define Prepaid Schema.

106
Configuration Guide

2.8.3 UI Configuration
2.8.3.1 View Configuration According to Prepaid Schema
You can define additional configurations according to the prepaid schema for the following views:
PROV_BUAG/Prepaid
PROV_BUAG/BuAgInOrderVS

2.8.4 Integration with SAP ERP

The replication of the prepaid account from SAP CRM to the SAP ERP is performed using the
middleware. The prepaid account is added to the BDOC structure of the business agreement. The
additional inbound adapter FKK_COM_PREPACC_MWX_INBOUND is found in the SAP ERP System.
There is no replication from SAP ERP to SAP CRM.
107
Configuration Guide

You can make the entry for the inbound adapter FKK_COM_PREPACC_MWX_INBOUND in Customizing
in table COM_BUPA_CALL_FU. This entry is part of the standard delivery.

During the initial load (for example during a master data migration), the information in the prepaid account
is combined with the according business agreement. This means that both the business agreement and
the actual prepaid account are created in a single BDOC..
The initial load can be started in Customizing under Architecture and Technology -> Middleware -> Data
Exchange -> Initial Load.

When using Sales and Order Management in the call center, you have to ensure that the relationship
between the corresponding business agreement and the prepaid account is always 1:1. It is technically
possible to create more than one prepaid account for one business agreement in the SAP ERP System.
During the integration with Provider Sales and Order Management, such a 1: n relationship of the
business agreement to the prepaid account is not supported.

2.8.5 Integration with SAP CC

2.8.5.1 Limit Alerts
When the prepaid balance reaches one of the given limits, SAP CC contacts the SAP CRM System
(function module CRM_ISX_PPACC_ALERT_HANDLER). Within this function module, the BAdI
CRM_ISX_PRP_NOTIFICATION_MSG is used to enrich the data and send the prepared message to a
message service (SMS, Mail, …).Expiration Handling
Provisional Close Date
This date defines the point at which date a prepaid account becomes inactive in SAP CC, if no
activation takes place. Every action in SAP CC (activation, usage …) modifies this provisional
close date. If the deactivation becomes effective in SAP CC, SAP CRM is called to close the
prepaid account (close date is set). The date is set using the BadI
CRM_ISX_PREPAID_CLOSEDATE_CRE.
The date is changed by several events in CC (usage, refills etc.) The “real” expiration date/close
date – changed in SAP CC for each event is not distributed back to SAP CRM
108
Configuration Guide

Close Date (closed since)

When a close date is entered, you cannot make any other changes to the prepaid account.
Exceptions are the fields ALTERNATIVE_PAYER and PAYMENT_BY. These two fields must be
editable because there must be a balance greater than zero.

To close the prepaid account in SAP CRM, SAP CC calls function module
CRM_ISX_PPACC_ALERT_HANDLER to change the data in SAP CRM. Therefore, the RFC user
involved needs the authorization to change a business agreement:
Authorization object : CRM_BA_CLS,
activity : 02
BUAG_CLASS : <BUAG_CLASS> to which the prepaid account belongs

2.8.6 Archiving
Since the prepaid account is an appendix to the business agreement (which is part of the business
partner in SAP CRM), the archiving of the prepaid account is integrated in the archiving of the business
partner.

2.8.7 BAdIs
The enhancement spot CRM_ISX_PREPAID_ENH_SPOT includes four BAdIs:
CRM_ISX_PREPAID_CHECK
The BAdI CRM_ISX_PREPAID_CHECK can be used to perform additional checks on the prepaid
data. The BAdI is called before the prepaid data is written to the database. To implement the
BAdI, the interface IF_CRM_ISX_PREPAID_CHECK has to be used (method
CHECK_PREPAID).
CRM_ISX_PREPAID_CLOSEDATE_CRE
The BAdI CRM_ISX_PREPAID_CLOSEDATE_CRE is used to set the provisional close date for
SAP CC. This date is also used in SAP CC.
CRM_ISX_PREPAID_SCHEMA_GET
The BAdI CRM_ISX_PREPAID_SCHEMA_GET is used to determine a prepaid schema for new
prepaid accounts being replicated to SAP CRM in the default implementation
CRM_ISX_PREPAID_DEFAULT
The prepaid schema is determined, based on the currency of the replicated business agreement.
The first prepaid schema found with the corresponding currency is used for the prepaid account
creation during the replication.

2.8.8 Prepaid Data in Business Agreement

2.8.8.1 Description
This table parameter contains the prepaid account information for the business agreement. This only
needs to be maintained if you want the business agreement to contain prepaid data.
For information about individual parameter fields, see the corresponding data element documentation in
the ABAP Dictionary.

Parameter Fields:

PPACC_GUID
PPACC_ID
PREPAID_SCHEMA
CURRENCY
CURRENCY_ISO
MAX_BALANCE
MIN_BALANCE
109
Configuration Guide

MAX_AMOUNT
MIN_AMOUNT
TOPUP_MODE
TOPUP_LIMIT
TOPUP_AMOUNT
PER_TP_INT_LEN
PER_TP_INT_TYPE
PER_TP_STRTDATE
PER_TP_AMOUNT
PER_TP_TRGT_BAL
PAYER_ALTERNAT
PAYMENT_BY
BDID_IN
CCARD_IN
NOTIF_RECIP_LST1
NOTIF_RECIP_LST2
NOTIF_LIMIT1
NOTIF_RECIP_SEL1
NOTIF_LIMIT2
NOTIF_RECIP_SEL2
NOTIF_LIMIT3
NOTIF_RECIP_SEL3
NOTIF_RECIP_SELT
NOTIF_RECIP_SELA
Use this table parameter if you want to change prepaid data in the business agreement.
For more information, see the documentation for parameter TPPACCDATA for the BAPI Create Business
Agreement (BAPI_BUPA_FRG0130_CREATE).
See also the documentation for parameter of TPPACCDATAX for the BAPI Change Business Agreement
(BAPI_BUPA_FRG0130_CHANGE).

2.8.9 Change Indicator: Prepaid Data in Business Agreement

2.8.9.1 Description
For every field in the prepaid data structure, there is a corresponding field in this structure with the same
name.
If you select a field in the change bar, the system uses the relevant value from the transfer structure of
the prepaid data. If you do not select a field, the system does not use any data from the transfer structure.

2.9 Service Data Distribution to SAP RM-CA

2.9.1.1 Use
Distribution of - for example telecommunications-specific - service data (such as telephone numbers) from
SAP CRM to SAP RM-CA requires you to activate SAP CRM integration in SAP RM-CA, and define a
separate dunning activity for processing automatic locks.
2.9.1.2 Procedure
...

1. Check and select the CRM Integration indicator in SAP RM-CA in the Customizing settings for the
SAP Telecommunications industry-specific component in the activity Activate/Deactivate Service
Data Distribution in RM-CA. You must select the indicator if you require automatic distribution of
service data to SAP RM-CA.

110
Configuration Guide

2. Define a dunning activity for automatic locks in the Customizing settings for Contract Accounts
Receivable and Payable under Financial Accounting (New) -> Contract Accounts Receivable and
Payable -> Business Transactions -> Dunning -> Configure Dunning Activities. Incorporate the
function module IST_DUNNING_BLOCK_DEVICE_0350 to execute the dunning activity.
In SAP ECC, choose Activate/Deactivate Service Data Distribution in RM-CA (IMG Object
IST_BS_TELDISTRIBUT).
In this Customizing activity, you can define whether data distribution for telecommunication services in
SAP RM-CA or management of services in SAP CRM is to be used.
2.9.1.3 Service Data Distribution in SAP RM-CA (Indicator Service Management)
During data distribution, for example for Telecommunication services, in SAP RM-CA, the table
IST_TDATA is used to manage service data, which must be populated by an external billing system. The
system creates a reference to the service to which the open item belongs in open items for the business
partner in the (DFKKOP table). The reference in the business partner item consists of entries from the
following three fields in the DFKKOP table:
Service type (SERVICE)
Additional reference object (ADD_REFOBJ)
Reference object ID (ADD_REFOBJID)
If you are using service data distribution in SAP RM-CA, the system determines the telephone number, IP
address or cell phone/SIM card number that belongs to the service from the IST_TDATA table on the
basis of the reference object ID and the additional reference object in the DFKKOP table. You can use
this assignment to create lock proposals at the level of the individual services objects (such as telephone
numbers) in SAP RM-CA. If you are not using service data distribution in SAP RM-CA, the system only
transfers the associated reference object from the open item. Data from the IST_TDATA table is not
available.

There are no plans to make the functions for managing telecommunications service data in the
IST_TDATA table compatible with future developments in the area of service data management. If you
want to use the IST_TDATA table for service data management, you should contact SAP.
2.9.1.4 Manage Services with SAP CRM Integration (Indicator CRM-Integration)
Service data is managed exclusively in SAP CRM. The IST_TDATA table cannot be used. Lock
proposals, which are generated in SAP RM-CA from the dunning run for open items, are based on the
contract account to which the open item belongs. The system creates a list of lock proposals in SAP RM-
CA in a worklist, which you can process periodically using a mass activity. The mass activity transfers the
lock proposals to SAP CRM using the SAP NetWeaver – Process Integration (PI). SAP CRM enters the
lock proposals in a worklist or can transfer them to an external system directly, where the services are
technically locked.
You can also transfer unlock proposals from the payment run to SAP RM-CA via PI, and unlock the
services immediately.
2.9.1.5 Activities
Select the Service Management indicator if you want to use service data distribution in SAP RM-CA
(without SAP CRM).
Select the CRM Integration indicator if you want to use service data management in SAP CRM.
You can specify the number of days for which lock proposals, which are sent successfully, are to be
retained in the worklist in SAP RM-CA before they can be deleted.

111
Configuration Guide

2.9.1.6 Further Notes

For more information on managing Telecommunications services, see the SAP Library at
http://help.sap.com SAP ERP SAP ERP Central Component ERP Central Component
Enhancement Package 4 Industries in SAP ERP SAP Telecommunications Contract Accounts
Receivable and Payable for Telecommunications Management of Telecommunications Services.

2.9.2 Configure Dunning Activities

IMG SAP ECC: Configure Dunning Activities:
In this Customizing activity, you define dunning activities for dunning open, overdue items.
You then assign the activities to the dunning levels in the activity Configure Dunning Procedure.
2.9.2.1 Requirements
The function modules required exist in the system.
You have maintained the required application forms.
2.9.2.2 Activities
...

1. Check the dunning activities delivered and change them if required.

2. Define any new dunning activities that you require. Use only activity types 01 and (only for industry
component Insurance) 02.

2.9.3 Configure Dunning Procedure

IMG SAP ECC: Configure Dunning Procedure
In this Customizing activity, you configure dunning procedures for Contract Accounts Receivable and
Payable.
Firstly you define dunning procedures, and then assign dunning levels to each individual dunning
procedure. The dunning levels basically determine the dunning interval, the charge schedule used for
determining the dunning charges, and how interest is calculated and posted. In addition, you must define
currency-dependent amount limits and dunning activities for every dunning level.
2.9.3.1 Requirements
You must have maintained the following:
Interest keys
Dunning procedure types
Dunning level types
Dunning charges schema
Dunning activities
2.9.3.2 Activities
...

1. Check the dunning procedures defined in the standard system, changing them where necessary.
2. To create a new dunning procedure, proceed as follows:
a. Define the dunning procedure.
b. Create the dunning levels for the dunning procedure.
c. Define currency-dependent amount limits for the dunning levels.
d. Define the required dunning activities for the dunning levels.

112
Configuration Guide

2.10 Technical Resource Management

You can manage technical resources related to order and contract items. Besides the existing allocation
of IBase and IObjects using the service type/division type, there is now a more flexible way to allocate
technical resources of various types. Whether an item‘s technical resources are managed in the new or
the classic way depends on the item’s product.
One main feature which allows more flexibility is the possibility to maintain technical resources as simple,
lightweight extensions of a contract item - that is, without linking the item to any other object within or
outside the system. Another option that improves flexibility is the possibility to link contract items to
resources in external systems.

2.10.1 Technical Resource Management With a Contract Extension

This chapter has been removed from this document and added to the Application Help Documentation.
To access this documentation, choose https://help.sap.com -> SAP for Industries -> SAP for
Telecommunications.

113
Configuration Guide

2.10.2 Technical Resource Management with Individual Object

2.10.2.1 Product Settings
Check the general product settings in Customizing under Cross-Application Components SAP Product:
Basic Settings Define Output Format and Storage Format of Product IDs:
The length of the ID must be 40 characters.
Product without Customizing Transfer from Backend Systems: Assign Category Hierarchies to
Applications:
There should be a hierarchy for the Product application. If necessary, create a new hierarchy.
Settings for Product Type Number Assignment Define Number Ranges for the Product Type
“Material”:
Create a number range group for your categories. Assign a number interval to the group.

Example:

Example for number range group ISU_TO

To create these groups, choose , Afterwards, select each element with and add
it to the ISU Technical Objects group by choosing . As result, the settings
could look as follows (example):

Choose transaction SNUM, enter number range object ISU_TMPVST. You should also assign a
number interval to this object.

114
Configuration Guide

2.10.2.2 Transaction COMM_HIERARCHY

In order to use the technical data, categories for the individual object families ‘0101’ and ‘0102’ have to
exist. The needed settings are described in Customizing under Basic Settings for Sales Setting Up
Master Data Creation of Hierarchies and Categories.
2.10.2.3 Customer Extensions
Customers can use the enhancement concept for product set types to add customer set types to the
existing objects. The following steps provide a short overview of how you can enhance a service object:
2.10.2.4 Transaction COMM_ATTRSET
Define the attributes you require here and assign them to set types. Read the standard documentation for
this functionality carefully. Do not use too many different set types, since this will severely impact the
performance of products and individual objects subsequently.
Enhance the product supply structures by transporting the set type and checking the flag Create API
Append.

The last table (3) is only partly relevant for the Interaction Center WebClient UI. Texts for the attributes
can be maintained at 3 different places, namely within the attribute itself (transaction comm_hierarchy, in
table (3) shown above and, when using the IC UI in the BSP Component Workbench). If texts have been
maintained at all places, the first to be taken is the one in the BSP Component Workbench, the second
the one in above mentioned table (3). If no texts have been entered here, the one from the attribute itself
will be taken.

115
Configuration Guide

When entering technical data in the Interaction Center, there is a standard completeness check for field
EXT_UI (= POD OD = Identification of Service). A BADI is however available for customer specific
checks, which could also be made dependent on the service type:
BADI Name: CRM_IST_SERV_OBJECT
Method: ALL_STATUS_CHECK
2.10.2.5 Transfer of Division-Dependent Set Categories to the PoD category
The report reads all set types maintained in the IMG activity Assign Set Types to Service Types. It
automatically identifies which set types exist in the category of object family 0102 (based on your
Customizing settings in the transaction COMM_HIERARCHY). If they do not exist you can attach them to
the category automatically. You can also delete set types if there is no individual object for this
category/division.
2.10.2.6 Create or Change CI_POD Customer Include
As is the case for the product, it is necessary to add the set type structures to generate or enlarge the
customer include CI_POD (or CI_CON for the location). Select the possible structures in the list on the
left, move them to the list of New Set Categories and choose Execute. Then test the structure, for
example by choosing the Display button.

116
Configuration Guide

2.10.2.7 Time Points for User Exits

The central BADI for the handling of iObjects is BADI CRM_IST_SERV_OBJECT. With SAP CRM 7.0
Enhancement Package 2, this BADI was enhanced with some new methods, in order to enable user exits
for special customer requirements:
ALL_BEFORE_SAVE
ALL_BEFORE_OUTPUT
ALL_AFTER_INPUT
ALL_AFTER_SAVE
Example: if you always want to add a special warranty to a service object of a given service type, you can
add the product ID of the warranty to field WARRANTY_PROD in the method ALL_BEFORE_OUTPUT.
2.10.2.8 Error Handling
Under certain conditions, incorrect entries may occur in table COMC_SETTYP_ATTR of the attributes for
the attributes of set type ISU_CONNOBJ.

117
Configuration Guide

SAP provides a report to solve this error. Please execute the following report:
ECRM_ISU_CHANGE_CONNOBJATTR.

2.11 Technical Resources and BRF

In the provider order and contract you can save service data, for example, SIM card numbers or phone
numbers, in service objects ( iObjects). Additionally the system provides a new place in an extension of
an item, so called Technical Resources (TR), where you can save such kind of information. When you
assign a TR scheme to a product, the system maintains and saves service data in this extension.
Business Rule Framework (BRF) is integrated in the provider order and contract, for example, contract
history and change processes. The iObjects are included in the BRF objects:

A similar integration must be provided for TR. The new TR handling is introduced with SAP CRM EHP2
(switch CRM_PROV_EHP2). As there is no delivery customizing for the TR schemes, a complete
customzing for BRF via delivery customzing cannot be provided. Instead a guide is provided, how to
provide the TR information for the BRF.

2.11.1 Delivery Customizing Switched with CRM_PROV_EHP2

You find the delivery customizing in the following customizing tables in Customizing under Customer
Relationship Management ->Transactions -> Settings for Provider Contracts -> Business Rule Framework
(BRF) ->Define Tags.
Tag Description Class/Interface Runtime Attribute
TC_TECH_RES_TAB Technical CL_CRM_BRF_TAG_STACK_1O_OBJ TC_TECH_RES
Resources

118
Configuration Guide

Table
TR_OBJ_ID Technical CL_CRM_BRF_TAG_STACK_1O_ATTR TR_OBJ_ID
Resource
Object ID
TR_OBJ_KEY Technical CL_CRM_BRF_TAG_STACK_1O_ATTR TR_OBJ_KEY
Resource
Object Key
TR_SLOT Technical CL_CRM_BRF_TAG_STACK_1O_ATTR TR_SLOT
Resource Slot
TR_TYPE Technical CL_CRM_BRF_TAG_STACK_1O_ATTR TR_TYPE
Resource Type
TR_VALID_FROM Technical CL_CRM_BRF_TAG_STACK_1O_ATTR TR_VALID_FROM
Resource Valid
From
TR_VALID_TO Technical CL_CRM_BRF_TAG_STACK_1O_ATTR TR_VALID_TO
Resource Valid
To

Customer Relationship Management -> Transactions -> Settings for Provider Contracts -> Business Rule
Framework (BRF) ->Define Tag Hierarchies
Application Tag Tag Descriptio Parent Tag Descriptio
Class Grouping n n
CRM_CFG_S ITEM_TAG TC_TECH_RES_TA Technical IST_ITEM Item
C CRM S B Resources
Solution Table
Configurator
CRM_CFG_S ITEM_TAG TR_OBJ_ID Technical TC_TECH_RES_TA Technical
C CRM S Resource B Resources
Solution Object ID Table
Configurator
CRM_CFG_S ITEM_TAG TR_OBJ_KEY Technical TC_TECH_RES_TA Technical
C CRM S Resource B Resources
Solution Object Key Table
Configurator
CRM_CFG_S ITEM_TAG TR_SLOT Technical TC_TECH_RES_TA Technical
C CRM S Resource B Resources
Solution Slot Table
Configurator
CRM_CFG_S ITEM_TAG TR_TYPE Technical TC_TECH_RES_TA Technical
C CRM S Resource B Resources
Solution Type Table
Configurator
CRM_CFG_S ITEM_TAG TR_VALID_FROM Technical TC_TECH_RES_TA Technical
C CRM S Resource B Resources
Solution Valid From Table
Configurator
119
Configuration Guide

CRM_CFG_S ITEM_TAG TR_VALID_TO Technical TC_TECH_RES_TA Technical

C CRM S Resource B Resources
Solution Valid To Table
Configurator

2.11.2 Example Customizing

You find an example customizing in the following customizing table under Customer Relationship
Management -> Transactions ->Settings for Provider Contracts->Business Rule Framework (BRF) -
>Define Tag Criteria.
In this customizing you can insert new lines for:
Application Class:
CRM_CFG_SC: CRM SolutionConfigurator
Tag:
TC_TECH_RES_TAB
Parent Tag:
IST_ITEM
Criterion:
You define which type of Technical Resources should be read. The expression in the column
criterion has the structure XX&YYY.
o XX:
Placeholder for a type of Technical Resources
You define the Types of Technical Resources in Customizing under Customer
Relationship Management -> Industry-Specific Solutions -> Settings for
Telecommunications Objects ->Technical Resources-> Define Assignment Schema for
Technical Resources. Here you define what kind of information is stored in the Technical
Resources, for example, mail adresses (EM), phone numbers, or SIM cards.
o &:
Fixed separator if YYY is used.
o YYY:
Placeholder for a number or the fixed expression MAX.
It is possible to have more than one Technical Resource of the same type. Therefore the
Technical Resource can be identified via an additional key named slot. This is a 3 digit number
(CRMT_TC_SLOT). For example, one item could have 10 mail adresses. If you want to get the
mail adress number 3, you use EM&3
Instead of the number you can also use the expression MAX, to get the Technical Resource with
the highest slot number. If the return value of this expression is initial, you know that no Technical
Resource of this type is assigned.
Example
The following Technical Resources exist:
email (EM)
telephone number (TN)
You can define as a Criterion:
EM First Technical Resource of type EM is read
EM&3 Technical Resource of type EM with slot 3 is reas

120
Configuration Guide

TN&MAX The last Technical Resource of type Tn is read

2.11.3 New Criterion for Additional Item Information

Via the Additional Item Information tag it is possible to get the information if a technical resource scheme
is assigned to the product of an item. As you see in the below screenshot there is an additional criterion
Uses Tech Resources.

2.12 Settings for the visibility of the risk class

With CRM 7.0, Enhancement Package 1 it is possible to make general settings for displaying credit
master data. You can display credit master data and use it in other processes using a PI interface to a
credit management system, such as SAP Credit Management (FIN-FSCM-CM). Furthermore, when
display of credit master data is disabled, the risk class is not even read. Remember that the risk class
data might be used in some programs and not only the UI. In case of de-activating the display, the risk
class data will not be available any more.
The credit master data is displayed in the telecommunication-specific Interaction Center and the dealer
application. Further processing of sales orders in the dealer application can be controlled according to the
risk class.
2.12.1.1 Procedure
In Customizing, navigate to Customer Relationship Management Basic Functions Credit
Management Business Partner Valuation Display Credit Master Data from Credit Management
System and execute General Settings. Here you can set, if risk class data is displayed and read or not.

121
Configuration Guide

2.13 Settings for Integration of Credit Management

You have the possibility to integrate an external credit management system, such as SAP Credit
Management (FIN-FSCM-CM). This integration consists of:
You can display credit master data and use it in other processes using a PI interface to a credit
management system. The credit master data is displayed in the telecommunication-specific Interaction
Center and the dealer application. Further processing of sales orders in the dealer application can be
controlled according to the risk class.
Within the creation of an order you are able to submit a credit check using a PI interface to a credit
management system,
You are able to transfer the liability of an order using a PI interface to a credit management system,
For further information on SAP Credit Management and the interfaces, see the Configuration Guide for
SAP Credit Management on the SAP Service Marketplace at http://service.sap.com/fscm SAP Credit
Management Media Library Documentation Configuration Guide, SAP ERP 6.0 EHP4
In SAP CRM you have to make settings in Customizing under Customer Relationship Management
Basic Functions Credit Management and check documentation in Customizing for detailed information.

2.14 Date Profiles for SAP CRM

Date profiles control which date types, time durations, reference objects and date rules can be used in a
specific transaction type or item category. Depending on the date profile, you also define the
characteristics for date types and durations (for example, time unit, reference object, duration, date rule)
in this activity. For example, as of CRM 2006s for Telecommunications, the most important date profiles
are IST_HEADER and IST_ORDITEM, which are included in the standard. Listed below, you can find the
most relevant characteristics:
Date Profile Date Types Durations
IST_HEADER BILL_DATE Billing Date BILLFREQ Frequency of Billing
Plan Settlement
BILL_DATE_TO Next Billing Date
CONTDURA Contract Validity
CANCDATE Cancellation Date Period

CANCRECEIVE Date of Canc.Receipt

CANCREQUEST Cancellation Request

CONTEND Contract End Date

CONTSTART Contract Start Date

DATE_FROM Dates from (Billing Plan)

DATE_TO Dates to (Billing Plan)

122
Configuration Guide

END_DATE End Date (Billing Plan)

HORIZON Horizon (Billing Plan)

START_DATE Start Date (Billing Plan)

IST_ORDITEM BILL_DATE Billing Date BILLFREQ Frequency of Billing
Plan Settlement
CANCDATE Cancellation Date
CONTDURA Contract Validity
CANCRECEIVE Date of Canc.Receipt Period

CANCREQUEST Cancellation Request

CONTEND Contract End Date

CONTSTART Contract Start Date

CONTSTART_OR Original Contract Start Date

DATE_FROM Dates from (Billing Plan)

DATE_TO Dates to (Billing Plan)

END_DATE End Date (Billing Plan)

ISTCONTENDTS End of Contract Time Slice

ISTCONTSRTTS Start of Contract Time Slice

ISTRUNTMBEG Start of Contract Term

ISTRUNTMEND End of Contract Term

SETTL_FROM Settlement from (Billing Plan)

SETTL_TO Settlement to (Billing Plan)

START_DATE Start Date (Billing Plan)

The most important date types have the following meaning:

Date Types Description Comments
CANCDATE Cancellation Date Cancellation Data
CANCRECEIVE Date of Canc.Receipt Date when the cancellation was received
CANCREQUEST Cancellation Request Requested Cancellation Data
Contract end date; will not be set initially. End date is only
CONTEND Contract End Date set during cancellation
CONTSTART Contract Start Date Contract start date; is never changed
123
Configuration Guide

End of Contract Time

ISTCONTENDTS Slice End date for a certain time slice
Start of Contract Time
ISTCONTSRTTS Slice Start date for a certain time slice
Start date of most current contract term (after a contract
extension, this date would reflect the most recent contract
ISTRUNTMBEG Start of Contract Term start date)
Planned contract end date; used for binding end date of
contracts.
This date will be copied to CONTEND when cancellation is
ISTRUNTMEND End of Contract Term triggered.

At the beginning, contract start date, start of contract time slice and start of contract term are identical.
This would change, however, during further processing. To give an example:
A contract is initially created and starts at 01.01.2009:
Contract Start Date: 01.01.2009
Start of Contract Time Slice: 01.01.2009
Start of Contract Term: 01.01.2009

In November 2009, this contract is extended by 12 months:

Contract Start Date: 01.01.2009
Start of Contract Time Slice: 01.01.2009 + 01.01.2010
Start of Contract Term: 01.01.2009

For February 1st 2010, an up sell is executed:

Contract Start Date: 01.01.2009
Start of Contract Time Slice: 01.01.2009 + 01.01.2010 + 01.02.2010
Start of Contract Term: 01.01.2010

Date Profiles can be created in IMG. Navigate to Customer Relationship Management Basic Functions
Date Management and execute Define Date Profile.

2.14.1 Contract Change Based on a Correct Time

To create or change a contract, two options are available to you:
1. The contract begins or ends at a certain time, for example midnight for the corresponding system.
This is set automatically.
2. You can set the current time if the start, end or change date of the contract has the current
system date.
The order capturing process remains the same if you use the second option, but the system defines the
current time.
During order capturing, the following checks are performed:
Check whether the Customizing settings for the fields have been made.
Check whether the creation or change date is the current system date (today).
In change processes such as product configuration or product change, the existing time slice
ends a second before the new time slice starts.

124
Configuration Guide

If you use the new logic and changes have to be made in future, the existing logic for the timestamp is
used.
Example for the existing logic. The Timestamp is not the current time.

Example for the new logic. The timestamp is the current time.

You can make the relevant settings in Customizing under Customer Relationship Management -> Cross-
Industry Functions -> Provider Contract Management -> Transactions -> Define Settings for Transaction
Types.

Set the flags for transaction types PRVC and PRVO. If you want to use the current time, you have to set
both flags for the transaction types for orders and for contracts (PRVC and PRVO). You can set time
stamp for only one process, for example Sales or for both processes. For SAP CC integration you have to
use the new logic.

The fields TIME_IN_SALES and TIME_IN_CHANGE appear if you activate the switch
CRM_PROV_EHP2. The switch setting is maintained in the function group CRM_PROVIDER_CD and in
screen 3.

125
Configuration Guide

2.15 Contract Creation and Processing

2.15.1 Asynchronous Creation of Provider Contracts
2.15.1.1 General Information
With CRM 7.0 Enhancement Package 3 it is not possible to create provider contracts either synchronous
or asynchronous. Synchronous creation of contracts is available is the default setting for relevant
transaction types. However, in order to improve performance of contract creation, it is recommended to
use asynchronous creation of contracts.
The difference between those two ways of creation a contract is the way it is created. Synchronous
contract creation happens by means of an action (please see action profile
IST_ACTION_ORDER_HEAD), whereas asynchronous creation makes use of middleware adapters. This
adapter is registered for the flow of the BDoC ‘BUS_TRANS_MSG’.

If asynchronous contract creation is switched on, it is not possible to communicate processes or parts of it
directly to the UI. This results in:
1. The contract numbers are not displayed anymore, after an order has been
submitted in the Interaction Center.

126
Configuration Guide

2. The status ‘In Activation’ for the order is not displayed, due to the fact that the
contract creation process updates the order item status. Reading the order after
the contract has been created, e.g. by navigation or new selection of orders will
give the correct status.
2.15.1.2 Procedure
Asynchronous contract creation can be activated for each provider order type that has been defined . You
can make the relevant settings in Customizing under Customer Relationship Management Cross-
Industry Functions -> Provider Contract Management -> Transactions -> Define Settings for
Transaction Types.

2.15.2 Status of Provider Orders and Contracts

The following status information are available for Provider Orders:

Provider Order – Status Management

Order Open Order contains

Saved (initial status) Errors

Order Contract Order contains

Order rejected
confirmed Accepted Errors

Order contains
Released Order rejected
Errors

On
Order contains
Activation In Activation
Errors
Date

All Items Activation

Completed
confirmed Failed

The statuses shown are both UI and technical statuses in one. In contrast to the provider order, the
provider contract UI statuses are not necessarily equal to technical statuses.
As it is possible to perform change processes on contractual items process specific statuses can be
reflected per each contractual item. The necessary statuses are shown below:
127
Configuration Guide

Provider Contract – Status Management

Contract Contains
Not yet started
created Errors

On
Activation In Activation
Date

After Activation
Active Cancelled
Activation failed

Cancellation Contains
In Cancellation Lock
pending Errors
After
Change
Locked Locked
Change
Change Cancellation
Pending
Pending Pending

2.15.3 Copy of Order Items in the Contract

The order must have the Released status. The system uses an action that is pre-defined in Customizing
(action profile IST_ACTION_ORDER_HEAD, action ORDER_FULFILLMENT) to transfer all
telecommunications order items (BUS2000155) to the contract.

You can use a user status profile to subject the release process to an approval procedure.

2.15.4 Manual Activation of Provider Contracts

In order to activate a provider contract manually, for instance for testing purposes, please proceed as
follows:
1. Run report CRM_IST_XI_CONF_SIMULATE (transaction SE38)
2. Check option “Perform ‘Commit Work’”

128
Configuration Guide

3. Choose Execute – F8
4. Keep settings on pop-up Test service provider and choose Execute – F8 again

5. Switch to XML Editor view

6. Paste sample XML and edit fields according to the contract that you want to confirm. Choose
Execute – F8

129
Configuration Guide

Further changes may be needed if your contract contains multiple items or if you want to change
existing contracts.

Example XML:
<?xml version="1.0" encoding="utf-8"?>
<nr1:TelcoServiceConfirmation xmlns:nr1="http://sap.com/xi/CRM">
<TelcoService>
<InternalID >0005064811</InternalID><!-- enter contract document number -->
<Item>
<InternalID >0000000010</InternalID><!--enter item number. -->
<ExternalID></ExternalID> <!-- space -->
<ItemProcessType></ItemProcessType> <!-- space or ISTB-->
<ActivationStatusCode>01</ActivationStatusCode> <!--enter activation status code for
Success 01 or for faild 02 -->
</Item>
</TelcoService>
</nr1:TelcoServiceConfirmation>

130
Configuration Guide

7. The system shows the result of the call. Choose Exit (Shift-F3) to complete the action. In case of
errors a XML containing the error reason will be displayed

8. If the call was successful, choose Extras -> Trigger COMMIT WORK in the menu to complete the
action.

Manual activation of contracts should only be done for testing purposes, but never in productive
environment.

131
Configuration Guide

2.16 Settings for Change Processes

2.16.1 General and Important Information about Change Processes
SAP CRM for Telecommunications provides distinguishes between the following (process) types of
change processes:
ISTA - Contract Change, for example:
– Product Change
– Prolongation
– Cancellation
– Move
ISTB - Change Technical Data, for example
– Change SIM Card
– Change Number
ISTC - Lock/Unlock
ISTD – New Contract

In general, change processes are used to update a contract. Contracts are however never updated
directly, but by means of change orders. Depending on the process type, the update of the contract can
differ.
An ISTA change order would update a contract as follows (example):

132
Configuration Guide

From the contract, all relevant data is copied to the change order. The change order changes the validity
dates of the existing contract item and copies the new data of the change order to a new contract item
with relevant dates to the contract. The technical object is linked from the old contract item to the new
contract item.

For an ISTB process, the update of the contract would look as follows (example):

From the contract, all relevant data is copied to the change order. The change order of an ISTB process
then directly updates the technical object of the contract.

Once a change order has updated a contract, the order cannot be modified! However, in case an error
occurs during the distribution of the contract, for instance during activation, the contract and later the
change order become erroneous and this would open the change order for modifications. Once the
changes are done, the modified change order would overwrite the contract with the new, correct data.
Because of this program logic, it is recommendable to keep any kind of approval processes within the
order, i.e. only create the contract after approvals (for instance by a sales manager) have been granted
on CRM side.
Persistent Contract History
As of SAP Enhancement Package 3 for SAP CRM 7.0, you can use the persistent contract history. To
use this function, you must activate the business function Integration of SAP CC and SAP CI with the
Provider Order (CRM_PROVORDERINT_1). For more information, see chapter Define BRF Events for
the Contract History.

133
Configuration Guide

2.16.2 Settings for Change Process ”Product Change”

2.16.2.1 General Information
As of SAP CRM 2006s you can up and down sell products in a sales order as well as in a change order.
In a sales order, all kind of up and down sells are supported. In the change order, however, an up and
down sell only works for main rate plans. The standard product change process does not support
contracts that refer to a master agreement item. In a sales order, all kind of up and down sells are
supported. In the change order, however, an up and down sell mainly works for rate plans.
To enable the above mentioned transfer, implement the Business Add-In (BadI) CRM_RESCUE_DATA.

You can define which products are supported for up and down selling in which order (i.e. sales order or
change order) by using the appropriate Process Type when maintaining the product master.
2.16.2.2 Procedure
In order to get displayed products for up and down selling, two settings have to be done:
1. Make Settings for Pricing
If prices for the up and down selling product shall be displayed in the change process, you have
to select in which way prices shall be calculated. This can be done in two ways, either by means
of IPC or by means of price lists.
See also:
Customizing under Customer Relationship Management Transactions Settings for Sales
Transactions Product Proposals in Quotation and Order General Settings for Product Proposals
2. Maintain Product Proposal Determination
You have to assign a method schema to all relevant sales organizations and transaction types.
This controls which product proposal is determined for a particular combination. You should do
these settings for all telco-specific transactions type, namely PRVO, PRVC and PRVR. The
method scheme provided in the standard that supports the display of product proposals is
‘000018’. Below, you can find an example for the settings which can be done:

Here, it is also important to maintain a price list for each entry so that a price can be displayed in the
product proposal, for instance:

See also:
134
Configuration Guide

Customizing under Customer Relationship Management Transactions Settings for Sales

Transactions Product Proposals in Quotation and Order Assign Method Schema to Transaction
Type

2.16.3 Revoke Processes

With SAP CRM 7.0, Enhancement Package 2 it is possible to revoke a cancellation and a contract
extension.
For the Revoke Extension Process it is important to mention that it can only be executed in the same
order. If the contract extension has been scheduled for the current date, it can only be revoked within the
change order. Once the extension process has been submitted, it can only be revoked, if the date for the
extension to start lies in the future.

2.16.4 Settings for Change Process Move

2.16.4.1 General Information
SAP CRM 7.0, Enhancement Package 2 supports two kinds of move processes, namely a move process
for a rate plan, which is part of combined rate plans, and a move process for rate plans. The difference is
that, while executing a move process for a single rate plan, also a product change is possible, which
should not be possible when moving a rate plan part of a combined rate plan.

Accordingly, SAP CRM 7.0 Enhancement Package 3 offers the following processes
MOVE (for rate plans within a CRP)
MOVE_SRP (for single rate plans)
2.16.4.2 Procedure
In order to support Move Processes, the time dependency for business partners needs to be activated.
This can be done in Customizing under Cross Application Components SAP Business Partner
Activation Switch for Functions
Activate the time dependency for addresses:

2.16.5 Settings for Change Process “Cancellation”

2.16.5.1 General Information
Cancellation processes in telecommunication industry can be relatively complex. For a lot of customers, it
is not sufficient to use one cancellation procedure. In a lot of cases, companies offer, apart from a normal
cancellation procedure, good will cancellations, for which no cancellation rules are needed at all. This
could not be managed by means of one cancellation procedure. For this reason, customers should define
their own cancellation processes if the standard one is not suitable. Other cancellation procedures than
the standard one are not supported directly for the standard change process.

135
Configuration Guide

Change processes shipped by SAP are sample processes based on best practice that might have to be
adapted to customers’ requirements.

2.16.6 Example: Settings for Telecommunications-Specific Lock

Processing
2.16.6.1 Define Lock Reasons
It is possible to define lock reasons (e.g. Lost Cell Phone). When doing so, it is obligatory to assign
service types, which are to be locked using this lock reason, to possible lock reasons. Thus you can
ensure that for instance lock reason “lost cell phone” can only be applied to a wireless rate plan and not
to a DSL rate plan.
2.16.6.2 Procedure
You make settings for lock processing in Customizing for Customer Relationship Management under
Cross-Industry Functions Provider Order and Contract Management Transactions Lock
Processing Define Lock Reasons. Choose a lock reason and assign one or more service types to it. If
you do not assign a service type to a lock reason, the lock reason can be assigned to all service types.

2.16.6.3 Define Authorization Profile for Lock Processing

It is possible to define authorization profiles for lock processing that regulates who can set and who can
delete locks.
2.16.6.4 Procedure
You make settings for lock processing in Customizing for Customer Relationship Management under
Cross-Industry Functions Provider Order and Contract Management Transactions Lock
Processing Define Authorization Profile for Lock Processing. Proceed as follows:
1. Create a new authorization profile, assign a function profile ID and enter a description.
2. Specify the lock origin for which this profile is to issue authorization, such as lock at customer
request and/or automatic locks.
3. Record the lock reasons for which this profile is to issue authorization. If you do not record any
lock reasons, the authorization applies to all customer and automatic locks.

136
Configuration Guide

2.16.6.5 Assign Authorization Profile for Lock Processing

After the authorization profile for lock processing has been created, it must be assigned to a functional
profile.
2.16.6.6 Procedure
In Customizing, navigate to Customer Relationship Management Interaction Center WebClient and
execute Define Business Role. Here proceed as follows:
1. Select a business role, to which you would like to apply the lock role, for instance PROVIDER_IC
2. Navigate to Assign Function Profiles
3. Create a new entry for Function Profile “TELCOLOCKS”
4. Assign the authorization profile for lock to this function profile

2.16.6.7 General Overview

Locks are processed in SAP for Telecommunications using the following three steps:
...

1. Generate dunning proposals (locks) or clear open items (payment run leads to unlocking) in SAP
RM-CA
2. Transfer lock requests from SAP RM-CA to SAP CRM using the Process Integration (SAP PI)
The PI system converts the lock reason from SAP RM-CA, which consists of a dunning procedure,
dunning level and dunning reason, to a lock reason in SAP CRM. This conversion is performed
using the PI Customizing settings. The lock reason is unique in SAP CRM; and can be created
according to your requirements.

You can also define any lock levels with the exception of the UNLOCK lock level, which is pre-defined
and has the lock level 00. You cannot change this lock level.
3. Transfer lock requests from SAP CRM to the external systems.

137
Configuration Guide

The following graphic shows the process steps in diagram form:

Key:
1: Outbound interface for lock request from SAP RM-CA
2: Inbound interface for lock request in SAP CRM
3: Outbound interface for locks in SAP CRM

...
...

1. Lock control using events in SAP RM-CA:

The system registers locks in SAP RM-CA (via the dunning run) or unlocks (via the payment run)
whilst retaining the existing functions for events. The system enters the lock requests in a worklist
and transfers the unlock requests to the PI outbound proxy method directly.
2. Read lock entries from the worklist according to specific selection criteria using the transaction
ISTUNLT930 (report)
The lock proposals read by the system are assigned the status 9 sent, which you can also use to
create an evaluation. You can also delete lock requests that have already been sent using the
report. Lock requests that have not yet been sent have the status 0 not sent.
3. Call the PI outbound proxy method to transfer lock requests to SAP CRM
Lock requests in SAP RM-CA contain the contract account, which is identical to the business
agreement in SAP CRM. In SAP CRM, the system uses the business agreement to search for the
associated telecommunications service objects (such as telephone numbers), which are to be
locked.
The PI Message Interface LockProposalBulkNotification_In is used to transfer the lock proposals to
SAP CRM.
4. Read the lock level for the lock type (lock directly or enter in the worklist) using the lock reason.
The system accesses the Customizing table CRMV_IST_REASON to do so (see the IMG activity
Define Lock Reasons).
5. Process the BAdI CRM_IST_LOCK_BADI
You can filter according to your own criteria in the BAdI, and decide whether the system is to
perform the lock directly or enter it in the worklist (table CRM_IST-LOCK_DB).
138
Configuration Guide

6. Process the worklist using the report CRM_IST_LOCK_LIST_PROCESSING (TC

CRM_IST_LOCK_PROCES)
The report filters according to specific selection criteria (lock date and PI message block size) and
transfers the locks found to external systems (using the PI Message Interface
LockBulkNotification_Out). The system deletes the locks from the worklist immediately when it
reads them.
7. Update the service object in the installed base, and transfer to external systems to be locked if
necessary.
In view of the fact that there is a separate status for locks from SAP RM-CA and locks from
SAP CRM, the system enters the respective lock level and the lock reason in the installed base,
and checks whether the respective other status has a higher lock level. If the current lock
requested has the higher lock level, the system forwards this service object to be locked to the
external systems.
8. Create locks as a result of a customer request using the telecommunications-specific Interaction
Center.
Processing here is the same as that for locks from SAP RM-CA.
For more information on the respective interfaces for PI Message Interfaces, see the SPROXY
transaction in SAP CRM.
2.16.6.8 Activities
In Customizing, choose Customer Relationship Management Industry-Specific Functions
Telecommunications Lock Processing:
-> Define Lock Levels
-> Define Lock Reasons

2.16.6.9 PI Configuration for Lock Processing in SAP RM-CA

2.16.6.10 Use
If you want to use automatic locks from SAP RM-CA during contract processing in the
telecommunications-specific Interaction Center, you should make the following configuration settings for
communication between SAP CRM and SAP RM-CA via the Process Integration (PI).
2.16.6.11 Start PI Configuration Wizard
Use the Configuration Wizard to create the scenario for internal communication.
...

1. Log on to the PI System and start the transaction SXMB_IFR. The system starts the Integration
Builder in the browser.
2. Use the Integration Directory application to start configuration of the Exchange Infrastructure.
3. Choose Object New in the menu to create a new scenario.
4. Double click on the Configuration Wizard entry in the navigation overview section of the dialog box.
The Configuration Wizard will guide you through creation of the entire scenario.

139
Configuration Guide

2.16.6.12 Create the Scenario for Internal Communication

...

1. Create a new object for internal communication, and choose Create.

140
Configuration Guide

2. Choose your SAP ECC System with SAP RM-CA and the interface as the business system:

3. Choose Continue.

141
Configuration Guide

4. Specify the SAP CRM System that processes the lock with the interface
LockProposalBulkNotification_In:

5. Choose Continue for a second time.

6. Choose Continue again to configure the sender agreements.
7. Enter a description for the communication scenario, such as IST_CRM51_Service_Management.
The system generates the corresponding elements.

142
Configuration Guide

8. Enter the logon data in the communication channel generated GeneratedReceiverChannel_XI and
the SAP CRM System as the service number:

Check that the corresponding user (XIAPPLUSER here) exists with the password entered.
You determine the service number in SAPCRM using the transaction Maintain HTTP Services
(SICF):

143
Configuration Guide

9. Choose Execute (F8) and then Goto Port Information in the menu.

The receiver type must be receiver. Modify this accordingly if necessary:

/sap/xi/engine?type=receiver
10. Create the value mapping. The character string in SAP FI-CA consists of the following elements:
Origin of the lock proposal
Dunning procedure
Dunning level
You must assign the character string to the lock reason in SAP CRM lock processing. This requires
you to perform a conversion to PI.
Choose the Tools Value Mapping entry during Integration Builder configuration. Enter the value
assignment as follows:

11. Activate the change list on the Change Lists tab page. Choose the Display Standard entry, choose
the Activate option from the context menu and confirm your selection by pressing the Activate
button.

2.16.7 Customer Specific Change Processes

SAP CRM 7.0 Enhancement Package 3 supports numerous change processes that customers can use
during their implementation. These change processes are based on best practices. In some cases, this
might not be sufficient for all requirements. This is why SAP provides a change framework for change
processes. Each customer can change the way change processes are defined and define new ones.
Generally speaking, the following options are available to adapt change processes:
144
Configuration Guide

Change of Events: Adapt Eligibility

BRF events are used to define, when a change process can be triggered. Hence, they define
when a change process is available. Customers can change these events using the business
rules framework (BRF) and thus adapt the conditions for starting a change process. Among
others this could be used to define a start point when cancellations of a contract can be execute,
for instance earliest 3 months before contract end date.
Implementation of customer specific Process Classes: Adapt Business Logic
Process classes controls the way change processes are executed. In case customer need
completely new change processes with a new logic a new class would have to be implemented.
Change of Process views: Adapt UI
Customers can adapt the views that are being displayed during change processes. Additional
fields could be displayed, for instance.
2.16.7.1 Procedure
Customer specific change processes can be set up by defining process profiles:
Process profiles are used to define change processes, for example for telecommunications-specific
contracts in the Interaction Center WebClient. You can modify the processes that have already been
supplied by SAP and add your own processes. The following steps have to be executed (will be
described in detail):
Define Process Views
Define Process
Define Process Profile
Assign Process Profile
For each process profile, several process types can be assigned (the process type combines a group of
associated change processes). In the standard, SAP offers 3 kinds of process types:
ISTA (used for change processes that result in a contract change, e.g. a product change)
ISTB (used for change processes that do not result in a contract change, for instance a telephone
number change)
ISTC (used for lock processes, for instance financial lock)
An implementation class controls a process for specific events (such as start, end, termination). You must
create a separate class for customer-specific implementations.
See also:
Customizing under Customer Relationship Management Industry-specific Solutions
Telecommunications Profiles Define Telecommunications-Specific Process Profiles
2.16.7.2 Define Process Views
Process views must be created BSP workbench. These views can be used here. For doing so, provide
the BSP application, the View name and a description, for instance:

2.16.7.3 Define Processes

In this step, you define the actual change process. For doing so, the following attributes can to be
defined:

145
Configuration Guide

Process Type: ISTA/ISTB/ISTC

Process Class: The process implementation class controls process execution. The class must
implement the interface IF_CRM_BTMF. If no process implementation class is
specified, the system uses the standard implementation class
CL_CRM_BTMF_CONTENT_TELCO to execute the process during the runtime.
Event: You can use BRF events to control which processes can be selected during the
runtime. You can for example specify that the Contract extension change process
can no longer be selected for a contract that has been terminated (for more
information, have a look at chapter Business Rule Framework)
Text: Text that appears in the Interaction Center WebClient process selection
IPC Active: Makes it possible to run the configuration of a configurable product in the change
process
Service Active: Makes it possible to change the technical data of a product during the change
process
Desc.Link Active: Description of the product appears as a link so that you can navigate to the product
details
Dur. Editable: Makes it possible to change the duration of a rate plan within a change process.

Additionally, you have to assign the views (you previously created) associated with the process including
optional navigation links (for external views). If you do not assign any views to the process, the system
executes the process directly. It is possible to add one or more views to a process.

An example for a change process is the product change:

In this change process, the configuration link is active, the technical data can be changed and the product
description link is active. Furthermore, the contract duration can be changed when doing a product
change.

Each process class is comparable to a BADI. You can use the methods of each class to implement you
own coding. Several interaction time points are offered.

146
Configuration Guide

2.16.7.4 Define Process Profiles

Once the processes have been created, they have to be assigned to a process type (ISTA/ISTB/ISTC),
which is itself assigned to a Process Profile.
Example:

2.16.7.5 Assign Process Profiles

After the process profile has been defined, it must be assigned to the according Interaction Center
WebClient profile, which can be done in Customizing under Customer Relationship Management
Interaction Center Web Client Define Business Role. Here choose the relevant business role (usually
PROVIDER_IC) and navigate to Assign Function Profiles. You can add your process profile under
ISTPROCESS. An example configuration would look as follows:

2.16.8 Definition and Implementation of ISTB Change Processes

2.16.8.1 General Information
SAP CRM 7.0 Enhancement Package 3 supports different kind of standard ISTB processes, for instance
telephone number change or SIM card change. ISTB processes refer to the change of technical data of
rate plans or combined rate plans.
In case customer requires individual ISTB change processes, for instance for IP Telephony IP Address
Changes, a custom process has to be defined.

147
Configuration Guide

In addition to that, change processes also have an impact on product modeling: Dependent components
valid for process type ISTB can be added to the relevant rate plan / combined rate plan, e.g.:

This dependent is an auxiliary product which is usually of type service. It would appear in the change
order of the newly defined ISTB process, unlike the contract products, which would not be part of the
change process. ISTB processes only change technical data, but not the contract itself.
2.16.8.2 Procedure
The definition of customer-specific ISTB processes, for example for the Telecommunications industry,
can be done in Customizing under Customer Relationship Management Industry-specific Solutions
Telecommunications Profiles Define Telecommunications-Specific Process Profiles.

2.16.9 Freeze of Activation Date During Product Change Process

Executing a product change process for the provider contract may change the bill cycle. If this happens,
the activation date has to be set accordingly. The activation must not be performed before the start of the
next billing period for the contract. This date is provided by Convergent Invoicing and has to be used in
the change process. Once the change process ha been executed, the activation date is frozen by graying
out this field on the UI, and you can no longer change it.
A new system status at document header level has been introduced to indicate whether the activation
date is frozen. The flag is set when the bill cycle check is executed for the change process. The flag is
evaluated when the UI for the change process is processed.
The implementation class CL_CRM_BTMF_TELCO_PRODUCT_CHAN contains an example
implementation of how to trigger freeze of the activation date. The relevant implementation parts are
added in the method FINISH.
148
Configuration Guide

To achieve convenient reuse by specialization, the method freeze_date() is available in the super-class
CL_CRM_BTMF_CONTENT_TELCO.

2.16.10 Billing Cycle Changes During Product Change Process

The billing cycle is set when a sales order is created for each contract and generally remains valid for the
respective contract during its entire lifetime, irrespective of any changes made to the contract in change
processes.
Since the billing cycle is dependent on settings made at product level, the process that can lead to
changes to the billing cycle is the product change process.
The implementation class CL_CRM_BTMF_TELCO_PRODUCT_CHAN contains an example
implementation of how to deal with billing cycle changes. The relevant implementation parts are added as
comments in the ‘FINISH’ method:
1. Checks are performed to determine whether the new product allows the current contract billing
cycle;
if yes, no further processing is necessary
if not, proceed with step 2
2. The billing cycle must only be changed at the start of a new billing period. Therefore, the
system/method checks whether the activation date for the process falls exactly at the start of the
next billing period for the contract. To do this, the system/method calls FI-CA via RFC-module to
determine the start date of the next billing period. This date is compared to the activation date of
the process. If the dates do not match, an error message is output.
3. If the process is completed, the new billing cycle is set for the contract.

You can find the implementation of step 1 and step 2 in lines 126ff of the FINISH method. Step 1 is
mainly executed in the CHECK_BILL_CYCLE method, step 2 in the CHECK_ACTIVATION_DATE
method.
You can find the implementation of step 3 in lines 214ff of the FINISH method. Step 3 is mainly executed
in the SET_BILL_CYCLE method.

2.16.11 Business Agreement Change Process

With this process,you can cahnge the business agreement of an active contract by assigning a new
business agreement to the change order. You can implement this process in class
CL_CRM_BTMF_TELCO_ASSIGN_BUAG.
Some prepaid products explicitly need a prepaid account with payment data assigned, otherwise
automatic refill is not possible. If the new prepaid account does not provide payment data, an error
message occurs when the new business agreement (and the new prepaid account) is applied to the
change order. You mus add payment data to the prepaid account by the payment detail view. Then check
the consistency of the new business agreement.
This check is implemented as an additional process CHECK BUSINESS AGREEMENT ASSIGNMENT
(class CL_CRM_BTMF_TELCO_CHECK_BUAG ), which can be performed only when the BUAG change
process displays the error (CRM_ISX_BTX_PAYMENT 218). If the error message does not occur, the
process cannot be displayed in the process list (CL_CRM_BTMF_TELCO_CHECK_BUAG -> check).

2.17 Workflows for Provider Transactions

2.17.1.1 General Information
Workflows are a common requirement in different industries, for example also in the telecommunications
industry. For instance, it is a common to enable workflows for cancellations processes. Before a contract

149
Configuration Guide

is finally cancelled, a supervisor should confirm the cancellation or try to contact customer again and
revoke the cancellation.
In the SAP CRM Telco solution, for example, workflows are also used for deferred activations and
deferred de-activations, i.e. activations/de-activations that are supposed to be executed in future.
Example: If a change order (product change, up-sell) is triggered on March 1st, 2000, for instance with an
st
activation date of December 1 , 2000, a change order is created and one of the Telco-workflows is
initiated. When the activation date, i.e. December 1 st, 2000, is reached, the workflow becomes active and
executes the activation.
The following events of workflows are CRM Telco-specific:
BUS2000156DEFERREDACTIVIATION
BUS2000156ACTIVATIONFAILED
BUS2000156DEFERREDDEACTIVIATION
BUS2000156DEACTIVATIONFAILED
In order to enable workflows for provider transactions, the triggering events have to be activated:
2.17.1.2 Procedure
1. In Customizing, choose Customer Relationship Management Basic Functions SAP Business
Workflow and execute Perform Task-Specific Customizing.
2. Navigate to Application Component Abbreviation “SAP-CRM-BTX-PRV and s elect “Activate event
linking”.

150
Configuration Guide

3. Activate the triggering event.

4. Set flag “Event linkage activated”. Save your entries and choose “Continue”.

151
Configuration Guide

The triggering event is now activated.

5. Repeat the steps above for all events.

2.18 Settings for the Analysis of Telecommunications

Contracts
To analyze Telecommunications contracts using SAP NetWeaver – Business Intelligence (BI), use the
DataSource 0CRM_IST_CONTR_I.
You can use this DataSource to load user-defined partner functions and date types for the
telecommunications contract to BI automatically according to the following settings. Add the
corresponding fields to the extract structure for the DataSource.
You should also define the partner functions, which are to be assigned to the partner function categories
supported by the DataSource as standard.
You should also refer to Customizing activities under Integration with Other SAP Components Data
Transfer to the SAP Business Information Warehouse Settings for Application-Specific DataSources
(PI Basis) Status Concept for BP/Product/CRM Objects, which you can use to transfer the user status
for the Telecommunications contract to BI.

152
Configuration Guide

2.19 API Provider

This chapter has been removed from this document and added to the Application Help Documentation.
To access this documentation, choose https://help.sap.com -> SAP for Industries -> SAP for
Telecommunications.

2.19.1 Interface for Order Creation

The following diagram shows the API interface.

153
Configuration Guide

The interface has the four basic components:

General data: This is mainly the header data for the order/contract, such as the partner, sales
organization and so on. CRMT_ISX_GEN_DATA_API
Item data: All data required to create an item belongs to this part for example product, dates,
business agreements and so on. CRMT_ISX_ORDER_ITEM_API
Control flags: These flags are used to control the create process. For example, if the order has to
be saved to the database using the save and commit flag. CRMT_ISX_CONTROL_API
Export part: This is the return part of the API. This includes the messages created during order
capturing and the IDs of the order or contract that has been created and saved.

The API method has two import parameters. The first parameter includes the order data and is based on
the structure CRMT_ISX_ORDER_CREATE_API. The second parameter includes the control flags and is
based on the structure CRMT_ISX_CONTROL_API.

The order data structure CRMT_ISX_ORDER_CREATE_API has the following structure:

Component Component Type Data Type Description

GEN_DATA CRMT_ISX_GEN_DATA_API Structure General data for provider

order API
ITEMS CRMT_ISX_ITEM_API_T Table List of items for provider
order API
ALT_PARTNERS CRMT_ISX_ALT_PARTNER_API_T Table List of alternative partners
for provider order API

GEN_DATA ( Structure CRMT_ISX_GEN_DATA_API)

The component GEN_DATA has the following structure and is based on the structure
CRMT_ISX_GEN_DATA_API:
Component Component Type Data Type Description
SOLD_TO_PARTY CRMT_ISX_PARTNER_API Structure Partner data in provider
order API
EMPLOYEE CRMT_PARTNER_NO Single field Partner number
ORGMAN CRMT_ISX_ORGMAN_API Structure Organizational data for
provider order API
PROCESS_TYPE CRMT_PROCESS_TYPE Single field Business transaction type

The component SOLD_TO_PARTY has the following structure and is based on the structure
CRMT_ISX_PARTNER_API:
Component Component Type Data Type Description
PARTNER_NO CRMT_PARTNER_NO Single field Partner number

ADDR_NR AD_ADDRNUM Single field Address number

154
Configuration Guide

The component ORGMAN has the following structure and is based on the structure GEN
CRMT_ISX_ORGMAN_API:
Component Component Type Data Type Description
SALES_ORG CRMT_SALES_ORG Single field Sales organization ID

SALES_OFFICE CRMT_SALES_OFFICE Single field Sales office

SALES_GROUP CRMT_SALES_GROUP Single field Sales group
DIS_CHANNEL CRMT_DISTRIBUTION_CHANNEL Single field Distribution channel

SOLD_TO_PARTY: The partner entered here is the standard partner for the contract and all
items where no alternative is entered. The partner has to be maintained in system before the
order is created. The partner’s structure includes the partner number and address number. The
partner number has to be defined each time.
o PARTNER_NO: the partner number (ID). This is mandatory.
o ADDR_NR: the address number of partner
o ORGMAN: this includes the sales organization, sales office, sales group, distribution
channel and division. If the partner is assigned to several sales organizations and has no
default sales organization, the sales organization has to be added to the interface. Note
that the sales organization has to be maintained in the system before calling the API. The
structure of ORGMAN has the following fields:
SALES_ORG: Sales organization
SALES_OFFICE: Sales office
SALES_GROUP: Sales group
DIS_CHANNEL: Distribution channel
DIVISION: Division
o EMPLOYEE: employee responsible. Must be assigned to the sales organization
o PROCESS_TYPE: Business transaction type. This has to be maintained and added to
the interface. The delivered process type PRVO can be used here to create the provider
order

Items
The component item has the following structure and is based on CRMT_ISX_ORDER_ITEM_API:
Component Component Type Data Type Description
ITEM_HANDLE CRMT_HANDLE Single field Item handle

PARENT_ITEM_HANDLE CRMT_HANDLE Single field Parent Item handle

CONTRACT_NR CRMT_ISX_CTR_ID Single field Contract ID

PRODUCT_ID COMT_PRODUCT_ID Single field Product ID

TIMEFRAME CRMT_ISX_DATES_API Structure Dates for provider order

API

BUAG_ID CRMT_BUAG_ID Single field Number of business

155
Configuration Guide

agreement
ITEM_CONFIG CRMT_ISX_ITEM_CONFIG_API Structure Item configuration for
provider order API

The component ITEM_CONFIG includes two components CONFIG (maintain for characteristic) and
TECH_RES (maintain for technical resource). The component is based on the structure
CRMT_ISX_ITEM_CONFIG_API:
Component Component Type Data Type Description
CONFIG CRMT_ISX_CONFIG_API_T Table List of configuration values
for provider order API

TECH_RES CRMT_ISX_TECH_RES_API_T Table List of technical resources for

provider order API

The component CONFIG has following structure and is based on the structure CRMT_ISX_CONFIG_API:
Component Component Type Data Type Description
CHARACTERISTIC COMT_CFGD_CHNAME Single field Characteristic name (object
characteristic)
VALUE COMT_CFGD_VALUE Single field Value of characteristic

The component TECH_RES has following structure and is based on CRMT_ISX_TECH_RES_API_T:

Component Component Type Data Type Description
TR_TYPE CRMT_TC_TR_TYPE Single field Technical resource type
TR_SLOT CRMT_TC_SLOT Single field Number of technical resource
slot
TR_OBJ_ID CRMT_TC_TECH_RES_ID ID of technical resource
TR_OBJ_KEY CRMT_TC_OBJ_KEY Key of technical resource

ITEM_HANDLE – Required for all items, referred to in the parent item field
PARENT_ITEM_HANDLE If there is a hierarchy at item level, this field has to be filled with the
handle from the main item. For example. if there is one sub-item, the sub-item has the handle
from the main item as the parent handle. The same applies to the dependent component.
CONTRACT_NR. The contract can be entered externally. In this case, the number has to be
entered at the level of the main item and not at sub-item or dependent item level. This number is
defined in the order and contract. This is also defined even if only the order is created.
PRODUCT_ID: You must enter the product ID here.
TIMEFRAME: You define the appointment types for the order/contract here. This has the
following components:
o CONTRACT_START: You define the contract start, time slice begin and runtime here.
The appointment types CONTSTART (contract start date), ISTCONTSRTTS (time slice
begin) and ISTRUNTMBEG (runtime begin) are defined here. This field has a timestamp
format, for example 01.09.2011 00:00:00. If this field is not filled, the system determines
dates using the date profile maintained in Customizing.
o TIMEZONE: Define the time zone for the order/contract if the field CONTRACT_START
is filled.

156
Configuration Guide

o CONTRACT_DURATION: The duration of the order/contract is defined here. The

system only defines durations that have already been maintained at product level. If the
entered duration is not assigned to the product, the system defines the default duration
from the product.
o DURATION_UNIT: This unit can be DAY, WEEK or YEAR. This has to be filled each time
if the CONTRACT_DURATION is filled.

- BUAG_ID: You must enter the business agreement ID here. The following check is implemented
here. The system first reads the customized payment setting for the product. If the product has
the prepaid schema and a new business agreement is required due to the customized setting, an
error message is triggered if the field BUAG_ID is initial or the business agreement entered is
already used in another order/contract. In this case, the order/contract cannot be created.
- ITEM_CONFIG: the product can be configured here. For example, you can enter a phone number
(technical resource) or characteristics MMS option. This part has the following components:
o CONFIG: You can maintain characteristics in this structure. If the product is configurable,
the configuration data has to be added to the interface otherwise the product has no
configuration. The configuration has to be maintained manually in the order/contract.
This structure includes two fields:
CHARACTERISTIC: You must enter the characteristics key (name) here. For
example, the product has the characteristic TV_CRAD with 2 values Mobile TV
normal (Mobile_TV) and Mobile HDTV (Mobile_HDTV). Now the characteristic
TV_CRAD has to be entered in the field CHARACTERISTIC and value, for
example Mobile_HDTV in the field value
VALUE: You must maintain he value of the characteristic here
o TECH_RES: You must maintain the technical resources (for example phone number,
DSL ID) for the product here. This structure has following components:
TR_TYPE: You must enter the technical resource type here for example MB
(Mobile Phone)
TR_SLOT: Number of the technical resource slot
TR_OBJ_ID: ID of the technical resource for example the phone number
TR_OBJ_KEY: Key for the technical resource
Alternative Partner
o REF_TO_ITEM_HANDLE: You must enter the handle of the items that have an
alternative partner.
o PARTNER_FCT: You must enter the role of the partner, such as the payer
o PARTNER_NO: You must enter the partner number(ID) here
o ADDR_NR: You must enter the address number of partner here
Control Flags
o EXPLODE_SUBITEMS: If this is selected, item explosion is activated. The explosion is
activated if the items are SC components. If the IPC is used for sub items, the sub-items
have to be added to the interface because in this case the explosion does not work. If SC
items are included in the first call of function module CRM_ORDER_MAINTAIN the SC
validation is switched off. The field SC_VALIDATION in switch structure
CRMT_ACTIVE_SWITCH is used for this purpose .A = Inactive B = Trigger.
o SUBMIT_ORDER – Sets the corresponding status of the sales order to create contract.
o SAVE_ORDER Save is called (kind of test mode, if not requested).
o COMMIT_AFTER_SAVE – Commit work is called in the API. You must select this flag if you
want to save the order/contract to the DB.
o SAVE_WITH_ERRORS – If this is not set, the system does not save orders containing errors
even if the save flag is set.

157
Configuration Guide

Remark: You can only save the order/contract to the DB if the fields SAVE_ORDER and
COMMIT_AFTER_SAVE are defined. If the order contains errors, you must also define the field
SAVE_WITH_ERRORS.
You must also define the field SUBMIT_ORDER, if a contract is involved. If you do not, the system only
creates the order.
Export
o ES_CREATED_ORDER – Structure with the GUID and object ID of the sales order created
o ET_RETURN – List of errors that arise during process
Remarks: If the product is configurable, the configuration data has to be added to the API interface. This
is not added automatically in the default configuration. The configuration has to be maintained manually in
the order/contract if configuration is not maintained.
Enhancement spot: CRM_ISX_BTX_API
The enhancement spot CRM_ISX_BTX_API is created to give the customer the option of influencing the
order/contract creation processes.
The BAdI CRM_ISX_BTX_API is created for provider order/contract creation. Customers can use this
BAdI to influence the creation process for the order/contract. The method MAINTAIN_ORDER in the
interface IF_CRM_ISX_BTX_API is called before the API calls the function module
CRM_ORDER_MAINTAIN. This is called in the method MAINTAIN_ORDER in the class
CL_CRM_ISX_PROV_ORDER_API. The customer should only change he data that is found in the
function module CRM_ORDER_MAINTAIN.
The following data can be changed:
o Sales organization
o Appointments
o Configuration of product
o Partner
o Billing
o Extension
o Header
o Item
o Switch
o Input fields table

158
Configuration Guide

2.19.2 Interface for Creating a Contract

In contrast to the order create operation, you can create multiple objects in a single call here (bulk mode).
API Interface

The interface is similar to the order create operation.

The import part contains:
o Contract: Data describing the content and structure of the contract to be created. This part is
identical to the corresponding part of the Create Order operation (components, general data
and items data). Additionally multiple instances – respectively data for multiple contracts to
be created - can be handed over here.
159
Configuration Guide

DDIC structures used are: CRMT_ISX_GEN_DATA_API /

CRMT_ISX_GEN_DATA_API_TAB
o Control Flags: Flags controlling the contract creation process.
DDIC structure is CRMT_ISX_CTRL_CONTR_CREATE_API
o SAVE_CONTRACT: Save is called (kind of test mode, if not requested)
o COMMIT_AFTER_SAVE: Commit work is called in the API. You must select this flag to
save this contract to the DB.
o ACTIVATION: Defines whether contract activation is performed:
A: Contract is activated
B: No contract activation, but charge plan mapping is evaluated and the
associated data is returned.
C: No contract activation
o NO_BDOC_SEND: If this is selected, no BDOC is sent via CRM middleware, when the
contract is saved.

The export part contains:

Contract: The system defines a corresponding instance in the result set returned for each instance of the
imported contract data.
DDIC structures used are: CRMT_ISX_RETURN_OBJECTS_API/
CRMT_ISX_RETURN_OBJECTS_API_T
This result set consists of:
o The header and object GUID for the created contract
o A list of messages created during order capturing
o An optional list of data generated by evaluating the cross -catalog mapping for each item.
The exported results correspond to importing interface in the function module
CRM_ISX_CONTRACT_MAINTAIN available in SAP ERP (structure
CRMT_ISX_CTR_CC_MAPPING_API). Data is generated if control flag activation is set
to the value ‘B’.

160
Configuration Guide

2.19.3 Interface for Contract Change

API Interface

Contract-
>Change

Import

Process
Item GUID
Data

Process ID

Contract
Parameters Name
SubItems
Value

Control
Save
Flags

Release

Commit
Export

Errors

Change Order

Header GUID

Object ID

The interface consists of the following import/export parameters:

Change data CRMT_ISX_CONTRACT_CHANGE_API
This includes the contract item GUID, BTMF process, and optional change data
Control flags CRMT_ISX_CONTROL_CHANGE_API
Flags for controlling the API work (for example if the change order has to be saved and
committed to the DB)
Return table with any messages Return structure with the GUID and object ID of a change order
created

Change data is transferred to the API module as a name/value table. Therefore, the table type
CRMT_ISX_PROCESS_ATTRIB_API_T is defined as the table for the following structure:

161
Configuration Guide

CRMT_ISX_PROCESS_ATTRIB_API
Component Component Type Data Type Description

NAME STRINGVAL Single Field Name of attribute to change

VALUE Ref to DATA Single Field Value for attribute to change

Structure of CRMT_ISX_CONTRACT_CHANGE_API
Component Component Type Data Type Description

ITEM_GUID CRMT_ITEM_GUID Single field Item GUID of

contract, which has
to be changed
PROCESS CRMT_BTMF_PROCESS Single field BTMF change
process
PROCESS_ATTRIBUTES CRMT_ISX_PROCESS_ATTRIB_API_T Table List of contract
attributes to change

Control Flags
SAVE_ORDER
Save order is called (kind of test mode, if not requested).
RELEASE_ORDER
Release change order to activate all changes simultaneously.
COMMIT_AFTER_SAVE
Commit work is called in the API.
Export
ET_RETURN data type BAPIRETTAB
List of error messages that arise during the API work.
ES_CHANGE_ORDER data type CRMT_RETURN_OBJECTS_STRUC
GUID and object ID of a change order created.

162
Configuration Guide

Further Hints

When processing provider order or contract data, it may be useful to indicate whether the API is active
(for example when using order capturing from the IC). For this purpose, static method
CRM_ISX_PROV_ORDER_API_DATA=> IS_API_ACTIVE returns ‘X’ if the API is active. If contracts are
created by the API, method CRM_ISX_PROV_ORDER_API_DATA=> IS_CONTRACT_API_ACTIVE
returns ‘X’. This could be used when implementing customer-specific logic within a BADI or user exit that
should only be executed when triggered by the API, for example when adding additional data.

163
Configuration Guide

3. Interaction Center
Besides others, you use this functionality to sell services and product bundles through your call center.
You give your customer service employees easy and efficient access to products and provider sales
orders and related processes, supporting both inbound and outbound calls.
All customer contract data, including e.g. telecommunications product and connection data, are stored in
the business scenario Sales and Order Management. This gives you a comprehensive overview of your
customers and the services they use, which in turn allows you to offer appropriate service packages. You
can use modeling tools to model your services and to create and change configurable product bundles
comprising services and physical products.
As well as selling your products, you can support customer service employees with a wide range of
change processes for existing contracts. These enable them to respond directly to requests from end
customers and to lock or unlock individual services as required. They can also have the system set locks
automatically, for example when an order reaches a certain dunning level, and to unlock services when
open items are cleared.

3.1 Basic Settings for Interaction Center

3.1.1 Define Business Role
3.1.1.1 Use
To configure the Interaction Center scenario variant in CRM 7.0 Enhancement Package 2, copy the
standard role Interaction Center Agent (PROVIDER_IC) to a new role in Customizing under Customer
Relationship Management Business Roles Define Business Role. In this new role, activate the work
centers relevant for IC scenario.
3.1.1.2 Procedure
...

In Customizing under Customer Relationship Management Business Roles Define Business Role,
you can create and define business roles. You can use this function to:
Assign function profiles including the navigation bar profile
De-activate work centers
Make work center group links visible in the menu and in work center pages
Make direct group links visible in the menu
3.1.1.3 Requirements
You have defined the configuration key in the IMG activity Customer Relationship Management
UI Framework UI Framework Definition Define Role Configuration Key. The following Role
Configuration Keys are delivered for the provider-specific business roles:

Business Role Role Configuration Key

TELCO-IC DEFAULT_IC
PROVIDER-DL <*>
TEL-CM TELCHANMAN
TEL-PM TELPARTMAN

164
Configuration Guide

You have defined the authorization role in Customizing under Customer Relationship Management
UI Framework Business Roles Define Authorization Role. The following authorization roles are
delivered for the provider-specific business roles:

Business Role Authorization Role

TELCO-IC SAP_CRM_UIU_PROVIDER_IC_AGENT
PROVIDER-DL SAP_CRM_UIU_PROVIDER_DL_AGENT
TEL-CM SAP_CRM_UIU_TEL_CHANNELMANAGER
TEL-PM SAP_CRM_UIU_TEL_PARTNERMANAGER

You have defined the logical links, the work center link groups, direct link groups, and the navigation
bar profiles in the Customizing activity under Customer Relationship Management UI Framework
Technical Role Definition Define Navigation Bar Profile. The following navigation bar profiles are
delivered for the provider-specific business roles:

Business Role Navigation Bar Profile

TELCO-IC TEL-IC
PROVIDER-DL TEL-DL
TEL-CM TEL-CHANNELMANAGER
TEL-PM TEL-PARTNERMANAGER

3.1.2 Define BRF Events for the Contract History

With CRM 7.0 Enhancement Package 2 it is possible to define the BRF events (Business Rules
Framework events), to extend the display of the history provider-specific contracts in the Interaction
Center WebClient. Thus, in the contract history a contract extension could be classified for instance as an
‘Extension Process’ instead of just a ‘Change Order’.
To do so, create BRF events with the Boolean event type. You check whether a specific process has
been executed in a provider order in these BRF events. If the BRF event returns the value ‘true’, the
system includes a new line with the text from the BRF event in the contract history.
3.1.2.1 Procedure
In Customizing, choose Customer Relationship Management Cross Industry Functions Provider
Contract Management -> Transactions -> Business Rule Framework (BRF).
Specify the BRF events to be used to check for existing change processes. You can restrict the check so
that specific BRF events are only checked for contract items with a specific product role. If you do not
make any entry in the Product Role field, the system checks the BRF event for all contract items.

165
Configuration Guide

Note that for each entry in this customizing table, a check will be executed. This could, in a worse case,
reduce performance.
3.1.2.1.1 Persistent Contract History
To optimize system performance, you can persist the contract history. In this case, the contract history is
not determined dynamically.
To use this function, you must activate the business function Integration of SAP CC and SAP CI with the
Provider Order (CRM_PROVORDERINT_1).
If you activate this business function, the new provider contracts are persisted. To persist also the existing
provider contracts, use report CRM_IST_HIST_REBUILD and schedule a job for this report. For more
information, see the report documentation by using transaction SE38.
If you define customer-defined processes and BRF events, you have to do the following:
Make the settings in Customizing for Customer Relationship Management under Cross Industry Functions
-> Interaction Center WebClient -> Define Application Profile. Implement method
DETERMIME_CONTRACT_HISTORY in the new class. If you do not implement this method, the method
of the superclass is used. However, the method of the superclass checks all BRF events, which reduces
the system performance.
In Customizing for Customer Relationship Management under Cross Industry Functions -> Interaction
Center WebClient -> Define Application Profile., assign the change process for your customer-defined
BRF events.

3.1.3 Define Identification Type for Verification Word

3.1.3.1 Purpose
The SAP CRM for the Provider Order Management solution offers the possibility to have customers
identify themselves via a verification word when calling the call center. The verification word is stored in
the business partner master and can be maintained in the Interaction Center and as self-service in the
Provider Web Shop during user registration. The identification type must apply to individuals. SAP
supplies the identification type IST001 here.
3.1.3.2 Procedure
In Customizing, choose Customer Relationship Management Cross-Industry Functions -> Interaction
Center WebClient -> Define Identification Type for Verification Word.
Enter the identification type.

3.1.4 Create and Assign Reference Business Partner

3.1.4.1 Purpose
A reference business partner is used when creating business partners who are consumers. The system
uses values from the reference business partner as reference data in the consumer-specific sets.

166
Configuration Guide

3.1.4.2 Procedure
1. Create the business partner via transaction BP. Assign the role ‘Sold-to Party’ to the business
partner and maintain the relevant sales areas.
2. Assign the previously created business partner as reference business partner. For doing so, in
Customizing navigate to Customer Relationship Management Master Data Business
Partner Basic Settings Maintain Reference Business Partner for Consumers and create the
according entry

3.2 Pricing Settings for Interaction Center

3.2.1 Price List
3.2.1.1 Purpose
A price list allows you to create a list of prices valid at a certain date for a certain list of products and
group of business partners.
In SAP CRM 7.0 Enhancement Package 2 you use price lists to integrate them into the product search in
the interaction center. The use of the price list here would result in the fact that the prices for all products
in the product search are displayed:

In order to use a price list for a product catalog in the Interaction Center, a Price List Type must be
created and afterwards be assigned to the relevant business transaction.
3.2.1.2 Procedure
Proceed as follows to enable Price Lists:
1. In order to use a price list for a product catalog in the Interaction Center, a Price List Type must be
created via Customizing under Customer Relationship Management Master Data Price List
and execute Define Price List Types.
Create a new entry and provide the following information:
Price List Type, e.g. ZTEL
Description
Number range interval, to determine the numbers that are assigned for price lists
Increment by which the item number increases between two consecutive price list items
Pricing procedure, usually 0PROV1
Action profile, to determine how the Post Processing Framework outputs a price list

167
Configuration Guide

2. After the new price type has been created, it must be assigned to a business transaction profile via
Customizing. In Customizing, choose Customer Relationship Management Interaction Center
WebClient Business Transactions -> Define Business Transaction Profiles.
b. Highlight the relevant business transaction profile, for instance DEFAULT.
c. Under Assign Price Types and Price List Types you can now assign the previously created
price list type to the relevant business transaction profile.

3.2.2 Discounts
3.2.2.1 Purpose
SAP CRM 7.0 Enhancement Package 2 supports discounts for orders in the Interaction Center on header
and item level.

Thus, a call center agent can provide discounts to customers when entering an order.
3.2.2.2 Procedure
As indicated before, you can enable discounts on the header level, but also on item level. In this example,
both types will be enabled, starting with the header:
1. In Customizing, choose Customer Relationship Management Basic Functions Pricing
Pricing in the Business Transaction and execute Set Up Easy Condition Entry.
Create a new entry for header discounts by selecting the checkbox field HEADER. Enter the
pricing procedure to which discounts shall be applied and add the condition types, which shall be
used for discounts, for instance 0RB0 (Absolute Discount).

168
Configuration Guide

Note that you can only choose condition types which are included in the selected pricing procedure
and which are defined with condition class A (Discount or Surcharge) or B (Prices). A further
requirement for the selection is that the condition type is set up in the way that manual changes
are allowed on header level and that the condition is no group condition.

2. The next step is to enable discounts also on item level, which is done in the same screen.
Navigate to IMG at Customer Relationship Management Basic Functions Pricing Pricing in
the Business Transaction and execute Set Up Easy Condition Entry.
Create a new entry for item level discounts by de-selecting the checkbox field HEADER. Enter the
pricing procedure (usually 0PROV1) to which discounts shall be applied and add the condition
types, which shall be used for discounts, for instance 0RB0 (Absolute Discount).

Note that you can only choose condition types which are included in the selected pricing procedure
and which are defined with condition class A (Discount or Surcharge) or B (Prices). A further
requirement for the selection is that the condition type is set up in the way that manual changes
are allowed on item level and that the condition is no group condition.

You can permit up to 5 price-relevant condition types from a particular pricing procedure for easy
condition entry. You can then enter values for these 5 conditions directly in the transaction screen, for
example a discount of 3%.
Easy condition entry is only possible for sales documents.

3.2.3 Discount Status

3.2.3.1 Purpose
SAP CRM 7.0 supports manual discounts for orders in the Interaction Center on header and item level. If
you enter manual discounts on item level, the system displays an icon on the status column. This icon
indicates that a manual discount has been granted.
The system displays the following icon for the relevant item:
3.2.3.2 Procedure
SAP provides a special condition function (5002 – Discounts) that you can assign to relevant condition
types. If this condition function is assigned and a manual discount for this condition type is maintained in
the order, the system displays the discount status icon automatically.
Assign the condition function 5002 to the relevant condition types in Customizing for Customer
Relationship Management under Basic Functions -> Pricing -> Define Settings for Pricing -> Create
Condition Types.

169
Configuration Guide

3.3 Setting Up Product Search

3.3.1 Activate Product Search in Product Master Data
3.3.1.1 Use
In the Interaction Center, an agent could either search for products in a certain product catalog or directly
in the entire product master. If the agent shall be able to search within the entire product master, some
settings are necessary that are described here.
3.3.1.2 Procedure
In IMG navigate to Customer Relationship Management Interaction Center WebClient Master Data
Products -> Activate Product Search in Product Master Data.
Here select the flag use master data to activate the use of the product master for the product search.

3.3.2 Define Catalog Profiles for Product Search

3.3.2.1 Use
As a second step, you have to enable the use of the product catalog in the product search in the
Interaction Center. You can maintain various catalog profiles, based on your catalogs, and these are then
available for selection by the Interaction Center agent when searching for a product. The system runs the
search according to the agents’ criteria based on the catalog profiles maintained for the catalogs in this
Customizing activity. The agent can narrow the search further by entering catalog variants, and catalog
areas. In addition the agent can search using various attributes taken from the list of characteristics
maintained for the catalog. A precondition for doing so is that you have created a product catalog and
catalog variants and have replicated your product catalog variants.
3.3.2.2 Procedure
In Customizing, choose Customer Relationship Management Interaction Center WebClient Master
Data Products -> Define Catalog Profiles for Product Search.
Here, carry out the following steps:
170
Configuration Guide

1. Enter a name and description for your product catalog profile. This name will be displayed for
selection in the Interaction Center product catalog search field, and not the actual name of the
product catalog.
2. Enter the product catalog and the product catalog variant which should be used for the search.
3. Enter a catalog view, if you are using one.
4. Select the List Box for Area flag. Select this flag if you are using catalogs with few catalog areas.
When the flag is selected all catalog areas (main and sub) will be displayed in a drop-down list for
selection by the agent in the catalog area search. Do not select this flag if you are using a catalog
with a lot of catalog areas. If the flag is not selected a browse functionality for the catalog area
search is available. This means the system displays only the main catalog area nodes and not all
sub area nodes for the search. You can then refine your search for the correct product within the
appropriate hierarchy nodes.
5. Enter the maximum number of attributes you wish to display for the search in the Interaction
Center. You can maintain lists of characteristics for your catalog areas. You can select a certain
number of these attributes for display as search fields in the product search in the Interaction
Center. Note, the attributes are taken from the top of the list of characteristics, so ensure you
maintain the order in your lists accordingly. For example, if you maintain the maximum number of
attributes to be shown as five, the system will take the first five attributes from the list of
characteristics, so you should maintain the lists so that these five attributes are at the top.

You can create as many profiles as you like. All these profiles will appear in the Interaction Center for
selection in the product catalog search area.

3.4 Tax Calculation in Product Search

In the product catalog search and product details, taxes can be calculated even though no business
partner is identified. For doing so, the settings of the reference business partner are used to calculate
taxes. The document currency is taken from the according sales organization.
As soon as a business partner is identified, taxes are re-calculated based on the settings of the business
partner. Tax values might change at this point of time.

3.4.1 See Also

For more information, see the SAP Customizing Implementation Guide under Cross-Application
Components Transaction Tax Engine.

3.5 Display of User Status and Organizational Data

As of CRM 2007 SP 06, you can use an enhanced user interface of the provider order and the provider
contract in the Interaction Center your industry. You can manually set a status for provider orders and
specify organizational data. These changes are available for the PROVIDER_IC role.
In the Sales Order work center, on the Header tab, there is a new Status & Organization tab available:
Status
You can manually set a status.
Organization
The data of the Sales and Service organization are automatically determined. If the system
determines more than one organization, a dialog box opens where you can select the
relevant organizations for the Sales and Service.

171
Configuration Guide

The organizational units are also displayed on a new tab in the Contracts work center.
3.5.1.1 Procedure
1. In Customizing, choose Customer Relationship Management UI Framework Business Roles
-> Define Business Role. Make sure the function profile IC_BT is available and add a profile value
if necessary.
2. In Customizing, choose Customer Relationship Management Interaction Center WebClient ->
Define Business Transaction Profiles. Choose Dependent Business Transaction and, for the
profile assigned under Define Business Role, add an entry for the relevant provider order
transaction (e.g. PRVO) and select the Auto. Dialog Box checkbox.

3.6 Organizational Units and the Interaction Center

3.6.1 Assignment of Users in the Organizational Model
To ensure that the Sales and Order Management business scenario functions are available in the
Interaction Center WebClient, your must assign your user to a position to which a relevant business role
is assigned. Make this assignment in the organizational model.
To start the Web Application IC, you must assign your user to an Organizational Unit.
...

1. Log on the System.

2. In Customizing, choose Relationship Management Master Data Organizational Management
Organizational Model Change Organizational Model.
3. Choose the relevant Organizational Position to which the adequate business role is assigned.
4. Assign your own user.
5. After having assigned your user, save your changes (Save button).

To maintain a relevant business role for the position your user is assigned to, follow this path in the menu:
Goto Detail object enhanced object description
Then enter the info type business role

Maintain a business role, for instance ‘PROVIDER_IC’, which is the business role that is delivered in
standard.

172
Configuration Guide

3.6.2 Organizational Unit Selection in the Interaction Center

SAP CRM 7.0 Enhancement Package 2 offers the functionality in the Interaction Center to select the
organization unit of business partner (customer) that is identified, in case the business partner is assigned
to several sales organizations. This is standard functionality and does not need any configuration.

3.7 Integration with Real Time Offer Management

3.7.1 General Information
Each time a customer is calling a call center, the agent is being requested to sell additional services to
the customer or enhance the installed base of the customer. This is independent of the reason the
customer is calling. Therefore the agent has to be supported by the system in terms of what to offer to the
customer. The offers should perfectly suit to the customer’s needs. To achieve this customers and their
behaviour have to be analyzed real-time and based on the results appropriate tailored offers shall be
generated and displayed to the agent. Real-Time Offer Management exactly fulfils all of these
requirements. As of CRM 7.0 Enhancement Package 1, Real-Time Offer Management if fully integrated
with the Telco Interaction Center for sales processes.

3.7.2 Settings for Interaction Center

In order to integrate Real-Time Offer Management into the Telco IC, the following steps are needed:
1. Enable Web Services
2. Create and Assign the Authorization
3. Create RFC destination to the Real-Time Decisioning Engine
4. Create a Logical Port for Web Service Proxy CO_OFFERSERVICE_SOAP
5. Create a Functional Profile for Real-Time Decisioning Engine
6. Enable Telco IC Role to Communicate with the RTD Engine
7. Adapt Navigation Bar Customizing
8. Enable “Offer” Button
9. Enable Events via Rule Modeler

Each step is described below.

For more information on the set up of Real-Time Decisioning, please also have a look at note 1096135
and at the Real-Time Offer Management Guides, which can be found under
http://service.sap.com/instguides SAP Solution Extensions SAP Real-Time Offer Management
SAP Real-Time Offer Management
3.7.2.1 Enable Web Service
1. The web service crm_ic_re_ws is released with standard SAP CRM shipment. The system
administrator has to launch the transaction WSCONFIG and release the web service for SOAP
runtime. Just enter the name of service (crm_ic_re_ws) and variant (crm_ic_re_ws) and press
create button in the toolbar. This will enable the service for communication through the
application.

173
Configuration Guide

2. After entering the information, press the create button. The following screen will be shown.

Web Service crm_ic_re_ws is used for real-time communication between CRM Interaction Center/ Dealer
Application and RTOM. It is used to send events from Interaction Center (IC) to RTOM and offers from
RTOM to IC. The communication over this web services happens several times during a customer
interaction.

3.7.2.2 Create and Assign Authorization

The call center agent needs a special authorization to receive the RTD offers. The relevant authorization object
is S_SERVICE. For demo assign * (user can execute all service calls). In a productive environment you must
explicitly specify the GUID of the crm_ic_re_ws service.

174
Configuration Guide

3.7.2.3 Create RFC destination to the Real-Time Decisioning Engine

1. Navigate to transaction SM59 and create a destination for the RTD engine.

2. Select the destination node “HTTP Connections to External Server” and press the “Create”
button. Enter all relevant information similar to the example screen shown below.

175
Configuration Guide

Make sure to provide the right target host and service number (HTTP Port). The path prefix
should be “/IngeneoSAPICSiteAdaptorWS/Service.asmx” as shown above. The path prefix
should not be changed.

3. Go to the “Special Options” tab and make sure the settings are as shown below.

4. As a last step, please save the connection details and test the connection to make sure the
destination is reachable.
3.7.2.4 Create a Logical Port for Web Service Proxy
CO_OFFERSERVICE_SOAP
1. Go to transaction LPCONFIG and enter the following information:

176
Configuration Guide

Make sure the proxy class is “CO_OFFERSERVICE_SOAP” is used. Enter a value for the
logical port as you like.
2. Click the create button.
3. Go to the tab “Call Parameters” and enter the HTTP destination which you created in the
previous step.

4. Save the information and make sure to “Activate” after saving.

3.7.2.5 Create a Functional Profile for Real-Time Decisioning Engine
1. In Customizing, choose Customer Relationship Management Interaction Center WebClient
Basic Functions Real-Time Offer Management -> Define Real-Time Offer Management
Profiles.
1. Choose New Entries and enter the information like the example shown below.

177
Configuration Guide

2. Make sure the logical port name is the one which was created in the previous step. If flag
“Feedback Required” is checked, the feedback screen for “Offers: will be shown to the Telco
IC Agent as the last step during the end of a customer interaction. If the “Feedback Required”
checkbox is checked, and “Complete Feedback” is also checked, then feedback details for all
“Offers” will be shown to the Telco IC Agent, otherwise only a partial feedback list will be
shown to the Telco IC Agent (provided “Feedback Required” is checked).
3. Make sure to select “Telco Integration in IC” for the field “CRM IC RTOM Scenario”.
3.7.2.6 Enable Telco IC Role to Communicate with the RTD Engine
2. In Customizing, choose Customer Relationship Management UI Framework Business
Roles -> Define Business Role.
3. Select the role for which RTD should be enabled. Click the node “Assign Function Profiles”.
Then press “New Entries” in the toolbar.

4. Add a function profile for Offer Management. In the Function Profile ID, select the entry
“OFFER” using F4–Help. Enter the function profile ID which was created in the previous step.
5. Add function profile for Toolbar. In the function Profile Id select the entry ‘WBAR’ using
F4Help. Enter function profile Id ‘RTD’ as the corresponding value.
6. Check if profile RUNTIME is added.

7. Please make sure, that the value “DEFAULT_IC” contains the reference to the Feedback
Custom Controller. For doing so, navigate in Customizing to Customer Relationship
Management UI Framework UI Framework Definition -> Maintain Runtime Framework
Profile. Click on DEFAULT_IC and select Global Custom Controller. It should contain
ICCMP_FEEDBACK with Controller FeedbackCuCo.

178
Configuration Guide

8. Save the business role. All the agents who are assigned to the newly created role will receive
recommendations from the RTD engine.
3.7.2.7 Adapt Navigation Bar Customizing
The navigation bar profile that is assigned to the standard IC business role (PROVIDER_IC) is TEL-IC.
This navigation bar profile would have to be enhanced to enable navigation to RTD Offers. For doing so,
please proceed as follows:
1. In Customizing, choose Customer Relationship Management UI Framework Business Roles ->
Define Business Role. Copy the standard navigation bar profile, for instance to ZTEL-IC. This is
required, as the standard profile misses some Outbound Plug mappings that are needed for offer
related navigation
2. Select the new profile and go to “Define Generic OP Mapping”. Add entries OFFER,
RDT_FEEDBACK, BT155_PSI(Display), BT155_PSI(Edit), BT265_PSO, and BT266_PCD (see
details on picture below).

179
Configuration Guide

If there are problems while creating a new entry, copy an existing entry and change it to the right
parameters.

3. In Customizing, choose Customer Relationship Management UI Framework -> Technical Role

Definition -> Define Work Area Component Repository (customizing table for outbound plug
definition). Select component “ICCMP_OFFRMAIN” and double click on the “Outbound Plug
Definition”. Make sure the following entries exist, otherwise make new entries as shown in the
picture below:

180
Configuration Guide

3.7.2.8 Enable “Offer” Button

In order to ensure that the Real-Time Offer Management “Offer” Button is displayed in the Telco IC, in
Customizing, choose Customer Relationship Management Interaction Center WebClient Customer-
Specific System Modification -> Define Toolbar Buttons and make sure the entry for the “Offer” button
exist (see the example below).

3.7.2.9 Enable Events via Rule Modeler

In order to have events sent to the RTD Engine, certain rules have to be created using the Rule Modeler:
1. Start CRM application with business role IC_MANAGER.
1. Select Create – Rule Policy.
2. Select Context ‘Intent Driven Interaction (IC
WebClient).
3. Create a rule policy for confirmed business
partner (e.g. RTD_BPConfirmed)
b. RTD_CPConfirmed
1. Policy Details: Business Role: enter the business role created in step 5; IC Event:
‘BPConfirmed’
2. Create rule: If Current Event eq ‘Business Partner Confirmed’ Then ‘RTD Engine
Event: Start of Session’

181
Configuration Guide

5. Create a rule policy for created business transactions (e.g. RTD_BTCreated)

RTD_BTCreated
Policy Details: Business Role: enter the business role created in step 5; IC
Event: ‘BTCreated’
Create rule: If Current Event eq ‘Business Transaction Created’ Then ‘RTD
Engine Event: Business Trans. Created’

6. Create a rule policy for entered data (e.g. RTD_DataEntered)

c. RTD_DataEntered

182
Configuration Guide

1. Policy Details: Business Role: enter the business role created in step 5; IC
Events: ‘BDCCurrentOneOrderChanged’, ‘CategoryChanged’, ‘OrderSaved’
2. Create 3 rules:
1. If Current Event eq ‘Current One Order Changed’ Then ‘RTD Engine
Event: Data Entered in BT’
2. If Current Event eq ‘Order was saved’ Then ‘RTD Engine Event: Data
Entered in BT’
3. If Current Event eq ‘Category Changed’ Then ‘RTD Engine Event: Data
Entered in BT’

7. Create a rule policy for confirmed objects (e.g. RTD_DataEntered)

d. RTD_ObjectConfirmed
1. Policy Details: Business Role: enter the business role created in step 5; IC
Events: ‘IObjectConfirmed’ and IbaseConfirmed’
2. Create 2 rules:
1. If Current Event eq ‘Ibase Confirmed’ Then ‘RTD Engine Event: Ibase
Confirmed’
2. If Current Event eq ‘Individual Object Confirmed’ Then ‘RTD Engine
Event: Object Confirmed’

183
Configuration Guide

The rules that need to be created are making use of new rule modeler actions that are part of the
standard delivery customizing.

3.7.3 Configuration of Web Services

3.7.3.1 General Information
SAP CRM 7.0 Enhancement Package 2 provides several web services that can be used for
communication between SAP CRM and Real-Time Offer Management. The following web services are
available:
ROM_AGENT, ROM_ACCOUNT, ROM_PRODUCT: these services are used by RTOM to read master
data from CRM. This is usually done once during a customer interaction. It is supported for the standard
Interaction Center..
ROM_SALES_ORDER: this web service is used by RTOM to read transactional data (sales orders) from
SAP CRM. This is usually done once during a customer interaction. It is only supported for standard
Interaction Center.
ROM_TELCO_ORDER: this web service is used by RTOM side to read orders and contract information
from SAP CRM.
Each of these web services has to be configured so that they can be used.

For more information on the configuration of web services for RTOM, please also have a look at Real-
Time Offer Management Guides, which can be found under: http://service.sap.com/instguides SAP
Solution Extensions SAP Real-Time Offer Management SAP Real-Time Offer Management 7.0
SAP RTOM 7.0 Integration Guide.

3.7.3.2 Authorizations
To work with the Web Services Tool the following minimum authorizations are necessary. If the user does
184
Configuration Guide

not have these authorizations, some functions (for example edit, activate) may be disabled.

Authorization object S_DEVELOP

DEVCLASS: $WS_BOL_GEN
OBJTYPE: FUGR, WEBI, STRU, TABL, TTYP, WEBS
OBJNAME: <name of service object>
P_GROUP: *
ACTVT: 01, 02, 03, 06, 07

Authorization object S_ICF_ADM

ICF_TYPE: NODE
ACTVT: 01, 06

Authorization object S_GUI

ACTVT: 02

Authorization object S_SRT_ADM

ACTVT: 43
WS_NAME: <name of service object>

Authorization object CRM_WST (only for transporting service objects)

USAGE: S / 1 / T
ACTVT: 21
OBJ_NAME: <name of service object>
3.7.3.3
3.7.3.4 Configure Web Services in SAP CRM
Prerequisites
You have copied and adapted the Web services that are available according to your needs. For more
Information, see Web Services in SAP Library under SAP Customer Relationship Management ->
Components and Functions -> Basic Data -> Business Object Layer -> Web Services Tool.
3.7.3.4.1 Procedure
2. Log on to SAP CRM
3. Go to transaction WSCONFIG.
Note that you need to complete steps 3 to 5 for the following four web service definitions:
/CRMWST/ROM_ACCOUNT
/CRMWST/ROM_AGENT
/CRMWST/ROM_PRODUCT
/CRMWST/ROM_TELCO_ORDER
4. Under Service Definition and Variant, enter /CRMWST/ROM_ACCOUNT, for example.
5. Choose Create.
6. In Release Web Services for SOAP Runtime, choose Save.
The following system message appears: No separate node could be found as a service or
external alias for the call address in the ICF. Do you want to create an external alias? This means
that you can call the Web service with the specified URL, but you cannot make any individual
Internet Communication Framework (ICF) settings.
Click Yes.
A transport request is created
7. Go to transaction WSADMIN.
8. Choose Goto Administration settings.
9. Set the J2EE server and port in the following format:[ http(s)://<server>:<port> ]

185
Configuration Guide

Example: http://p178654.wdf.sap.corp:50200
Note: You have to enter the user credentials that should be used by the Web service when
logging on to the system.
10. Double-click on the Web service name.
11. Double-click on the URL.
12. Double-click on the external alias.
13. Choose the tab page Logon Data and set the logon data.
14. Now test the Web service.
To do this, go to transaction WSADMIN and select the Web service /CRMWST/ROM_ACCOUNT.
Choose Test.
15. The Web Services Navigator allows you to view the Web service /CRMWST/ROM_ACCOUNT in
your browser.
16. Perform steps 9-15 for all the Web services.

A key part of RTD Engine is the flexible customer profile. The customer profile consists of all customer-
related attributes that are valuable to RTD Engine for selecting the most suitable offer for the customer.
The range of customer-related attributes that should belong to the customer profile is very customer-
specificand changes regularly – this is usually triggered by the marketing department.

You can define and change a customer profile. This includes configuration steps in RTD engine and
defining and changing Web services. RTD Engine responds to these new and changed customer profiles.
With SAP CRM, you have an example generic (non-industry-specific) customer profile that you can use
as a template. This example customer profile includes all the configuration that is necessary to integrate
the IC with RTD Engine. The result is that IC calls RTD Engine for real-time offers that are suited to the
individual customer calling.
3.7.3.5 Testing of Web Services
Before the SAP RTOM Web services can be used by the customer, they must be activated and some
configuration effort has to be done.
At the moment there are four RTOM web services for Telco CRM. To test these web services in SAP CRM the
functionality “Test Page” of the SAP CRM Web Services tool can be used. It makes sense, to display an object
in the SAP CRM Web UI and to compare it with the fields delivered by the Web Service. To test the
authorization rights of the users too, it makes sense to log on to the SAP CRM system with the user accounts
that are used for the web services or with an account that has the same rights. Which user is used for a Web
Service can be seen in the transaction WSCONFIG. To do so the technical name of the Web Service must be
entered.

For more information on the testing of web services for RTOM, see Real-Time Offer Management Guides
under: http://service.sap.com/instguides SAP Solution Extensions SAP Real-Time Offer
Management SAP Real-Time Offer Management 7.0 SAP RTOM 7.0 Integration Guide

3.7.4 Additional Information

3.7.4.1 Traces
The following steps describe how to run a trace for IC events sent to the RTD engine and on how to
validate that the events on IC side are setup correctly.
1. Activate the trace
a. Set user parameter CRM_OFFER_ENGINE to ' X' (yes, there is a space in front of the
X).
2. Start trace selection and display
a. Start transaction CRM_ICI_TRACE

186
Configuration Guide

b. You should see 2 radio buttons, one for ICI, one for RTD Engine.
c. Select time period, e.g. “last 2 hours’ and select ‘RTD Engine’

3. As a result, you get a list with available trace files. Select the top one.

4. To confirm that the IC setup was successful, go through a full transaction in IC, including account
confirm, sales order create, sales order save and End.
5. Make sure that the following events are shown in the trace:

187
Configuration Guide

3.7.4.2 Supported Events

The following data is sent from the Telco Interaction Center to RTD:

Screen UI action Event sent Data sent (examples)

Account Id Confirm account account confirmed Account Id, contact Id (optional),
Account Id Confirm contact person related partner Partner Id
confirmed
Offer List display offer report offers feedback Offer Id, displayed
Offer List Add to order report offers feedback Offer Id, added to cart
Click on ‘Sales Order’ in business transaction Transaction Id, Type=PRVO, Provider
Navigation Bar created Order, Category ID =BUS2000265
Sales Order Adding product directly None
Sales Order Delete product None
Sales Order Save data entered into Transaction Id, Type Id = PRVO, Provider
transaction Order, Category Id=BUS2000265,
Product GUIDs of all products in the
item list
Sales Order Save report offers feedback Offer Id, ordered (for all offers related to
this sales order)
Click on ‘End’ end session Feedback for all offers
Click on ‘Sales Order’ in Business transaction Transaction Id, Type=PRVO, Provider
Navigation Bar created Order, Category ID =BUS2000265

188
Configuration Guide

3.8 Information Security

3.8.1.1 Use
Information security makes it possible to restrict the access of certain users to only certain categories of
information when they search the Solution Database via:
Knowledge search in Interaction Center (IC) WebClient
Frequently asked questions (FAQs) and solution search in Internet Customer Self-Service (ICSS)
For example, you may want to allow customers searching the Solution Database via ICSS to access only
information for external users, not to retrieve documents flagged for internal use only.

Information security is not used when knowledge administrators search the Solution Database from within
the Solution Database.
3.8.1.2 Features
Information security is achieved by the use of problem profiles, solution profiles, and group profiles. The
set of problems and solutions displayed is determined by the values of attributes such as the problem
type and validation category. For example, you could specify that the profile Guest is allowed to retrieve
only documents belonging to problem type A and validation category Guest.

Problem Profile Solution Profile Group Profile

Individual profile containing a Individual profile containing a Collection of individual
set of values for one or more set of values for one or more problem and solution profiles.
of the following attributes: of the following attributes: It allows the user to access all
Problem type Solution type problems and solutions
matching at least one of its
Problem subtype Solution subtype individual profiles
Application area System status
Validation category User status
Priority type and level
System status
User status
Subject profile

3.8.1.3 Activities
See http://help.sap.com SAP Business Suite SAP Customer Relationship Mgmt. SAP SAP CRM
7.0 Enhancement Package 1 Components and Functions Master Data Solution Database
Concepts Information Security
Maintaining Information Security Profiles
Assigning Information Security Profiles to Users
For details on building your own information security via a Business Add-In, see:
17. Generic Information Security
18. Generic Information Security in SAP CRM

189
Configuration Guide

3.9 Maintaining Information Security Profiles

3.9.1.1 Maintaining Individual Profiles
1. In the SAP Customizing Implementation Guide, choose Service Enterprise Intelligence
Maintain Information Security Profile (transaction CRMD_SDB_PRMN).
The Display Information Security Profile screen appears.
2. You have the following options:
To change an existing profile, choose Display Change, specify the profile, and choose Enter.
To create a profile, choose Create Profile, specify the profile, and choose Enter. Then enter a
description and the profile type, and choose Enter.
To create a profile by copying an existing profile, specify the existing profile on the Change
Information Security Profile screen, choose Enter, and choose Copy Profile.
3. Enter your data as required.
If you want to enter more than one value for an attribute, for example, specify two problem types,
enter the first value, choose Enter, choose More Values, and then choose Insert Values.
3.9.1.2 Maintaining Group Profiles
1. Carry out steps 1 and 2 in section Maintaining Individual Profiles.
2. Include or exclude the individual profiles as required.
You can access the detail screen for each individual profile by selecting an individual profile and
choosing Details.
3.9.1.3 Seeing Where a Profile Is Used
1. Carry out step 1 in section Maintaining Individual Profiles.
2. Specify a profile and choose Profile List Usage.
The list indicates the users to which the profile is assigned, and, if the profile is an individual profile,
the group profiles in which it is contained.
You can access the detail screen for each group profile by selecting a group profile and choosing
Details.
3.9.1.4 Displaying the Problems and Solutions Accessible Through a Profile
1. Carry out step 1 in section Maintaining Individual Profiles.
2. Specify a profile and choose Profile List SDB Records.
You can access the detail screen for each record by selecting a record and choosing Details.
3.9.1.5 Deleting Profiles
1. Carry out step 1 in section Maintaining Individual Profiles.
2. Choose Display Change.
3. Specify a profile and choose Enter.
4. Choose Delete.

3.10 Assigning Information Security Profiles to Users

3.10.1.1 Use
For the applications to which information security applies, see Information Security Use.

190
Configuration Guide

3.10.1.2 Prerequisites
You have maintained the information security profile (transaction Maintain Info. Security Profile,
CRMD_SDB_PRMN).
3.10.1.3 Procedure
...

1. In the SAP Customizing Implementation Guide, choose Service Enterprise Intelligence Assign
Profile to User (transaction CRMD_SDB_PROF).
2. Choose New Entries and specify the user and the profile.
Use the following table to help you make your entries:
Entry Result
You do not specify a user. The user can display all released problems and
all released solutions.
You specify a user, but assign no profile. The user can display all released and
unreleased problems, and all released and
unreleased solutions.
You specify a user and assign a problem The user can display only problems matching
profile (or a group profile containing only at least one of the assigned problem profiles,
individual problem profiles). and all released solutions linked to the
displayed problems.
You specify a user and assign a solution profile The user can display only released problems
(or a group profile containing only individual and linked solutions matching at least one of
solution profiles). the assigned solution profiles.
You specify a user and assign a group profile The user can display only problems matching
containing individual problem profiles and at least one of the assigned problem profiles,
individual solution profiles. and linked solutions matching at least one of
the assigned solution profiles.

3.11 Browser Settings

For all browsers related settings, please have a look at notes 1162605, 1162685 and 1114557.

3.12 Business Partner Search

For searching for business partners, you have the following options:
Standard business partner search
If you use the standard settings, no configuration is necessary.
Define Account Identification
Business partner index search
Define Search Index for Business Partner Search
High-speed business partner search (see below)

The high-speed search is currently not implemented and is scheduled for future support packages. Follow
the consulting note 1125660.

191
Configuration Guide

3.13 Integrated Communication Interface

3.13.1.1 Purpose
The Integrated Communication Interface (ICI) supports the integration of non-SAP communication
products with SAP components that use communication services. The ICI is intended in particular for
scenarios involving multiple communication channels such as telephony, e-mail, and chat, but it can also
be used in single-channel scenarios. It enables activities such as an agent accepting an inbound phone
call, an agent deflecting an inbound chat request, or a supervisor monitoring queues. The ICI is only one
of several components required to implement communication scenarios of this kind.

An example scenario is the integration of communication management software systems with the
Interaction Center (IC) WebClient and IC manager dashboard, provided by SAP Customer Relationship
Management (SAP CRM). For illustration purposes, this example is used throughout this documentation.
The graphic below represents a simplified view of such an example scenario without detailing the
interfaces. The scenario is made up of functionality from three distinct sources – application component,
technology component, and external (non-SAP) component.

SAP offers also a communication management program, namely SAP Business Communications
Management (SAP BCM). For more information, please have a look at the next chapter about SAP
Business Communication Managements.

3.13.1.2 Technology
The ICI is based on Simple Object Access Protocol (SOAP) and eXtensible Markup Language (XML),
which are non-proprietary, Web-oriented, open interface technologies. HTTP is used at transport level.
You can run this communication scenario completely in the ABAP stack of the SAP Web Application
Server.
3.13.1.3 Testing
For test purposes, you can simulate external communication management software using the Contact
Center Simulator (CSS). The CSS has its own user interface to simplify simulation.

192
Configuration Guide

A running J2EE engine is required for this kind of testing.

3.13.1.4 Certification
A certification process is implemented to verify the connectivity of external communication products with
SAP using the ICI. An external product does not have to support the ICI in full. Partial certification is
possible to enable the connection of single-channel communication products, such as telephony
products.
3.13.1.5 Integration
The system architecture required to connect the Interaction center with external communication
management software using the ICI is made up of several components.
The system architecture of the Interaction center example scenario in a live environment is shown below:
3.13.1.6 Live System Architecture

System Architecture Legend

ICI Integrated Communication Interface
BCB Business Communication Broker
BSPs Business Server Pages
SAM Simplified ABAP Messaging

3.13.1.7 ICI-Specific Components

The BCB, BCB API, and SOAP dispatcher components enable the ICI. The messages passed between
the application component and the external component are passed via the ICI.

193
Configuration Guide

3.13.1.8 Application-Specific Components

The application-specific components are linked to the ICI-specific components via the Business
Communication Broker Application Programming Interface (BCB API). This is the API for application
customizing.
In the interaction center example scenario, the application consists of the Interaction Center WebClient,
which provides an ABAP-based user interface for interaction center agents. For more information, see the
documentation for the Interaction Center WebClient, which you can find on the SAP Help Portal under
Customer Relationship Management.
The IC server sends actions to the communication management software via the ICI-specific components
and receives events back from the communication management software also via the ICI-specific
components. The actions might include agent logon, initiate outbound phone call, or remove chat line
from chat session. The events might include new inbound phone call, or new posting in chat session.
3.13.1.9 External Components
These are non-SAP communication systems. In this scenario, the external product is communication
management software, which is a multichannel communication product. This is responsible for merging
requests from different media, routing requests to specific agents or agent groups, queuing requests,
signalling inbound requests to the IC, and so on. The external products communicate with SAP via the ICI
using SOAP and XML.
3.13.1.10 Features
Many application components use external communication services. Integrating an external
communication product with an application component using the ICI can provide:
Integration of multiple communication channels such as phone, e-mail, fax, pager, and chat
Active reporting of new, changed, or completed phone calls, e-mails, or chat sessions (known
generically as items)
Monitoring and statistics
3.13.1.11 Installation
The ICI is delivered and installed as an integral part of the SAP ABAP Basis, meaning that no separate
installation of the ICI is necessary.
3.13.1.12 Customizing
Customizing is via transaction CRMM_BCB_ADM.
3.13.1.13 Testing
You can use the Contact Center Simulator (CSS) to test the ICI without connecting to live communication
management software.

3.14 SAP Business Communications Management

3.14.1.1 Use
Communication management software refers to software products that manage communication channels
such as phone, e-mail, and chat. The Integrated Communications Interface (ICI) allows the
communication management software to communicate with the Interaction Center (IC) WebClient.

With SAP Business Communications Management software, you can deploy IP telephony for everyone
who needs it, including telemarketing experts, customer service agents, switchboard operators, office
workers, mobile experts, and their managers.
SAP Business Communications Management enables key business processes, including:

194
Configuration Guide

Running an inbound contact center

o Run a single or multisite inbound contact center to respond to customer inquiries.
o Give agents – no matter where they're located – full access and control over
communications functions via Web-based tools.
o Give managers the real-time monitoring, reporting, and quality analysis functions they
need to make better business decisions, continually improve agent performance, and
support long-term process development.
Running an outbound contact center
o Plan and execute outbound telesales, telemarketing, and proactive customer service
programs efficiently and effectively, across all locations.
o Minimize redundant work by combining disconnected outbound-calling initiatives into a
single, networked operation.
o Give managers the real-time monitoring, reporting, and quality analysis functions they
need to make better business decisions, continually improve agent performance, and
support long-term process development.
Enterprise-wide communications management
o Provide an all-IP communications foundation for communication-enabled business
processes across the enterprise.
o Provide enterprise-wide IP or Voice Over IP (VoIP) telephony for everyone who needs it
– from any network-connected workstation, terminal, or mobile phone around the world.
Reporting
o Monitor and manage your communications in real time.
o Adjust communication-enabled business processes as needed and manage multiple
locations as a single entity.
o Give your organization a combined operational and business view of all communications
and contact center operations.
Interactive voice response (IVR)
o Provide automatic voice response to customer inquiries or gather information for
intelligent routing of inquiries.
o Allow customers to respond by touch tone, obtain or leave information, and, if needed,
connect to the appropriate contact center agent.

SAP Business Communications management is fully integrated into SAP Business Suite:

195
Configuration Guide

For more information on SAP Business Communications Management, please have a look at SAP’s
homepage under http://www.sap.com/solutions/business-suite/crm/businesscommunications/index.epx.

All SAP Business Communications Management related configuration guides can be found at the SAP
Service Marketplace under http://service.sap.com/instguides SAP Solution Extensions SAP
Business Communications Management (SAP BCM)

196