VK12 — VK12 Change Condition Records

VK12 is the change transaction for condition records - the actual price, discount, surcharge, freight, or tax values sitting behind a condition type and access sequence. The structural fact that explains most confusion: VK12 only changes a record identified by an exact key combination already stored in the generated condition table (an A-table) for that access sequence. It does not let a user create a new combination on the fly. If nobody ever ran VK11 for that specific customer/material/sales-org combination, VK12 shows nothing, and the natural reaction is to assume the transaction is broken or the condition type is missing, when in fact the record simply was never created for that key.

VK12 is reached for whenever a price, discount, or surcharge already live in the system needs a new value or a new validity period - annual price increases, freight rate updates, a renegotiated customer rebate. The normal sequence is VK13 to confirm the record and key combination actually exist, then VK12 to change it, reserving VK11 for genuinely new combinations. It sits downstream of the pricing procedure setup in VOV8 and upstream of every sales order (VA01/VA02) and billing document that redetermines or copies pricing. Mass condition changes across many key combinations are typically done through a mass maintenance variant rather than repeated single-record VK12 runs.

Start from the A-table generated for the relevant condition table, filter on the key fields (sales org, customer, material, condition type KSCHL) to get KNUMH. Join KNUMH into KONP to read the current amount, unit, and currency, and into KONH to read DATAB/DATBI validity. Compare KNUMH values before and after the change - a new number for the same key combination confirms the system delimited the old record rather than overwriting it. Cross-check CDHDR/CDPOS filtered by user and date to confirm who made the change and when.

The underlying data model - KONH, KONP, and the generated A-tables per condition table - is unchanged on S/4HANA. VK12 remains fully functional and is still the transaction most consultants reach for during single-record or small-batch changes. S/4HANA also offers a Fiori-based app for managing sales pricing conditions with list-based mass editing, but it operates on the same tables underneath, so the diagnostic approach described here applies regardless of which front end was used to make the change.

Functional SD/pricing territory. Ownership sits with the SD or pricing consultant maintaining the condition type and access sequence, not Basis or ABAP, unless the failure traces to an authorization object at the sales-org level. A clean handover includes the condition type, condition table, exact key combination, the KNUMH before and after the change, and a list of any open orders that still show the old price.

VK11 is the natural companion for cases where the key combination does not yet exist and a new record must be created rather than changed. VK13 is the read-only check to run before any VK12 change, to confirm the record and combination actually match expectations. VOV8 controls which pricing procedure and therefore which condition types apply to a given sales document type, which explains why a changed condition sometimes has no effect on a particular order category. VA22 is where repricing of an already-created sales document is triggered after a condition record change, closing the loop between the master data change and the transactional document.