Pricing Routines, Requirements, and Alternative Calculation Types

Explanation

Standard condition technique (condition type plus access sequence plus condition record) handles the majority of pricing scenarios, but some business rules cannot be expressed purely through master data lookups. SAP addresses this with pricing routines assigned at the pricing procedure line level: requirement routines, alternative calculation type routines, and alternative base value routines. These are ABAP routines maintained through the routine maintenance environment (commonly referred to by consultants as VOFM routines) and referenced by a numeric routine number in the pricing procedure configuration. A requirement routine controls whether a condition line is even considered during pricing for a given document. For example, a routine might state that a certain freight surcharge condition type is only relevant if the sales document type is a standard order and the shipping condition is a specific value, or that a rebate-relevant condition should be skipped entirely for intercompany billing documents. Requirement routines return a true/false-like result and are evaluated before the system attempts to access condition records for that line, which improves performance by skipping irrelevant access sequence lookups and also enforces business rules that would be awkward to encode purely in condition record keys. An alternative calculation type routine replaces the standard rate-times-quantity calculation with custom logic. This is used when a price or surcharge must be derived from a formula rather than a flat or scaled rate, such as a percentage calculated from a combination of other condition values, a tiered calculation based on multiple fields simultaneously, or a rounding rule that standard scale logic cannot express. Because this routine fully overrides how the condition value is computed, it must be written carefully to avoid breaking condition subtotal logic, statistical condition flags, or downstream accounting determination that assumes standard calculation behavior. An alternative base value routine changes what quantity or value the condition rate is applied against. Standard base value is typically the order quantity or net value up to that point in the pricing procedure, but some business scenarios need the base to be a different figure, such as a weight-based value, a value from a different condition line, or a value computed from a custom field. This is common in industries with volume-based or weight-based pricing, such as chemicals or metals, where price is quoted per ton but the sales unit is pieces or cases. Because routines are custom ABAP code, they introduce a testing and governance burden that condition records do not. Every routine change requires transport management, regression testing across affected document types, and careful review of side effects, since a routine bug can silently produce wrong prices across large volumes of orders before anyone notices, especially if the routine only misbehaves under specific field combinations. In S/4HANA, the same VOFM-based mechanism generally continues to exist for on-premise and private cloud, though extensibility governance is often tighter, and public cloud editions restrict custom ABAP routine development to defined extension points, pushing some of this logic toward BAdIs or side-by-side extensions instead of classic VOFM routines. Consultants should verify current extensibility scope for the specific S/4HANA edition before assuming classic routine maintenance is available, since restrictions and available extension patterns can differ by release and licensing model. Group conditions and condition exclusion groups are related advanced mechanisms worth understanding alongside routines. A group condition allows a discount to be calculated based on a combined quantity or value across multiple line items sharing a group key, rather than per line item independently, which matters for volume discounts that should reward total order size rather than individual material quantities. Condition exclusion groups let the system compare several conditions that would otherwise both apply and keep only the best one for the customer (or the one defined by the exclusion procedure), preventing unintended stacking of discounts that were never meant to combine.

Code example

* Simplified illustration of routine assignment in pricing procedure (conceptual, not full syntax)* Pricing Procedure Line for condition type ZFRT (custom freight surcharge)* Requirement Routine: 901  -> "Only apply if shipping condition = 02 (express) and doc type = OR"* AltCalcType Routine: 0 (standard) - uses normal rate x quantity* AltBaseValue Routine: 902 -> "Base value = gross weight of the item, not net value" * Pseudocode representation of Requirement Routine 901 logic:IF komk-auart = 'OR' AND komp-vsart = '02'.  sy-subrc = 0.   "condition line is relevant, proceed to access sequenceELSE.  sy-subrc = 4.   "condition line skipped, no record lookup performedENDIF. * Pseudocode representation of Alternative Base Value Routine 902 logic:xkwert = komp-ntgew.   "use item gross/net weight instead of net value as base* This changes what the ZFRT rate (e.g., per KG) is multiplied against.

Real project scenario

A metals distributor needed freight surcharges calculated on shipment weight rather than order value, but only for express shipments on domestic sales orders; regular ground shipments used a flat handling fee instead. The team implemented a requirement routine to restrict the express surcharge condition to the correct shipping condition and document type combination, paired with an alternative base value routine to switch the calculation base to total gross weight. During testing, a defect surfaced where return orders inherited the same routine logic and incorrectly applied outbound freight surcharges to credit memos; the fix added a document category check inside the requirement routine and the team documented the rule so future routine changes would explicitly consider all document categories, not just the originally requested scenario.

Common mistakes

• Writing requirement routines that only account for the originally requested document type, missing return orders, credit memos, or intercompany documents that flow through the same pricing procedure. • Using alternative calculation type routines that bypass statistical condition handling, causing incorrect postings to accounting. • Changing an alternative base value routine without checking every condition type and pricing procedure that shares the same routine number, since routines are reusable and changes can have wide blast radius. • Failing to regression test routine changes across all sales document types and delivery scenarios before transport to production. • Assuming custom routines are available identically across all S/4HANA deployment models without checking extensibility restrictions, especially in public cloud. • Not documenting routine business logic outside the code, leaving future consultants unable to explain why a routine behaves a certain way.

Best practices

• Reserve requirement, alternative calculation type, and alternative base value routines for logic that condition records genuinely cannot express. • Explicitly test routine logic against all relevant document categories, not just the primary use case, including returns and credit memos. • Track routine reuse across pricing procedures before making changes, since one routine number can affect multiple condition types. • Maintain external documentation describing each custom routine's business purpose and edge cases handled. • Confirm current extensibility options for the target S/4HANA deployment model before designing a solution around classic ABAP routines. • Use group conditions and exclusion groups where the requirement is about combining or comparing discounts, reserving custom routines for true calculation logic gaps.

Interview angle

At advanced level, interviewers look for clear separation between what condition records and access sequences can do versus what requires a routine, plus awareness that routines are shared, numbered objects with wide impact. A strong answer explains a real routine scenario, describes the specific business rule it solved, and names at least one regression risk the team had to test for, showing genuine hands-on exposure rather than textbook recall.