Skip to Content

Business Partner Data Cleansing

Business Partner Data Cleansing

Table of Contents

1.Business Partner Data Cleansing – Introduction

2.Customizing to set up Merge

     a) What needs to be defined in CLEARING and what needs to be defined in CLEAR_REP?

     b) What is the significance of defining the nodes in CLEARING and CLEAR_REP?

     c) Customizing for BP_REALIGN background task

     d) What will happen after START is pressed and how to execute the background job immediately?

     e) What is the result once the background job is set to finished state?

3.Improvements in enhancement packages

     a) How to maintain Merge Customizing after Upgrade?

     b) Merge Account based on Variants

4.UI Behavior

     a) When the Merge Accounts button will be enabled?

     b) When the datasets will appear on the UI?

     c) Behavior of Check Boxes in the UI

     d) Error messages while creating Cleansing Case

     e) What is the UI Behavior once Confirm button is pressed?

     f) What happens to the Address-Dependent communication data?

     g) Behavior of different data sets  in the UI

          i. Main Address (node CRM010)

          ii. Non-Main Address (node BUP010)

          iii. Business Transactions (node CRM370)

          iv. Bank Data (node BUP310)

          v. Marketing Profile (CRM390)

5. Important Notes

1. Business Partner Data Cleansing

Data cleansing allows you to compare, include and merge redundant business partner master records (potential duplicates) in data cleansing cases. When the data cleansing process has been completed, you can remove data records from the system using archiving. From the search result list for accounts or employees, choose Merge Accounts or Merge Employees. Alternatively, a duplicate check can determine that an account is possibly duplicate. Click Merge Now begin the process of merging data immediately or click Merge Later to process a cleansing case later.

In the list of records within a cleansing case, set the status Master for the record that you want to retain. By default, one record is defined as the master record, but you can change this setting. All records with the status Source are automatically marked for archiving.

The comparison shows only the data that differs between the selected records, and where a decision is therefore required as to which data should be retained. Select the individual pieces of data that you want to retain, either from the master or source record.

Depending on the Customizing settings, the data will be visible in the Referenced Data section. The nodes available under CLEARING variant will be available in Web Ui under reference data section and the nodes available under CLEAR_REP will not be visible in the Referenced Data assignment block. Data that is not visible is merged automatically by the background task, whereby data from the master record is retained in case of conflicts. Click Confirm to confirm the changes you have made before continuing, or click Cancel to reverse your changes. Enter a date and time for the background merge. Click Start to start the merge at the specified time.

2. Customizing to set up Merge

a) What needs to be defined in CLEARING and what needs to be defined in CLEAR_REP? What is the significance of defining the nodes in CLEARING and CLEAR_REP?

Nodes which have to be seen on the UI have to be configured in the CLEARING variant.

Exception: Address-dependent communication data, Contact person's work address & associated communication data, Employee's work address & associated communication data are not available for selection on the UI.

- Nodes which can be merged via a background job have to be configured in the CLEAR_REP variant. Usually, it is recommended to configure nodes which have the possibility of high data volumes in this variant.

- Nodes that are maintained as part of the CLEAR_REP variant are automatically processed as part of the batch job called BP_REALIGN, irrespective of whether the same nodes are maintained in the CLEARING variant. For more details on customizing of BUPA_REALIGN refer Customizing for BP_REALIGN background task

- With the introduction of note 1707913, it is also possible to define your own variants in BUSWU02, and use these variants for deciding which nodes will be merged via the background job and which nodes will be displayed on the UI. More details refer Merge Account based on Variants.

b) Customizing for BP_REALIGN background task

Step 1: Action Profile Configuration (transaction CRMC_ACTION_CONF)

Double-click on ‘Task (for Business Partners)’:

Overview:

Processing Details:

Step 2: Action Profile Definition (transaction CRMC_ACTION_DEF)

a) Double-click on the BP_TASK action profile, and make sure the following data are maintained:

b) Double-click on ‘Action Definition’, and make sure the following data are maintained:

c) Double-click on ‘Processing Types’ , and make sure the following data are maintained:

Step 3: IMG customizing (transaction SPRO)

a) Implementation Guide -> Customer Relationship Management -> Transactions -> Define

Transaction Types: Execute

b) Create a Z transaction type by copying it from standard transaction type 1003, for example.

c) ‘Definition of transaction types’

Maintain the following data:

• Short Text

• Description

• Inactive (No selection)

• Action Profile = BP_TASK

• Other mandatory fields

d) Double-click ‘Assignment of Business Transaction Categories’:

e) Double-click ‘Customizing Header’

c) What will happen after START is pressed and how to execute the background job immediately? What is the result once the background job is set to finished state?

On clicking the START button on the UI,

- a background job is created and scheduled - the user executing the merge should have the authorization to:

a) execute ABAP programs & schedule the program to run as a background job. Refer to documentation of authorization object S_PROGRAM

b) release background jobs. Refer to documentation of authorization object S_BTCH_JOB

  Please refer notes 1628694, 1727030, 1752260 related to authorization object required for cleansing.

- the cleansing case is set to status 'Completed'

- the cleansing case is saved (on save, the BAdI CRM_BP_UIU_SAVE is called)

- control passes back to the Account Search view, with the message "Accounts have been merged."

When the background job has status 'Finished',

- Check the application log (transaction SLG1) for object COM_CLEAR. If there are no errors in the application log, the accounts were merged successfully. In case of any errors the source account will not be flagged for archiving.

- The source account(s) will be flagged for archiving and will now have a relationship "is replaced by" (BUR013) with the target account

- The target account will have all the data that was selected for merge on the UI and will also contain the data moved by the CLEAR_REP variant.

Once the Start button is pressed, a background job will be created and this can be viewed using transaction SM37. The background job will be executed based on the Start Date and Start Time maintained under scheduled Merge in the Cleansing case. In case if you have to execute the background job immediately irrespective of the date and time maintained in the cleansing case please follow the following steps

Select the Job and click on Job->Change

Click on Start condition

Click on Immediate and Click on Save Button

Again click on Save button and it will take you to the Job Overview where you can check the status of the Job

Additional Info: In case if you want to debug the Background Job please follow the steps as shown below

1. Get the corresponding GUID for a cleansing case number from DB table comm_clear_stack.

2. Check whether the guid is present in CRMM_BUPA_MERGE

3. Keep a breakpoint in report CRM_BUPA_REALIGNMENT

4. Execute the report with the GUID fetched from the table comm_clear_stack

5. The breakpoint kept in report will get hit and from there you can continue the debugging.

3. Improvements in enhancement packages


a) How to maintain Merge Customizing after Upgrade?
The customizing in transaction BUSWU01 and BUSWU02 will be lost after an upgrade.
Current Solution:

Customers need to implement note 1512517:

1. Download text files attached to the note
(text files includes the table entries TBZ5, TBZ5F and TBZ5T needed in CRM system)
2. Create report attached to the note in tr. SE38
3. Execute report: The report reads the text files and updates TBZ5, TBZ5T and TBZ5F accordingly

The report deletes the existing entries in TBZ5, TBZ5F and TBZ5S (also the entries customer namespace).

New Solution:

To avoid the manual steps 1 and 2, two new database tables and a report are delivered by SAP CRM ( in the existing package CRM_BUPA_CLEARING)

• Customizing tables:

CRMC_TBZ5 S-Table with the fields of TBZ5
CRMC_TBZ5F S-Table with the fields of TBZ5F

• Report CRM_BUPA_TBZ5_UPDATE calls function module  CRM_BUPA_TBZ5_UPDATE

• Function module CRM_BUPA_TBZ5_UPDATE:

• Authority check (user has authority to execute transaction BUSWU01)
• Write sys log entry
• Table entries in TBZ5, TBZ5S and TBZ5F with OBJAP = ‘BUPA’ and a node name in SAP namespace are deleted
• TBZ5 and TBZ5F are updated with the entries of CRMC_TBZ5 and CRMC_TBZ5F

After an upgrade or an support package import, the customer needs to execute the report CRM_BUPA_TBZ5_UPDATE, which repairs the customizing. The report does not remove the nodes in customer name space.

Nodes in Customer Name Space:

The SAP nodes will be reset to standard by executing report CRM_BUPA_TBZ5_UPDATE. After this it has to be checked, if the customer nodes have a consistent parent / brother (RELATKEY). If there are nodes with identical RELATKEY and RELATSHIP, only one of these nodes will be displayed in BUSWU01. Therefore we have to update the RELATKEYand RELATSHIP of customer nodes. This is implemented in the sub routines PROCESS_TBZ5_CUST_NODES and PROCESS_TBZ5F_CUST_NODES. After executing the report the customer nodes will be typically at the end of the list in tr. BUSWU01 and BUSWU02.

PS: Check note number 1702041 for more details.

PS : This report and database tables are available only from CRM 7.0 EHP1 onwards

b) Merge Account based on Variants

The customer can decide in transaction BUSWU02 which data should be merged in the user interface (variant CLEARING) and which data should be merged in background processing (variant CLEAR_REP). Because the variants CLEARING and CLEAR_REP belong to the SAP namespace, all changes done in these variants will be lost after an upgrade.

For that reason, the customer should have the possibility to create own variants in customer name space and to define that these variants should be used in the BP merge.

A new customizing is implemented where the customer can maintain which variants are used in the merge user interface and in the background processing.

New customizing structure in IMG (CRM -> Master Data -> Business Partner):

Define Data Entities for Selection in Cleansing Variants:

In this Customizing activity, you check the set of data entities that are available for data cleansing (merging of duplicate accounts and employees) and add any customer-specific entities that you have defined. The data entities are organized in a tree structure that shows the technical objects representing the data entities.

Define Variants for Data Cleansing:
• In this Customizing activity, you create variants that determine the data entities processed during data cleansing for accounts and employees. If you do not create your own variants, the standard variants CLEARING (for data merge with user interaction) and CLEAR_REP (for data merge in the background) will be used.
You can create variants that determine which data entities are relevant for the following procedures:
• Automatic merging of data records in the background (without user interaction)
• Checking by the business user prior to merging (display on the WebClient UI of the cleansing case)
Business users can check conflicts and differences for these data entities and select which piece of data will be transferred to the master data record during the merge.

Select Variant for User Interaction and for Background Processing:
In this activity, you can specify which cleansing variant is used for the following:
• Checking by the business user prior to merging (display on the Web Client UI of the cleansing case)
• Automatic merging of data records in the background (without user interaction)
If you do not specify a variant, the predefined variants are used as follows:
• CLEARING (for data merge with user interaction)
• CLEAR_REP (for data merge in the background)
If you want to use customer-defined cleansing variants, you have defined them in the activity “Define Variants for Data Cleansing”.


BAdI: Determination of Variant for Data Cleansing:
You can use this BAdI in data cleansing for accounts and employees, to determine which data entities are shown in the cleansing case Web Client UI and which are merged in the background, dependent on the attributes of the cleansing case.
For example, if you merge employee records and want to reduce the amount of data that needs to be checked by the user, you can use this BAdI to determine a variant for background processing, dependent on the business partner role.
For more details check the documentation available in SPRO.


BAdI: Checks Prior to Data Merge:
You can use this BAdI in data cleansing for accounts and employees to implement customer-specific checks prior to creation of a cleansing case. You can create multiple implementations of the BAdI to have multiple checks.
The BAdI is called when a business user clicks Merge Accounts (or Merge Employees) in the account (employee) search results list (Web Client UI).
For more details check the documentation available in SPRO.
PS: Using the customizing “Select Variant for User Interaction and for Background Processing” the variants for data merge with user interaction and for data merge in the background can be defined. But these variants cannot be changed based on the Role of the business partner. But using the BadI maintained in customizing “BAdI: Determination of Variant for Data Cleansing” different variants can be used for different Business Partner with different Roles. For Example Employee can be merged with variant, other Accounts can be merged with another variant.  Please check the note 1716680 and 1707913 for more details on using custom variants.

4. UI Behavior


a) When the Merge Accounts button will be enabled?
The ‘Merge Accounts’ button will be enabled on the result list only if:
• At least two accounts are selected
• If the following authorization is assigned to the user:
OBJECT 'B_CLEAR'  (CASE_TYPE = D, ACTVT = 16)
(Refer to notes 1116984, 1607725 and 1781310 for details).


b) When the datasets will appear on the UI?
If a data set should be displayed on the UI, then the corresponding node should be present only in the CLEARING variant. If a data set is present in both the CLEARING and the CLEAR_REP variant, then the data set will not be shown on the UI.

c) Behavior of Check Boxes in the UI
• All items which are checked (on Target and/or Source) should later be visible in the Target account and all unchecked items should not be visible in the Target account.
• All checked items of the Source will be copied to the Target (they will be available in the Target account) and will not be deleted from the Source.
• All checked items of the Target will stay there (they will be available in the Target account).
• All unchecked items of the Source account will not be copied to the Target, and will not be deleted from the Source.
• All unchecked Items of the Target account will get deleted from the Target account.
• After clicking on the ‘Confirm’ button, the data that is still available to be merged from the source to the master account is checked again.


d) Error messages while creating cleansing case
Sometimes once the accounts are selected from the search result list and Merge accounts is pressed the cleansing case popup will open up with error messages. These error messages will be irrelevant to the cleansing case. This error messages displayed will be from some business transaction. Note 1796095 will solve this problem.
In some cases while clicking on the Start button in the cleansing case an error message “Cannot be saved” will get displayed in the UI. This is because when the start button is pressed ORDER_SAVE BAdI implementation will be called in order to create a background job. If there is any problem in the ORDER_SAVE BAdI then such error messages will be displayed. In that case the customer implementation needs to be checked. Similarly if any error messages/Exception occur while clicking on the Save button there could be some problem in the in the implementation of CRM_BP_UIU_SAVE BAdI.

e) What is the UI Behavior once Confirm button is pressed?

Disappearance/Non-appearance of data sets: If, after clicking on ‘Confirm’, the value of a data set is the same on both the source and the master, then the data set is no longer shown on the UI.

Example 1
Master account has a role ‘Sold-to-Party’. Source account has a role ‘Bill-to-Party’.

If both master role and source role are checked and then ‘Confirm’ is clicked, then the role of the source will be copied to the master, i.e., the master will both ‘Sold-to-Party’ and ‘Bill-to-Party’ roles, and the source will have role ‘Bill-to-Party’. After ‘Confirm’, since the role ‘Bill-to-Party’ exists in both the master and the source, this will not be shown on the UI. Only the role ‘Sold-to-Party’ will be shown on the master.

Example 2
Master account does not have a role. Source account has a role ‘Payer’.

If both master role and source role are checked and then ‘Confirm’ is clicked, then the role of the source will be copied to the master, i.e., the master account will have role ‘Payer’ and the source account will also have role ‘Payer’. After ‘Confirm’, since the role ‘Payer’ exists on both the master and the source, the dataset will disappear from the UI.

Note: The behavior of the Roles (BUP200) also applies to some other nodes like Sales (CRM350), Shipping (CRM320), Billing (CRM340) and Blocking Reasons (CRM130).

f) What happens to the Address-Dependent communication data?

Address-dependent communication data are not displayed on the UI. However, when an address is moved from the source to the master, all its dependent communication data are also moved (refer to note 1259396).


g) Behavior of different data sets  in the UI
Consider the case when all nodes relevant for cleansing are configured in the CLEANSING variant. This means that all nodes will be visible on the UI (with the exception of communication data, and data that is the same in both the source and the target).
Depending on the data set being merged, the UI behavior will differ.


For Main Address (node CRM010):


The main address of the source account is unchecked by default. If the main address needs to be merged to the target account, the corresponding checkbox should be checked explicitly.

Checking the main address at the source account will uncheck the main address at the target account:

After clicking on ‘Confirm’:

The main address of the target is overwritten by the main address of the source.

For non-Main Address (node BUP010):

If a non-main address should not be merged to the target account, the corresponding checkbox should be unchecked at the source account.

Business Transactions (node CRM370):

All business transactions are moved from the source to the master. This allows for the following possibilities

1. Business transactions at the Source account are checked, and business transactions at the Master account are unchecked.

In this case, when the ‘Confirm’ button is clicked, the Source business transactions are no longer visible on the UI. These are moved to the Master. The business transactions at the Master account are not changed; they are retained at the Master account.

After ‘Confirm’:

2. Business transactions at the Source account are checked, and business transactions at the Master account are also checked.

In this case, when the ‘Confirm’ button is clicked, the source business transactions are no longer visible against the Source account on the UI. They are moved to the master. The business transactions at the Master account are not changed; they are retained at the Master account.

After ‘Confirm’:

Later, when the cleansing case is saved and opened again, we will be able to see the business transactions at the target:

Note: The behavior of the business transactions node (CRM370) also applies to some other nodes like Installed Base (CRM140), Claims (SPL010), Document (CRM150), and Account classification(BUP240).

Bank Data (node BUP310):


1. Bank data at the Source account are checked, and bank data at the Master account are unchecked.

In this case, when the ‘Confirm’ button is clicked, the bank data of the source account are no longer visible on the UI. These are copied to the master. The bank data of the master account are removed, and the data of the source account is now assigned to the master account.


When opening the cleansing case the data is selected at both the source account and the master account:

Unchecking the data at the master account:


After clicking ‘Confirm’ (the bank data set is no longer visible):

After the case is saved and executed, the bank data of the source account is now available in both the Source account and in the Master account.


2. Bank data at the Source account are checked, and bank data of the Master account are also checked.

In this case, when the ‘Confirm’ button is clicked, the bank data of the source account is shown on the target account, as well as retained on the source account



After the case is saved and executed, the target has both its own bank data, as well as the bank data of the source account. The bank data of the source account is retained at the source.


Note: The behavior of the bank data (BUP310) also applies to Tax Numbers (BUP320).

Marketing Profile (CRM390):


Only the attribute set will be displayed, the individual attributes in the attribute set are not displayed. The same multi-valued attribute set is maintained in both the master account and the source account, but with different values for the attribute. Initially, the data is checked in both the source account and the master account.


The marketing attributes at the master account are unchecked, and the attributes at the source account are unchecked.



After ‘Confirm’, the values of multi-valued attribute set are appended to the master account. The values of the attribute set at the source account are retained.
For single-valued attributes, if the attribute set in the master account is unchecked, and the attribute set in the source account is checked, then the values of the master account are not changed. The source account still retains its single-valued marketing attribute.


Note: The behavior single-valued attributes also applies to the merge of unique identification numbers (BUP450).

5. Important Notes

1056406 - Merge accounts: Deletion of referenced data

1259396 - Merge Accounts: communication data

1057080 - Merge accounts: deletion of notes

1049358 - Merge accounts: two addresses are kept

1796855 - To Be Archived checkbox is enabled in Merge popup

1789126 - Order block reason is not transferred from source to master

1781310 - Merge button is enabled without authorization

1767481 - Error when merging two Accounts with different languages

1752260 - Issue with authorization object S_BTCH_ADM during merge

1749295 - Error while canceling Merge of a newly created account

1727822 - Merge: Description of Order Block Reason is incorrect

1726612 - Notes are not merged while running a cleansing case

1716680 - Merge BP's: use customer variants for batch and dialog

1712376 - Merge of Marketing Permissions in Data Cleansing

1707913 - Determination of Variants when Merging Business Partners

1702041 - BP Merge: Entries in BUSWU01 lost after Upgrade

1689809 - New Business Transactions are created while merging accounts

1685201 - Cleansing/Merge WebUI: Marketing Permissions (7.03)

1651404 - Merge: Changed by field in a transaction holds wrong value

1650777 - Exception CX_BOL_EXCEPTION while merging accounts

1644150 - Exception CX_SY_MESSAGE_IN_PLUGIN_MODE raised during merge

1641992 - Not possible to merge accounts with same industry sector

1634033 - Merge Accounts: BAdI CRM_BP_UIU_SAVE not called on save

1625006 - Cleansing case: Merge account buffer issue.

1618443 - Incorrect Navigation on Creating a Cleansing Case & dumps

1613269 - Exception in Merge Accounts

1608478 - Account Merge does not work in the WebUI

1606854 - Account Merge: Main Address data is getting deselected.

1598187 - Merge : Appearance of wrong Target Group Entries

1596577 - Authorization for Account Merge

1582901 - Error when merging accounts with identical Empl. responsible

1556823 - Error msg while trying to merge identical sales area data

Tags:
Former Member