1. Root Cause Analysis

The standard DMC migration object for vendor extensions is strictly designed under the assumption that the Supplier ID and the Business Partner (BP) ID are identical.

KBA 3410894 Error “Business partner XXXXXX doesn't exist” occurs when preparing or simulating the migration object

When processing the general structure data (S_SUPPL_GEN), the system executes a standard rule named BOR_LFA1_2 to validate and assign BP attributes (such as person/org names). In this rule, the system queries the BP master table (BUT000) using the Vendor Number (lv_lifnr). Because your system is configured to use different numbers for Vendors and BPs, the system searches for the Vendor ID inside the BP table, fails to find it, and triggers the hard error: “Business partner 0000200000 doesn't exist.”

2. Proposed Technical Solution

To bypass this standard limitation and enforce the use of different Vendor and BP numbers for existing vendor migrations, we need to customize the DMC object. I recommend the following approach:

• Step 1: Structure Adjustment: Add an additional field to the source structure S_SUPPL_GEN in LTMOM (e.g., BP_NUMBER).
• Step 2: Field Mapping: Map this new custom field to the target field BPARTNERHDRBP within the R_IT_DATA target structure.
• Step 3: Rule Customization: Adjust the ABAP logic inside rule BOR_LFA1_2 so that the system searches BUT000 using the newly provided BP number, rather than defaulting to the Vendor number.

Technical Reference for your ABAP Team: 

Current Standard Logic:

Proposed Custom Logic:

DATA(lv_search_partner) = COND #( WHEN _wa_s_suppl_gen-bp_number IS NOT INITIAL 

                                   THEN _wa_s_suppl_gen-bp_number 

                                                 ELSE lv_lifnr ).

SELECT SINGLE name_first, 

              name_last, 

              name_org1, 

              name_org2, 

              type,

              partner_guid

  FROM but000

  INTO CORRESPONDING FIELDS OF ls_but000

  WHERE partner = lv_search_partner.

3. Important Disclaimers & Next Steps

Before we proceed with implementing this customization, please be aware of the following:

• Iterative Testing Required: This custom logic will bypass the current validation error. However, the data will subsequently be passed to the core API (CMD_MIG_BP_CVI_CREATE). Because we are altering the standard data flow, we must extensively test this in a Development/Quality environment to ensure the core API accepts the split numbering without triggering secondary errors from technical and functional perspectives.
• Support Impact (Crucial): Making these changes will convert the standard migration object into a “Customized Object.” Consequently, it will no longer be covered by standard SAP Incident Support. The project team will need to take full responsibility for the maintenance and functional validation of this custom object moving forward.

Please review these findings with your technical and functional teams.