Functionalintermediate
SAP Pricing & Condition Technique
The generic condition technique engine underlying pricing in SD, MM, and other modules.
The condition technique is one mechanism reused across SAP: pricing, output determination, account determination, batch determination and tax all work this way.
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
1
Learn it once and several unrelated areas of configuration stop being mysterious.
2
The four pieces.
condition type one component -- PR00 base price, K004 discount
condition table a field combination -- customer + material
access sequence an ordered list of tables to try
condition record the actual value, maintained in VK113
The access sequence is the interesting part: most specific wins. A discount condition type might search
in this order:
4
1. customer + material -> a deal for this customer on this product
2. customer -> this customer's general discount
3. material group -> a promotion on this product family5
SAP tries table 1. If a record exists, it uses it and stops. Otherwise it tries 2, then 3.
6
So a customer-specific price automatically beats a general one, without any rule saying so. The ordering of
the access sequence is the rule.
7
The pricing procedure strings the components together. It lists the condition types in order and how
each is calculated:
8
10 PR00 base price 1,000
20 K004 customer discount -5% -50
30 subtotal 950
40 KF00 freight +20
50 MWST output tax 18% of step 30 +171
-----
net value 1,1419
Notice step 50 takes 18% of the subtotal at step 30, not of the base price. A procedure defines those
references, plus requirement routines that can suppress a condition entirely — for instance no manual
discount for certain customer groups.
10
Which procedure applies is itself a determination. And it confuses people, so state it plainly. It is
found from three things:
11
sales area + customer pricing procedure indicator
+ document pricing procedure indicator12
So the same customer can be priced differently on a quotation and a credit memo, because the document type
carries its own indicator.
13
How to debug it. The conditions tab of a sales order has a pricing analysis that shows every access
that was tried, in order, with the key it searched for and whether a record was found.
14
That turns "why is there no discount" from guesswork into reading a list. In nearly every case the answer
is that the record exists under a slightly different key than the access looked for.
15
And the payoff. Output determination decides which document goes out by which medium, and batch
determination picks which batch to ship — both use access sequences over condition tables in exactly this
way. One mechanism, several problems.
16
What the interviewer is probing.1. "Explain the condition technique." Probing: whether you know the chain. Stalls: "Pricing
rules." Moves up: condition tables hold records, access sequences decide the lookup order,
condition types use an access sequence, and the pricing procedure sequences the types.
17
2. "How do you debug an unexpected price?" Probing: the practical skill. Stalls: "Check the
master data." Moves up: the pricing analysis on the order item, which shows every condition type
attempted and why each access succeeded or failed.
18
3. "What is a statistical condition for?" Probing: the detail. Stalls: "Nothing." *Moves
up:* showing a value without affecting the net price — used for expected costs and margin display.
19
4. "Why would a condition record exist but not apply?" Probing: the common trap. Stalls: "It
should." Moves up: the access sequence found a more specific record first, the validity dates do
not cover the pricing date, or a requirement routine excluded it.