SAP ISU/CRM General Facts

-Ripunjay Singh Rathaur

Integration Approach

� CRM Middleware ensures that configurable business object data (like Customer Data) is distributed from

sending system to different receivers. CRM middleware provides an open architecture, efficient data

distribution and an integrated integration process. It also contains a role based authorization concept.

� The RFC connections connect the systems with each other and used to send/receive data. Information

distribution is controlled by the middleware server, which also uses the Bdocs to control data transfer

and error handling.

� CRM Middleware consists of the following :

1. Central component of the Middleware that is part of the CRM Server. This server as a message router

and controls the flow of messages and different adapters.

2. The R/3 plug-in that is installed in a connected SAP R/3 backend system. This is an interface for data

exchange between a SAP R/3 system and mySAP solutions.

Data Replication using Bdocs

� Message processed in the CRM Server are Bdoc messages. Bdoc messages contain Business data, which

have to be distributed using CRM middleware.

� The business data in these messages refer to business object types such as business partner, product,

business transaction and other CRM information.

Communication: CRM Middleware/SAP R/3 /IS-U

To know how to create RFC Destination please follow the below Link:

http://www.slideshare.net/ripunjay_rathaur/rfc-destination-step-by-step

To know how to create Sites follow the link below:

http://www.slideshare.net/ripunjay_rathaur/middleware-creation-of-site-publicationsubscription

In addition to this you must define a logical system in for clients in the SAP backend using the customization

transaction SALE for ALE settings. However, ALE is not used for the data exchange between the R/3 backend and

SAP CRM middleware.

Maintain the RFC destination of the partner system:

� The RFC destination of the CRM system must be entered in the SAP R/3 backend (2001.1 and later

release) in the table CRMRFCPAR. Use T.Code SM30 for this.

� If site with the type R/3 is created on the CRM server using the administration console, you can enter an

existing RFC destination. The logical system is automatically allocated.

Table maintenance:

Site Concept

Integration Data: Data Model

The Slide describes the connection between several objects in IS-U and the accompanying objects in CRM. The

Integration solution guarantees the consistency between the objects in both systems; for example, change to the

IS-U contract trigger changes to the corresponding contract items in CRM, and back.

Replication of IS-U Objects: Relevant Bdoc Types

Replication of IS-U objects: Technical Objects

Ibase Terminology:

Ibase Hierarchy

� An Ibase normally consist of a connection object, any number of Point of Delivery can be allocated to this

object.

� A technical object can only be changed in the IS-U system. When you select Save, the objects are

automatically replicated in the CRM system by means of delta download.

• The basic idea behind the solution is :

� An energy supplier uses technical objects almost always for billing and information purpose. For

this type of company, it makes sense to transfer previous billing-related master data in the

technical object area from the billing system (IS-U) to CRM.

� However, technical objects in IS-U play a considerably larger role for a distribution company with

added Sales and Distribution departments, where the organizations are not completely

separated. Technical objects in a Grid area can still be created and maintain by the technical

departments (rather than the sales departments) in these companies. In addition to this, sales

employees can create technical objects (at the moment only in the CIC) for billing purposes, for

customers in other grid areas.

� This separation means changes cannot be made at the moment to technical objects in CRM.

� The Ibase can have a maximum of two hierarchy steps.

IBASE: Upload of Technical Objects

� CRM enables you to create new technical objects that can be transferred to the IS-U system via the

Contract (upload).

� Once the Contract is saved, the master data generator creates the technical objects that were

replicated in IS-U as new, billable technical constructs (connection objects, premise, Installation

and Point of delivery).

� Data for Connection object and Point of delivery is created first of all, using a master data template.

A second master data template is used to create data for the business partner and contract.

� Once this data has been created, the connection object and Point of delivery are allocated to the

contract in IS-U. A contract number is also created in IS-U.

� This IS-U contract number is replicated in the CRM service contract. In the CRM system, the status

of the service contract changes from ‘open’ to ‘Replication complete’.

Business Partner: SD Customer and BP in IS-U

� When you create a Contract Partner or prospective customer in IS-U, you can also create an SD customer

in the background. The standard customer can:

• Make use of services

• Purchase goods

� A standard Customer is created based on a predefined reference customer

� Different Integration Scenarios are possible:

• SD Billing documents can be posted in FICA

• SD Billing documents requests can be integrated in the IS-U bill

Business Partner: Supported Scenarios

Business Partner: Mapping and Structures

BP Relationship

Business Agreement: Definition/Data

• Master Data at business Partner Level for controlling account processes in FI-CAL

• Equivalent to Contract Accounts in ISU/CCS (less data)

• The Data is made up of

� Inbound Payments

� Outbound payments

� Dunning Control

� Correspondence Control

� Tax

• You can determine the maximum number of business agreements for each business partner in

Customization.

• You can divide different types of business agreements into business agreement classes.

Business Agreement: Prerequisites for Initial Load

• Initial load to Business Partners (sold-to-party) completed.

• Analysis of required contract account types

• Customization

a. Basic Settings

b. Business agreement classes

c. Tax category and Tax characteristics

d. Mapping with FI-CA customizing

i. Correspondence variant

ii. Payment Methods

iii. Shipping Controls

• Mapping Tax determination and terms of Payment

• Mapping field control

• Synchronizing number ranges

• Checking event tables

� Some components (like, IS-U) require that the number of the contract is identical to the business

agreement number in CRM. Identical numbers are allocated in CRM when the system identifies a business

agreement class that has been allocated a corresponding number range. In R/3, the system then identifies

the contract account category to which the corresponding, external number range has been allocated.

� You must configure the number ranges so that an appropriate external number range in each different

system is allocated to every internal number range.

� For the Initial load, you must temporarily switch between internal and external number ranges and

allocate at least one business agreement class to every number range.

Business Agreement: Event Tables

Contracts: Replication and Integration of Contracts

You are a customer Service agent at contract level. You have to create technical objects (service provider) and

contracts in the CRM system. You also have to ensure that the Data is successfully replicated in IS-U system.

Processes: Contract conclusion in mySAP CRM (Call Center)

� A customer calls the call center and wants to conclude a utility contract.

� Step 1: Identify the Customer

� Step 2: Select Utility location (=POD). This is usually done using the address. If neither the connection

object nor the Point of delivery exists in the CRM, the technical objects can be created in CRM IC.

� Step 3: Select the product, once the product has been selected; all contract specific details are negotiated

with the customer (like, Move-In date).

� Step 4: Product-specific configuration. A configuration can be recorded for each utility product. Data is

entered in this configuration during the customer contact. One example is Annual Consumption, which is

given by the customer.

� Step 5: Save the Service Contract (without any error), the replication is triggered and the data is

transferred to IS-U. In IS_U the master data is either newly created or existing master data is changed. If

technical objects were created during the sales process, they are replicated at this time.

� Step 6: Change the status of a CRM contract item. Following the successful replication, the status of CRM

contract item is changed so that the call center employee can see the replication was a success.

Processes: Contract change in MySAP Utilities

In this process the distributor informs the retail company that it has lost a customer in its service territory.

• First, an Idoc informs the retail company that a contract has to be ended. In the IS-U system, the contract

is ended for the specific date (existing function).

• The corresponding CRM contract (respective CRM contract item) now has to be determined in the IS-U

system.

• The contract must be ended in CRM for the same date.

� Contracts can exist and be changed in the CRM system as well as in IS-U.

� Processes exist in the deregulated environment that change contracts without customer interaction.

Status Processing: CRM to IS-U

System and User Status

• The system and user status displayed at Utility contract item Level

� Transfer Status (important for replication)

� System status (given by SAP, e.g. finished due to product change)

� User Status (defined by customer)

We can view the CRM contract item actions that have been executed or are to be executed on the ‘Actions’ tab

page.