Using Range Tables

When dealing with numerical intervals, mapping tables cannot help. Say you want to assign different prices to packages of different weight intervals. You would have to determine the interval with a component first, and with the interval known, access a mapping table and get the price from it.

Range tables provide support for handling numerical intervals within the table itself. With these tables you can define the weight ranges or your packages in the table and assign a different price for each interval. Let’s see how this works.

Just like for mapping tables, the structure for range tables is defined separately from their content. Input and output columns as well as the data types of the output columns are defined in a so called "range table class". A range table class is made up of:

• Decision, whether the upper bound of the numerical intervals is considered part of the interval ("inclusive") or not ("exclusive")
• Decision, whether the upper bound of the last interval is "bounded" or "unbounded"
• 0 to 5 input columns of data type "string"
• 1 to 15 output columns of type "string", "Single Number", "Cumulative Number" or "Range Size Cumulative Number"

The figure below shows a range table class in the core tool.

There are four datatypes for numerical output values:

String

This datatype simply contains a string as an output. The idea is to support use cases, where string properties are associated to number intervals in the following form:

• Packages with a weight over 0 and up to 1 kg are assigned the weight class "light".
• Packages with a weight over 1 and up to 3 kg are assigned the weight class "medium".
• Packages with a weight over 3 and up to 20 kg are assigned the weight class "heavy"

Single number

This datatype provides a single number as an output. This can be the price for a package falling into a specific weight class. The idea is to support use cases, where prices are defined in the following form:

• Packages with a weight over 0 and up to 1 kg cost 12,- €
• Packages with a weight over 1 kg and up to 3 kg cost 15,- €
• Packages with a weight over 3 kg and up to 20 kg cost 25,- €

Cumulative number

A cumulative number property sums up the numbers of intervals the number value provided is overlapping usually excluding the range the weight falls into. The idea is to support use cases, where prices are defined in the following form:

• The first kg of a package costs 12,- €
• The next 2 kg cost 3,- €
• The next 17 kg cost 10,- €

Range Size Cumulative Number

This datatype is similar to the "cumulative number" datatype as it sums up the intervals affected by the value compared with the intervals. However, additionally to the sum of all prices the range size of all affected intervals is considered as well.

The idea is to support use cases, where prices are defined in the following form:

• The first kg cost 6,- € per kg
• The next 2 kg cost 1,50 € per kg
• The next 17 kg cost 2,- € per kg

The configuration of the range table introducer is like the one used to read from mapping tables. First, a range table class needs to be selected. The class defines which input columns must be mapped to properties.

The below numbered functions relate to the above figure:

1. Once a range table class was selected, a specific range table ID can be read from a parameter at runtime or provided as a specific table selection at design time.
2. The reference date is there to pick the right table version out of the table’s chronology. The table version will always be the one valid at the date and time stated by the reference date.
3. The range input property is the number property containing the value you want to pass to the range table. This value will be compared with the tables intervals to select the correct interval and derive the output values.
4. The section "Mapping of Input Properties" requests a type-compatible property to be assigned to each input column of the table, just the same way you know it from the mapping table introducer.

For the output properties you can see that there is a significant difference to the mapping table introducer: There are two tables with output properties.

• The upper table labeled "Mapping of Generated Properties" lists all the columns you have defined as output columns in your range table class.
• The difference here is, that each line / output property has two cells at its end. Each cell expects you to enter a property name, that the output value is written to. So why are there two output property names, when you just want to calculate one output value?

Depending on the datatype your output property has, just one of the two output property names does matter. Let’s look at the content of the two output property names depending on each datatype available for your output property.

When you have chosen Single Number as the output property data type, the first column Generated Property Name is the only one available. You are not able to enter any value into the second column Generated Cumulative Property Name. As range table output column of datatype single number will only provide the output value of the range table column determined by the numeric property, it makes no sense to define a property name, that contains any cumulatively calculated value. Therefore, the second column is disabled.

Let’s remember the examples given above for the different output column data types and build a corresponding example. Assume the following ranges are defined for a single number output property.

When a numeric package weight of 7 kg is passed into the comparator component, the result of the single number property is 25, as the quantity of 7 is between 3 and 20. No further calculation is made. As a result you will only enter a property name in the column Generated Property Name. Here the name Price was entered. In our example after the comparison of the package weight with your range table a property called Price will be available, which contains the value 25. The column Generated Cumulative Property Name cannot be used as no cumulative calculation is made.

Assume package prices are a bit different. Now the package price is defined per weight interval:

• The first kg of a package costs 12,- €
• The next 2 kg cost 3,- €
• The next 17 kg cost 10,- €

The table would look like this (pay attention to the change of the output column data type):

Now there is a cumulative value to be calculated. You are now able to set both output property names:

Here the Generated Property Name field is set to Price while the Generated Cumulative Property Name is set to Cumulative Price. As a result, SAP Convergent Charging will create two properties with different values. Let’s assume you send a weight value of 7kg into the table comparator again. After the range table comparison two new properties will be available instead of just one:

• The property Cumulative Price will contain the value 15. The system will determine the interval hit by the quantity. Here it is the third interval. It then adds up the output column values of all the intervals prior to the one, that was hit. Here these are the column values of the first and second interval: 12 + 3 = 15.
• The property Price will still contain the price found in the interval hit by the package weight you have sent into the comparator. The weight value is 7, so the third interval is hit. It s associated with a price of 10. The property Price will therefore have a value of 10.

As you can see both output properties still have to be added together to get to the total price to charge: 15 + 10 = 25.

Let’s assume the price is different per interval, but stated per kg instead of per weight interval:

• The first kg cost 6,- € per kg
• The next 2 kg cost 1,50 € per kg
• The next 17 kg cost 2,- € per kg

The resulting range table would look like this (again the output data type has changed!).

Again, both output property names must be set. Here the same names have been chosen as for the previous example. But remember, you could provide any name you want to the generated properties.

Aassume a value of 7 kg is passed to the table again, so that once again the third interval is hit. As both generated property names must be set, two output properties are calculated:

• For the property "Cumulative Price" all intervals are determined, that are prior to the interval hit by the number passed to the range table. As the number 7 means the third interval was hit, the first and second are selected.
• Not for each of these intervals the output column value is multiplied with the interval size. For the first interval this means .
• For the second interval this means
• Then the sum of these products is calculated:
• The property "Cumulative Price" will thus contain the value 9.
• For the property "Price" the value will again be the output vale of the interval hit by the number value passed to the range table. As the value is 7 the third interval is hit. Its output value is 2, so the value of the property "Price" is 2.

Looking at the results, you are not quite at the desired result yet. Our prices were supposed to work like this:

• The first kg cost 6,- € per kg
• The next 2 kg cost 1,50 € per kg
• The next 17 kg cost 2,- € per kg

Following this logic a package weight of 7 kg should result in

1. 6,- € for the first kg
2. 3,- € for the next 2 kg (each kg goes for 1,50 €)
3. 8,- € for the remaining 4 kg (each kg goes for 2,- €).

This totals up to 17,- €.

The range table comparison came up with 9,- for the property "Cumulative Price" and 2,- for the property "Price". The sum of it is 11,- € so, you are clearly lacking 6,- €, as the last interval does not consider the quantity. So what is missing?

This is where the lower table labeled Computed Properties becomes important.

Each range table introducer creates a set of standard properties independent of the output columns your range table provides. These properties are there to provide flexibility to the user, so that a variety of price calculation models can be supported beyond the ones listed here. The following table provides a list of these properties along with an explanation of its meaning. You will need one of them.

For your purpose you need the computed property called Value Beyond Lower Bound. For the package weight of 7 kg the third interval is hit. Its lower bound is 3. The difference between 7 kg and 3 kg is 4 kg. These 4 kg must be multiplied with the output property value of the interval, which is 2,- €. The product of 2,- € and 4 kg totals up to the missing 8,- €

You can now total up the sums of all intervals:

1. 6,- € for the first kg
2. 3,- € for the next 2 kg (each kg goes for 1,50 €)
3. 8,- € for the remaining 4 kg (as you have just calculated)

The sum is 17,- €, as expected.

You can use the computed properties as you see fit. However, not all the properties are available in each branch. The following table shows for which branches each property is available.

		<property> is below the first bound	<property> is in a range	<property> Found in last Unbounded Range	<property> Is Above the Last Defined Bound
	Lower bound of range	It is equal to 0	It is equal to the lower bound of the selected range.	It is equal to the lower bound of the selected range.	It is equal to the last upper bound.
Computed Property	Upper bound of range	It is equal to 0	It is equal to the upper bound of the selected range.		It is equal to the last upper bound.
	Range Size	It is equal to 0	Upper Bound of Range - Lower Bound of Range.		It is equal to the last upper bound.
	Prorata in Range		Value Beyond Lower Bound / Range Size
	Value Beyond Lower Bound		Difference between the lower bound of the range and the value of the input property that is used to select the appropriate range	Difference between the lower bound of the range and the value of the input property that is used to select the appropriate range
	Value Beyond Upper Bound				Difference between the upper bound of the last defined range and the value of the input property

Each range table manages exactly one numerical property and compares it with sets of intervals defined in the table. The additional input columns are handled as in mapping tables. For each combination of values for the input columns, a set of intervals must be provided. Let’s give an example for this.

Assume you want to provide prices for packages of different weight classes measured in kilogram.

Prices as well as the boundaries of the weight classes depend on the country the package is sent from as well as a service level, that was chosen by the subscriber.

You can solve this by adding two input columns Country and Service Level to the range table class. The weight is the mandatory numerical value, which is always managed by a range table, so you don’t add a dedicated column for it. An output column "price" of data type "Single Number" will contain the price associated to each package based on its weight.

When you have to manage prices for the countries "France" and "Germany" as well as the service levels "Standard" and "Premium", you have to maintain four sets of intervals – one for each combination of input values:

Although the interval boundaries for France Standard and France Premium do not differ, you must add them twice into the system – once for each input column value combination. The figure above shows how a range table created based on the range table class shown in the previous figure.

Note that the output values table does only show the interval set associated to the combination of input values selected in the table above.

You might have noticed that range tables do not contain a "valid from" and "valid to" date column by default. Instead, each range table is organized in chronologies. This means, that any modification of a range table’s content – even the tiniest one – will result in a new element in the tables chronology. The whole table data (along with the potentially tiny modification) will be stored again with a certain valid-from date. The date will be requested when you save the table to the database of SAP Convergent Charging.

Just like there is a subscriber specific variation of mapping tables, there is a subscriber specific variation of range tables. This table type is only accessible to the subscriber account it is bound to and cannot be accessed by any other subscriber account. Therefore, subscriber range tables lend themselves well to store contract individual or customer individual price information or other customer- / subscriber-related data.

When you want to read data stored in a range table you must use the range table introducer comparator component.

The range table introducer component has a set of outbound branches. The following branches are always available:

• <property> Is Below the First Bound
• <property> Is in a Range
• Input values not found

Depending on where the numeric property value fed into the range table lies, the corresponding output branch is taken.

One additional outbound branch dealing with the last interval is available depending on the range table class configuration: When you have selected your range table class to be unbounded for the last interval, the 4^th outbound branch is called

<property> Found in Last Unbounded Range

If you configure your range table class to be bounded though, having your numeric value found in the last interval is the same as finding it "in a range". At the same time the branch "<property> Found in Last Unbounded Range" doesn’t make sense as there is no unbounded last range. Therefore this branch is replaced with:

<property> Is Above the Last Defined Bound

The following table summarizes this:

Branch name	Last interval is unbounded	Last interval is bounded
<property> Is Below the First Bound
<property> Is in a Range
<property> Found in Last Unbounded Range
<property> Is Above the Last Defined Bound
Input values not found

In the following video, Melissa will show her colleague Jonathan how to create a new range table class in SAP Convergent Charging.

Now that Jonathan has learned how to create a range table class, Melissa will now train him how to create a range table based on the new range table class he has just created. He will fill the table with the price information needed to support the Bandwidth usage of the cloud selection service.