SAP CPQ Local Pricing vs Stateless Pricing vs Document Pricing

[kelvinye]

Introduction

The Document Pricing feature was introduced some time back in 2023 (I think), and with each new CPQ releases the Document Pricing becomes more prevalent - more customers are adopting it for their project.

For those who are new to this topic: both the Stateless Pricing and Document Pricing are pricing provided by SAP Variant Configuration and Pricing Service, one might ponder what's the difference between the 2 option since pricing still comes from CPS?

Note: SAP Variant Configuration and Pricing Service is also known as VCP, but I will refer to as CPS (prefers the older name) in this article.

To better understand, let's recap on the following topics in the following order:

1. Recap - CPQ Local Pricing
2. Recap - Stateless Pricing
3. Finally - Stateless Pricing vs Document Pricing

 

Recap - CPQ Local Pricing

CPQ Local Pricing refers to one where prices and/or costs are stored locally in CPQ (Pricebooks and/or Custom Tables), and then have the CPQ Calculation Engine to compute and provide the results. In this section let's briefly explore the capabilities and power of CPQ Calculation Engine.

Item level calculations

On item level, users can give discounts by percent, discounts by amount, unit net price or extended amount (subtotal). In a typical discount scenario, user applies a discount percent of 25, and CPQ computes forward and calculates the discount amount, net price, extended amount - as shown below.

CPQ supports reverse calculations, meaning to say that the calculation engine not only computes forward but also in reversal manner. In the example below instead of applying a discount percent, user applies a discount amount and the calculation engine not only computes forward for the net price and extended amount, it also does a reverse calculation for the discount percent.

In another example, user sets the extended amount for Qty of 2 items, the calculation engine does a reverse calculation for the net price (unit price), discount amount and discount percent.

Header level calculations

Sometimes applying discounts on item level can be cumbersome in the scenario for large Quotes with hundred of items, and here's where CPQ allows user to set header level discounts or Quote total price - the calculation engine does a reverse calculations and pro-rates out the discounts onto the product type and the item level.

In short, whichever way the discounts or prices are applied the numbers (i.e discount percent, discount amount, net price, etc) will always tally up - now that's really sweet isn't it?

Recap - Stateless Pricing

In Stateless Pricing, prices are fetched from the CPS pricing service in real-time, without needing prices to be replicated and store locally in CPQ Pricebooks and/or Custom Tables.

The Requests and the "Forgets"

Take this scenario: User is on the product configurator doing configuration, on each attribute change Stateless Pricing fetches pricing from CPS, thereafter on adding the product to Quote CPQ stores the CPS pricing response into a hidden item field (VCPricingPayload or VCItemPricingPayload) and forgets about it - thus on item level when user e.g. gives a discount percent, CPQ does not do a Stateless Pricing call.

CPS pricing response payload

In standard integration, the CPS pricing response the net value is mapped onto the standard List Price column in CPQ. Net value is the "final" computed amount, after taking into account list price, freight, discounts, surcharges and miscellaneous condition types in a pricing procedure.

Users can choose to apply further discounts to provide a better selling price, and in this case it will leverage on the CPQ calculation engine to compute the discounts and prices. Now one may also wonder: if the item net value has already factored in the discounts in stateless pricing, won't a further discounts in CPQ actually sort of "doubles" it up?

As mentioned, CPQ stores each CPS pricing response on a hidden item field (VCPricingPayload or VCItemPricingPayload), to avoid situation such as above i.e. double discounting, one can write a script to iterate the CPS pricing response to extract each pricing condition and have them mapped out onto the desired item fields.

Example script to mapped out each pricing condition to CPQ item fields:

In the example below, instead of using the standard integration which maps the net value to CPQ List Price, the script maps the pricing response list price (PR00) and discounts (ZRA1) onto the respective item fields, and then have CPQ calculation engine derived the net price (which is the pricing response net value). In this way, user have clarity on the various pricing conditions, allowing them to be better equip when applying or even reducing the discounts.

The above may look like a perfect solution but it still uses CPQ calculation engine which differs from how ERP calculates - you will sometimes encounter a scenario where there are 1 cents or 2 cents difference in the amount in CPQ Quote vs ERP Sales Order (there is difference in how each system does the rounding and the number of decimals involve at each step).

Finally - Stateless Pricing vs Document Pricing

To avoid confusion, Document Pricing by no means replaces the Stateless Pricing, Stateless Pricing is still use when one is doing the product configuration. Rather the Document Pricing is an additional feature which allows user to make changes on line items e.g. discount percent and have it call CPS for price determination and gets back the discounted amount.

Document Pricing takes after the ERP calculation technique, the example below illustrates ERP calculation technique: the calculation steps through from step 10 to step 40, if user decides to give a manual fixed discount amount at step 40, it does not do a reverse calculation to determine the discount percent, unlike CPQ Calculation Engine.

When CPQ have the document pricing feature turned on, you will be able to see the list of pricing procedures available from CPS from within CPQ setup - add the desired pricing condition and map the item fields to each pricing condition.

On using document pricing, the item fields are simply "space holders", it doesn't matter if you map PR00 to a standard List Price field or any standard/custom item field, the eventual calculation will all just work! However we usually try to find an equivalent item fields to map, e.g. PR00 to standard List Price item field and not create additional custom item fields unnecessarily. This is also important if you intent to mixed items using variant pricing and CPQ local pricing, then it make more sense to map them appropriately to present the figures correctly on the Quote.

One can also view the price condition details from within CPQ, there's no need to head over to CPS to view them.

Note: Document Pricing feature needs to be turn on via a support ticket.

Conclusions

After going through my article which describes CPQ Local Pricing, Stateless Pricing and Document Pricing, I hope one can better understand the differences and have a better know-how on its use and application.

Speaking of advantages and disadvantages, IMO I don't think one is more superior than the other, e.g. CPQ Local Pricing via CPQ Calculation Engine will always have an edge in performance over pricing from CPS, but you will need to have all pricing conditions replicated and stored locally in CPQ. At the end of the day it really depends on the customer needs, their system architecture as well as future plans.

I hope you enjoy the read and if you're interested in how-to-setup-document-pricing, drop me a comment or DM. Signing off - Kelvin.