Master data is the most critical data setup for the order to cash process to run smoothly. Before covering master data in SAP CRM, SAP APO, and SAP TMS, it is important to understand that the SAP ECC system is the client of record for most of the master data that propagates to SAP CRM, SAP APO, and SAP TMS. The following screenshot shows different master data initiating from an SAP ECC system and replicated into SAP CRM, SAP APO, and SAP TMS:

Figure 2.1 – SAP ECC master data propagation to SAP CRM, SAP APO, and SAP TMS

The transit time from SAP TMS is replicated to SAP APO. Note that there is no standard integration of the transit time to replicate between SAP TMS and SAP APO, but it could be customized if you are working with these SAP ecosystems together. Next, we'll examine the master data elements.

The key master data elements required to execute sales transactions in SAP CRM are organization data, business partners, products, and pricing. Vendors are also replicated from SAP ECC to SAP CRM as business partners. CRM doesn't have inventory; therefore, it doesn't have the concept of a plant as in the SAP ECC system. Let's review CRM master data and concepts around each of these master data elements, starting with organization management.

Organization management overview

One of the first steps when setting up a system with master data is setting up the organization model. The organization model should be set up based on the organization structure requirements based on the project's needs.

The organization structure in CRM is the master data, whereas the organization structure in ECC is a part of the configuration. The maintenance of the organization structure is different in CRM than in ECC. CRM organization structure is more flexible as you can add org units.

ECC organization determination is based on the customer master; that is, if the customer is extended to a different sales org, these sales orgs will be shown as an option when creating a sales order. In CRM, the org determination is based on the org profile assigned to the transaction.

The organization structure in CRM is more flexible and easily maintainable. You can have different organization structures for sales and service business functions within the same organization. A sales org within CRM is mapped to an ECC org unit. Additionally, you can maintain a sales and service org for sales org units or you can create a sales org based on the ECC org structure and create the service org structure based on the service scenarios in CRM.

Explanations of organizational data in the CRM system are as follows:

• Sales organization: The organization unit responsible for selling a product based on certain terms and conditions is termed as the sales organization. In CRM, organization units are created and are mapped to the ECC sales organization within the Function tab of the org master data.
• Distribution channel: A distribution channel is a channel or medium through which materials or services are delivered to the customer. The assignment of the distribution channel within CRM is similar to the sales org. Organization units that are created in CRM are mapped to a distribution channel and division within the Function tab of the org master data.
• Division: The division is the product line of business within an organization. Multiple product lines can fall into multiple divisions and each product line corresponds to each division.
• Sales office: The sales office is defined based on the geographical location of the organization and a company creates the sales office based on the territory they want to sell their product. A sales office within the CRM org structure is assigned to a sales org. The business partner and other attributes, such as postal code, can be assigned to the sales office independent of the sales org.
• Sales group: The number of people working within a sales office is divided into groups and those are called sales groups.
• Sales district: A sales district can be assigned to the org unit attributes within the CRM org structure and can be copied to the transaction from the org structure.
• Service organization: A service organization owns an entity and is comparable to a sales organization in a sales scenario. It is responsible for processing service transactions such as service order/confirmation, service contracts, and so on.

Division usage in SAP CRM

A division is part of a sales area and one of the key pieces of information in sales transactions that helps in reporting a specific line of business. It is also represented as the line of business in a sales transaction. Some businesses may have a requirement to use a dummy division if they aren't using a division as part of their sales area. In that case, the division entered on the sales order is a dummy division mostly represented by 00 and this also ensures the transactions are free of error. Here are the division usage options available in SAP CRM:

• CRM Division Not Active: If you want to use a dummy division in your business transaction, you must activate the Division not active field. If you are not working with divisions in CRM, then activate this field and add an R/3 dummy division. Please note that the divisions entered in R/3 dummy divisions should exist in the ECC system. For example, if the value of an R/3 dummy division is 00 and the Division not active checkbox is activated, then the order created in CRM will be replicated to ECC with division 00 as the header and line items.
• Header Div. Active: An organization working with multiple product lines is recommended to keep the header division active and the division will be determined based on the determination rule. If this is active, then the header division on the CRM sales order is replicated to ECC. For example, if the order division at the order header is 07 in CRM, the order replicated to ECC will consist of 07 as the header division and will be copied to the items as well. If the material is assigned with a different division than in the sales order header, the line item on the sales order will have a division from the product master.

Here is the configuration menu path to configure the use of a division within SAP CRM: SPRO | CRM | Master Data | Organizational Management | Division Settings | Define Use of Division and Dummy Division

Organization data setup

The steps to maintain the org structure in the SAP CRM system are discussed next.

Step 1 – maintaining number ranges for an org structure

You define the number range for the org structure in this step. The following is the configuration menu path to define the number range SPRO | CRM | Master Data | Organization Management | Number Range Maintenance | Maintain Number Range

A subgroup is defined where the first two characters specify the plan version and the last two specify the object type. $$$$ is the default setting. SAP recommends using an internal number range for the org unit. The next screenshot shows Subgroup with the internal and external number range assignment:

Figure 2.2 – Subgroup number assignment

The next screenshot shows the actual number range assignment to the subgroup. Here you can mark the number range to be external or internally determined by the system:

Figure 2.3 – Organization number range maintenance

Note

To add your own number range, please add the entry based on plan version + object type and click Number Range Maintenance to add the number range based on your business requirements.

Step 2 – maintaining number ranges for an org business partner

First, we need to create number ranges for the org business partner, using transaction code BUCF.

Then, we need to define Grouping and assign a number range. This is done using the following menu path: SPRO | Cross-Application Components | SAP Business Partner | Basic Settings | Number Ranges and Groupings | Define Grouping and Assign Number Ranges

The following screenshot shows defining the business partner grouping for an organization and assigning a number range to the grouping:

Figure 2.4 – Defining and assigning a number range to the business partner grouping

You can use either an internal or external number range based on your business requirements. To keep the number same between business partner and the organization number within organization model; you need to maintain the parameter for HRALX Group, PNUMB as 3 within Set up Integration with HR under Integration Business Partner-Employee in CRM configuration.

Step 3 – converting an org model to represent multiple assignments in SAP ECC

If you are using the ECC backend system with multiple assignments, then it is recommended to convert the org model into multiple assignments in CRM. Once this report is executed, you cannot go back to the standard backend integration version. Therefore, before running this report, you can first run it in test mode.

Multiple distribution channels and divisions can be assigned to the org units (sales organization, sales office, and sales group) with this report: SPRO | CRM | Master Data | Organizational Management | Data Transfer | Convert Organization Model to Represent Multiple Assignments in SAP ECC

Once you execute the report, you will see the option shown in the next screenshot. You can also run it in test mode. To run the report in test mode, hit Test to test the program:

Figure 2.5 – Converting an org model to represent multiple assignments in SAP ECC

The current date will default to the date of the program run. Execute it. The log display will show you a list of the org units converted to the enhanced version.

Step 4 – organizational structure download

Run the CRMC_R3_ORG_GENERATE report to download the ECC org structure and create the same organization structure in CRM: SPRO | CRM | Master Data | Organizational Management | Data Transfer | Copy SAP ECC Sales Structure

Select R/3 Org Structure listed in the upper portion of the screen under R/3 Organization Structures and hit the Generate Selected Lines button. This step will generate the organization structure within CRM, which can be seen in the lower portion of the screen. You can also see the status of the generated organization structure in CRM, whether it is generated successfully or not. Once the generated structure shows successfully generated, save the organization structure. The org structure will create on saving.

You can also create service skill groups as an org unit in the CRM org structure if you are working with a service organization and the service structure is separate from the sales structure. This can be created manually with transaction code PPOSA_CRM. Under the org unit, you can create positions and a holder and add attributes to the org unit based on your specific business needs. Make sure to activate the Obj Permitted in Determination checkbox for the organization to determine any CRM transactions. Run the HRBCI_ATTRIBUTES_BUFFER_UPDATE program to clear the org buffer. It is recommended to run the report during business off-hours as this report deletes the tables and rebuilds them.

Org determination in a sales transaction

A sales organization captures the sales in a sales transaction and helps the business to identify the revenue generated in a specific sales organization. Therefore, it is of the utmost importance to determine the correct sales organization in a sales transaction. There are two ways to determine the sales organization in an SAP CRM sales order, that is, with an organization model determination rule or a responsibilities determination rule. Detailed configuration steps for determining the org in a sales transaction are mentioned here.

Rule type responsibilities

Rule type responsibilities are determined based on the org unit assigned to the responsibility. For example, if region R1 is assigned to sales org unit S1 and you want to determine the organization on the transaction based on this specific region, then a rule will be created to assign the business partner (Sold to Party) to region R1. When the transaction is created for Sold to Party, sales org S1 will be determined on the sales order based on region R1 assigned to sales org S1. The attributes within this rule are defined directly in the rule container. Therefore, even if the org model is set up, the attributes need not be linked to the org model. The configuration path to configure a rule and assign it to the org data determination is as follows: SPRO | CRM | Master Data | Organizational Management | Organizational Data Determination | Wizard for Organizational Data Determination | Create Determination Rule of the Responsibility Type

Once an org determination rule is created, the rule is assigned to the org data profile. The configuration path is as follows: SPRO | CRM | Master Data | Organizational Management | Organizational Data Determination | Wizard for Organizational Data Determination | Change Rules and Profiles | Maintain Organizational Data Profile

The following screenshot shows the organizational data profile that a determination rule is assigned to:

Figure 2.6 – Maintaining an organizational data profile

Assign the org data profile to the transaction type as shown:

Figure 2.7 – Assigning the org data profile to the transaction type

Now we have covered rule type responsibilities, which is one way to determine the org data in business transactions. Another way to determine org data is by configuring a rule type organizational model. Let's go through that option.

Rule type organizational model

Within this rule, you need to assign attributes to the org model. Therefore, the org model is set up with the attributes with which you want to determine the org data in the business transaction. The org determination is carried out based on what attribute values you have assigned to the org unit. For example, business partner A is assigned to sales group SG1 and SG1 is assigned to multiple sales areas in the org model. When the business transaction is created for business partner A, the system determines SG1 and the sales org, distribution, and division linked to SG1 in the org model. It is necessary to activate the Object Permitted for Scenario flag for org data determination in the transaction to be successful.

The steps to configure a rule and assign it to the org data determination are as follows:

1. Like the configuration done for the rule type responsibilities, create a determination rule for the rule type organization model. In this step, you select the attributes from the wizard and assign these attributes to the org model: SPRO | CRM | Master Data | Organizational Management | Organizational Data Determination | Wizard for Organizational Data Determination | Create Determination Rule from Organizational Model
2. Once the rule is generated, assign the rule to the org data profile. Assign this rule to the org data profile as outlined in the following path: SPRO | CRM | Master Data | Organizational Management | Organizational Data Determination | Wizard for Organizational Data Determination | Change Rules and Profiles | Maintain Organizational Data Profile

   The following screenshot shows org determination rule being assigned to the org data profile:

   

   Figure 2.8 – Assigning an org determination rule to the org data profile

3. The final step is to assign the org data profile to the transaction type as shown:

Figure 2.9 – Assigning the org data profile to the transaction type

We have gone through the concept of the org model setup and different ways to determine the org model in sales transactions. Our next master data topic is business partners. Let's review and understand the concept of business partners in SAP CRM.

Customers are referred to as business partners in SAP CRM. Business partners are those that organization does business with and they are categorized as follows:

• Accounts: Accounts can be an organization, individual accounts, or a group. Sold to, Ship to, Payer, and Bill fall under the accounts category.
• Contacts: Account contacts are people assigned to the accounts. These are maintained as a relationship to the accounts.
• Employee: Employees are also people, and are the members of the company that are responsible for any interactions with the accounts.

A business partner consists of general data and sales area data. The data in most business scenarios needs to be in sync from ECC to CRM. In most SAP implementations, ECC is the client of the record that propagates to CRM, APO, and TM:

• General data: This includes information such as address, identification, control of where the tax information resides, classification (information about account group mapping and the business partner, marking whether it is a competitor, prospect, consumer, or customer), and status.
• Sales area data: This includes data on sales, shipping, billing, and pricing. It is specific to the sales area (sales org, distribution channel, and division).

Business partner concepts

The concept of a business partner in CRM is different from accounts in SAP ECC. You need to assign a grouping, that is, a number range, manually when creating a business partner in CRM. Roles are assigned to the business partner and these can be Sold to, Ship to, Bill to, and so on. The following sections look at these in detail.

Business partner roles

Business partner roles classify the business partner in business terms. This means every business partner has a specific role; for example, a business partner can have the Sold to, Ship to, Bill to, or Payer role (and so on). Each of these roles also controls the view of the business partner web UI. Some business partner roles show specific views that are different from other roles; for example, a competitor role has views that normal business roles such as Sold to and Ship to don't have.

It also derives the classification of the customer whether the business partner is a consumer, customer, prospect, competitor, or rented address. The business partner role is used for classification purposes during data exchange with SAP ECC.

Business partner relationship

The business partner relationship specifies the connections between two partners. A business partner relationship has business partner relationship categories that describe the kind of relationship between two partners, for example, Is a contact person of or Is a Bill to party of. Basically, the business partner relationship category describes the characteristics of the business partner relationship. You can also set a validity period for a business partner relationship.

Business partner functions

Like ECC customer masters, CRM has business partners with general data consisting of the address, identification, control, classification, payment transaction, long text, marketing attributes, status, and factsheets. This screenshot shows a business partner example in SAP CRM that shows various tabs:

Figure 2.10 – A business partner with the Sold to Party role

The following points look at these tabs in detail:

• Address: Address data within a business partner is maintained when creating the business partner in SAP CRM. The address maintained in ECC is replicated to SAP CRM. You can have multiple addresses based on the address usage; for example, standard addresses of a Sold to can have a different billing address and delivery address. If only one address is maintained in the customer master data, then that is referred to as the standard address.
• Identification: Identification data within a business partner gives the company the ability to key in some industry-specific information, identification numbers, that is, linking the ECC customer master data to the CRM customer master data based on ID type, and tax information. In the case of vertical industry standards where you are required to have GLNs, they are maintained in the account master. This can be keyed in the Location 1 and Location 2 number fields within the Identification tab, which helps to determine the account based on GLNs.

  Tax classification and tax number data can be stored in the Identification tab of the business partner. This is data that is required to determine how business partners are to be taxed. The tax classification corresponds to the ECC tax classification used in the customer master records.

• Control: Control information in the business partner consists of control parameters, that is, business partner type, authorization group, and print format. The authorization group is used to stipulate which business partners a user is allowed to process. Control data also gives information on the business hours, such as goods receiving hours. Goods receiving hours are assigned with the factory calendar, which has the number of weekdays that the Ship to party can receive products.
• Payment transaction: Payment transaction allows the organization to maintain the bank details and payment card information. When a transaction is processed for a customer, the payment card information on the transaction is populated based on the data fed in the customer master.
• Classification: Classification information shows you whether the account is a competitor, consumer, customer, or prospect. If the PIDE transaction settings in ECC have the account group mapped to the classification customer for a specific CRM customer grouping, then the customer check is activated in the Classification tab.
• Long Texts: Long texts are customer text IDs that can be populated on the transaction for a given specific customer.
• Status: A customer's status information is populated in the Status tab. A customer can be archived, centrally locked, or not released. Based on the customer status, you can either use this customer to process any transaction or not. Any status related to a transaction blocking reason, delivery blocking reason, or billing blocking reason is showed on the business transaction if the customer master data has any of these statuses populated.

To define blocking reasons you customize in CRM under the path Master Data | Business Partner | Status Management | Define Blocking Reasons.

The life cycle stages signify the different stages of a business partner. Different stages may entail the customer being a lead at the starting stage, then the lead turns into an opportunity, and then the lead is converted into a customer. Once a customer is created in SAP, sales transactions are created for this customer to perform sales.

As we have gone through the business partner functions; let us now understand the business partner employee and its distribution from ECC into CRM in our next section.

Role Employee for HR Integration in CRM

An employee is a business partner that is a person within an organization. This is an internal business partner with a business partner category person. You can establish a relationship between a customer and an organization employee. You can create a business partner employee in SAP CRM or you can integrate an employee within HR in ECC and load it to CRM.

You can distribute your existing internal employee records by Application Link Enabling (ALE) from the HR application components in the ECC system to CRM.

If you configure the settings in CRM under Integration Business Partner – Employee, the system creates an employee in CRM from the distributed HR master data, that is, business partners with the employee role and Is employee of relationship between these business partners and your organization.

Duplicate checks for the Accounts and Contacts

You can activate duplicate checks for accounts and contacts in SAP CRM. The duplicate check is not activated by default. Once the duplicate check is activated, the duplicate business partner is shown as a popup and you can either discard the new business partner creation or merge it with another account.

You activate duplicate checking in customizing under SPRO | SAP NetWeaver | Application Server | Basis Services | Address Management | Duplicate Check | Activate Duplicate Check and Determine Limit for BAPIs.

Make sure that the duplicate check has been activated for both index pools (tables BUT000 and BUT052):

Figure 2.11 – Activating duplicate checks and determining the limit for BAPIs

You can add a Threshold BAPIs value, as shown in Figure 2.11, if 80% of the data of the new partner creation matches an existing business partner in the system; in that case, the user will receive a duplicate check popup.

Pre-requisite steps to replicate customers from ECC to CRM

First, we need to define business partner number ranges in SAP CRM:

1. In the SAP CRM menu, go to the BUCF transaction.
2. Choose Change Intervals.
3. Click on Add Intervals to add the number range shown in the following screenshot:
   

   Figure 2.12 – Adding business partner intervals

4. You can maintain number ranges the same as they are maintained in ECC (transaction code OVZC), marking them as an external number range.

Next, we need to assign number ranges to business partner groupings (SAP CRM):

1. Go to SPRO | Cross-Application Components | SAP Business Partner | Business Partner | Basic Settings | Number Ranges and Groupings | Define Groupings and Assign Number Ranges.
2. Choose New Entries and add an entry as follows for Sold-To, Ship-To, Bill-To, Payer, and other partners per your business needs, and then assign a number range to the groupings based on the same number ranges in ECC:

Figure 2.13 – Maintaining business partner groupings

Now we have to assign ECC account groups to CRM business partner groupings (SAP ECC). For each of the SAP ECC account groups, define a mapping to a CRM business partner classification and grouping. The steps are as follows:

1. Access the activity using the PIDE transaction.
2. For each account group, specify the classification (CRM customer) and the grouping (that is, number ranges).
3. In the dialog, choose ECC | CRM: Assign Account Group to BP Classification.
4. Choose New entries.
5. Enter the following values based on your business requirements:
   

Figure 2.14 – PIDE – R/3CRM Assign Account Group to BP Classification

Business partner roles within SAP CRM don't map to the ECC account groups automatically. Therefore, mapping ECC account groups to the Sold-To, Ship-To, Bill-To, and Payer CRM roles must be done programmatically.

Customers loaded from ECC to CRM are loaded as Sold-To party for any account groups in ECC. Therefore, it is necessary to map the account groups to the business partner roles as specified in SAP Note 914437 – Pre-assigning business partner roles during download from account group. The standard business transaction event (BTE) that maps ECC account groups to CRM business partner roles needs to be enhanced using a custom user exit.

Mapping ECC customer master data standard fields to CRM custom fields

The steps required to map fields from ECC customer master data to CRM business partner master data are as follows:

1. Create a custom field on the customer master data based on your requirements through the AET tool. This will add the custom fields to the BUT000 table.
2. In ECC, access transaction code SE11 and enter BSS_CENTI as the structure name. Double-click on CI_CUST and create a structure called CI_CUST by adding the custom fields that were added in the CRM business partner using AET. Please make sure to have it added in ECC with the same sequence that was added in CRM.
3. Repeat the same steps for the BSS_CENTIX structure. Double-click on CI_CUST_X and create a CI_CUST_X structure by adding the custom fields that were added in the CRM business partner using AET. Use the GB_BAPIUPD component type.
4. Modify the code to map the fields as a copy of FM SAMPLE_FCTMODULE_DE_EIOUT in ECC.
5. Create a customer product entry in TBE24, and then assign it to the DE_EIOUT event with the new function module (FM) created (copy of FM SAMPLE_FCTMODULE_DE_EIOUT) in the TBE34 table.

Adding additional fields to customer adapter objects

You can add additional fields to a customer adaptor object via transaction SM30, accessing the SMOFFILFLD table and maintaining the entries. Once you add the entries, save them.

Maintaining the adapter settings

The steps to maintain filters before downloading the customer and customer relationship are as follows:

1. Go to transaction R3AC1.
2. Select the CUSTOMER_MAIN business object and choose details.
3. Go to the Filter Settings tab.
4. In the Source Site Name field, choose the site (OLTP).
5. Maintain the filter settings based on your business requirements.
6. Save your settings.
7. Hit the Filter Sync (R/3) button to synchronize your filter settings.

With this step, you have maintained the adapter settings by adding a filter. Filters are fields or attributes with a filter value that you can mark as inclusive or exclusive and download the customer from SAP ECC to SAP CRM. For example, if you want to exclude a customer of a certain account group, you would exclude it while setting the customer adapter object.

Customer master data replication

Once you have completed all the pre-requisite steps, you can start loading a customer from ECC to CRM. To replicate a customer, follow these steps:

1. Go to the SAP CRM menu and access transaction R3AS, as shown in the following screenshot:
   

   Figure 2.15 – Customer master initial load

2. In the Load Object field, enter CUSTOMER_MAIN.
3. In the Source Site field, enter OLTP, and in the Destination Site field, enter CRM.
4. To run the replication, choose Execute (F8).
5. Confirm the next screen's message by clicking Continue.

Monitoring the replication status (SAP CRM)

You can monitor the replication status via transaction R3AM1. The replication is complete if the object is marked with the Done status. If there are any problems during replication, you can access transaction code SMW01 to get details of the error.

We have now gone through the business partner concept and its configuration to replicate it from SAP ECC to the SAP CRM system. Our next focus is the Product Master Data (PRD), its concept and how we replicate it into SAP CRM.

Products are the goods or services that are sold by an organization to customers. A product drives most of the key functionality on the order line item. It consists of different data elements; that is, the basic data is applicable across different functions whereas sales area data is specific to sales. Some attributes can be plant-specific and some can consist of conditions with a price. Any business-relevant data related to the products is stored in the product master and drives the complete order to cash process.

The product type in SAP CRM describes the basic characteristics of a product. There are different types of products in SAP CRM but the most relevant product types in sales transactions are of the Material and Service types.

You can control deactivating the product types based on your business requirements by going to SPRO | Cross-Application Components | SAP Product | Settings for Product Type | Deactivate Product Types.

A technological overview of product master data in SAP CRM is as follows.

Attributes and set types

Set types are the group of fields (attributes) that are assigned to a category. Based on your business scenario, you can create your own set types and attributes. A hierarchy consists of categories and categories consist of set types and attributes. Some standard set types are assigned to the MAT_ base hierarchy, which is inherited by the next level of hierarchies, for example, MAT_HAWA and MAT_FERT.

Categories and hierarchy

A product hierarchy consists of multiple categories and can be created based on your business requirements. Lower-level categories inherit set types from higher-level categories. R3PRODSTYP is the default base hierarchy.

A product can be assigned to only one category within the same hierarchy and set types can be assigned to more than one category within the same hierarchy that belongs to a particular product type, for example, material. The same set type cannot be assigned to a different hierarchy of the material product type.

To download the product hierarchy, run the DNL_CUST_PROD1 customizing adaptor object load. This loads the product hierarchy from SAP ECC to SAP CRM.

The following diagram shows a diagrammatic representation of the Hierarchy, Category, Set Type, and Attribute flow:

Figure 2.16 – Hierarchy, Category, Set Type, and Attribute flow

You create the attribute and set the type via SAP Menu | Master Data | Product | COMM_ATTRSET - Maintain Set Types and Attributes. Figure 2.17 shows an example of an attribute. You assign a value range to attributes while maintaining the attributes:

Figure 2.17 – Defining attributes

The next screenshot shows an example of a set type. A set type has attributes and can be org-dependent. If an attribute is marked as Business Warehouse-relevant, a data source is created for the set type automatically. You also need to mark the set type as Material, Service, Financing, or Warranty. You can also add fields to the UI product view and create UI configurations for set types:

Figure 2.18 – Defining the set type

We have now covered the maintenance of attributes and set types that can be created for the product master and covered the sequential connection of the hierarchy, category, set type, and attribute. Let's now understand relationships within the product master.

Relationships

Products can have relationships maintained in the PRD and those can be accessories, warranties, customer material information records, vendors, components, customers, and so on. The data stored in the relationship of the product master is essentially used in CRM business transactions. There is no customer material information record as separate master data like in the SAP ECC system. The customer material information is a part of the product master relationship. Customer material information can be maintained in the CRM product master relationship and a customer material information record can be loaded via the CUST_MAT_INFO middleware adapter object from ECC to CRM. The customer/distribution chain relationship is updated with the customer material information record from ECC.

The accessories relationship can be used to assign additional products that can be used as a part of product proposals in a transaction. The Customers tab in the product master relationship corresponds to the customer material number. This can be maintained in the product master. Similarly, the Vendors tab in the relationship corresponds to the vendor material number.

Customer-specific relationship types can be defined with the Easy Enhancement Workbench and additional steps are involved to make these visible in the CRM web client UI. Please refer to SAP Note 1139562 in the SAP service marketplace for more information on customer-specific relationships.

Product functions

Product functions such as prices, taxes, material general data, sales area data, and units of measure play an important role when executing different business processes. The following sections cover these product functions in detail.

Prices

Prices are a key element and are used in business transactions such as sales orders, quotations, contracts, and so on based on various combinations in the condition tables, and one of the fields within a condition table is product. Product prices can be viewed on the product master within SAP CRM if the condition maintenance techniques are configured. More details about pricing are discussed in the next topic of this chapter, which gives you an overall idea of the functionality of pricing and how it works within a business transaction.

If you want to use the pricing functionality in the product master, you must assign product-specific condition tables and types to the appropriate condition group in customizing path for Customer Relationship Management, by choosing Master Data | Conditions and Condition Technique | Condition Technique: Basics | Create Maintenance Group.

If you want to use the pricing functionality in the product master, you must assign the condition group to the SAP CRM application in customizing path for Customer Relationship Management, by choosing Master Data | Products | Special Settings for Sales Operations | Assign Condition Group to Application CRM.

If you want to view details of the price calculation, you must enter the PRC_CALC_TRACE user parameter and the X parameter value in your user preferences (transaction SU3).

Taxes

You can view whether a product is taxed in the product master. By assigning a sales tax to a product, you determine how the product is taxed. The details in the tax assignment block are country, region, tax type, and tax group.

Units of measure

You can maintain Base Unit, Sales Unit, Delivery Unit, and Alternate Unit of Measures in SAP CRM as you do in the ECC system. When creating a sales transaction, the Sales Unit of measure is populated by default and if the sales unit of measure is not maintained, then the base unit of measure defaults on the sales transaction.

You can only use base units of measure that have been defined in customizing path in CRM SPRO | SAP Web Application Server | General Settings | Check Units of Measurement.

Sales area data

Sales area data within the product master is shown on the Sales and Distribution tab and contains information specific to sales. You can have multiple sales areas assigned to a product and each of the sales area information on the Sales and Distribution tab can be different. The concept is the same as in the ECC system. When creating a product in SAP CRM, you can assign the sales area manually, whereas if a product is replicated from the ECC system, the data cannot be changed manually. If you want to change an ECC-replicated product, then you need to maintain the set type for the product type in the BAdI: Allow Changes to Product Data configuration.

Product groups and sales groupings, such as volume rebate groups, are maintained in the sales area data. Two set types assigned to the sales area data are CRMM_PR_SALESA (Sales: Control Fields, Quantities) and CRMM_PR_SALESG (Sales: Groupings). You can also enter product sales text that can be determined on the sales order if required based on the text determination procedure.

Material data

Material data of the product is applied at the material level, meaning this data is not dependent on the sales area data or purchasing data. This is similar to the basic data of the material master in the ECC system. Material data consists of Basic Data for Materials, Base Units of Measure, Global Trade Item Number, and Basic text.

The division is maintained in the basic data in CRM whereas in ECC, the material has the division at the sales area level. A division is an attribute in organizational management. If a header division is not used in your system, the division exists only at the item level and is derived from the product data. You specify in Customizing whether a header division is to be used.

The General Item Category group is defined to determine the item category on the sales transaction, for example, NORM.

Global Trade Item Number is used to identify products in CRM business transactions. This can be used as a product determination on sales transactions. The Global Trade Item Number (GTIN) is a 14-digit number that includes various EAN/UCC numbering structures and is used to uniquely identify a product worldwide.

Status management

The status within the product master controls whether you can use the product in a business transaction, whether it is locked, deleted, and so on. The following system statuses are predefined in various central SAP tables for the PRD object type and cannot be changed:

• Locked
• Can Be Archived
• To Archive
• Archived
• Deleted

You can also configure the user status, but it doesn't have any effect on the standard functionality.

Products download

In order to download products successfully, there are pre-requisite steps to download customizing objects for categories and hierarchy. Once the customizing objects are loaded successfully, the following steps need to be carried out before loading the products from ECC to CRM.

Defining number ranges for materials (SAP CRM)

The material number range setting is different from the customer master and it doesn't require a number range definition for replicating materials from the R/3 system to the CRM system. This means that if the categories within the material product type are not assigned to any of the groups containing a number range, then the system will take the number from the R/3 system and automatically create products with the same number in the CRM system. To avoid duplicate numbers when creating materials in both the CRM and ECC systems, it is imperative that the number ranges for materials in the CRM system and the R/3 system do not overlap.

To define the product number range, follow this menu path, Cross-Application Components | SAP Product | Settings for Product Type | Number Assignment | Define Number Ranges, for the Material product type. This will present the following screen:

Figure 2.19 – Defining number ranges for the Material product type

Maintaining number range groups (SAP CRM)

You can assign a number range and group the category IDs within the configuration path mentioned to configure the number ranges. This will be based on your business scenario and what category ID you need to assign to what number range.

The following screenshot shows the number range maintenance for the material product type wherein you can define the number range interval:

Figure 2.20 – Maintaining groups

You can assign a number range to maintained groups and then assign material types to the group. When creating products, the numbers assigned to the material are taken from the group, as shown in Figure 2.21:

Figure 2.21 – Group overview

Defining item category groups (SAP CRM)

To avoid any failure of material load from ECC to CRM, it is necessary to sync the item category group configuration from ECC to CRM. Follow the given path to configure an item category group: SPRO | Customer Relationship Management | Transactions | Basic Settings | Define Item Category Group

Once you are done with the preceding configuration, you maintain the master data adaptor object setting as stated here:

1. Go to transaction R3AC1 and select the MATERIAL business object, and then choose Details (F2).
2. Go to the Filter Settings tab.
3. In the Source Site Name field, choose the site (OLTP).
4. Maintain the filter settings based on your business requirements and save your settings.

Replicating products (SAP CRM)

Once you are done with setting up the Material adaptor object, the next step is to replicate the material from SAP ECC to SAP CRM. The steps to execute the material load are as follows:

1. Go to the SAP CRM menu, and then to transaction R3AS.
2. In the Load Object field, enter MATERIAL.
3. In the Source Site field, enter OLTP, and in the Destination Site field, enter CRM:
   

   Figure 2.22 – Material initial load

4. To run the replication, choose Execute (F8).
5. Confirm the next screen message by choosing Continue.

Monitoring the replication status (SAP CRM)

After initiating the material load, you monitor the load via transaction R3AM1. In the Object Name field, enter the MATERIAL downloaded object to get the download status of this object. The replication is complete if all objects have the status Done.

We have covered the concept of PRD, its various functions, and the replication steps from SAP ECC to SAP CRM. Now that we are well versed in the concept of PRD in the SAP CRM system, let's continue with the pricing concept and see how it works with business transactions.

Pricing in SAP CRM is carried out in business transactions such as quotations, sales orders, contracts, or service processes. Based on the company's requirements, a pricing procedure is created that comprises different condition types, for example, List Price, Discounts, Freight Charges, Rebate condition (if applicable), and Surcharge. While creating a business transaction, the system uses the condition techniques to determine the correct price for the product. Pricing information in SAP CRM can be downloaded from the ECC system or can be created in CRM directly:

Figure 2.23 – Price determination in CRM sales transactions

This diagram shows the flow logic of price determination in the SAP CRM system. The pricing procedure is assigned with condition types; condition types are assigned with an access sequence; an access sequence has condition tables, and you create the condition record for the condition table defined in the Customizing. Price determination in business transactions is based on the sales area, the document pricing procedure assigned to the transaction type, and the customer pricing procedure assigned to the customer master. Let's review the configuration steps to understand how to determine the pricing procedure in business transactions.

Pricing procedure determination

Pricing procedure is determined based on sales area (sales org, distribution channel, and div), customer pricing procedure, and document pricing procedure. The pricing procedure comprises a list of condition types and subtotals based on the business requirements. Routines can be assigned to each of the condition types based on business logic.

The next screenshot shows a pricing procedure determination configuration and the path to configure is SPRO | CRM | Basic Functions | Pricing | Pricing in the Business Transaction | Determine Pricing Procedures:

Figure 2.24 – Pricing procedure determination

Before creating or determining our pricing procedure, condition types, access sequences, and condition tables should be configured or loaded from ECC based on your business requirements. Let's review this setup:

• Condition types: Condition types are the actual price, discounts, surcharges, and so on in the business document. Condition types can be determined automatically, or they can be entered manually. For automatic determination of the condition type, an access sequence should be assigned to it. A condition type can be a group condition, header condition, or item condition.
• Access sequences: The access sequence determines the sequence of the condition tables that determines the condition record for a specific condition type.
• Condition tables: A condition table consists of a list of fields that determines the correct condition type based on the access sequence. An SAP-delivered condition table ranges from 0 to 500 and a customer-specific table ranges from 501 to 999.
• Condition records: These are entries or records based on the condition table and fields. The actual price, discounts, and surcharge are entered in the condition records for a specific period. These are either loaded from ECC or can be maintained directly in CRM.

There are specific steps required to load customer-specific condition records and the maintenance of the condition records in CRM.

Downloading the pricing procedure and condition types

The steps to download the pricing procedure and condition records are as follows.

Defining ECC fields in CRM

To download the condition records, the fields within condition tables in CRM should be in sync with ECC condition tables, meaning if there are certain fields that are not available in CRM, those should be added to load the condition records successfully.

If the ECC fields are not present in the CND_MAPT_ACS_REM structure, they should be added into the CND_MAPT_ACS_REM_CUST structure.

Defining customer-specific fields in the CRM field catalog

A customer-specific field should be added to the field catalog within CRM. These are the list of fields that are going to be accessed to determine the price and once added to the field catalog, they are available in the communication structure of CRM_COND_COM_BADI.

The menu path is Customer Relationship Management | Basic Functions | Pricing | Define Pricing Related Settings | Define Field Catalog.

The following screenshot shows the field catalog wherein you can define additional fields you want to add to determine the prices on the sales transaction. The fields that you create for the condition table should be available in this field catalog:

Figure 2.25 – CRM field catalog

Defining a mapping of fields between CRM and ECC

To map standard fields, SAP has provided the CND_MAPC_CNV_FLM table, wherein you will find the field mapping between CRM and ECC for standard fields with the conversion function module assigned if needed. To maintain the field mapping for custom fields, the CND_MAPM_CNV_FLM table should have the entry of the field mapping as previously and this can be added via the V_CND_MAP_CNVFLD view.

The following screenshot shows an example for the Process_Type field, which is maintained in the CND_MAPM_CNV_FLM table:

Figure 2.26 – The CND_MAPM_CNV_FLM table maintained with Process_Type

Download the customizing object to sync the condition tables and pricing procedure between ECC and CRM.

Once the condition tables with custom fields are created in CRM, you can load the condition tables from ECC to CRM before loading the actual condition records. A pre-requisite step is to open the CRM client so that the custom field and condition tables are replicated correctly. This is done by following these steps:

1. From the SAP CRM menu, go to transaction R3AS and fill in the Load Object field with the DNL_CUST_CNDALL entry.
2. In the Source Site field, enter OLTP, and in the Destination Site field, enter CRM:
   

   Figure 2.27 – Downloading pricing customizing objects

3. To run the replication, choose Execute (F8).
4. Confirm the next screen message by clicking Continue.

Access transaction code R3AM1 to confirm that the customizing load ran successfully. Verify that all the pricing procedures, access sequences, condition types, and condition tables are generated corrected after the download.

Creating condition tables

After the pricing customizing object is downloaded successfully, the next step is to create the condition adaptor objects for the condition tables and then load the condition records by running these condition adaptor objects one by one.

The steps to create the condition adaptor objects for the condition tables are as follows:

1. Go to transaction R3AC5.
2. Create adapter objects for the following condition tables (if the adapter object for the condition table doesn't exist as standard) as a copy of a standard object, say, DNL_COND_A621:
   

Figure 2.28 – Condition adaptor object

Downloading condition records

The steps to execute the condition record download are as follows:

1. Go to transaction R3AS.
2. In the Load Object field, enter ZDNL_COND_A621.
3. In the Source Site field, enter OLTP, and in the Destination Site, enter CRM.
4. To run the replication, choose Execute (F8).
5. Confirm the next screen message by choosing Continue.

Repeat these steps for all the condition adaptor objects to load all the condition records. Once the condition records are loaded and the pricing configuration is completed, the price determination will happen on the CRM business transactions.

The concept of pricing routines in SAP CRM using IPC

The SAP Internet Pricing and Configurator (IPC) is used in CRM to calculate the price of any business transactions, for example, quotations, orders, or contracts. IPC is used in any CRM application, whether it is a Web Channel or Interaction Center application. The routines created in CRM are developed in Java and are assigned to the condition type within a pricing procedure. Downloading the pricing customization takes care of assigning a routine to a condition type if pricing is loaded from ECC.

Once you have carried out all the previous activities, if there are certain custom routines that you have implemented in ECC and you want to create the same routine in CRM, then you need to follow the next steps.

To create a new custom routine, you must have a Java project created in the Eclipse environment. You can refer to the steps on how to download, create your own custom routine, and upload the pricing routine to the SAP CRM environment. This is mentioned in OSS Note 809820 – User exit concept for pricing. You can access the SAP OSS note via the service marketplace (service.sap.com). Based on your environment setup, you can also use NWDI.

Pre-requisites

Pricing a user exit should be compiled with J2SE 1.4.x and it is important that the compiled class files are compatible with JDK version 1.4. The VMC Java environment of SAP BASIS 7.00 does support 1.4 class files and libraries.

You download the routine and upload the JAR file via the /SAPCND/UE_DEV transaction.

Creating PRC_UE_CUSTOMER.jar to upload the user exit

After implementing the specific pricing logic based on the business requirement, you upload the pricing routine to the SAP environment. JAR files are generated through Eclipse, which you upload in the /SAPCND/UE_DEV transaction code. This is shown in the next screenshot:

Figure 2.29 – Uploading a user exit JAR file

Once the user exits are loaded to the SAP system, it is a time to register the routine and the attributes if required in the configuration as mentioned in the following sections.

Overview of different user exit types

The next screenshot shows the different user exit types for usage PR (pricing). These need to be configured based on your requirement and the routines added to the pricing procedure. The transaction code to configure the user exit types is /SAPCND/UEASS.

Any rules based on the user exit type should be added as an implementation and formula. This is shown in the following screenshot, where you can see there are different user exit types:

Figure 2.30 – User exit types

These user exit types are Condition Base Formula, Requirement, Condition Value Formula, and so on. Each of these user exit types can be assigned with implementations and formulas and associated attributes:

Figure 2.31 – User exit type details

On the detail screen of each user exit type, the Scope field and User Exit Interface exist. Options within the Scope field are A number-dependent, B One unique-implementation, or C Multiple-Implementations.

Registering an implementation

Once you have identified which routine belongs to which user exit type, you will need to register an implementation within this step. Here is an example of the REQ user exit type and the attributes assigned to the implementation that is required in the user exit.

The following screenshot shows one of the examples of the DEPARTURE_CTY user exit type being registered for the Requirement user exit type:

Figure 2.32 – REQ user exit type implementations

The next screenshot shows the attribute assigned to the user exit type named DEPARTURE_CTY. This attribute is passed via a pricing communication structure to VMC to calculate the prices on the sales transaction line item:

Figure 2.33 – User exit attributes

Assigning implementations to a formula

After defining the implementation for the user exit type, the next step is to assign the formula. The customer formula extends from 600 to 999 and the number is the same as what is being assigned in the pricing procedure. Each user exit type must have a formula number assigned to it as shown:

Figure 2.34 – Formulas assigned to the user exit

Attributes assigned

The next screenshot shows tax departure city as one of the attributes assigned that is used to determine the price for the condition type:

Figure 2.35 – Attributes assigned to the formula

After going through all the configuration steps, it is necessary to reset VMC (transaction code SM53) and run the IPC_DET_CLEAR_CUST_BUFFER IPC buffer program to make your changes effective. In the CRM SMOFPARSFA table, you can control the pricing redetermination in ECC for CRM orders by adding the entry for PRICINGTYPE with the pricing indicator, for example, pricing indicator G is set for reprising tax in ECC when the sales orders are replicated from CRM to ECC.

Verifying routines loaded to SAP CRM

You can verify routines in SAP CRM that are loaded via /SAPCND/UE_DEV. Access transaction code VMCJDB and double-click on dbsources as highlighted:

Figure 2.36 – Virtual machine container mini debugger

You will see the list of the routines you have uploaded to the SAP CRM system under the list of Java source files located in the database. Double-click on one of the routines to view the Java source file.

We have covered the pricing master data concept, that is, the configuration to determine the price on the business transaction, configuration required to communicate pricing to the Virtual Machine (VM) container, and download pricing from SAP ECC to SAP CRM. Now that we have covered business partners, products, and pricing, let's continue to understand how vendors work in SAP CRM.

Vendors are created in ECC and can be loaded to CRM based on your business requirements. Vendors are an integral part of the order to cash transaction when it comes to third-party sales orders. When products are not available in the organization's warehouse, then the sourcing is executed via a third-party vendor. In typical CRM sales order scenarios, a customer service representative might need vendor information if it is a third-party sales order and therefore it becomes imperative to determine the correct vendor on the CRM sales order. For vendor determination, you need to load vendors into the CRM system. In CRM, these vendors are created as a business partner in the BBP000- Vendor role when downloaded from ECC.

Downloading vendors

Downloading vendors from ECC to CRM requires some pre-requisite steps, which are stated as follows.

CRM settings

The following steps are performed in CRM settings:

1. Activate the VEND_MWX_CREATE_MAIN_BDOC function. In transaction SM31, the CRMC_BUT_CALL_FU table for the business partner outbound of business partner objects and the VEND_MWX_CREATE_MAIN_BDOC function must be active.
2. Activate the VEND_MAIN and VENDOR_MAIN adaptor objects. In transaction R3AC1, the VEND_MAIN and VENDOR_MAIN adapter objects must be active. A filter for each role of role category vendor must be set for the VEND_MAIN object.
3. Create a subscription for vendors in SMOEAC. In transaction SMOEAC (admin console), there will be a subscription for the All Vendors publication to the ECC system (site). For example, you can specify All Vendors (MESG) as the subscription's name:
   

   Figure 2.37 – Vendor subscription in SMOEAC

4. Creation of Business Partner Grouping for Vendors: In this step the business partner grouping for vendors is created by activating the external grouping and assigning the Number range to the grouping. The Number range should be same as the ECC vendor number range.

   Figure 2.38 shows the activation of external grouping and the Number range getting assigned to grouping:

Figure 2.38 – Vendor business partner grouping

SAP ECC settings

Like the settings and the steps executed in SAP CRM to set up vendors, you need to execute the settings in the SAP ECC system. These are as follows:

1. Activate PI_BP_PROXY_BAPI_VENDOR: Within transaction SM31, the COM_BUPA_CALL_FU table for R/3 object inbound processing (time R3OBI) of vendor records (object VEND), the PI_BP_PROXY_BAPI_VENDOR function must be active, and the PI_BP_PROXY_BAPI_CUST_VEND function must not be active.
2. Settings in the CRMSUBTAB table: In transaction SM31, the CRMSUBTAB table for user CRM, the COM_VEND_MAIN_INBOUND function should be active for the VEND_MAIN object of the BUPA class for upload. The PI_BP_VENDOR_MAIN_EXTRACT function should be active for the VENDOR_MAIN object of the VEND class for download.
3. Settings in the PIDV table: In the PIDV transaction, maintain the mapping between the CRM role categories for vendors (usually role category BBP000) and the corresponding ECC account group as shown in Figure 2.39 and Figure 2.40.

   The next screenshot shows the mapping of the account group to the business partner role category from R/3 to CRM, that is, the data flow from SAP ECC to SAP CRM:

Figure 2.39 – Assignment of the account group to the business partner role category

The next screenshot shows the mapping of the business partner role category to the account group from CRM to R/3, that is, the data flow from SAP CRM to SAP ECC:

Figure 2.40 – Assignment of the business partner role category to the account group

By default, Business Documents (BDOCS) of the VEND_MAIN type are sent in the SAP CRM system for all CRM business partners as soon as you activate the distribution function in the CRM_BUT_CALL_FU table for VEND_MWX_CREATE_MAIN_BDOC. This is a mandatory step to load the vendors in CRM.

Vendor download in CRM – R3AS

After all the previous activities, vendors are downloaded using the R3AS transaction in CRM:

Figure 2.41 – Vendor initial load via R3AS

Now that we have covered the concept of the vendor master and understood the exact settings required to download the vendor from SAP ECC to SAP CRM, our next topic is plant settings and the concept of how to utilize a plant as a business partner in SAP CRM.

The concept of a plant doesn't exist in SAP CRM as there is no inventory maintained in the SAP CRM system. Inventory management is executed in the SAP ECC system. A plant is maintained as a business partner in SAP CRM. A plant is the logistical organizational unit where the products are manufactured and stored. An availability check of any product is based on the plant wherein the ATP check happens, and the transfer of requirement occurs from CRM to APO. For the system to use the number range of the plant when downloading the plant, the internal standard grouping should be activated against the plant grouping entry. Also, CRM doesn't have storage locations and a shipping point. The storage location and shipping points are determined in ECC when the orders are replicated from CRM to ECC.

Within CRM, a plant is created as a business partner and is mapped to the plant in ECC or APO based on where the availability check happens. The plant business partner is termed as location mapping to plant in ECC or APO in the CRMM_LOCMAP table. You can download a plant by executing the following steps:

1. Create number ranges for the plant – transaction code BUCF.
2. Define a grouping and assign number ranges using the following menu path: SPRO | Cross-Application Components | SAP Business Partner | Basic Settings | Number Ranges and Groupings | Define Grouping and Assign Number Ranges.
3. Run transaction R3AS for the DNL_PLANT object.

These steps will create the business partner with the role plant and will map the location to the plant in ECC or APO in the CRMM_LOCMAP table.

The plant setting topic provides information as to how a plant is created as a business partner in SAP CRM; the adaptor object to load the plant and the mapping table updating in the CRM system. With this section of the chapter, we have covered each and every element of master data in SAP CRM.

In this chapter, we went through SAP CRM master data: the organizational model, business partners, products, pricing, plants, and vendors. This chapter forms the basis of the sales process within SAP CRM and it is necessary before understanding transaction processing in SAP CRM. With this chapter, you have got a good understanding of how to set up master data and configure the system to replicate data from the SAP ECC system to CRM.

Organization data, business partners, and products form the basis of all transactions. Any issue with this data has an impact downstream and causes hindrance to the order to cash cycle. This chapter gave appropriate information to minimize and reduces risk related to master data and to make sure you understand the details around the setup.

This chapter also built a foundation for the remaining chapters in this book. The next chapter is about master data in SAP APO, where we will cover the master data including location, plant, and resource master that plays a role in the order fulfillment process while business transactions are processed in the SAP CRM system.

• Additional information related to CRM organizational management can be found in the SAP Help documentation at https://help.sap.com/viewer/b90203d3616f482ebd9776775ac722d8/7.0.4.15/en-US/9e0682c5fb4744fe95cc4e7b669d67bb.html.
• Information on the concept of the business partner and details can also be found at https://help.sap.com/viewer/b90203d3616f482ebd9776775ac722d8/7.0.4.15/en-US/48b3d5a903d0356be10000000a421937.html.