This chapter covers the following topics:
The methods outlined in this chapter can be used by licensed customers of Oracle Advanced Pricing, Oracle implementation consultants, and Oracle pre-sales consultants.
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 actions
Pricing controls
Pricing extensibility
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:
Price lists
Agreements
Formulas
Modifiers
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:
Flexible Attribute Mapping
Oracle Advanced Pricing, when licensed with Oracle Order Management, Oracle iStore, or other Oracle products, provides you with defaults for the customer and product hierarchy and other commonly referenced pricing rule drivers. These can be used without extending the product.
For customers whose product or customer hierarchy is more complex, Oracle Advanced Pricing provides flexible attribute mapping. This enables you to add or change levels of the customer and product hierarchy in addition to the seeded values delivered with the product. You can use attribute mapping to substitute an alternative source and structure for either the product or customer hierarchy, rather than using those supplied as defaults when the product is installed.
You can use attribute mapping to link Oracle Advanced Pricing to data maintained outside Oracle Advanced Pricing and outside Oracle Applications. In addition to the customer and product hierarchy related data mentioned, you can use attribute mapping to make pricing read a currency rate from an external source used in a pricing formula computation.
Application Programming Interfaces (APIs)
Oracle Advanced Pricing delivers a set of public APIs that you can leverage using your own code. This enables you to significantly extend the use of Oracle Advanced Pricing.
For example, the Get_Custom_Price API can be linked to a price list using a formula with a term of type Function. You can use this API to make Oracle Advanced Pricing obtain a cost from a purchase order that is used in a calculation that yields a selling price based on actual cost.
Oracle Advanced Pricing APIs are documented in the Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide. For users who want to write code for these APIs, a downloadable ARU is available on My Oracle Support that contains coding examples.
The following image depicts the basic flow for Oracle Advanced Pricing:
Pricing Flow
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.
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.
The recommended implementation methodology for Oracle Advanced Pricing consists of three steps.
Analyze pricing needs.
Develop pricing solutions.
Test pricing solutions.
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:
Distinguish between the digital widgets and other widgets. Digital widgets are discounted separately from analog widgets.
The pricing solution must allow for either 1 or 2 of each digital widget to qualify for the free item.
The pricing solution model must allow for adding multiple lines to the order to allow line 1 and 2 to be combined to equal the mix and match criteria.
The 10% discount is taken off the selling price.
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 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.
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
Edible products
Collectible products
Rick's edible products are sold through the following:
Grocery store retail outlets
Mass merchandiser retail outlets
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:
Hobby and toy stores
Mass merchandiser retail outlets
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 rule: For product San Francisco Rice Cakes.
Pricing rule: For all customers belonging to retail customer class and to all customers in mass merchandiser customer class.
Pricing action: Give promotional discount of 10%.
Pricing rule: For all customers belonging to retail customer class and to all customers in mass merchandiser customer class.
Pricing rule: For product San Francisco Rice Cakes.
Pricing rule: Exclude HugeCo from previous rule.
Pricing rule: Apply to all orders received between August 1 and October 15.
Pricing action: Give HugeCo everyday low price schedule (see table).
Pricing rule: For product San Francisco Rice Cakes.
Pricing rule: For customer HugeCo.
Pricing control: Apply to all orders for HugeCo received from January 1 to December 31.
Collectible Product
Pricing action: Give list price of $375 per case.
Pricing rule: For product New Millennium Set.
Pricing rule: For all orders for customers belonging to hobby dealers.
Pricing action: Give list price of $325 per case.
Pricing rule: For product New Millennium Set.
Pricing action: For orders for customers belonging to mass merchandiser class.
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 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:
Customer name
Customer class
Site
Ship to
Bill to
Agreement name
Agreement type
GSA
Sales channel
Account type
Party ID
Ship To Party Site
Invoice To Party Site
Note: These attributes can be used as qualifiers for price lists and modifiers. Information about Party ID, Ship To Party Site, and Invoice To Party Site are automatically derived from the sourcing rules.
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:
Use attribute mapping rule to source from Oracle customer tables.
Use tables outside Oracle to store the customer 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 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:
Item number
Item category (supports hierarchical categories)
Item All
Pricing attributes to specify a level more detailed than just item
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:
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
Key implementation decisions:
What qualifiers and qualifier groups do I need?
What customer groupings are required in order to develop qualifiers that implement my pricing rules?
Which pricing actions are needed to process my scenarios?
What product groupings are needed for my pricing actions?
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.
Qualifiers
Qualifiers enable you to define eligibility rules that determine which pricing actions are applied to a transaction. Although a qualifier can be used for any pricing rule, the qualifier window is generally used to define pricing rules related to attributes defined for the customer hierarchy or for other elements not related to the product hierarchy.
When you implement Oracle Advanced Pricing, think in terms of structure for your pricing actions and qualifiers used to select those actions. Use the example of Rick's Souvenirs you used previously in the chapter.
Rick's Souvenirs has two broad product lines each sold through two sales channels. One of the channels overlaps. Pricing followed the channel lines, with the exception of one large customer. Draw some inferences as to how to structure pricing actions and rules based on this information.
Customer Groupings
Two levels of customer hierarchy must be tied to pricing rules:
Customer class: grocery, mass merchandiser, hobby
Customer name: HugeCo
Because customer class and customer name are both seeded elements of the customer hierarchy, no extension to the customer hierarchy is necessary.
Pricing Actions
The action/rule statements derived earlier show that the need for price list and promotional discounting actions that vary by product and are conditioned by channel.
Edible Product
- Price list with breaks for grocery and merchandiser
- Promotional pricing discounts for grocery and mass merchandiser
- Alternative price list with breaks for HugeCo
Collectible Product
- Price list for hobby
- Price List for mass merchandisers
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.
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.
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.
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.
Begin with simple scenarios, and then work your way up to more complex ones.
Verify that you receive your expected numerical results.
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