SD Pricing Part 7: Pricing Routines — Requirements, Alternative Calculation Types and Base Values

📌 KEY POINTS
✅ Requirement routine (Reqt column): condition is determined only if the routine returns sy-subrc = 0 (e.g. requirement 2 = item relevant for pricing).
✅ Alternative calculation type (AltCTy): computes the condition value with custom logic instead of rate × base (e.g. 11 profit margin).
✅ Alternative condition base value (AltCBV): changes the base the rate applies to (e.g. net value, weight).
✅ Custom routines are created in VOFM (900–999), activated and assigned in the pricing procedure — no modification of standard code.
⚠️ Pricing routines run for every item and every repricing — slow SELECTs here slow down every order.

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 6 covered exclusion and groups. Now logic beyond configuration.

━━━━━━━━━━━━━━━━━━━━
▶ 1. REQUIREMENT ROUTINES

• Assigned per procedure line (Reqt).
• Examples: 2 = item relevant for pricing, 4 = cost, 10 = plant is set (tax), 23 = only in billing.
• Custom: condition only for export customers, only for certain item categories.

━━━━━━━━━━━━━━━━━━━━
▶ 2. ALTERNATIVE CALCULATION TYPE

• Replaces the standard calculation.
• Examples: 11 profit margin (net − cost), 16 tax calculation.
• Custom: freight as a percentage with minimum, price by formula.

━━━━━━━━━━━━━━━━━━━━
▶ 3. ALTERNATIVE CONDITION BASE VALUE

• Changes the base: e.g. net value instead of gross, or a weight- or volume-based base.
• Custom: base = net value excluding certain conditions.

━━━━━━━━━━━━━━━━━━━━
▶ 4. CREATING CUSTOM ROUTINES

• VOFM > Requirements > Pricing (or Formulas > Condition value / Condition base value).
• Copy closest standard, number 9xx, activate, assign, transport.
• Use KOMK (header), KOMP (item), XKOMV (conditions) — read-only except the output fields.

━━━━━━━━━━━━━━━━━━━━
▶ 5. GOVERNANCE AND PERFORMANCE

• Register routines with owner and purpose.
• No database updates, minimal SELECTs, use buffered tables.
• In S/4HANA prefer standard features (e.g. pricing function modules, BAdIs) where available.

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

1. Check whether configuration can express the rule.
2. If not, copy the closest standard routine to 9xx.
3. Implement minimal logic, activate, assign in V/08.
4. Test with positive/negative cases and measure performance.

✅ CHECKPOINT: the custom condition appears only for items meeting your rule, and pricing time is unchanged.

A client added a custom alternative calculation type that read the customer's contract table with a non-buffered SELECT for every condition line. Orders with 400 items took minutes to price, and billing runs overran their batch window. The routine was rewritten to read the contract once per document into a buffer (static internal table keyed by document), and the logic was simplified. Pricing time returned to normal and the routine was added to a performance-reviewed register.

• Modifying standard routines instead of creating 9xx.
• Expensive SELECTs in routines called per item and per condition.
• Forgetting the KOBEV form counterpart for requirements.
• Using routines where configuration (condition tables, exclusion) would do.
• Not activating or transporting routines.

• Try configuration first; use routines for real logic only.
• Copy standard routines to 900–999 and keep them small.
• Buffer data reads; avoid database access per call.
• Register and review custom routines.
• Test performance with large orders and billing runs.

Questions: "What is a pricing requirement?", "Difference between alternative calculation type and alternative base value?", "How do you create a custom pricing routine?"
Strong answer: requirement routines decide if a condition applies (e.g. 2 item relevant for pricing), alternative calculation types compute the value (e.g. 11 margin), alternative base values change the base; custom 9xx routines in VOFM using KOMK/KOMP/XKOMV, activated and assigned in V/08, with performance and governance care.