28294599 Using Workflow in Oracle Order Management

Using Workflow in Oracle OrderManagement

An Oracle White PaperOctober 2001

Using Workflow in Oracle Order Management Page 1

Using Workflow in Oracle Order Management

Table of Contents

EXECUTIVE OVERVIEW ..................................................................................... 4

INTRODUCTION..................................................................................................... 4

FUNCTIONAL DIFFERENCES............................................................................. 5

R11I FEATURES...................................................................................................... 6

FLEXIBLE AND EXTENSIBLE ORDER PROCESSES....................................................... 6Order Header and Line WorkFlow processes ................................................... 6Workflow enabling order and line business functions....................................... 7Creating customized workflow activities/sub-processes.................................... 9Process dependencies...................................................................................... 10

AUTOMATED, DEFERRED AND MANUAL TRANSACTIONS...................................... 11INTERACTIVE DECISION SUPPORT AND EXCEPTION HANDLING............................... 12

ORDER MANAGEMENT WORKFLOW STANDARDS.................................. 12

SYNCHRONOUS - IMPLEMENTING A BUSINESS FUNCTION THAT IS AUTOMATICALLYEXECUTED............................................................................................................. 12MANUAL - IMPLEMENTING A BUSINESS FUNCTION THAT REQUIRES USERINTERVENTION. ..................................................................................................... 13DEFERRED - IMPLEMENTING A BUSINESS FUNCTION THAT IS EXECUTED OFF-LINE. 14NAMING CONVENTIONS ........................................................................................ 15

Process Flow................................................................................................... 16Sub-Process..................................................................................................... 16Function Activity ............................................................................................. 16

ACTIVITY RESULTS ............................................................................................... 17DEFAULT ERROR PROCESS.................................................................................... 18ACCESS CONTROL................................................................................................. 18

USING WORKFLOW IN ORDER MANAGEMENT........................................ 18

SET UP................................................................................................................... 18Setup “Order Management WF Administrator” WF item attribute ................ 18Review seeded OM WF data and Define Workflow processes via the WorkflowBuilder............................................................................................................. 19Setup approval notification and OM: Notification Approver.......................... 20Setup Workflow assignments for order/line transaction types ........................ 22Setup the WF background Engine ................................................................... 23

ORDER OR LINE BUSINESS PROCESSES THAT ARE WORKFLOW ENABLED ............... 23Booking ........................................................................................................... 23Scheduling ....................................................................................................... 23


Create Supply .................................................................................................. 24ATO Processing............................................................................................... 24Ship.................................................................................................................. 24Purchase Release ............................................................................................ 24Return Receipt ................................................................................................. 25Fulfillment ....................................................................................................... 25Invoice Interface.............................................................................................. 25Close Order and Close Line ............................................................................ 26

MOVING ORDERS AND LINES FORWARD IN THEIR FLOWS ...................................... 26Synchronous Completion................................................................................. 26Manual Completion......................................................................................... 27Deferred Completion....................................................................................... 28

TRACKING ORDER STATUS .................................................................................... 28Order and Line Summary status...................................................................... 28Workflow Activity Status Page ........................................................................ 29Workflow Monitor ........................................................................................... 30Public Status APIs........................................................................................... 31

WORKFLOW AND OTHER OM FUNCTION AREAS .................................................... 32Cancellations................................................................................................... 32Holds ............................................................................................................... 32Processing Constraints.................................................................................... 32

ERROR HANDLING ................................................................................................. 33Expected Errors............................................................................................... 33Unexpected Errors .......................................................................................... 33

PURGING WORKFLOW STATUS INFORMATION....................................................... 34

CUSTOMIZING ORDER AND LINE FLOWS................................................... 34

GUIDELINES .......................................................................................................... 35EXAMPLES ............................................................................................................ 36CAVEATS .............................................................................................................. 42

CONCLUSION ....................................................................................................... 43

GLOSSARY ............................................................................................................ 44

REFERENCES........................................................................................................ 44

APPENDIX A.......................................................................................................... 45

R11I.2 SEEDED ORDER HEADER/LINE WORKFLOW PROCESSES.............................. 45

APPENDIX B .......................................................................................................... 45

R11I.2 SEEDED WF ITEM ATTRIBUTES ................................................................. 45

APPENDIX C.......................................................................................................... 47

R11I.2 SEEDED UTILITY ACTIVITIES....................................................................... 47

APPENDIX D.......................................................................................................... 48

PROCEDURES AVAILABLE TO QUERY HEADER STATUS.......................................... 48PROCEDURES AVAILABLE TO QUERY LINE STATUS ............................................... 48

APPENDIX E .......................................................................................................... 50

PL/SQL WF WRAPPER FOR THE FUNCTION ACTIVITY “IS THIS A BIG ORDER” ..... 50



Table of Figures

Figure 1a: Generic Order Header Workflow process ..................................5Figure 1b: Generic Order Line Workflow process.......................................6Figure 2: Sub-process that checks Order Totals and sends out a

Notification................................................................................................9Figure 3a: Order Booking sub-process........................................................10Figure 3b: Enter Line sub-process...............................................................11Figure 4: Automatic Scheduling sub-process ............................................13Figure 5: Manual Booking sub- process .......................................................14Figure 6 : Deferred Booking sub-process ....................................................15Figure 7: Return Approval sub-process........................................................21Figure 8: Transaction Types Form................................................................23Figure 9: Progress Order LOV; available from the Sales Order Form....27Figure 10: Order Organizer. Shows Order/Line Status summary ..........29Figure 11: Workflow Status Page, available from the Sales Order Form30Figure 12: Workflow Monitor, available from the Status Page.................30Figure 13 : Line Flow - Standard Items Only..............................................36Figure 14: Book - Order, Manual and Deferred .......................................37Figure 15: Export Compliance sub-process that uses a function activity38Figure 16: Export Compliance sub-process that allows a re-try..............38Figure 17: Export Compliance sub-process that is externally completed39Figure 18: Export Compliance sub-process that handles holds. .............40Figure 19: INCORRECT Flow to support both Order and Return Lines41Figure 20: CORRECT Flow to support both Order and Return Lines ..41



EXECUTIVE OVERVIEWBusinesses seek technologies to increase profitability and enhance competency.They hope to use such technologies to streamline and automate their transactionflows, better manage exceptions and identify non-value added activities.Companies need software systems that can work in dynamic businessenvironments, allow users to control business rules and increase transactionautomation. Such systems not only have to be flexible and but have to also be easyto use.

Workflow technology supports automation and continuous improvement ofbusiness processes. It supports routing information of any type according to user-defined business rules. Business transactions, such as order placements orpurchase requests which involve various controls, routings, and approvals, can bemanaged more efficiently by leveraging Workflow technology. This is the primaryreason why, Oracle Order Management integrates with Oracle Workflow; toprovide users with a comprehensive order processing and fulfillment system.

INTRODUCTIONOracle Order Entry (Release 11 and earlier) includes a feature called Order Cycles.This feature provides the flexibility in setting up different order processes to fitvarious business needs. Today, Order Management has greatly enhanced the ordercycles functionality by replacing Order Cycles with Workflow. The goal is to giveyou the following benefits:

• Flexible and extensible order processing for all industry segments

• Automated transactions for reducing operation overhead

• Interactive decision support and exception handling

This paper attempts to explain functional differences between R11 Order Cycleand R11i Workflow. It also discusses Order Management Workflow features,Workflow standards, setup procedures, various means of processing orders andother useful tips.


FUNCTIONAL DIFFERENCES

In R11i Order Management, Workflow replaces Order Cycles. Order cycles, cycleactions and approval cycle actions are obsolete. Users can define workflowprocesses that determine the series of activities that are executed in an order lifecycle. Such workflow activities replace cycle actions. Workflow notificationactivities replace approval actions. The following table lists how cycle entities mapto workflow ones in R11i:

R11 Entity R11I Entity

Order Cycle Workflow runnable process

Cycle Action Workflow activity, Workflow sub-process

Cycle Action Result Workflow activity result and look up

Cycle Action Prerequisite Workflow Activity Transitions

Approval action Workflow Notification Activity thatrequires a response

Note: Please check the Workflow users’ guide(A85440-01) for detailedinformation on workflow activities, sub-processes, processes, transitions andnotifications.

The following is an example of a generic order header workflow process:

EndEnter Book - Order,Manual

Close - Order

Figure 1a: Generic Order Header Workflow process


The following is an example of a generic order line workflow process:

Figure 1b: Generic Order Line Workflow process

R11I FEATURES

Flexible and extensible order processes

Order Header and Line WorkFlow processes

In R11i, an order and each of its lines follow different workflow processes, unlikeR11 order cycles, where an entire order and all its lines followed the same cycle.

For example in R11i, an order header is entered, booked and then closed. Linesflow through line specific steps after the order is booked, such as scheduling,shipping, invoice interface, etc. Different lines on an order can follow differentline flows, thus completing different activities. This means that return lines andsales order lines can be processed on the same order using different process flows.This can support requirements such as a Car Dealership, who can on a singleorder sell a new car to a customer and accept a trade-in on the customer’s old car.

In R11 Order Entry, you can tailor cycles to your meet order processing needs bydefining approval or custom cycle actions. Adding new approval actions is easy.However adding new custom actions is much harder, since that means you have tointegrate with the obscure C based utilities that help set the status columns andmove the order or line forward. Secondly the number of custom actions orapprovals you can define is limited, since the number of status columns (Scolumns) available is fixed.

Unreserve

Close - LineCreate Supply - Line Invoice Interface -Line

Enter - Line Fulfill - Deferred Fulfill EndSchedule - Line Ship - Line, Manual


Order Management addresses both these drawbacks in 11i, by integrating withWorkflow. Oracle Workflow provides you with the Workflow Builder, a tool thatlets you model your Ordering process, graphically. Secondly there is no limit onthe number of custom function or notification activities you can define.

Order Management provides you with seeded functional activities and sub-processes. Using the Workflow Builder, you can define new function activitiesand notifications. These functional activities, notifications and sub-processesserve as building blocks for creating flows. The product comes seeded with severalorder and line flows. If these seeded flows do not meet your requirements you candefine your own. You can use these for processing your orders and lines, byassigning them to order and line transaction types.

Workflow enabling order and line business functions

If a business function is a workflow enabled, you can control when it is going tooccur by adding the appropriate activity or sub-process into a workflow process.You can also control how it is executed; whether the activity requires userintervention, whether the activity is automatically executed, the activity isexpensive and needs to be executed off-line.

You can find order header or line business functions that are workflow enabled, inthe seeded OM workflow activities or sub-processes. Order Management (OM)comes seeded with the following workflow item types:

OM Order Header (OEOH) - All Order Header level activities and sub-processes,are seeded under this WF Item type. Header flows are started using this itemtype, with the header ID as the Item Key. An order flow is started when an orderheader is created and saved.

OM Order Line (OEOL) - All order line level activities and sub-processes, areseeded under this WF item type. Line flows are started using this item type, withthe line ID as the item key. An order line flow is started when an order line iscreated and saved.

OM Standard (OESTD) - Common functions and lookups are seeded under thisitem type. No flows are started using this item type.

OM Change Order (OECHGORD) - Change Order Notification flows are startedusing this item type.

Some functions are seeded in multiple variants (Synchronous, Manual & Deferred).The following is a list of all the business functions that are Workflow enabled:

Header level functions

Activity or Sub-processname

Equivalent to Cycle Action Concurrent programavailable in R11I


Book - Order, ManualBook - Order, Deferred

Booking No

Close Order Close order No

Header level InvoiceInterface

N/A No

Line level functions

Activity or Sub-processname

Equivalent to Cycle Action Concurrent programavailable in R11i

Schedule - Line

Schedule - Line, Deferred

Demand Interface Yes **

Invoice Interface -Line

Invoice Interface - Line,Deferred

Receivable Interface No

Ship -Line, Manual Pick Release, ShipConfirm and InventoryInterface

Yes, to Pick Release

Fulfill - Line N/A No

Close - Line Close line No

Purchase Release - Line,Manual

Purchase Release - Line,Deferred

Purchase Release Yes

Create Supply - Line N/A No

Create Supply Order - Line

Create Configuration -Line

Create ConfigurationManufacturing Data- Line

Manufacturing Release Yes, to createConfiguration, to createWork Orders.

Return Receiving - Line RMA Interface No

Note: For more details on the sub-process, please refer to the Order or Linebusiness processes that are workflow enabled section, further down in this paper.

** - The seeded sub-processes have been designed such that concurrentprogram will pick up lines that did not schedule due to exceptions (holds,


missing data etc.).

Creating customized workflow activities/sub-processes

Order processes can be dynamic and complex. Companies in different industriesor regions often have different business needs and rules for fulfilling orders.Instead of providing flows and activities to meet every possible business rule andneed, Order Management integrates with Workflow to provide easy customizingcapability.

Oracle Workflow provides a complete set of PL/SQL APIs and public views thatcan be used to make any application function workflow enabled. For example,your business makes a big floor announcement if an order whose total valueexceeds a certain amount, is booked. You can create custom sub-process thatchecks the order total and send FYI notifications to a group of people.

Yes

No

Start End (Yes)Is this a BIG Order? Big Order comingthrough

End (No)

Figure 2: Sub-process that checks Order Totals and sends out a Notification.

The function activity “Is this a BIG Order” checks whether the Order valueexceeds a certain amount (set via an activity attribute). If it does, then itcompletes with a ‘Yes’ and a FYI notification is sent to a certain applicationResponsibility. The Appendix lists the PL/SQL API that the function activitycalls. You can then, this sub-process in a header flow after the seeded “Book -Order, Manual” sub-process and assign it to an Order Type.

The notification activity this sub-process uses is defined to be an FYI notification.That is there is no result type associated with it. However you could also designthis sub-process such that the notification requires a response, i.e. it is an approvalnotification. The sub-process could then meet the requirement where an orderwhose value exceeds a certain amount needs a special approval before it canproceed. To ensure that the lines on the order wait for the approval, you wouldneed to coordinate the order and line flows using the workflow continue-flow andwait-for-flow activities. The following section discusses how you can do that.

Note: Please refer to the Using Workflow in Order Management section for examples ofdefining approval notifications. Refer to the section Customizing Order and Line Flows formore examples of customizations. Refer to the Workflow Users Guide (A85540-01) fordetails on defining Response and FYI Notification Activities).


Process dependencies

Oracle Workflow provides utilities to build dependencies between parent and childworkflow processes. With respect to orders and lines, the followingdependencies come to mind:

Example: Order lines should wait for the order to book before progressing in theirindividual Line flows.

Example: All order lines should close, before the order header closes.

Order Management creates all order flows are created as parent flows. Line flowsfor the lines on an order are created as child (detail) flows.

Native WF utilities “Wait For Flow” and “Continue flow” are used to support thiskind of order(parent) - line(child or detail) coordination. So to coordinate ordersand lines for Booking; The “Continue Flow” (Book - Continue Line) activity isincluded as part of the Order Booking Sub-process (Figure 3a.). It is configured(via activity attributes) to continue the line activity that is waiting for the order tobook. The “Wait For Flow” (Wait for Booking) activity is included in the “Enter- Line” sub-process in the line flow (Figure 3b). It is configured (via activityattributes) to wait for the “Continue Flow” inside the seeded booking process.This ensures that the line flow waits for the header level booking sub-process tocomplete.

Complete

Not Eligible

On Hold

Incomplete

Book - Continue LineBook - Eligible Book End (Complete)Start

Figure 3a: Order Booking sub-process


Wait for Booking EndStart

Figure 3b: Enter Line sub-process

You may need similar coordination for other business functions.

Example: All order lines should wait for a custom order level Legal Approval tocomplete before progressing in their individual Line flows.

To support that, you would also need to use these Wait-for-flow and Continue-Flow activities and configure them based on your custom approval activity(Notification).

Note: Please Refer to the Workflow Users Guide (A85540-01) for details on usingcoordination activities.

Automated, Deferred and Manual TransactionsWorkflow activities can be executed automatically by the Workflow engine.Instead of users pulling orders by running batch processes, the Workflow enginecan push orders forward. This is called “synchronous” or “automatic” executionmode.

As opposed to the synchronous mode, a workflow activity can be set to requireuser intervention. We call this “manual” execution mode. A workflow activitycan also be set-up to be executed by the Workflow background engine in order tosave on-line transaction time. This is called “deferred” execution mode.

Automatic and deferred modes are natively supported by Workflow. OrderManagement additionally gives you the manual mode for more flexibility.

For example, if you use the seeded “Schedule- Line” sub-process (Figure 4) in aline flow, an order line automatically schedules after the order header is booked.You can setup an expedited order process where several activities are performed


sequentially (synchronously) without user intervention.

If you use the seeded “Book - Order, Manual” sub-process (Figure 5) in a headerflow, the order will book only when the user requests to book an order (byclicking the “Book” button OR via the Progress Order LOV in the R11I SalesOrder form).

If you use the seeded “Book - Order, Deferred” sub-process(Figure 6) you do notneed to explicitly request for the order to book. Rather the order will book whenWorkflow Background Process concurrent program will processes the deferredactivity. (See Setup Workflow Background Engine in later section).

In the Order Management Workflow Standards section, we discuss how toimplement business functions in synchronous, deferred, and manual modes.

Interactive decision support and exception handlingNotification functionality is new in R11I and can be used for handling businessexceptions and approval requests. As described before, you can setup anotification that requires a sales manager’s approval when booking orders over acertain dollar amount. The role assigned to the Notification Performer,determines whom the notification is sent to.

By default, users can view their own notifications in Order Management. The“Notifications” menu entry in the Order Management Menu launches theWorkflow Notification Viewer Web Page. Users can setup the Workflownotification viewer to view notifications using a web interface or receivenotifications as e-mails in plain text.

Note : Please refer to Setup approval notification and OM: Notification Approver inlater section for details on notification features.

ORDER MANAGEMENT WORKFLOW STANDARDS

Most Order Management functions are seeded in one or more variants(Automatic/Synchronous, Manual or Deferred). The following section discusseshow these variants are designed.

Synchronous - Implementing a business function that is automaticallyexecuted.

In a synchronous mode, the function executes automatically. That is, it requiresno User intervention.

Example - The seeded “Schedule - Line” sub-process.


Not Eligible

Complete

IncompleteOn Hold

EndScheduleStart

Schedule - Eligible

End

Figure 4: Automatic Scheduling sub-process

If you create a Line that uses a flow with this Scheduling sub-process, then theLine will schedule as soon as the Order books. If Scheduling cannot completedue to Holds or other expected errors then the flow will transition to the Schedule-Eligible activity. You can run the Schedule Order Concurrent program to re-process such lines or complete them via the Progress Order LOV on the SalesOrder Form.

Manual - Implementing a business function that requires userintervention.

To enable a function to be completed manually, you need to place special blockactivity before the actual function activity. This special block activity needs to callthe function OE_STANDARD_WF.STANDARD_BLOCK and NOT theWF_STANDARD.BLOCK. This ensures that Orders or Lines awaiting at thisspecial activity shows up in the Progress Order LOV, in the Sales Order Form.

We recommend that you follow the following naming conventions to name thisspecial block activity:

Internal Name - “FuncName_ELIGIBLE” (eg: BOOK_ELIGIBLE)

Display Name - “Function Name - Eligible” (eg: Book - Eligible)

Example - The seeded “Book - Order, Manual” sub-process.


Complete

Not Eligible

On Hold

Incomplete

Book - Continue LineBook - Eligible Book End (Complete)Start

Figure 5: Manual Booking sub- process

The “Book - Eligible” activity calls the function OE_STANDARD_WF.STANDARD_BLOCK. If you create an Order with an Order Type that uses thisBooking sub-process in its Header flow, it’s flow will stop at the “Book -Eligible” activity. The Progress Order LOV on the Sales Order Form will showyou that this order is eligible for Booking. You can book such an order either byclicking ‘OK’ button on the LOV or by clicking the “Book” button on the SalesOrder Form.

Deferred - Implementing a business function that is executed off-line.

Oracle Workflow lets you associate a cost to a function activity. This refers to theprocessing time it takes to execute that activity. Generally, you should assigncomplex, long running activities a high cost. In normal processing, the WorkflowEngine completes the execution of a single activity before continuing to asubsequent activity. In some cases, an activity might take so long to process thatbackground processing would be more appropriate.

The default threshold for the Workflow Engine is 50 hundredths of a second.When a flow comes across an activity whose cost is higher than the threshold, it isdeferred to the background.

Cost can also be relative in terms of the business flow that is being executed. Forexample; you have a few Order Entry clerks who are dedicated to taking ordersfrom habitual, long time customers. Since you have all the standard informationfor these customers already set-up, you would rather that the order is entered asquickly as possible into the system and the clerk not have to wait for it to book,before he can move on to the next order or customer. So in this case you wouldwant the booking process to be deferred.

Now on the other hand, you have some other Order Entry clerks who deal withnew first-time customers. In this case, you want the order to be booked onlineso that the clerk can if required get additional information from the Customer orinform him about credit check related issues.

To give you such flexibility, Order Management uses the Workflow APIWF_ENGINE.Defer_Thread to defer a flow to the background. That is instead


of defining an activity to be a high cost one, it gives you variants of businessfunctions that are deferred and those that are not. This gives you a lot moreflexibility in designing your flows.

Thus you could use the seeded “Book - Order, Deferred” sub-process forprocessing orders from longtime customers, but use the seeded “Book - Order,Manual” sub-process for processing orders from new customers. Note that boththese sub-processes use the same “Book” function activity.

The naming convention followed for activities that call theWF_ENGINE.Defer_Thread is as follows:

Internal Name - FunctionName_DEFER (e.g.: BOOK_DEFER)

Display Name - Function Name - Deferred (e.g.: Book - Deferred)

Example - The seeded “Book - Order, Deferred” sub-process

Complete

Not Eligible

IncompleteOn Hold

Book End (Complete)Start Book - Continue Line

Book - Eligible

Book - Deferred

Figure 6 : Deferred Booking sub-process

In this sub-process, the activity “Book -Deferred” calls the WF APIWF_STANDARD.DEFER_THREAD to defer the flow to the background.When the Workflow Background Engine picks up this deferred flow, it executesthe “Book” activity, thus booking the order.

Naming ConventionsOrder Management follows certain naming convention for creating WF processes,sub-processes, activities, etc. It is not necessary that you follow the sameconventions. However doing so, will make all OM WF data (seeded and custom)appear consistent to the end user.

Here, we discuss only the “display name” naming conventions. Unlike internalnames, display names can be changed after Workflow data is created. Users can


see these display names in both Workflow builder and in the Workflow monitorwhen viewing the order or line status. For “internal name” naming conventions,please refer to Order Management User Guide.

Order Management follows the following naming convention for “DisplayNames”:

Process Flow

Format: Order/Line Flow - XXX

e.g.

Name Description

Order Flow - Generic Generic order header flow that can go withany line flow for standard item, model, return.

Order Flow - Generic, withheader level invoicing

Generic order header flow that includesheader level invoice activities.

Line Flow - Generic Generic sales order line flow that supports allitem types except the Configured Item.

Line Flow - Return for creditonly

Return line flow for issuing credit only.

Sub-Process

Format: Function - Order/Line, Manual/Deferred

e.g.

Name Description

Book - Order, Manual Automatic booking header level sub-process

Book - Order, Deferred Deferred booking header level sub-process

Invoice Interface - Line Automatic Invoice Interface line level sub-process

Function Activity

Format: Function - Eligible/Deferred/Continue/Wait

e.g.

Name Description

Book The actual booking function activity

Book - Eligible Booking eligibility block

Book - Deferred Activity to defer Booking


Book - Continue Line Booking coordinating activity to continue the waitingline flows

Wait for Booking Line coordinating activity that waits for the Order toBook.

Activity Results

Most Order Management function activities use the standard seeded lookup “OMSub-Process Results, handles Holds”. This lookup has the following resultcodes: Complete, Incomplete, On Hold, Not Eligible.

A function activity completes with the “Complete” result when it executessuccessfully. E.g.: When the seeded “Book” function successfully books an order,it will complete with a “Complete” result.

A function activity completes with the “Incomplete” result when it runs intoexpected errors that it is built to handle. The “Incomplete” result normallytransitions to an “Eligibility” block or a Wait Activity. E.g.: When the seeded“Book” function finds that the order header does not have a Customer specified,it will complete with an “Incomplete” result and transition to the “Book -Eligible”activity. You can then provide the missing information and attempt to re-bookthe order via the “Book” button or the Progress Order LOV.

A function activity completes the “On Hold” result when it runs into a generic oractivity specific Hold. The “On Hold” result normally transitions to an“Eligibility” block or a Wait Activity. E.g.: When the seeded “Book” functionfinds that there is generic hold on the order, it will complete with an “On Hold”result and transition to the “Book -Eligible” activity. You can then provide themissing information and attempt to re-book the order via the “Book” button orthe Progress Order LOV.

A function activity completes with the “Not Eligible” result when it does not makesense for the Order Header or Line to be processed by a that activity. E.g.:When the seeded ‘Schedule” activity processes a Service Item Line, it completeswith a “Not Eligible” result and transitions to the end of the scheduling sub-process.

It is important to note, that only on a successful completion (Complete or NotEligible result) of a business function, does a flow exits out of the respectivefunctional sub-process. Hence most function high-level sub- processes (thosethat can be used in runnable flows) use the seeded lookup “OM Sub-ProcessSuccess Results”. This lookup has the result codes: Complete, Not Eligible.

All seeded flows are built using the “Default” transitions to move a flow forward,as opposed to having separate transitions for the “Complete” and the “Not


Eligible” results. The assumption being that in either case the sub-process hascompleted processing and the flow can move forward.

Default Error ProcessAll Order Management seed WF data is defined to use the “Retry Only” errorprocess. This process determines the notification flow that Oracle Workflowstarts when a workflow activity runs into an unexpected error.

When you create any new OM WF data, you should specify this error process asthe default. If you do not specify an error process, then Oracle Workflow doesnot start a notification flow in case the activity runs into an unexpected error. Ifyou specify a default error process other than “Retry Only”, the user who receivesthe error notification has the option of skipping or aborting the errored activity,this can result in data corruption. Order Management does not support youspecifying a default error process other than “Retry Only” error process.

Note: Please refer to “Handling Errors” section for details on how unexpected errors are handled.

Access ControlAll Order Management seed WF data is locked at the access level of 20. Youshould be working at an access level of 100. To customize, you can make copiesof the seeded processes and then make the necessary modifications.

The following data is not locked:

• Item Attribute - OM WF Administrator

• Message Bodies

USING WORKFLOW IN ORDER MANAGEMENT

Set upHere are the things you need to do before using Workflow with OrderManagement:

• Setup “Order Management WF Administrator” Workflow item attribute

• Review seeded OM WF data and define Workflow processes via theWorkflow builder

• Setup approval notifications and OM: Notification Approver

• Setup Workflow assignments for order/line transaction types

• Setup the WF background Engine

Setup “Order Management WF Administrator” WF item attribute


You need to assign a responsibility (role) to the Order Management Workflowitem attribute “Order Management WF Administrator” for unexpected errorhandling. An order progressing along a flow can run into unexpected errors(Rollback segment errors, Data integrity errors etc).

Whenever an unexpected error occurs, a notification is sent (please refer toWorkflow error process in Workflow User’s Guide) to the responsibility assigned to“Order Management WF administrator” item attribute. The WF activity thatgenerated the error is marked to be in an error state.

You can set this item attribute via the WF builder. The item attribute is availablefor Order Management Workflow items OEOH (OM order header), OEOL (OMorder line) and OECHORD (OM Change Order) and needs to be set for all three.The item attribute is set to have a default value of SYSADMIN.

In the Workflow builder, click on any of the OM Workflow items (OEOH,OEOL or OECHORD). Under the “Attribute”, find “Order Management WFadministrator”. Right click on it and select “Properties” to open the propertieswindow. In the “Attribute” tab, there is a “Default” region. Assign aresponsibility in the “Value” field. If you can’t see any other responsibilities in theLOV, you’ll need to load roles from the database by going to the menu bar “File”and select “Load roles from database”.

Note: Please refer to the section Error Handling on details on how errors are handled.

Review seeded OM WF data and Define Workflow processes via the Workflow Builder

Before you can process orders in Order Management, you need to setup the orderheader/line workflow processes, just like you setup order cycles in R11 OrderEntry. Order Management comes with several seeded order and line workflowprocesses. We recommend you do the following:

1. Review the seeded flows, activities, notifications, etc. Check whether theseeded data meets your business needs.

2. Create custom activities, notifications, and any other components needed tobuild flow processes to meet your specific business requirements.

3. Use the seeded runnable flows as examples to create your own flows, usingseeded and/or custom sub-processes/activities. OR Copy a seeded workflowprocess to create a new workflow process and modify this newly, copiedworkflow process according to your business requirements.

Suggestion: You can build few complex flows to accommodate various businessscenarios. Or you can build several simpler flows to handle the different businessprocess needs and use them appropriately via Transaction Type WorkflowAssignments. You need to balance performance with user convenience. Since acomplex flow will have more condition checking and branching to handle variousscenarios, the performance cost will be higher. However, the down side of


creating many simpler flows is that it relies on user to pick the right OrderType/Line Type when entering orders.

Note: Please see the Appendix for seeded R11i.2 workflow processes.

Setup approval notification and OM: Notification Approver

Workflow Notifications in R11I replace R11 Approval functionality. To supportthe Approval requirements, you need to define Notification Activities that requirea response. When an order or line flow comes across such an activity, the WFEngine will send out a notification to the approver and request a response. Theapprover can either approve, decline, or forward the notification to anotherapprover.

In R11 Order Entry, any user who had access to “Approve Orders” form couldperform an approval. In R11i Order Management, there are a couple of ways youdetermine who gets an Approval Notification :

• When you add the notification activity to a workflow process, set the“Performer” to be of type “Constant” and assign a value (WF Role) to it. Thisis a static approver for this notification for any order or line using thisworkflow process. That is such a notification will always go to the samerecipient (WF Role).

• When you add the notification activity to a workflow process, set the“Performer” to be of type “Item Attribute” and assign the value “NotificationApprover” to it,. In this case, the responder of the notification is the valueindicated by the “NOTIFICATION_APPROVER” Workflow Item attribute.

(With R11i.2) When an order or line is created, this WF item attribute is set basedon the value of the Profile Option “OM: Notification Approver”. When thenotification is sent, the recipient is derived based on the value of the “NotificationApprover” item attribute. This means that the same notification can go todifferent recipients for different orders/lines.

You can also set the value of this Workflow item attribute dynamically based onone of the following values: “OM: Notification Approver” profile option value,“Created By” of the order or line. To do this, you place the seeded orderManagement Workflow utility “Set Notification Approver” in a workflow processbefore the notification activity.


Passes

Fails

Start Approve ReturnOrder

End (Complete)Approve - ContinueLine

End (Incomplete)Approval Failed

Utility - SetNotification Approver

Figure 7: Return Approval sub-process

You then need to set its activity attribute “Source” to one of the following: ProfileApprover, Created By, Order Created By. When this activity is executed, it willdynamically set the WF Item Attribute “Notification Approver” for that Order orLine to the appropriate role value. And the notification will be sent to that role.

• You could define custom activities that dynamically determine who theApprover is. We recommend that you use the Notification Approver Itemattribute as a place holder to store such a value, as opposed to definingadditional item attributes. Again the responder on the Notification Activitywould default from the Notification Approver Item attribute.

When defining notification message bodies, you can use the following seededOrder Management Workflow item attributes to provide context:

• Header Short Descriptor - This returns the order type and order number.

• Line Short Descriptor - This returns the order type, order number, and linequadruplet (Line number, shipment number, option number, service number).

You can use these as default values for your message attributes and then use themessage attributes in the body of the message.

e.g. This return order (&RMA_HDR_SHORT_DESCRIPTOR) requires yourapproval.

In this example, the message attribute RMA_HDR_SHORT_DESCRIPTOR hasthe WF item attribute “Header Short Descriptor” as its default value.

Again you can define additional item attributes, set them using custom functionactivities and use them for message context. However note that having too manyworkflow item attributes defined can deteriorate performance, since a databaserow is created for the order or line for every item attribute defined.

You can use the seeded “Approval Failed” block defined under OM: Standard(OESTD) to manage failed approvals. Transition failure results to this block to


ensure that the flow does not progress any further. You can then manually cancelthe Order or Line that failed the approval.

Setup Workflow assignments for order/line transaction types

Note: Please refer to the Transaction Types White Paper for detailed information on definingTransaction types and setting up workflow assignments .

Now, how do you get an Order or a Line to start a particular workflow process? -by setting up workflow assignments for Order and Line transaction types. This isvery similar to associating order cycles to order types in R11 Order Entry.

In R11i, in addition to order types, you have line types. Both order and line typesare setup using the Transaction Types form. When you define an order type, youneed to assign a header workflow to it. E.g. You set up a “Standard” order Type.You can assign the seeded “Order Flow - Generic” to it. Now if you create anorder with the “Standard” order type. The order header will start a flow using the“Order Flow - Generic” workflow process.

Since each line follows its own flow, you also need to setup workflow assignmentsat the Line Type level. Line level workflow processes are assigned based on anorder type, line type, and item type combination. You have to do the following:

1. Setup Line and Order Types in the Transaction Type form

2. Query up a particular Order Type

3. Click on the “Assign Line Flows” button

4. Assign a line workflow process for a combination of Order type, Line type,and Item type. If you leave item type field empty, any type of item will be ableto use this line flow assignment.

E.g. If you setup the following assignment:

Standard Order Type + Standard Line Type + Standard Item -> Line Flow -Generic

When you create an Order using the Standard order type, add a Line using theStandard line type for a standard item, it will start a flow using the Line Flow -Generic workflow process.


®

12

Figure 8: Transaction Types Form

Setup the WF background Engine

The Workflow Background Engine processes deferred activities, wait activities andtimed out activities. You need to schedule the “Workflow Background Process”concurrent program to re-submit periodically. When scheduling the concurrentprogram, please specify Order Management work item types as parameter so that itonly picks up activities specific to Order Management work items.

Note: Refer to the Oracle Workflow Users Guide (Part Number A85440-01) forinformation on the Workflow Background Engine.

Order or Line business processes that are workflow enabled

Booking

In R11i, Booking an Order is workflow enabled. You can book an order invarious ways. You may decide to use the “Book - Order, Deferred” process forcertain kinds of Orders and the “Book - Order, Manual” for certain others. Youcan also create you own Booking process that say, lets you control when the Orderbooks, but defers it to the background. You can also add an order-level approvalbefore the Booking process in a header flow.

Order Management uses native WF co-ordination activities to ensure that orderlines wait for the order to book before progressing. A seeded sub-process “Enter- Line” is provided at the line level; this is configured to wait for the seededBooking function to complete before progressing (figure 3).

Scheduling


In R11i, the Scheduling function allocates supply to your demand and makes theOrder line visible to MRP (as demand). Order Management provides twovariations on Scheduling, one where it is performed synchronously and anotherone where it is deferred. In both cases exceptions are routed to the “Schedule -Eligible” block activity. You can progress lines that are at this activity using theSchedule Orders Concurrent program or the Progress Order LOV. You couldalso define your own custom sub-process, such that Scheduling can only be donevia the concurrent program (by placing the “Schedule - Eligible” activity before the“Schedule” activity).

Note: Please refer to the Scheduling White Paper for more details.

Create Supply

The seeded “Create Supply” sub-process has the intelligence to route Order Linesdifferently based on the item type and whether they are internally or externallysourced. You need to use this sub-process when defining line flows that need tosupport different types of items. For example, it branches ATO model linesthrough the Create Configuration process; or branches externally sourced lines tothe Purchase Release process.

Note: The “Create Supply” sub-process can handle all kinds of lines except theConfigured Item Line.

ATO Processing

The entire ATO process is now workflow enabled. There are various seeded sub-processes to support functions such as creating the configuration item, the BOM& routings, calculating lead time and rolling-up cost, creating the work order, etc.The processing needed for handling the configuration item is separated out fromthat for the ATO Model.

The seeded “Line Flow - Generic” can handle all kinds of lines except theConfigured Item Line. The seeded flow “Line Flow - Configuration” supportsprocessing for Configured Item Lines.

Ship

The functionality provided by the cycle actions of Pick Release, Back OrderRelease, Ship Confirm and Inventory Interface is now delivered via the seeded“Ship - Line, Manual” sub-process. Each of the shipping functions are notWorkflow enabled in R11i. In fact the “Ship” activity is a block activity that waitsuntil the line is picked, shipped and interfaced to Inventory and Shippingcommunicates that information to Order Management.

One a Line hits this block activity, you need to manually pick and ship the lineusing the Shipping transaction forms.

Purchase Release


The seeded Purchase Release sub-process interfaces information to Purchasingwhen order lines need to be drop-shipped. This process has been seeded in twovariations:

“Purchase Release - Line, Manual” - This needs manual intervention. You canPurchase Release the Line either via the Progress Order LOV from the SalesOrder form or by running the Purchase Release Concurrent Program.

“Purchase Release - Line, Deferred” - This defers the Purchase Release activity tothe background. When the WF Background Process Concurrent Program is run itpicks up such deferred activities and processes them.

Return Receipt

The RMA Interface concurrent program is obsolete in Order Management. TheReturns receipt and acceptance function is workflow enabled using block activities.Returns are received using the Oracle Purchasing Receipt functionality.Purchasing looks at a view based off Return Lines to determine what is eligible tobe received. It then communicates information to Order Management regardingreceipt and acceptance against those lines.

Fulfillment

In R11 Order Entry the Receivables Interface Concurrent program had built-inintelligence to not interface lines that were not “fulfilled”. Example: The ATOModel, Class and Option lines would not interface to Receivables until theConfigured item was shipped.

Order Management enhances this functionality of “Fulfillment” and separates itfrom the function that interfaces to Invoicing. Ship-confirmation, PurchaseRelease Receipt and Returns Receipt are supported as fulfillment events, out of thebox. Fulfillment is also workflow enabled and the seeded “Fulfill” activityensures that lines do not move forward in their flows until they are fulfilled. Youcan define your own fulfillment sets and put Lines in them. The fulfillmentfunctionality will ensure that they all go past the “Fulfill” activity together. ATOand PTO configurations are viewed as native fulfillment sets by the application.

When you define custom line flows, ensure that you configure the “Fulfill”activity appropriately by setting its activity attributes.

Invoice Interface

The Receivable Interface concurrent is obsolete in. The seeded “Invoice Interface- Line” sub-process interfaces line information to Invoicing.

Order Management also provides the means to interface all lines on an Order toInvoicing at the same time via the seeded sub-process “Header level InvoiceInterface - Order”. You can use the seeded Order Flow “Order Flow - Genericwith Header Level Invoice Interface” along with the seeded Line Flow “LineFlow - Generic with Header Level Invoice Interface” to interface the entire order


to Invoicing.

It is important to note that the creation of the invoice is still controlled by theAuto Invoice concurrent program. You need to setup Invoicing Grouping Rules ifyou want to create one invoice for the entire order.

The application still supports Invoicing only after Shipping. There is nothing toprevent you from a creating a workflow process that interfaces to Invoicing beforethe Line is shipped. However if a line using such a flow is partially shipped,Invoicing data will be pointing only to the original line. Secondly various seededconstraints go into effect one a line is Invoice interfaced, Eg.: You cannot cancela line once it is interfaced to Invoicing. This will prevent you from canceling a linethat is not yet shipped. You would also need to resolve legal issues if any withrespect to recognizing revenue before the product is shipped.

Close Order and Close Line

The Close Orders Concurrent program is obsolete in R11i. Closing Orders andLines is workflow enabled. The seeded “Close - Order” sub-process uses nativeWF co-ordination activities (wait for Flow) to ensure that the order header closesafter all the lines have closed. It is designed to close the order at the end of themonth.

The seeded “Close - Line” closes the line and uses the native WF activityContinue-Flow to communicate to the waiting header Close process

Note: The Service Interface Concurrent Program is obsolete with R11i. OrderManagement calls CRM APIs whenever an Order is created or updated.

Note: Please refer to the Sales Order Overview White Paper on more details on the variousproducts that Order Management integrates with.

Moving Orders and Lines forward in their flows

How do you progress an order or line along its flow? As we said before, there arethree modes in which business functions could be executed: Synchronous,Manual or Deferred.

When an order (or line) is created, the application starts a header (or line) flow forit. The Workflow engine will push the order/line ahead as long as the activities aresynchronous. The flow stops when it hits block activities, notification activitiesor wait activities. The flow gets deferred to the background when it hit a high-cost activity or an activity that explicitly defers the flow to the background.

Synchronous Completion

In this mode, once a flow is started or re-started (after it has stopped) the WF


activities are executed synchronously or online until it reaches the end of the flowor reaches some kind of a block activity or is deferred.

Example - You create a line that uses the seeded “Line Flow - Generic”. This hasthe seeded “Schedule - Line” sub-process (Figure 5). Provided that there are noholds, once the order is booked, the line will automatically go ahead and schedule.The flow will then continue on stop at the “Ship” activity, making the line eligiblefor Pick Release.

Manual Completion

If the order/line hits an “Eligibility Blocks” like the one we discussed in thesection on “Implementing a “manual” function in Order Management”, then youcan move the order/line forward via the Progress Order LOV (Can be accessedfrom “Action” button). This LOV displays the functions that the order or line iseligible for (and can be manually completed).

The following (Figure 9), shows the case where an order is eligible for Booking.That is the flow for that order, uses the seeded “Book - Order, Manual” sub-process (Figure 4). The order is currently stopped at the “Book - Eligible” block.The Progress Order LOV displays that the order is eligible for Booking. ClickingOK on the LOV, will trigger completion of the “Book -Eligible” block, the flowwill move to the “Book” activity and execute it, thus booking the order.

®

20

Figure 9: Progress Order LOV; available from the Sales Order Form

Some seeded “Eligibility Blocks” can be completed en-masse by running thefollowing concurrent programs:

Schedule Orders

Purchase Release


AutoCreate Configuration Items

AutoCreate Final Assembly Orders

Some other block activities can be completed by performing certain specificactions.

Thus if a line is waiting at the “Ship” activity, you have to Pick Release the lineand then Ship Confirm it to move it forward. If a return line is stopped at the“Wait for Receiving” activity, you need to receive the goods against that returnline (and accept them) to move it forward.

If a order or line flow stops because it is awaiting a user response on a NotificationActivity, then you need to respond to the Notification to re-start the flow.

Deferred Completion

A order or line flow can also stop because the flow was deferred to theBackground Engine. Example: You create an order that uses a flow that has theseeded “Book - Order, Deferred” sub-process (Figure 6). When the flow reachesthe “Book - Defer” activity, the Order flow is deferred to the background. Youneed to run the Workflow Background Engine Process concurrent program topick up such deferred flow and process them.

Fulfillment is deferred in all the seeded line flows. You need to schedule theWorkflow Background Engine Process concurrent program to run at periodicintervals to be able to fulfill and invoice interface lines. The WorkflowBackground Engine also processes Wait activities and Timed-Out activities.

Tracking order statusR11 Order Entry tracks cycle status via the S and S Date columns on OrderHeaders and Lines. In R11i Order Management workflow status is storedWorkflow entities; in WF_ITEM_ACTIVITY_STATUSES andWF_ITEM_ACTIVITY_STATUSES_H tables. The Workflow Engine maintainsstate information and history for work items (orders & lines) in these tables.Some core status information (Booking, Open/Close, Fulfillment etc) is de-normalized onto the base Order Management entities.

So how do you know where an order or line is in its flow? There are a couple ofways:

Order and Line Summary status

The status field on order and line tabs in the Sales Order form and OrderOrganizer, shows where an order or line is in its flow.

The header status displays one of the following values based on where the order


header is in its flow: Entered, Booked, Closed or Canceled.

The line status displays one of the following values based on where the order lineis in its flow: Entered, Booked, Awaiting Shipping, Awaiting Receipt, PickedPartial, Picked, Shipped, Received, Awaiting Fulfillment, Fulfilled, InvoiceInterfaced, Invoice Interfaced Partial.

Status for the Configuration Line will additionally show the following information:BOM and Routing Created, Config Item Created.

Status for configuration and ATO Item lines will additionally show: ProductionEligible, Production Open, Production Partial, Production Complete, dependingon where the line is in its line flow.

Figure 10: Order Organizer. Shows Order/Line Status summary

Workflow Activity Status Page

You can also launch the Workflow Status page from the “Tools” menu from theSales Order Form/Order Organizer. A Browser window is launched to displaythe Workflow status history in a tabular format.. It displays detailed informationon when an activity was completed, which activity is currently active etc. Youcan use filters on this page to only view status information for certain kinds ofactivities (eg: Response Notifications, FYI Notifications, Functions etc.).


Figure 11: Workflow Status Page, available from the Sales Order Form

Workflow Monitor

From the Status Page, you can launch the Workflow Monitor, via the “ViewDiagram” button. This gives you a graphical representation of where an order orline is in its flow. The progress of flow is highlighted in green. You can selectindividual components of the flow, and the tabs at the bottom will displayinformation about the selected activity/sub-process. You can also zoom in/outof sub-processes using the buttons in the right-hand corner.

Figure 12: Workflow Monitor, available from the Status Page


Public Status APIs

Order Management also provides you with Public PL/SQL APIs to query orderand line workflow status.

The package OE_HEADER_STATUS_PUB provides status information fororder headers for Booking, Cancellation and Close status.

The package OE_LINE_STATUS_PUB provides status information for OrderLines for Cancellation, Configuration Creation, Close, Drop-Ship Receipt,Fulfillment, Invoice Interface, Pick Release, Return Receipt, Scheduling,Shipping and Work Order Management.

These APIs are overloaded with the following generic signature:

GET_FUNCTION_STATUS (ENTITY_ID IN NUMBER, STATUS OUTVARCHAR2)

GET_FUNCTION _STATUS(ENTITY_ID IN NUMBER STATUS OUTVARCHAR2, DATE_COMPLETED OUT DATE)

Where FUNCTION stands for the actual function that you are querying statusinformation for. ENTITY_ID stands for either HEADER_ID or LINE_IDdepending on whether the functions is returning order or line status information.You need to pass to the API the HEADER_ID or LINE_ID for the order or linethat you are querying status for.

These APIs allow you to retrieve status information or status and date(when thefunction was completed) information for a order header or line. The APIs returna ‘Y’ when a order or line has completed a specified business function, a ‘N’ whena order or line has not completed a specified business function and a ‘P’ when aorder or line has partially completed a specified business function (eg: InvoicedInterfaced partial on account of unfulfilled Required for Revenue components).

Example - To check whether a certain order is booked, you can call the bookingstatus API as follows:

OE_ORDER_HEADER_PUB.GET_BOOKED_STATUS(12345,

l_result);

In this case the header_id for the order whose booking status you are querying is12345. L_result is declared as a variable of type VARCHAR2.

If the order is booked, then after this call, l_result will have a value of ‘Y’, if theorder isn’t booked then l_result will have a value of ‘N’.

If you wanted to query both the booking status and the date the order was booked,you can call the booking status API as follows:

OE_ORDER_HEADER_PUB.GET_BOOKED_STATUS(12345,


l_result, l_result_date);

If the order is booked then the l_result_date will indicate the date the order wasbooked on.

Note: Please see the Appendix for a listing of Procedures.

Workflow and other OM function areas

Cancellations

Cancellations is not workflow enabled in Order Management. However when youfully cancel an order or a line, its flow is stopped and transitioned to the CloseOrder or Line activity. The order or line summary status will indicate the orderor line is canceled.

Holds

In R11 Order Entry, you cand define generic or cycle action specific holds. Cycleactions honor both kinds of holds. This is carried forward in Order Management,you can define and apply generic or activity specific Holds (based on workflowactivities). Header and line flows honor both kinds of holds. A flow that comesacross a hold does not proceed unless that hold is removed.

Example: You cannot Book an order that has a generic order level hold or aBooking specific hold. The Book activity posts messages indicating that a holdexists. It then completes with an “On Hold” result and transition back to the“Book - Eligible” activity.

You can define custom workflow activities that honor holds. Order Managementprovides Public APIs (OE_HOLDS_PUB) that can apply holds, check whetheran order or line is on hold and remove holds. You can also seed lookups(Holdable Header Activities, Holdable Line Activities) based on your customworkflow activities and define holds based on them.

Processing Constraints

In R11 Order Entry you can define security rules based on cycle actions. In R11iOrder Management, the Processing Constraints Framework provides you withenhanced security rules functionality. You can define processing constraints basedon flow state or custom PL/SQL APIs. The application checks constraints beforeevery update/delete/insert operation. If the Constraints are status based, theframework logic looks at WF status tables or status information de-normalizedonto the base Order Management entities. The product comes seeded withvarious constraints and you can define additional constraints.

Example: Cannot delete an Order Line, once the Order is booked,

Example: Cannot change quantity, once Line is past some custom approval.


Since the Processing Constraints Framework looks at Workflow status tables, youcan define constraints based your custom activities as well.

Error handlingThere are two kinds of errors that Order and Line flows can run into; Expectederrors and Unexpected errors.

Expected Errors

These are errors that business processes expect to run into and handle.

Example: Booking requires that a Customer is specified on the Order. If youattempt to Book an Order that does not have a Customer specified, theapplication will display an appropriate message and the Order will not book. Theseeded WF activity “Book” will complete with an “Incomplete” result.

When an activity is completed via the Sales Order Form, i.e the activity issynchronous or is manually completed via the Progress Order LOV, theProcessing Messages window pops up to display messages that indicate the errors.

When an activity is processed by the Background Engine, i.e the activity isdeferred, these error messages are stored in the Order Management processingmessage table. You can view these messages via the Processing Messages windowusing either the Concurrent Program request number, or the Workflow activity(Book) and/or by Order or Line Basis.

When an activity is completed via a concurrent program, its output file lists all theerror messages that were posted.

Unexpected Errors

These are errors that a business process does not expect under normalcircumstances. Eg: Database errors such as running out of rollback segments,Data integrity errors.

In this case, the activity errors out and Oracle Workflow starts the default errorprocess - “Retry Only”. This is seeded WF error process. T he activity that raninto the unexpected error gets marked with an ‘Error’ status (inWF_ITEM_ACTIVITY_STATUSES) and a notification listing the details is sentto the role specified in the “OM Workflow Administrator” item attribute.

Once the problems have been corrected the administrator can choose the ‘Re-try’option on the notification and complete it. This triggers a retry of the erroredactivity. The Administrator can also choose to retry the activity from theWorkflow Monitor.


Note: Refer to “Setup Order Management WF Administrator WF item attribute” sectionon how you can set this WF Item attribute.

Purging Workflow Status Information

Oracle Workflow provides a Concurrent program that lets you purge workflowstatus information for flows that have completed. If the high volume ofworkflow status information is affecting performance negatively, you can run thisConcurrent program to delete WF status history data for Closed Orders (and theirclosed Lines) whose flows have completed. Do remember, to specify a value (indays) for the "Age" parameter, the program only purges those flows thatcompleted

before the number of days specified.

However if you run this concurrent program, you should be aware of thefollowing:

• You will no longer be able to view Workflow status information for suchorders.

• Most of the core Order Management status information (like open, booked,fulfilled etc) is de-normalized onto the base OM entities. Most seededprocessing constraints work off these base columns. Seeded constraintsprevent you from updating Orders/lines that are closed. However if you haddefined custom constraints based off workflow activity statuses, they wouldno longer apply (since the WF status information is deleted).

• Many OM Public Status APIs look at Workflow tables to return status anddate information for some seeded business functions. If you purge workflowstatus information for closed orders, you will not be able to use these StatusAPIs for those orders.

Note: Order Purge functionality is provided with Order Management. The PurgeOrders concurrent program lets you purge selected closed orders and their workflowhistory.

CUSTOMIZING ORDER AND LINE FLOWS

You can customize Order or Line Workflow processes via the Workflow builder.Again you should be working at an access level of 100. You can copy seededrunnable processes, change the internal & display names and then modify them asneeded. Any new runnable Order or Line flows can be used by assigning them to


Order or Line types via the Define Transaction Types form.

GuidelinesWe recommend the following guidelines when you define custom data:

• When defining runnable order or line flows, use the seeded functional sub-processes as opposed to using the function activities.

Example: When defining a header flow, use one of the seeded Booking processesas opposed to the seeded “Book” function activity.

The functional sub-processes are designed to handle exceptions and sometimes toadditional stuff.

You could use specific function activities when the seeded flows also use them.

Example: All the seeded line flows that support fulfillment use the functionactivity “Fulfill”.

• Adhere to the following rules

� All order header flows should have the Close Order sub-process. Allline flows should have the Close Line sub-process.

� If the header or the line flow (used with the header flow) is using anyof the seeded functional sub-processes then; the order header flowshould have the Booking sub-process and the line flow should havethe Enter sub-process (to ensure that lines wait for the order tobook). If Close Order and Close Line are the only seeded sub-processes you are using in your header or line flows then you do notneed to include the Booking sub-process in the Header flow and youdo not need to include the Enter sub-process in the Line flow.

� Do not design a line flow such that the line interfaces to Invoicingbefore it ships. See the section Order or Line processes that are workflowenabled - Invoice Interface for details.

� Include the functions sub-processes that represent the processing youwould like the order or line to go through. Thus if a line needs beinterfaced to Invoicing, you need to ensure that its flow has a sub-process that does that.

� Some WF activities need to be configured to be used, via setting itsactivity attributes. You need to set the activity attributes when suchan activity is placed in a process. Example - Fulfillment activity, Theactivity to set the Notification Approver.

� If you add order level approvals that need to be honored by all lineson an order, then you may need to ensure that new lines are notadded to the order once it is past that header approval (via customconstraints).


• Always specify “RETRY_ONLY” as the default error process for any customWF data.

• If you copy a seeded functional sub-process and change its definition (eg: adda custom activity in between seeded activities, delete a seeded activity etc)and use it in new order or line flows, then this sub-process is considered acustom sub-process. Oracle does not guarantee that such a custom sub-process will provide the same functionality as the seeded sub-process.Secondly, when the seeded functional sub-process is altered to provideenhanced functionality, the custom sub-process will not automatically bechanged.

Hence instead of customizing the seeded functional sub-process, you shouldcreate a different activity or sub-process that does the custom processing.You can then place this new activity or sub-process before or after theappropriate seeded functional sub-process in a runnable Order or Line flow.

Examples

You can do simple to very complex customizations using Oracle Workflow. Youcan design order - line co-ordination based on custom activities. You can defineyour custom activities such that they honor holds. You can define customactivities such that they can be completed via the Progress Order LOV. You canalso define constraints based on your custom activities and how they werecompleted.

• Standard Items and PTO Only - Your business does not do ATO processingand it does not drop-ship lines. The seeded Order Management flows aredesigned to handle different kinds of items. You can copy and modify theseto exactly suit your requirements, thus making them more efficient.

You can copy the flow “Line Flow - Generic” to a new one, change itsinternal and display name. You can then remove the sub-process “Create Supply- Line” from this new definition(Figure 13). This sub-process internally callsother sub-processes based on whether the item is built and whether the line isinternally or externally sourced. Since you only deal with Standard items andPTOs and you do not source from an external vendor, your line flows do not needthis sub-process.

Close - LineInvoice Interface -Line

Enter - Line Fulfill - Deferred Fulfill EndSchedule - Line Ship - Line, Manual

Figure 13 : Line Flow - Standard Items Only


• Deferred Booking that is manually controlled - You want your Order Entryclerks to be able to control when an order is booked, however you do notwant them to have to wait while the order books. Order Management doesnot seed a sub-process that supports this exact variant, however you can veryeasily create such a sub-process. Using the seeded activities Book -Eligible,Book -Deferred, Book, and Book - Continue Line, you can create a newBooking sub-process. Branch the transitions for the Incomplete and OnHold results back to the Book - Eligible activity. Create an order header flowthat uses this booking process and assign it to an Order Type.

Incomplete

On Hold

Book - Continue LineBook - Eligible Book End (Complete)Start Book - Deferred

Figure 14: Book - Order, Manual and Deferred

• Custom external processing - Your business sells to foreign nations and henceneeds to comply with export regulations. You use Export Compliancesoftware from an external vendor that ensures that you are compliant. Youneed to integrate with this software so that it checks that an order line isexport compliant before it can be processed further.

There are many different ways to achieve this:

Define a workflow function activity “Export Compliance” that calls a PL/SQLAPI that integrates with your Export Compliance software (Figure 15). If theOrder line is export compliant then if completes with a “Passes” result. In case offailure it completes with a “Fails” result and transitions to a failureblock(WF_STANDARD.BLOCK), that ensures that the flow does not moveforward. You would then need to manually cancel the line.


Passes

Fails

Export ComplianceStart

Export ComplianceFailed

End (Passes)

End (Fails)

Figure 15: Export Compliance sub-process that uses a function activity

Alternatively you could also code the cover for the “Export Compliance” activitysuch that, in case of failure it transitions the flow to a Block activity that calls theAPI OE_STANDARD_WF.STANDARD_BLOCK (Figure 16). Users who havethe authority to deal with such lines can either cancel the line or complete thenecessary procedures to make the line compliant. In the latter case, they wouldbe able to progress the line from the Progress Order LOV(from the Sales OrderForm). The sub-process is designed such that it performs the compliance checkagain.

Passes

Fails

Export ComplianceStart

Export ComplianceFailed, Cancel or

Re-try

End (Passes)

Figure 16: Export Compliance sub-process that allows a re-try

If the Export Compliance call is expensive you can defer it by setting its cost to behigher than the WF Threshold.

If you think it is more efficient to process Lines for export compliance en-masse,you can design the sub-process as follows(Figure 17):


PassesStart Eligible for Export

Compliance CheckEnd (Passes)

Figure 17: Export Compliance sub-process that is externally completed

The block activity “Eligible for Export Compliance Check” calls the APIWF_STANDARD.BLOCK. You can write a concurrent program that can pick uplines that are eligible for “Export Compliance”; that is it queries lines that areawaiting at the block activity “Eligible for Export Compliance Check” by lookingat WF Item Activity Statuses view. It then integrates with the export compliancesoftware and processes them. If they fail export compliance, the concurrentprogram can call the Order Management Process Order API(OE_ORDER_PUB.Process_Order) to cancel such lines. If they pass exportcompliance, it can complete the block activity using WF Engine APIs(WF_ENGINE.COMPLETE_ACTIVITY).

You could refine it further (Figure 18); in cases where completing some additionalprocedures could make an Order Line compliant, the concurrent program couldput the Line on Hold, using the Order Management Hold APIs). In such cases theflow transitions with a “On Hold” result to an eligibility block. Authorized Userscould complete required procedures and release the Hold. They could thencomplete the “Handle Holds” block activity via the Progress Order LOV. Youcan also set a time-out interval (e.g. 1 day) on the block activity, this willautomatically trigger its completion after the specified time. In case it is deemedthat there is anything that can be done to make this Order Line export compliant,the user could cancel the line. This will force the flow to closure.


Complete

On Hold

Start Eligible for ExportCompliance Check

End

Handle Holds

Figure 18: Export Compliance sub-process that handles holds.

As you can see, using Order Management and Workflow you can solve thisbusiness requirement in many different ways. You could enhance this processfurther, by adding notifications activities.

Once you have defined one or more sub-processes to meet your needs, you needto use it/them in a line flow(s) and assign the flow(s) to a Line Type(s).

Oracle Workflow also lets you define activities that call external functions. It usesOracle Advanced Queues functionality to achieve this.

Note: Refer to the Oracle Workflow Users Guide (Part Number A85440-01) for moreinformation on the WF APIs and on defining function activities of type PL/SQL andExternal. Refer to the Open Interfaces Manual (Part Number - A83746-01) for informationon the calling the Process Order API.

• Defining a flow that can be used for both Outbound(order) andInbound(return) Lines:

Order Management does not seed a generic flow that can support both order andreturn lines. However, if you wanted to do so for some reason, you can do sousing the seeded sub-processes. However this should be done with cautionas Workflow does not function identically to Cycles.


Unreserve

Close - Line

Create Supply - Line


Enter - Line Fulfill - Deferred Fulfill End

Schedule - Line Ship - Line, Manual

Return Receiving -Line

Figure 19: INCORRECT Flow to support both Order and Return Lines

The above flow WILL NOT work correctly, since once a line is booked, WFrandomly picks which transition to process first. It then processes it all the waytill it can go no further. So for an outbound Line using this flow, if the branch‘Returns receiving’ is first processed, it will get marked as “Not Eligible” and hitthe “Fulfill -Defer” activity (to defer thread) and stop. Then the WF Engine startsexecuting the other branch; the line will schedule and hit the “Ship - Line, Manual”sub-process, where it will stop and wait to get picked and shipped. However theBackground Engine could pick up the deferred thread and execute the “Fulfill”activity. This activity will error out since the fulfilling event for the order line“Ship-Confirmation” is not yet complete.

For this to work correctly you need to define the flow as follows:

Unreserve

Return

Order

Close - Line

Create Supply - Line


Enter - Line Fulfill - Deferred Fulfill End

Schedule - Line Ship - Line, Manual

Return Receiving -Line

Utility to Get LineCategory

Figure 20: CORRECT Flow to support both Order and Return Lines

After booking the line flow branches based on the Line Category ensuring thatonly one of the branches are (Order or Return) executed runtime. The activity“Utility to get Line Category” is seeded OM: Order Line Work Item.


Caveats

While you get immense flexibility when designing order and line flows with OracleOrder Management and Oracle Workflow, we recommend that you do so wisely.It is recommended that you acquire training in using Oracle Workflow, before youcustomize Order Management Workflow processes.

We also recommend that you keep in mind the following:

• When Order Management sends you patches for bug fixes or new releases, itwill affect only the seeded OM data. You should carefully review any WFpatches you receive. You need to look at the changes made, and decidewhether you need to change your custom processes accordingly.

Example - You define a custom booking process (Figure 13). Patches thatupdate the definitions of the Book-Order, Manual and Book-Order, Deferred willnot affect the definition of this custom booking process. However if OrderManagement sends out a patch that changes the definition of the seeded Bookactivity, your custom process will also pick up the updated definition since it isreferencing this seeded activity.

Example: Currently the seeded Book function internally calls the CreditChecking API. With a future release Order Management release, this maychanged such that credit checking/payment verification is WF enabled. The APIthat seeded Book function will be changed to not call the credit checking API.And the seeded Booking processes will be changed to include the credit checking/payment verification workflow activities. Now when you get this patch, youneed to review it and modify your custom booking process accordingly. If you donot, then your custom booking process will not do credit checking (since itreferences the updated book function that no longer calls credit checking).

• You may define new workflow item attributes for the seeded OrderManagement Work items. However you should keep in mind that OracleWorkflow creates a row for every item attribute whenever a flow is startedusing a workflow item type (irrespective of whether the item attribute has avalue) and this can affect performance negatively. Hence we recommend thatyou define new workflow item attributes judiciously.

Example: You define 10 new item attributes under the item type “OM: OrderLine”. You define new workflow activities that set values for these attributes andyou use them in your notification activities. Now whenever you create an OrderLine, Workflow will create 10 additional rows in WF_ITEM_ATTR_VALUES forthese new attributes.

Order Management uses the primary key (Header_id/Line_id) for the Order/Lineas the workflow item key when it starts Order/Line flows. You can use this inyour function activities to get more information about a order or line.

Note: Look at the appendix for an example of a PL/SQL based function activity.


CONCLUSIONOracle Order Management’s use of Workflow provides you with powerful orderprocessing and fulfillment capabilities. You need to understand the capability thatOracle Workflow provides and the seeded functionality that Order Managementprovides to design the best order processing flows for your business. Byconfiguring flows that are flexible and optimal, you can significantly improve yourorder fulfillment times, thus increase your profitability.


GLOSSARY

The document uses the following abbreviations:

Line Type(s) - Line Transaction Type(s)

OE - Order Entry

OM - Order Management

Order Type(s) - Order Transaction Type(s)

R11 - Release 11

R11i - Release 11i

Transaction Type(s) - Order and Line Transaction Type(s)

WF - Workflow

Other terms used -

Flow - A flow is what the application starts for a order or a line. A flow is startedusing a specific "workflow process"

Workflow Process - A workflow process is made up of workflow activites orworkflow sub-processes.

Workflow Sub-process - A workflow sub-process is made of workflow activites ormore workflow sub-processes. A workflow sub-process is not defined as"runnable" which means that you cannot start a flow using it.

REFERENCES

Oracle Workflow User’s Guide - Part Number A85440-01

Applications Open Interface Manual - Part Number A83746-01

All the White Papers that this document refers to are available on Metalink


APPENDIX A

R11i.2 seeded order header/line Workflow processes

Header level seeded workflows:Order Flow-GenericOrder Flow-Generic with Header Level Invoice InterfaceOrder Flow-Return with Approval

Line level seeded workflows :

Line Flow-ATO ItemLine Flow-ATO ModelLine Flow-ConfigurationLine Flow-Configuration w/authorization to ShipLine Flow-GenericLine Flow-Generic with authorization to ShipLine Flow-Generic with Header Level Invoice InterfaceLine Flow-Generic, Bill OnlyLine Flow-Generic, Ship OnlyLine Flow- Standard ServiceLine Flow- Return for Credit onlyLine Flow- Return for Credit with ApprovalLine Flow- Return for Credit with ReceiptLine Flow- Return for Credit with Receipt & Approval

APPENDIX B

R11i.2 seeded WF Item AttributesOrder Management comes seeded with the following WF Item attributes.

• Item Attributes that are common for OEOH, OEOL & OECHORD:

Order Management WF Administrator (WF_ADMINISTRATOR) - This is set tohave a default value of ‘SYSADMIN’. You can changes this to reference any otherWF Role. This is the role that the default error process sends notifications to,when a WF activity runs into unexpected errors.

• Item Attributes that are common for OEOH, OEOL:

User ID (USER_ID) - The FND User that created the Order or Line.

Application ID (APPLICATION_ID) - The Application tied to the Responsibilityunder which the Order or Line was created.

Responsibility ID (RESPONSIBILITY_ID) - The Responsibility under which theOrder or Line was created.

Org ID (ORG_ID) - The Operating Unit in which the Order or Line is created.


Notification Approver (NOTIFICATION_APPROVER) - The item attribute thatis used as a placeholder to hold values for Notification Responders. The utilityactivity “Set Notification Approver” can set a value for this attribute. With 11i.2onwards, this is set to the value of the profile option OM: Notification Approverat the time the Order or Line is created.

The first 3 item attributes are used to set Application Context (Profiles, OperatingUnit context) by calling a AOL utility (FND_GLOBAL.APPS_INITIALIZE()).This code is executed in the selector function that the WF Engine calls using a‘SET_CTX’ mode, when executing deferred activities for a work item (Order orLine).

The ORG_ID Item attribute is used to test whether a flow is being re-started inthe right application context (Operating Unit). This code is executed in theselector function that the WF Engine calls using a ‘TEST_CTX’ mode, wheneversomebody calls it to restart a flow.

Note: Please refer to the Oracle Workflow User’s Guide for more information on theselector function and Callbacks for setting and testing context.

• Item Attributes defined under OEOH:

Order Category(ORDER_CATEGORY) - This is the category of the OrderHeader (ORDER, RETURN or MIXED). This is set when the Order Header iscreated. It is can be used to branch flow logic based on order category.

Header Short Descriptor(HDR_SHORT_DESCRIPTOR) - This is an attribute oftype PL/SQL Document. That is it is set dynamically. It can be used to providecontext to message bodies. It returns the Order Type and Order Number.

• Item Attributes defined under OEOL:

Line Category(LINE_CATEGORY) - This is the category of the Line (ORDERor RETURN). This is set when the Order Line is created. It is can be used tobranch flow logic based on line category.

Line Short Descriptor(LIN_SHORT_DESCRIPTOR) - This is an attribute oftype PL/SQL Document. That is it is set dynamically. It can be used to providecontext to message bodies. It returns the Order Type, Order Number, LineNumber, Shipment Number, Option Number and Service Line Number.

Lead Time Rollup Organization (LEAD_TIME_ROLLUP_ORG), Lead TimeRollup Config Item(LEAD_TIME_ROLLUP_ITEM), Lead TimeDate(LEAD_TIME_DATE), Lead Time CategoryStructure(LEAD_TIME_CATEGORY_STRUCTURE), Lead Time Request ID(LT_ATTR_REQ_ID), AFAS Line ID (AFAS_LINE_ID) - These are used toprovide parameter values to the Lead Time Calculation Concurrent Program. Thisis launched by the ATO Config creation sub-process.

• Item Attributes defined under OECHORD:


Resolving Role(RESOLVING_ROLE) - The Role that the change OrderNotification is going to. This is set dynamically when a User chooses to send aChange Order Notification to a certain responsibility. It is set when the changeorder notification flow is started.

User Text(USER_TEXT) - This is used to store the message body that an enduser types in when he chooses to send a Change Order Notification to a certainresponsibility. It is set when the change order notification flow is started.

Order Number(ORDER_NUMBER) - This is used to provide context to thechange order notification. It is set dynamically when the change order notificationflow is started.

APPENDIX C

R11i.2 seeded utility activitiesThese are seeded under the OM Standard (OESTD) Workflow Item Type.

• Approval Failed (APPROVE_FAILED_BLOCK) - This is a block activitythat can be used to transition failure results from Approvals. It calls the WFStandard block function. Using this activity enables the flow to remain active,so that you can manually cancel the Order/Line.

• Set Notification Approver (UTIL_SET_NOTIFICATION_APPROVER) -This is a function Activity that can be used to set the value for the itemattribute NOTIFICATION_APPROVER It has an activity attribute called‘SOURCE’ of type lookup(NOTIFICATION_APPROVER_SOURCE).The default value for this attribute is ‘PROFILE_APPROVER’.

The lookup NOTIFICATION_APPROVER_SOURCE (Role Sources forNotification Approver) has the following codes:

PROFILE_APPROVER (Notification Approver Profile Role Value),ORDER_CREATED_BY (Role that created Order), CREATED_BY (Role thatcreated the entity)

• Sample Block that can be completed from the Sales Order Form(BLOCK_ORDER) - This is the block activity that can be used to indicateeligibility for a function activity that follows it. A Order or Line awaiting atthis activity will show up in the Progress Order LOV (available from the SalesOrder form).

The following utility activities seeded under OM Order Line(OEOL) and can beused as decision points in branching a flow.

• Utility - Is Return Line Receivable?(RMA_IS_LINE_RECEIVABLE) - Thisutility returns a result of Yes or No based on whether the line is receivable.

• Utility to Get Line Category(UTIL_GET_LINE_CATEGORY) - This utilityreturns the line category Order or Return.


• Utility to Get Supply Source Type(UTIL_GET_SUPPLY_SOURCE_TYPE) -This Utility return the line supply source type Internal or External.

APPENDIX D

Procedures available to query Header Status

Functions available in the package OE_HEADER_STATUS_PUB:

PROCEDURE Get_Booked_Status( p_header_id IN

NUMBER,

x_result OUT VARCHAR2);

PROCEDURE Get_Booked_Status( p_header_id IN

NUMBER,

x_result OUT VARCHAR2, x_result_date OUT DATE);

PROCEDURE Get_Closed_Status( p_header_id IN

NUMBER,


PROCEDURE Get_Closed_Status(p_header_id IN NUMBER,


PROCEDURE Get_Cancelled_status( p_header_id IN

NUMBER,


PROCEDURE Get_Cancelled_Status( p_Header_id IN

NUMBER,


Procedures available to query Line Status


Functions available in the package OE_LINE_STATUS_PUB

PROCEDURE Get_Closed_Status(p_line_id IN NUMBER,


PROCEDURE Get_Closed_Status(p_line_id IN NUMBER,


PROCEDURE Get_Cancelled_status( p_line_id IN

NUMBER,


PROCEDURE Get_Cancelled_Status(p_line_id IN

NUMBER,


PROCEDURE Get_Purchase_Release_status(p_line_id IN

NUMBER,


PROCEDURE Get_Purchase_Release_status(p_line_id IN

NUMBER,


PROCEDURE Get_ship_Status(p_line_id IN NUMBER,


PROCEDURE Get_ship_Status(p_line_id IN NUMBER,


PROCEDURE Get_pick_Status(p_line_id IN NUMBER,



PROCEDURE Get_pick_Status(p_line_id IN NUMBER,

x_result OUT VARCHAR2,

x_picked_quantity OUT NUMBER,

x_picked_quantity_uom OUT VARCHAR2);

PROCEDURE Get_Received_Status(p_line_id IN NUMBER,


PROCEDURE Get_Received_Status(p_line_id IN NUMBER,


x_result_date OUT DATE);

/* This function returns invoice interface status */

PROCEDURE Get_Invoiced_Status(p_line_id IN NUMBER,


/* This function returns invoice interface status */

PROCEDURE Get_Invoiced_Status(p_line_id IN NUMBER,


x_result_date OUT DATE);

APPENDIX E

PL/SQL WF wrapper for the function activity “Is this a BIG Order”

Note: WF Function wrappers have to meet certain specifications. Please refer to theWF Users Guide for more details.

Note: This API calls an Order Management Group API to get the Order Total. APublic version of this totals API will soon be available.

CREATE OR REPLACE PACKAGE BODY OM_WF_WHITEPAPER as


PROCEDURE CHECK_ORDER_TOTAL(

itemtype IN VARCHAR2,

itemkey IN VARCHAR2,

actid IN NUMBER,

funcmode IN VARCHAR2,

resultout IN OUT VARCHAR2)

IS

l_order_total number;

l_big_value number;

BEGIN

-- RUN mode - normal process execution

IF (funcmode = 'RUN') THEN

/* Get Total Order Value for this Order */

l_order_total :=

OE_TOTALS_GRP.GET_ORDER_TOTAL(to_number(itemkey),

null, 'ALL');

/* Get Activity Attribute Value that determines

what amount makes an Order

BIG */

l_big_value :=

wf_engine.GetActivityAttrNumber(itemtype,

itemkey, actid, 'BIG_VALUE');

/* Check whether this Order is a BIG Order */

IF (l_order_total > l_big_value) then

resultout := 'Y';

ELSE

resultout := 'N';

END IF;


RETURN;

END IF; -- mode is ‘RUN’

-- Other execution modes may be created in the

future. Your

-- activity will indicate that it does not

implement a mode

-- by returning null

resultout := '';

RETURN;

EXCEPTION

WHEN OTHERS THEN

-- The line below records this function call in

the error system

-- in the case of an exception.

wf_core.context('OEOH', 'CHECK_ORDER_TOTAL',

itemtype, itemkey, to_char(actid),

funcmode);

RAISE;

END CHECK_ORDER_TOTAL;

END OM_WF_WHITEPAPER;

Using Workflow in Oracle Order ManagementCreated October 2000Updated October 2001Authors: Leena Sampemane, Tsui-Ying Wang

Oracle CorporationWorld Headquarters500 Oracle ParkwayRedwood Shores, CA 94065U.S.A.

Worldwide Inquiries:Phone: +1.650.506.7000Fax: +1.650.506.7200Web: www.oracle.com

This document is provided for informational purposesonly and the information herein is subject to changewithout notice. Please report any errors herein toOracle Corporation. Oracle Corporation does notprovide any warranties covering and specificallydisclaims any liability in connection with this document.

Oracle is a registered trademark, and Oracle Order Management is a trademark(s) or registered trademark(s) of Oracle corporation.All other names may be trademarks of their respective owners.

Copyright © Oracle Corporation 2000All Rights Reserved

Documents

28294599 Using Workflow in Oracle Order Management