Pricing Formula

SQL Built-In Functions for Pricing Formulas in Oracle Advanced Pricing Page 1

SQL Built-In Functions for Pricing Formulas in Oracle Advanced Pricing

An Oracle White Paper August 2011


SQL Built-In Functions for Pricing

Formulas in Oracle Advanced

Pricing

EXECUTIVE SUMMARY

The purpose of this document is to demonstrate the ways some of the SQL Built-

In Functions can leverage functionality within Pricing Formulas, in Oracle

Advanced Pricing, to generate list prices and modifier values. The use of SQL

Built-In Functions is part of the standard applications, and this document is

designed to supplement the existing User and Implementation Guides for

Advanced Pricing 11.5.10 and Release 12.

Introduction

The following document has been collated to provide an overview guide to

establish what is possible with SQL Built-In functions and Pricing Formulas.

Unfortunately, although information is available about SQL Built-In functions with

respect to PL/SQL coding, there was nothing that detailed the use within pricing

formulas.

An example of the complexity is where a client sold licences to businesses to enable

recorded music to be played to the general public. Each different type of business

would have different „tariff‟ types, to enable a fairer generation of licence fees,

rather than a flat rate for all.

Using Quoting and Configurator the client was able to capture a wide range of

commercial details, such as Audible Area, Average Attendance, Number of

Performances, Licence Period, etc. Although the Ordered Quantity was only 1

Licence sold, there could be numerous parameters in determining the fee. Pricing

Attributes linked through Configurator would capture the values that the Pricing

Formula would use to calculate the fee.

Pricing Formulas in Advanced Pricing apply basic mathematical formulae, using a

variety of data sources, to assist in the calculation of list prices and modifier values.

A Pricing Formula is structured with two elements:

Formula

Formula Steps

Within the formula, a standard mathematical calculation is defined using traditional

mathematical operators (+ - / * etc). However, rather than the actual figures in the

calculation, the formula references the formula steps that are listed in the form.


The example screenshot below displays how the Formula Steps are related in the

Formula Line, “DECODE” and “NVL” are examples of SQL Built-In Functions.

Each step can be the same or a different data source or type, for example,

„Numeric Constant‟ (step 7)

„Pricing Attribute‟ (step 6)

The formula could be defined as (7+6), not („Numeric Constant‟ + „Pricing

Attribute‟). See Oracle Advanced Pricing User’s Guide for more details on the Pricing

Formula set up and usage.

Included in the structure of the mathematical formula, is the ability to add SQL

Built-In Functions. In standard SQL programming these are seeded functions to

help you manipulate data. These built-in functions fall into the following categories:

Numeric

Character Functions Returning Character Values

NLS Character

Character Functions Returning Number Values

Datetime

General Comparison

Conversion

Large Object

Collection

Heirarchical

Data Mining


Encoding and Decoding

NULL-Related

Aggregate

Historically, the Advanced Pricing User Guide mentions SQL Built-In Functions and

lists, „NVL‟, „SQRT‟, and „MOD‟ as examples and further provides an example in

the use of the „SQRT‟ (Square Root) command. In later releases of Advanced

Pricing, an example of the „GREATEST‟ SQL Built-In Function is seeded as part

of a minimum fee pricing formula.

The User Guide describes the following example:

“For example, the valid formula (1+2*SQRT(3))/4 contains:

• Operands: 1, 2, 3, and 4

• Mathematical operators: +, *, and /

• Built-in function: SQRT

• Parentheses: to group the operands and operators

For each preceding step number, you need to create four formula lines since the

formula has four step numbers.

Oracle Advanced Pricing uses the formula line and evaluates it to obtain the value

of the operand and calculates a formula. It does not use the face value of the step

number.”

A list of all SQL Built-In Functions can be found in the PL/SQL User's Guide and

Reference.

Not all of the SQL Built-In Functions are suitable for use directly within Pricing

Formulas formulae, generally those listed in the „Number‟ and some in the

„Miscellaneous‟ categories can be used directly into the formula line. This does not

preclude the other functions being used within other formula steps elements such

as Pricing Attributes packages and functions or Get_Custom_Price.

Formulas v Modifiers

Some of the functions listed later could be replicated using functionality available

through modifiers, e.g. Recurring Price Breaks. However the expanding commercial

use of Oracle Applications could mean that modifiers may not necessarily be suited

for the required pricing calculations. For example, where a licence is sold to play

recorded music, a charge to show live satellite sports, or even calculate the cost of

legal aid cases, the transaction quantity is always 1, however additional factors that

could be captured through Configurator /OA Framework forms could be used in

the calculation of the final price.

For example, music licences for businesses could be calculated based on the

number of chairs in a hairdressing salon to the number of speakers in a theme park.

Likewise, pubs and bars showing sports could be charged on the number of seats


on site or the rateable value of the premises, as well as the consumption of alcohol

per unit.

Where these complex pricing calculations are required to support different business

models, pricing formulas using the SQL Built-In Functions can satisfy the most

complex of models as opposed to trying to replicate these using modifiers.

Formulas v Customisation

Additional pricing and qualifier attributes can be defined in a custom package and

used in the pricing objects. This extends the functionality of the pricing module.

The accepted approach is to generate a custom package, e.g. XX_PRICING_PKG,

listing functions that are mapped to the pricing and qualifier attributes. There is a

temptation to use this package to derive all the complex pricing calculations, rather

than utilise the SQL Built-In Functions in a pricing formula.

Each Built-In Function will attempt to derive a value, used in the calculation. These

values can subsequently be seen in the Formula Steps within the Pricing Engine

Request Viewer, enabling much easier debugging and maintenance rather than

everything, not just the attributes, coded in the custom package. Therefore always

look to use the Built-In functions in pricing formulas ahead of any short-cut

technical calculation customisation.


SQL BUILT-IN FUNCTIONS

Overview

There are numerous SQL Built-In Functions that can be used within standard SQL

or PL/SQL development; the complete list is displayed in Appendix A. However,

for Pricing Formulas, generally only mathematical number and some miscellaneous

functions will be used. This section considers those most likely to be used in

pricing formulas. Although discussed individually, there is nothing to prevent

functions being nested within calculations containing other functions.

The following section has been compiled with reference and acknowledgement to

Oracle® Database SQL Reference 10g.

Sql Built In Functions – ‘Numeric’

CEIL

CEIL (n)

This function enables a value or calculation to be rounded up to the nearest integer,

i.e. nearest integer greater than or equal to n, where the structure is CEIL(n).

Example:

Step 1 - Numeric Constant = 10

Step 2 - Pricing Attribute = 3

CEIL(1/2) = 3.333 = 4

CEIL(2/1) = 0.3 = 1

(CEIL(2-1)/2) = -2.333 = -2

If a pricing attribute could return a decimal value, CEIL(“pricing attribute”) will

round the attribute value up to the nearest integer.

This command is particularly useful if pricing formulas are used for calculating

price banding for a list price that cannot otherwise by controlled using recurring

price breaks, i.e. if the quantity is 1, and additional pricing attributes determine

price ranges.

Business Use Example

A bar entertainment licence is priced, calculated on Area in Metre2

00 – 10 100

11 – 20 200

21 – 30 300

31 – 40 400

41 – 9999999 100 for every 10 m2 consumed additionally.

In this case the formula, would have the steps,


Step 1: Pricing Attribute – e.g. Licence Area in M2

Step 2: Numeric Constant – 10

Step 3: List Price – 100 (derived from price list value field)

The pricing formula would be displayed as “(CEIL(1/2))*3”, such that for every

10m2 or part of consumed a price of 100 would be applied. Therefore, if 62 m2 is to

be priced, the value would be CEIL(62/10)*100 = 700 as 6.2 would be rounded to

7.

FLOOR

FLOOR (n)

This is the opposite of the “CEIL” command. This function enables a value or

calculation to be rounded down to the nearest integer, i.e. nearest integer less than

or equal to n.

Example:



FLOOR(1/2) = 3.333 = 3

FLOOR(2/1) = 0.3 = 0

(FLOOR(2-1)/2) = -2.333 = -3

With pricing formulas, this could be used in ranges to calculate where whole values

had been used. The remainder would not be included in the calculation, if FLOOR

were used.


Using the previous example, the pricing formula now displayed as

“(FLOOR(1/2))*3”, such that for every 10 consumed a price of 100 would be

applied. Therefore, if 62 m2 is to be priced, the value would be

FLOOR(62/10)*100 = 600 as 6.2 would be rounded to 6.

This function could also be applied to subscriptions to satellite and cable services.

The customer will renew in advance of the expiry date, but they are still charged for

a set period, e.g. one year, rather than one year plus the time in advance the

payment is made, i.e. FLOOR(licence period).

MOD

MOD (n, x)

This function will return the remainder of the calculation, where n is divided by x.

In the event that x is zero, the function will return the value of n.


Example:

Using actual numbers instead of Formula Steps,

MOD(11.5,4) = 3

MOD(25,12) = 1

MOD((13*5),6) = (65,6) = 5

This could be used in a pricing calculation where whole Units of Measure are

priced at one rate, and decimal remainders given a premium value.


Software licences are sold in sets of 10 at 100 for each licence. Where the set is split

less than 10, a surcharge of 15% is added to the licence price.

Pricing Attribute “Licence Quantity” (step 1)

List Price „100‟ (derived from price list) (step 2)

Numeric Constant “10” (step 3)

Numeric Constant “1.15” (step 4)

The pricing formula will be displayed as, ((FLOOR(1/3))*2)+(MOD(1,3)*(2*4))).

The FLOOR calculation will determine the fee based on the whole sets consumed

by the Licence Quantity. The MOD calculation will determine the cost of the

individual split set licences and charged at the increased list price. Please refer to the

REMAINDER function below regarding how MOD and REMAINDER generate

different values.

POWER

POWER (n, x)

This function will act as if nx, therefore raising the value of n by the power of x.

The value of the base value and exponent can both be any numeric value; however,

if the base is negative then it can only be raised by an integer.

Example:




POWER(1,2) = 10*10*10 = 1000

POWER(2,1) = 3*3*3*3*3*3*3*3*3*3 = 59049

(POWER(2,1)/2) = (3*3*3*3*3*3*3*3*3*3)/3 = 19683



Steel rods are sold based on the volume of each rod extruded and priced per

Metre3. The standard mathematical formula for this is “πr2l”. Pricing Attributes

would be defined for the radius and length of the steel rod, the value of pi set at

22/7 or 3.147 etc

Numeric Constant “22” (Step 1)



Pricing Attribute “Rod Radius” (Step 4)

Pricing Attribute “Rod Length” (Step 5)

List Price (from Price List) (Step 6)

The pricing formula would be displayed as ((1/2)*(POWER(4,3)))*5)*6

The POWER function is used to calculate the radius squared. A function like this

could probably be most useful when calculating fluid material, e.g. concrete, into

solid objects.

REMAINDER

REMAINDER (n, x)

This function will return the remainder of the calculation n divided by x.

Example:


REMAINDER(11.5,4) = 4

REMAINDER(25,12) = 1

REMAINDER((13*5),6) = (65,6) = 5

Although Remainder seems similar to the MOD function, the difference between

the two functions is how the „remaining value‟ is dealt with. For the MOD

function, any remaining value is treated as a FLOOR therefore will be rounded to

the lowest integer, whereas the REMAINDER function treats the value as a

ROUND, and therefore will convert to the nearest integer, irrespective of higher or

lower integer.

From the example above, the difference can be seen as,

REMAINDER(11.5,4) = 4 (3.5 ROUND to 4),

whereas MOD(11.5,4) = 3 (3.5 FLOOR to 3).

This can also be explained using the following example.

SELECT MOD(4,5) FROM DUAL

will produce a result of 4. This result can be explained using the formula,


n – (x *FLOOR(n/x))

Therefore 4 – (5 * (FLOOR(4/5)) = 4 – (5*0) = 4.

Whereas the alternate example,

SELECT REMAINDER(4,5) FROM DUAL

will produce a result of –1. This result is explained as ROUND is used instead of

FLOOR.

n – (x *ROUND(n/x))

Therefore 4 – (5 * (ROUND(4/5)) = 4 – (5*1) = -1.

So, although MOD and REMAINDER are similar, there are some key distinctions

that need to be considered when being used in a pricing formula.

ROUND (number)

ROUND (n, z)

This function will round up or down the value of n based on the integer specified

in z. The integer determines the number of places to the right of the decimal point

the value should be rounded. If the value of z is positive, this indicates places to the

right of the point, a negative number indicates rounding to the left of the point. If

there is no integer value, i.e. ROUND(n), the value is rounded to the nearest

integer.

Example:


ROUND(11.12345,2) = 11.12

ROUND(11.12345,4) = 11.1235

ROUND(10/3,2) = 3.33

When using this function, consideration should be given to the Rounding Factors

linked to the price list, if associated. For example, if the pricing formula rounds to 2

decimal places and the price list to 5 places, the resultant value could have

additional zeros added, i.e. n.nn000.

The ROUND command would most likely be used where a complex calculation

would require a subset of the data being calculated to be set to x decimal places,

rather than calculate the whole amount.


The most common case where the ROUND function will be used is in replicating

clients‟ pricing structure, originally calculated using spreadsheets. Where a client

fixes values to 2 decimal places, they would expect to see the same value in Oracle

as they would generated using their spreadsheets. Sometimes this will not happen,

as the price is only „rounded‟ at the end of the formula calculation, however, should


the client insist on exact replication of their data, then use of the ROUND

command within the pricing formula will enable replication of rounded values from

spreadsheets.

SQRT

SQRT (n)

This is a basic function as described in the Pricing User Guide; this function will

return the Square Root of the value n.

Example:


Step1 - Numeric Constant = 10


SQRT(1) = 3.162

SQRT(2) = 1,732

(SQRT(2)/2) = 0.577

TRUNC

TRUNC(n,x)

This function will return a decimal number truncated to the specified number of

decimal places. This value must be an integer. If this parameter is omitted, the trunc

function will truncate the number to 0 decimal places.

Example:


TRUNC(125.815) = 125

TRUNC(125.815,1) = 125.8

TRUNC(125.815,2) = 125.81

TRUNC(125.815,-1) = 120


Taken from Note: 554674.1 Formula Setup to Round To Nearest High $100.00

A basic formula to round a number up to the nearest 100:

(trunc((F(x)-1)/100)*100)+100

where F(x) can equal a simple number or a more complex equation.


F(x) is assumed to be > 0.

An example of a formula used in the formula setup screen:

((TRUNC(((1+NVL(((2/(2+3+4+5+6)) * (7+8+9+10+11)),12))-14)/13))*13)+13

Where Field 12 = 0 , step 12, numeric constant of 0

Field 13 = 100, step 13, numeric constant of 100

Field 14 = 1, step 14, numeric constant of 1

The other steps could be any pricing attribute or modifier value.

The functions listed above are not an exhaustive list, but the most likely to be used

in Pricing Formula calculations. Other „NUMBER‟ functions listed in Appendix A

are more pure mathematical and statistical based, but could also be used in Pricing

Formulas, should a business model require it

Sql Built In Functions – ‘Null-Related’

NVL

NVL(x,y)

This function will return the value of y, if the value of x is deemed to be NULL.

The NVL function is explained in the standard pricing user guide. Its use is to assist

the formula calculation in determining what to do if a NULL value is derived in the

pricing formula. This is most often used where values for pricing attributes are

being sourced and the system may not be able to retrieve a valid value.

If a NULL value is returned then the sales order will display a blank price or an

„ERR in formula‟ warning.

The purpose of the NVL function is to direct the calculation to another value if the

original is returned as null.

Most often another formula step line of Numeric Constant 0 or 1 is used in this

instance. The reference to this is by identifying the value or calculation that might

return a null value and then pointing to the corresponding replacement value to be

used.

Example:

NVL(1,2) = will return the value of step 2 if the value of step 1 is null

NVL((1*2),3) will return the value of step 3 if the calculation of steps(1*2) is null

NVL((1+2+3+4+5+6+7+8+9),10) will return the value of step 10 if the previous

calculation of formula steps returns a null value

NVL and Error Conditions


It was mentioned earlier about the impact of NULL values appearing in a pricing

formula calculation. Unless specified, using an NVL command, any calculation that

contains a NULL value, will cause a pricing formula to fail.

In Order Management, there are two messages that are likely to appear should the

system have issues with NULL values and the pricing formula.

“Error in Formula processing :

&ERR_TEXT”

or

“Error in evaluating formula. Please supply any Pricing Attributes that may

be required by the Formula. Or alternatively, use NVL in formula for steps

that may potentially have null value. Also, check if all steps used in the

formula have been setup as formula lines”

Unfortunately, both are fairly non-descriptive, but let the user know that the

formula has failed. On the sales order line, the list price field will display a null

value..

To rectify the error, use the Pricing Engine Request Viewer, and click on “Step

Values”.

(

Providing the profile option, „QP: Insert Formula Step Values into Temp Table‟

has been set to „Yes‟, the user will be able to access the Step Values form. This lists

all formula steps that have been used in the pricing formula price list calculation.

Therefore, where particular Step numbers are missing, the user can deduce which

Steps need to have NVL commands, or the whole formula has an NVL command.

NOTE: The Step Values listed only pertain to the price list calculation and not

from any formula associated with modifiers.


This form lists the respective values used in the calculation. Therefore, values

derived from pricing attributes will be listed.

The screenshot above shows Steps from 1 – 8, if a corrupt value was present, then

one of the Step numbers would be missing. To resolve that, locate the step in the

pricing formula and use NVL(step number, “alternate value”) in the pricing formula and

reprice.

Generally, as mentioned, a numeric constant of 0 is used as the “alternate value”,

however, that may not trigger a potential problem to an inquiring user in a price

calculation, however, using an exceptionally large value, e.g. 9999999 would

immediately indicate an problem with the price.

For example,

Pricing Attribute “Usage” Step1

Numeric Constant “9999999” Step2

Thus, pricing formula is NVL(1,2), such that if no Usage value can be determined,

a value of “9999999” is used in its place, which if installed would most likely place

the order on credit hold

With Order Management, there is always an Error message if a potential NULL

value is not catered for, and the Price field blank.

However, this feature, NVL, is particularly useful when using pricing formulas with

Configurator in Quoting, as opposed to Order Management. In Order

Management, if the pricing formula is in error, a warning will appear and a blank

displayed in the price field. The Pricing Request Viewer can then be used to

determine which step in the formula caused the error.

However, in Quoting an error in the pricing formula will cause the whole

calculation to fail and require the whole quote to be re-input. Therefore by

wrapping the whole formula in a NVL command, a value can still be forced to the

Quote form, e.g. 0, 9999999999, etc. The user can then investigate errors without

the need for complete re-input of the quote.

In Quoting, an error message might be displayed indicating a NULL value or

invalid Formula Step. However, the configuration is not left on the quote with a

final price of blank, as it would in OM. Unfortunately, in Quoting, the quote will


simply fail and require the whole configuration to be submit to Quoting once the

correction has been made. On small structures, this could not be an issue, however,

if this was for a chain of restaurants, requiring a configuration per site for the

company, this could potentially be a huge structure that would have to be re-input.

Therefore, as a good practice, if pricing is using formulas and quoting is using

pricing formulas, ALWAYS, wrap the formula with an NVL function. Again the

„alternate value‟ could 0 or 99999999 etc. But at least build in contingence for

NULL values.

NVL2

NVL(z,y,x)

The NVL has a related function, NVL2. This function is an extension of NVL,

whereby instead of replacing a NULL value with another value, the expression will

return a NULL value replacement and a non-NULL value replacement. Based on

the results of an expression z, the system will return x value (if NULL), or y value

(if non-NULL).

Example:

NVL2(1,2,3) = will return the value of Step 2 if Step 1 is not null

NVL2((1*2),3,4) will return the value of Step 4 if the calculation of Steps(1*2) is

null

NVL2((1+2+3+4+5+6+7+8+9),10,(11*12)) will return the value of Steps(11*12)

if the previous calculation returns a null value

This function would be useful if a pricing attribute was populated, a formula would

be derived, whereby if the attribute was left blank a zero or alternate values would

be returned.

This function could be considered an IF-THEN-ELSE, but restricted to the use of

identifying calculations should a NULL value be present.


When calculating the cost of preparing cut wood, an additional cost must be

included where the thickness of the wood is below 1cm. Measurements of the

prepared wood are collected in the ordering process using set values, therefore the

thickness is either NULL or a set size, and the list price calculated. If wood below

1cm thickness is required, an additional 15% is added to the price.

Pricing Attribute “Cut Length” (Step 1)

Pricing Attribute “Cut Width” (Step 2)

Pricing Attribute “Cut Thickness > 1cm” (Step 3)


Pricing Attribute “Cut Thickness < 1cm” (Step 4)

List Value 10 (from price list) (Step 5)

Numeric Constant “1.15” (Step 6)

The formula, in this example, would be NVL2(3,((1*2*3)*4),((1*2*4)*(5*6)))

Where the thickness was input for “> 1cm”, the first price calculation would be

used, if the “> 1cm” was NULL, then the additional 15% would be added to the

list price value.

Sql Built In Functions – ‘General Comparison’

GREATEST

GREATEST(x,y)

This function used in a formula string will compare expressions of data and return

the highest value, i.e. if x is higher than y, then x is returned. The data can be a

single value, a calculation or a combination of both.

Should the datatypes of the expressions be different, then the expressions will be

converted to the datatype of the first expression, i.e. „x‟.

Example:

Step1 - Numeric Constant = 10


GREATEST(1,2) = 10

GREATEST(2,1) = 10

(GREATEST(2,1)/2) = 3.333

The examples are using standard values, however, the same concept can be applied

to pricing formulas. For example, in the seeded minimum fee formula in Advanced

Pricing pricing,

Step 1: Pricing Attribute – Order Amount


Using the formula “Greatest(1,2)” will derive a value of either 750 or the actual

Order Amount dependent on which is the higher value.


The traditional use of a GREATEST command is when calculating minimum

values within a pricing formula, as per the example the seeded formula loaded with

Advanced Pricing. Another business example could be,

The Licence for a Bar to show particular sports, not pay per view, is based on the

Annual Revenue of the Bar, of which the minimum fee for the licence is £500. The


Licence Fee is 5% of the Gross Revenue or £500 whichever is the greater. To gain

the licence the bar owner, must submit revenue figures to the licence authority.

To generate the fee, a Pricing Attribute of “Gross Revenue” will be defined.

Pricing Attribute “Gross Revenue” Step 1

Numeric Constant “0.05” Step 2

Numeric Constant “500” Step 3

The Formula would be displayed as GREATEST((1*2),3). Therefore, the larger

value of 5% of Gross Revenue or £500 would be the licence fee.

LEAST

LEAST(x,y)

This function used in a formula string will compare expressions of data and return

the lowest value, i.e. if x is higher than y, then y is returned. The data can be a single

value, a calculation or a combination of both.

Should the datatypes of the expressions be different, then the expressions will be

converted to the datatype of the first expression, i.e. „x‟. Should one of the

expressions return a NULL value that will be considered the lowest value and be

returned.

Example:



Least(1,2) = 3

Least(2,1) = 3

(Least(2,1)/2) = 1

The examples are using standard values, however, the same concept can be applied

to pricing formulas. For example,

Step 1: Pricing Attribute – Order Amount


Using the formula “Least (1,2)” will derive a value of either 750 or the actual Order

Amount dependent on which is the lower value.


Using the example from GREATEST, a licence authority could now apply a

maximum licence value of £500. Therefore, the charge for the licence would now

be 5% of the Gross Revenue or £500 whichever is the smaller.


Sql Built In Functions – ‘Encoding and Decoding’

DECODE

DECODE(w,x,y,z)

This function operates similar to IF-THEN-ELSE expressions. This function is

used to generate “IF” statements within more complex pricing formulas.

However, rather than a basic IF-TRUE-FALSE syntax, the DECODE function

will permit a string of statements, to allow many True/False links in a single

formula.

The DECODE function requires as a minimum four elements,

1: Statement

2: Result

3: True

4: False

Such that the minimum pricing formula structure is DECODE(1,2,3,4).

Example:

DECODE(1+1,2,3,4)=3 as 1+1 equals 2, therefore result statement is 3.

DECODE(1+2,2,3,4)=4 as 1+2 equals 3, therefore result statement is 4.

This basic concept can easily be translated into pricing formulas. Generally this will

be used in collaboration with a Factor List formula step entry as the statement, and

Numeric Constant formula steps as the results.


Simple

The client would like to apply a discount modifier only on a line with an ordered

quantity that is a multiple of 5.

Using a combination of DECODE and MOD.

Pricing Attribute “Ordered Quantity” (Step 1)

Modifier Value (Step 2)



Using the formula steps, the formula expression would be,

DECODE((MOD(1,4),0,2,3)

Where the Ordered Quantity was divisible by 5 and no remaining value, i.e.

MOD=0, then the discount value was applied linked to the modifier value.

However, if MOD produced a value greater than 0, then the modifier would still be

applied, but with a value of 0 instead.

Complex


A customer generates orders based on the attendance an end-customer has for a

site. Below 1000, uses the standard list price, anything over 1000 uses a more

complex formula.

Step 1: Factor List – ATTENDANCE

Pricing Attribute – Attendance 0 – 1000 1


Step 2: Numeric Constant 1


Step 4: List Price

Step x-y additional steps.

The pricing formula would read, DECODE(1,2,4,(x….y)). Such that where the

attendance is less than 1000, this would equal Step 2, therefore Step 4 will be used

in the calculation. If the attendance is higher, then the more complex formula

(x…..y) would be used.

This example can be expanded to build in a several different pricing formulas

within the decode statement. If another band is entered, such that 1001 – 5000

attendance is double the list price, while 5000+ is now the complex formula.

Step 1: Factor List – ATTENDANCE






Step 4: List Price

Step x-y additional steps.

The pricing formula would now read, DECODE(1,2,4,3,(4*3),(x…..y)). Such that if

the Attendance is less than 1000, this equals step 2, therefore List Price (Step 4) is

used. If the Attendance is between 1001 – 5000, this equals Step 3, therefore the

calculation is List Price * 2 (Step 4* Step3), if neither Attendance is satisfied, then

the complex formula (x….y) will be used.

This approach can be used for a limitless number of conditions, providing the

Factor List value has a Numeric Constant to reference by. The Factor List need not

be a range of values, the value to be mapped against the Numeric Constant is just

the adjustment factor, what derives it is dependent on the Context and Attribute

within the Factor List, e.g. values of „Yes‟ and „No‟ can be linked to adjustment

factors of 1 and 2.


CASE

CASE n WHEN x THEN y ELSE z END

The CASE built-in function is an refinement of DECODE, in that a statement and

result can provide for True and or False results. However, CASE statements are

restricted to 255 arguments, each WHEN..THEN condition counts as two

arguments. Although, a pricing formula with that many conditions would be

exceedingly rare. This is the same limit as the DECODE function.


A Multi currency mark-up is defined to enable marketing rounding on public price,

If converted list price between 1-499 => then rounding up 1

If converted list price between 500-999 => then rounding up 5

If converted list price between 1000-99999999=> then rounding up 10

CASE WHEN 1 BETWEEN 2 AND 3 THEN ((CEIL(1/4)*4)-1) WHEN 1

BETWEEN 5 AND 6 THEN ((CEIL(1/7)*7)-1) WHEN 1 BETWEEN 8 AND 9

THEN ((CEIL(1/10)*10)-1) END

List price (step 1)










CASE V DECODE

When attempting IF-THEN-ELSE statements in pricing formulas, the examples

presented demonstrate that CASE and DECODE can both be used. But how to

determine which function to use in which scenario?

DECODE will only allow you to compare one value to another in the statement.

However, as in the example previously, a factor list can be used to list ranges of

values, providing there is an attribute that can be applied to the factor list. This is

where CASE can have the advantage.

CASE statements allow for > and BETWEEN comparisons, as seen in the

example above. The List Price needs to be compared to other values, as there are

no other attributes available, it is possible to compare the List Price to Numeric

Constants.


If a new attribute “Converted List Price” is defined, then the above example could

be defined using DECODE.

DECODE(1,2,((CEIL(7/2)*2)-7),3,((CEIL(7/5)*5)-7),4, ((CEIL(7/6)*6)-7))

Factor List “Converted List Price” (Step 1)

Converted List Price 1 – 499 1








List Price (Step 7)

The CASE statement could be argued is easier to understand than DECODE.

However, with the DECODE, by using Factor Lists and Attributes, should values

need to change due to yearly rate adjustments, the effective dates linked to the

Pricing Date will enable easier maintenance.

If this does not need to be considered, then the easier option would be the CASE

statement. DECODE is a series of values within the parentheses, and can be

difficult to follow, whereas the expression WHEN x THEN y is clear.

There is no right or wrong usage of CASE and DECODE, it is dependent on the

data sources available and the data comparisons required to produce the final value.

Sql Built In Functions – ‘Aggregate’

Aggregate functions return a single result row based on groups of rows, rather than

on single rows. When used in Pricing Formulas, the functions can take the values

of a Pricing Attribute and manipulate the data to provide the required calculation.

The following lists some of the Aggregate functions and how they might be applied

to a particular situation.

Business Use Example Data

A business calculates the list price of an item based on a uplift from the purchase

price over the previous 6 month period. A pricing attribute is defined that will

collate the purchase prices for the invoiced and closed purchase order lines for the

specific item being ordered.

Item A PO Price Jan 2011 1234

Feb 2011 1256


Mar 2011 1321

Apr 2011 1378

May 2011 1398

Jun 2011 1434

AVG

AVG(x) This function will return the average value of the expression x. If a Pricing Attribute has been defined to return multiple rows of numeric values, the AVG function can be used to calculate a single value for the pricing formula. Business Use Example The business calculates the List Price of an item being ordered on the average purchase order price over the last six months and adds a margin of 25%. The pricing formula will be, (AVG(1))*2 Step 1 – Pricing Attribute “PO Price” Step 2 – Numeric Constant 1.25 The system will calculate (1234+1256+1321+1378+1398+1434)/6 = 8021/6 = 1336.83. Therefore the calculated list price for the sales order would be 1671.04.

MAX

MAX(x) This function will return the highest value of the expression x where the expression evaluates a more than one row of data. If a Pricing Attribute has been defined to return multiple rows of numeric values, the MAX function can be used to calculate a single value for the pricing formula.

Business Use Example For certain customers, the business calculates the List Price of an item being ordered on the maximum purchase order price over the last six months and adds a margin of 25%. The pricing formula will be, (MAX(1))*2 Step 1 – Pricing Attribute “PO Price” Step 2 – Numeric Constant 1.25 The system will evaluate (1234, 1256, 1321, 1378, 1398, 1434) and return 1434. Therefore the calculated list price for the sales order would be 1792.5.


MIN

MIN(x) This function will return the lowest value of the expression x where the expression evaluates a more than one row of data. If a Pricing Attribute has been defined to return multiple rows of numeric values, the MIN function can be used to calculate a single value for the pricing formula.

Business Use Example For its best customers, the business calculates the List Price of an item being ordered on the minimum purchase order price over the last six months and adds a margin of 25%. The pricing formula will be, (MIN(1))*2 Step 1 – Pricing Attribute “PO Price” Step 2 – Numeric Constant 1.25

The system will evaluate (1234, 1256, 1321, 1378, 1398, 1434) and return 1234.

Therefore the calculated list price for the sales order would be 1542.5.


EXAMPLE

EXAMPLE

The following BR.100 set up extracts is for a recorded music licence for special one off events.

The table below shows the customer data that needed to be converted into a formula. Using the formula, meant that only the List Price value was amended each

year for inflation (RPI%)

Average Attendance Fee(£) 1 - 500 10.99 501 - 2000 21.98 2001 - 3500 43.96 3501 - 5000 65.94 5001 - 6500 87.92 6501 - 8000 109.90 8001 - 9500 131.88 9501 - 11000 153.86 Fees increase pro rata £ 21.98 per band of 1,500 persons.

VAT should be added at the current rate to the above charges.

To obtain the value of the licence, three main parameters need to be recorded:

Number of People in Attendance

Number of Hours the Event will last

Here, where the Attendance is fewer than 500 people this will incur a set fee from the Price List (i.e. £10.99, whereby over 500 people a formula will calculate the

licence fee.

Name Description Effective Dates Formula

Event Tariff 01-OCT-2000 NVL(((DECODE(1,2,3,4,(CEIL((7-5)/6)*(3*4))))*NVL(8,2))*NVL(10,2),9)

Formula Type Pricing Attribute Context Pricing Attribute Component Step Reqd Flag Seeded

Factor List 002 ATTENDANCE 1

Numeric Constant 1 2

List Price 3


Formula Type Pricing Attribute Context Pricing Attribute Component Step Reqd Flag Seeded




Pricing Attribute XX Criteria Average Attendance 7 Y

Pricing Attribute XX Criteria Number of Days 8 Y


Pricing Attribute XX Common Attributes Licence Days 10

Factors Form

Name Factors

Base Pricing Attributes

Component Base Pricing Attribute Context Base Pricing Attribute Operator Value From Value To Adjustment Start Date End Date

002 ATTENDANCE XX Criteria Average Attendance Between 1 500 1

002 ATTENDANCE XX Criteria Average Attendance Between 501 9999999 2


APPENDIX A

SQL Built-In Functions

Extracts from Oracle® Database SQL Reference 10g Release 2 (10.2)

Numeric Character Datetime Conversion Aggregate

ABS CHR ADD_MONTHS ASCIISTR Large Objects AVG

ACOS CONCAT CURRENT_DATE BIN_TO_NUM BFILENAME COLLECT

ASIN INITCAP CURRENT_TIMESTAMP CAST EMPTY_BLOB CORR

ATAN LOWER DBTIMEZONE CHARTOROWID EMPTY_CLOB COUNT

ATAN2 LPAD EXTRACT COMPOSE COVAR_POP

BITAND LTRIM FROM_TZ CONVERT Collection COVAR_SAMP

CEIL NLS_INITCAP LAST_DAY DECOMPOSE CARDINALITY CUME_DIST

COS NLS_LOWER LOCALTIMESTAMP HEXTORAW COLLECT DENSE_RANK

COSH NLSSORT MONTHS_BETWEEN NUMTODSINTERVAL POWERMULTISET FIRST

EXP NLS_UPPER NEW_TIME NUMTOYMINTERVAL POWERMULTISET_BY_CARDINALITY GROUP_ID

FLOOR REGEXP_REPLACE NEXT_DAY RAWTOHEX SET GROUPING

LN REGEXP_SUBSTR NUMTODSINTERVAL RAWTONHEX GROUPING_ID

LOG REPLACE NUMTOYMINTERVAL ROWIDTOCHAR Hierarchical LAST

MOD RPAD ROUND ROWIDTONCHAR SYS_CONNECT_BY_PATH MAX

NANVL RTRIM SESSIONTIMEZONE SCN_TO_TIMESTAMP MEDIAN

POWER SOUNDEX SYS_EXTRACT_UTC TIMESTAMP_TO_SCN Data Mining MIN

REMAINDER SUBSTR SYSDATE TO_BINARY_DOUBLE CLUSTER_ID PERCENTILE_CONT

ROUND TRANSLATE SYSTIMESTAMP TO_BINARY_FLOAT CLUSTER_PROBABILITY PERCENTILE_DISC


Numeric Character Datetime Conversion Aggregate

SIGN TREAT TO_CHAR TO_CHAR CLUSTER_SET PERCENT_RANK

SIN TRIM TO_DSINTERVAL TO_CLOB FEATURE_ID RANK

SINH UPPER TO_TIMESTAMP TO_DATE FEATURE_SET REGR_

SQRT TO_TIMESTAMP_TZ TO_DSINTERVAL FEATURE_VALUE STATS_BINOMIAL_TEST

TAN NLS Character TO_YMINTERVAL TO_LOB PREDICTION STATS_CROSSTAB

TANH NLS_CHARSET_DECL_LN TRUNC TO_MULTI_BYTE PREDICTION_COST STATS_F_TEST

TRUNC NLS_CHARSET_ID TZ_OFFSET TO_NCHAR PREDICTION_DETAILS STATS_KS_TEST

WIDTH_BUCKET NLS_CHARSET_NAME TO_NCLOB PREDICTION_PROBABILITY STATS_MODE

TO_NUMBER PREDICTION_SET STATS_MW_TEST

General Comparison Character Number TO_SINGLE_BYTE STATS_ONE_WAY_ANOVA

GREATEST ASCII TO_TIMESTAMP Encoding and Decoding STATS_T_TEST_

LEAST INSTR TO_TIMESTAMP_TZ CASE STATS_WSR_TEST

LENGTH TO_YMINTERVAL DECODE STDDEV

Null – Related REGEXP_INSTR TRANSLATE…USING DUMP STDDEV_POP

COALESCE UNISTR ORA_HASH STDDEV_SAMP

LNNVL SUM

NULLIF VAR_POP

NVL VAR_SAMP

NVL2 VARIANCE

SQL Built-In Functions for Pricing Formulas in Oracle Advanced Pricing

August 2011

Author: Marcus Lawrence

Contribution Acknowledgements: Stuart May, Kevin DeMartelaere, Stanislas Martin, Carolyn Graver and Pradeep Bansal

Oracle Corporation

World Headquarters

500Oracle Parkway

Redwood Shores, CA94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200

www.oracle.com

Oracle - Hardware and Software Engineered to Work Together

Oracle is a registered trademark of Oracle Corporation.

Various Product and service names referenced here in maybe trademarks of Oracle Corporation.

All other product and service names mentioned maybe trademarks of the irrespective owners.

Copyright©2002 Oracle Corporation

All rights reserved.

Pricing Formula

Documents

pricing formulas

pricing attributes

oracle advanced pricing

oracle advanced pricing

use of sql builtin functions

pricing attribute step

formula formula steps

seeded functions