I am S/4HANA evangelist and support customers on their HANA journey. Recently I completed a project for S/4HANA conversion and through this blog series I want to take you through my project life-cycle; How to start, plan and execute; What to keep in mind and watch out for. This is topic #4 of 10 part blog series.
As you are proceeding to further read this blog series, it means you have decided that in-place system conversion is the right option for you and you have executed and resolved the SI Pre-Checks and are ready to synchronize CVI.
In my experience, CVI is perceived as one of the top barriers for system conversion and even more because it is a prerequisite for SUM DMO (one of the SI Pre-Check). In my experience, in a system conversion project where master data harmonization is not a mandate and Business Partner is created 1:1 for each customer / supplier, this is not as complex an activity as it is perceived to be. Reasons for that are 1) CVI architecture which minimizes the business impact, 2) SAP CVI Cockpit that is one stop shop for all synchronization activities and 3) suppress check framework that allows you to suppress (configurable) few data related issues e.g. Tax Code, Postal Code, Email, Bank Data, Tax Jurisdiction, Industry, Transportation Zones etc.
Lets deep dive further. Business Partner is the leading object in S/4HANA across all areas whereas in some cases it is still linked to the ECC entities (synchronized at real-time) and in other cases the functionalities have been re-designed completely to directly use Business Partner in the design e.g. AR and AP will continue to use customer and supplier for transactions but the master data for customer and supplier cannot be maintained directly (secondary entity) and will be done using BP TCode, whereas Credit Management will directly maintain all the credit related data in Business Partner related DB tables. So, it is important to identify all the areas that will use Business Partner in your system (like Banks, Customer, Suppliers, Credit Accounts, Contact Persons, Employee Vendors, Employees, Credit Processors etc) as it might impact the CVI design (e.g. if you are using employee and they need to be synchronized with employee vendors then you can only use 2 character BP group though max 4 characters are allowed).
While it is important to identify all the areas that will use Business Partner in S/4HANA, only CVI is mandatory before SUM DMO. Rest of the design is done post S/4HANA conversion. So we will focus only on CVI in the below sections of this blog (rest will be part of mandatory innovations TOPIC 08). CVI is 'Customer Supplier Integration' that allows you to integrate customer/supplier objects with business partners and keep them in sync at real-time. This architecture gives you following advantages:
Activities Before SUM DMO
Conversion of customers and suppliers to Business partner is one of the SI Pre-Checks and unless completed, SUM DMO cannot be executed. Thus CVI activation must be done in ERP system before SUM DMO and BP activation can be done either before or after. This creates 3 approaches for CVI activation:
Approach 1: Implement completely within SAP ECC prior to SAP S/4HANA
Approach 2: Implement as part of SAP ECC at every stage of the SAP S/4HANA conversion
Approach 3: Implement partially within SAP ECC prior to SAP S/4HANA with no impact to end users (recommended)
Before you start CVI activities, please read the CVI cookbook and SI Note (do check the attachments too) as it will save you time later.
During the SI Pre-Checks, system might identify issues with address number. Programs provided in OSS Note 1158803 & 1070798 can be used to fix those data inconsistencies. This is in addition to the master data issues that will be identified later.
For CVI activation, the next activity to be performed is to execute the programs PRECHECK_UPGRADATION_REPORT and CVI_MIGRATION_PRECHK to do the number range analysis and master data analysis (this helps to proactively identify issues that you might face during the CVI synchronization) respectively. SAP recommends to setup CVI in such a way that the new Business Partner number is same as the old customer/supplier number (but it is not mandatory; you can have Business Partner with a number different than customer / supplier). So during the analysis, if it is identified that there is an overlap of number range between customer and supplier then a decision has to be taken to ascertain which entity will retain the same number for Business Partner and which entity will have a new number range for Business Partner (Business Partner can only have single number range hence 1 Business Partner cannot be mapped to 2 different entities as 'Same Number' design). Also note:
Other important consideration for the BP design is to decide the usage of new attributes like BP Type, BP Group & BP Role (as per SAP design, BP Group controls the number range and BP role controls the field status groups). 2 design options are available:
While Business Partner has a few new attributes like BP Group, BP Type, BP Role, rest of the attributes and configurations are same as customer/supplier. Other than number range configuration and the configuration for the new entities, everything else is retained as 1:1 as is.
CVI requires separate configuration for customer/supplier to Business Partner synchronization and separate configuration for business partner to customer / supplier synchronization. It is recommended that both the configurations are completed in ECC itself and only the synchronization direction change is done in S/4HANA.
CVI Synchronization Cockpit (old tool CVI_UPGRADE_CHECK_RESOLVE, new tool CVI_COCKPIT with tracking and monitoring) helps with the same.
Other points to note:
Once the Business Partner Configuration and the master data cleanup is complete, you are ready to start the CVI synchronization (which will actually create the Business Partner for each customer / supplier including its contact persons and update the link tables).
CVI Synchronization executes MDS_LOAD_COCKPIT (it is the Master Data Synchronization cockpit and used by entities that are registered with it; Business Partner is one such entity). I recommend:
As CVI synchronization is background process, if the Business Partner update fails when customer / supplier is updated in ERP or customer / supplier update fails when Business Partner is updated, a Post Processing Order (PPO) is created and can be assessed via MDS_PPO2 transaction (I suggest creating a small utility to analyze the MDS_PPO2 messages for ease of analysis later). Once the error(s) are resolved, the PPO order is not automatically removed but has to be manually marked as 'Complete'. This could be a time consuming process during CVI activation where thousands of orders could be generated. Report /SAPPO/CLOSE_ORDERS_2 can be used for mass closure of PPOs.
It is also observed that during the CVI synchronization, some inconsistencies may appear in the link tables (Business Partner created but link missing or the link is present but the business partner is not created) and SAP provides you with cleanup programs via notes 1958471, 0974504 and 2373665 which must be executed before you rerun the CVI Cockpit for unsynced records.
Once CVI activation is complete (Execute TCode CVI_FS_CHECK_CUS_ENH -> CVI Synchronization -> Complete; this reactivates the suppressed checks hence must be done before productive use of the system), SI Pre-checks are executed again for validation. Please note if you have some configuration/data maintained in non-production clients as well, SI Pre-Checks will continue to show a few warnings for those clients (e.g.SI2: MasterData BP_CHK_CON_ASSIGNMENT_04_W, SI2: MasterData BP_CHK_POST_CON_ASSIGNMENT_04_W ) and they can be ignored. You cannot exempt them as the error code is not 7.
Activities After SUM DMO
While one can follow approach 1 (mentioned above) and complete both CVI synchronization and BP activation in ECC, I recommend to activate CVI in current ECC system and activate BP in S/4HANA. Reason being a lot of enhancements and BP features towards customer / supplier use in BP are only available in S/4HANA and those changes are not back-ported to ECC (yet) hence you will face issues while using BP in ECC. So the synchronization direction change must be done in S/4HANA that will make BP as the leading object.
If you use custom fields in customer / supplier tables, you will need to enhance BP transaction code using BDT and XO to add those fields to the BP screen (BDT) and allow the update back to the customer / supplier DB tables (XO) (Refer to BP Screen Enhancement Cookbook in the OSS Note 2309153 attachments). In my experience, BDT and XO are very stable and mature frameworks and will allow you to retain your current screen design from customer / supplier sub-screens to BP sub-screens without any enhancement or core code modification. To achieve this, custom sub-screens and BDT/XO objects are created (like sub-header ID, Data Set, Field Group, View, Section, Screen, Screen Sequence, Screen Category, and Function Modules that will hold the actual sub-screen and its logic). While BDT allows you to create a separate custom application to plug-in the new sub-screens, I noticed issues with its integration with SAP sub-screens hence I recommend to add the custom sub-screen to SAP application CVIC / CVIV itself.
Security design of BP is mostly same as customer's / supplier's with the exception of sensitive fields (wherein ECC field authorization groups work on exclusion criteria, S/4HANA field authorization groups work on inclusion criteria hence will require custom development). Also in S/4HANA all the old customer / supplier transaction codes redirects the user to BP transaction code.
From change management perspective, you will need to train your business users to use BP transaction code. This is a single transaction code which replaces 50+ customer / supplier transactions in ECC. Also a new concept of 'Application Transaction Code' is introduced in S/4HANA wherein you can create specific transaction codes to allow certain roles only (SPRO -> SAP Business Partner -> Business Partner -> Basic Settings -> Business Partner Roles -> Define Application Transactions).
In TOPIC 05 we will discuss "Executing SUM DMO".
As you are proceeding to further read this blog series, it means you have decided that in-place system conversion is the right option for you and you have executed and resolved the SI Pre-Checks and are ready to synchronize CVI.
In my experience, CVI is perceived as one of the top barriers for system conversion and even more because it is a prerequisite for SUM DMO (one of the SI Pre-Check). In my experience, in a system conversion project where master data harmonization is not a mandate and Business Partner is created 1:1 for each customer / supplier, this is not as complex an activity as it is perceived to be. Reasons for that are 1) CVI architecture which minimizes the business impact, 2) SAP CVI Cockpit that is one stop shop for all synchronization activities and 3) suppress check framework that allows you to suppress (configurable) few data related issues e.g. Tax Code, Postal Code, Email, Bank Data, Tax Jurisdiction, Industry, Transportation Zones etc.
Lets deep dive further. Business Partner is the leading object in S/4HANA across all areas whereas in some cases it is still linked to the ECC entities (synchronized at real-time) and in other cases the functionalities have been re-designed completely to directly use Business Partner in the design e.g. AR and AP will continue to use customer and supplier for transactions but the master data for customer and supplier cannot be maintained directly (secondary entity) and will be done using BP TCode, whereas Credit Management will directly maintain all the credit related data in Business Partner related DB tables. So, it is important to identify all the areas that will use Business Partner in your system (like Banks, Customer, Suppliers, Credit Accounts, Contact Persons, Employee Vendors, Employees, Credit Processors etc) as it might impact the CVI design (e.g. if you are using employee and they need to be synchronized with employee vendors then you can only use 2 character BP group though max 4 characters are allowed).
While it is important to identify all the areas that will use Business Partner in S/4HANA, only CVI is mandatory before SUM DMO. Rest of the design is done post S/4HANA conversion. So we will focus only on CVI in the below sections of this blog (rest will be part of mandatory innovations TOPIC 08). CVI is 'Customer Supplier Integration' that allows you to integrate customer/supplier objects with business partners and keep them in sync at real-time. This architecture gives you following advantages:
- You can continue to use customer and supplier numbers in Sales Order and Purchase Order respectively
- Because of integration, both old and new data models remain active in S/4HANA which means that any interface or custom code using KN*/LF* tables will not require any change. This also means that some of the common fields like name, address, bank, credit cards, tax numbers are duplicated between Business Partner and customer/supplier and rest of the details are directly stored in customer/supplier DB tables. BDT (Business Data Toolset) and XO (Extensible Objects) are the two supporting frameworks that enable this real-time synchronization and support custom fields as well (custom fields must be added to the Business Partner screen for end user data maintenance).
- Any custom fields in KN*/LF* tables will remain in the same table and will not be moved to Business Partner tables.
- 2 way integration between customer/supplier provides you with the flexibility to implement CVI in ECC production system (much before the S/4HANA conversion) and continue to use customers / suppliers. Switch to use Business Partners will be done in S/4HANA (approach 3 below).
- In a system conversion where the expectation is to setup Business Partner as 1:1 with customer/supplier design, SAP provides you with tools that allow you to copy the config as is from C/V to BP. Starting Oct 2019 they have launched CVI Cockpit that consolidates all the required CVI activities in one transaction.
- It is also understood that you might not be archiving your customer / supplier master data on regular basis or might have 'marked for deletion' records thus would not like to go through intensive exercise of data cleanup for those records ( or even for active master data). CVI Synchronization provides suppress check framework wherein you can 'suppress' the checks for few identified fields (SPRO Activity and additional checks can be suppressed via BADI implementation).
Activities Before SUM DMO
Conversion of customers and suppliers to Business partner is one of the SI Pre-Checks and unless completed, SUM DMO cannot be executed. Thus CVI activation must be done in ERP system before SUM DMO and BP activation can be done either before or after. This creates 3 approaches for CVI activation:
Approach 1: Implement completely within SAP ECC prior to SAP S/4HANA
Approach 2: Implement as part of SAP ECC at every stage of the SAP S/4HANA conversion
Approach 3: Implement partially within SAP ECC prior to SAP S/4HANA with no impact to end users (recommended)
Before you start CVI activities, please read the CVI cookbook and SI Note (do check the attachments too) as it will save you time later.
During the SI Pre-Checks, system might identify issues with address number. Programs provided in OSS Note 1158803 & 1070798 can be used to fix those data inconsistencies. This is in addition to the master data issues that will be identified later.
For CVI activation, the next activity to be performed is to execute the programs PRECHECK_UPGRADATION_REPORT and CVI_MIGRATION_PRECHK to do the number range analysis and master data analysis (this helps to proactively identify issues that you might face during the CVI synchronization) respectively. SAP recommends to setup CVI in such a way that the new Business Partner number is same as the old customer/supplier number (but it is not mandatory; you can have Business Partner with a number different than customer / supplier). So during the analysis, if it is identified that there is an overlap of number range between customer and supplier then a decision has to be taken to ascertain which entity will retain the same number for Business Partner and which entity will have a new number range for Business Partner (Business Partner can only have single number range hence 1 Business Partner cannot be mapped to 2 different entities as 'Same Number' design). Also note:
- This does not mean any change to existing customer/supplier or existing transactions. Instead the link between the new Business Partner and old customer/supplier is maintained in a table and MDS_LINKS transaction can be used to find the relationship. In summary, NO impact to business.
- It is recommended that post S/4HANA conversion, the number range for the customer/supplier where Business Partner has a different number range, is changed to match. As this is for future master data, it will again have minimal business impact.
Other important consideration for the BP design is to decide the usage of new attributes like BP Type, BP Group & BP Role (as per SAP design, BP Group controls the number range and BP role controls the field status groups). 2 design options are available:
- Using the existing configuration of Customer / Supplier Account Group for field group setting in BP transaction code (refer to OSS Note 2516606). Please note, this is applicable for existing customer / supplier fields only and for the new BP fields, you will need to use the new BP field groups. (Recommended if you only use customer / suppliers in S/4HANA and are ok with minor changes but it will lead to complexities if you use customer / supplier as well as other entities in Business Partners)
- Using the approach of 1:1 replication of account group vs BP Grouping/Role and then design everything in BP. (Recommended if you want like for like behavior in S/4HANA using the BP configuration attributes).
While Business Partner has a few new attributes like BP Group, BP Type, BP Role, rest of the attributes and configurations are same as customer/supplier. Other than number range configuration and the configuration for the new entities, everything else is retained as 1:1 as is.
- Customer/Supplier to Business Partner Mapping : Data Assignment for C/V/CP, Bank Details, Payment Cards, Form of Address, any Default Values for Sync (C/V to BP)
- Contact Person : Department / Functions / Authority or Power of Attorney / VIP Status / Marital Status / Legal Form / Payment Cards / Industries
CVI requires separate configuration for customer/supplier to Business Partner synchronization and separate configuration for business partner to customer / supplier synchronization. It is recommended that both the configurations are completed in ECC itself and only the synchronization direction change is done in S/4HANA.
CVI Synchronization Cockpit (old tool CVI_UPGRADE_CHECK_RESOLVE, new tool CVI_COCKPIT with tracking and monitoring) helps with the same.
Other points to note:
- If you wish to link the inter-company customer and supplier to the same Business Partner, refer to OSS Note 2363892. If implemented, it is mandatory to maintain the same address, bank details, credit cards and tax numbers for both customer and supplier linked to the same Business Partner.
- If employee vendors exist in your system, ensure that the respective Business Partners are created with BP Type 'Person'. Refer to FAQ OSS Note 2713963.
- If SD credit management is active in your system and the sold-to parties are already converted to BP for UKM000 BP role then these records will be skipped during the CVI synchronization and you will have to extend the customer / supplier roles for the Business Partner using the BAPI BAPI_BUPA_ROLE_ADD_2.
Figure 1: Activating CVI in ECC before S/4HANA Conversion
Once the Business Partner Configuration and the master data cleanup is complete, you are ready to start the CVI synchronization (which will actually create the Business Partner for each customer / supplier including its contact persons and update the link tables).
CVI Synchronization executes MDS_LOAD_COCKPIT (it is the Master Data Synchronization cockpit and used by entities that are registered with it; Business Partner is one such entity). I recommend:
- Use the 'Test Run' option (available since August 2019 for BUPA object) to identify potential data issues before actually creating the Business Partners.
- For optimized performance, this program has 2 features:
- Block Size: How many records should be processed in 1 packet; this does not have much impact towards the online execution (except for program memory if a large # of records are to be converted).
- Max (parallel) Processes: How many processes can be executed in parallel; this option is only available if 'Background Processing' is chosen. Please note that it actually uses 'Dialog' work processes and not 'Background' so ensure that you have sufficient number of dialog work processes available. If you use a different application server for critical jobs, you can choose the same via 'Server Group'. Parallel processes can be monitored via SMQ2 queues.
I recommend the parallel processing option while executing the CVI synchronization with number of processes based on 3000 records per process (e.g. if you have 30,000 customers in account group ABCD, you choose 10 'Max Processes') and setup the queue by account group with unique queue name (MDS_BUPA_<Account Group>). Delete the old/stuck queues for MDS* from SMQ2 before starting the new queues. Benchmark the CVI execution time based on the queue processing time(s).
While SAP suggests that MDS_LOAD_COCKPIT can be executed live on the production system, I recommend it to be executed over the weekend with limited system activity and customer / vendor maintenance transactions locked to avoid 1) failures due to locked objects and 2) inconsistencies in production transactions due to suppressed checks (if chosen to be activated).
As CVI synchronization is background process, if the Business Partner update fails when customer / supplier is updated in ERP or customer / supplier update fails when Business Partner is updated, a Post Processing Order (PPO) is created and can be assessed via MDS_PPO2 transaction (I suggest creating a small utility to analyze the MDS_PPO2 messages for ease of analysis later). Once the error(s) are resolved, the PPO order is not automatically removed but has to be manually marked as 'Complete'. This could be a time consuming process during CVI activation where thousands of orders could be generated. Report /SAPPO/CLOSE_ORDERS_2 can be used for mass closure of PPOs.
It is also observed that during the CVI synchronization, some inconsistencies may appear in the link tables (Business Partner created but link missing or the link is present but the business partner is not created) and SAP provides you with cleanup programs via notes 1958471, 0974504 and 2373665 which must be executed before you rerun the CVI Cockpit for unsynced records.
Once CVI activation is complete (Execute TCode CVI_FS_CHECK_CUS_ENH -> CVI Synchronization -> Complete; this reactivates the suppressed checks hence must be done before productive use of the system), SI Pre-checks are executed again for validation. Please note if you have some configuration/data maintained in non-production clients as well, SI Pre-Checks will continue to show a few warnings for those clients (e.g.SI2: MasterData BP_CHK_CON_ASSIGNMENT_04_W, SI2: MasterData BP_CHK_POST_CON_ASSIGNMENT_04_W ) and they can be ignored. You cannot exempt them as the error code is not 7.
Activities After SUM DMO
While one can follow approach 1 (mentioned above) and complete both CVI synchronization and BP activation in ECC, I recommend to activate CVI in current ECC system and activate BP in S/4HANA. Reason being a lot of enhancements and BP features towards customer / supplier use in BP are only available in S/4HANA and those changes are not back-ported to ECC (yet) hence you will face issues while using BP in ECC. So the synchronization direction change must be done in S/4HANA that will make BP as the leading object.
If you use custom fields in customer / supplier tables, you will need to enhance BP transaction code using BDT and XO to add those fields to the BP screen (BDT) and allow the update back to the customer / supplier DB tables (XO) (Refer to BP Screen Enhancement Cookbook in the OSS Note 2309153 attachments). In my experience, BDT and XO are very stable and mature frameworks and will allow you to retain your current screen design from customer / supplier sub-screens to BP sub-screens without any enhancement or core code modification. To achieve this, custom sub-screens and BDT/XO objects are created (like sub-header ID, Data Set, Field Group, View, Section, Screen, Screen Sequence, Screen Category, and Function Modules that will hold the actual sub-screen and its logic). While BDT allows you to create a separate custom application to plug-in the new sub-screens, I noticed issues with its integration with SAP sub-screens hence I recommend to add the custom sub-screen to SAP application CVIC / CVIV itself.
Security design of BP is mostly same as customer's / supplier's with the exception of sensitive fields (wherein ECC field authorization groups work on exclusion criteria, S/4HANA field authorization groups work on inclusion criteria hence will require custom development). Also in S/4HANA all the old customer / supplier transaction codes redirects the user to BP transaction code.
From change management perspective, you will need to train your business users to use BP transaction code. This is a single transaction code which replaces 50+ customer / supplier transactions in ECC. Also a new concept of 'Application Transaction Code' is introduced in S/4HANA wherein you can create specific transaction codes to allow certain roles only (SPRO -> SAP Business Partner -> Business Partner -> Basic Settings -> Business Partner Roles -> Define Application Transactions).
In TOPIC 05 we will discuss "Executing SUM DMO".
- SAP Managed Tags:
3 Comments
