VD02 — Change Customer Sales Area Data
VD02 changes only the sales area segment of the customer master - sales, shipping, billing document, and partner function data for a specific sales organization, distribution channel, and division. It does not touch general data or company code (finance) data. That scope restriction is the source of most confusion: users expecting to change address or reconciliation account here find those fields absent, because that belongs to XD02 or FD02.
This page covers VD02, the sales-area-only customer master change transaction in SD, distinguishing it from the centralized XD02 and finance-only FD02 variants. It focuses on why the transaction appears locked or incomplete in some systems, and how changes here interact with existing sales documents and pricing.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,070 words
Purpose
VD02 maintains the sales area view of the customer master: pricing-relevant fields (customer pricing group, price list type), shipping data (delivery priority, shipping conditions, plant), billing data (payment terms at sales area level, account assignment group), and partner functions, all scoped to one sales organization, distribution channel, and division combination. It deliberately excludes general data (name, address, communication) and company code data (reconciliation account, payment methods, dunning), which belong to FD02 and are combined with sales area data in the centralized XD02. The structural fact that explains most support tickets: a customer master is really three separate segments stored and authorized independently, and VD02 only opens one of them.
When it is used
Reached for when a change is purely sales-side and the person making it has no reason to touch finance data - a sales assistant correcting shipping conditions, a pricing analyst updating the customer pricing group, or someone adding a new partner function for an existing sales area. In many landscapes VD02 is disabled in favor of always using XD02, so consultants should check the customer master strategy before assuming VD02 is the expected entry point. Interfaces and mass-change tools (LSMW, CATT scripts, BAPI-based customer maintenance) update the same underlying tables without going through VD02 at all, so a field discrepancy is not necessarily a VD02 problem.
How to use it in practice
- Enter the customer number.
- Enter sales organization, distribution channel, and division to select the sales area.
- Choose specific views (sales, shipping, billing document, partner functions) or leave blank to step through all of them.
- Confirm the sales area on the selection screen if prompted.
- Amend fields on each tab as needed.
- Save; the system checks mandatory fields and consistency before writing.
Key data objects
- KNVV - sales area data: pricing group, price list, delivery priority, shipping conditions, order probability, currency, one row per customer/sales org/distribution channel/division.
- KNVP - customer partner functions per sales area, linking partner roles (sold-to, ship-to, bill-to, payer) to the sales area record.
- KNVI - customer tax classification at sales area and country/tax category level.
- KNVD - output/message determination records tied to the customer at sales area level.
- CDHDR and CDPOS - change document header and item, recording who changed which field and when, if change document logging is active for that field.
How to prove it in the data
Query KNVV filtered on KUNNR, VKORG, VTWEG, SPART to confirm the sales area record exists and inspect current values of the field in question (VKGRP, VKBUR, KALKS, WAERS, VSBED, LPRIO, AWAHR). To see who changed it and when, query CDHDR filtered on object class for customer master and the customer number, then join to CDPOS on the change document number to see the specific field, old value, and new value. If CDPOS shows nothing for a field the user insists changed, that field is not configured for change document logging - check the current value directly in KNVV instead.
ECC vs S/4HANA
VD02 continues to function on S/4HANA and writes to the same underlying tables (KNVV, KNVP, KNVI). The strategic direction is to maintain customers as business partners with a customer role through the business partner transaction, with customer-vendor integration synchronizing changes back into the classic customer master tables. VD02, XD02, and FD02 remain usable for existing customers but new master data setup is generally steered toward the business partner transaction and its Fiori equivalents for customer maintenance.
Common pitfalls and how to diagnose them
- Missing sales area: user reports VD02 rejects the customer or shows a blank screen because KNVV has no record for that sales org/distribution channel/division combination. This is not a change scenario - the customer needs to be extended to that sales area first, typically via VD01 or XD01, not fixed inside VD02.
- Authorization restriction: VD02 is locked out in systems standardized on XD02, or the user lacks authorization for the specific sales organization. Check S_TCODE and the customer master authorization object for sales org restriction before assuming a data problem.
- Change does not affect open documents: modifying customer pricing group, delivery priority, or shipping conditions in VD02 only affects new sales documents. Existing open orders and deliveries retain the values copied at creation time; the reflex fix of re-saving VD02 repeatedly does nothing for them, they must be changed individually or via a mass document update.
- Partner function changes do not cascade: adding or changing a partner function in VD02 does not retroactively update partner functions already determined on existing sales orders. Confusion arises when a new ship-to is added but old orders still route to the previous one.
- Customer master lock: a background job, batch input session, or another user session can hold a lock on the customer master, producing an enqueue error. This resolves itself when the other session ends; forcibly deleting the lock entry can corrupt an in-flight update.
- Incomplete change document trail: not every sales area field is configured to write to CDHDR/CDPOS. Absence of a change document entry for a field is not proof the field was never changed, only that logging is not active for it.
Whose problem this is
Functional SD/customer master territory: field content, sales area logic, and partner function setup belong to the SD consultant. Authorization lockouts and enqueue/lock issues belong to Basis or security. A clean handover states the customer number, sales area, the specific field and old/new value expected, the transaction or interface used, and whether the change was meant to affect existing open documents.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/vd02ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.