VK11 — Create Condition Record for Pricing

VK11 creates a condition record: a stored value for a condition type, tied to a specific combination of key fields (sales organization, customer, material, price list, and so on) and a validity period. The structural fact that explains most of the confusion around VK11 is that a single condition type can be linked to several condition tables through its access sequence, and each condition table has its own generated database table. Entering a value under one key combination does not create it under another, even if both belong to the same condition type. Which table a given record lands in is decided by the key combination selected on the VK11 initial screen or key combination list, not by the condition type name.

VK11 is used during pricing master data setup and maintenance: a new customer-specific price needs to be entered, a promotional discount needs a validity window, a freight scale needs updating, or a price list needs a new material added. It is reached for before the affected sales order, quotation, or contract is created, since existing documents already carry their own copied conditions and do not re-read master data automatically. For high-volume loads, mass condition maintenance or LSMW-based upload is preferred over manual VK11 entry; VK11 is the right tool for one-off or small-batch changes, not for repricing thousands of material-customer combinations.

Start from VK13 for the condition type and key combination in question to read off the internal condition number. Then use SE16N on KONP filtered by that condition number to see the stored amount, unit, and scale rows, and on KONH for the validity dates. To confirm the record exists under the exact key combination a document is trying to match, browse the generated access table for that condition table filtered on sales org, customer, or material, and check that the condition number returned there matches the one seen in KONP; a mismatch or an empty result explains why pricing did not pick it up.

VK11 behaves the same way on S/4HANA as on ECC; the transaction, the underlying condition tables, and the access sequence logic are unchanged. S/4HANA offers Fiori applications for managing pricing condition records that provide a list-based, mass-edit style front end over the same underlying tables, useful for reviewing or bulk-updating records rather than one-off entry. Consultants comfortable with VK11 can continue using it directly; nothing about the master data model changed.

This is functional SD pricing territory, owned by whoever configures pricing procedures and condition types. ABAP involvement is limited to custom condition tables, new access sequence fields, or pricing routines (VOFM). A clean handover includes the condition type, the exact key combination used, the sales area, the validity dates in question, and the condition number if one has already been identified through VK13.

VK12 and VK13 are the change and display counterparts to VK11 and are the first stop when a record's existence or validity is in question. VKOA covers account determination, a separate but structurally similar condition technique worth understanding once VK11's access-sequence logic is clear, since both rely on condition tables and key combinations. VOV8 defines the sales document type and its pricing procedure determination fields, which decide which pricing procedure, and therefore which condition types, apply to a given document category in the first place.