User Exits and Fast Group Condition Processing

In fast group condition processing, some pricing user exits are compatible with this process, whilst some are not. A list of known compatible and incompatible user exits can be found in SAP Note 1487240. To help evaluate your own pricing user exits for compatibility with fast group condition processing, sample compatible and incompatible users exits are illustrated below.

Caution Caution

These are examples of possible coding and serve as a guideline only to understanding the type of user exits that are compatible or incompatible with this procedure.

End of the caution.

Sample Compatible and Incompatible User Exits

Sample Compatible User Exit

A type of compatible user exit does not have complex cross-item logic, for example when a pricing item is used in the method implementation as illustrated by the sample code in the figure below:

Example Example

This figure illustrates a sample user exit without complex cross-item logic:

This graphic is explained in the accompanying text.

User Exit Compatible with Fast Group Condition Processing

End of the example.

Incompatible User Exits

Fast group condition processing is not compatible with complex user exit logic because the pricing engine uses its own internal logic for selecting items with value-dependent group conditions. The pricing engine cannot have any control over changes via user exits. In particular, the pricing engine cannot react to changes to calculation-relevant attributes (for example base value, rate and so on) of multiple items from the following exits:

Group processing level calculation exits (for example from overwriteGroupConditionValue of value formula exit)
Item level calculation exits (for example from overwriteConditionValue of the value formula exit)

Example Example

This figure illustrates a sample user exit that is incompatible with fast group condition processing:

This graphic is explained in the accompanying text.

Sample User Exit Incompatible with Fast Group Condition Processing: Sample 1

Assuming that an incompatible user exit of the type illustrated above is used, and the business transaction comprises three items, item 10, item 20, item 30 and a (value-dependent condition) percentage group condition, 1GRP with a rounding difference distribution and a non-group discount condition 1DIS. In addition to this, a pricing procedure has a condition value formula and you have to change the base value of the condition 1DIS.

The business user changes the quantity of item 20. The process flow in the pricing engine is as follows:

Item calculation at item level for item 20.
Cross-item pricing comprising:
1. Calculation of the value-dependent group condition 1GRP.
2. Recalculation of items to adjust results due to any possible changes to the group condition 1GRP (in this case due to rounding difference compensation).
During the recalculation of item 20, user exits such as value formula, base formula and so on are executed but the base value of 1DIS of item 30 is not recalculated because the pricing engine is not aware of any changes and does not recalculate items after group calculation.

However, if it is the case that there is a condition value formula in the pricing procedure, and you have to change the base value condition, 1DIS of the other items in the pricing procedure then in the above example, 1DIS is executed during recalculation of item 20, with the result that the base value of 1DIS belonging to item 30 could be changed. However, in this example item 30 will not be calculated which results in errors in the total value.

End of the example.

Example Example

This figure illustrates another type of user exit that is incompatible with fast group condition processing:

This graphic is explained in the accompanying text.

Sample User Exit Incompatible with Fast Group Condition Processing: Sample 2

In this piece of sample coding, the user exit has attempted to set the condition value of an item by aggregating the condition values of other items. If fast group condition processing is used, then certain items may get the wrong calculation because they are not recalculated after group condition calculation. For example, if an item is designated for distributing rounding difference during group condition processing, consistent calculation is usually guaranteed by recalculating that item alone to update the values. However, if any other conditions of any other items require recalculation due to changes in the value-dependent item, then the logic in the user exit above does not communicate to the pricing engine any real reason for recalculating those items. So by default, the pricing engine does not recalculate prices and errors arise.

End of the example.