Explain SAP Pricing & Condition Technique in SAP

27 / 65

Functionalintermediate

SAP Pricing & Condition Technique

The generic condition technique engine underlying pricing in SD, MM, and other modules.

The condition technique is one of those "once you get it, half of SAP suddenly makes sense" topics, and interviewers ask about it specifically because it's reused far beyond SD pricing - output determination, batch determination, account determination, and tax procedures all use the identical underlying mechanism, so demonstrating a real grasp of it signals broad configuration competence rather than memorized transaction paths.

The condition technique is like a customer-service escalation script that tries the most specific answer first (this exact customer and this exact product) and falls back to more generic answers (this product regardless of customer, or a company-wide default) only if nothing more specific is found, stopping the moment any match succeeds.

Key Concepts

At its core, a condition type represents one price/discount/surcharge/tax component (e.g., PR00 base price, K004 customer discount, MWST output tax). Each condition type looks up its value using an access sequence - an ordered list of condition tables (combinations of fields like sales org + customer + material, or just material) it tries in sequence, using the most specific match found and stopping once one succeeds. Condition records (VK11/VK12, maintained per condition type and key combination) hold the actual values - e.g., "customer 100300, material FINISHED-100: 10% discount."

PR00K004MWSTVK11VK12

All relevant condition types for a business scenario are strung together into a pricing procedure (V/08 in SD), which also defines calculation logic between steps (e.g., a discount calculated as a percentage of a prior step's subtotal rather than a flat amount), subtotal accumulation points, and requirement/exclusion routines that can suppress a condition type entirely under certain conditions (like disabling manual discounts for certain customer groups). Determining which pricing procedure applies to a given document uses a separate small condition technique of its own (based on sales area + customer pricing procedure indicator + document pricing procedure indicator), which is a frequent point of confusion worth explicitly untangling in an interview answer.

V/08

A senior-level answer connects this to troubleshooting via the pricing analysis tool available directly on the sales order/PO's conditions tab (showing exactly which condition tables were checked, in what order, and why a particular one did or didn't find a record), and mentions that the exact same access-sequence-plus-condition-table architecture underlies output determination (which output type/medium to use) and batch determination (which batch to pick for a delivery), demonstrating the technique's reuse across completely different business processes.