Condition Record Maintenance, Scales, and Validity Management

Explanation

Condition records are the master data that make the pricing procedure produce actual prices, discounts, and surcharges. A pricing procedure and access sequence only define where the system looks; the condition record is what it finds. Getting condition record design right is one of the highest-leverage activities in an SD implementation because poorly designed condition tables lead to either explosive maintenance volume (too granular) or inaccurate pricing (too coarse). Each condition record is tied to a condition table, which defines the key fields (for example sales organization, distribution channel, customer, material, or price list group). The combination of fields chosen for a condition table is a direct trade-off: more fields give more precision but require more records and more maintenance discipline; fewer fields simplify maintenance but risk one record accidentally applying to combinations it should not cover. A common project decision is to introduce a customer price group or material price group field specifically to avoid maintaining prices per individual customer-material combination when business logic allows grouping. Scales allow a single condition record to hold different rates depending on quantity or value breakpoints. Scale type settings determine whether the scale is 'from' (each breakpoint rate applies to quantities from that point upward) or graduated interval-based, and whether the base value is the order quantity, cumulative value, or another basis. Scale maintenance mistakes are common: entering scale rates in the wrong direction, forgetting that a 'from' scale applies the highest qualifying rate to the entire quantity rather than incrementally by tier, or misconfiguring the scale base so it does not match the unit expected by the sales document line. Validity periods (valid-from and valid-to dates) let condition records represent time-bound pricing such as seasonal discounts, promotional campaigns, or contractual price changes. The system selects the condition record whose validity period contains the pricing date of the document (which itself is derived from configuration, often the requested delivery date or document date). Overlapping validity periods for the same key combination are not allowed within the same condition table entry and will be rejected or will create exclusion at maintenance time, but overlaps across different condition tables in the same access sequence can still occur, requiring careful access sequence sequencing (most specific table first) so that promotional pricing records are found before generic list price records. Mass maintenance of condition records is typically done through condition record maintenance transactions with multiple line entry, or through data migration tools such as LSMW, migration cockpit (S/4HANA), or direct upload templates, because manual entry does not scale for large customer or material populations. Data governance around who can create, change, or delete condition records (especially pricing that affects margin) is a control point often tied to authorization objects and change document review, since incorrect condition records are a frequent root cause of billing disputes and margin leakage. In S/4HANA, condition record maintenance can also be exposed through Fiori apps that provide more guided, list-based editing experiences, though the underlying condition technique and condition table structure remain conceptually the same as ECC. Some organizations also evaluate whether newer condition contract or settlement management capabilities are more appropriate for complex rebate-like scenarios rather than trying to force everything through basic pricing condition records with heavy scale logic.

Code example

* Example: Two condition records for the same condition type, illustrating access priority* Condition Type: PR00 (Price) * Record 1 - Condition Table 305 (Customer/Material) - very specific* Sales Org: 1000  Customer: 100234  Material: FG-100* Valid From: 2024-01-01  Valid To: 2024-12-31* Rate: 95.00 USD per PC * Record 2 - Condition Table 304 (Material) - generic fallback* Sales Org: 1000  Material: FG-100* Valid From: 2024-01-01  Valid To: 9999-12-31* Rate: 100.00 USD per PC * Access sequence for PR00 must list Table 305 BEFORE Table 304* so the customer-specific price (95.00) is found first when it exists,* falling back to the generic material price (100.00) otherwise. * Scale example on Record 2 (quantity-based 'from' scale):* Scale Qty      Rate*     1 PC       100.00 USD*    50 PC        95.00 USD*   100 PC        90.00 USD* An order for 120 PC uses the 90.00 rate for the ENTIRE quantity* in a standard 'from' scale, not tiered per bracket.

Real project scenario

A consumer goods company maintained material-level list prices in one condition table and customer-specific negotiated prices in another. During a contract renewal, the commercial team updated the customer-specific table but left the old validity end date one day short of the new contract start date. For that one-day gap, orders fell back to the generic list price, which was significantly higher, causing a visible price spike on a handful of orders that the customer's procurement team flagged immediately. The root cause was traced through the condition record validity history and access sequence log, and the fix included both correcting the gap and adding a validation check in the price update template to catch date discontinuities before upload.

Common mistakes

• Creating condition tables with too many key fields, leading to unmanageable maintenance volume. • Leaving gaps or unintended overlaps between validity periods when renewing time-bound condition records. • Misunderstanding 'from' scale behavior and assuming rates apply incrementally per tier rather than to the full quantity. • Sequencing access sequence entries so a generic table is checked before a more specific one, causing specific pricing to never be found. • Mass-uploading condition records without validating key combinations, creating duplicate or conflicting records. • Not restricting change authorization on pricing-sensitive condition types, allowing uncontrolled margin-impacting edits.

Best practices

• Design condition tables with the minimum field set that still meets business precision requirements. • Order access sequences from most specific to least specific condition table. • Document scale type and scale base decisions clearly so business users maintaining records understand rate behavior. • Use mass maintenance tools with validation logic to prevent duplicate keys or date gaps. • Restrict condition record change authorization for margin-sensitive condition types and review change documents periodically. • When renewing time-bound pricing, always align new valid-from dates with the prior record's valid-to date with no gap or unintended overlap.

Interview angle

Interviewers often ask candidates to explain how the system chooses between multiple valid condition records for the same condition type, and to describe a 'from' scale versus a graduated scale in their own words with a numeric example. Being able to trace a pricing discrepancy back to validity period gaps or access sequence ordering, rather than just saying 'check the condition record,' demonstrates practical troubleshooting depth expected at intermediate level.