Improving Performance in Order Management

An Oracle White Paper

July, 2009

Performance in Order Management

EXECUTIVE OVERVIEW

This document provides a broad discussion of how to use Oracle 11i Order Management for a robust
order management solution in high volume industries. To accomplish this goal, the document lists a
number of functional areas that may be tuned for optimal scalability. Order Management has an
extensible configurable architecture, which allows you to tailor your flows in a way that makes sense for
your industry and your business requirements. Of course, how you use and configure your system
impacts performance. This document identifies opportunities for setting up your system to scale for
higher volumes.
High volumes may occur in any industry, but are particularly common for Consumer Goods, Wholesale
Distribution, and Telco. Manufacturing companies may also have high volumes, particularly if they are
using models. In general, high volume businesses process 50,000 to well over a million lines a day.
However, you may want to follow some of the suggestions in this document even if you are processing
30,000 lines a day.
Performance varies depending on what features you use, and how you perform key functions such as
scheduling, pricing, tax calculation, credit checking, etc. This document provides tips for each of these
functional areas.
Performance is also dependent on system configuration. It is not possible to make absolute hardware
recommendations, because hardware requirements vary based on the features used and the volume of
processing. Hardware requirements may also vary depending on the time window allowed for processing.
For instance, more powerful hardware is required to process 100,000 lines in one hour than in three
hours. The best hardware is the fastest hardware, with substantial available memory.
Although it is not possible to predict throughput for a given hardware configuration, it is possible to
identify throughput observed with a specific hardware configuration. Please refer to Appendix A of this
document for information about throughput observed using a specific set of features with 11i10.

Introduction

Order Management supports the on-line manual entry of orders. High volume users who enter many
orders online should use the Quick Sales Order form, as it can be tailored to reduce the keystrokes
required to enter orders.
Order Management also provides two types of Order Import, standard and High Volume Order
Processing (HVOP), a bulk-enabled version of order import introduced with 11i9. Standard Order
Import processes and inserts records one at a time into the database. Bulk-enabled HVOP can process

and insert multiple records at once, so it is called bulk-enabled.

Standard order import is full-featured. HVOP supports a more limited feature set. We sometimes use
the analogy of an SUV and a sports car, comparing standard order import to the SUV and HVOP order
import to the sports car. To take the entire family on an outing, you want all the features provided by an
SUV. On the other hand, if all you need is to get somewhere really fast, you can do without accessories
such as luggage racks and spare tires. Similarly, you can use standard order import to support all features
of Order Management. For greater speed but with some feature limitations, you can use HVOP.
Most of the tips in this white paper pertain to importing orders more quickly. This is appropriate, as
most high volume users import a significant percentage of their orders. However, there is also a section
pertaining to online order entry, UI Performance.
This document is organized by feature. It identifies each feature affecting performance, and explains
the impact. It also states whether the recommended tips affect only HVOP order import, both types of
order import, the process order API, and / or online processing.

BACKGROUND

Oracle Order Management has always supported full-featured order import. Some high-volume users
asked for a streamlined, more performant version of order import in exchange for a somewhat reduced
feature set. This was provided in 11i9.

11i9
In 11i9, Order Management provided High Volume Order Processing (HVOP) as an alternative way to
import new orders in other words, the creation of orders. This method of order import achieves
performance gains by:

Using the bulk processing features of RDBMS

Processing order in batch, rather than order by order
Providing a streamlined, more limited feature set
Reducing the number of SQLs (Minimum DMLs) and managing data in memory. (DML is for Data
Manipulation / Modification Language, which includes statements that change the data, i.e. UPDATE,
INSERT, and DELETE.
Distributing data equally across threads based on number of lines per order
HVOP order processing can be an option for those who need to process large volumes of order lines in a
limited amount of time, perhaps with minimal hardware. If you have to process 30,000 lines in an hour,
you may be a candidate for HVOP. On the other hand, a different processing environment might be
capable of processing 100,000 lines per hour without using HVOP.
With HVOP 11i9, some features are supported but not optimized, e.g. workflow, credit checking,
shipping integration and pricing integration.
11i10
In 11i10, the following areas were enhanced to better meet the needs of high volume users.
Pricing

With 11i10, pricing is bulk-enabled for HVOP order import. This is achieved by:
Leveraging the JAVA pricing engine, which is available to early adopters via the Approved Strategic
Implementation Program.

 Pricing lines in memory cache, before posting to the database

Pricing attribute mapping in memory cache across orders

Using one call to price all orders being imported
Many pricing features used in high-volume business flows are supported. Refer to the Pricing section
below for more details.
Shipping

Additionally, 11i10 provides performance improvements for lines interfaced with shipping, for either of
the following conditions.
Lines imported in Booked status with High Volume Order Processing (HVOP) order import are
interfaced to shipping in batch, rather than line by line. The improvement is for lines interfaced from
Order Management to Oracle Shipping Execution.
Lines interfaced from shipping back to Order Management are also bulk-enabled, if full quantity is
shipped. Note that this second performance improvement is not restricted to orders imported with
HVOP.

Process Manufacturing

For 11i10, Process Manufacturing added HVOP order import support for process items.

R12.1.1
With 12.1.1, High Volume Order Import (HVOP) has been enhanced to provide Configuration and Tax
calculation support at entry/booking.

The High Volume Order Processing (HVOP) concurrent program now uses the Oracle Workflow
product bulk apis for bulk creation of workflow processes so as to give better performance.
Ignore Item for Pricing Custom hook solution also comes with 12.1.1 from Pricing.. This helps
customers having large orders where some of them are zero priced lines. The details are found in the
section named Zero Priced Lines.
For the list of recent performance fixes please refer to Metalink Note: 849060.1

HVOP ORDER IMPORT

If you are a high-volume user, you are probably importing the majority of your order lines. You need to
evaluate whether you can use HVOP order import. How do you know whether to use standard or
HVOP order import? There are many factors to consider: line volumes, the time window available to
import a specific number of lines, the system configuration, and required features. To help with your selfanalysis, Oracle Order Management provides a questionnaire to help you assess if your business is a good
candidate for HVOP order import. This document, 225753.1, is available on Metalink.

http://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=225753.1
Keep in mind that deciding whether to use HVOP is not an either / or decision. You can use both. You
can use HVOP to import those lines that are eligible for HVOP, and use standard order import to bring
in those lines using features not supported by HVOP. For example, if 20% of your lines require drop
ship, consider importing 80% of your lines using HVOP, and the remaining 20% of your lines using

standard order import.

HVOP order import actions are limited. These are supported: order creation, manual pricing
adjustments, and booking. These are not supported: manual sales credits, updates and deletes. Shippable
and non-shippable flows are supported, but drop ship and return flows are not. Standard items and kits
are supported, but ATO / PTO models, ATO items, and service items are not.
With HVOP, workflow scheduling is supported but not optimized. Workflow scheduling supports ATP
and the reservation time fence. The autoscheduling profile option is supported. HVOP autoscheduling
supports ATP calculations but does not support the reservation time fence. If desired, you can use
Autoscheduling to schedule the lines, and then the Reserve Orders concurrent program, released in
11.5.8, to reserve lines for the reservation time fence.
Using HVOP, tax can be calculated at invoicing. However, HVOP does not support tax calculation at
entry or booking. Orders paid with credit cards cannot be imported with HVOP.
In Releases 11.5.10 (comes with one-off patch 5620899 or any cummulative patch after Jan 2007) and
12.1.1 HVOP has been enhanced to support Tax calculation at entry or booking.
Other HVOP supported features include holds processing, item cross-referencing, acknowledgements,
and credit checking. (Credit-checking is supported but not optimized.)
HVOP does not support the full defaulting framework. However, it does support a more simplified
defaulting architecture, which is described in the subsequent section on defaulting.
Appendix B contains a complete list of supported and unsupported HVOP features.
KEY FUNCTIONAL AREAS IMPACTING PERFORMANCE
Shipping
With HVOP 11i10, if you import lines with HVOP order import in Booked status, the lines are bulkenabled as they are interfaced with shipping. This means the bulk-enabling feature, which optimizes
performance, is used to push Booked lines all the way through to shipping more quickly.
ITS

When you Ship Confirm or run the Interface Trip Stop concurrent program in 11i10, the interface of lines
from shipping back to Order Management is optimized when full quantity is shipped. This means that
performance is better if you can avoid partially shipped lines. When you ship full quantity, the system
does not incur the cost of splitting lines. This performance benefit applies to the ship confirm process,
and also to the concurrent program for Interface Trip Stop.
Additionally, you can improve ITS performance by grouping deliveries with fewer trips.
Deferring the call to Inventory Process Online API

What else can you do to improve the performance of ITS? When setting up ITS (Interface Trip Stop),
you have the option to defer the Inventory Process Online API which occurs during Inventory Interface.
Shipping first calls the Order Management Interface, and then the Inventory Interface. These calls are
serial, i.e. OM Interface completes before Inventory Interface begins.
At the time of this writing, there is no indication that performance is improved by deferring the call to
Inventory Process Online API at the time of Inventory Interface. If there is a change, this document will
be updated. You may want to defer Inventory Process Online API for the purpose of load balancing, but
this deferrment will not take the lines to Invoice Interface in less time.
Preventing Calls to Advanced Pricing at Ship Confirm

If you are not calculating freight charges at ship confirm, you can turn off pricing events triggered by Ship
Confirm. To do this, navigate to the Pricing -> Setup -> Event Phases form. Query up all of the

sequences. If there is an active Event called Enter Shipment, disable it by giving it an End Date. This
will prevent the system from calculating freight charges at Ship Confirm.
Note: you can only access the Event Phases form if you have fully licensed Advanced Pricing.
Also, if you have not licensed Oracle Transportation Execution, check to make sure Oracle
Transportation Execution is not installed accidentally. If installed, Oracle Shipping will call Oracle
Transportation Execution to rate the trip, and this in turn will call Advanced Pricing at the time to
calculate rates. You can check whether Oracle Transportation Execution is installed via a PL/SQL
function:
fnd_installation.get(716,716,l_fte_install_status,l_industry)

If l_fte_install_status equals to 'I', then it means that Oracle Transportation is installed on that instance.
If Oracle Transportation Execution is installed, the flag for AutoCalculate Freight Rate at Ship Confirm is
always checked. The flag for autocalculate freight at Ship Confirm can be found on the Shipping
Parameters form under the Transportation tab. If Oracle Transportion Execution is installed, then the
flag is checked and Advanced Pricing will be called at Ship Confirm.
PRICING
With release 11i10, pricing is bulk-enabled for HVOP. These features are supported:

Discounts
Surcharges
Freight and special charges
Static or dynamic formulas
GSA pricing
Unsupported features are: promotional goods, term substitution, limits processing, item upgrade, coupon
issue, catchweights pricing. Attribute sourcing is limited because orders are priced before posting to the
database.
Note that there are three levels of pricing performance possible with HVOP 11i10 pricing:
O Optimal

Optimal

Use Java Pricing Engine*

Use supported pricing features

Improved from
11i9

Use Java Pricing Engine*

Same as 11i9

Do not use Java Pricing

Engine*

Use all pricing features

Use all pricing features

*Available to those in the Approved Strategic Implementers Program

Repricing at Booking

Regardless of whether you use standard or HVOP order import, there are other pricing considerations.
For example, do you require repricing at booking? If not, turn it off. Oracle Advanced Pricing supports

modifiers that apply only at the time of booking. If you are using this functionality, you should not
prevent repricing at booking. But many users set up pricing to occur at the time the lines and orders are
created. If this is when your pricing occurs, you can turn off repricing at booking.
To turn off repricing at booking, use the Pricing Manager responsibility. Go to the Event-Phase window,
and query all phases. For any event that has a BOOK event, set the Start Date and End Date to some
prior date on the Event line. This disables the Book event for pricing.
To identify whether the Booking process is executing repricing, run the following SQL statement:
SELECT count(*)
FROM QP_EVENT_PHASES
WHERE pricing_event_code = 'BOOK'
AND trunc(sysdate) between trunc(nvl(start_date_active, sysdate)) and
trunc(nvl(end_date_active, sysdate)) and
rownum=1;
If the SQL query returns a value greater than zero, it confirms that you have setup modifiers for the
BOOK event.
If you turn off repricing at booking, it will improve the performance of both standard and HVOP order
import. It also improves the performance of online booking, or Process Order API calls with the action
request to Book the order.
Pricing Setup Tips
When you are pricing online, heres what happens:

When you type in Item, Quantity, and tab out, the PRICE event fires.
When you navigate out of a line, the LINE event fires.
When you save the order, the ORDER event fires.
When you book the order, the BOOK event fires.
If you want to add your own phases, or change the above mapping of events to phases, do not attach the
same phase to different events. For example, if you add a phase to both the LINE and ORDER event, all
the modifiers in this phase will be evaluated twice, once when you navigate out of a line and again when
you save the order. This degrades performance unnecessarily.
If you are looking to reduce time navigating between lines, minimize your modifiers in phases attached to
the LINE event. For example, you could change your modifier from List Line Adjustment Phase to All
Lines Adjustment Phase.
If you constantly change your modifier setup, define your modifiers for easy de-activation.
Note: If 10 modifiers are in a single modifier list, and if 5 of those modifiers are end-dated, the pricing
engine will only evaluate the 5 modifiers that are not end-dated. But if you define the same number of
modifiers into two lists of 5 modifiers each, you can de-activate one of the pricing lists. Then the pricing
engine will evaluate only active price of 5 modifiers.
One benefit of deactivating, as opposed to end dating, is that end-dated modifiers can be applied if you
price quotes or orders with past dates. If you are sure you never use specific modifiers, it is better to
deactivate them to ensure that the system will not evaluate and apply them.
Another benefit of deactivating, rather than end dating, is that deactivating incurs less cost because the
active flag on the modifier list is indexed. End dates are not indexed. Also, there is some additional code
to handle end date null values, which are not allowed with deactivation.

The above setup tips can improve the performance of online orders, as well as both standard and HVOP
order import.
To optimize HVOP Pricing available with 11i10, you should perform these setups.
Setup the JAVA pricing engine, assuming you participate in the Approved Strategic Implementers
program. (The setup steps will be referenced when the JAVA pricing engine is in full production.)
Run the concurrent program, QP: Maintains the Denormalized Data in QP Qualifiers. This program
checks your pricing setup, to determine if you can use the optimized code path. It updates the profile
option QP: High Volume Order Processing Compliance.
Check the site level value of the profile option QP: High Volume Order Processing Compliance. This
profile option cannot be set by users; instead it is set by the concurrent program Maintains the
Denormalized Data in QP Qualifiers. If the site level value is No, you will need to modify your pricing
setups, or not use the optimized code path.
If the site level value for QP: High Volume Order Processing Compliance is Yes, and if you are not
using customer sourcing rules, no further setup is required. But if the value is Yes and if you are using
custom sourcing rules, you may need to modify your custom sourcing rules. This is because the
optimized code path doesnt load the global record structure for G_HDR or G_LINE. If your custom
sourcing rules call G_HDR or G_LINE, modify your sourcing rules to pass the values directly.
The above steps will improve the performance of HVOP order import. Using only the Java Pricing
Engine will improve the performance of standard order import, online processing, and Process Order
API.

ZERO PRICED LINES

Ignore Item for Pricing Custom hook solution is to expose a profile controlled custom hook solution
which gets called for each line during pricing engine call, in which the customer identify if the item source
line needs to be priced or can be ignored for pricing engine processing and defaulted to 0. This way no
further pricing processing on the line. This would help customers having large orders or opening
configurator window which has major set of lines priced as 0. Implementation GuideLines 1) Customer's
pricing setup implementer has to identify the pattern which is suitable to identify the item lines which are
0 priced. This is completely left to discretion of the customer business. 2) No internal caching is present.
So, the same item for same line can be called again and again when different pricing calls are made at
various EVENT points. Customer needs to maintain caching logic, so that they don't hit same query
repeatedly in same session, which will help in performance.

The above performance improvement for orders having many zero priced lines has been
included in patch 8203943 for 11.5.10 and 8203956 for R12.

WORKFLOW
If you are using 11i9, the streamlined version of generic line flow is not seeded, but you can create your
own streamlined version, eliminating subprocesses. If you remove the subprocesses, the system does not
need to maintain status information for the subprocesses, and also for the Start / End activities inside the
subprocesses. It also reduces DML contention against the wf_item_activity_statuses. You may even be
able to remove additional activities based on your business requirements. For instance, if you source from
stock and do not manufacture, you can delete the activity Branch on Source Type. This allows you to
maintain the line flow for sourcing from stock. If you modify your flows, its critical that the
modifications be done correctly. For more information on streamlining workflow, refer to Metalink Note
130511.1

http://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=130511.1
With 11i10, Order Management seeds a generic line flow for performance: Line Flow Generic:
Performance. This seeded flow improves performance by reducing the number of subprocesses and
status checks. It can be used for all items types. Because this flow is not modular, it should not be
modified.
Note: The streamlined line flow, Generic: Performance, provides the same functionality as Generic line
flow. The benefit of the Generic line flow is that it simplifies extending or customizing workflow. This is
because the traditional Line Flow, Generic, has subprocesses. So if you copy the flow and insert a new
activity at the top level (i.e. the main flow), the rest of the flow will contain references to the subprocesses
defined by Order Management. Then when Order Management updates these subprocesses via a patch,
the modified workflow automatically points to the updated subprocess since the modified flow only
contained a reference to it. With the Generic: Performance lineflow, there are no subprocesses. There
are no references to subprocesses, only copies of the lineflow. Therefore, when a patch is applied, you
need to recopy and modify again the seeded flow if you have changed it. This is a side effect of having
everything at the top level for performance reasons.
Streamlining workflow improves the performance of both standard and HVOP order import, as well as
online performance. It improves the performance of the Process Order API, and concurrent programs
that process workflow activities.
Workflow Background Engine
The Workflow Background Engine also impacts overall system performance. By analyzing the frequency
and type of processing you require, you can ensure that the WF background engine runs efficiently. To
run the WF Background Engine, you must set two parameters:

Deferred? If set to yes, the WF background engine will pick up all deferred lines. For example, you
could pick up lines with deferred fulfillment.
Timeout? If set to yes, the WF background engine will pick up all timed-out lines.
Try to avoid running the Workflow Background Engine multiple times with both of the above parameters
set to yes. Instead, run it as required to check for one of the parameters. For instance, you might want
progress Deferred lines four times an hour, and progress timed-out lines one time a day. (Its likely that
you have more deferred processes than timed-out). However, the frequency depends on your business
needs. You may need to run the WF Background Engine several times a day, but the process will be
more efficient if you specify either Deferred or Timed Out lines, not both.
The Workflow Background Engine processes line by line. It is single-threaded, and cannot be multithreaded. However, you can schedule more than one job instance processing the same item type (for
example , Item Type = OEOL and Process Deferred = Yes), if the processing load for that item type is
excessive.
The activity of the Workflow Background Engine affects all order processing standard and HVOP
order import, online processing, and Process Order API.
Deferring Post-Booking Workflow Activities
You have the option to defer post-booking activities at the line level. For example, with seeded flows you
can defer either Schedule Line or Ship Interface by adding a Wait Activity, as shown in the diagram
below.

Alternatively, instead of deferring the post-booking activities at the line level, you can defer the booking
itself by using an order header workflow like the sample one depicted below:

The booking process is not inherently faster if deferred, but it provides a mechanism for load balancing.
If you can defer booking until off-peak hours, manual order entry or order import will be faster because
the booking process is deferred.
Deferred booking is recommended only if (1) you cannot meet your throughput goals during peak hours
and (2) you have exhausted all other tuning possibilities.
Certain order-taking scenarios lend themselves to deferred booking. If you are importing orders or
entering faxed information, you could defer booking. However, if you are talking to a customer while
taking the order, you might prefer to book the order while on the phone with the customer.
Another scenario that lends itself to deferred booking is converting quotes to orders. If you are
convering a large quote of perhaps 1000 lines to become a booked order, the process can take some time.
When converting quotes to orders, you might want to defer the booking process. Then when a user
performs an action to convert a quote to an order, the process will take less time. The booking action can
then be done in the background by the workflow engine.
Tax Calculation

Tax calculation at the time of entering or booking an order is only an estimate. If a product is
backordered for any length of time, there is a higher possibilty that the tax rate may change between
booking and invoicing. Evaluate whether you really need tax calculation at entry or booking. This
feature is often needed only when selling directly to consumers.

With Order Management Pack G, or 11.5.7, it is possible to declare the point of tax calculation on the
Order Transaction type setup. The Tax Event attribute on the Finance tab can be set to Invoicing. In
that case, Order Management does not perform any tax calculation, which improves the performance of
saving lines. However, the tax is still calculated in Receivables when the invoice is created. If you are
using HVOP order import, you will need to calculate tax at invoicing, as HVOP does not support tax
calculation at booking or entry.
With tax calculation deferred until invoicing, credit check will not include taxable amounts. Also, you will
not be able to view the tax if you open the order before invoicing. In many high volume scenarios, the
requirement is simply to print the tax on the invoice, not view the tax in the sales order form. You will
need to decide whether you can defer tax calculation, based on your business needs.
Deferring tax calculation is a requirement for HVOP. Additionally, it improves the performance of
standard order import, the sales order form, and the Process Order API.
In Releases 11.5.10 and 12.1.1 HVOP has been enhanced to support Tax Calculation at entry or booking.
RECEIVABLES TRANSACTION TYPE
For each line type set up in Order Management, specify the Receivables Transaction Type. This reduces
processing time for tax defaulting and tax calculation.

This improves the performance of online processing, Process Order API, and Standard order import.
CREDIT CHECKING
Evaluate the necessity of credit checking all customers. In many scenarios, users still ship to their
important customers, even if there are credit issues. If you can limit credit-checking to high-risk
customers, this will improve performance.

Both standard and HVOP order import support real-time credit-checking and pre-calculated exposure
functionality introduced in Family Pack G. For best performance, consider using the precalculated
exposures.
Using precalculated exposure functionality, Order Management enables you to periodically rebuild a credit
exposure image (orders, invoices and payments) for all customers or customer sites for all possible credit
rule definitions. When you submit the Initialize Credit Summaries Table concurrent program, changes to
the customer or customer site are calcualted and updated, based on your setup for each defined credit
check rule.
Refer to the Order Management Users Guide, Initialize Credit Summaries Table Concurrent Program, to
setup precalculated exposure. The User Guide explains that you can also import exposure details from
an external system.
These performance improvements will apply to the sales order form, order import, online processing, and
the Process Order API.
Values to ID Conversions
To improve performance, specify all ID columns on the interface tables instead of populating the Value
columns. This reduces the time that import process requires to convert Values to IDs.

Avoiding Values to ID conversions will improve the performance of HVOP and standard Order Import.
DEFAULTING
Defaulting is necessary to save time when entering orders in the sales order form. But if you are
importing orders, evaluate whether you can populate the values directly in the interface tables. For
example, you may know that the Bill To on the line is the same as the Bill To on the header. In that case,
pass the Bill To directly to the header and the line. If you pass all values to the interface tables, instead of
defaulting to get those values, the system can avoid the cost of checking the defaulting rules, and updating

those attributes within Order Management.

You do not have the option to turn off defaulting for standard order import. However, you could still
recognize performance gains by populating values directly in the interface tables, thereby allowing the
system to bypass defaulting. Populating the values directly in the interface tables improves the
performance of both order import, and the public Process Order API.
HVOP Defaulting
HVOP does not support the full defaulting framework. Instead it supports simplified defaulting with a
fixed hierarchy of sourcing. For headers, the fixed hierarchy is:

Agreements
Invoice To
Ship To
Order Type
For lines, the fixed hierarchy is:
Item
Ship To
Order Header
With HVOP, these attributes are not defaulted. They must be supplied directly in the interface tables:
Agreement
Currency
Customer / Contact
Customer PO
Deliver To / Deliver To Contact
Invoice To / Invoice To Contact
Ship To / Ship To Contact
Salesperson
Shipping / Packing Instructions
Sales Channel
Subinventory
All line-level attributes except subinventory can default from the header.
HVOP order import parameters window provides the option to turn off defaulting. If you can populate
values directly in the interface tables, turn off defaulting for better HVOP order import performance.
SCHEDULING
Imported lines can be autoscheduled or scheduled via workflow. A comparison is below.

When entering orders through the UI, lines can be autoscheduled when the line is saved, via right-mouse
click scheduling, or by manually entering the schedule date. If scheduling is not deferred, Booking is
followed by workflow scheduling.

Autoscheduling

Workflow
Scheduling

What it is

Schedules when the

line is entered or
created

Scheduling occurs
as part of a flow,
without manual
intervention, if set
up to do so

Performance

More performant

Incurs cost
associated with the
start and stop of
workflow

Flexibility

Less flexibility:
scheduling always
occurs at the time of
entering or updating a
line

More flexibility:
scheduling can be
deferred until after
Booking, after a
Wait activity, etc.

Scheduling can include ATP calculations and reservations. Scheduling can occur with batch order import,
either standard or HVOP, or at the time of manual online order entry.

Autoscheduling

Workflow
Scheduling

Online Order
Entry using
the UI

Supports both ATP and

the reservation time fence

Supports both ATP

and the reservation
time fence

Standard
Order Import

Supports both ATP and

the reservation time fence

Supports both ATP

and the reservation
time fence

HVOP Order
Import

ATP is supported but the

reservation time fence is
not

Supports both ATP

and the reservation
time fence

There are a number of factors that affect scheduling.

1. ATP
Regardless of whether you are scheduling with online order entry or with standard or HVOP batch
importing, there is overhead associated with ATP. You should use ATP calculations if needed, but many
users find they can avoid ATP checks in a high volume environment. Or you may want to to limit ATP
high value items with scarce supply.

Accurate ATP requires maintenance. For example, you need to keep the PO receipt dates up-to-date. If
you do not do the required maintenance, the quality of ATP suffers. If your volumes are high, consider
limiting the use of ATP to a few critical items.

With ATP, you may encounter an issue if the requested quantity is not available. If you are using
standard order import and if a line fails to schedule due to no availability
If you are sending a Schedule Ship Date, none of the lines for that order are imported.
If you are autoscheduling, the failed lines are imported without a Schedule Ship Date.
With HVOP, if the requested quantity is not available when Autoscheduling, the system logs a message
and continues. The order will import and workflow will try to schedule the line again. But if you send a
specific Schedule Ship Date and there is no availability, workflow takes the line back to Scheduling
Eligible status. If the requested item is not available with workflow scheduling, the line is imported but
unscheduled.
2. Sourcing Rules
Regardless of whether you are using ATP, try to populate the warehouse on the line. By specifying the
warehouse, you can avoid the cost of the system checking sourcing rules to determine the best warehouse.

This applies to both HVOP and standard order import, as well as online order processing.
3. Arrival or Lead Time Scheduling
Arrival / Lead Time calculations also require processing. You may need to calculate lead times and arrival
dates. But if your volumes are extremely high, you may want to evaluate whether you can schedule for a
ship date rather than an arrival date. Lead time scheduling will look at the sourcing rules, and may need to
evaluate regions and zones.

Lead time scheduling affects standard and HVOP order import, online processing, and Process Order
API.
4. Reservations
Manual online order entry and standard order import support the importing of reserved quantities,

and the reservation time fence.

HVOP does not support the importing of reserved quantities. HVOP workflow scheduling supports
the reservation time fence, but autoscheduling does not. The recommended approach for creating
reservations with HVOP is to schedule via autoscheduling, and then run Reserve Orders, released in
11.5.8, to create reservations as desired.
Reserve Orders is not inherently faster than reserving via the Reservation Time Fence. Your
requirements should drive the decision about when to reserve. If the requirement is to book and schedule
synchronously as quickly as possible, then defer creating reservations, i.e. use Reserve Orders after
booking.
5. Scheduling Configurations
If you are using kits, note the setting of the profile option, OM: Included Item Freeze Method. This
profile option determines the date and time Order Management uses to determine the included items for
a configurations bill of material. For better performance, set the profile option to freeze the included
item either at Entry or Booking. Then the system does not have to incur the cost of requerying the BOM
and exploding it again at the time of scheduling or picking.

The above profile option does not apply to HVOP. However, it applies to standard order import and
online processing.
With 11i10, a change was made in the way ATO and SMC PTO model lines are processed for workflow
scheduling. The system still sends all configuration lines to GOP for scheduling, but scheduling occurs
only when the Model line (for an ATO model or a Ship Model Complete (SMC) PTO model) reaches the
scheduling activity.

If you are using 11i9 or an earlier version with ATO or SMC models, and you want to use this
functionality, you can apply patch 3794704.
This performance benefit applies to workflow scheduling, using either standard or HVOP order import,
and also online workflow scheduling.

Scheduling with Order Import

Both standard and HVOP order import support workflow scheduling. However, they also support
autoscheduling. Autoscheduling occurs as the line is created. When importing orders, either with
standard or HVOP order import, autoscheduling is more performant than workflow scheduling. This is
because there are associated costs with workflow scheduling. Also, depending on your batch size, the
system may have to make multiple calls for workflow scheduling. For example, if your batch size is 5000,
and you import an order with 10,000 lines, there are two calls made for workflow scheduling. If you want
to autoschedule with standard order import, set the OM: Autoschedule profile option to Yes.

With HVOP order import, there is an additional benefit for autoscheduling. With HVOP, the system
makes a single bulk call to GOP, which is faster than a line-by-line call. The order lines are also updated
in bulk, rather than line-by-line, with a Schedule Date. With HVOP, you can autoschedule either by
setting the OM: Autoschedule profile option to Yes, or providing a Schedule Date on the line.
Online Scheduling
Within the sales order form, you can schedule orders online. This is often done manually using Right
Mouse, Scheduling. In addition, you can autoschedule or schedule via workflow.

If autoscheduling is turned on and you are entering orders manually, autoscheduling occurs as each line is
saved, with right-mouse click scheduling, or by entering the schedule date. Then the cost of scheduling
is not incurred at the time of booking. If you use autoscheduling with online order entry, booking is
faster, and the overall scheduling time is more performant than workflow scheduling.
If you schedule via workflow, a typical line flow synchronizes scheduling to occur with booking.
Pressing Book causes the order to book. After booking, workflow schedules the order lines. You can
modify workflow so that scheduling is deferred to occur at a different point in the flow, not synchronous
with booking. One advantage of deferred scheduling is that it can occur in evenings, as an example, at a
time with the processing load is lighter. The benefit of deferred scheduling is not that scheduling takes
less time, but that you can book orders more quickly, and plan scheduling to occur at a time when your
processing load is lighter. This benefit applies to both order import (standard or HVOP), and also to
online scheduling. You may want to evaluate whether its beneficial in your business to delay scheduling
until a time when there is less load on the system.
HVOP note: With 11i10, it is possible to progress Booked lines more quickly to the point of Shipping
Interface. To progress to the point of Shipping Interface, lines must reach the status of Awaiting
Shipping. This will not occur if scheduling is deferred. If you defer scheduling with 11i10, you will lose
the benefit of bulk-enabling lines to the point of Shipping Interface. With deferred scheduling, the
interface to shipping will happen line by line.
When evaluating whether to defer scheduling, consider your requirements. If you need for Booking to be
faster, defer scheduling. If you need to Book and Schedule synchronously, but you must schedule lines as
quickly as possible, omit reservations at the time scheduling and later run Reserve Orders. Also, you
could schedule synchronously with booking, but defer the ship interface.

ATTACHMENTS

Order Management allows setting up rules to automatically attach documents when creating an order. If
you are not using this functionality, set the value of the profile option, OM: Apply Automatic
Attachments to No.
Turning off attachments improves the performance of standard order import and online processing.
HVOP order import does not support automatic attachments.
MARGIN CALCULATION
Order Management provides functionality to calculate margins for order lines. If you do not require this
functionality, turn it off in the Order Management Systems Parameters form.

HVOP does not calculate margins. If you can turn off margin calculations, it helps the performance of
standard order import, Process Order API, and online order entry.
TRANSPORTATION EXECUTION
From 11i9, Order Management provides integration with Transportation Execution. If you are not using
Transportation Execution, turn off Get Ship Method and Freight Rating in the Order Management
System Parameters form.

The transportation features Get Ship Method and Freight Rating are not supported by HVOP. Disabling
the Transportation Execution parameters in the OM parameters form improves the performance of
standard order import, Process Order API, and online processing.
VERSIONING
In 11i10, Order Management provides versioning capabiltiy, either manual or automatic. Versioning is a
useful feature but it can tax the system if used too broadly. Versioning uses the Audit Trail infrastructure
of the Constraints framework.

If you require versioning, limit its use to the required attributes:

Specify which attribute(s) should be versioned
Select the correct Applies To phase, either Fulfillment or Negotiation
Also limit the conditions, i.e. you might want to roll the version only at the time booking. Keep in mind
that versioning backs the entire transaction into history, and there will be a larger performance impact for
larger orders.
AUDIT TRAIL
Order Management provides functionality to keep audit trails for various attributes. The functionality is
very flexible, allowing you to maintain an audit trail for one attribute but not for others. Analyze your use
of audit trail. If you can minimize its use, it will improve overall scalability.

HVOP supports only the Create operation, so it is not an issue with HVOP. But Audit Trail has an effect
on performance. To help performance for standard order import, online order entry, and Process Order
API, limit the extensive use of Audit Trail.

Debug
Ensure that debug is turned off.
OM: Debug Level, set to 0 for OFF
WSH: Debug Enabled, set to No
WSH: Debug Level, set to 0 for OFF (for Pick Release and ITS debug)

 QP: Debug Mode, set to Request Viewer Off

Having debug on can result in significant performance overhead, increasing processing times by a factor
of up to 10.
It may be necessary to turn on debug for the purpose of troubleshooting the code execution path. If so,
turn on debug only for the purpose of generating the debug file. This profile option should be set only at
the user level.
For generating Order Management trace files to record elapsed time, set OM: Debug Level to OFF, i.e.
the debug level should be 0.
The setting of any of the Debug profile options can affect both standard and HVOP order import, as well
as online processing. They can also negatively impact Pick Release, Interface Trip Stop, Ship Confirm,
and Inventory Interface.

HVOP Setup
For Order Management HVOP order import, no special setup is required. However, you will probably
want to evaluate whether you can import a significant portion of your orders using HVOP order import.
To use both standard and HVOP order import, separate the lines for each import run. First bring in all
lines eligible for HVOP order import, and then import the remaining lines using standard order import.

UI Performance
This section pertains to entering order online processing. Although most high volume environments
depend heavily on order import, some high volume businesses enter orders online.
Folders
If you can use the default sales order form, there is less processing cost in the sales order form. On the
other hand, the use of Folders tailored to your business scenario can save users a significant amount of
time.

In a manual order entry environment, you may find that a tailored folder can reduce the amount of time
required to enter the typical order. However, if you are importing the bulk of your orders, evaluate
whether you can use the default folders. Or if only a few orders require frequent moving from tab to tab,
you may want to consider the trade-off of faster processing vs faster order entry.
Using default folders improves the performance of online processing, i.e. all actions in the sales order
form. There is no impact on standard or HVOP order import.
Defaulting
Defaulting required values greatly reduces the amount of time required for CSRs to complete the entry of
an order. On the other hand, there is some cost to defaulting. You should review your defaulting to
ensure that you are defaulting only those attributes that are of importance to your business. For example,
if you are not using the attribute for Shipment Priority, dont incur the cost of defaulting that value to the
header or line.
Online Booking
Scheduling can occur via workflow, immediately after booking. This extends the booking time. As an
alternative, you may want to autoschedule. If you enter orders in the sales order form, autoscheduling
schedules lines as they are saved. If you dont need to schedule when saving a line or at the time of
booking, you can defer scheduling to occur later in the flow. Alternatively, you could create a line flow
with Scheduling Manual subprocess, which would advance the line to Scheduling Eligible. Lines in
Scheduling Eligible status could be scheduled later using the Schedule Orders concurrent program, or

they could scheduled manually at a later time.

Add Customer
In 11.5.6 Order Management added a feature to create a new customer account from the sales order form.
This feature is useful, because it allows CSRs to create a new customer without having to leave the sales
order form and to move to the Customer form. However, the order entry process can be greatly reduced
if the customer exists in the system. As much as possible, have all customer created before the order
entry process.
Online Configurations
The profile option, OM: Configuration Quick Save, improves the performance of saving configurations
during online order entry. The values are Yes and No. If set to Yes, Class lines are inserted into the
database with very little validation. If you are pricing classes, test to ensure that pricing occurs as
expected, i.e. at the order event.

This profile option, if set to Yes, is more beneficial if your model has many classes. For instance, the class
may act more like a placeholder, i.e. 50 classes and 50 options. In this case, the performance gains will be
noticeable. However, if you are using 5 classes, each with 50 options, the benefit will be less.
This feature applies only to unbooked orders created using the online UI.
Another profile option, OM: Show Line Details, allows you to show only the model on the sales order
form. If your typical orders are for 10 models with 50 lines each, its not feasible to view all the lines for a
model within the sales order form. You may prefer to show only the lines for the model. If you show
only the lines for the model, you can move more quickly from the order header to the lines tabs, for
instance. Also, its easier to view what models are on the order.
This profile options applies only to online order processing, and is relevant for both usability and
improving performance.
Quick Sales Order
The Quick sales order form allows you to tailor the form for optimal order entry. For example, if you
always use the Price and Availability form, you can have Pricing and Availability as a button on the form.
You can keep a feature you use frequently, such as Pricing and Availability or Related Items, open in the
lower region of the Quick Sales Order form.

By tailoring the form to meet your requirements, you can reduce the number of keystrokes for entering an
order. Make sure that your changes are supporting the common business scenarios, as you will want to
avoid the cost of a tailored folder that is rarely used.
Defer Pricing
If you are using the Quick sales order form, there is a flag on the form to Defer Pricing. (This flag does
not exist on the standard sales order form.) The default value for this control is determined by the profile
option OM: Quick Sales Order Form: Defer Pricing. If set to yes, pricing does not occur as the lines are
entered; instead pricing occurs when the order is saved.

Additionally, if the tax event on the Transaction Type is Entered, and if the Defer Pricing flag is set, tax
calculation is deferred until the order is saved. Two examples are below.
The tax event on the Transaction Type is Entered, and Defer Pricing is set. When the user enters an
item or qty, and nagivates out of the field, tax is not calculated because the price is null. At the time of
saving, the pricing and tax calculation occurs.
Again, assume that the tax event on the Transaction Type is Entered, and Defer Pricing is set. If there
is an existing order, with a price, updating the Item or Qty attribute in the order will calculate tax, even if
Defer Pricing is set to yes. Updating other attributes that dont trigger taxing will not cause tax to be

recalculated. But when the order is savevd, the price may change and tax will be recalculated again.
If the Tax Event on the Transaction Type is Entered, tax is calculated when the price is changed, or a taxrelated field changes. But if Pricing is deferred, tax is not calculated when navigating out of the line;
instead both price and tax are calculated when the order is saved.
Refresh Behavior
In both the standard and Quick Sales Order form, orders are automatically requeried from the database
after each save. The entire order is refreshed to ensure the processing of delayed requests for changed
values. For example, a changed value on a model may cascade to options, or there may be a pricing
update due to an order event.

To control the behavior of requerying the database for a refresh, a new profile option OM: Sales Order
Form: Refresh Method is added in 11i10. There are four values:
Automatic Refresh with Repositioning of the Cursor. The screen is refreshed, and the cursor is
repositioned to the line from which the Save was performed.
Automatic Refresh without Repositioning of the Cursor. The screen is refreshed, and the cursor is
always repositioned to the first line.
Manual. Users have to requery to see the refresh changes. The screen is not refreshed automatically.
Askme. A dialog box asks the user to decide whether they want to refresh the screen to see the data. If
the user says Yes, the screen is refreshed. Otherwise the screen is not refreshed.
Of these four options, Manual is most performant, followed by AskMe. If you want the screen to be
automatically refreshed, Automatic Refresh without Repositioning of the Cursor is more performance
than Automatic Refresh with repositioning of the Cursor.
For the Quick Sales Order form only, there is an additional profile option, OM: Quick Sales Order Form:
Auto Refresh. The Quick Sales Order form looks at the following profile to determine if the refresh
should be initiated. If the following profile option is set to refresh, i.e. Line, Line Details, or Both, then
the Quick Sales Order form looks at the above profile option to determine how the refresh should occur.
There are four possible choices for OM: Quick Sales Order Form: AutoRefresh:
None. Do not refresh the lines after saving.
Line. In this case, only the Lines are refreshed after a save. The changes in the Line Details region of
the Quick Sales Order form, e.g. Related Items, Service, etc., are not refreshed after saving, and they are
not coordinated while entering lines. Users need to navigate to the region, i.e. Related Items, to view the
Line Details information.
Line Details. Only the Line Details are refreshed after a save. This option coordinates the Line Details
regions, such as Related Items or Service, while entering lines. Additionally, the active Line Details region
displays refreshed date after the save, which eliminates the need for the to navigate again to that region.
Both. Both the Line and the Line Details regions are refreshed after a Save. In this case, the active
Line Details region appears, so the user does not have to navigate there manually to view the data in the
line details region. Also the line details regions are coordinated while entering order line.
The refresh behavior impacts online processing.
Integration with TeleSales
TeleSales users can efficiently enter sales orders by directly calling the sales order form from the eBusiness
Center form. This functionality improves the UI navigation, but does not enhance the performance of
the processing of the order.

Invoking the Sales Order Form from the eBusiness Center results in opening the Sales Order Form. You
want to avoid the frequent opening and closing the Sales Order Form, which is expensive. Instead, keep
the Sales Order Form open, and toggle to it from the eBusiness Center. For example, query for the
customer in the eBusiness Center, and then copy the customer account name from the eBusiness Center
to the Sales Order form.
The profile option OM: Sales Order Form Preference controls whether TeleSales calls the standard or the
Quick order form.
Integration with CRM
Several applications track events that occur in the order fulfillment flow in Order Management. E.g.
Installed base tracks where items are shipped to update its location. Order Management then feeds for
every relevant change in the flow of the order information into the queue
'ASO_ORDER_FEEDBACK_T'.

Following query will show the number of rows in the ASO_ORDER_FEEDBACK_T table and the
name of consuming CRM Application like - Oracle Trade Management (OZF) ,Oracle Service Contracts
(OKS) , Oracle Sales Compensation (CN).
select consumer_name, msg_state, count(*)
from aso.aq$aso_order_feedback_t
group by consumer_name, msg_state;
If you are not using any of the consuming Applications returned by the above query then set the user
defined profile OM:Bypass Notification to Order Capture to 'Y'
Navigation steps to create profile:
1.Create a new profile with the following values:
Name: ONT_BYPASS_NOTIFY_OC
Application: Oracle Order Management
User Profile Name: OM: Bypass Notify OC
Description: Bypass enqueue to CRM
Active Dates Start: <valid date>
2. Login to the System Administrator Responsibility -> Profiles.
Set the Value of the Profile OM: Bypass Notify OC to "Y" at the Site Level..

BEST PRACTICE FOR PERFORMANCE TUNING

Begin by tuning performance for a single thread. Then tune performance for multiple threads.
Single Thread
For your test, begin by creating a batch of orders that you will use to gather your sample data. Use an
order size that is representative of a typical order in your production system. For instance, if a typical
order has 10 lines, use 10-line orders. Or if the typical order has 5 lines, create5-line orders.

Ensure that the order uses functionality typically used in your business, i.e. autoscheduling, pricing
features, credit-checking, etc. For pricing, set up price lists, modifiers, and qualifiers as your business
requires.

Then do the following:

Import the orders in Entered status without turning on Trace. Note the timings for a single thread for
1000 lines of your typical order, i.e. for 100 orders of 10 lines each, or 500 orders with 2 lines each, etc.
Then process the orders, importing them again in Entered status, with Trace ON. Again note the
timings, i.e. for a single thread for 1000 lines using your typical order.
Then import the orders in Booked status without Trace. Note the timings again -- for a single thread
for 1000 lines using your typical orders.
Then import lines in Booked status with Trace On. Note the timings.
The above information is needed to report to Support the timings recorded. The raw trace + Tkprof
output can be sorted in [exeela, fchela, prsela].
Basedon analysis of the tkprof, Oracle Support may recommend additional patches, set up changes,
custom indexes, etc.
Apply Oracles recommended changes to the environment, and then begin another reiteration of the test.
Testing for Scalability with Order Management
After ensuring optimal performance for a single-thread run, prepare to run Order Management using 10
threads. Each thread will be for 1000 lines, using the same typical orders as discussed in the above
section.

Using the same sample order size and setups, do the following:
Import a batch of 1000 lines in Entered status, without trace on, for 10 threads. Note the timings.
Repeat the process with SQL tracing enabled at level 8 (waits). Generate StatsPack or AWR (for 10g)
reports for the run. Note the timing and provide the trace file for one of the threads.
Then repeat the level 8 trace for orders in booking, and provide the trace file for one of the threads.
Provide Oracle support with the recorded timings of the trace files, the number of threads used, and the
Tkprof outpot, sort in exeela fchela prsela sequence, with the Explain plan turned off.
Oracle Support will then be able to analyze the output, and may recommend additional patches, set up
changes, custom indexes, or reverse key indexes. Implement Oracles recommendations, and then begin
another iteration of this procedure using a different number of threads.
Tuning for the optimal number of threads
Repeat this process with a different number of threads to find the optimum number of threads to use.
The most common batch size for diagnosis is 1000 lines.

Start with perhaps 2 threads. Then gradually increase the number of threads to find the optimal
throughput. Throughput will increase as more threads are used.
TROUBLESHOOTING

Partitioning
Patch 1531371, which partitions Order Management tables, is suited for those customers who primarily
use parallel streams for Order Import or HVOP, and for which a significant amount of buffer cache latch
contention is being observed. This patch partitions the tables by the primary keys to minimize block
contention, which results in improved scalability for standard order import or HVOP.

Some businesses import a small percentage of their order lines, with standard order import or HVOP.

For those who enter most of their orders manually using the standard sales order or the Quick sales order
form, the partitioning supplied by Patch Patch 1531371 is not suitable. Partitioning adds overhead for
orders entered online.
There may be other reasons why you want to partition. For example, you might want to separate open
and closed orders. You can of course partition the OM tables in a logical manner using other partition
keys, but partitioning adds overhead. If you are entering most of your order lines manually, do not apply
this patch for partitioning unless the overall benefit of partitioning outweighs the performance overhead.
For more informatin, refer to the white paper Partitioning and Purging Best Practices in the eBusiness
Suite.
Collecting Statistics
If the SQL trace files, Statspack, or AWR reports suggest that a SQL statement or set of SQL statements
are performing poorly and the root cause is due to a sub-optimal execution plan, and the statistics may be
stale, you should gather statistics using the Gather Schema Statistics concurrent program in order to
ensure the execution plans are based on the most recent set of statistics. To gather statistics for the
schema of Order Management, including the interface tables, refer to Metalink Note 130511.1.

http://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=130511.1

Scripts
In addition, Metalink Note 169935.1 provides information on how to use the following scripts:

http://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=169935.1
bde_chk_cbo.sql -- Order Management recommends this script because it provides output for
analyzing any performance issue. It gives the Database parameter details and their settings.
qpperf.sql Advanced Pricing recommends that you run this script if you are facing an issue pertaining
to pricing performance.
For additional information about pricing performance, refer to the Pricing Performance White Paper:
Metalink Note 137328.1, Oracle 11i Tuning Advanced Pricing for Optimal Performance
http://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=137328.l

Scalability Contention

If you are running multiple workers of Order Import or HVOP in parallel, you may experience segment
contention due to block contention. When multiple threads of order import (standard or HVOP?) are
running, the threads may show signs of contention such as waits on buffer cache latches including cache
buffer chains latch waits. You can identify the hot or contended segments by referring to the Statspack or
AWR reports in the segment waits section. Statspack or AWR will list the top segments by buffer gets,
disk reads, and waits.
Typically, the contention involves primary key indexes such as OE_ORDER_LINES_U1. To reduce the
contention, you can apply the partitioning patch or rebuild the contended indexes as reverse key indexes.
Reverse key indexes reverse the key value, which results in index entries being stored across blocks, rather
than in the same block. This helps reduce index contention. Reverse key indexes will also increase the
index segment footprint in the buffer cache, so you will need to increase the buffer cache size to
accommodate the reverse key.

Trouble-shooting Analysis
There may be occasions where you have implemented the tips covered here, and you still are having a
performance issue. In that case, you may need development assistance for troubleshooting.

If that is the case, prepare the information as directed in Appendix C, and provide this information in
your TAR.

WATCH OUT FOR

Here is an exception you will need to understand.

With Order Management, if you want to use both supported and unsupported features for HVOP, you
need to separate lines for each type of import. HVOP order import does not import lines with
unsupported features, i.e. ship sets or tax calculation at booking. With Pricing, if you want to use both
supported and unsupported features, all your lines will import but the optimized code path will not be
used if the pricing setups contain any unsupported features.

EXAMPLES

Limited Feature Set / HVOP Order Import

Because performance is critical, you may want to use only those features supported by HVOP and
Advanced Pricing. You can live without features such as iPayment integration, ship sets, and drop
shipping. But you want to find additional ways to improve your performance. For example, you could:

Populate the interface tables directly with all value, rather than use the limited defaulting capability
provided by HVOP
Use the streamlined workflow, Line Flow Generic: Performance
If there are deferred processes, set the Workflow Background Engine to run efficiently (If you are not
deferring processes, you may not need to run the Workflow Background Engine.)
Turn off Reprice at Booking
Limit credit-checking to high-risk customers, and using precalculated exposures
Import lines as Booked, so they are bulk-enabled up through Shipping interface
Use the Java pricing engine, if part of the Approved Strategic Implementers Program
Specify the Receivables Transaction Type for the lines
Ensure that Debug is off

Limited Features / HVOP Concurrent Program

If you use HVOP, you can populate the Schedule Date directly in the interface tables for optimal
performance. You also want to use the reservation time fence, but HVOP supports the reservation time
fence only via workflow scheduling.

To achieve your objectives, you could bring in the orders using HVOP, scheduling by supplying the
Schedule Date in the interface table. This allows you to schedule the orders in less time than using
workflow scheduling. Then you can run the Reserve Orders concurrent program to place reservations per
your defined parameters.
There are also concurrent programs for Inventory Interface and the Credit Check Processor. You can
run those programs at specific times, either to improve or the performance of order import or to control
when processing occurs.

Combining HVOP and Standard Order Import

You have determined that for most orders, its OK to calculate tax at the time of invoicing. This is
because 90% of your orders are shipped to directly to businesses, and your requirement is to ensure that
tax is printed on the invoice. You can do this with HVOP. However, 10% of your orders are coming
from an online web store, where tax must be calculated at the time of booking the order.
For optimal performance, you use HVOP to bring in the 90% of your lines that do not require tax
calculation at the entry of booking of the order. You use standard order import to import the remaining
lines.

Full Features / Standard Order Import

You want to use all features within Order Management, but you have high order volumes and a limited
amount of time for importing and processing. You decide to buy additional hardware and memory to
support all features.
Additionally, you modify as many setups as possible to optimize performance:
Use the streamlined workflow, Line Flow Generic: Performance
Set the Workflow Background Engine to run efficiently
Turn off Reprice at Booking
Limit credit-checking to high-risk customers, and using precalculated exposures
Specify the Receivables Transaction Type for the lines
Ensure that Debug is off
Turn off automatic attachments if possible
Limit the use of features such as Gross Margins, Audit Trail, and Transportation Execution as allowed
by your business
Also, you make every effort to ship full quantities, to ensure better performance of Interface Trip Stop.
You may even decide to defer Inventory Interface for a few minutes, for better load-balancing. You also
ensure that no unnecessary calls are made to Pricing at the time of Ship Confirm.

ONLINE ORDER ENTRY

You have many heads-down data entry people who are pounding the keyboard to enter as many orders as
possible in a short amount of time.

You will probably want to use the Quick Sales Order form, as it can be tailored to keep open your most
frequently used region, i.e. Pricing and Availability, Related Items, Options, Services, or Adjustments. Set
up defaulting so that the CSR needs to enter minimal header information, plus the item and quantity on
the line.
Also consider using the seeded default folder, for optimal performance. You should evaluate the
advantages vs. the cost of tailoring your own folder.
If possible, set the Defer Pricing flag on the Quick Sales Order form to default to Yes.
Also choose the most efficient refresh behavior for the Quick Sales Order form, based upon your
business requirements. For instance, you may want the form to refresh, but it may be acceptable to
reposition the cursor to the first line.
To avoid the cost of adding customers on the fly, set up accounts for all expected customers. This will
greatly reduce the amount of time required to enter an order.
In 11i9 as well as in 11i10, you can directly launch the sales order form from the TeleSales eBusiness
Center form, which provides a 360-degree view of the customer. A profile option, OM: Sales Order
Form Preference, controls whether TeleSales calls the standard classic form, or the Quick form.
It is always recommended to have a larger SGA for better performance of order entrry. For the
recommened 'Database Initialization Parameter Settings for Oracle Applications Release 12' refer to
metalink note 396009.1. Make sure that Gather schema statistics is done on a regular basis so that the
optimiser will choose the correct plan and the performance will be good.
From Release 12.1 the performance of the Item LOV can be improved by setting the profile option 'OM:
Use Materialized View for Items LOV' to 'Yes'. When this profile is set the LOV brings up the Items
from a materialised view which is faster.. Make sure you run the concurrent program Refresh Order
Management Materialized Views to populate the materialized view whenever there is a change in the Item
related setups.

Integration with TeleSales

TeleSales users can quickly and efficiently enter sales orders by directly calling the sales order form from
the eBusiness Center form. This functionality improves the UI navigation, but does not enhance the
performance of the processing of the order. The profile option OM: Sales Order Form Preference
controls whether TeleSales calls the standard or the Quick order form.
APPENDIX A

Order Management provides many features, and each of these features has variations. Its not feasible to
provide a performance time for each of the feature variants. These features were used to obtain the
following benchmark.
Various steps in the order-to-cash flow were measured: order creation, booking, shipping &
invoicing. The order import tests are based on HVOP order import.
A single price list was used without discounts.
Credit Checks were not performed.
Standard Items & Kits

 ATP / Non-ATP Mix (20%/80%).

Scheduling (For HVOP, auto scheduling was used).
Test Environment:
These tests were internal performance tests, and were not audited or verified by an external agency.
The test was conducted using 260 orders and 77 lines per order.

The following chart contains benchmarks for 11i10. These numbers show the number of lines processed
per hour for specific features, using a single 450 Mhz processor. Other environment details are:
Applications - 11.5.10 Vision Database 10.1.0.3 (10gR1) Middle Tier - 8.0.6, patchset 13
Feature
HVOP Order Import, Standard Items
HVOP Order Import, Reserveable Items
HVOP Order Import, Lot Controlled
HVOP Order Import, Serial Controlled
HVOP Order Import, Kit Controlled
HVOP Order Import with Pricing
Pick Release, Standard Items
Pick Release, Reserveable Items
Ship Confirm, Standard Items
Ship Confirm, Reserveable Items
Interface Trip Stop, Standard Items
Interface Trip Stop, Reserveable Items

Throughput per Hour

37500
37650
37400
37900
36000
25000
31173
8605
107000
75300
11400
8366

The order import features are known to scale well across multiple processors. For instance, you might see
a degradation of 10% across four processors, i.e. 4 processors could import 90,000 lines priced in an hour.
Indications are that ITS and Pick Release also scale well.

11i10, One
Hour, HVOP

1 450 Mhz Processor

400
1.2 Ghz
Mhz
37,500 112,500

Standard
items
Reserveable 37,650 112,950
items
37,400 112,200
Lotcontrolled
items
Serial37,900 113,700

4 450 Mhz
Processors
1.2 Ghz

400
Mhz
135,000 405,000
135,540 406,620
134,640 403,920

136,400 409,320

controlled
items
Kits
36,000 108,000
Std items
25,000 75,000
with pricing

129,600 388,800
90,000 270,000

The following graph demonstrates scalability across multiple processors. To achieve speed, performance
scales well with additional hardware.

For the list of recent performance fixes in R12 please refer to Metalink Note: 849060.1
APPENDIX B

These features are supported by HVOP order import:

Autoscheduling, workflow scheduling, and the scheduling parameters for LAD and Promise Date setup
Booking
Manual price adjustments
Order creation
Shippable and non-shippable flows
Standard items and kits

 Pricing many features such as discounts, surcharges, freight and special charges, static or dynamic
formulas, GSA pricing
Process manufacturing (11i10)

These features are not supported:

Add customer
Any action request other than booking
ATO items
Audit trail
Automatic attachments
Commitments
Configurations other than kits
Credit card orders
Defaulting framework use of the full-featured defaulting. HVOP does support limited defaulting, as
described in the Defaulting section.
Drop shipments
End customer
Freight Rating for Transportation Execution
Get Ship Method for Transportation Execution
Gapless order numbering
Insert-based constraints
Internal orders
IPayment integration
Margin calculations
Move, Add, Change, Disconnect (MACD)
Multiple and partial payments
Pricing attributes, coupons, ask-for promotions
Quote processing
Releases against blanket sales agreements
Reservations
Returns
Service items
Sets arrival, ship, fulfillment
Tax calculation before invoicing
Updates, deletes
Versioning

HVOP has been enhanced in 11.5.10 to support configurations and Tax calculation at entry or booking.
To get these customers need to apply one-off patch 5620899 or any cummulative patch created after
January 2007. This ER is also front ported to 12.1.1.

APPENDIX C

If your performance issue(s) require development assistance, you need to provide the following
information to assist with troubleshooting.
1. Logged Issues
Bug / Tar Number

CSI Number

Description

2. If you are experiencing a UI performance issues, answer the following

questions. Otherwise proceed to the next question.
Describe the middle tier hardware configuration (number of CPUs and memory)

Does the environment use customized code in CUSTOM.pll?

Are there custom folders?

3. Describe the Pricing setups.

Identify the number of price lists and modifier lists, and if possible, provide the
output of $QP_TOP/patch/115/sql/qpperf.sql

Describe the selectivity of the qualifiers on the price lists and modifiers. If there
is higher selectivity (that is, fewer lines are eligible for the qualifier), the pricing
engine performance is much better.

Is the Not= operator used on qualifiers?

Are custom attribute mapping rules being used? If yes, the values should be
cached.

How many attributes and qualifiers are passes per order line?

Does the customer use linegroup level modifiers? When the linegroup based
modifiers are set up, do they typically apply to specific items / categories or to all
items?

Are blind modifiers used?

Get_Custom_Price API should include caching whenever appropriate. Is this

occurring?

4. Models and Configurations

How many orders are being imported during the average import run?
How many models are on the typical order?
How many options and classes are in one model?
Is the system checking for holds for options and option classes?
Which types of models are used? ATO only? PTO only? Both?
Does scheduling occur at the time of order import by passing the schedule ship
date or ship set ID?
How much time is taken for a typical run of order import with models?
What is the Order Management Family Pack level?
In one order import run, do you import orders in both Booked and Entered
status?
Does pricing occur at the option class level?
Does pricing occur at the option level?

Are options selected with Configuration or with the Options window?

If you use Configurator, do you use complex rules?
rules changed frequently?

If so, how many? Are the

How frequently are BOMs updated?

Do you Oracles UI to create the orders? If so, do you use the profile option OM:
Configuration Quick Save?

5. What patches have you applied? If available, provide % or timing

improvement observed with each patch.

6. Process/Setup Changes Implemented. Where available, provide percentage

or timing improvement observed with each change, e.g. turned off pricing at
booking or implemented streamlined workflow.

Scalability in Order Management

May 2005
Author: Manish Chavan and Linda Henry
Contributing Authors: Nithya Lakshmanan, Venkatesh Malapati, Ahmed Alomari

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
Web: www.oracle.com
This document is provided for informational purposes
only and the information herein is subject to change
without notice. Please report any errors herein to
Oracle Corporation. Oracle Corporation does not
provide any warranties covering and specifically
disclaims any liability in connection with this document.
Oracle is a registered trademark, and Oracle Order Management
is a registered trademark(s) of Oracle corporation.
All other names may be trademarks of their respective owners.
Copyright Oracle Corporation 2001
All Rights Reserved