Configuring the Pricing Procedure and Condition Technique

Explanation

Once the fundamentals of pricing are understood, the next step is learning how consultants actually build and maintain the pricing procedure and the condition technique that drives determination. A pricing procedure is a sequence of steps, each referencing a condition type, and each step has attributes that control calculation behavior: the 'from' and 'to' columns define subtotal ranges used for building up base amounts for subsequent conditions, the requirement column attaches a routine that controls whether the condition is even considered for a given document, the calculation type controls whether the condition is percentage-based, fixed amount, or quantity-based, and the account key routes the condition's value to the correct general ledger account during billing through account determination. Getting these column settings right is what separates a working pricing procedure from one that produces incorrect subtotals or fails to post correctly to Finance. The condition technique itself works through access sequences: each condition type that requires automatic determination is linked to an access sequence, which is an ordered list of 'accesses,' each pointing to a condition table (a combination of fields such as sales organization, customer, material, or price list) and the system searches these tables from most specific to least specific until it finds a valid condition record. This is why field combinations and access order matter enormously: if the access sequence is not properly sequenced from most specific to most general, the system might find a broader match before checking a more specific and intended one, or vice versa, leading to incorrect price selection. Another key intermediate concept is condition exclusion and condition supplements. Sometimes multiple discounts could apply simultaneously, and pricing procedure exclusion groups let consultants define that only the most favorable condition should be applied among a competing set. Condition supplements let a base condition automatically bring in additional related conditions, useful for bundling a standard discount with a promotional discount without requiring the order processor to add both manually. Intermediate consultants must also understand how pricing determination is triggered on the sales document header versus item level, how new pricing can be forced via a manual pricing type at the item level (for example, redetermine and keep manual entries versus a full redetermination that overwrites manual changes), and how copy control between sales document types affects whether pricing is copied as-is or redetermined at each subsequent document, such as from quotation to order to billing. Troubleshooting at this level goes beyond checking condition records; it means reading the pricing procedure configuration in conjunction with the analysis log to determine whether a missing condition is due to a missing access, a failed requirement routine, or an incorrect condition table field combination. In S/4HANA, the underlying condition technique and pricing procedure structure remain conceptually the same as ECC, though some clients adopt newer condition contract or rebate frameworks in S/4HANA that extend beyond classic SD rebate processing; consultants should verify with the specific system's configuration rather than assume feature parity, since public cloud editions may restrict certain configuration transactions and instead expose pricing setup through more guarded configuration apps with reduced flexibility compared to on-premise.

Code example

* Example: Pricing procedure step structure (illustrative, not executable ABAP)* Step  CondType  Description         From  To   CalcType  AcctKey* 10     PR00      Base Price          -     -    C(fixed)   ERL* 20     K004      Material Discount   10    -    A(percent) ERS* 30     K005      Customer Discount   10    -    A(percent) ERS* 40                Subtotal: Net 1     10    30* 900    MWST      Output Tax          40    -    A(percent) MWS* Notes:* - Step 20 and 30 both base their percentage on step 10's amount (From=10)* - Subtotal at step 40 accumulates steps 10 through 30 for downstream use* - Requirement routines (not shown) can suppress K004/K005 for certain doc types

Real project scenario

During a rebate and discount redesign for a wholesale distributor, the client complained that two overlapping customer discounts were both applying and stacking beyond the agreed maximum margin erosion. The consultant reviewed the pricing procedure, identified that no exclusion group had been configured between the two discount condition types, set up a condition exclusion group so only the higher-value discount would apply, and validated the fix by re-running pricing analysis on sample orders before releasing the change to production.

Common mistakes

• Setting incorrect 'from' and 'to' subtotal references, causing discounts to calculate on the wrong base amount • Forgetting to configure condition exclusion groups when multiple discounts could legitimately compete for the same order • Assigning an access sequence with fields ordered from general to specific instead of specific to general • Not testing copy control redetermination settings when moving from quotation to order to billing, causing unexpected price changes at billing • Overlooking that manual pricing type settings can silently prevent automatic redetermination during later document changes

Best practices

• Design access sequences from most specific to least specific field combinations to avoid unintended matches • Use condition exclusion groups whenever multiple discounts could legitimately compete for the same line item • Always validate subtotal 'from-to' ranges after adding or reordering pricing procedure steps • Test full document flow (quotation to order to billing) after any pricing procedure change, not just the sales order screen • Maintain clear documentation of account key to G/L account mapping for every revenue-relevant condition type

Interview angle

At the intermediate level, interviewers frequently probe understanding of access sequence design, exclusion groups, and the difference between requirement routines and access sequence field combinations, since these are common root causes of real pricing defects. Being able to walk through a troubleshooting scenario using the pricing analysis log is often more valued than reciting configuration menu paths.