Get to Know All Significant Specifics of SAP CPQ Pricing and Calculations (Part 2/2)
This article is continuation of the previous article, both trying to give a digested overview of SAP CPQ pricing with the expert's focus on usual pain points.
Table of Contents
Quote Pricing in More Details
It was already stated the quote will start from basic pricing fields and calculate all other item pricing fields and also totals on the level of product type and quote.
This is facilitated through calculation routines where the standard pricing fields are always calculated by applying the same formulas (e.g. item Net Price is obtained by adding item Discount to item List Price).
But exactly how these formulas are organized and included to the execution chain differs between two quote engines (CPQ has two versions: 1.0 and 2.0). This is one of few places where the two engines differ from the perspective of an application modeler and we will try to give good hints for both.
Here things evolve around the concept of editable groups, where one is basically an arbitrary clustering of pricing fields that can be edited at the same time (and not just pricing fields).
The idea is that we do not allow end users to modify, for example, item discount and item net price simultaneously, as the net price depends on the discount and changing both would be inconsistent. Hence, the two fields should be put in different editable groups. We do allow implementers to put the two in the same group and CPQ will manage if end user updates the two fields simultaneously, but we also give a mechanism for project implementers to avoid this and and editable groups are solution for that exactly.
After the value of any field inside of a single editable group is changed, the quote Calculate action is guaranteed to run. The action will, in turn, run only specific calculation routines, applied for the whole of the quote, that the modeler has set to run for an update inside of the editable group.
So, the task of the "Cart Fields Administration" setup and the tables inside of the module which looks intimidating to many, is to allow modelers to decide which fields will be editable, organize those in several editable groups and decide which quote-level calculations will run for an update in each group (update of any field value inside of the group):
The screen gives you setup applied for the quote status "Preparing" and the user group "Sales".
Now, when you have been introduced to the module with the biggest tables in CPQ setup, let us add few more details.
The three standard system calculations (you see activated for the group 1 in the screen) you are expected to use always as those will calculate all standard pricing fields on the item, product type and quote total levels. You just need to add extra system or custom calculations if those are needed for your use case.
Observe the group 2 where a use case is implemented allowing user to change discount or multiplier on the product type level. It uses the two out of the box, reverse calculations at the start, just to propagate updates to the basic item pricing fields and then executes the three standard calculations to roll out the new item-level values to all pricing fields in quote.
UI controls at the very top of the screen are just reservoirs of all fields (on the level of item, product type or quote) and calculations that you can use in the editable groups.
You do have hovering tips and formulas for each of calculations so you can know what they do exactly.
Maybe some of you, even after we provided explanations in the paragraph above, still think the upper administration module is scary. This is why we fully redesigned it for the engine version 2.
We removed editable groups so people do not have to deal with yet another concept and here they start from a single field in quote and decide which calculations will run for the field update and in which order.
If you select a system field a list will be displayed giving all default calculations that will run for the field value update. You can reorder and modify the list or add other calculations.
If you select a newly created custom field you will start building the list of calculations from scratch.
All occurs in "Quote Fields and Calculations" section in the Quote menu section:
But there are important differences with these elements in comparison to quote 1.0. The first is that the set of fields was sensibly reduced - you will notice many less used fields, like Multiplier, were removed and will not cram in your screen.
The second is that calculations are now fully granular - they calculate value of a single field, which always has a few standard dependencies. You do not have "All Item Fields - Direct" to calculate all item fields at once, but you are expected to chain multiple atomic calculations to include only fields that you need. "Why would more manual work be better?" - you might ask. Because this way you will avoid limitations we had before like not being able to insert calculation of an item custom field in the middle of the existing calculation row. Before, you always had to decide between going before or right after one of the three standard calculations.
Edit-ability of fields is set in the second tab following a different paradigm - you do not do it for individual fields but you select a rule criteria (e.g. users of type Sales who work in SAP company), combine that with a quote status to apply the rule for and then select all fields which will be editable for the specified criteria and the quote status.
Another, equally important difference is that in quote 2.0 prices are kept in CPQ database in the currently selected currency. The reason was to make the quote faster, but you have to do manual conversions when doing SQL reports.
Scripting in CPQ Pricing
CPQ exposes broad IronPython interface that allows you to modify all calculation results described in this and the previous article by coding and applying any business logic of yours.
In Configurator context you can e.g. add scripts that run after every rules execution cycle and further modify already calculated product and attribute prices. You can make the custom logic run only once, at the moment of adding the product to quote and for example modify which attributes will be line items.
In the quote context you can code Custom Calculations and nest those anywhere inside of chains of Calculations described above.
There are multiple concerns with performances and scripting if used arbitrarily to implement these requirements. Please review our series of articles that deal with that exactly.
Behavior Changes with Application Parameters
Many details above can be altered or extended by setting values of CPQ application parameters.
Here we will give just a few examples, where the titles will be parameter labels the way those are specified in the quote 1.0 setup:
Allow Edit List Price on the Cart
You were able to add item list price to an editable group above, but that will not make the field editable if the parameter is not preconfigured to allow that. List Price is a product of configuration and you need to decide if you want to allow the field to be modified in quote too. A similar decision you need to make for the item cost field and this one is controlled by "Allow Edit Cost on the Cart" parameter.
Always Refresh List Price on Reconfigure
With the previous parameter you could have allowed for item list price to be editable in quote, but then the question would arise about what will happen with a user-entered value when the item is reedited and its configuration updated. The same applies for the quote reconfigure action executed in any context. As list price is the main product of configuration both keeping and refreshing the value is a valid business use case. The parameter decides between the two options.
Equivalent parameters exist for cost and discount fields also and those are named "When item’s cost is edited in the quote, upon changing item’s configuration, cost will be recalculated" and "When updating quote item, reapply default discount/multiplier"
Discount Rules for Parent Items in the Quote will be Applied On
CPQ has two sets of fields for discounts: regular ones and rolled up discounts (which apply for the whole item subtree). To exactly which of those will the default rules apply you choose by altering the parameter value, but the default is just the regular item discounts.
CPQ pricing abounds with many specifics of its pricing models and it is hard to grasp all details by just using the standard means to train yourself in CPQ.
This article should reduce the long learning curve and tiring back and forth when you realize omissions in you understanding of CPQ pricing during an implementation.
It is also composed to accentuate and elaborate details around which confusion is usually present, from the expert's previous experience in work with the community. Do not omit to visit the official CPQ Help where you can find comprehensive explanations of all modules that participate in CPQ pricing.
Please note that CPQ pricing is not the only topic where you might feel confused or you need more support to execute quality implementations. Please review the whole series of articles that gives exposition on other functional topics in CPQ.