Lesson 2 of 5
Condition records, validity and scales
11 min
If configuration is the engine, condition records are the fuel. They are maintained by the business, change often, and are the single most common reason a pricing test fails. This lesson covers how records are maintained, how validity periods and scales work, and why dates matter so much.
Where records are maintained
In SAP GUI the classic transactions are VK11 (create), VK12 (change) and VK13 (display), started with a condition type and then a choice of key combination, which is the condition table. In the Fiori launchpad, the Manage Prices - Sales app lets a pricing specialist search, create and change sales condition records in a list, maintain scales, and export to and import from a spreadsheet. Many S/4HANA projects use the app for day-to-day maintenance and keep the GUI transactions for specialists.
| Field | Meaning | Contoso example |
|---|---|---|
| Condition type | Which pricing element the record belongs to | PPR0 base price |
| Key fields | Values for the fields of the chosen condition table | Sales org 1710, distribution channel 10, material CMC-ALT-100 |
| Amount and unit | Price or percentage, currency, per quantity and unit | $240.00 per 1 piece |
| Valid from / valid to | The date range in which the record can be found | January 1 to December 31 |
| Scale | Optional tiers by quantity, value, weight and so on | 1 piece $240.00; from 100 pieces $228.00 |
| Upper and lower limit | Optional bounds for manual changes to the condition | Discount may be changed between 0% and 10% |
| Deletion indicator | Marks the record as no longer to be used | Set when an old customer price is retired |
A sales price condition record. Field labels vary slightly between the GUI and the app.
Validity periods and the pricing date
Every record has a valid-from and valid-to date. When SAP prices an item, it looks for records valid on the item's pricing date. The pricing date is proposed when the order is created, usually from the document date or the requested delivery date depending on the sales document type, and it can be changed on the order. The pricing date, not today's date and not the delivery date, is what counts.
- Dec 31Old price endsRecord A: CMC-ALT-100 at $235.00, valid to December 31
- Jan 1New price startsRecord B: $240.00, valid from January 1. When a new record overlaps an old one, SAP shortens the old record's validity.
- Jan 3Order enteredMaria enters an order with pricing date January 3; SAP finds record B and prices at $240.00
- Jan 3Back-dated orderAn order with pricing date December 30, agreed in writing last year, finds record A at $235.00
- Mar 1PromotionRecord C, a customer discount valid March 1 to March 31, is found only for orders priced inside that window
Scales
A scale gives different amounts for different quantities or values on one record. Contoso sells CMC-ALT-100 at $240.00 per piece, dropping to $228.00 from 100 pieces and $220.00 from 500 pieces. The scale type decides whether each tier is a "from" quantity (the usual case) or a "to" quantity. Two details matter for testing: the exact boundary (does 100 pieces get the lower price?) and the scale base, which may be the item quantity or, for a group condition, the total across several items.
| Order quantity | Scale tier reached | Expected price per piece | Expected net value |
|---|---|---|---|
| 99 | From 1 | $240.00 | $23,760.00 |
| 100 | From 100 | $228.00 | $22,800.00 |
| 101 | From 100 | $228.00 | $23,028.00 |
| 500 | From 500 | $220.00 | $110,000.00 |
The last row is not a trick. With "from" scales, buying one more piece can lower the total, and customers notice. If the business does not want that effect, the fix is a different scale design or a graduated scale, which charges each tier separately. That is a pricing design decision for the process owner, not a defect, but a good test makes the effect visible.
Mass changes and price reports
Prices change in bulk at least once a year. Records can be changed in mass through the app's spreadsheet import or the GUI's condition maintenance transactions, and existing records can be listed with standard price reports. On a project, treat a mass price update like a small release: extract before, load, extract after, and compare a sample against the approved price list.
What would you do?
Priya's team runs a regression of 40 order-to-cash scripts in client 100. Twelve fail with "price missing" on CMC-ALT-100, all created today. Yesterday the same scripts passed. What is the most likely cause to check first?
- Condition records hold amounts, key fields, validity dates, optional scales and limits.
- Maintain them with VK11/VK12/VK13 or the Manage Prices - Sales app.
- SAP finds records valid on the item's pricing date, not on the date you run the test.
- Scales have boundaries; calculate expected results at, just below and just above each break.
Check your understanding · not graded
Lesson check
1. Which date decides which condition record is found for an order item?
2. Which Fiori app is used to maintain sales prices as condition records?
3. With a "from" scale of $240 from 1 and $228 from 100, what price applies to 100 pieces?
4. Why do pricing tests often fail right after data migration?