KONV table — Document Pricing Conditions Table

One row of KONV represents a single pricing condition line as it existed inside one commercial document at the moment that document was priced and saved - one step of the pricing procedure, for one item, in one document. Every sales order and billing document carries a document condition number, KNUMV, and every condition type that fired during pricing (price, discount, surcharge, tax, freight) gets its own row here, tied to the item it applies to and the step number in the pricing procedure that produced it. KONV is a snapshot: it captures the value SAP calculated and stored at save time, not a live recalculation. It does not describe why a price is what it is in general terms; it describes what a specific document actually charged, at what rate, at what step, and for what reason, at the moment it was last priced and saved.

The technical key of KONV is the combination of the first four fields below; nothing shorter uniquely identifies a row.

Every lookup into KONV starts from the document header, because KNUMV is only known once a document has been saved.

MANDT restricts by client as normal, but the table itself is large - every priced document leaves several rows behind. Never select from KONV by condition type alone; the same KSCHL recurs across millions of rows for unrelated documents. Always obtain KNUMV from the document header first (VBAK or VBRK), then filter on KNUMV, and add KPOSN if only one item is of interest. Treat KINAK as mandatory in any aggregation: rows with a non-blank KINAK were calculated but excluded from the actual result, and summing KWERT without excluding them overstates totals. For volume price analysis across many documents, use the standard pricing reporting tools rather than ad hoc joins.

Symptom: a discount that should have reduced an invoice line did not. Take the billing document number, read VBRK-KNUMV, then select KONV where KNUMV equals that value, KPOSN equals the item's position number, and KSCHL equals the discount condition type. No row at all means the condition never fired during pricing (determination or a requirement excluded it). A row with KINAK set means it fired but was deactivated - check STUNR and neighboring rows at the same step to see which condition overrode it.

KONV's underlying storage was redesigned in S/4HANA. Condition data now lives in a newer set of tables built for extensibility, removing the fixed-length limitations of the old structure. KONV is retained as a compatibility view so existing custom reports and interfaces that select from it by name continue to return correct results. New developments should read pricing data through the released interfaces for condition data rather than selecting KONV directly, since the physical storage behind it no longer matches the historical layout field for field in every scenario.

The SD pricing/configuration consultant owns the pricing procedure and condition determination logic that produces these rows. The order-to-cash functional lead owns whether a specific document priced correctly. Basis is only pulled in for raw table growth or read performance on very high-volume systems. FI/CO gets involved when a condition's accounting relevance, such as revenue account determination, is in dispute.

KONP holds the master condition records the rates originate from; KONH holds the header-level condition control for a document, paired with the KPOSN = 0 rows in KONV. VBAK, VBAP, and VBRK are the documents whose KNUMV ties everything together. Rows are written or rewritten whenever a sales order or billing document is created, changed, or re-priced through the standard order and billing transactions, and by mass pricing update programs.