Run implications: maintaining business partners after go-live

After conversion, the direction of CVI reverses: the business partner leads, and CVI updates the customer and supplier records from it. That changes daily work for everyone who maintains master data, and it changes some integration and authorization designs. Plan these changes as part of the project, not as a surprise in hypercare.

Post-conversion customizing

• Activate synchronization from BP to customer and BP to vendor; deactivate the old direction.
• Activate post-processing office monitoring for the new direction.
• Map BP groupings to customer and vendor account groups, including whether the customer or supplier number equals the BP number.
• Adjust number ranges; in SAP's example the BP range becomes internal and customer and vendor ranges external, so numbers stay equal.
• Test by creating a BP with customer and supplier roles and checking the numbers and records.

SAP's training uses transaction BP_CVI_IMG_CHK in SAP S/4HANA as a guided procedure for these settings. Do them first in the converted development system, keep them in transports, and move them with the conversion of quality and production, so each converted system is ready the moment SUM finishes.

People, roles and authorizations

Users who maintained customers in XD01 now work in a different transaction with a different structure: roles, groupings, general data shared across roles. Maria's order-to-cash team and Ana in accounts payable need training on BP before user acceptance testing, not after go-live. Authorization roles must be rebuilt for BP maintenance; a role that let a sales user maintain customer sales data must not now let them change supplier bank details on the same BP.

Governance needs an owner too. Decide who may create BPs, with which groupings and roles, and how duplicates are prevented, because one BP can now serve several departments. Contoso assigns master data ownership to a small central team, with order-to-cash and procurement requesting changes through a simple workflow, and keeps the daily PPO check in that team's job description.

Negative tests prove the design. In CMQ, Priya’s team logs on with a sales test user, opens Lakeside Components (17300001), and tries to change its bank details, add a supplier role and change the company code data. Each attempt must fail with an authorization message; for the Fiori apps, the failed check is traced with STAUTHTRACE rather than SU53. The same user must still be able to change the sales area data of a customer. Store the messages as evidence; Nadia, Contoso’s security and GRC lead, signs the result.

Integration

The BP approach item notes that the DEBMAS and CREMAS IDocs are not recommended for data integration between SAP S/4HANA systems, because BP leads; business partner web services are the suggested route, and IDocs remain sensible when the other side only knows customers or suppliers. Contoso's CRM interface, deactivated during the load, needs its own regression test after conversion, and SAP points to specific notes for landscapes where SAP CRM business partners must be mapped to the BPs created by CVI.

The model also shapes later data loads. In Contoso's Wave 2, the 1,946 in-scope customers of Alternadores del Norte, including Flotillas Monterrey S.A. de C.V., are loaded into the converted system as business partners for company code 1910, with roles and groupings decided upfront. The CVI decisions made now define how that load is designed.

For Wave 2, the load uses the SAP S/4HANA Migration Cockpit through the Migrate Your Data app (F3473), whose customer and supplier migration objects create business partners with their roles in one step. The groupings, roles and number ranges defined for the converted system are the targets the mapping must hit, and the same completeness and data checks from lesson 4 apply to the 1,946 records.