Improving Performance in Order

Management
An Oracle White Paper
May, 2005
 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.

White Paper Title Page 2

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

White Paper Title Page 3

 • 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

White Paper Title Page 4

 performance improvement is not restricted to orders imported with
HVOP.

Process Manufacturing

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

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 self-analysis, 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.
Other HVOP supported features include holds processing, item cross-referencing,
acknowledgements, and credit checking. (Credit-checking is supported but not
optimized.)

White Paper Title Page 5

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 bulk-enabled 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.

White Paper Title Page 6

 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*
Use all pricing features
Same as 11i9 Do not use Java Pricing Engine*
Use all pricing features
*Available to those in the Approved Strategic Implementers Program

White Paper Title Page 7

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, here’s 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.

White Paper Title Page 8

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 doesn’t load the global record structure for
G_HDR or G_LINE. If your custom sourcing rules call G_HDR or

White Paper Title Page 9

 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.

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, it’s 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

White Paper Title Page 10

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 a
day, and progress timed-out lines one time a day. (It’s 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 multi-threaded.
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.

The booking process is not inherently faster if deferred, but it provides a

White Paper Title Page 11

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.

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.

White Paper Title Page 12

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 User’s 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

White Paper Title Page 13

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

White Paper Title Page 14

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 Scheduling occurs
the line is entered as part of a flow,
or created without manual
internvention, if
set up to do so
Performance More performant Incurs cost
associated with the
start and stop of
workflow
Flexibility Less flexibility: More flexibility:
scheduling always scheduling can be
occurs at the time deferred until after
of entering or Booking, after a
updating a line 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 Supports both ATP and Supports both ATP and
using the UI the reservation time fence the reservation time fence
Standard Order Import Supports both ATP and Supports both ATP and
the reservation time fence the reservation time fence
HVOP Order Import ATP is supported but the Supports both ATP and
reservation time fence is the reservation time fence
not

There are a number of factors that affect scheduling.

1. ATP

White Paper Title Page 15

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.

White Paper Title Page 16

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 configuration’s 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

White Paper Title Page 17

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 it’s 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

White Paper Title Page 18

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

White Paper Title Page 19

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.

White Paper Title Page 20

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, don’t 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 don’t 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

White Paper Title Page 21

lines each, it’s 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, it’s 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 don’t 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 tax-related 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.

White Paper Title Page 22

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

White Paper Title Page 23

 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.

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

White Paper Title Page 24

 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 Oracle’s 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 Oracle’s 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

White Paper Title Page 25

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.

White Paper Title Page 26

 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

White Paper Title Page 27

unsupported features, all your lines will import but the optimized code path will not
be used if the pricing setups contain any unsupported features.

White Paper Title Page 28

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

White Paper Title Page 29

 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, it’s 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.

White Paper Title Page 30

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.

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.

White Paper Title Page 31

APPENDIX A

Order Management provides many features, and each of these features has
variations. It’s 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

White Paper Title Page 32

 Feature Throughput per Hour

HVOP Order Import, Standard Items 37500

HVOP Order Import, Reserveable Items 37650
HVOP Order Import, Lot Controlled 37400
HVOP Order Import, Serial Controlled 37900
HVOP Order Import, Kit Controlled 36000
HVOP Order Import with Pricing 25000
Pick Release, Standard Items 31173
Pick Release, Reserveable Items 8605
Ship Confirm, Standard Items 107000
Ship Confirm, Reserveable Items 75300
Interface Trip Stop, Standard Items 11400
Interface Trip Stop, Reserveable Items 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, 1 450 Mhz 4 450 Mhz

HVOP Processor Processors
400 1.2 400 1.2
Mhz Ghz Mhz Ghz
Standard items 37,500 112,500 135,000 405,000
Reserveable items 37,650 112,950 135,540 406,620
Lot-controlled items 37,400 112,200 134,640 403,920
Serial-controlled items 37,900 113,700 136,400 409,320
Kits 36,000 108,000 129,600 388,800
Std items with pricing 25,000 75,000 90,000 270,000

White Paper Title Page 33

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

300000

250000

200000
Order Lines / Hour

150000

100000

50000

0
1 2 3 4
N u m b e r o f P ro c e s s o rs

400 M H z 1 .2 G H z

White Paper Title Page 34

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

White Paper Title Page 35

• 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

White Paper Title Page 36

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?

White Paper Title Page 37

 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? If so, how many?
Are the rules changed frequently?

How frequently are BOMs updated?

Do you Oracle’s 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.

White Paper Title Page 38

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