Advanced Pricing

Oracle Advanced Pricing is a rules-based application with an engine component to service the pricing requirements of Oracle applications to price customer transactions. Oracle Advanced Pricing enables you to set up pricing actions such as price lists, agreements, formulas, and modifiers that the pricing engine applies to transactions.

 

Oracle Advanced Pricing also enables you to define a set of sophisticated pricing rules (and pricing controls that can be used in conjunction with the rules) to precisely govern how and when pricing actions are applied to transactions. The pricing engine is a software component of Oracle Advanced Pricing that is called by an application such as Oracle Order Management or iStore to apply pricing actions to transactions.. Applications make calls to the pricing engine when transactions need pricing services or need to be priced.

Following are the primary advantages of using Oracle Advanced Pricing over basic pricing capability included in Oracle Order Management:

Advanced Pricing Concepts

Before you develop a pricing solution model for customer requirements, you must understand how Oracle Advanced Pricing works. Pricing concepts can help you learn about the functional capabilities of Oracle Advanced Pricing. There are four
major pricing concepts:

  • Pricing rules
It describes the rules-based logic the pricing engine uses to apply a pricing action to a transaction. Pricing rules are built around the customer and product hierarchies.With Oracle Advanced Pricing you can define rules dependent on data other than the pricing hierarchy. For example, discounts are often progressive-based on volume.
  • Pricing actions
Pricing actions are specific pricing activities that the engine applies to transactions. For example, the pricing engine can establish a list price by applying a price list action to an order line. Similarly, discounts that lower the list price down to a net selling price are a modifier action.
Oracle Advanced Pricing provides pricing actions that can be used to handle pricing problems. Pricing Actions can be directly related to specific pricing forms, or objects. These objects are: Price lists, Agreements, Formulas & Modifiers.
  • Pricing controls
Pricing controls are used to control how pricing applies actions. For example, effectivity dates can be used to control when rules are in effect and when they are not. They can also be used to define when an action that a rule points to can be applied.
Pricing also supports several other types of controls. For example, you can set up phases, which are groups of pricing actions. You can then tie these phases to physical events in order management. Incompatibility groups are another example of pricing controls. You can assign modifiers to incompatibility groups such that only one modifier within an incompatibility group can be selected by the pricing engine.
  • Pricing extensibility
Pricing is often driven by customer factors, by trade customs, or by sales channel requirements. Almost no two companies implement pricing in the same way, even if they compete in the same industry. To address this variability, Oracle Advanced Pricing provides the following extensibility features that help meet your business needs: Flexible attribute mapping & APIs

Advanced Pricing in windows & HTML Interface
Pricing is a collection of business pricing objects, each of which has defined functionality. These objects and their associated functionality are a set of tools that you can use to construct a pricing solution. You interact with these Oracle
Advanced Pricing business objects using windows (or Forms) that you set up to obtain functionality.

Oracle Advanced Pricing provides an HTML-based user interface (UI) that enables you to complete many pricing tasks previously available only in the Oracle Forms-based interface. The HTML UI features guided steps and user-friendly pages
that you can use to set up and maintain modifiers, price lists, and qualifiers.

Cross-Format Compatibility
Pricing entities such as price lists, modifiers, or qualifiers created in one format can be maintained in the other. For example, if you created a price list in the Forms-based UI, you could update and maintain the price list in the HTML UI. You can still use the Forms-based user interface to set up and maintain pricing functions and features as in previous releases.

Methodology Steps

The recommended implementation methodology for Oracle Advanced Pricin consists of three steps:

 
 
Analyzing Pricing Needs
Developing a complete and correct understanding of the customer pricing requirements is the first step in implementing pricing. To develop a pricing solution with Oracle Advanced Pricing, you must break down the pricing requirements into
their component parts. Once you analyze customer requirements, underlying pricing requirement elements, relationships between the elements, and calculations, you can associate each of these elements and their relationships with the correct
business object. From this you can construct a pricing solution.

Define Pricing Requirements
For example, customers in the Northeast Region may order any two digital widgets and receive 10% off of either analog widget item ABC or DEF ordered at the same time. This is a promotional discount given for orders received between October 1 and December 31.

Analyze Pricing Requirements
Break down the requirement into the underlying component pricing requirements. This is accomplished through gathering enough information to precisely define the pricing action itself, and the conditions under which this action is to be taken.

Develop Pricing Solutions
The next step is to develop rule and action statements that define the pricing actions to be taken and under what conditions that pricing action to be taken. First define the action:
Pricing action: Give a 10% discount taken off normal selling price. This action statement is independent of customer, product, or dates.
Pricing rule: Discount action taken only for all customers in the Northeast Region.
Pricing rule: Discount action applied only to analog widgets with item numbers ABC or DEF.
Pricing rule: Discount action taken only when analog widgets are ordered at the same time as digital widgets.
Pricing rule: Discount action taken only for orders received between October 1 and December 31.

Developing Pricing Solutions
Once you have defined your pricing actions and rule statements, you can define a pricing solution within Oracle Advanced Pricing. You begin defining the implementation solution by designing an overall structure for pricing. The following sections contain information necessary for decisions you must make when creating this structure.

1. Implementation Decisions: Single versus Multiple Currency Price Lists Oracle Advanced Pricing supports both single currency price lists and multiple currency price lists. For single currency price lists, there is one currency defined per price list. For multi-currency price lists, a Multiple Currency Conversion list is attached to the price list defining multiple currencies and conversion factors and rules for converting prices.

2. Implementation Decision: Are the seeded context values on Oracle customer tables sufficient to contain customer hierarchy?

When installed with Oracle Order Management, the customer hierarchy in Oracle Advanced Pricing is seeded to roll up individual customers according to the following structure, which is based on RA_Customer: Customer name, Customer class, Site, Ship to, Bill to, Agreement name, Agreement type, GSA, Sales channel & Account type.
If the seeded qualifier context values from the Oracle customer tables are adequate, then attribute mapping for customer hierarchy are not necessary. If the seeded qualifier context values from the Oracle customer tables are not sufficient, there are two options for Release 11i. Both approaches requires you create attribute mapping to attribute mapping to inform pricing of the location of the customer hierarchy data elements you wish to reference in pricing qualifiers.

You must create a default sourcing rule for each qualifier attribute that you define since the pricing engine uses sourcing rules to locate the attribute values. You can use expand the your hierarchies by:
■ Use flex fields on customer table to hold flattened hierarchy.
■ Use tables outside Oracle to house the customer hierarchy.
When defining your customer hierarchy, the lowest level in your hierarchy has the lowest flexfield segment sequence number. For example, the pricing engine must choose between a price for an item negotiated with a specific customer and a price for the same item given to all customers in a customer class. You want the engine to select the customer-specific price. Set the customer qualifier as more specific than the customer class qualifier, and the engine will select your desired price. This flattens your pricing hierarchy across the Qualifier descriptive flexfield. Each hierarchy may be defined within a context or across contexts depending on how many levels you have in your pricing hierarchies.

3. Product Hierarchy : Product hierarchies are single- or multi-level groups to which a product may be associated with. Pricing rules are structured around these groupings which then affect the pricing actions a customer receives.
Each level in your product hierarchy where your business sets its pricing and discounting should be defined as a product attribute in the seeded product context ITEM. Do this step after you specify your requirements to take best advantage of the flexibility of Oracle Advanced Pricing for managing pricing in your enterprise The product hierarchy in Oracle Advanced Pricing is seeded with ITEM context based on the Oracle Applications Item Master, MTL_SYSTEM_ITEMS table. For this context, the flexibility of Oracle Advanced Pricing enables you to define your product hierarchy as follows:
Item number, Item category, Item All & Pricing attributes to specify a level more detailed than just item When defining your product pricing hierarchy, the lowest level in your hierarchy has the lowest flexfield segment sequence number. If the pricing engine must choose between an item price and an item category price, set the item segment as more specific than the product group segment. This flattens the pricing hierarchy in the item context of your Pricing Attribute descriptive flexfield. Each level in your hierarchy at which you wish to manage pricing is represented as a segment.

Item categories and category sets
You must design and define any item categories and category sets for pricing and discounting. If you use the seeded context values on the Oracle item master, you can use only the predefined item categories context flexfield structure for the Item Categories Key flexfield within Oracle Advanced Pricing. However, you can change the default category code combination for the seeded inventory category. You are limited to the standard seeded item category structure only. Oracle Advanced Pricing does not consider any new structures that you set up for your Item Categories flexfield.

Pricing Attributes
Attributes define exactly what is being priced or modified. Attributes can be factors that affect the price of the item, additional definition that does not require creating an item, or discounting at a level higher than item in the product hierarchy. Creating pricing attributes in different contexts enables attributes to be grouped according to their business. The item context is reserved for defining the product pricing hierarchy. Every level in the product hierarchy at which pricing and discounting is set should be defined as a segment in this context.

4. implementation decision: Must I implement pricing attributes, multiple price lists, or both? What pricing and qualifier attributes do I need, and how do I decide which is which?
Complex pricing scenarios can be best be solved with a combination of pricing attributes and multiple price lists. Not only can a combination of the two be easier to understand and maintain, but it can improve engine performance.
Pricing attributes further control what is being priced or modified on a price list or modifier list. Each level in your product hierarchy should be defined as a pricing attribute in the seeded context, item. You must create a default sourcing rule for
each pricing attribute that you define since the pricing engine uses sourcing rules to locate pricing attribute values.
For multiple price lists, qualifiers offer and/or capability as well as =, between, and not= operators.
For example:
■ If you charge different list prices for the same item, depending on conditions in effect at time of order, you can use pricing attributes.
■ If conditions are product oriented (example Item 123 Grade A is priced differently from same item Grade B) then product attributes are indicated
■ If conditions are not product oriented, but depend on customer’s membership in hierarchy or combination of customer and other factors like order type, time of day, then multiple price lists are indicated

Testing Your Pricing Solutions
The final step in the Oracle Advanced Pricing implementation methodology is to test your pricing solutions.
1. If you upgraded from Release 10.7 or 11 to Release 11i, and are running Oracle Advanced Pricing in Basic Mode with upgraded data, establish a separate test instance of your system and do your testing there.
2. Verify that you tested each scenario. Develop a documented script for each scenario that describes the setup and expected result, and then gives a step by step outline.
3. Begin with simple scenarios, and then work your way up to more complex ones.
4. Verify that you receive your expected numerical results.
5. Once your setups work in your test environment, you can begin replicating these setups into your production environment. Verify that the price list and modifier flags are set to inactive. Select beginning effectivity dates with caution
to prevent the pricing engine from prematurely using new setups for pricing production transactions.
 

Price Lists

Price lists are essential to ordering products because each item entered on an order must have a price. Each price list contains basic list information and one or more pricing lines that define item and/or item category prices. Basic information includes the price list name, effective dates, currency, pricing controls, and shipping defaults such as freight terms and freight carrier. For a price list, you can define price breaks, pricing attributes, qualifiers, and secondary price lists.
A Price list is useful for maintaining the prices and other pricing details of products and services.

  • It serves as a repository of items with their related pricing details. You can call up a price list and add/edit/delete related items and item categories.
  • You can also use the price list to define attributes for the products, which will then determine the pricing action.
  • The pricing engine requires that all items, services, models, option class and options should be selected and displayed on price list.
  • Fields such as payment terms, freight terms and freight carrier are available on the price list form. By defining the OM defaulting rules to use these fields from the price list window, you are able to default values directly into the SO based upon which price list has been selected for the order.

Price List Form Details

The price list Name should be unique across PTEs (Pricing Transaction Entities) otherwise an error occurs. For example, if a price list named Corporate is created in the Order Management PTE, an error message displays if you create a Corporate price list in the Purchasing PTE.

Price List Currency

For international sales, you can record transactions in different currencies by defining a price list for each currency. After entering the currency for an order or return, you must choose a price list in the same currency.
 
Multi-Currency Conversion Lists
For pricing in different currencies, multi-currency conversion lists enable you to maintain a single price list for multiple currencies. However, this is an Oracle Advanced Pricing feature which is available only if Oracle Advanced Pricing is fully installed and multi-currency lists are enabled.

Round To Factor
You can define the number of places to the right or left of the decimal point to which the pricing engine rounds prices from price lists and modifiers from modifier lists. If you enter a negative number, you increase the number of characters to the right of the decimal point. If you enter a positive number, you affect more columns to the left of the decimal point. If you enter zero, rounding occurs to whole decimals. Rounding factor -3 indicates rounding to the nearest thousands (for example,.1007 rounds to .101). Rounding factor of +2 indicates rounding to the nearest hundred; for example 107 rounds to 100).
Note: The pricing engine does select inactive price lists when doing a pricing request. Other applications can call an inactive price list and use relevant information.

Secondary Price List
The pricing engine uses secondary price lists when it cannot determine the price for an item using the price list assigned to an order. Primary and secondary price lists have the same currency.
  1. You can assign the same secondary price list to multiple price lists but you can not assign a secondary price list to a secondary price list.
  2. If the item that you are ordering is not in the primary price list, the pricing engine uses the highest-precedence secondary price list (the secondary price list with the lowest value for the precedence field).
  3. Line-level discounts and modifiers that apply to the primary price list do not apply to the secondary price list.
  4. If an item appears on both the primary and a secondary price list with the same effective dates, the pricing engine uses the primary price list to price the item.
  5. If an item appears on the primary price list but is not active (the effective end date has passed), the pricing engine uses the price on the secondary price list.
Agreement Price List: Oracle Advanced Pricing allows you to establish agreements with your customers that define the prices, payment terms, and freight terms that you negotiate.
There are two methods by which you can manage agreements:
  • Standard agreements which use standard price lists (PRL)
  • Pricing agreements which use agreement price lists (AGR)
Note: If you are unable to query or update the price list after  saving or exiting from the window, consult with your Pricing Administrator for access privileges. Your security access privilege may not allow you to access the price list windows.

Other Tab
 
The Other tab displays the following information, and if applicable, details about the related Sales Agreement:

• List Source Document Number: The number of the sales agreement associated with the price list.
• List Source Code: Displays the code for the price list source (BSO will be the source code for sales agreement).
• Pricing Transaction Entity: Displays the name of the pricing transaction entity creating the price list. This field cannot be updated.
• Source System Code: Displays the code name for the source system creating the price list such as QP for pricing. This field cannot be updated.
Note: The Pricing Transaction Entity and Source System fields display for all price lists regardless of whether there is a related Sales Agreement.
• Shareable box: Indicates if the modifier is shared or not. If non-shareable (the default), then this modifier is specific to that agreement and cannot be used with other sales agreements.

If shared, the modifier is not exclusive to the sales agreement and can be selected for use with other agreements. Source Document Number: This is the Number of the sales agreement associated with the price list. Once you have completed entries in the price list header, you can add price list lines that define the actual items and list prices for the price list.

 
Enter the price list line details as given below

You can define the following types of prices for price list lines:
  • Unit price: A fixed price.
  • Percent Price: A price which is a percent of the price of another item.
  • Formula: Multiple pricing entities and constant values related by arithmetic operators. For example, you define the price of an item to be a percentage price of another price list line.
  • Price Break: If the price of an item varies with the quantity ordered, you can define bracket pricing or price breaks. The following table displays an example of a price break setup:
1.  Product context is always item.
2.  Depending on the value of Product Attribute, select an item number or an item category for the Product Value.
3.  Select a UOM (unit of measure).
Select Primary UOM if this price list line UOM is the primary pricing unit of measure for the item. Oracle Pricing uses the primary pricing unit of measure and the Oracle Inventory unit of measure conversion information to price an order whose unit of measure does not have a price list line.
Select an Application Method. Use Unit Price for inventory items and either the Unit Price or Percent Price for service items
4. Enter Value and Formula as follows:
■ For inventory items, enter the base list price of the item in Value.
■ For service items, enter a value in the Value field. If Application Method is Unit Price, enter the base list price of the item. If Application Method is Percent Price, enter a percent of another item's price.
■ Enter the name of a previously defined static formula in Static Formula.
If you enter a static formula, you must submit the concurrent program Update Formula Price’s to calculate the value. The result of the calculation changes the value of Value.
5. Enter the starting and ending effectivity dates of this price list line in Start Date and End Date.
The dates should be within the start and end effectivity dates of the price list.
6. Enter a numeric value in Precedence; this is the product precedence. When the pricing engine is trying to locate a price, it uses precedence to resolve conflicts when it selects more than one price list line from a price list.
7. Save your work

Copying a Price List

You can quickly create a new price list by copying an existing price list. Only active price list lines (those with an effective end date later than the current date) can be copied.

Adjusting a Price List
Use this process to adjust the prices for a price list. You can adjust prices for the entire price list or selected items, item category sets, and item categories. You can define your criteria further by selecting the item status or creation date of the items to adjust.
For example, you can specify a category so that only the price list lines for the selected category are adjusted. If you leave any of the fields blank, pricing adjusts the price list regardless of that field. You can adjust the price by either an amount or percent:
■ Percent: Enter a value to adjust list prices by a certain percentage. For example, when adjusting by a percentage, entering 10 raises list prices by 10 percent while -10 lowers list prices by 10 percent.
■ Amount: Enter a value to adjust list prices by a fixed amount. For example, when adjusting by an amount, entering 5 increases list prices by five whole units of currency. Entering -5 decreases list prices by five whole units of currency.

Note: You can only view or update a price list for your pricing transaction entity. The profile QP: Pricing Transaction Entity must match the pricing transaction entity of the price list.
You can only view or update a price list in your source system. The profile QP: Source System Code must match the source system of the price list. Otherwise, the price list is view-only.
The profile option QP: Selling Price Rounding Options affects the rounding of adjustments. For more information on this and other profile options.

Pricing Attributes

To define pricing attributes:
1. Click Pricing Attributes in the List Lines tab to display the Pricing Attributes window.


2. Select a Pricing Context and Attribute for the selected product.
3. Select an Operator value: =, not=, or BETWEEN.
4. Enter Value From.
5. Enter a value for Value To, if the Operator is BETWEEN.
6. Save your work.

Setup

The following image depicts the setup flow for Oracle Advanced Pricing. Some of the steps outlined are required and some are optional. If you have already completed a common-application setup (setting up multiple Oracle Applications products) some of the following steps may be unnecessary.

A Required Step With Defaults is required only if you want to change the seeded default values. Review those defaults and decide whether to change them to better suit your business needs. Do optional steps only if you plan to use the related feature or complete certain business functions.

Attribute Management

Attribute mapping enables you to extend your pricing capabilities by using data from a wide variety of non-standard sources to drive your pricing actions. The data sources for the qualifiers and pricing attributes can be from within or outside of Oracle Applications.

Using the attribute management feature, you can complete the following tasks:
• Create new contexts and attributes
• Update existing contexts and attribute properties
• Disable existing attributes.

Creating new contexts and attributes extends the ability of Oracle Advanced Pricing to provide user-defined data sources to drive pricing actions. The three methods to source data for an attribute are:
• User Entered: Attribute value is entered by user.
• Custom Sourced: Custom code is used to derive an attribute.
• Attribute Mapping: The pricing engine derives information from other Oracle Applications and non-Oracle data sources.

Qualifier and pricing attributes are used to define customer or product attributes:
• A product attribute defines product pricing characteristics such as a product item, item number, category, or brand.
• A customer attribute defines customer pricing characteristics such as customer name or customer number.

When the pricing engine gets a pricing request, attribute management retrieves all values for the qualifier and pricing attributes that are associated with the transaction. The pricing engine evaluates these values to determine which price lists and modifiers are eligible for the transaction.

For example, the following setup could define a discount for a specific day of the week:
Pricing Action               Pricing Rule           Data Source          Attribute Value
Discount Modifier            Qualifier           Day of the Week           Monday

Terminology for Attribute Management



Pricing Transaction Entity (PTE)
A PTE is an ordering structure that has associated request types and source systems. Different applications may have different request structures when they make requests to the pricing engine.

Source System

The source system is the application that captures the pricing setup data.

Request Type
The request type identifies the type of transaction that is being priced. Different applications make requests to the pricing engine. Request types of these applications may be different. Some applications may share their request types. For example, iStore and Order Capture share the same request type. On the other hand, Order Management and iStore have different request structures.

Secondary Price List & Qualifiers



1. In the Secondary Price List tab, select a Secondary Price List.
Advanced Pricing - Price Lists window
If the item you are ordering is not in the primary price list, the pricing engine looks for the price on any attached secondary price list. If the item is found, the pricing engine uses the highest precedence secondary price list (the secondary price list with the lowest value in the Precedence field).

2. Save your work.
Note: The pricing engine does not evaluate qualifiers on secondary price lists; however, some user setups may require them to be evaluated. In these cases, the System Administrator must change the profile QP: Qualify Secondary Price Lists to Yes.

To create qualifiers:



1. Select the Qualifiers tab.
Advanced Pricing - Price Lists window: Qualifiers tab
2. Enter a qualifier Grouping Number. Qualifier lines with the same grouping number generate an AND condition and qualifiers with different grouping numbers generate an OR condition.
3. Select the Qualifier Context.
4. Select the Qualifier Attribute. For example, if you selected Qualifier Context = Volume, then all the qualifier attributes for volume are listed (except Order Amount which cannot be used).

Price Breaks

You can use price breaks (bracket pricing) to define prices that vary with the quantity ordered. For example, if you buy up to 10 items the price is $20 per item, but if you buy more that 10 items, you get a lower price per unit.
Note: If you define a price for an Item Category, then all items within the category are eligible for the price break.

When setting up price breaks, you can define price breaks as either Point or Range breaks:

Point break

Defines prices based on the price bracket in which the total quantity falls.
For example, if you ordered 16 units of Item A11111, the total quantity falls into the Price 2 bracket where the unit price is $45. So the total price is calculated as follows:
Total price = 16 * $45 each = $720

Range break
Defines prices based on the ranges of the defined price breaks. For each range, the engine calculates a price and sums across all ranges to obtain the list price.
For example, if you ordered 16 units of Item A11111, the unit price from each price
(Price Breaks 1 and 2) is applied as follows:
• Price I: For the first 11 units * $50 each (unit price from Price 1) = $550
• Price 2: The remaining 5 units * $45 each (unit price from Price 2) = $225 Total price (the extended price) = $550 + $225 = $775. The unit price is now 775/16.

Note: Before setting up price breaks, the following must be selected in the Price Lists window:

  • Line Type: Price Break Header
  • Application Method: Unit Price or Block Price
Define Price Breaks
To define price breaks, click Price Breaks in the List Lines tab of the Price Lists window to display the Price
Breaks window.


1. The Pricing Context is Volume (default), and the Pricing Attribute is Item Quantity. Optionally, select a different Pricing Attribute.

2. Enter a Value From and Value To. Price ranges for breaks must start with 0 with no gaps between breaks. If you leave the Value To field blank, a value of 999999.. (15 digits long) defaults in the database, but does not display in the Value To field.

3. Enter a Price:
• For inventory items and item categories, enter the base list price of the item.
• For service items: If the Application Method is Unit Price, enter the base list price of the item. If the Application Method is Percent Price, enter a percent of another item's price.

4. Select an Application Method.
• Unit Price: For inventory items and item categories.
• Percent Price: For service items. You will only see Percent Price as an Application Method if the price list line is a service item.
• Block Price: Using block pricing, you can apply a lumpsum price rather than a per unit price to a price list line. Block pricing also allows pricing setups that price by recurring values within blocks

5. Optionally, enter a Recurring Value for a block price. For example, if the Recurring Value is 100, then the range is priced for every 100 items within the block.
Note: The Recurring Value field is enabled when the following values are selected:
• Break type is Range.
• The application method of Block Price is selected for both the price list line and price break line

Price Breaks with Block Pricing



Using block pricing, you can apply a lumpsum price rather than a per unit price to a price list line. Block pricing also provides flexibility when the unit of measure (UOM) of the header is different from the pricing attributes of each break range.

  • In non-block pricing price breaks, the UOM of the break range lines is the same as that of the header.
  • In block pricing, the break ranges can have different units of measure than the header. Lastly, block pricing also allows pricing setups that price by recurring values within blocks.
In regular breaks, lines have the application method of unit price (for inventory items) and percent price (for service items only). For block pricing breaks, unit price or percent price is replaced by block price to differentiate between the line UOM and the header UOM. Like regular breaks, block pricing can be defined for either Point or Range price
types.

When the break type is Range, and application method is BLOCK, you can define a recurring value for that block. For example, if the Recurring Value is 100, then the range is priced for every 100 items within the block.
Note: If the recurring value does not divide evenly into the block, the resulting price is a prorated amount, not a flat rate, of the block price.

The following examples show how price breaks with block pricing could be used:

Example 1: Example of Block Price Using a Recurring Value
You can apply a block price and have the price repeat for defined intervals (the recurring value); for example, to charge $10 per 100 items up to 1,000 items. In this example, the recurring value is 100.

Note: You cannot use Recurring Value if the Price Type is Point.
When a recurring value is used with price breaks, the Block price repeats for every interval defined by the Recurring Value column. In this example, for the first 1200 units, the price is $10 for each 100 units up to 1200 units.
For over 1200 units and more, you could create a second price to define a price of $30 for each 100 units.
Therefore, if 1,300 units were purchased, the total cost would be $150, which is calculated as follows:
• Block price 1: Price for first 1200 (1200/100= 12 X $10): $120 (first price break)
• Block price 2: Price for each additional block of 100 units beginning with 1201 units: $30 (second price break)

Block Price with Application Method of BLOCK PRICE and BREAK UNIT PRICE
If BLOCK PRICE is selected as the application method in the price header for a price list (this is possible only with Range breaks), you can select the following application methods for the price lines:
• BLOCK PRICE
• BREAK UNIT PRICE
When the BREAK UNIT PRICE application method is used in the line, the price specified is the break unit price per attribute. For example, if the price is based on the price attribute Item Weight, the price to be specified is price per unit weight. When setting up the price break, the price provided should be the break unit attribute price. The break unit price for the ordered item is calculated by multiplying the BREAK UNIT PRICE with the sourced Volume Attribute value divided by the ordered quantity. For example: if the Item Weight in lbs is used as the Volume Attribute in the following price breaks ($10 is the price per lb.):



The Item Weight is sourced from the total line weight of a sales order line. For example, if a sales order is entered for three items each weighing 2 lbs, then the unit list price returned from the preceding price would be: [10 X 6]/3 = $20. Six is the total line weight (2 x 3) lbs.

Modifiers


Modifiers enable you to set up price adjustments (for example, discounts and surcharges), benefits (for example, free goods and coupons), and freight and special charges that can be applied immediately to pricing requests or accrued for later disbursement. Using modifiers, you can:

    * Set up a modifier list with multiple modifier lines that define the terms of the price adjustment.
    * Create eligibility rules for modifiers by assigning list and line level qualifiers.
    * Define modifiers that are incompatible with other modifiers.
    * Create exclusive modifiers.
    * Create cascading modifiers.
    * Accrue monetary and nonmonetary benefits.
    * Create monetary or usage limits that a customer can receive for a promotion, deal, or other modifier.

Modifiers determine the adjustments made to the list price. These are dependant on various business factors such as type of adjustment to make, the level at which adjustments are made, how the modifiers are qualified, how they are applied, etc.

Using  modifier lists, you can create groupings of price adjustments, and freight and special charges that you offer and report together to meet various business needs.At the list level, you define criteria that is common to all of the line level modifiers. You can create three modifier list types in oracle pricing
1. Discount List
2. Surcharge List
3. Fright and Special Charges list


■Use modifier lines to define the type of price adjustments, or freight and special charges that the pricing engine applies to pricing requests. You can associate certain line types with each list type. You can use the following line types:
 Discount: Creates a negative price adjustment.
 Surcharge: Creates a positive price adjustment.
 Freight charge: Applies a freight charge.
 Price Break: Applies a variable discount or surcharge price adjustment to a   pricing request based meeting the condition of a break type.Only point price breaks are allowed in basic pricing modifiers. for ex, the following pricing decisions are:
If item quantity = 1-50, then discount=5%

■The table below describes Modifier List Types and if Discounts, Surcharges, or Freight and Special charges are applicable to the List type. A value of
 Yes: indicates that the entity is available for the Modifier List Type.
 No: indicates that the entity is not available for the Modifier List Type.

Create a modifier list
1. In the Main tab, select the modifier Type.

2. Enter a Number and Name for the modifier list; the value does not have to be numeric.
Note: The modifier Name should be unique across all PTEs (Pricing Transaction Entities) otherwise an error occurs. For example, if a modifier named "Corporate" is created in the Order Management PTE, an error message displays if you create a "Corporate" modifier in the Purchasing PTE.

3. The Global box is selected when the Pricing Security Control profile option is set to ON. This means that the modifier list can be used by all operating units for pricing transactions. If Global box is deselected, operating unit field is displayed. If multi-org access is NOT enabled, operating unit defaults from profile MO: Operating Unit. This operating unit field cannot be updated by users. If multi-org access is enabled, operating unit defaults from profile MO: Default Operating Unit.
Users can over-ride this default and select an operating unit that they have access to as defined by MO: Security Profile. The use of this modifier is then only restricted to pricing transactions for this operating unit.

4. Select or clear Automatic:
• If selected, the Automatic box is also selected at the line level, and the pricing engine automatically applies the modifier.
• If cleared, then the modifier must be manually applied.
Note: If you select Automatic for a list, all the lines for this list default to Automatic.

5. Enter Currency. This is an optional field.

6. Enter the Start Date range.
Note: If you do not enter dates (start/end), the list is effective from the creation date and does not become ineffective.

Creating List Level Qualifiers
Modifier list level qualifiers help the pricing engine to determine who is eligible for the modifier lines. If an order is not eligible for a modifier list, it is not eligible for that list's line level modifiers even if the lines have qualifiers for which the order is eligible.

Creating Modifier Lines
Use this process to create modifier lines to define how the price is adjusted. Once you have created and saved a modifier line, you cannot edit or change the Product Attribute Value for the line. To change the Product Attribute Value for a line, you should end date the existing modifier and create a new modifier.

1. Enter the Level.
• Line: The pricing engine determines if the pricing request is eligible for this modifier by validating the request for each line. It applies this modifier at the line level.
• Order: The pricing engine determines if the pricing request is eligible for this modifier by validating the pricing request header. It applies this modifier at the order level but prorates a percentage value to each line.

2. Enter Modifier Type from the following:
• Discount
• Surcharge
• Freight/Special Charges
• Price Break

3. Select or clear Automatic. If you select it, the pricing engine automatically applies this modifier. If you clear it, someone must manually apply it to an order.
Note: If you select Automatic at the modifier list level, Automatic for each line appears as selected but you can change it. You can allow manual application of discounts, surcharges, and freight and special charges line types.

4. Select or clear Override.
If selected, you can manually change how the modifier is applied for each order.

5. The values of Pricing Phase, Incompatibility Group, and Bucket will be dependent on the modifier level chosen.
For Basic Pricing, the Incompatibility Group will always be Level 1 Incompatibility Group, and bucket will be defaulted to 1 for line level modifiers.
Enter discount,surcharge information and freight charge information in appropriate tabs.

Creating Line Level Qualifiers
Modifier line level qualifiers help the pricing engine to determine who is eligible for the modifier lines. If an order is not eligible for a modifier line, it is not eligible for the line level modifiers even if the lines have qualifiers for which the order is eligible.

Once a qualifier is end dated, the group having that end dated qualifier becomes invalid. The modifier having that end dated qualifier will apply only if there is another group of qualifiers that satisfy the conditions and are within the valid date ranges.

Modifier Concepts



Using modifiers, you can set up price adjustments, benefits, freight and special charges, and promotional limits to control spending or usage. You can define simple discounts and surcharges as well as more advanced deals and promotions. The following list describes the main modifier concepts and related entities:

  • Modifier lists contain one or more modifiers. Modifiers have list level and line level components. Each list level must have one or more lines associated with it.
  • By defining qualifiers at the list and line levels, you define a customer's eligibility for the modifier.
  • Control features that influence modifiers are products and product groups, pricing attributes, phases, incompatibility groups, levels, and buckets.
  • The use of modifiers can result in volume breaks, additional buy/get products, and benefits.
Modifier Components


Using modifier lists, you can create groupings of price adjustments, benefits, and freight and special charges that you offer and report together to meet various business needs.

At the header level of the modifier list, you define criteria that is common to the modifier lines. Create modifier lines for a modifier list to define the type of price adjustments, benefits, or freight and special charges that the pricing engine applies to pricing requests.

Adjustment Method



The adjustment method (also known as the application method in the forms-based UI) determines how the modifier applies the price adjustment. You can select from the following adjustment methods:

  • Percent: Creates a percentage price adjustment on each unit based on the percentage entered in the Value field. For example, to apply a 10 percent discount, select percent as the adjustment method.
  • Amount: Creates a fixed price adjustment on each unit using the amount entered in the Value field.
  • Lumpsum: Creates a price adjustment for this lump sum amount on the entire line.
  • New price: Overrides the selling price of this item and makes the new price (defined in the Value field) the new selling price. Creates a price adjustment for the difference between the list price and the new price.
The following table shows examples of how the pricing engine uses the adjustment method to calculate the extended selling price of an order line:


Lumpsum Adjustment Method with Group of Lines
When Lumpsum is selected as the adjustment method for a modifier line, the pricing engine creates a price adjustment for the defined lumpsum amount. The lumpsum can be based on group quantity (sum of item quantities) or an item amount (a monetary amount).

Two examples are provided to compare how the lumpsum amount is calculated if either 1) Group Quantity or 2) Item Amount is selected.
The following Discount list modifier is used in each example.

QP_PREQ_PUB.PRICE_REQUEST

QP_PREQ_PUB.PRICE_REQUEST API can be called to obtain the Price of an item

NB - is important to ensure that the pricing phase on the modifier line matches the pricing event used when calling the API.

For example if the pricing phase on the modifier is -- All Line Adjustments then to apply the modifier -- p_control_rec.pricing_event :='BATCH'; or alternatively change the pricing phase to -- List Line adjustments (note that setting the phase to the value will cause the pricing engine to update the price whenever the order line is changed and may have an impact on performance).
Pricing Attributes

1. Item priced is Inventory Item ID - 307627

Qualifier Attributes
1. Price List is Price List ID - 54824
2. Customer is Customer ID - 16071

A Modifier has been created where:
1. The Modifier is qualified at Header Level by the Customer ID - 16071
2. The Line on the modifier is qualified by pricing attribute - Inventory Item is 307627.

Price List
1. For Testing purposes I have not included the Inventory Item ID -- 307627 on the price list - 54824
2. The Price List does however include an ALL_ITEMS value which sets the price to 1.23

When Calling the PRICE_REQUEST API, I have passed the following values.

1. ALL_ITEMS pricing attribute which will be used to return a price from the price list if the item has not been included on the price list. This will only return a price if the Price List has a value for ALL_ITEMS.

line_attr_rec.LINE_INDEX    := 1;
line_attr_rec.PRICING_CONTEXT    :='ITEM';
line_attr_rec.PRICING_ATTRIBUTE   :='PRICING_ATTRIBUTE3';
line_attr_rec.PRICING_ATTR_VALUE_FROM   :='ALL';
line_attr_rec.VALIDATED_FLAG    :='N';
p_line_attr_tbl(1)    := line_attr_rec;

2. The Inventory Item to be priced

line_attr_rec.LINE_INDEX    := 1;
line_attr_rec.PRICING_CONTEXT    :='ITEM';
line_attr_rec.PRICING_ATTRIBUTE   :='PRICING_ATTRIBUTE1';
line_attr_rec.PRICING_ATTR_VALUE_FROM   :='307627';                  -- INVENTORY ITEM ID
line_attr_rec.VALIDATED_FLAG    :='N';
p_line_attr_tbl(2)    := line_attr_rec;

---- Qualifier Attribute Record

3. The Price List used to price the item

qual_rec.LINE_INDEX     := 1;
qual_rec.QUALIFIER_CONTEXT    :='MODLIST';
qual_rec.QUALIFIER_ATTRIBUTE    :='QUALIFIER_ATTRIBUTE4';
qual_rec.QUALIFIER_ATTR_VALUE_FROM   :='54824';                     -- PRICE LIST ID
qual_rec.COMPARISON_OPERATOR_CODE   := '=';
qual_rec.VALIDATED_FLAG    :='Y';
p_qual_tbl(1)     := qual_rec;

4. Customer Qualifier will be used to determine (in this test) which modifier is to be used.

qual_rec.LINE_INDEX     := 1;
qual_rec.QUALIFIER_CONTEXT    :='CUSTOMER';
qual_rec.QUALIFIER_ATTRIBUTE    :='QUALIFIER_ATTRIBUTE2';
qual_rec.QUALIFIER_ATTR_VALUE_FROM   := 16071 ;   -- CUSTOMER ID;
qual_rec.COMPARISON_OPERATOR_CODE   := '=';
qual_rec.VALIDATED_FLAG    :='Y';
p_qual_tbl(2)     := qual_rec;

The following Script will create a procedure called XX_TEST_PRICE_REQUEST ---  PRICE_REQUEST_API_EXAMPLE.sql

Do the following to run the script from a SQL*Plus session

SQL> Set Serveroutput on size 100000
SQL> Exec XX_TEST_PRICE_REQUEST

This should then return output similar to:

File : /usr/tmp/l5027518.dbg
Return Status text Routine: QP_PREQ_PUB.PRICE_REQUEST SUCCESS
Return Status  S
+---------Information Returned to Caller---------------------+
-------------Request Line Information-------------------
Line Index: 1
Unit_price: 1.23
Percent price:
Adjusted Unit Price: .615
Pricing status code: UPDATED
Pricing status text:
-----------Pricing Attributes Information-------------
Line detail Index 3
Context ITEM
Attribute PRICING_ATTRIBUTE1
Value 307627
Status Code
---------------------------------------------------
Line detail Index 2
Context ITEM
Attribute PRICING_ATTRIBUTE3
Value ALL
Status Code
---------------------------------------------------
-----------Qualifier Attributes Information-------------
Line Detail Index 3
Context CUSTOMER
Attribute QUALIFIER_ATTRIBUTE2
Value 16071
Status Code N
---------------------------------------------------
------------Price List/Discount Information------------
Line Index: 1
Line Detail Index: 2
Line Detail Type:NULL
List Header Id: 54824
List Line Id: 189859
List Line Type Code: PLL
Adjustment Amount : 1.23
Line Quantity :
Operand Calculation Code: UNIT_PRICE
Operand value: 1.23
Automatic Flag: Y
Override Flag:
status_code: N
status text: INSERTED IN L_LIST_CUR
-------------------------------------------
Line Index: 1
Line Detail Index: 3
Line Detail Type:NULL
List Header Id: 191260
List Line Id: 221749
List Line Type Code: DIS
Adjustment Amount : -.615
Line Quantity :
Operand Calculation Code: %
Operand value: 50
Automatic Flag: Y
Override Flag: N
status_code: N
status text: PRODUCT_QUALIFIER_ONLY
-------------------------------------------
--------------Related Lines Information for Price Breaks/Service
Items---------------

PL/SQL procedure successfully completed.

Pricing Security


In addition to the functional security, Oracle Advanced Pricing provides an additional level of security
called pricing security. Pricing security provides an additional security which can be used to restrict pricing activities such as updating and viewing pricing entities to users who are granted specific access privileges.

Oracle Pricing Administrator responsibility can be used for pricing security set up and maintenance.  This responsibility provides an HTML user interface and provides the authorization to access & update all pricing entities. The features provide by pricing security are:

1. Restricting pricing entities to operating units:
Pricing entities (Price list & Modifiers) are not part of the multi-org structure provided by oracle EBS but pricing security can be used to assign a pricing entity to a specific operating unit.

You can restrict usage to one operating unit or allow usage by all operating units by making it Global.
Global Usage: A pricing entity can be used across all operating units when making a pricing request. A pricing entity is originally owned by the creating organization. At creation checking the 'Global' flag allows usage across operating units; unchecking it restricts usage to the owner organization. Ownership/Usage may be updated on this page.

2. Restricting pricing entities to grantee (Global, Operating Unit, Responsibility, or User level) :
You can grant view-only or maintain access privileges to functional users at the Global, Operating Unit, Responsibility, or User level.

Pricing Security Terms (as in Oracle user guide)


The following terms are used in Oracle pricing security:

1.1 Pricing Entity: A pricing entity can be a price list, modifier list, or pricing agreement.

1.2 Entity Set: A set of pricing entities that can be used as an Entity Type to which you
can grant privileges with Maintain or View-Only access levels.

1.3 Entity Type: A term used to describe one of the following pricing entities: Standard Price list, Modifier List, Pricing Agreement, and Entity Set.

1.4 Entity Usage: Grants the usage of the entity to one or all operating units so that it can be used during pricing engine calls.

1.5 Global Usage: When Global Usage is set to Yes for a pricing entity, it can be used across all operating units for processing orders. If No is selected, the usage of the entity is restricted to the operating unit that created or owns it.
When security is turned on, a Global box indicating Global Status is dynamically added to the header region of all price lists and modifiers. A user with Maintain access privileges can update the Global box.

2.1 Grantee: The specific user or users for a Grantee Type who are given permission to view or maintain a pricing entity. Used in combination with a Grantee Type.

2.2  Grantee Type: The level to which privileges are granted:

  • Global: Includes all users with access to pricing menus.
  • Operating Unit: Includes users who have the named operating unit as the default operating unit (as specified in MO: Default Operating Unit profile).
  • Responsibility: Includes users within the named responsibility.
  • User: Specifies a named user.

2.3  Access Level: Provides Maintain or View-Only access to a pricing entity:

  • View-Only: Enables the user to view but not update the pricing entity.
  • Maintain: Enables the user to view and update pricing entities. Not all of the entities support delete capabilities.

Advanced Pricing Responsibilities:
Advanced Pricing comes with three seeded responsibilities. These responsibilities have different purposes as explained below.

Oracle Pricing Administrator
The user who is assigned the Oracle Pricing Administrator responsibility has complete access to all pricing entities without restriction and is responsible for the global setup and administration of pricing security.
The administrator is responsible for Privileges, Entity Sets & Entity Usage setups.

Oracle Pricing Manager
The user who is assigned the Oracle Pricing Manager responsibility can access all features for setting up, using, and maintaining pricing features and functions (except pricing security) such as price lists, pricing formulas, modifiers, attribute management, and item and category management.

Oracle Pricing User
This responsibility provides access to the HTML user interface where you can create price lists and modifiers (Deal, Discount, Promotion, Surcharge), access the price list maintenance feature, and attach qualifiers and qualifier groups to modifiers and price lists.