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

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

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

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 multi-threaded. 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 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.

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:

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 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, HVOP

1 450 Mhz Processor 4 450 Mhz Processors

400 Mhz

1.2 Ghz 400 Mhz

1.2 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- 37,900 113,700 136,400 409,320

controlled items Kits 36,000 108,000 129,600 388,800 Std items with pricing

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