Business Partner and customer-vendor integration (CVI)

One object instead of two

In ECC a partner that was both customer and supplier existed twice (XD01 and XK01). In S/4HANA the Business Partner (BP) is the single entry point: transaction BP or the Fiori apps replace XD01/XK01, and the old transactions redirect to BP.

Category is fixed at creation. Grouping drives the number. Roles decide which customer or supplier data exists.

The BP tables

Central data is stored once, however many roles the partner has. Query it through CDS views (I_BusinessPartner and friends) where you can.

Shared data is maintained once and reused by every role.

Roles and the tables they create

Assigning a role makes CVI write classic tables. FI roles bring company-code data; FLCU01 and FLVN01 bring sales-area or purchasing-org data. A 'missing sales area' is almost always a missing FLCU01 role or org data, not a CVI bug.

KNA1 or LFA1 is written by whichever customer or supplier role arrives first.

Try it: roles to tables

Try it · Match

Match each BP role to the organisational-level data it adds.

Pick an item on the left, then its match on the right.

How CVI synchronises

In S/4HANA the leading direction is BP to customer/supplier, in the same unit of work as the BP save. The pairing lives in CVI_CUST_LINK and CVI_VEND_LINK: without a link row, the BP has no customer even if a matching KNA1 row exists.

Step through · 1 of 6

A BP is saved from transaction BP, a Fiori app, the API_BUSINESS_PARTNER OData service, MDG activation or a Migration Cockpit load. All roads end in the same BP save logic.

One save, two worlds updated.

Number ranges and groupings

In the CVI IMG you assign each BP grouping to a customer and vendor account group and decide whether numbers are the same. Same numbers need aligned external ranges and get hard when an existing customer also becomes a supplier. Decide before the first mock load; changing it later means reloading.

Where CVI breaks

Conversion tools: CVI_COCKPIT for the phases, MDS_LOAD_COCKPIT for mass synchronisation, MDS_PPO2 for failed records, and report CVI_FS_CHECK_CUSTOMIZING for customising gaps.

Most CVI errors are configuration or mapping gaps, not program bugs.

Try it: a mock load fails

Try it · What would you do?

Mock load 2: about 4% of customers fail with 'number already exists'; the other 96% load fine. What do you check first?

The conversion journey

On brownfield, every customer and vendor needs a BP before conversion, so CVI starts months early. On greenfield, the Migration Cockpit Customer and Supplier objects create BPs and CVI writes the classic tables, so the same configuration matters.

Brownfield CVI phases, as the CVI cockpit structures them.

BP in the MDG replication flow

In co-deployed MDG, activation writes the BP and CVI writes KNA1/LFA1. DRF then replicates the BP (typically BusinessPartnerSUITEBulkReplicateRequest, or DEBMAS/CREMAS IDocs), and the receiver runs CVI again. Its configuration must match the hub's.

CVI runs in the hub and again in each receiver. Monitor both.

Try it: order the replication

Try it · Put in order

Put the steps of an MDG BP change, from request to receiver, in order.

1CVI in the hub writes KNA1 / LFA1
2Receiver's inbound processing runs CVI
3MDG activates the BP in the hub
4DRF sends the BP message to the receiver
5Steward submits the change request
6Workflow routes it for approval

Remember

BP is the only entry point; customer and supplier are roles of a BP.
CVI maps BP to KNA1/LFA1 and dependent tables, linked in CVI_CUST_LINK / CVI_VEND_LINK.
Fix the number strategy before the first mock load; CVI runs again in every receiver.

Check yourself

Which role adds purchasing organisation data (LFM1) to a BP?

A KNA1 row exists, but the BP shows no customer role data. What is the most likely cause?

What is the leading synchronisation direction in a running S/4HANA system?

MDG activates a BP successfully, but a receiving S/4 system rejects it. Where do you look first?