SD / O2Cintermediate

SD Pricing Part 4: Condition Records, Scales and Validity Management

Key takeaway

Maintain condition records the way pricing teams need: VK11/VK12 and the Fiori price apps, validity periods and overlaps, scales (quantity, value, weight; from-scales and graduated), mass maintenance, release/approval and change documents.

Explanation

📌 KEY POINTS
✅ Condition records hold the values per key and validity period; maintained with VK11/VK12/VK13, VK31/VK32 (condition maintenance) or Fiori price apps.
✅ Validity periods must not overlap unintentionally — a new record with overlapping dates adjusts or replaces the existing one.
✅ Scales let the value depend on quantity, value or weight; scale type decides "from" scales or graduated (each band priced separately).
✅ Mass maintenance and upload tools handle annual price changes; change documents record who changed what.
⚠️ Price increases entered with past validity dates reprice open documents unexpectedly when they are repriced.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Parts 2–3 configured the technique. Now the data that drives prices every day.

━━━━━━━━━━━━━━━━━━━━
▶ 1. MAINTAINING RECORDS

VK11 create, VK12 change, VK13 display — per condition type and key combination (table).
VK31/VK32: condition maintenance by area menu, many records at once.
S/4HANA Fiori: Manage Prices – Sales, mass upload via file.

━━━━━━━━━━━━━━━━━━━━
▶ 2. VALIDITY

Valid-from/valid-to per record.
Overlapping records: system adjusts the older record's validity.
Future-dated records for planned price increases.

━━━━━━━━━━━━━━━━━━━━
▶ 3. SCALES

Scale basis: quantity, gross value, weight, volume (set in condition type).
Scale type: from-scale (whole quantity gets the band price) or graduated (each band priced separately).
Scale check: ascending/descending.

━━━━━━━━━━━━━━━━━━━━
▶ 4. ADDITIONAL DATA

Upper/lower limits for manual changes.
Payment terms, fixed value dates on records (some condition types).
Release status/processing status for approval workflows (where configured).

━━━━━━━━━━━━━━━━━━━━
▶ 5. CONTROL AND AUDIT

Change documents per record (VK12 > Environment > Changes).
Authorizations by condition type and sales org.
Reports: price lists (V/LD), condition record lists.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

Create a price record with a scale in VK11.
Create a future-dated increase.
Create an order before and after the change date.
Check change documents.

✅ CHECKPOINT: orders price correctly on both sides of the validity change, and the change history shows who changed the price.

Code example

ABAP Code

===== STEP 1: create record (VK11) =====Condition type ZPR0 → key combination "Customer/Material" (table 501)Customer 1000 | Material M-100 | Amount 95.00 EUR / 1 PC | Valid 01.01.2026–31.12.2026Scales (quantity): from 1 = 95.00 | from 100 = 90.00 | from 500 = 85.00 ===== STEP 2: future price increase =====VK11 same key | 98.00 EUR | valid 01.07.2026–31.12.9999  → old record ends 30.06.2026 ===== STEP 3: mass maintenance =====VK32 condition maintenance (area menu) | Fiori "Manage Prices – Sales" with upload ===== STEP 4: audit and lists =====VK12 > Environment > Changes > Per condition recordV/LD pricing report (price lists)   Authorization objects for condition maintenance per condition type/sales org

Real project scenario

A pricing team uploaded the annual price increase with valid-from 1 January, but the upload ran on 15 January. Open orders repriced by users (or by redetermination rules on billing) picked up the new prices retroactively, and key accounts disputed invoices. The process was changed: increases uploaded at least two weeks ahead with future validity, copy control/billing pricing rules reviewed, and a checklist for communicating increases to key accounts.

Common mistakes

Entering price increases with past validity.
Overlapping validity from different teams.
Using from-scales where graduated scales are agreed (or vice versa).
Maintaining records without authorization restrictions.
No review of change documents for key accounts.

Best practices

Upload price changes with future validity.
One owner per condition type and key combination.
Choose scale type deliberately with sales.
Restrict maintenance authorizations by condition type and sales org.
Report on overlaps and recent changes regularly.

Interview angle

Questions: "How do you maintain condition records?", "Difference between from-scale and graduated scale?", "How do you plan a price increase?"
Strong answer: VK11/VK12/VK13, VK31/VK32, Fiori price apps; validity management and overlaps; scale basis and types; mass upload with future dates; change documents and authorizations.

Practice this lesson

Quick check

1. A price increase is entered on 15 January with validity from 1 January. What is the main risk?

2. Which transaction creates a condition record?

3. With a graduated scale (0–99 at 10 EUR, from 100 at 9 EUR), how is an order of 150 pieces priced?

Interview questions

1. A pricing team plans the annual price increase for 40,000 condition records. How do you organize maintenance and avoid disputes?

Answer it in your own words first, then compare.

2. A global customer needs volume-based pricing where the discount percentage increases as cumulative order quantity across multiple orders in a month grows. How would you design this using scales, and what limitation must you flag to the business?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.