- SAP Managed Tags
Many of you may know the basic principles of price calculation, but in this blog post, I want to delve into how a complex scenario can be implemented. When it comes to pricing in dynamic systems, there are various factors to consider. Let's explore a specific use case to understand how volume tolerance and deviation can impact pricing in a complex scenario. To illustrate this, we will consider the following use case:
In the ever-evolving industry of book production and distribution, a printing machine manufacturer specializing in book manufacturing, sets out to meet its customers' demands with steadfast dedication. The printing machine manufacturer offers their printing machines as a service, where the outcome, which is the number of printed books, is charged. The company operates with a pricing rate of 5 euros per 1000 books printed. Foreseeing a substantial volume, the customer has forecasted 1 million books per month, prompting the company to tailor its pricing strategy accordingly. With an agreed volume tolerance of 5%, minor deviations do not incite any variation clause or price change. However, for more significant volume discrepancies, the company has established a pre-agreed scale that permits adaptive price adjustments. For instance, a 10% decrease in volume will trigger a 7% price increase, while a 10% volume increase will result in a 3% price decrease. This adaptable pricing model allows the company to adeptly navigate the dynamic landscape of book production pricing, ensuring a responsive approach to customer needs while upholding profitability and competitiveness within the market.
In addition to volume considerations, the company has a committed performance guarantee to uphold. For example, Machine Efficiency is set at 91%. Should the efficiency fall below 90%, a 1 ppt price reduction per ppt performance decrement will be applied. Conversely, any efficiency surpassing 92% will lead to a 1 ppt price increase per ppt performance enhancement. The company has capped the maximum price adjustment at 10%, providing a framework that balances flexibility and stability in pricing adjustments.
Our assumption is that the printed books and performance are sent with individual usage records through an external system to the SAP Subscription Billing system.
Let’s represent this information in a table and fill some examples to enhance clarity (Forecast 1.000.000 books):
| Month | Printed Books | Performance | Price per 1000 books | Performance price adjustment | Expected bill |
| Jan | 950,000 | 91% | 5€ | 950 * 5€ = 4750€ | |
| Feb | 1,000,000 | 92% | 5€ | 1,000 * 5€ = 5,000€ | |
| Mar | 975,000 | 88% | 5€ | -0.02 * 5€ * 975 = -97.5€ | 1. Line: 975 * 5€ = 4,875€ 2. Line: -0.02 * 5€ * 975 = -97.5€ |
| Apr | 1,100,000 | 91% | 5€ * 0.97 = 4.85€ | 1,100 * (5€ * 0.97) = 5,335€ | |
| May | 950,000 | 95% | 5€ * 1.035 = 5.175€ | 0.03 * 5.175€ *950 = 147.90€ | 1. Line: 950 * 5.175€ = 4,916.25€ |
| Jun | 1,200,000 | 95% | 5€ * 0.97 = 4.85€ | 0.03 * 4.85€ * 1,200 = 174.60€ | 1. Line: 1,200 * 4.85€ = 5,820€ 2. Line: 0.03 * 4.85€ * 1,200 = 174.60€ |
In January and February, you can see a normal price. In March, there is a reduction due to underperformance. The April row shows a higher price due to overprinting. In May the machine performance is at 95% and finally in June there is a high performance and an overprinting.
Now let’s see, how to configure the pricing scheme for this scenario:
In our SAP Price Calculation setup, we will need three price element specifications:
- BLOG_BASE for calculating the price based on proportions of printed books and the target quantity,
- BLOG_PERFORM for calculating price discount for lower performance and
- BLOG_SECURE for calculating a surcharge for higher performance of the machine
Additionally, we require two lookup tables. One will store the price for printed books based on the proportion of printed books and the forecasted value, and the other will store the limits to determine whether the machine is performing high or low.
To make things easier, we will start with creating some fields in the “Manage Field Catalog” tile:
| Name | Source | Field Type | Description |
| Limit | Internal | Quantity | Representing the limits |
| Books | External | Quantity | Number of printed books |
| Performance | External | Ratio | Performance of production line |
| targetQuantity | External | Quantity | Forecasted quantity |
| Proportion | Internal | Quantity | Storing the proportion amount |
After that we are going to create two lookup tables:
Next, let's proceed to the Lookup Table Data:
Access the "Manage Lookup Table Data" application and upload the specified pricing information for the BLOG_UsagePrice table.
The prices are based on the proportion, as stated in the use case.
Following that we will enter the following data into the BLOG_Limits table
You may notice that the limit varies depending on whether the plan is Perform or Secure.
With that established, let's proceed with creating the Price Element Specifications: The first one will be the BLOG_BASE, which will calculate the price based on the proportion of the printed books
In the second step we have a formula which executes the following logic:
Books / RatioOf(targetQuantity)
With that, we will calculate proportion and can do the lookup in the table.
For example: The customer has forecasted a volume of 1,000,000 books but printed 1,100,000. With the formula this will lead to: 1,100,000 EA / RatioOf(1,000,000 EA) = 1.1 EA
In the next step, SAP Price Calculation will verify whether a row is found in the table, and if so, it will calculate the price.
Upon reviewing the lookup table, you will notice that there are ranges, and the outcome of our calculation is 1.1 EA, which falls within the last range. Therefore, in this scenario, the result will be calculated as: 1,000,000 EA* 4.85€ = 4,850,000€, as the volume is 10% greater than or equal to, resulting in a price reduction of 3%. This result will be used as the reference price in the next step.
Next, we will create another Price Element Specification: BLOG_PERFORM
In this Price Element Specification, the input is the reference price, which is the result of the previously created Price Element Specification. It is important to note that in the 3rd step, when SAP Price Calculation checks the lookup table, you have the option to include constants as input and output fields
If you recall, in the BLOG_Limits table, we have two different plans that determine the limit. Therefore, if we have the Perform plan, the limit will be 0.9.
These formulas are utilized to calculate the deviation from the limit, which is stored in the lookup table, and to guarantee that the difference does not exceed 10%. Additionally, certain formulas are applied to prevent negative amounts in the calculation. Finally, the final factor is combined with the 100% price condition and applied to the reference price.
For the last Price Element Specification, BLOG_Secure, you can just copy the second one and change the input field constant for plan to “Secure”. Also make sure, that you change the sequence for the step "Calculate [difference] as a [Quantity] using the formula, to: (Performance - RatioOff(Limit)) * Books / RatioOff(Books)
With that we can continue with the Pricing Schema.
The final pricing schema should look like this:
Let’s continue in SAP Subscription Billing and create a subscription to see, how the bill will look like in the end.
First. upload usage data representing the data from the table, describing the use case. We will focus on the data from March - May:
The printer will send the following information to SAP Subscription Billing:
Performance 88/100 => the machine performance is at 88%.
Books = 975,000=> 975,000 books were printed in March. The same we will do with the data for April and May.
Now let’s check the bill:
Mar:
Apr:
May:
In summary, grasping the complex price calculation within SAP Subscription Billing and SAP Price Calculation is crucial for businesses. By effectively utilizing these systems, companies can ensure competitive pricing and improved profitability, leading to better decision-making and increased revenue.
I am very grateful to Carsten Jerichow for the support and assistance he has provided on this specific topic. His help has been greatly appreciated.
If you have any questions, feel free to leave a comment or send me an email.
| User | Count |
|---|---|
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
