Perhaps your company is considering implementing SAP CRM to take over functionality you currently carry out in R/3 Sales and Distribution (SD), such as pricing. Regardless of which SAP CRM component you plan to implement, downloading the R/3 customer and product masters ensures consistency between your planning and sales support system (CRM) and your finance and execution system (R/3).

If you have had your SAP system for a while, you may have enhanced your R/3 system to support specific business needs. In general, these enhancements support specialized pricing requirements or other requirements that lead to adding new fields. Let me show you how you can incorporate these enhancements into the CRM environment so that a move to CRM is a step forward for your company and not a step backward.

You should use these processes if:

• You need your data for order processing and you plan to take orders in SAP CRM
  
  
• You use your data for pricing and you plan to carry out pricing in SAP CRM
  
  
• You use your data for workflow or sales assignments

I’ll describe the three methods you can use to move data from R/3 to SAP CRM and enhance it in SAP CRM, and then show you the options for the data flow processes. I’ll also point out some differences between R/3 and SAP CRM data, such as transactional and pricing differences. In general, this article applies to R/3 4.6C and above, including SAP ERP Central Component (ECC) and SAP CRM 4.0 and above. SAP changed the Internet Pricing and Configurator (IPC) significantly with SAP CRM 2005, so comments concerning pricing are most relevant to that environment.

Methods to Enhance Data

You have three options to move the data from R/3 to SAP CRM and enhance it: Easy Enhancement Workbench, sets, and custom tables.

Easy Enhancement Workbench

Easy Enhancement Workbench is a simple tool that automatically generates the necessary structures for People-Centric User Interface (PCUI), SAP NetWeaver Business Intelligence (SAP NetWeaver BI), and SAPGUI. If you are moving specific objects — business partner and business partner relationships, business transactions, marketing elements, account plans, service items, and any other items that are not products — this tool can save you time.

Sets

You use sets (groups of variants) to add fields to the product master. However, you should use caution when adding sets. Although the process appears to be a master data or configuration process, assigning sets and their attributes fundamentally changes the database. After you add a set, you cannot remove it without removing the underlying product data. If the source data is from R/3, you fill the sets via user exit programming. You also can use sets to add attributes to the business partner for segmentation purposes in Marketing. This assignment is not structural — it’s similar to classification in R/3.

Custom Tables

If you prefer to keep the custom table separate, such as when data is optional, you can still maintain it concurrently with another standard table. For example, you could use this process if you wanted to update a processing table with the change information from the ERP system. In this case, the system triggers Business Add-Ins (BAdIs) when it writes the records to the database. Note that you cannot use custom tables to alter product data, but you can use them to update other tables.

Data Flow Processes

After you select which method you want to use to enhance the data, you can download it from R/3 to SAP CRM. To download the custom data, you need to use a pair of user exits — one for R/3 (CRM0_200) and one for SAP CRM (SMOUTIL3). For more information about these user exits, refer to SAP Note 417906. The user exit on the R/3 side packs the data into the BAPIMTCS structure. You configure it by assigning the specific function module to the process CRM0_200 in table TPS34. The middleware calls this user exit prior to sending any data to SAP CRM. On the SAP CRM side, the user exit unpacks the data and moves it to the Business Document (BDoc) prior to the database update (Figure 1). You configure it by creating a new entry in table TBE24 to activate middleware exits. Then, enter process SMOUTIL3 in table TPS34 with the name of your function that will unpack the data.

Figure 1

Table structures available to download additional data from R/3

In the code in Figure 1, T_INT_TABLES are the R/3 table structures, T_BAPISTRUCT is the CRM structure after the system moves the data, T_MESSAGES contain informational and error messages (to cancel the download, for example), and T_OTHER_INFO is a free-form “envelope” that you can use to store data in R/3, retrieve it in SAP CRM, and move it to T_BAPISTRUCT. The T_OTHER_INFO table contains the structure BAPIEXTC, which has four 250-byte fields that move the data from R/3 to SAP CRM. The user determines how to use these fields — typically the first field contains the structure name and key. Regardless of how you pack the fields, the SAP CRM user exit must extract the data in the same manner as you packed it. If possible, the same programmer should write both ends of the exchange.

Figure 2 shows how SAP CRM unpacks the data from R/3. A single record exists in the T_OTHER_INFO table for each instance of the object being downloaded. The assignment process defines a record structure for (LS_MAT_INFO), and then fills the structure with the = statement. If you are passing down multiple types of data, then the struc_name is different depending on the data passed.

Figure 2

Sample code that shows how you can redefine the fields in the download structure to identify the specific data stored in the fields

After you change the field structure in SAP CRM, then you can load the actual data into the new set that you added to the product master in SAP CRM. Figure 3 is a portion of the exit code after assigning field 2 to the appropriate record layout. This shows how you load the data into the product BDoc prior to saving it to the database.

Figure 3

Assignment of downloaded data to new set ZZCOMM_PR_FRG attached to the sales view of the product

CRM0_200

The system calls a function associated with process CRM0_200 for all objects that you download to SAP CRM — you can find the sample module for this process, SAMPLE_PROCESS_CRM0_200, in table TPS01. The system calls the same process function as a wrapper function, which processes the data. Within the wrapper function, you can call functions written specifically to manipulate the different download objects — for example, one function to edit material data and a second function to edit customer data. You activate this user exit by maintaining two tables:

• Table TBE24 defines a customer product value — typically BC-MID for middleware exchanges
  
  
• Table TPS34 defines the function the system should call for the process interface CRM0_200

The sample code provides only the function’s signature and is not a coded example.

CRM Receiver SMOUTIL3

SAP CRM calls the SMOUTIL3 user exit after the standard processing has unpacked the BAPIMTCS structure and loaded the BDoc. With the SMOUTIL3 user exit, the system performs a final validation check and stops the data transfer if something is incorrect. For example, suppose you create a customer product hierarchy in SAP CRM that links a product group value to the rest of the R/3 hierarchy. You can use the function module that you assigned to SMOUTIL3 to check whether the customer hierarchy values match the existing R/3 product hierarchy. If they match, the system assigns the customer hierarchy in SAP CRM. If they do not match, the system cancels the data download by raising an error message.

Data Model Differences Between R/3 and SAP CRM

Table 1 shows the differences between the data models in R/3 and SAP CRM. Note that in SAP CRM, you do not have account codes, so unless you code a user exit, you can only upload business partners of each type (organization or person) into a single account code. In SAP CRM, partner functions are excluded. You assign number ranges with grouping and carry out screen controls with roles.

In SAP CRM, the system converts partner functions into relationships — in addition to partners. You can assign attribute values to these relationships, which enables the same business partner to have relationships with two different business partners with similar values. This commonly occurs with the SAP CRM role of contact person — in R/3, this is usually an employee. You also can model other relationships in SAP CRM. For example, Customer B is a distributor for Customer A or Customer X is a competitor of Customer Y. In general, SAP CRM does not offer a “company” master data view — for example, the accounting information remains in R/3.

Product Differences

You may notice that products are treated a bit differently in SAP CRM. For example, SAP CRM does not download plant or costing data from R/3. As with business partners, SAP CRM separates data into more discrete packages. Furthermore, SAP CRM stores data changes in history data tables. Finally, the product hierarchy is a true hierarchy — the GUID of each level points to the GUID of the next level up the hierarchy. With this in mind, to save time and effort, I strongly recommend that you use the delivered function modules, such as COM_PRODUCT_GETDETAIL_API, to get product data, rather than coding your own selections.

Transactional Differences

When you move to SAP CRM, the system adds new document types — opportunities and leads — to the sales document types. Also, SAP CRM follows the “one-document” concept. For example, R/3 stores an activity in a different table, so it does not connect the activity with other sales transactions. However, in SAP CRM, quotations, activities, opportunities, and orders are just different instances of a common sales transaction. This makes moving from one transaction type to another easy, but makes custom reporting more complex until the data model is understood.

Pricing Differences

In R/3, condition tables contain the key data that points to a separate KONP record that contains the pricing rate. Conversely, in SAP CRM, the key record contains the base pricing rate. If no scale is present, then only one read is required to get the pricing information. This takes at least two data accesses in R/3.

Also, SAP CRM supports some pricing functions that R/3 does not because of missing master data:

• Product cost-based pricing
  
  
• R/3 rebate processing
  
  
• Customer expected price
  
  
• Data determination at access level

SAP CRM performs pricing with IPC. This means that you must rewrite in Java any customer pricing routines that you use in R/3 transaction VOFM. Finally, it may be necessary to download additional data to support certain pricing schemas.

Michael Debevec

Michael Debevec is president of Debevec Consulting, Inc., and is a senior consultant with more than 14 years of experience with SAP. He has worked with SAP CRM for the past nine years and assisted in implementations in the high tech, consumer products, and pharmaceuticals industries. Prior to working in SAP, Michael was an IS manager in charge of logistics systems.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.