XD01 and XK01 Retirement in Favour of BP

Classic ECC behaviour

S/4HANA behaviour

Project impact

• Custom ABAP programs, LSMW loads and batch input recordings that call XD01/XK01 in the background fail or are blocked; anything relying on batch-input screen sequences for these transactions has to be rebuilt against BP or its BAPIs.
• Authorisations built around the classic customer and vendor authorisation objects no longer control BP maintenance on their own; without the business partner authorisation objects, users can end up able to edit data they were never meant to touch, or conversely locked out of everything.
• End users in accounts payable and sales administration lose a screen layout they have used for years; BP's tabbed, role-driven UI groups fields differently, and complaints about 'where did the field go' spike in the first weeks after go-live.
• Interfaces and middleware (EDI, IDoc-based vendor or customer replication, third-party CRM feeds) that create master data via old function modules or direct table calls need to be repointed at BP-compatible APIs or the current BAPIs, or they silently create incomplete business partners.
• Number range mismatches between customer, vendor and business partner surface only when a specific number is requested that the BP number range cannot produce, which tends to appear first during month-end mass vendor creation runs, not in testing with a handful of records.
• Data quality issues invisible in ECC, such as a customer and a vendor for the same trading partner never being linked, become visible and sometimes mandatory to resolve once the business decides to merge them into one business partner.

Migration actions

• Run the customer/vendor integration pre-checks well before the technical conversion window; this is a hard gate, not a nice-to-have, and the conversion tooling will not proceed cleanly past it if customer, vendor and business partner numbering or grouping is inconsistent.
• Decide the target model early: one business partner per legal entity carrying both customer and vendor roles, or separate business partners kept aligned by number. This decision drives grouping design, number range alignment and downstream reporting, and reversing it after go-live is expensive.
• Rebuild every batch input, LSMW and custom creation program that touched XD01/XK01 against BP-compatible BAPIs or the business partner API, rather than trying to keep the old recordings alive through the compatibility redirect.
• Redesign authorisations using the business partner authorisation objects, mapped explicitly to the roles and groupings in use, before go-live rather than patching access issues in production during week one.
• Retrain accounts payable, accounts receivable and sales administration staff on the BP screen layout ahead of cutover; a short hands-on session prevents a wave of tickets asking where familiar fields moved.
• Reconcile number ranges for customer, vendor and business partner and fix collisions in the source system before conversion, since fixing them afterwards means touching live master data.

Whose problem this is

Common pitfalls

• Teams treat the pre-check as a formality and only look at the results the week before cutover, discovering thousands of customer or vendor records with grouping conflicts that need business decisions, not just technical fixes.
• A handful of test records pass cleanly through BP creation in the sandbox, but a mass load of tens of thousands of vendors at go-live exposes number range exhaustion or grouping mismatches that never appeared in small-scale testing.
• Authorisation redesign gets deferred as 'we'll tighten it after go-live', and for weeks every business partner role effectively grants broad edit access because nobody configured the finer-grained checks.
• Interfaces that were quietly relying on customer or vendor number equal to business partner number keep working in test because the test system happened to be built that way, then break in production where legacy numbering diverged.
• Reports built directly against customer or vendor tables continue to work because the integration layer keeps them populated, creating a false sense that nothing changed, until someone tries to extend a report to pull business partner relationship data that simply is not there in the old tables.