Aggregation of rate elements with rate subelements Subscription billing

[tvc_em]

Dear Experts,

I need to achieve the following usage-baseds cenario in SAP Subscription billing and I'd need your input.

An external system will send to subscription billing usage records of rate elements "drivers" and "vehicle".
Both rate elements have the same 2 rate subelements: "active" and "inactive".

For the usage of 0 to 19 units (both "drivers" and "vehicle", both "active" and "inactive") a fixed amount is billed every month, ex. 50€.

From the 20th units on, a price per unit is billed in addition to the fixed price, ex. 5€/1ea. 
The same price is billed for "drivers" and "vehicle", "active" and "inactive".

How do you suggest to achieve this in a "simple" way?
I know I should use Tiered pricing, but this doesn't support Fix price type.
I also know that I need to set up an aggregation to have the rate elements with corresponding rate subelements contributing all together to the quantity included in the fixed amount: I set up an aggregation in the aggregation catalog and I added a step in the pricing tree of the price element specification (see screenshots) but the system doesn't aggregate the quantities coming from the usage records.

Any help would be much appreciated!

Thank you in advance
Elena

[Juan_Torrero]

This may be better handled by other LoB, Sales rather than Finance, since there are pricing elements involved.

[CarstenJ · Accepted solution]

Hi Elena,

I'm happy to discuss this here in the community.
On the first glance the design of the rate plan template with two rate elements with each having 2 rate subelements does not seem to be optimal.
However, I do not fully understand the required outcome.

If I understand you right, your external system will send 4 kind of usage records:
1. units with active drivers
2. units with inactive drivers
3. units with active vehicles
4, units with inactive vehicles

And you want to have exactly corresponding 4 different charges on the bill. At least that would be the result if you use the charge definitions you described.

Is this the expected structure of the bill?
Or would you expect a bill with one charge for vehicle&drivers and another one for active&inactive?

Kind regards,
Carsten

PS:
When Subscription Billing is rating usage, the price calculation happens always on the level of a charge. E.g., if you send a usage record with active drivers, then only this specific charge is calculated.
With that, the aggregation rule cannot be used to dynamically aggregate quantities across charges.
 

PS2:
Regarding the problem with a fixed rate for tier 1 to 19, you could adjust the suitable quantity before applying the price condition in the Calculate Price Element function.
A typical strategy could be:
a) have a lookup table with the minimum quantity (e.g. 19 EA) as an output column. Replace EA if you use another one for the rate element.
b) determine highest value of the quantity and the minimum quantity using the Suitable Quantity operator.
c) use this suitable quantity to calculate the price element. The price condition type Single with a linear price type would do the job.

[tvc_em · Accepted solution]

Dear Carsten,

thank you very much for your answer, this is already very helpful.

The goals I'm trying to achieve are the following:

1. Avoid overcomplicating the set up and future maintenance of rate elements.
2. Set up rate elements in a way to manage usage records sent from the external system in a uniform way for all the rate plans.
3. Create an invoice with the lowest number of lines possible.

Unfortunately, I think it will be difficult to achieve all the 3 goals together but if you have any idea I'm all ears 🙂 

Yes, the external system will send 4 kind of usage records as you described, and the reason why I thought we need to set up 2 rate elements with 2 subelements each is because we have other rating strategies like the following:

- Different price for driver and for vehicle. Same price for active or inactive units (no aggregation, unit price is applied to total qty).
- Different price for driver and for vehicle. Different price for inactive units (no aggregation, unit price is applied to total qty).
- Fixed price for active drivers & vehicles. Different price for inactive units (no aggregation, unit price is applied to total qty).

I thought that using two rate elements (driver & vehicle) with 2 subelements (active & inactive) was a better solution than creating 4 rate elements (ex. driver active, driver inactive, etc.), if you think otherwise I can go back on this decision (I'm still working in a DEV system).

Concerning the bill structure, ideally when the same price is applied to all the rate elements and subelements, only one line is necessary. On the other hand, when different prices are applied, multiple line should be printed.
I already did some research and I'm afraid that having one line per rate element/subelement is the only solution that will fit all the scenarios.

Thank you for clarifying why the aggregation is not working right know, I think I understand the logic better now but unfortunately I still don't see how I can achieve the scenario "For the usage of 0 to 19 units (both "drivers" and "vehicle", both "active" and "inactive") a fixed amount is billed every month, ex. 50€ + From the 20th units on, a price per unit is billed in addition to the fixed price, ex. 5€/1ea. The same price is billed for "drivers" and "vehicle", "active" and "inactive"."
Based on the info provided on the other pricing scenario we have to achieve in parallel, do you maybe have an idea on how to achieve this?

Thank you also for the tip on the fixed rate for tier 1 to 19, I'll test it 🙂

Thank you very much in advance for your help.

Kr,
Elena

[CarstenJ · Accepted solution]

Dear Elena,

the tricky thing is if you want to have a combined threshold for the number of active vehicles and number of active drivers.
For example, if active drivers = 14 and active vehicles is 10 and you want to do the pricing based on the total quantity of 24 units:
fixed price 50€ for the first 19 units + 5 * 5€ resulting in 75€.
In Subscription Billing, there is currently no means do to such cross-charge aggregation. And given the other rating strategies like same or different prices for these combinations, I think you would indeed require for each scenario a distinct metric = rate element.

Drivers units priced independently from vehicles - then you can use the setup you've chosen.
Drivers priced together with the vehicles - then you probably need another rate element which represents the metric "drivers + vehicles). 

After reading your last reply, I also think that rate subelements could be a good approach for your scenario. Just keep in mind, that each combination of rate element and rate subelement is resulting in separat charges in the bill. And that the rating and pricing for each usage record will be done separately. 

Best, Carsten

[tvc_em · Accepted solution]

Hi Carsen,

thank you very much again for your explanation, I'm glad that at least I was going in the correct direction in terms of configuration.
Concerning the aggregation, I guess I was confused by the explanatory example proposed in the SAP Help (https://help.sap.com/docs/PRICE_CALCULATION/53987d38467243e28cbeb8514d015666/8dace9fbf88541549e82e24...) where the aggregation is applied to the scenario "You want to price separately different sorts of apples, but the price per kilogram depends on the total quantity of apples in the priceable document."
Thanks again and have a nice day!

Kr,
Elena

[tvc_em · Accepted solution]

Dear Carsten,

I was going to test your solution for the fixed rate for tier 1 to 19 using the suitable quantity and I would really appreciate some further clarifications if it's not too much to ask.

a) have a lookup table with the minimum quantity (e.g. 19 EA) as an output column. Replace EA if you use another one for the rate element.
-> I'm using lookup table UsagePrice, should I copy it and then add the minimum qty in the table outputs next to "price" or do you mean I should create a new field "minimumQuantity" then create the corresponding lookup table with only the minimum qty in the table outputs? 
->in the Lookup Table Outputs, blocksize is the only code I can select that has field type "quantity" (see screenshot below), is this the code I should add in the Lookup Table Outputs?
b) determine highest value of the quantity and the minimum quantity using the Suitable Quantity operator.
c) use this suitable quantity to calculate the price element. The price condition type Single with a linear price type would do the job.
-> do you mean that I have to create a price element specification for the new lookup table based on the new field "minimumQuantity" ? how exactly can I add this to the price element specification of my UsagePrice to calculate the fixed price for up to 19 units, and unit price for 20+ units?

I apologize for all the questions, I'm new to Subscription billing and I'm trying to catch up quickly.
You help is highly appreciated!
Kr,
Elena

[CarstenJ · Accepted solution]

Hi Elena,

a) In order to configure an output column in a lookup table, you will need a field defined in the field catalog. You can choose to create a new one or reuse an existing field. I recommend keeping the number of fields as low as possible through maximum reuse. However, it's important not to reuse a field that has a different business meaning attached to it. Since blocksize represents the size of a block typically used for block pricing of usage (e.g. API calls which are priced in blocks of 1000 calls), it would be best to create a new field called "minimumQuantity" with a proper description.

Then, create a new lookup table with "minimumQuantity" as an output column. You can decide to define it with only the minimumQuantity as output or include both the minimumQuantity and the price condition. The choice between these two approaches depends on factors such as reuse, understandability of the pricing tree, and data maintenance. Typically, I would prefer the single table approach as it allows for the maintenance of the minimum quantity together with the prices.

c) I would recommend leaving the predefined content untouched and creating a new price element specification, for example, by copying the existing UsagePrice (e.g. "UsagePriceMinQuant") and then using this in the pricing scheme instead of "Usage Price".

Best
Carsten

---

[tvc_em · Accepted solution]

Hi Carsten,

again, I'm extremely grateful for your support.

I'm much closer to the solution now, but not there yet.
I'd like to share the configuration I set up based on your advise hoping it might be useful to others as well.
As displayed in the screenshots, I created a new field, a new lookup table with output minimumQuantity and price, and I'm trying to complete the new price element specification with the suitable quantity indicator.
When I'm completing the suitable quantity indicator, the only possible value, both for field "initial qty" and "quantity 2",  is "quantity", some error messages say that:
- the 2 fields shouldn't not contain the same value
- the field value can only come from the available list (in this case the only option is (quantity" as already said, I cannot force a number in these fields for example)
-  both field must be filled in.

Is it also a new field "quantity1" necessary? if so, where will be the min and max value of the suitable quantity indicator be set (in my case 1 and 19)? in the lookup table data of my ZF_UsagePrice_minQty?
I'm very sorry for all the questions but it doesn't exist any real example of configuration of the suitable quantity indicator and I'm not sure how it should go further at this point.

Kr