Multi Parameter Based Pricing

Oracle Revenue Management and Billing provides a facility to define pricing for a price item based on multiple parameters. You can also define pricing for bundles based on multiple parameters. You can enable or disable the multi parameter based pricing feature by setting the Multi Parameter Based Pricing (C1_​PPARM_​FLG) feature configuration. For more information, see Setting the C1_​PPARM_​FLG Feature Configuration.

If the multi parameter based pricing feature is disabled, you can define pricing for a price item based on the variance parameter. If the multi parameter based pricing feature is enabled, you can define pricing for a price item based on multiple parameters. For example:

Pricing 1 and Pricing 2 are defined for Price Item A based on two parameters - Country and Currency. Before you define pricing based on country and currency, you need to define these parameters in the system. Once you define these parameters, you need to associate them to the price item (i.e. Price item A).

Then, when you define Pricing 1 for Price item A, you need to set the following price item parameters:

• Country - US

• Currency - USD

Similarly, you need to define Pricing 2 with Country set to Germany and Currency set to USD.

The following table lists the tiering ranges defined in Pricing 1 where price item parameters are set to US, USD:

The following table lists the tiering ranges defined in Pricing 2 where price item parameters are set to Germany, USD:

Now, when the user performs 1500 transactions (in USD) of Price Item A in Germany, 12000 transactions (in USD) of Price Item A in US, the system creates two billable charges. In one billable charge (with Price Item A, US and USD combination), the system uses $1 as the rate for calculating charges, and in another billable charge (with Price Item A, Germany and USD combination), the system uses $3 as the rate for calculating charges.

Note that in this case the parameters based on which you have defined pricing and tiering ranges are same. You can use different parameters while defining pricing and tiering ranges, if required. You can also use another price item or bundle and its parameters while defining tiering ranges. For example:

The following table lists the tiering ranges of Pricing 1 defined for Price Item A where price item parameters are set to US, USD:

Now, when the user performs 1500 transactions (in USD) of Price Item A in US, 200 transactions (in USD) of Price Item B in Germany, the system creates one billable charge. The system adds the transactions with the following combinations and then determines the range of Price Item A within which the total units (i.e. 200) fall:

• Price Item B, Germany, USD

In this case, the total units fall in the 100 - 200 range of Price Item A, and therefore the system uses $1 as the rate for calculating charges (i.e. 1500*1=1500).

Some parameters might be mandatory and some might be optional while defining price item pricing. You can define price item pricing based on these parameters at various levels, such as:

• Account Agreed

• Account Price List

• Account Inherited Price List

• Customer Agreed

• Customer Price List

• Customer Inherited Price List

• Parent Customer Agreed

• Parent Customer Price List

• Parent Customer Inherited Price List

• Default Price List

• Global Price List

As prices can be defined at multiple levels, the system first searches for exact match at all levels (using the search order). If the system finds the exact match at multiple levels, the price assignment at the higher precedence level is considered. Let us understand this with the help of an example.

Pricing 1 is defined for Price Item A with the following parameters at the Account Agreed level:

Pricing 2 is defined for Price Item A with the following parameters at the Parent Customer Agreed level:

Pricing 3 is defined for Price Item A with the following parameters at the Account Price List level:

Now, when the user performs transactions (with the type set to BT in US) of Price Item A in USD, the system searches for price with exact match (Type - BT, Country - US, and Currency - USD). The exact match is available at two levels - Account Agreed and Parent Customer Agreed. The system considers the price at the Account Agreed level because this level has higher precedence.

Depending on the search order defined for the division (to which the account belongs), the level with higher precedence changes. Accordingly, the price assignment at the higher precedence level is considered for calculating the charges.

If the system does not finds the exact match at any level, it searches for the best fit match at all levels. Let us understand how the best fit match is determined with the help of an example.

Pricing 1 is defined for Price Item A with the following parameters:

Pricing 2 is defined for Price Item A with the following parameters:

Pricing 3 is defined for Price Item A with the following parameters:

Pricing 4 is defined for Price Item A with the following parameters:

The system has Pricing 1, Pricing 2, Pricing 3, and Pricing 4 defined for Price Item A. Now, when the user performs transactions (with the type set to BT in US) of Price Item A in USD, the system does not find price with exact match (Type - BT, Country - US, and Currency - USD). Therefore, it searches for the best fit match.

While searching for the best fit match, the system rules out the optional parameter with lowest priority (i.e. Currency) and checks whether the price (with Type - BT and Country - US) is available. If the price is available, the system considers the price as the best fit match. Therefore, in this case, Pricing 1 is considered as the best fit match.

Suppose, if the price (with Type - BT and Country - US) is not available, then the system rules out the optional parameter with next lowest priority (i.e. Country) and checks whether the price (with Type - BT and Currency - USD) is available. If the price is available, the system considers the price as the best fit match. In this case, Pricing 2 would be considered as the best fit match. If the system finds the best fit match with same weight at multiple levels, the price assignment at the higher precedence level is considered.