Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Isu crm facts 01.doc


Published on

SAP ISU and CRM Replication objects and Facts

Published in: Technology, Business
  • More than 5000 registered IT consultants and IT corporate's. Request IT online training at
    Are you sure you want to  Yes  No
    Your message goes here

Isu crm facts 01.doc

  1. 1. SAP ISU/CRM General Facts -Ripunjay Singh RathaurIntegration 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. 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. 3. Communication: CRM Middleware/SAP R/3 /IS-UTo know how to create RFC Destination please follow the below Link: know how to create Sites follow the link below: addition to this you must define a logical system in for clients in the SAP backend using the customizationtransaction SALE for ALE settings. However, ALE is not used for the data exchange between the R/3 backend andSAP 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. 4. Table maintenance:
  5. 5. Site Concept
  6. 6. Integration Data: Data ModelThe Slide describes the connection between several objects in IS-U and the accompanying objects in CRM. TheIntegration solution guarantees the consistency between the objects in both systems; for example, change to theIS-U contract trigger changes to the corresponding contract items in CRM, and back.
  7. 7. Replication of IS-U Objects: Relevant Bdoc Types
  8. 8. Replication of IS-U objects: Technical ObjectsIbase Terminology:Ibase Hierarchy
  9. 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. 10. CRM enables you to create new technical objects that can be transferred to the IS-U system via theContract (upload).Once the Contract is saved, the master data generator creates the technical objects that werereplicated in IS-U as new, billable technical constructs (connection objects, premise, Installationand 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 thecontract 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 statusof the service contract changes from ‘open’ to ‘Replication complete’.
  11. 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 billBusiness Partner: Supported Scenarios
  12. 12. Business Partner: Mapping and StructuresBP Relationship
  13. 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. 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 TablesContracts: Replication and Integration of Contracts You are a customer Service agent at contract level. You have to create technical objects (service provider) andcontracts 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. 15. A customer calls the call center and wants to conclude a utility contract.Step 1: Identify the CustomerStep 2: Select Utility location (=POD). This is usually done using the address. If neither the connectionobject 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 negotiatedwith the customer (like, Move-In date).Step 4: Product-specific configuration. A configuration can be recorded for each utility product. Data isentered in this configuration during the customer contact. One example is Annual Consumption, which isgiven by the customer.Step 5: Save the Service Contract (without any error), the replication is triggered and the data istransferred to IS-U. In IS_U the master data is either newly created or existing master data is changed. Iftechnical 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 CRMcontract item is changed so that the call center employee can see the replication was a success.
  16. 16. Processes: Contract change in MySAP UtilitiesIn 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. 17. Status Processing: CRM to IS-USystem and User Status • The system and user status displayed at Utility contract item Level Transfer Status (important for replication)
  18. 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’ tabpage.