Implementation Methodology

This chapter covers the following topics:

Overview of Implementation Methodology

The methods outlined in this chapter can be used by licensed customers of Oracle Advanced Pricing, Oracle implementation consultants, and Oracle pre-sales consultants.

Oracle Advanced Pricing Concepts

Before developing a pricing solution model for customer requirements, you should understand how the following pricing concepts are used to describe your pricing rules, pricing actions, controls, and the links to any extensions you employed.

Pricing Rules

Pricing rules describe the rules-based logic that the pricing engine uses to apply a pricing action to a transaction.

Pricing rules are built around the customer and product hierarchies, and are often linked to the customer. Because customers belong to single or multi-level groups, Oracle Advanced Pricing enables you to define rules that associate pricing actions with a group or level of a group that a customer belongs to.

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.

You can set up pricing rules in the Qualifier window to describe customer and non-product rules. These qualifier objects are then attached to pricing actions. The product hierarchy definitions are contained in the action objects. For example, if a price list calls for all items in item category A to be priced at $1.00, the product definition is setup as part of the Price List window rather than using the Qualifier window. To restrict the usage of the same price list to only a VIP customer class, enter the customer class in the Qualifier window.

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, a discount that lowers the list price down to a net selling price is 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 windows, or objects. These objects are:

Modifiers are a class of pricing actions that modifies the net price either up or down. You can select from several types of modifiers to apply a specific pricing action with specific behavior characteristics.

Note: Modifiers are sometimes called adjustments.

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.

There are many different controls in pricing. All are important, but some require more careful planning prior to implementation.

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:

Basic Flow of Pricing

The following image depicts the basic flow for Oracle Advanced Pricing:

Pricing Flow

the picture is described in the document text

Oracle Advanced Pricing prices any transaction by first identifying a list price defined in a price list. Pricing determines whether the price found on the price list must be adjusted. Modifiers control the price of these adjustments, and can modify price either up (positive) or down (negative). Once the pricing engine has selected one or more modifiers that adjust the price or applies a benefit, it computes the final price or net selling price.

Pricing windows

Pricing is comprised of business pricing entities, each of which has defined functionality. You can use these entities and their associated functionality to construct pricing solutions. You interact with these Oracle Advanced Pricing business entities using windows (also known as Forms) and HTML pages that you set up to obtain functionality.

Pricing windows are specific tools within the Oracle Advanced Pricing product used to provide pricing solutions. Each object has certain functions that it performs as part of the solution. For further discussion of Oracle Advanced Pricing windows, see Oracle Advanced Pricing User's Guide.

Using Oracle Advanced Pricing in the HTML Interface

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.

Note: The HTML user interface is available only in Oracle Advanced Pricing.

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.

Note: Some features, such as qualifier groups, can only be set up in the Forms-based UI.

Accessing the HTML User Interface

To access the HTML user interface, select the Oracle Pricing User responsibility and click the Home link to display the Oracle Advanced Pricing Home page.

See the Oracle Advanced Pricing User's Guide for more information on the features and functions available using the HTML UI.

Methodology Steps

The recommended implementation methodology for Oracle Advanced Pricing consists of three steps.

  1. Analyze pricing needs.

  2. Develop pricing solutions.

  3. Test pricing solutions.

1. Analyze Pricing Needs

The first step in implementing pricing is to understand your customer's pricing requirements. 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 analysis, you can construct a pricing solution.

Note: Pricing Terminology

In analyzing pricing requirement prior to implementing Oracle Advanced Pricing, it is important to consider that pricing terminology varies greatly across companies. Terminology such as tiered pricing, block pricing, off-invoice, price ceilings, price floors, and many others vary in their definition from one company to the next.

The best way to avoid misleading terminology is to define each term by its underlying pricing action and the rules that define the precise conditions under which that action is taken.

Step 1. Define Pricing Requirements

Identify the pricing scenario and its 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.

Step 2. Analyze Pricing Requirements

Define the underlying component pricing requirements by gathering enough information to precisely define the pricing action itself, and the conditions under which this action is to be taken. Break down the preliminary problem statement further:

Step 3. Create Rule and Action Statements

The next step is to develop rule and action statements that define the pricing actions to be taken and the conditions for the 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 Structures Example

In the example it is depicted how a pricing requirement expressed by an end user can be broken down into a pricing action statement and pricing rules that describe the conditions under which the action should be taken. Pricing policies may be defined in broader terms. In this case, before each action is defined along with its associated rules, it is necessary to understand the overall pricing structure of the company.

Step 1: Define the Pricing Requirement

Rick's Souvenir Company sells two different consumer product lines. These products are sold through different sales channels. Rick's Pet Store sells

Rick's edible products are sold through the following:

Rick's collectible products are completely unrelated to the edible products, and are produced in a separate manufacturing facility. They are sold through the following:

Given the overall configuration of the business described, the pricing policies of the company are most likely closely tied to the structure. The following information is discovered after further investigation of Rick's Souvenir Company:

Edible Products

The edible products sold to retail outlets and mass merchandisers receive price breaks depending on the quantity ordered. For example, product 12345 San Francisco Rice Cakes is sold as follows:

Volume Price Per Case
0-49 55
49 - 199 50
199 - 499 45
499 and over 40

All edible products are priced similarly for retail and mass merchandisers. All retail and most mass merchandisers also are subject to receive promotional discounts that are offered to induce higher volume and or build market awareness at certain times of year. As an example, promotional discounts are offered on San Francisco Rice Cakes for orders placed between August 1 and October 15 as an inducement to retailers to build up inventory of San Francisco Rice Cakes for Halloween.

One very large mass merchandiser customer, HugeCo Inc., has elected to eschew promotional pricing in favor of what they term every day low price. They negotiated a net price for each item. In the case of San Francisco Rice Cakes, this builds in an additional 10% off the price per case sold to HugeCo to reflect the theoretical average deal rate that other customers receiving promotional pricing receive for all promotions given throughout the year. This gives HugeCo a different pricing schedule for San Francisco Rice Cakes which is as follows

Volume Price per case
0-49 50
49 - 199 45
199 - 499 40
499 and over 35

Collectible Products

The collectible products consist of decks of cards where each card has the picture of a popular sports figure. The decks of cards are oriented to particular sports, such as baseball, soccer, and football. Collectible sports cards are limited production runs, and are targeted towards consumers who collect and trade the cards. The pricing of one of the collectible card products, the New Millennium Set, varies depending on sales channel. No promotional pricing is used, and quantity discounts are not given. However, for various business reasons, collectible sports card products including item number 65432 New Millennium Set is priced higher to the hobby dealers than to mass merchandisers. A case containing 24 complete New Millennium Sets is priced at $375 to hobby dealers, and the price for mass merchandise outlets is $325.

Step 2: Analyze the Pricing Requirement

Rick's Edible Products have three separate pricing policies or structures: one for grocery, another for mass merchandisers other than HugeCo, and one especially for HugeCo. Within the grocery and mass merchandisers (non-HugeCo) channels, there are two levels or pricing: list price and promotional pricing.

HugeCo also has two levels. In HugeCo's case, these levels are list price and everyday low price. Because HugeCo receives the everyday low price, it should not also receive promotional pricing.

Collectible sports cards have different selling channels each with a different pricing policy. These are hobby list price and mass merchandiser list price. Because there is no promotional price, HugeCo's everyday low price is the same as other mass merchandisers' price.

Step 3: Create Rule, Action, and Control Statements

The following examples are limited to the two products already defined: edibles and collectibles; however, this same approach is used for defining other product pricing.

Edible Product

Pricing action: Give volume sensitive list price (see table for San Francisco Rice Cakes for prices at specific order volume levels).

Pricing action: Give promotional discount of 10%.

Pricing action: Give HugeCo everyday low price schedule (see table).

Collectible Product

Pricing action: Give list price of $375 per case.

Pricing action: Give list price of $325 per case.

2. Develop Pricing Solutions

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

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.

It is very important to determine which price list strategy your organization supports. Advanced Pricing provides a profile option and concurrent program to convert existing prices lists from a Single Currency Price List to Multiple Currency price lists. However, once this profile is enabled, and price lists are converted, users should not return to NON Multi-Currency price lists. Changing the profile back to No may cause undesired results if conversion criteria was used. Oracle does not support changing the setting back to No.

For further discussion on using Multiple Currency Price Lists, see: Oracle Advanced Pricing User's Guide, Multiple Currency Price Lists.

Single Currency Price Lists

Single Currency Price Lists are the default setting for Advanced Pricing. These are used when your business requires that you maintain different prices for different currencies, and there is no relationship between prices defined.

Multiple Currency Price Lists

Multiple Currency Price Lists enables businesses that have pricing strategies based on a single price for an item in a base currency and use exchange rates or formulas to convert that price into the ordering currency. At engine run time, the pricing engine will take the currency from the order and search for a price list(s) with base or conversion currencies matching this currency. The pricing engine converts the price from the base currency and calculates the ordering currency based upon the established conversion rules.

Implementation Decisions Related to Customer and Product Attributes

Customer attributes are used to reference single- or multi-level groups with which a customer may be associated. Pricing rules are structured around these groupings which then affect the pricing actions a customer receives.

Key Implementation Decision: Are the seeded attributes on Oracle customer tables sufficient to contain customer groupings required for your pricing needs?

The following qualifier attributes with context of Customer (also called Customer Attributes) are seeded in Oracle Advanced Pricing:

You can use the preceding attributes by referencing them as qualifiers for either modifiers or price lists.

If the seeded qualifier attributes from the Oracle customer tables are adequate, then further mapping of customer attributes is not required. If the seeded qualifier attributes from the Oracle customer tables are not sufficient, you can create additional customer attributes in Oracle Advanced Pricing using attribute management. For example, you may want to define attributes for additional customer groupings.

For both options, you can use attribute mapping to define the location of the customer data to reference in pricing qualifiers. You must create a default sourcing rule for each defined qualifier attribute because the pricing engine uses mapping rules to locate the attribute values. You have the following options to expand your attributes:

You can map an alternative set of customer attributes using attribute mapping. For more information on attribute mapping, see Overview of Attribute Management.

A customer class is a grouping of customers. You can define as many classifications as you want and set up pricing data depending on how you want to make prices/benefits available to different classifications. For attributes that reference an Oracle Trading Community Architecture (TCA) Party, you can select the Party Hierarchy Enabled check box. This enables you to create qualifiers so that any associated price lists and modifiers are available to the party hierarchy defined in TCA.

Product Hierarchy

Product hierarchies are single or multi-level groups to which a product may be associated. 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.

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:

You can define attributes using the attribute management feature in Oracle Advanced Pricing. When defining product attributes, use the precedence value to define the hierarchy. If the pricing engine must choose between an item price and an item category price, set the item attribute as more specific than the product group attribute.

Item categories and category sets

You can define item categories and category sets for pricing and discounting. Item categories in pricing setups are always based on the item category of the item at the Master Level and not at the Org level.

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 requirements. 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.

Key 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:

Example: Structuring Your Pricing Rules and Actions

Key implementation decisions:

The structure of your customer and product hierarchies is crucial in setting up and implementing Oracle Advanced Pricing because these hierarchies are essential for defining pricing rules.

Product groupings: Lists are set for the individual products and in this case you have specific item numbers. However, the promotional discount of 10% applies to all edible products. Because item number and item category are both seeded elements in the product hierarchy you need not consider extending the product hierarchy.

Price Lists

Set up the following price lists for edible and collectible products

Edible Product

Begin by structuring a single price list that handles list pricing. The following table depicts the price list and its related price break lines:

Context Attribute Unit Price Value Pricing Attribute Value To Value From
Product Item 55 12345 Volume 0 49
Product Item 50 12345 Volume 49 199
Product Item 45 12345 Volume 199 499
Product Item 40 12345 Volume 499 9999999

In the previous example, you set up a price list action in Oracle Advanced Pricing that gives channel specific pricing for edible products.

Collectible Product

Now set up a second price list to handle the collectible product 65432 New Millennium Set.

Context Attribute Unit Price Value Pricing Attribute Value
Product Item $375 65432 Customer class Hobby
Product Item $325 65432 Customer class Mass Merch

The price list is qualified for both customer classes of both Mass Merch and Hobby. Because the price is different for the two classes, within the price list, you used customer class as a pricing attribute. This enables you to define the collectible item on the list twice, once for each channel.

Combined Edible and Collectible Price Lists

You can combine the two separate price lists into one price list with both price break lines and price lines:

Context Attribute Unit Price Value Pricing Attribute Value To Value From
Product Item 55 12345 Volume 0 49
Product Item 50 12345 Volume 49 199
Product Item 45 12345 Volume 199 499
Product Item 40 12345 Volume 499 9999999
Product Item $375 65432 Customer class Hobby Not applicable
Product Item $325 65432 Customer class Mass Merch Not applicable

Promotional Discount Modifier

Two adjustments are required for a total solution. The first adjustment: promotional pricing for edible products given to both grocery and mass merchandise class customers. The second adjustment: special everyday low pricing instead of the standard pricing given to HugeCo. A new, additional requirement: the everyday low pricing received by HugeCo must be accounted for as a discount.

First you need a modifier for promotional pricing. The promotional discount is the same percentage for the entire customer class. In the following table, the customer class is Mass Merch and Hobby for the edible products promotional discount.

Context Attribute Value Type Method Amount Incompat. Group
Product Category Edible Discount Percent 10 GRP01

An incompatibility group assignment is added because the modifier should not be used for HugeCo. Build the modifier for HugeCo:

Context Attribute Type Method Unit Price Value Pricing Att. Value From-To Incomp. Group
Product Item PBH Amount 50 12345 Volume 0-49 GRP01
Product Item PBH Amount 45 12345 Volume 49-199 GRP01
Product Item PBH Amount 40 12345 Volume 199-499 GRP01
Product Item PBH Amount 35 12345 Volume 499-999999 GRP01

You defined a modifier for HugeCo that gives HugeCo a new price based on volume. By using a modifier action rather than a price list action, you met the finance requirement to account for the difference in list price and the everyday low price given to HugeCo as a discount. By using Application Method of amount you are substituting the unit prices on the modifier for the unit prices found on the price list shown in either example 1 or example 3 at each volume level. Because modifiers also support price breaks, you structured the HugeCo modifier as a price break.

Having accomplished this, you are ready to turn to your next implementation decision area: pricing controls.

Establishing Pricing Controls

Pricing controls describe a group of features in Oracle Advanced Pricing that enable you to specify how the pricing engine interprets your pricing rules and actions. From an implementation perspective, one is a decision that you should make in your implementation process.

Key Implementation Decisions: Must I implement incompatibility groups?

In the example you used earlier in this chapter, by assigning the two modifiers for HugeCo to an incompatibility group, you can force the pricing engine to only choose one.

Key Implementation Decisions: Must I implement incompatibility groups?

In the example you used earlier in this chapter, by assigning the two modifiers for HugeCo to an incompatibility group, you can force the pricing engine to only choose one.

Must I use Oracle Advanced Pricing's exclusivity feature?

Exclusivity enables you to specify a modifier that, if selected by the pricing engine, is the only modifier applied to a transaction.

Do I instruct Oracle Advanced Pricing to use precedence or best price to decide between incompatible modifiers?

Oracle Advanced Pricing offers two methods to choose between incompatible modifiers: precedence and best price. Precedence is the usually the best choice.

Must I implement GSA Pricing?

GSA pricing enables you to establish a floor level price. It is used to comply with General Services Administration Pricing rules. GSA pricing integrates with Oracle Order Management.

Must I use multiple pricing buckets? If so how many levels do I need?

Pricing Buckets give you the capability to handle discounts with multiple subtotals.

Do the seeded pricing phase/Oracle Order Management event relationships work or must I reconfigure them?

Pricing modifiers and price lists must be associated with a specific pricing phase. When an application calls the pricing engine during a pricing request, the phase is identified in the call; this enables the pricing engine to select only the qualified pricing actions for that phase. In Oracle Order Management, the integration with prices links certain physical events in the order processing cycle to specific phases. By linking events to a specific phase, Order Management can specify particular pricing phases to the engine. The mapping of pricing phases to order management events can be configured by the user.

More detailed information on the pricing phases and how to use them, see: Oracle Advanced Pricing Implementation Guide, What are Pricing Phases?.

What effectivity dates must I establish?

Oracle Advanced Pricing provides very extensive effectivity dating capabilities. When the pricing engine is invoked by a calling application such as Oracle Order Management, it is passed a pricing date. The engine uses this date as a reference point to compare to effectivity dates found on various pricing forms.

The pricing date can be defaulted in Oracle Order Management. For specifics, see Oracle Order Management User's Guide.

What unit of measure considerations are necessary for Oracle Advanced Pricing setup?

If the Pricing engine attempts to determine a base price for a transaction, then the engine attempts to search qualified price lists for a price in the unit of measure that is in transaction line to be priced. If the engine finds such a UOM, the transaction UOM becomes the pricing unit of measure.

If that search is not successful, the engine searches for a conversion factor to convert the UOM on the incoming transaction to the primary UOM on the price list line.

The pricing engine returns only those modifiers defined in the same unit of measure as the pricing unit of measure, or where there is no product UOM specified. The latter may be the case if the modifier is not product specific.

Verify that all modifiers and price lists used together have common units of measure. Verify that if the unit of measure on the price list and modifier is different from the ordering UOM, that a conversion factor has been set up.

Do I want to control spending of Promotions?

Promotional Limits functionality enables you to set maximum values for benefits that a customer can receive for a promotion, deal or other modifier. By limiting the amount of a benefit that can be received, you can keep promotional spending within budget and prevent promotion budget overruns.

For more information on Promotional Limits, see: Oracle Advanced Pricing User's Guide.

3. Testing Your Pricing Solutions

The final step in the Oracle Advanced Pricing implementation methodology is to test your pricing solutions.

Note: If you upgraded from a release prior to 11i and are running Oracle Advanced Pricing in Basic Mode with upgraded data, do your testing in a separate test instance of your system.

  1. 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.

  2. Begin with simple scenarios, and then work your way up to more complex ones.

  3. Verify that you receive your expected numerical results.

  4. 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.

Related Topics

Diagnostics and Troubleshooting