Technical Considerations

This chapter covers the following topics:

Basic versus Oracle Advanced Pricing

Oracle Advanced Pricing and Oracle Order Management, with its basic pricing component, share a common code set. Licensed users of Oracle Order Management are authorized to use the basic features of the set, while licensed users of Oracle Advanced Pricing are authorized to use the full set of features.

The following SQL statement can be issued from within SQL*Plus to obtain the installation status for Oracle Advanced Pricing: SQL: select qp_util.get_qp_status from dual;.

The following table describes the values of get_qp_status:

Value Meaning
S Shared installation. Only basic pricing features are available.
I Full installation. All Oracle Advanced Pricing features are available.

When pricing functionality is installed SHARED, the setup forms contain restricted function. This is accomplished using several methods, including:

The pricing engine and pricing setup APIs are authorized for use only if Oracle Advanced Pricing is installed.

Note: Although the pricing engine is a common component of both basic and Oracle Advanced Pricing, it does not execute the API Get_qp_status. The pricing engine returns user setups as allowed by the APIs and setup forms.

Architectural Overview

Oracle Advanced Pricing significantly increases the pricing functionality of Oracle Order Management. Both Oracle Advanced Pricing and basic pricing are designed to:

Architectural Changes and Innovations

Some of the major architectural features and innovations of Oracle Advanced Pricing include:

Oracle Advanced Pricing Engine Processing

The Oracle Advanced Pricing Engine is composed of a search engine and a calculation engine.

Search Engine

The search engine uses qualifier and pricing attributes to select a list of price and modifier list lines. These may be applied to the pricing request according to rules of eligibility, incompatibility, exclusivity, and precedence.

Determining Eligibility

The search engine selects lists and list lines based on effectivity dates. It compares the pricing effective date supplied by the calling application against the following dates to determine if a list or list line is effective for the given pricing date:

Active/Inactive Lists

To be selected by the search engine, a list must be marked as Active. If the active flag is set to no (inactive), the search engine does not consider the list, even if it is effective for the pricing date.

Pricing Currency

For single currency price lists, the search engine matches the currency of the transaction to the currency of the price and/or modifier lists. Only lists defined in the same currency as the transaction are selected. The currency of the transaction must be included in the pricing request structure.

To price transactions in multiple currencies, set up a price list and modifier list for each currency for which a transaction may be priced. Formula functionality enables you to convert the base currency price and modifier lists to the transaction currency, passing the transaction currency as a formula pricing attribute.

For Multiple Currency price lists: The search engine matches the currency of the transaction to the currency of the price list(s) with the base or conversion currencies matching this currency. The pricing engine converts the price from the base currency and calculates the transaction currency based on the established conversion rules. The search engine matches the currency of the transaction to the currency of the modifier lists. Only modifiers in the same currency as the transaction are selected. The currency of the transaction must be included in the pricing request structure.

To price transactions in multiple currencies, set up a Multiple Currency price list with attached multiple currency conversions, and a modifier list for each currency where a transaction may be priced.

Identifying Appropriate Transaction Pricing Data

The search engine must know the data source to determine whether it is appropriate to price a transaction. For example, only price lists set up to price contracts should be considered when deriving a price for a contract line.

A source system identifier, which identifies the application that created the pricing data, is recorded on all price and modifier lists. Examples of this include Oracle Order Management, Oracle Marketing, and Oracle Service Contracts.

The request type identifies the type of transaction that is being priced. Each pricing request line must be identified with a request type. Examples of this include Oracle Order Management and Oracle Order Capture.

The mapping of a request type to one or more source systems defines the source(s) of pricing data that are used to price a transaction. For example, if a pricing request line has a request type of Order, the search engine considers only data from a source system that is mapped to this type of request. The following figure illustrates the source system and request mapping concept.

Source system and request mapping concept

the picture is described in the document text

Phasing the pricing of a transaction

A user may configure a pricing transaction, when the source system process flow requires it to occur, through pricing phases and pricing events. Pricing phases and events also define the pricing data that should be considered for application to the request at that point in the transaction process flow. Rather than pricing an entire transaction at once, you may break up pricing into discrete activities.

A pricing event occurs when a specific point in the process flow of the sourcing application requires service by the pricing engine. Pricing events in the source system trigger base price determination for the transaction, certain transaction lines, and price adjustments, benefits, or charges to be applied to the whole transaction or to specific transaction lines.

A pricing phase controls which modifiers are considered by the search engine and in what sequence they should be applied to the request. Some pricing phase attributes determine which modifiers can be placed in a phase. For example, if the list type of the pricing phase is charges, only list lines of this type may be placed in the phase. Phase attributes that are used to control the modifiers placed in the phase are:

A pricing event can be mapped to one or more pricing phases, and a pricing phase can be assigned to more than one pricing event. The following figure illustrates this how pricing events and phases can be mapped.

Pricing events and phases mapping

the picture is described in the document text

The concept illustrated in the previous figure allows the following pricing business rules types to be implemented:

Selecting Price Lists and Modifier Lists based on Qualifiers

A qualifier is a user-defined rule that specifies one or more conditions under which the pricing engine applies a price list, price adjustment, or other benefits or charges. If a condition described in a qualifier evaluates as true when the search engine is processing, then the pricing object(s) tied to that rule are considered eligible by the search engine.

Many companies apply prices and discounts across and at different levels of their customer hierarchy. Each level at which businesses set their pricing and discounting can be conditionally tested in a qualifier.

When creating a price list, discount, or promotion, pre-defined qualifiers can be used to define who is eligible for the price or modifier.

Qualifier attributes are combined with operators to create qualifying conditions for a list header or modifier. The following operators are available:

Qualifying conditions such as the following may be used to define eligibility for prices, promotions, etc.

When pricing a transaction line, the search engine compares the qualifying conditions on the list header with the value of the qualifiers on the pricing request line. Qualifiers for a pricing request line are populated using dimension sourcing. For example, if eligibility for a price list is qualified by Market Sector = Consumer Products, and if the value for the market sector qualifier is consumer products, then the price list is available to price that transaction line. If the qualifiers on the list header are met for modifier lists, the search engine also ensures that any qualifiers at the line level are satisfied.

Qualifiers may be grouped to create AND/OR conditions using a grouping number. For example, if a 10 percent discount is given if a customer is a preferred customer and the customer spends more than $150, the qualifying condition may be defined by creating qualifiers in the same qualifier group:

Qualifier Group Qualifier Attribute Operator Value From Value To
1 Customer class = Preferred Not applicable
1 Order amount Between 150 99999999999

If the requirement is to give a 10 percent discount if a customer is a preferred customer or the customer spends more than $150, the qualifying condition may be defined by creating qualifiers in different qualifier groups:

Qualifier Group Qualifier Attribute Operator Value From Value To
1 Customer class = Preferred Not applicable
2 Order amount Between 150 99999999999

Multiple qualifiers may be included in a qualifier group.

If a qualifier is mandatory for all qualifying conditions and must be included in all qualifier groups, a -1 qualifier group number can be given. The search engine always ensures that this condition is met before proceeding to check all other groups. For example, the conditions to receive a 10 percent discount on an order are that a customer is a preferred customer OR the customer must spend more than $150 AND must place the order on a United Kingdom website, and the customer must always pay with a Visa card. This is defined as follows:

Qualifier Group Qualifier Attribute Operator Value From Value To
-1 Credit card type = Visa Not applicable
1 Customer class = Preferred Not applicable
2 Order amount Between 150 99999999999
2 Website domain = .co.uk Not applicable

Pricing Attributes: Selecting What is Priced

Pricing attributes are user-defined attributes that define what is being priced or modified. Attributes may include factors that affect the price of the item, provide additional definition without the need to create an item, or manage pricing and discounting at a level higher than in the product hierarchy.

Examples of pricing attributes are:

Pricing attributes are defined under contexts and attributes. Creating pricing attributes in different contexts allows attributes to be grouped according to their business use. The context of Item is reserved for defining 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.

Pricing category: Milled goods
Pricing sub-category: Flour
Margin group: Branded flour
Margin sub group: Homepride
Product group: White
Size 1.0kg
Configuration 12*2
Stock keeping unit: SKU1234

Product Pricing Hierarchy Example

In the product pricing hierarchy example given, each of the eight levels are defined as attributes in the item context in the pricing context defined in contexts and attributes.

The attributes are ordered to reflect the structure of the product pricing hierarchy, with the lowest level in the hierarchy having the lowest sequence number. The search engine uses the sequence to select the most specific price or discount. For example, if no price is found for a promotion product, use the configuration price. If no price is found for the configuration, use the pack size price. If no price is found for the pack size, use the flour type. The item context of the pricing attribute represents a flattened view of the product pricing hierarchy.

As with qualifiers, the search engine compares pricing attributes on the transaction or pricing request line with pricing attributes on the price or modifier list line. This determines if the base price or modifier can be applied to the request line. Product and pricing attributes for a pricing request line can be either user entered or populated using attribute mapping.

Exclusion enables a price adjustment, benefit, or charge to be given at a level in the product hierarchy but it excludes lower levels in the hierarchy from that modifier. In the product pricing hierarchy defined previously, if a 10 percent discount is given on all flour apart from the Homepride brand, then a discount can be created with a product attribute of Oracle Advanced Pricing Subcategory = Flour, excluding Margin Sub Group = Homepride. The search engine eliminates any pricing request lines with the margin sub group pricing attribute of Homepride.

The search engine returns only those modifiers that are defined in the same UOM as pricing (which is determined when the base price is derived as described) or where there is no product UOM is specified. The latter may be the case if the modifier is not product specific.

UOM Conversion Logic

The search engine only returns modifiers which are defined in the same unit of measure as the pricing unit of measure, or when no unit of measure specified. The latter may be the case if the modifier is not product specific, or if the type of modifier does not require a unit of measure.

Modifier Level Code

Modifier level code determines which qualifiers and pricing attributes are considered by the search engine when deciding if a request line qualifies for a modifier. This code also determines at what level a modifier should be applied to the request.

Line Level Code

Only qualifiers and pricing attributes of an individual request line are considered by the search engine. For volume related pricing attributes only the quantity of the request line is considered for qualification. Modifier application is at the request level.

Group of Lines Level Code

The quantity in the pricing UOM and amount spent on an item is summed across all qualified request lines. The total item quantity and amount on the request or total quantity and amount at a level in the product hierarchy is considered by the search engine when deciding whether a modifier is qualified. Modifier application is at the request line level.

Order Level Code

Only qualifiers or pricing attributes of the summary request line or header are considered by the search engine when deciding whether a modifier is qualified. It is not possible for a header level modifier to be qualified by a request line. Modifier application is at the summary request line/header level.

Freezing Pricing Request Lines

The Calculate Price flag allows the calling application to fully or partially freeze the price on a pricing request line. Price may be completely frozen with no additional modifiers applied, or additional modifiers may be applied in certain phases, depending on the value of the flag. Possible values are as follows:

Flag Value Action
Y (calculate price) Applies all prices and modifiers to the request line.
N (freeze price) Does not apply any prices or modifiers to the request line.
P (partial price) Only applies prices or modifiers in certain phases.

When the calculate price flag is set to partial price, the search engine observes the freeze override flag on the phase. When the calculate price flag is set to yes the search engine applies eligible modifiers in the phase to the request line. When the calculate price flag is set to no the modifiers in the phase are not considered for application to the request line. This enables, for example, the price of a line to be fixed but still allows freight charges to be applied to the line.

Other Qualifying Items

Some types of modifiers allow multiple buy items to be specified as a qualification for the benefit or charge. For example:

Using this example, the search engine determines whether the pricing request contains all qualifying items in the specified quantity or amount before the modifier is applied to the pricing request line for the benefit item (the $400 discount on the dining table). The modifier must always contain a primary item, which can be combined with groups of other items. In the previous example, chair is the primary item combined with two other qualifying items, coffee table and standard lamp. The OR condition is achieved by giving additional buy items different grouping numbers. If the condition were six chairs, a coffee table, and two standard lamps, the grouping numbers would have been the same.

Note: The only pricing attributes that can be used with the additional qualifying items are those in the volume context.

Modifiers that allow the definition of additional qualifying items are:

Resolving Incompatibility and Exclusivity Between Modifiers

Once the search engine locates all modifiers eligible for application to a pricing request line, it must be determined whether the modifiers are exclusive or incompatible.

Additional modifiers may not be applied to a pricing request line if an exclusive modifier is applied to the request line in the same pricing phase. For example, a customer receives a 15 percent discount on an item and is not eligible for any other discount on the item.

An incompatible modifier may not be applied to the same pricing request line as any other incompatible modifier within a pricing phase. For example, a 5 percent discount on a tennis racquet may not be given if the customer is also eligible for “Summer Sports Promotion” that gives a 6 percent discount on all sporting goods.

Incompatibility between discounts is defined between modifiers at the same level in a discount application hierarchy. This following image illustrates this concept. In the image, Level 1 is base level discounts, Level 2 is specially negotiated discounts, and Level 3 is retrospective discounts/accruals.

If the discounts of Levels 1 through 4 in the following image are set for the same product family (and therefore applied to the same pricing request line) a customer entitled to receive all of these discounts only receives one discount from each incompatibility group. For example, the customer could be eligible for a 5 percent discount, a 1 percent special discount, and a $100 off the invoice.

Incompatibility Groups for a Pricing Phase

the picture is described in the document text

If the customer negotiates a 15 percent exclusive discount for the same product family and the search engine determines that this discount can be applied to the pricing request line, then only this discount is applied to the line in the current pricing phase. None of the discounts in Levels 1 through N is considered. This concept is illustrated in the following image.

Incompatibility Groups and Exclusivity rules

the picture is described in the document text

Note: Incompatibility and exclusivity rules only apply to modifiers that are in the same pricing phase and that are eligible to be applied to the same pricing request line.

Price List Lines

Price list lines are always treated as exclusive; all price lists lines are automatically assigned to EXCL: Exclusive Incompatibility Group. When multiple prices are found for the same pricing request line in the ordered UOM or in the pricing UOM the search engine selects the price list line using precedence resolution. If the price list lines are of equal precedence the search engine returns an error for the request line.

The following image depicts price list search/incompatibility processing, part A. It contains diamond boxes, which represent decisions, and rectangular boxes, which represent processes.

Box 1 asks whether the price list is passed by the calling application:

Box 2 asks if matching lines are found. No leads to part B. Yes leads to Box 3: Match pricing attributes and perform grouping. Proceed to Box 4, which asks whether any price list lines are matched in grouping. No leads to part B. Yes leads to Box 5: Match UOMs. Proceed to Box 6, which asks if matching UOM lines exist in the order UOM. Yes leads Box 7. No leads to Box 6a, which asks whether any primary UOM lines exist. No leads to part B. Yes leads to Box 7: Find the line with the highest precedence. Proceed to Box 8. Box 8 asks if more than one line has the same precedence. Yes leads to Box 8a: Use attribute count matching to resolve the same precedence issue. Proceed to Box 8b, which asks if more than one line has the same number of matched attributes. Yes leads to part B; No leads to Box 9. A No result to Box 8 leads to Box 9, which asks whether the order UOM is different than the pricing UOM. No leads to Box 10. Yes leads to Box 9a: Perform UOM conversion. Proceed to Box 9b, which asks if a conversion error occurred. Yes leads to part B. If No, proceed to Box 10: Price list line selected. This ends the process.

Price List Search and Incompatibility Processing

the picture is described in the document text

The following image depicts price list search and incompatibility processing, part B. It contains diamond boxes, which represent decisions, and rectangular boxes, which represent processes.

Box B asks if the search is primary, secondary or full.

If the search is primary, proceed to Box B1: Select matching lines from secondary price lists in order of precedence. Proceed to Box B1a, which asks if any matching lines are found. If Yes, return to part A, Box 3. If No, proceed to Box B1b, which asks if the search flag for the pricing phase is Yes or No. If Yes, return to Box B. If No, Proceed to Box B2a: No price found.

If the search is secondary, proceed to Box B3, which asks whether the price list is validated and enforced. If No, return to part A, Box 1a. If Yes, proceed to Box B2.

If the search is full, proceed to Box B2, which asks if the status code is incompatibility, nor price, or UOM error. No price and UOM error lead to Box 2a. Incompatibility leads to Box B2b: Return error: unable to resolve incompatibility. Boxes B2a and B2b end the process.

Price List search and incompatibility processing

the picture is described in the document text

Modifiers

When multiple modifiers in an incompatibility group are eligible for application to a pricing request line, the search engine must determine which modifier should be applied. The search engine uses two methods to determine this: precedence and best price. Which method the engine chooses depends on the incompatibility resolution method which is set for the pricing phase. If the incompatibility resolution code for the phase is precedence, then the search engine selects the most specific modifier. If this fails (the modifiers have equal precedence), then the search engine uses best price resolution. If the incompatibility resolution method on the phase is best price, the search engine attempts to find the modifier that gives the greatest discount. If this fails, the search engine returns an error for the request line.

The following image shows modifiers search and incompatibility processing. It contains diamond boxes, which represent decisions, and rectangular boxes, which represent processes.

Box 1 asks whether any modifier/header line is passed as certified asked for. Yes leads to Box 1a: Select modifiers for matching products without qualification. No leads to Box 1b: Select modifiers by matching qualifiers, products, and attributes. Both boxes lead to Box 2: Perform price break evaluation. Proceed to Box 3: Perform line group processing. Proceed to Box 4: Perform qualifier group and attributes group matching.

Box 4 leads to Box 5, which asks whether any modifiers of the selected lines are in an exclusive group. Yes leads to Box 6. No leads to Box 5a, which asks if there are any more incompatible groups. If not, then the process is complete. Yes leads to Box 5b which asks if the incompatibility group is null. Yes leads to Box 9. No leads to Box 6.

Box 6 asks whether any of the modifiers in the selected lines are asked for. Each answer leads to a different case. No leads to the first case, which begins with Box 6a-1. This box asks whether any of the selected lines are eligible for more than one incompatible modifiers. No leads to Box 9. Yes leads to Box 6a-2, which asks for the incompatibility resolve at phase. Best price leads to Box 7. Precedence leads to Box 6a-3: Find lines with highest precedence. Proceed to Box 6a-4, which asks if more than one line has the same precedence. Yes leads to Box 7; No leads to Box 9.

A Yes result to Box 6 leads to the second case, which begins with Box 6b-1. This box asks whether the lines are eligible for more than one asked for in the same incompatibility group. No leads to Box 9. Yes leads to Box 6b-2 which asks for the incompatibility resolve code at phase. Best price leads to Box 7. Precedence leads to Box 6b-3. which asks whether more than one line has the same precedence. Yes leads to Box 7; No leads to Box 9.

Box 7: Compare modifiers to find best price leads to Box 8, which asks if more than one modifier has the same best price. No leads to Box 9. Yes leads to Box 8a: Select any modifier. Proceed to Box 9: Modifier selected. Proceed to Box 10, which asks if this modifier is in the exclusive group. No leads back to Box 5a; Yes ends the process.

Modifier search and incompatibility processing

the picture is described in the document text

Precedence and Specificity

The search engine always selects the modifier that is the most specific; the modifier with the lowest precedence number is selected.

For example, all priority customers get a 5 percent discount on Product Family A. Customer Boomerang Emporium, although a priority customer, has negotiated a 10 percent discount on the same product family and is therefore not eligible to receive the 5 percent discount.

Both discounts are defined in the same incompatibility group and phase. The search engine determines that both are eligible to be applied to a Boomerang Emporium order for an item in Product Family A. Because the discounts are incompatible and both can not be applied to the order line, the search engine must determine which discount is more specific. In this case, the Boomerang Emporium negotiated discount is more specific than the general customer class discount. The search engine derives modifier specificity by selecting the lowest precedence number from each of the qualifiers and any product attributes on the modifier. The search engine then applies the modifier with the lowest precedence to the pricing request line. In the example shown, if the precedence of the customer qualifier is 1, the precedence of the customer class qualifier is 2, and product family has a precedence of 3, then the specificity would be calculated as follows:

Type of Discount Qualifier Precedence Pricing Attribute Precedence Overall Precedence/ Specificity
5 percent discount 2 (customer class) 3 2
10 percent Boomerang Emporium discount 1 (customer) 3 1

The search engine selects the 10 percent Boomerang Emporium discount because it has the lowest precedence (the most specific discount). This concept is shown in the following image.

Precedence and incompatibility

the picture is described in the document text

At time of setup, the qualifier or product attribute precedence defaults from the value defined in attribute management. The sequence of the qualifier and product attributes in and across contexts determine which qualifiers have priority when the selection engine is forced to choose between multiple prices, incompatible benefits, or charges that are eligible for application to request line. The sequence number of each segment should be unique across the qualifier descriptive contexts, the item context, and the most specific qualifiers and product attributes having the lower sequence numbers.

Best Price

Best price is an alternative method of precedence for selecting which modifier should be applied to the pricing request line when multiple incompatible modifiers are eligible. Using this method, the modifier that gives the greatest discount to the customer is selected. For more information, see Best Price Resolution for Modiers.

Calculation Engine

The calculation engine takes a pricing request line and its associated pricing request line details to calculate the base price, adjusted price, and/or the extended price.

Fixed Minimum Price (GSA Pricing)

Oracle Advanced Pricing enables you to set a minimum price below which the item price cannot be discounted for all, or a subset of, customers. This setting is commonly used to manage General Service Administration (GSA) contracts, which must ensure that commercial customers do not receive discounts equal to or greater than those fixed for customers on GSA contracts. GSA Violation is checked if the customer is a GSA violation or if the invoice location is GSA. GSA Violation is checked if the customer is a GSA violation or if the invoice location is GSA.

The minimum or GSA price for an item is set on a special GSA minimum price list; a discount list with the minimum price specified as a new (fixed) price type of discount. A GSA discount is created when the regular item price is reduced to the GSA price for a GSA customer, enabling the discount cost to be recognized. The GSA discount list is available only to GSA customers and automatically qualified by GSA = YES when created. Using attribute mapping, all orders for GSA customers are sourced with GSA = YES to ensure that these orders receive the minimum price for the item or items.

If GSA pricing is enabled and the customer is not a GSA customer, then the calculation engine determines whether the selling price for an item violates the minimum allowed price for this item. If the selling price violates the minimum price then the calculation engine returns a status of GSA violation to the request line. The calling application is responsible for error handling such as determining whether to place the order line on hold.

Note: The calculation engine does not consider pricing attributes when comparing the selling price on the request line with the GSA price, therefore the GSA price can only be set for a product attribute.

In a non-GSA environment this functionality can be used to prevent pricing below the allowable minimum price. In this case the GSA price list would list all items and their possible selling price. No customers would be defined as GSA so the calculation engine would verify that the selling price of an item had not fallen below the minimum for all customers.

Calculating Price Breaks

A price break is a series of quantity delimiters to which associated prices or discounts by range of quantity, volume, value, or weight are ordered by the customer. A price break is modeled in Oracle Advanced Pricing as a set of discount, surcharge, or charge modifiers grouped through related modifiers under a price break header modifier. The price break header contains all qualifiers, product attribute, any pricing attributes (apart from those in the volume context), unit of measure, date effectivity, and other attributes that are common elements of the price break. The price break lines contain only the break unit. The break unit must be pricing attributes in the volume context of the pricing attribute descriptive flexfield.

The search engine finds any price breaks eligible for application to the pricing request line. The search engine only considers elements of the price break header, (qualifiers, product and pricing attributes), incompatibility, and whether a price break line exists to match the break unit (quantity, amount, and so on) of the pricing request line.

The calculation engine takes the price break lines and determines a base price or discount value for the modifier. The value depends on the type of price break:

Applying manual adjustments

The pricing engine applies any overridden manual or automatic adjustments passed in by the calling application. For more information, see: Oracle Advanced Pricing Implementation Guide, Integration chapter.

Pricing Engine Flow

During a pricing engine call, the calling application:

As an aid to understanding, the following is a simplified pseudocode flow of the Oracle Advanced Pricing engine call. This flow may vary in future releases.

Invoking Application Integration Code

engine call preparation
populate global record as needed in attributes mapping
call build_Contexts for header and the line (or for every line if it is save or book event)
populate engine PL/SQL record structure
call the engine (QP_PREQ_PUB.Price_Request) within engine call
clear the temporary tables
populate temporary tables from input PL/SQL structure
for every phase of the event loop
if pricelist phase then
select pricelist list line in the pricelist provided by the call
if not found then perform the secondary search
if not found in secondary search perform big search (see Event Phases)
end if
if modifiers phase then
select and insert matching modifiers into temp tables
perform grouping, incompatibility, breaks processing 
end if
end loop
call calculation engine
populate output PL/SQL structure from temp tables
return back to the invoking application

Extendibility Features

Oracle Advanced Pricing contains a number of extendibility features.

Oracle Advanced Pricing APIs

Oracle Advanced Pricing contains several application programming interfaces (APIs). For setup and Oracle Advanced Pricing engine calls, PL/SQL APIs are available. Sample working API calls can be downloaded by ARU and are available from My Oracle Support. These can be studied and modified for specific customer needs. For a complete listing of Oracle Advanced Pricing public APIs, see: Oracle Order Management Open Interfaces, API, & Electronic Messaging Guide.

Related Topics

Optimal Performance