Optimal Performance

This appendix covers the following topics:

Overview of Optimal Performance

This appendix addresses implementation and setup considerations, and provides specific recommendations that improve performance from Oracle Advanced Pricing.

Oracle Advanced Pricing is designed to deliver maximum flexibility when pricing customer transactions. In e-business, transactions may be entered:

These Oracle applications integrate with Advanced Pricing in Oracle Release 11i, and use the pricing engine to price these transactions.

Each time a customer transaction is entered, the pricing engine is called to search through the applicable pricing rules, called qualifiers, to apply to this transaction. Then these rules are used to select the correct set of pricing actions including price lists, formulas, discounts, and promotions required to correctly price the transaction.

Potentially, thousands of available actions may have been set up in the internal tables of Advanced Pricing, so the task of the pricing engine to provide maximum flexibility while delivering fast performance for e-businesses is very challenging.

The pricing engine cycles each time a calling application makes a pricing request to the engine. Calling applications in Release 11i include Oracle iStore, Oracle Order Management, Oracle Contracts, Oracle TeleSales, Oracle Inventory, and Oracle Quoting.

Pricing engine performance is the amount of cycle time that elapses between when the pricing request is submitted to the engine and when the pricing result is returned.

The pricing engine runs through two types of processing activities each time it executes. First, the engine evaluates user-established qualifier rules. Based on these rules, the engine selects qualified pricing actions the calling application may need to apply to the transaction being processed. Second, the calculation engine performs the calculations necessary to compute selling price.

The following image depicts the Oracle Advanced Pricing engine cycle:

Advanced Pricing Engine Cycle

the picture is described in the document text

Analysis of pricing engine performance characteristics reveals that the selection process is subject to more execution time variability, due to the number of records that may be selected. This chapter addresses the issue of optimizing selection engine performance.

Meeting the demanding performance requirements of e-businesses has been a major design goal. To achieve this goal, the Pricing Development team strives to optimize product performance particularly of the pricing engine.

Choices you make when selecting settings or setting up your pricing data can substantially improve the performance of the Advanced Pricing Engine. For this purpose, the implementation recommendations and considerations in the Oracle Advanced Pricing Implementation Guide are designed to assist you in optimizing the performance you receive from Oracle Advanced Pricing.

Oracle Advanced Pricing Setup Considerations

Analyzing your pricing data setups is the best way to improve Oracle Advanced Pricing engine performance. Removing any unnecessary qualifiers and inactivating any unnecessary, price lists, and modifiers can substantially improve pricing engine performance.

There are distributions of data in the pricing data setup, however, that can slow the pricing engine execution. The first of these is qualifier selectivity.

Qualifier Selectivity

As the pricing engine finds qualifiers that apply to a transaction, it selects all active price lists or modifier actions that the qualifier pertains to. When qualifiers identify a narrow range of pricing actions, the majority of which should be applied to the transaction, then that qualifier has high selectivity. When a single qualifier is linked to many pricing actions, the majority of which cannot be simultaneously applied to a transaction, then that qualifier is said to have low selectivity.

The new search optimizer contains the latest performance capabilities. Search optimizer introduces the ability of the pricing engine to tag the most selective qualifier within a group of qualifiers attached to the same modifier. For example, a 2% discount modifier has two qualifiers: Price list = Corporate and Customer = XYZ. Price List = Corporate is a non-selective qualifier (it is attached to many modifiers). Customer = XYZ is a selective qualifier (occurrence is low). The pricing engine first matches the most selective qualifier within the qualifier group and then matches the less selective qualifiers for the selected modifier. Search Optimizer uses the qualifier number of occurrences as criteria to tag selectivity. The pricing engine distinguishes selectivity of the qualifiers Price List = Common Price List and Price List = Customer Specific Price List.

If a modifier has qualifier as well as the product attached to it, then the pricing engine is qualifier driven rather than product driven. For example, 2% discount modifier has a qualifier attached: Price list = Corporate. It also has a product attached: Item=ABC. The pricing engine matches the qualifier first and then matches the product. At least one qualifier should be selective within the qualifier group.

Low Qualifier Selectivity Impact

Low selectivity has an adverse impact on pricing engine performance. The effect of low selectivity depends on the distribution of pricing data. The larger the data volume when qualifier selectivity is low, the greater the negative impact on performance.

Qualifier Selectivity Examples

High Qualifier Selectivity

To illustrate the effects of selectivity, use the following business example consider how different pricing setups with high and low qualifier selectivity can be structured. Pricing engine performance implications are examined.

Qualifier Group has four qualifiers namely customer name, order type, price list, region. Customer Name is occurring five times. Therefore, it is tagged as most selective qualifier in the group. Although the other qualifiers are not highly selective, pricing engine will perform better because most selective qualifier is searched first. The following illustrates the setup with high qualifier selectivity:

Qualifier Group Qualifier Qualifier Count Selectivity (Search Indicator) Exclusivity Group Precedence
1 Customer Name = 'ABC' 5 1 1 100
1 Order Type= Standard 300 2 1 100
1 Price List = Corporate 200 2 1 100
1 Region=Western 50 2 1 200

Low Selectivity Due to Historical Records

A company has low setup selectivity because of a large number of modifier and price list records with effectivity dates in the past. This company has been in business for several years. It has several price lists and discount records in its system, many of which are outside their effectivity dates but still in the system for historical purposes. Using the same base as in the previous example, the setup data for this example could be as follows:

Qualifier (Customer Class) Qualifier Effective Dates Price List Effective Dates Modifier Exclusivity Group Precedence
Wholesale 2/15/1991 - present First Quarter Wholesale 2/15/2001- 3/31/2001 5% discount 1 100
Wholesale 2/15/1991 - present First Quarter Wholesale 2/15/2000 - 3/31/2000 4% discount 1 100
Wholesale 2/15/1991 - present First Quarter Wholesale 2/15/1999 - 3/31/1999 6% discount 1 100
Wholesale 2/15/1991 - present First Quarter Wholesale 2/15/1998- 3/31/1998 5% discount 1 100
Wholesale 2/15/1991 - present First Quarter Wholesale 2/15/1997 - 3/31/1997 4% discount 1 100
Wholesale 2/15/1991 - present First Quarter Wholesale 2/15/1996 - 3/31/1996 6% discount 1 100
Wholesale 2/15/1991 - present First Quarter Wholesale 2/15/1995- 3/31/1995 5% discount 1 100
Wholesale 2/15/1991 - present First Quarter Wholesale 2/15/1994 - 3/31/1994 4% discount 1 100
Wholesale 2/15/1991 - present First Quarter Wholesale 2/15/1993 - 3/31/1993 6% discount 1 100
Wholesale 2/15/1991 - present First Quarter Wholesale 2/15/1992 - 3/31/1992 4% discount 1 100
Wholesale 2/15/1991 - present First Quarter Wholesale 2/15/1991 - 3/31/1991 5% discount 1 100

Assume that the other classes, Retail and Other, have similar data. Now examine customer All, where management has experimented with many different discount structures over time.

Qualifier (Customer Class) Qualifier Effective Dates Price List Effective Dates Modifier Exclusivity Group Precedence
All 1/01/1991 - present Corporate 1/01/2001 - 12/31/2001 2% discount 1 200
All 1/01/1991 - present Corporate 1/01/2000 - 12/31/2000 1.9% discount 1 200
All 1/01/1991 - present Corporate 1/01/1999 - 12/31/1999 1.8% discount 1 200
All 1/01/1991 - present Corporate 1/01/1998 - 12/31/1998 1.7% discount 1 200
All 1/01/1991 - present Corporate 1/01/1997 - 12/31/1997 1.6% discount 1 200
All 1/01/1991 - present Corporate 1/01/1996 - 12/31/1996 1.5% discount 1 200
All 1/01/1991 - present Corporate 1/01/1995 - 12/31/1995 1.4% discount 1 200
All 1/01/1991 - present Corporate 1/01/1994 - 12/31/1994 1.3% discount 1 200
All 1/01/1991 - present Corporate 1/01/1993 - 12/31/1993 1.2% discount 1 200
All 1/01/1991 - present Corporate 1/01/1992 - 12/31/1992 1.1% discount 1 200
All 1/01/1991 - present Corporate 1/01/1991 - 12/31/1991 1% discount 1 200

In the previous example, the qualifier selectivity is very low, negatively impacting pricing engine performance. When the pricing engine executes against this data, it will find that all the historical records (those with effectivity dates that are already past) will be preliminarily qualified and selected by the Pricing Engine for further processing, even though only one price list and modifier will be finally selected to apply to the transaction. Specifically, for the historical records, the pricing engine will be forced to compare the exterior pricing date passed to it from the calling application to the effectivity date range of each record to determine if whether the selection process should proceed to the next step of considering the precedence. Since the effectivity date evaluation is a record-by-record process, large number of historical records will have an adverse impact on Pricing engine performance.

Correcting Low Qualifier Selectivity Due to Historical Records

Pricing engine performance can be improved by properly handling historical records. While the most direct route to improving engine performance is to eliminate historical records from the system, many companies must retain historical records.

Oracle Advanced Pricing provides a flag on both price list and modifier records that informs the engine whether the record is active. Because the pricing engine determines record status during the qualifier scan process, records set to inactive are automatically excluded from further consideration.

Low Qualifier Selectivity Due to Release 10.7/11 Pricing

Oracle Advanced Pricing provides more flexibility in setting up your pricing data than Release 10.7 or Release 11.

In Release 10.7 and in Release 11.0, discounts had to be associated to a price list because a price list was a mandatory qualifier for a discount. Users had to create different discounts because only one discount could be linked to one price list. In turn, price lists could be linked to either the customer, the Order Entry order type, or manually overridden on the order.

Therefore, in releases 10.7 and 11.0, many customers could potentially have large numbers of discount records, even when the number of different discrete discounts used was low.

Correcting Low Qualifier Selectivity due to Release 10.7/11 Upgrade

Reducing the number of discount records and making the qualifiers specific will help you optimize 11i pricing engine performance. Consider merging these discount records into as few 11i modifier records as possible, and then use 11i Pricing to tie them to customer groups.

If you examine your qualifiers and your business pricing requirement, you may find that you can qualify pricing by using either price lists or modifiers at the higher level of the product hierarchy. For example, suppose you are selling greeting cards and have only 15 distinct prices but 100,000 items. By grouping the items into item categories and using item category as the qualifier, you only have to create 15 price list lines rather than 100,000 lines. This grouping results in the pricing engine searching through price list lines, which substantially improves pricing engine performance. If your business needs do not require a price list to act as a qualifier to a discount, you should delete any records that have been created as part of your upgrade process.

Low Selectivity When Qualifiers are Used as Constraints

If, for example, you have modifier lists, out of which 200 lists have Price List = Corporate as the only qualifier, this results in low selectivity of the qualifier because the pricing engine must process every list that satisfies this qualifier.

Correcting Low Selectivity When Qualifiers are Used as Constraints

If your business requires non-selective qualifiers as the only qualifiers, consider combining lists so that there are fewer lists for the engine to scan.

Redundant Qualifiers

Pricing engine performance can be boosted by avoiding redundant qualifiers. Here is an example of a redundant qualifier:

Customer = XYZ AND Customer Site = ABC

Because it is more specific than Customer, Customer Site is sufficient for selection of the appropriate price list or modifiers. Adding the customer qualifier causes the unnecessary evaluation of the customer condition. By eliminating such redundant qualifiers, pricing engine performance is optimized.

Blind Modifiers

Modifiers without any qualifier or any product attached are blind modifiers. These modifiers are processed by the engine for every request line. Engine performance is negatively affected as more blind modifiers are defined in the system.

Use of ALL_ITEMS as a Product

Modifiers defined for ALL_ITEMS are processed by the engine for every request line. Engine performance is negatively affected as more ALL_ITEMS are defined in the system.

Use of Exclusions and the NOT= Operator

The pricing engine needs additional processing time to evaluate NOT = Operator in qualifiers, as well as EXCLUDE in the product hierarchy. If you have a high volume of setup data, use caution when implementing these operators.

Pattern Search

Flexibility of pricing setup with attribute management provides you with ample opportunity to fit your business needs. As a result of this flexibility, the pricing engine needs to look for all combinations and permutations to get the appropriate price lists and modifier lines eligible for the incoming line. Since all the attributes (pricing, product and qualifier) for price lists and modifier lines are optional, it is challenging to decide the best search selectivity path to suit customer setup.

The Pattern Search feature solves the indefinite search path to a fixed best possible search path. You can enable the search engine part of the pricing engine to use pattern search to see improved performance. Pattern search ensures better pricing performance in all pricing related flows such as, order entry, save, quote entry, save, reprice, opening configurator, and adding top model item.

To make all pricing calls to use the pattern search engine, you must set up the following:

  1. Set an applicable value for the QP: Pattern Search and QP: Pattern Search Path profile options. See Profile Options Setup Summary in Oracle Advanced Pricing Implementation Guide.

  2. As a one-time action, run the QP: Pattern Upgrade concurrent program with empty criteria to upgrade the existing pricing setup to patterns. See Reports and Concurrent Programs in the Oracle Advanced Pricing User Guide.

For further information, see 'Pattern Based Searching Logic in Pricing Engine For Performance Improvement', My Oracle Support Note 948900.1.

Ignore Pricing

You can inform the pricing engine to ignore lines that have no significance from pricing perspective using the QP: Custom Ignore Pricing profile option and implementing the QP_CUSTOM_IGNORE.IGNORE_ITEMLINE_FOR_PRICING custom hook API. See Profile Options Setup Summary and ‘Ignore Pricing for Order Lines – Custom Hook’ white paper available in My Oracle Support Note 113492.1.

Additional Tips for Better Performance

Here are additional tips to improve processing:

  1. Always pass the price list that needs to be used for pricing, unless your business demands otherwise.

  2. Try to avoid multiple price list lines from triggering incompatibility processing which eliminates ineligible list lines - this prevents unnecessary post selection processing.

  3. Avoid using the same attribute for both the header and line level qualifiers. For example, if Customer = Joe's Diner is a Header level qualifier, it is not necessary to define it again as a line level qualifier.

Analyzing your Data Distributions Using a Script

Oracle Advanced Pricing provides a script to analyze data distribution. The script is delivered as part of the product at $QP_TOP/patch/115/sql/qpperf.sql. If you encounter performance problems, then run this script at the SQL*Plus prompt using APPS login. If a customer performance bug has been logged, then the script results should be provided to the pricing team for their review. The script also provides hints that may assist you identify performance issues.

Alternately, you can run this script as a concurrent program and view the output in the concurrent request output file. Using the Oracle Pricing Manager responsibility, navigate to Reports, and submit a request for the concurrent program Diagnostics: Performance Analysis.

Note: Scripts may change, so it is important to verify with Oracle Support that you have latest version of the script.

Technical Improvements

When you implement Oracle Advanced Pricing, several technical measures can be taken to ensure the best response time from the pricing engine. These measures are related to implementation-time activities.

Attribute Mapping

Oracle Advanced Pricing enables you to perform attribute mapping. Use caution when writing your own attribute sourcing. The code you write is executed for every pricing engine call. If the code is not tightly written, this can negatively impact pricing engine performance.

Pricing provides you with an option to source all the setup attributes or source attributes of only active price list, modifiers. Performance will be improved if the profile QP: Build Attributes Mapping Options is set to active only.

Phases and Events

Oracle Advanced Pricing enables pricing engine execution to be divided into phases with each phase associated with an event in the calling application.

You do no need to fetch or view the discounts when you enter the order lines - you can modify the event phases records to run the discounting phases when you save the order lines. This approach causes the engine to perform the price list line selections as each line is entered, while preventing the engine from doing the selection or calculation of modifiers until the save event causes the modifier selection to cycle. For users who must not view the discounts line by line as the order is entered, this technique can enhance pricing engine performance.

If you have unused pricing event phases, set the end date to a past date. This prevents pricing engine from attempting to select when the event that triggers the pricing phase occurs.

Temporary Tablespace

Oracle Advanced Pricing uses the temporary tablespace feature of the Oracle database extensively. Proper sizing of temporary tables is important to obtaining optimal performance. Depending on the size of the transaction to be priced, the initial extent for temporary tables should be sized at between 64K and 256K. The temporary tablespace should be defined as locally managed.

Memory Considerations

Because the pricing engine is frequently called during the order entry process, pricing packages must always be loaded into memory. Keep the following Pricing packages in memory:

Warning: Ensure that your shared pool size is calculated based on system use!

Performance in the Pricing Setup window

The following performance-related improvements in the setup window have been made:

Performance in applying Pricing Denormalization Patches

If you have a high volume of price list and modifier data, it may take from 5 minutes to an hour to apply pricing patches. A denormalization script is provided for the existing data. The denormalized columns are important for the pricing engine to select the list price or modifiers, and large denormalization patches have been provided with parallel threading to improve the performance.

Pricing Engine Redo Log

Users have experienced significant increase in the redo log while pricing the transactions. In the latest release, this redo is minimized by avoiding the delete operation on the temporary tables. Please check with support to ensure that you have the redo reduction patch applied.

Performance of Asked for Promotions

Users have experienced significant performance whenever asked for promotions were defined in the system. In the latest release, these issues are resolved by pre-matching the asked for Promotions. Please check with support to ensure that you have applied the latest performance patches.

Summary of Recommendations

The pricing engine is a resource intensive process that uses Oracle 8i temporary tables. The performance of pricing engine statements is significantly affected by inaccurate CBO settings, memory settings, or any other significant high-load process. Many of the pricing performance bugs were resolved by tuning the database parameters or correcting other high-load statements. Following table lists common causes of performance issue:

Symptom Probable Cause How to fix it
1) Performance is slow and OM debug file is getting created in the debug directory OM debug or QP debug is causing very high pl/sql processing Make sure that Profile ONT_DEBUG_LEVEL is set to 0 and profile QP:QP_DEBUG is set to No.
2) Trace File is showing a big difference between CPU and Elapsed time Pricing Engine Temporary tables are being thrown out of memory. 1) Some other non-pricing statement may be taking a huge amount of Logical Reads (These high-load statements would deteriorate Pricing engine performance). Execute the following statement to find high-load sql. Select sql_text, buffer_gets from v$sql where buffer_gets in (select max (buffer_gets) from v$sql);
2) Change db_block_buffers to a higher number.3--There may be CPU contention. Make sure that there are no runaway processes. Check your hardware resources.
3) Significant amount of time is spent during Pricing Pricing Performance patches may not have been applied Contact your support analyst to obtain any know performance fixes applicable to the specific release.
3a) Huge amount of redo is seen while pricing the transaction Delete operations on Pricing temporary tables are generating redo Redo is reduced by eliminating deletes. Please contact support to get the appropriate patch.
4) Trace File is showing Misses in library cache during parse Not enough Shared Pool Increase the value of Shared Pool parameter in the frequently used Pricing Engine packages.
5) Trace file shows huge volume in the pricing temporary table qp_preq_qual_tmp Qualifiers may be unselected which causes large number of records being selected by the engine Run qpperf.sql to see if any unselected qualifiers exist. Restructure the setup either by moving these qualifiers to Pricing attribute or by moving the qualifier from the line to the header. Use qpperf.sql Stmt # 10,16.
6) Trace File is showing obj$ and other sys statements SYS/SYSTEM schema is analyzed. Do not analyze SYS/SYSTEM schema.
7) CBO is causing full table scans CBO parameters in Init.ora may not be set properly. Use/fnddev/fnd/11.5/admin/sql/AFCHKCBO.sql to check this).
8) Excessive calls made to the pricing engine at booking and scheduling Pricing may be turned on at scheduling. OM profile "OM: Deactivate Pricing at Scheduling" should be set to yes.
9) Form stops responding ST patches for temporary table may not have been applied. Check My Oracle Support Note 119542.1.
10) Unnecessary Pricing call is made at Booking Pricing Event Phase is active for Book Event Use Pricing Manager responsibility, invoke Event-Phase screen, Query Book event, set the end date to some prior date.
11) Unnecessary Modifiers are being fetched with every line Automatic or Manual Modifiers are created without any qualification. Analyze the price adjustments data to check if certain modifiers are selected for every line and are unnecessary. Inactivate these modifiers. Use qpperf.sql Stmt # 17, 27
12) Sales Order processing slow at Booking OM performance patches may not have been applied Check My Oracle Support for recommended performance patches.
13) Many obsolete modifier headers are being queried by Pricing Engine Upgraded obsolete Pricing data is still active. Inactivate the obsolete List headers by clearing the active flag. Use qpperf.sql Stmt# 5.
14) Trace file is showing custom code being executed many times as well as taking a huge amount of time. Inefficient Extension /custom code is being called by Attributes mapping or by get custom price. Caching is not implemented in the custom code Implement caching and tune the custom code. If you are not able to implement caching for order attributes at the line level, which changes for every call, then please look at the Order Amount sourcing as an example of caching such attributes.
15) Pricing debug screen is showing unnecessary qualifiers/ attributes being passed to the pricing engine. Somebody has setup prototype modifies using the qualifiers and attributes which are not used by the production application Pricing engine will get all the qualifiers, pricing attributes even if those are setup for prototype purpose. If you have setup such modifiers then inactivate these modifiers in the production instance. Then change the value of the profile QP_BUILD_ATTRIBUTES_MAPPING_OPTIONS to Y and run the Build Context concurrent program.
16) Many modifiers and price list lines coming into the pricing engine. 1) Multiple "Not=" qualifiers without any selective qualifier in the qualifier group.
2) Excessive use of "ALL_ITEMS" product element.		 Too many lines of the same product element or same qualifier will reduce the selectivity of the engine. Evaluate alternate setup.
If you have many "Not = " qualifiers without having any other selective qualifier in the group then performance will be affected. You can change your sourcing rule to convert the "Not = " qualifier to Equal to.
For example instead of saying Customer Not= cust1 or Customer = cust2, you can evaluate the condition in Attributes mapping if customer not in (cust1, cust2) then cust_code = 1 by using cust_code as a qualifier.
17) Temporary Table space growing significantly. Causing huge overheads. Initial extent of the Temp table space may be high. Pricing engine temp tables are created with big initial extents. Change the storage clause of Temporary table space with a minimal setting of initial extent. Change the temporary table space to be locally managed.
18) Performance is slow when profile is enabled to save requests in Pricing Engine Request Viewer. Huge quantities of data are being written into the request viewer tables. Change the profile QP_Debug to Not store debug Log into request viewer tables. Also, purge data from Request viewer tables by using the Purge Concurrent program.

Pricing Setup Window

The following performance-related improvements were made:

Global Engine Flag for Caching Attribute Mapping

On repricing, pricing engine is called once for each order. For multiple lines order, the build_sourcing is executed for every line to source all the attributes such as order amount and customer information. These attributes are therefore repeatedly sourced multiple times.

A pricing engine global flag, G_NEW_PRICING_FLAG is introduced to indicate that the attributes has been sourced for the first line so that sourcing is not required for all the following line(s). The flag has an initial value of 'Y' and build sourcing is only executed when this value is 'Y'. At the end of initial build sourcing call, this value is set to 'N' so that subsequent build sourcing is not necessary. The flag is reset back to 'N' at the end of the pricing engine call. This implementation helps to avoid unnecessary processing and hence improve the performance.

Customers who have any customized attributes can use the flag in a similar way to improve the pricing engine response time. This flag is set internally as described above. Developer can use the value of this flag to decide if re-sourcing is necessary.

Flag: QP_PREQ_GRP.G_NEW_PRICNG_CALL

Value: 'Y' or 'N'

Example of caching the order amount

PROCEDURE Get_Order_AMT_and_QTY (p_header_id IN NUMBER) IS
     orders_total_amt      NUMBER; 
     orders_total_qty      NUMBER; 
     returns_total_amt    NUMBER; 
     returns_total_qty    NUMBER; 
BEGIN

     SELECT SUM(nvl(pricing_quantity,0)*(unit_list_price)), 
          SUM(nvl(pricing_quantity,0)) 
          INTO  orders_total_amt, orders_total_qty 
     FROM oe_order_lines 
     WHERE header_id = p_header_id 
          AND (cancelled_flag = 'N' OR cancelled_flag IS NULL) 
          AND (line_category_code <>'RETURN' OR line_category_code IS NULL) 
               GROUP BY header_id;
     G_Order_Info.header_id := p_header_id;
     G_Order_Info.order_amount := FND_NUMBER.NUMBER_TO_CANONICAL(NVL(orders_total_amt,0)-NVL(returns_total_amt,0)); 
     G_Order_Info.order_quantity := FND_NUMBER.NUMBER_TO_CANONICAL(NVL(orders_total_qty,0)-NVL(returns_total_qty,0)); 
EXCEPTION
     WHEN no_data_found THEN 
          OE_DEBUG_PUB.ADD('NO Data Found'); 
END; 

FUNCTION Get_Order_Amount(p_header_id IN NUMBER) RETURN VARCHAR2 IS 

BEGIN
     IF qp_preq_grp.g_new_pricing_call = qp_preq_grp.g_no THEN 
          RETURN G_Order_Info.order_amount; 
     ELSE
          Get_Order_AMT_and_QTY(p_header_id); 
          RETURN G_Order_Info.order_amount;
     END IF; 
END Get_Order_Amount;

Custom Applications Integrating with Oracle Applications

All the custom applications integrating with Oracle Applications need to integrate with the QP_PREQ_PUB.PRICE_REQUEST API instead of QP_PREQ_GRP.PRICE_REQUEST for the latest features and improved performance. For more information, see: Integrating with Oracle Advanced Pricing.

Performance Patches

Patches help improve the performance of the pricing engine. You should check with support for information on new and updated patches.