Condition Record Exists but Not Applied in Pricing

The business symptom

The configuration behind it

• Validity period mismatch: the condition record's valid-from/valid-to does not cover the pricing date actually used by the document, which may be the order date, the requested delivery date, or the billing date depending on the pricing date control on the item category or document type, not the date the consultant assumes.
• Exclusive access sequence: the access sequence for the condition type is flagged exclusive, so once an earlier access in the sequence finds any record, later accesses (including the one holding the intended record) are never even executed.
• Condition exclusion group: a different condition type in the same exclusion group returned a value first and the pricing procedure's exclusion logic dropped the lower-priority one, even though both records are valid and both were found.
• Key combination mismatch: the record was created against a combination that does not match the transaction data being passed, for example customer plus material when the order is actually keyed by price list type plus material, or a sales area that differs from the one on the order.
• Requirement routine on the pricing procedure step: a coded requirement attached to the condition type's line in the procedure evaluates false for this document (item category, plant, order type) and skips the step regardless of whether a record exists.
• Deletion indicator set on the record: the record displays in VK13 but carries a deletion flag, so it is logically inactive for new pricing even though it is not physically gone.
• Release/approval status: the record was created under a condition record release procedure and has not been released for use yet.
• Scale mismatch: a scale exists on the record but the order quantity or value falls outside the defined scale steps, or the scale base (quantity vs value vs weight) does not match how the order is measuring the line.
• Item category not relevant for pricing: the item's pricing indicator on the item category is blank, so the item is excluded from pricing determination entirely regardless of any condition record.
• Communication structure field not populated: the field the condition table's key combination relies on (a customer group, a price group, a characteristic from a classification) is empty on the order because no copy control or user exit filled it, so the access technically runs but finds no match on that field.

What to check

• Open the order item in VA02/VA03, go to conditions, and use the pricing analysis function. This is the single most useful step: it shows exactly which access sequence steps were run, which found a record, and which were skipped, and why.
• If the analysis shows the access was never run, check the pricing procedure in V/08 for that document's determined procedure and confirm the condition type's step is present and not disabled by a requirement routine.
• If the access ran but found nothing, check the condition record itself in VK13: validity dates against the actual pricing date field being used, deletion flag, release status, scale entries.
• If a record was found but a different condition type overrode it, check the access sequence definition in V/07 for the exclusive indicator, and check condition exclusion group assignments.
• Check the item category in VOV7 for the pricing relevance indicator on the line item in question.
• If the key combination is suspect, check the condition table definition behind the access sequence and compare its fields against what is actually populated in the order's communication structure at that point.

How to prove it in the data

Resolution path

The fix people try first (and why it fails)

Whose problem this is