SAP SD Pricing

SD uses the condition technique: a pricing procedure combines condition types (price, discounts, surcharges, freight, tax) in sequence to compute the net value of each item. Condition records (e.g. a price list, a customer-specific discount) supply the values automatically based on access sequences.

• Condition types: price, discount, surcharge, freight, tax.
• Pricing procedure: the sequence/logic of conditions.
• Access sequences & condition records: where values come from.
• Condition tables: the keys (customer/material/price list).

The condition technique sounds abstract until you follow it once in order. Four objects, and each one answers a different question.

A condition table is a combination of fields: customer and material, or material alone, or price list and material. It is the key under which a price can be stored.

An access sequence is an ordered list of those tables, most specific first. It is the search strategy: look for a price agreed with this customer for this material, and if there is none, fall back to the list price for the material.

A condition type is one element of the calculation, with an access sequence attached. PR00 for the base price, K007 for a customer discount, and so on. It also carries the rules: whether the value is a percentage or an amount, and whether it can be changed manually.

A pricing procedure lists the condition types in calculation order, with subtotals, and says which are statistical, meaning shown but not added.

At order entry the system walks the procedure, and for each condition type walks its access sequence until it finds a record. First hit wins, and it stops looking.

VK11 creates condition records, VK12 changes them and VK13 displays them. That is where the actual numbers live, and it is master data maintained by the business rather than configuration.

The configuration sits in SPRO under Sales and Distribution, Basic Functions, Pricing. Condition tables, access sequences, condition types and the procedure are each their own node, in that order, which mirrors how they depend on each other.

On the order itself, the item conditions tab shows the result, and the analysis button beside it is the single most useful tool in SD. It lists every condition type in the procedure, every access it attempted, and the reason each one did not find a record.

Pricing results are stored in PRCD_ELEMENTS in S/4HANA, which replaced KONV. Condition records themselves live in the A tables, one per condition table, which is why they are numbered rather than named.

Half an hour, and it teaches more about pricing than reading the configuration guide.

1. Create a sales order with VA01 and look at the item conditions. Note which condition types found a value.
2. Open the analysis. Find PR00 and read which access found the record and which were skipped.
3. Now create a condition record with VK11 for a customer discount, for this customer and this material only.
4. Create the order again. The discount appears, and the analysis shows it found a record at the most specific level.
5. Change the order to a different customer. The discount disappears, and the analysis shows every access missing. Nothing is broken: the record simply does not exist at any level the sequence looks at.

That last state is what most pricing tickets actually are.

Pricing drives the revenue posted at billing, so it must be exactly right. It is highly configurable to model complex commercial rules (customer discounts, promotions, freight). The same condition technique appears in MM, so mastering it here transfers. Pricing is a frequent, high-value SD specialisation.

It is also the join to procurement. The same condition technique prices a purchase order, with different condition types and its own procedure, which is why an MM consultant and an SD consultant can usually read each other's pricing problems. See SAP MM pricing for the buying side and SAP SD configuration for where the procedure is assigned.

• How many condition tables. Every extra combination is another place a price can hide. Start with the fewest that model how the business actually agrees prices.
• Where manual entry is allowed. Letting a salesperson override a price is convenient and it removes the audit trail that a condition record gives you.
• Percentage or absolute discounts. Percentages scale with the order and absolutes do not, and choosing wrongly shows up on the largest orders where it costs most.
• What is statistical. Expected margin or cost is usually carried statistically so it can be reported without changing what the customer pays.

Pricing splits cleanly into two responsibilities, and most trouble comes from the split being unclear rather than from the configuration.

Configuration is a consultant's job. Condition types, access sequences and the procedure are transported like any other setting, and they change rarely once the business is running.

Condition records are the business's job. They are master data. Prices, discounts and freight rates change constantly, and the people who agree them should be the people who maintain them, through VK11 or a mass upload.

When that boundary is not agreed, one of two failures follows. Either the business cannot change a price without raising a ticket, so prices lag behind what was actually agreed with the customer. Or consultants keep write access to condition records long after go-live, and nobody can say who changed a price or why.

Validity dates are the mechanism that makes business ownership safe. A record carries a valid-from and valid-to date, so a price rise can be entered in advance and takes effect on the day. Reading the validity of a record before changing it is the habit that prevents somebody overwriting next quarter's agreed price with this quarter's.

The reporting question follows from the same place: when a customer disputes an invoice, the answer is the condition record that applied on the order date, not the one in the system today. See SAP SD customers for the master data that decides which records are even looked at.

• Missing/wrong condition records, wrong price.
• Misordered pricing procedure, wrong calculation.
• Overcomplex pricing that is hard to maintain.

• Adding a condition table to fix one customer. It solves today and lengthens every access sequence from now on.
• Forgetting validity dates. A record that expired last night is the most common cause of a price that worked yesterday.
• Reading the conditions tab instead of the analysis. The tab shows what happened. The analysis shows why. See SAP SD reports for finding the affected orders afterwards.

• Testing a new condition record only on a new order. Existing open orders keep the price they were created with until something reprices them, which is usually what the business wanted and occasionally not.

Maintaining a condition record is the easy half, and designing the procedure and access sequences behind it is the part you do in the course.

One more thing worth knowing early. Pricing runs again when a document is copied, so a delivery or an invoice can reprice depending on what copy control says, and that is configurable per document type. When an invoice does not match the order it was created from, the pricing type in copy control is the setting to read first, and it catches out people who have already learned everything else on this page.