CX Works

A single portal for curated, field-tested and SAP-verified expertise for your SAP Customer Experience solutions. Whether it's a new implementation, adding new features, or getting additional value from an existing deployment, get it here, at CX Works.

Get to Know All Significant Specifics of SAP CPQ Pricing and Calculations (Part 1/2)

We have faced lots of confusion or lack of understanding in questions people have posed about SAP CPQ (Configure Price Quote) pricing in the last few years. This is understandable as the pricing implementation is of sizable complexity with the functionality divided between several modules.


The standard learning journey would be to read multiple detailed technical documentation pages, for all participating modules, and partake in several SAP CPQ implementations. This article and its sequel will give you a short guide to SAP CPQ pricing that you might reach for at any point of your later CPQ career. 

Table of Contents

Difference Between Pricing in Configurator and Pricing in Quote

We in the SAP CPQ community often meet people that are comfortable working with sales software and who expect that pricing is resolved in a single point of the user journey or that a single functional object is the carrier of pricing routines. With SAP CPQ, this is not the case - the application has at least two distinct phases of the standard user flow: individual product configurations (Configurator module) and the quoting phase, where all product configurations are present in the form of items.

Also, the two modules are not everything that drives pricing - there are a few more in SAP CPQ, like discounting rules, where default discounts are specified (applied when a product is added to quote) and minimal and maximal allowed values are set.

This is all a perfectly justified business flow - price generation must occur in Configurator too, as salesman has to see how prices change while altering product attribute selections.

A simplified pricing paradigm of SAP CPQ would be this: the task of configuration (aided by discounting rules) is to produce values for the basic pricing fields (list price, cost, monthly recurring price and cost, discount, multiplier and quantity) while the quote module should allow for some of them to be conditionally modified (e.q. discounts by following discounting rules) and, more importantly, it should roll out the base price values further to calculate all other item, product type total and quote total pricing fields.

It is simplified as, for example, custom item fields might be defined together with their calculation formulas and those should enter the quote-level calculations too.

Pay attention to the pricing elements being output of the configuration phase, that you can see in the right portion of the screen. There you will find product price with prices of regular attributes calculated in right away, while all attributes (line items and regulars) will be listed separately at the bottom.



Here is how the same configuration looks when added to quote:



Do notice that the quote does not display configuration attributes and their prices unless those are marked to be line items. 
Just several standard item pricing fields are activated for the example tenant (net price and extended amount) while there are also many others and it is the standard practice too, to introduce multiple custom item pricing fields.

Pricebook Lookup and Custom Pricing

Two pricing types are the first choice an implementer has to make when building a model. The choice can be made on a very granular level - up to the individual attribute values.

If standard SAP CPQ pricebooks are used it implies individual prices and costs (both one-time and recurring) for products and attributes are obtained by part-number search in pricebooks (and eventually by price code too).
Custom pricing means that the same pricing values will be obtained from custom-built SAP CPQ formulas, which combine plain numbers and SAP CPQ tags. Those will be validated in run time and specific prices will be assigned to products and attribute values.


Location of modeling to be executed is different for the two modes: with Pricebook Lookup the modeler just selects the option, sets the part numbers and the rest of the work is spent on populating pricebooks. With Custom Pricing each product and attribute value has to get its own formula assigned inside of the product setup pages. But again, the selection between Custom Pricing and Pricebook Lookup you can make on the level up to the individual attribute value.

Let us spend a bit of time on basics of SAP CPQ markets and currencies so we see how the pricing type selection further reflects to quote.

Currencies, markets and pricebooks are standard system objects which are user defined and provide functionality which is apparent from their names. A market can use just a single currency and a pricebook can belong just to a single market. Salesman is able to select a different market or pricebook for a quote at the header section (the currency is automatically set by market selection):

If just the selected market gets changed, a default pricebook for the new market will automatically be applied.

Now, when the salesman changes the market or just the pricebook, all configurations in quote get re-validated and for all elements which are priced by Pricebook Lookup the new prices are fetched from the newly selected pricebook. Pricebooks keeps prices in the market currency, so no exchange rates and market factors are applied (and you are advised not to use those).

What happens with configuration elements which had Custom Pricing selected as the pricing mode? They are not affect by pricebook change but a market change will reassign those too.
The change here is that the system-defined currency exchange rates (and eventual additional market factors) will get applied in order to express prices in the currency of the newly selected market.

Now you understand how important it is that the rules that you build in the system are resilient to market and pricebook selection changes and that they contain logic, numbers and checks which are universally correct for all users working in the system.
So, do bear in mind the following four forms of decimal numbers while modelling CPQ formulas (here given on the example of the current item's list price):

  • <*CTX( Quote.CurrentItem.ListPrice.DefaultDecimal )*>  - gives price in the default market and en-US number format, with no thousands separator and the default number of calculation decimals
  • <*CTX( Quote.CurrentItem.ListPrice.DefaultDisplay )*>  - gives price in the default market and user number format

  • <*CTX( Quote.CurrentItem.ListPrice.MarketDecimal )*>  - gives price in the current market and en-US number format, with no thousands separator and the default number of calculation decimals

  • <*CTX( Quote.CurrentItem.ListPrice.MarketDisplay )*> - gives price in the current market and user number format


Equivalents of these forms you will also find in scripting.

Recurring Prices

SAP CPQ does provide out of the box implementation for monthly recurring prices but you have to activate those by setting an app parameter. When that is done recurring list price and cost fields will get displayed in all places in setup where list price and cost fields are displayed currently. Those are noted with MRC (Monthly Recurring Cost) prefix. Be mindful that this is support only for base monthly recurring prices and costs. Also that SAP CPQ does not deal with start and end dates of the subscription period and does not calculate the period totals. Monthly recurring totals are just sums of monthly recurring prices for individual items - if you want more you have to add logic and use custom fields to define periods and their totals. 

SAP CPQ integrates with other SAP Sales Cloud software, like SAP Subscription Billing, that offers much more granular support for subscriptions. 

Configurator Pricing in More Details

Now let us unmask what happens in Configurator and how prices of attributes and products can be combined.

Do note at first that an attribute might be set to be a line item in the context of an individual product or it does not have to be. If it is a line item that it will show as a separate subitem in quote and its price will not be summed to the product line price. Only fields like Rolled Up List Price will calculate in prices of line items too.

Now let us see what happens with prices of attributes which are not line items.

If the product price mode is set to Pricebook Lookup than the attribute value prices will be summed up to the product price and will always operate as a whole. Things can be different if you opt to implement Custom Pricing for a product. There is an extra choice to be made for Custom Pricing: between product Base Price or product Pricing Formula. If you go with just Base Price then it will be used as the basis of the product item price and prices of individual non-line-item attributes will get summed to it.



If the Pricing Formula is set, the Base Price will be ignored (as in the screen above) and the runtime validation of the formula will become the price of the product line. So the pricing formula will disregard individual prices of all attributes which are not line items, while those which are line items are, as stated in the start, independent of this. The Pricing Formula goal is to define a custom logic that calculates the product item price and if individual attributes need to be included you should do that in the formula.

Conclusion

Your next reading should be Part 2 of this series "

As pricing is not the only topic that you might need an expert's insight for, please check the whole series of articles where all different functional topics of SAP CPQ are covered.

Also, if you decide to engage with implementations of SAP CPQ projects you can visit official SAP CPQ Help where you would find many web pages covering technical details of all pricing-related topics.