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.