SAP S/4HANA Business Partner – CVI - Handling of old data which is not archived yet

[Andi_M]

Introduction

Very often when I initiate a Customer/Vendor Integration (CVI) conversion pre-project, I encounter old data that often makes the CVI conversion challenging. At this point, project members mention that they had considered archiving the data, but due to missing time, the archiving project did not start yet.

In this blog post, I want to present an alternative solution to archiving if archiving is not possible at this point of time. The goal is to move all old master data to dedicated "rubbish" account groups like Z999. For the CVI conversion of these account groups, master data checks can be switched off using a BAdI implementation. The advantage of this approach is to have a separated dataset of old data assigned to the account group Z999. By using separate account groups and internal number ranges, the CVI mapping can be much easier due to the usage of Business Partner (BP) grouping. This setup can also be reused at a later point in time for archiving.

ATTENTION: It is crucial to note that all mass change activities (Account Group changes, Master Data changes) must be done BEFORE CVI activation.

 

Create Z999 Account Groups

Customer

Create a custom account group (e.g., Z999)

with a maximum setup:
- Set all fields to optional
- Assign all partner functions

Create a Customer Account Group:

Go to IMG: Financial Accounting -> Accounts Receivable and Accounts Payable -> Customer Accounts -> Master Data -> Preparations for Creating Customer Master Data -> Define Account Groups with Screen Layout (Customers)

Switch off master data checks:
Usually, old master data contains invalid data like postal codes, tax numbers, etc. To handle this, you can switch off master data checks based on the functionality found in the following customizing setting:
IMG -> Master Data Synchronization -> Customer/Vendor Integration -> Activate Field Check Suppression

In this case, we will ignore this customizing setting and switch off all mentioned master data checks.

5. BAdI BUPA_INBOUND:
Create a custom BAdI implementation for BAdI BUPA_INBOUND with the following coding (example). Importantly, restrict this implementation to your Z999 Business Partner Grouping, as this BAdI is a central point in Business Partner handling and is used in all Business Partner activities.

 

Set Field Status:

Ensure that all fields are set to Optional.

 

Create and assign a dummy number range:

Go to IMG: Financial Accounting -> Accounts Receivable and Accounts Payable -> Customer Accounts -> Master Data -> Preparations for Creating Customer Master Data -> Create Number Ranges for Customer Accounts

Go to IMG: Financial Accounting -> Accounts Receivable and Accounts Payable -> Customer Accounts -> Master Data -> Preparations for Creating Customer Master Data -> Assign Number Ranges to Customer Account Groups

 

Assign Partner Functions (Partner Determination):

Go to IMG: Sales and Distribution -> Basic Functions -> Partner Determination -> Set Up Partner Determination -> Set Up Partner Determination for Customer Master
- Assign all available Partner Functions to your new Account Group

 

Create a new Partner Determination Procedure and assign all Partner Functions:

Supplier

Follow the same steps as for the Customer Account Group and Partner Determination setup. Pay attention to name the Supplier Partner Determination Procedure ZV99 to avoid naming conflicts.

Create a Supplier Account Group:

Go to IMG: Financial Accounting -> Accounts Receivable and Accounts Payable -> Supplier Accounts -> Master Data -> Define Account Groups with Screen Layout (Vendors)

Create a custom account group (e.g., Z999) with a maximum setup:

- Set all fields to optional
- Assign all partner functions

Assign Partner Functions (Partner Determination):

Go to IMG: Materials Management -> Purchasing -> Partner Determination

Create Z-Reports for Mass Account Group Change

Based on the function modules CUSTOMER_CHANGE_ACCOUNTGROUP (for customers) and VENDOR_CHANGE_ACCOUNTGROUP (for vendors), create custom Z-Reports to perform mass changes of account groups.

Here is an example coding for mass changing the Customer Account Group:

*&---------------------------------------------------------------------*
*& Report Z_MASS_KTOKD
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT Z_MASS_KTOKD.

TYPES: BEGIN OF ty_customer,
          kunnr TYPE kna1-kunnr,
          ktokd TYPE kna1-ktokd,
        END OF ty_customer.

data: lt_customer TYPE TABLE OF ty_customer,
      ls_customer TYPE ty_customer,
      lv_subrc    TYPE sy-subrc.

SELECT-OPTIONS: s_kunnr for ls_customer-KUNNR.

PARAMETERS:            p_ktokd     TYPE kna1-ktokd.

SELECT kunnr from kna1 INTO CORRESPONDING FIELDS OF TABLE lt_customer
  where kunnr in s_kunnr.

LOOP at lt_customer INTO ls_customer.
  ls_customer-ktokd = p_ktokd.

  CALL FUNCTION 'CUSTOMER_CHANGE_ACCOUNTGROUP'
    EXPORTING
      IV_CUSTOMER                    = ls_customer-kunnr
      IV_ACC_GROUP                   = ls_customer-ktokd
     IV_ALLOW_NEW_REQUIRED          = 'X'
     IV_ALLOW_NEW_SUPPRESSED        = 'X'
     IV_ALLOW_WRONG_NUMBER          = 'X'
*   TABLES
*     ET_NEW_REQUIRED_FIELDS         =
*     ET_NEW_SUPPRESSED_FIELDS       =
   EXCEPTIONS
     CUSTOMER_NOT_FOUND             = 1
     SAME_ACCOUNTGROUP              = 2
     NO_AUTHORITY                   = 3
     NEW_REQUIRED_FIELDS            = 4
     NEW_SUPPRESSED_FIELDS          = 5
     CHANGE_NOT_ALLOWED             = 6
     WRONG_ACCOUNTGROUP             = 7
     WRONG_NUMBER                   = 8
     INTERNAL_ERROR                 = 9
     CUSTOMER_LOCKED                = 10
     OTHERS                         = 11
            .

  lv_subrc = sy-subrc.
  CASE lv_subrc.
    WHEN 0.
        COMMIT WORK.
*   implement your success message here
    WHEN OTHERS.
*   Implement suitable error handling here
  ENDCASE.

ENDLOOP.

Select your old/outdated customer and vendor numbers based on you own custom criteria.

Mass change of account groups to Z999

Post Processing after Account Group change

To avoid legal entity merge (customer + supplier -> single BP) you have to decouple customer and vendor.

Customer

Clear KNA1-LIFNR

Do a mass change of customers using transaction XD99.

Supplier

Clear LFA1-KUNNR

Clear LFB1-PERNR

Do a mass change of customers using transaction XK99.

CVI Setup

Create a Business Partner number range for old Customers and Suppliers:

Go to IMG: Cross-Application Components -> SAP Business Partner -> Business Partner -> Basic Settings -> Number Ranges and Groupings -> Define Number Ranges

Create a Business Partner Grouping for old Customers and Suppliers:

Go to IMG: Cross-Application Components -> SAP Business Partner -> Business Partner -> Basic Settings -> Number Ranges and Groupings -> Define Groupings and Assign Number Ranges

Set up CVI mapping:

Customer

Go to IMG: Master Data Synchronization -> Customer/Vendor Integration -> Business Partner Settings -> Settings for Customer Integration -> Define BP Role for Direction Customer to BP

Go to IMG: Master Data Synchronization -> Customer/Vendor Integration -> Business Partner Settings -> Settings for Customer Integration -> Field Assignment for Customer Integration -> Assign Keys -> Define Number Assignment for Direction Customer to BP

Supplier

Go to IMG: Master Data Synchronization -> Customer/Vendor Integration -> Business Partner Settings -> Settings for Vendor Integration -> Define BP Role for Direction Vendor to BP

Go to IMG: Master Data Synchronization -> Customer/Vendor Integration -> Business Partner Settings -> Settings for Vendor Integration -> Field Assignment for Vendor Integration -> Assign Keys -> Define Number Assignment for Direction Vendor to BP

Switch off master data checks

Usually, old master data contains invalid data like postal codes, tax numbers, etc. To handle this, you can switch off master data checks based on the functionality found in the following customizing setting:
IMG -> Master Data Synchronization -> Customer/Vendor Integration -> Activate Field Check Suppression

In this case, we will ignore this customizing setting and switch off all mentioned master data checks.

BAdI BUPA_INBOUND

Create a custom BAdI implementation for BAdI BUPA_INBOUND with the following coding (example). Importantly, restrict this implementation to your Z999 Business Partner Grouping, as this BAdI is a central point in Business Partner handling and is used in all Business Partner activities.

  method IF_EX_BUPA_INBOUND~CHECK_BEFORE_INBOUND.
    data:           lv_flag           TYPE boolean.

    lv_flag = abap_true.

    check c_bp_central_data-common-data-bp_control-grouping = 'Z999'.

      "Tax numbers check supression
        CALL FUNCTION 'SKIP_TAX_NUMBER_CHECK'
          EXPORTING
            ix_check_deactivate = lv_flag.

        CALL FUNCTION 'SKIP_CUSTOMER_TAX_NUMBER_CHECK'
          EXPORTING
            ix_check_deactivate = lv_flag.

        CALL FUNCTION 'SKIP_EU_TAX_NUMBER_CHECK'
          EXPORTING
            ix_check_deactivate = lv_flag.

        "API to supress Regional check
        CALL FUNCTION 'ADDR_SUPPRESS_REG_DATA_CHECK'
          EXPORTING
            suppress_reg_data_check = lv_flag
          EXCEPTIONS
            parameter_error         = 1
            OTHERS                  = 2.

        " suppress address postal code checks
        CALL FUNCTION 'ADDR_SUPPRESS_POSTALCODE_CHECK'
          EXPORTING
            suppress_postalcode_check = lv_flag
          EXCEPTIONS
            parameter_error           = 1
            OTHERS                    = 2.

        " supress tax juridiction code checks
        CALL FUNCTION 'ADDR_SUPPRESS_TAXJURCODE_CHECK'
          EXPORTING
            suppress_taxjurcode_check = lv_flag
          EXCEPTIONS
            parameter_error           = 1
            OTHERS                    = 2.

        "suppress bank checks
        CALL FUNCTION 'SKIP_BANK_DETAILS_CHECK'
          EXPORTING
            ix_check_deactivate = lv_flag.


  endmethod.

Testing

Now, let's test the setup with an example customer to illustrate how this solution works.

Change Account Group

Display Customer

To display current customer please run transaction XD03.

Mass Change

To change the Account Group, run the Z-Report Z_MASS_KTOKD and change Customer Account Group to Z999. 

Display Customer after Account Group change

Delete field KNA1-LIFNR via transaction XD99

Activate CVI

Activate CVI for the direction Customer -> Business Partner
Go to IMG: Cross-Application Components -> Master Data Synchronization -> Synchronization Control -> Synchronization Control -> Activate Synchronization Options

CVI Conversion

After completing all the preparation steps, you can convert your Customers to Business Partners using the Synchronization Cockpit (MDS_LOAD_COCKPIT), starting from the CVI Cockpit.

Check Synchronization status before conversion

Run Transaction CVI_LINKS to check the synchronization status of the customer.

Run CVI Conversion

Run transaction MDS_LOAD_COCKPIT directly or from CVI Cockpit.

Check conversion Monitor

 

Check Synchronization status after conversion

Run Transaction CVI_LINKS to check the synchronization status of the customer.

Conclusion

As a result, you have separated your old data into a specific Account Group and a specific Business Partner Group. With this solution, users and reporters can easily identify whether data is outdated or relevant.