VBPA table — Sales Document Partner Table VBPA

One row in VBPA represents a single partner function assigned to a sales document, either at header level (item number zero) or at item level when the item overrides the header partner, for example a different ship-to on one line of a multi-line order. The row records which partner function (sold-to, ship-to, payer, bill-to, or a client-specific function) applies, and which business partner fills that role — a customer, a vendor (for functions like forwarding agent), or an employee (for sales rep or employee responsible). VBPA is populated by partner determination at document creation, using the customer master's default partners as a starting point, and can be manually overridden afterward on the document itself.

Always restrict on MANDT and VBELN first; VBPA is not selective on its own and a scan without a document number range will hit the full table. When looking for a specific role, filter on PARVW as well, since a single document can carry ten or more partner rows once custom functions are configured. If more than one row can exist for the same PARVW, do not assume the first row returned is the right one — check PARZA and, for item-level questions, check POSNR explicitly rather than relying on header data alone. Do not read VBPA in isolation to conclude a customer's current address or terms; it stores the partner reference as of determination time, not live master data.

Symptom: an order shipped to the wrong ship-to address. Select VBPA where VBELN equals the order number and PARVW equals the ship-to code (typically WE). If multiple rows return with different PARZA values, the order has split ship-tos and the delivery process picked one deterministically — check which item's POSNR-level row (if any) overrides the header row before assuming the customer master default was wrong.

VBPA continues to exist in S/4HANA in essentially its original shape and remains the table where sales document partner determination results are stored; the underlying business partner model consolidation (customer and vendor as business partners) did not change VBPA's structure, which still carries KUNNR and LIFNR as before. Reporting and app layers increasingly read partner data through compatibility or analytical views rather than direct table access, but the table itself, and the logic that populates it during order processing, has not been replaced.

The SD functional consultant owns questions about why a given partner appears (or does not) on a document, since that behavior is driven by the partner determination procedure assigned to the sales document type. Master data or customer service ownership covers the default partners maintained on the customer master itself. Basis or interface teams should not be asked to explain partner selection logic; their role is limited to data extraction, not determination rules.

VBAK and VBAP are the header and item tables VBPA hangs off of, written together during order entry (VA01) and change (VA02). KNVP holds the customer master's default partner functions, which partner determination reads when a new document is created; changes there via customer maintenance transactions only affect future documents, not existing VBPA rows. ADRC stores the address behind ADRNR for one-time or overridden partners. KNA1 and KNVV supply the general and sales-area customer master data that VBPA's KUNNR points to.