5.5 Special Pricing Functions: Condition Exclusion, Group Conditions, Header Conditions, Condition Update, and Supplements

Special Pricing Functions: Condition Exclusion, Group Conditions, Header Conditions, Condition Update, and Supplements

While standard access sequences and calculation schemas resolve everyday pricing scenarios, enterprise sales environments frequently present complex commercial requirements: preventing multiple promotional discounts from stacking, rewarding bulk purchases spanning diverse product lines, and managing retroactive annual volume rebates.

SAP S/4HANA provides advanced pricing capabilities—Condition Exclusion, Group Conditions, Header Distribution, and Settlement Management—to govern these demanding commercial scenarios.

---

Condition Exclusion Groups: Preventing Margin Erosion

In standard pricing, if a customer qualifies for a Customer Discount (K007), a Material Discount (K004), and a Seasonal Promotional Discount (ZPRO), the pricing engine will apply all three additively. This cumulative stacking can severely erode profit margins.

To prevent over-discounting, SAP provides Condition Exclusion Groups (configured via transactions OV31, OV32, and V/08).

+-------------------------------------------------------------------------+
| Configuration Architecture: Condition Exclusion                        |
+-------------------------------------------------------------------------+
| 1. Transaction OV31: Define Condition Exclusion Groups                  |
|    • Group Z001: Standard Customer Discounts (K005, K007)               |
|    • Group Z002: Special Promotional Discounts (ZPRO, ZVOL)             |
|                                                                         |
| 2. Transaction OV32: Assign Condition Types to Exclusion Groups         |
|                                                                         |
| 3. Transaction V/08: Assign Exclusion Procedure to Pricing Procedure    |
|    • Select Exclusion Method (A, B, C, D)                               |
+-------------------------------------------------------------------------+

The Four Primary Exclusion Methods

When assigning exclusion groups to a pricing procedure in transaction V/08, the consultant selects an Exclusion Method:

Condition exclusion also works without exclusion groups. If the condition exclusion indicator is set in a condition type or a condition record, every later condition type in the pricing procedure whose requirement routine checks this indicator is deactivated. Conditions before it are not affected. Set in the condition type, the indicator applies to all records of that type; set in a condition record, it applies only to that record. In the standard procedure, PR00 can carry requirement 2 and K007 requirement 6: if the indicator is set on the PR00 record, K007 is excluded.

How Deactivated Conditions Appear in Sales Orders

When a condition is suppressed by condition exclusion, SAP does not delete the line from the pricing screen. Instead, the condition remains visible on the item condition screen but is marked as inactive, with an inactive reason that points to condition exclusion. Its value is displayed, but it does not count toward the net value, so the pricing analysis still shows why it was excluded.

---

Group Conditions: Cross-Item Scale Aggregation

A Group Condition allows the pricing engine to evaluate scale tier thresholds by summing quantities or values across multiple line items in the same sales document.

The Business Scenario

Consider a company selling office supplies. The company offers a quantity scale for all materials in Material Group 01 (Writing Instruments):

• 1 to 9 units: $10.00 / unit (0% discount)
• 10+ units: $8.00 / unit (20% discount)

A customer orders three distinct pens in the same sales order:

• Item 10: Blue Pens (Material Group 01) — Quantity: 4 EA
• Item 20: Black Pens (Material Group 01) — Quantity: 3 EA
• Item 30: Red Pens (Material Group 01) — Quantity: 5 EA

Without Group Condition:

Each line item is evaluated independently:

• Item 10 (4 EA) < 10 units $\rightarrow$ $10.00 / unit
• Item 20 (3 EA) < 10 units $\rightarrow$ $10.00 / unit
• Item 30 (5 EA) < 10 units $\rightarrow$ $10.00 / unit Result: Customer receives no volume discount because no individual line item reached 10 units.

With Group Condition (KGRPE = [X] in V/06):

The condition type is flagged as a group condition and given a group condition routine that decides which items are added together. The official course lists three formulas:

• Formula 1 (complete document): adds up all items that carry the same condition type.
• Formula 2 (all condition types): adds up all items, regardless of condition type.
• Formula 3 (material pricing group): adds up all items with the same material pricing group (field KONDM).

With formula 3 and the three pens sharing one material pricing group:

1. The system aggregates the items: $\text{Total Group Quantity} = 4 + 3 + 5 = 12\text{ EA}$.
2. The system reads the scale using the aggregated quantity of 12 EA.
3. Because $12 \ge 10$, the 20% discount level ($8.00 / unit) is reached.
4. The system applies the $8.00 rate to all three line items.

Apportionment and Rounding Differences

When a group condition represents a flat fixed monetary amount (e.g., $100.00 order surcharge) rather than a unit rate, the system must apportion the total amount across eligible line items. SAP apportions the amount proportionally based on each item's relative net value or weight.

To ensure that rounding does not make the item parts differ from the header amount, set the rounding difference comparison indicator in the condition type: the system then adds any difference to the item with the largest value.

---

Condition Update: Limits per Condition Record

If the Condition update indicator is set in a condition type, the system accumulates values in each condition record of that type. In the condition record you can then set limits: a maximum condition value, a maximum number of orders, or a maximum condition base value. The cumulative values can be displayed in the condition record, and once a limit is exceeded, the record is no longer used. A typical use is a promotional discount that should end after a budget is used up or after a fixed number of orders.

Condition Supplements

A condition supplement lets you maintain the values of further condition types inside the condition record of a main condition type, such as PR00. Supplements have no access sequence of their own; they are found and maintained together with the underlying PR00 record. You define the allowed supplements in Customizing of the main condition type by assigning a separate pricing procedure (for example PR0000) that lists the supplement condition types. A price and its associated discounts can then be maintained and determined in one step.

---

Header Conditions vs. Item Conditions

Pricing conditions can operate at either the item level or the document header level:

Distribution of Header Conditions

Header conditions are entered manually and are not found by automatic pricing; in the standard system you cannot create condition records for them. What happens next depends on the condition type:

• Percentage header conditions (such as HA00) are copied to every item with the same percentage.
• Absolute header conditions that are group conditions (such as HB00) are distributed across the items. By default the distribution follows the items' share of the net value: if item 10 represents 60% of the document net value and item 20 represents 40%, a $100.00 header discount becomes $60.00 and $40.00.

The basis for distribution can be changed in the pricing procedure through the alternative condition base value, for example routine 12 (gross weight), 13 (net weight), or 01 (volume).

---

Diagnostic Troubleshooting: The Pricing Analysis Tool

When a pricing condition record fails to determine in a sales order, the most common beginner mistake is guessing the cause. SAP S/4HANA provides a built-in diagnostic engine: the Pricing Analysis Tool.

How to Access the Analysis Tool:

1. Open the sales order in transaction VA02 (Change) or VA03 (Display).
2. Navigate to the line item condition screen (Item $\rightarrow$ Conditions).
3. Click the Analysis button at the bottom of the screen.

+-------------------------------------------------------------------------+
| Pricing Analysis Screen (VA02 / VA03)                                   |
+-------------------------------------------------------------------------+
| [-] Pricing Procedure RVAA01                                            |
|     [+] Step 10  PR00 (Base Price)           --> Record Found (Table 005)|
|     [-] Step 105 K004 (Material Discount)                               |
|         [-] Access Sequence K004                                        |
|             [x] Step 10 (Table 005 Customer/Mat) --> Condition not found|
|                 • Field KUNNR = 0001000050                              |
|                 • Field MATNR = M-01                                    |
|             [ ] Step 20 (Table 004 Material)     --> Requirement 2 not met|
+-------------------------------------------------------------------------+

What the Analysis Screen Reveals:

• Access Sequence Traversal: Displays every table queried in order.
• Field Values: Shows the exact values extracted from KOMK and KOMP at runtime.
• Requirement Routine Status: Indicates whether an access step was bypassed because an ABAP requirement routine returned SY-SUBRC <> 0.
• Condition Record Found / Missing: Explicitly states whether a record existed in the database table for those runtime keys.
• Exclusion Status: Flags whether a condition record was located but deactivated by a Condition Exclusion Group.

---

Repricing Functions in Sales Documents

When order attributes change (such as customer delivery date or shipping conditions), users can trigger repricing by clicking the Update button on the document condition screen and selecting a Pricing Type:

• A (Copy condition records and re-determine scales): Retains existing rates but recalculates tiered scale rates based on updated quantities.
• B (Carry out completely new pricing): Erases all existing condition records and executes the pricing procedure from scratch (manual conditions are lost!).
• C (Copy manual pricing elements and re-determine others): Retains manually entered discounts or surcharges while re-evaluating automatic condition records.
• G (Copy pricing elements unchanged and re-determine taxes): Keeps all pricing unchanged and only recalculates statutory output taxes (MWST), standard when changing Ship-to addresses.

---

Rebates in SAP S/4HANA: From SD Rebate Processing to Condition Contracts

In SAP ECC, customer rebates were handled with SD rebate processing: rebate agreements (VBO1/VBO2) with rebate condition types such as BO01 and BO02. Every rebate-relevant billing item was recorded in the rebate index table VBOX, which could grow very large in high-volume businesses.

In SAP S/4HANA, SD rebate processing is not the target architecture: new rebate agreements are not supported, and existing ones can only be processed until the end of their validity. The successor is Settlement Management with condition contracts (maintenance transaction WCOCO). Condition contract settlement determines the business volume from the source documents when settlements run, posts accruals, and settles with partial, final, and delta settlements. Section 5.8 covers condition contract management in detail.