VD03 — Display Customer Sales Area Data

VD03 shows the sales area view of a customer master record: one combination of sales organization, distribution channel, and division. This view carries the fields SD documents actually read at runtime - pricing group, customer pricing procedure, delivery priority, shipping conditions, delivering plant, order and billing blocks, incoterms, and the partner functions valid for that sales area. The structural fact that explains most confusion is that the customer master is split into three independent segments: general data (client level), company code data (per company code), and sales area data (per sales org/channel/division). VD03 only ever shows the third. A customer can exist perfectly well in general data and still be unusable in a sales order because no sales area record was ever created, and VD03 against that combination will show a selection error rather than a blank customer.

Reached for whenever an SD issue needs to be traced to master data rather than document data: a pricing condition that will not determine, a shipping point or route that defaults wrong, a partner function missing during sales order create, or a credit or billing block that nobody remembers setting. Used as a quick read-only check before escalating to VD02 for a fix, and preferred over XD03 when the analyst already knows the issue is SD-specific and wants to skip the general and company code tabs. In S/4HANA landscapes running the Business Partner model, the same information is reached through the BP transaction with the customer role, and VD03 becomes a legacy shortcut rather than the primary path.

Query KNVV on KUNNR, VKORG, VTWEG, SPART to confirm the sales area record exists at all - no rows means the customer was never extended to that sales area, which is the single most common root cause of order-creation failures. Check VWERK, WAERS, KDGRP, PLTYP, and the block fields (LIFSK, FAKSK) for the actual values SD documents will read. To check whether a change actually affects an existing order, compare KNVV against the corresponding fields already copied into VBAK/VBAP for that sales document - master data changes made after order creation do not retro-apply.

VD01, VD02, and VD03 continue to work in S/4HANA against the underlying KNVV/KNVP/KNVI tables, but the strategic master data object is now the Business Partner, accessed through the BP transaction with a customer role assigned. New customer creation through pure VD01/XD01 style transactions is restricted or blocked in many S/4HANA configurations, forcing creation through BP instead, while VD03 as a read-only check often remains usable for as long as the compatibility layer is active.

Functional SD or master data governance owns this transaction and its data. ABAP involvement is limited to custom field checks or validations on the sales area segment. A clean handover states the exact KUNNR/VKORG/VTWEG/SPART checked, what was found missing or wrong, whether any sales document already used the old values, and whether the fix belongs in VD02/XD02 or upstream in the BP maintenance process.

XD03 is the natural next stop when the issue might sit in general or company code data rather than the sales view. VD01 and VD02 are the create and change counterparts for the same segment. VA01 and VA02 are where the copied-at-creation behavior actually bites, useful for confirming whether a master data fix needs a document-level correction too. VK11 is worth checking alongside VD03 when a pricing group or customer pricing procedure looks correct in the master but the condition still fails to determine, since the condition record itself lives separately.