Business Partner as Single Customer Vendor Master

Classic ECC behaviour

S/4HANA behaviour

Project impact

• Every existing customer and vendor master record needs a CVI mapping run before the technical upgrade; records that fail mapping (duplicate tax IDs, missing required fields, inconsistent address data across customer and vendor versions of the same company) block the conversion outright, not just a warning.
• Custom ABAP that reads KNA1 or LFA1 directly for master data still runs technically after conversion but can silently diverge from the BP data, because updates now flow through BP first; reports built on old joins start showing stale or partial data.
• Interfaces and middleware (EDI, IDoc-based customer/vendor creation, third-party CRM feeds) that create master data via the old BAPIs either stop working or create records that are technically valid but functionally incomplete because CVI role assignment did not fire correctly.
• Authorisation objects change: access previously controlled purely by customer/vendor authorisation objects now also depends on BP authorisation objects, so users who could maintain vendors before conversion may find themselves locked out post go-live until roles are extended.
• End users lose XD01/XK01 muscle memory; master data maintenance moves to BP transactions or Fiori apps, and anyone maintaining data through batch input or LSMW scripts built around the old transaction codes needs those rebuilt.
• Month-end and dunning runs that rely on customer/vendor account groups mapped to specific number ranges can break if BP number range configuration was not aligned with legacy number ranges during the CVI setup.

Migration actions

• Run the CVI pre-check tooling against the ECC system well before the planned conversion window, not the week before, because remediation of duplicate or conflicting master data takes far longer than the check itself.
• Resolve duplicate tax numbers, duplicate bank details, and address inconsistencies between customer and vendor versions of the same legal entity; these are business decisions (which address is correct) as much as technical fixes.
• Define and freeze the BP number range strategy relative to existing customer and vendor number ranges before any data is converted, since retrofitting number ranges after BPs exist is disruptive.
• Identify every custom program, interface, and batch job that creates or changes customer/vendor master data directly, and redirect them to BP-based creation logic (or the CVI-aware equivalents) ahead of go-live.
• Rebuild authorisation roles to include the BP authorisation objects alongside the legacy customer/vendor ones, and test with real end users, not just basis-level access checks.
• Run at least one full-volume test conversion in a sandbox with production-like master data volumes; CVI mapping issues that look trivial on a hundred records can multiply into thousands of blocking errors at production scale.

Whose problem this is

Common pitfalls

• Teams assume CVI is a one-time technical step run during the conversion weekend, then discover mid-cutover that thousands of records fail mapping and there is no time to fix them under the outage window.
• Custom reports built on direct KNA1/LFA1 selects appear to work fine in test because test data was converted cleanly, then produce wrong results in production once ongoing BP-driven updates diverge from the classic tables over the following weeks.
• Authorisation gaps surface only when real users try to maintain data in production, because test scripts were run under near-basis-level test users that bypassed the actual role restrictions.
• Vendors that are also customers (intercompany trading partners, rebate scenarios) get mapped to two separate BPs instead of one BP with two roles, because the mapping rules were not explicitly configured for that overlap, and this only becomes visible during month-end netting or intercompany reconciliation.
• Interfaces that create master data get 'fixed' by pointing them at the old customer/vendor creation logic wrapped around CVI, which works but silently reintroduces the exact data drift the whole exercise was meant to eliminate.