A calculation step is a container for a pricing condition template, which determines the behavior of the step and how to retrieve the data required to perform the calculation.
The Pricing Condition Template is the functional equivalent of the SAP "Condition Type." The template determines the nature of the pricing condition (whether it’s a price, a discount, or a surcharge) and helps the pricing engine find the data. When integrating with an ERP, the unique ID of the pricing condition template maps directly to the SAP condition type ID.
The meta type of the Pricing Condition Template determines its behavior:
-
Price: Establishes the base price for calculation (Quantity × Condition Value).
-
Discount (Amount / Percentage / Flat Rate): Calculates fixed discounts, percentage-based discounts and surcharges, or uniform flat rates applied across the order.
-
Subtotals (Last Valid Value, Minimum, Maximum, Summation): Capture intermediate totals (like the sum of all previous discounts) and store them in memory so subsequent steps (like Tax) can reference them. They don’t modify the order total.
-
Free Good: Adds free products to the order based on purchase conditions.
-
User Exit Only: Runs custom code rather than standard calculations.
The condition level determines whether the pricing condition applies to the entire order total or specific product line items.
The pricing condition template links to a search strategy, which tells the pricing engine the prioritized sequence of keys to use when looking for the condition record. The search strategy consists of one or more search strategy steps in sequence. Each step links to a key type, which is a combination of key attributes. For example, a key type can include key attributes that specify a specific customer, a specific product, and a specific market.
Select the Exclusive checkbox to stop searching upon finding the first condition matching the keys. Otherwise, the pricing engine continues searching and applies the last matching condition.
To avoid storing millions of pricing conditions on the offline mobile device, use a hierarchy search to look for broader pricing rules defined at higher organizational levels. You can apply a percentage discount to either a specific tier in the customer hierarchy or the product hierarchy. For example, if you have 1,000 customers and 10,000 products, searching without hierarchy results in 10 million condition records returned. With a hierarchy search, you can limit the results to a smaller number. For example, a searcxh with 10 customer groups and 50 product categories returns 500 condition records.
Don't combine a customer hierarchy search and a product hierarchy search in the same key type, as that approach forces the pricing engine to cross-reference every customer node against every product node, which can degrade performance. For example, if the customer has four hierarchy levels and the product has five levels, the result is 20 searches per search step.
Calculation steps are highly configurable; they can reference the results of previous calculation steps to act as subtotals, apply specific rounding rules, and dictate to which order attribute the result is written. To use the result of a previous step, use a step reference. In a percentage step, for example, you can use a step reference to retrieve the previous step result for which to calculate the percentage. In a subtotal step with a meta type like Minimum, Maximum, or Summation, you can use a step reference to retrieve the results of a range of steps (for example, 10–15) or a list of steps (for example, 10, 12, 15).
When calculating a required condition such as a base price, you can mark a step as mandatory. If a step is mandatory and has no linked pricing condition template, the calculation stops and the mobile device shows an error message.
For a value that is not directly added to the order item’s final total, you can mark a step as statistical. Results calculated in statistical steps can be used in subsequent steps. One type of statistical step is an accrual step, which is used for items that are technically part of the calculation but don’t immediately change the net price shown to the customer. The result of an accrual step is recorded for internal reporting or future financial settlement: for example, a marketing rebate or promotion to be deducted later.
Use a Calculation Group to classify types of order items and apply behaviors to them. For example, you can create a “free good” group for promotional items, then create a 100% discount step that applies only to that group.
For interim values that you need to preserve until the end of the calculation, use Calculation Variables. There are six copy variables and six carryover variables. When you store a result step in a copy variable, it overwrites the variable value with the step result. When you store a step result in a carryover variable, it adds the result to the variable value.
To override the standard pricing logic, add a User Exit: custom Apex or JavaScript code that affects the current condition base, the calculation result, or whether to run the step at all.
To log a step and make it available for printouts and reports, mark the step print relevant.