KONH table — Condition Record Header Table

A row in KONH represents one condition record: a specific condition type valid for a specific date range, created against one particular condition table (key combination) such as customer/material or price list/material. It does not itself store the price or the key values (customer number, material number, and so on) or the amount. The key values live in a generated access table named after the condition table number (KOTABNR), and the rate, scale, or percentage lives in KONP, both linked back to KONH by the condition record number KNUMH. KONH is written whenever a condition record is created, changed, or deleted through condition maintenance, regardless of whether the usage is sales pricing, purchasing, output determination, or account determination, because all of these reuse the same condition technique tables.

KONH is not small and KNUMH is not something a user knows, so direct selection on KNUMH is rare; the practical entry point is the generated access table for the relevant condition table, filtered on the real key values (customer, material, sales organization), which returns the KNUMH to look up in KONH and KONP. Always restrict on client, and when checking whether a record is currently active, filter on DATAB and DATBI against the date in question rather than just today's date. LOEVM_KO must be checked separately from the validity dates because a deleted record can still fall inside a valid date range. KAPPL and KVEWE should be restricted early since the same KOTABNR values can appear across unrelated condition technique applications.

To confirm whether a price change actually reached the master data: identify the condition table used for the pricing condition type (from customizing of the access sequence), query its generated access table for the customer or material key combination to get KNUMH, then read KONH for that KNUMH to confirm KSCHL, DATAB, DATBI, and LOEVM_KO, and read KONP for the same KNUMH to confirm the rate. If the record shows correctly in KONH and KONP but the order still prices differently, the discrepancy is in KONV on the document, not in master data.

KONH and KONP remain the standard master data tables for classic condition technique pricing in S/4HANA on-premise; VK11, VK12, and VK13 still write and read them the same way as in ECC, and no compatibility view has replaced them for this purpose. Advanced or condition-contract-based pricing scenarios introduced in later S/4HANA capabilities can layer additional objects on top of the same condition technique, but the core KONH/KONP/KONV relationship for standard SD pricing is unchanged.

Whether a condition record exists, its validity, and its rate is an SD pricing configuration and master data question, owned by the pricing analyst or SD consultant who maintains condition records through VK11/VK12, not by basis or by a generic data team. Discrepancies between master data and what a document actually priced belong to whoever configured the access sequence and pricing procedure, since the explanation usually sits in requirement routines or exclusion settings rather than in the table content itself.

KONP holds the rate, scale, and currency for each KONH record and is always checked alongside it. KONV holds the conditions actually copied into a live sales or billing document and is the correct place to look when a document's price is in question rather than the master record. KONA covers rebate and condition contract agreements, which generate their own condition records through the same technique. VK11, VK12, and VK13 create, change, and display condition records that write to KONH and KONP; MEK1 and related purchasing transactions do the same for purchasing condition records sharing this table structure.