The document discusses SAP CRM middleware which ensures configurable business object data is distributed from source systems to receivers. It controls data flow and adapters. The middleware consists of a central component and R/3 plugins. Business data in messages refer to business objects like customers and are distributed using Bdocs. The document also discusses how CRM middleware connects SAP R/3 and IS-U systems using RFC destinations. It provides links on how to create RFC destinations and sites for middleware. Technical objects can be created and changed in IS-U and replicated to CRM. Contracts can be created in CRM and replicated to IS-U, updating master data. Status of CRM contracts is updated following replication success

1. 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.

2. 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.

3. 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.

4. Table maintenance:

5. Site Concept

6. 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.

7. Replication of IS-U Objects: Relevant Bdoc Types

8. Replication of IS-U objects: Technical Objects
Ibase Terminology:
Ibase Hierarchy

9. 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

10. 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’.

11. 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

12. Business Partner: Mapping and Structures
BP Relationship

13. 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

14. 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)

15. 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.

16. 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.

17. 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)

18. 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.