Business Partner approach: Customer Vendor Integration to Business Partners (CVI)
Customer Vendor Integration, it is a pre-requisite to migrate to S/4HANA. This means that the ECC t-codes to maintain customers and vendors (FK01/02/03, FD01/02/03, XK01, etc.) will disappear, and customers and vendors will be maintained through BP t-code, as Business Partners.
This takes place in a system conversion from SAP ECC to S/4HANA system, as the vendors and customers need to be synchronized as BP. In a greenfield installation, customers and vendors will directly be created as BP.
Business Partner is not a new concept for S/4HANA. It is a relevant object for SAP FSCM solution and CRM. In this case to maintain vendors and customers, acts as a shell to maintain customer and vendor tables.
Business Partner approach neither exists since S/4HANA. It was an option available before. The synchronization means that when you update a customer with t-code XD02 the changed will be reflected in the BP and vice versa, if you do a change using t-code BP, it will be reflected in XD02. The big change with S/4HANA as we said, is that the old t-codes will no longer be available so it is mandatory to migrate to BP.
Of course that having this new objects, makes relevant new tables, but the important thing is that the old tables for vendors and customers still exists (LFA1, KNA1, etc.). Again, it is a shell to maintain vendors and customers. This means that the programs pointing to old customer/vendor tables will not be affected.
Why SAP does this?
* There are redundant object models in the traditional ERP system. Here the vendor master and customer master is used. The (mandatory) target approach in SAP S/4HANA is the Business Partner approach (Customer-Vendor Integration [CVI]).
*Business Partner is now capable of centrally managing master data for business partners, customers, and vendors. With current development, BP is the single point of entry to create, edit, and display master data for business partners, customers, and vendors.
*The specific tables for customer data (KNA1) and vendor data (LFA1) remain available and are not impacted.
As summary of the process:
1.Archive obsolete vendors and customers. This is highly recommended as will reduce the quantity of customers, vendors to be synchronized. (In some projects it is not possible as the company does not have the archiving procedure set for customers and vendors). All non archived objects, will need to be synchronized as the installation process will check that.
2.Analyze the ranges. It is recommended that Business Partner ID and Vendor/Customer ID are the same, but this is not always possible as in SAP ECC is normal that customers and vendors have overlapping in ranges. You must plan the new ranges numbers if overlapping exists.
2.Implement pre-checks, Activate Business Functions and Perform customizing.
3.Execute the Mass Data Synchronization program.
4.If data errors appear (and trust me, they will), be prepared to execute a data cleansing process.
5.Re-execute the synchronization cockpit until everything is synchronized.
*Business Partner roles:
The synchronization will create the BP with 2 roles for each object:
- For customers: FI Customer and Customer
- For vendors: FI Vendor and Vendor
One corresponds to the FI area and the other one to the sales/purchasing area.
In my experience, performance of the program is not great. For a small number of customer/vendors will not be a problem, but if you have hundreds of thousands of employee/vendors it can be an issue. However, increasing the number of parameter “Max. Processes”, the performance will improve.
For example, if you change this parameter to 10, the program will parallelize the batch execution, improving the timing. Of course this must be tested to find the optimal size as might depend on your system architecture settings.
When there are ranges overlapping and you need to pick how to maintain vendors or customers numbers, SAP recommends to maintain customers as usually sales and customers are more important for companies than vendors (of course, companies prefer to send invoices and collect money than pay them).
Useful information about table mappings
I strongly recommend this blog from an author that describes really well the configuration required
This document offers a great description of the technical process to perform the customzing. It is applicable to 1610 too.