Workflow - Common Errors and Solutions - Rev

 

Common Errors and Solutions when Using Workflow in Order Management An Oracle White Paper  March 2007

 

Contents Executive Summary ………..………………..…………………………………………1 1. Introduction Intr oduction …………………….…………..……….…………………… …………………….………… ..……….……………………………….2 ………….2 2. Processing Orders Using Workflow ….….……….……………………………….7 ….….……….……………… ……………….7 3. Error Handling …….………..………….…………….……………………… …….………..………….… ………….…………………………….16 …….16 4. Data Corruption ……………………..….…………….……………………… ……………………..….… ………….……………………………25 ……25 5. Workflow Performance Degradation ……..………….…………………………..29 6. Data Needed to Request Request Data Fix ……………..…..… ……………..…..….……………………… .………………………..30 ..30 Appendix A ……………………………………………….……………………………32 References ……………………………………………….……………………………33 List of Illustrations: Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure Figure

1a. Generic Order Header Workflow Process …. …………………….…2 1b. Generic Order Line Workflow Process ………………………………….3 1c. Generic Generate Default Account Process ……………………………3 1d. Activities List Window ……………………………………………………..5 1e. View Diagram Window …………………………………………………….6 2a. Incomplete Result at Booking ………………………………………..9 ………………………………… ……..9 2b. Process Message Window for Activities in SO Form Form ……………… 10 2c. Process Message Window for Deferred Activities ……………………11 2d. On Hold Result at Booking ………………………………………………12 2e. Not Eligible Result at Invoice Interface ……………………………… 13 3a. OMERROR Process …………………………………………………… …………………………………… ……………… 17 3b. Open Messages Checkbox is Checked ………………………………. 18 3c. View Open Messages from the Sales Order Form ………………… 19 3d. Line “Stuck” at “Shipped” – Open Messages not Checked ………….20 3e. Fulfill Activity in Error …………………………………………………….20 3f. Workflow Errors for Fulfill Activity ………………………………………21 ………………………………… ……21 3g. Retry of the Fulfill Activity in Error ………………………………………21

Figure Successful Retry the Fulfill Activity Error………………………….23 ……………………….. 22 Figure 3h. 3i. Line After Retry ofof the Fulfill Activity in in Error

1

 

Executive Summary:

Workflow in Order Management is the engine that processes orders from start start to finish. At times, or order der headers and lin lines es encounter errors errors in eithe eitherr seeded or customized fflows. lows. When the workflow gets “stuck” it refuses to continue to the next activity.  The result is that orders orlines RMAs cannot booked, configuration items cannot be created, cannot b ebe be fulfilled, shipments cannot be invoiced, orders cannot be closed and so on. This presentation will discuss how to resolve and prevent these workflow issues and as a last resort what data is needed to request a data fix from Development.

1

 

1 Introduction Workflow controls the sequence of events that occur in the processing of sales documents such as orders, quotes, blanket sales agreements, returns, order lines, and return lines. Oracle Workflow manages activities, executes functions, sends notifications, maintains completed activity history, detects errors, and initiates error proc processes. esses. An Item Type is a grouping grouping of  workflow components components into a high level category. All components of a workflow process must be associated with a specific item type. An item type can c contain ontain multiple multiple processes. OM Item Types

Order Management uses the following seeded workflow item types to process headers and lines: 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 item type with the header ID as the Item Key. An or order der flow is start started ed when an order header is created and saved. OM Order Line (OEOL) - All order line level activities and subprocesses are seeded u under nder tthis his WF item type. Line flows flows are started using using thi this s item type wi with th the line ID as the item k key. ey. An order line flow is started when an order line is created and saved. OM: Generate Cost of Goods Sold Account (OECOGS) - This is the item type that encompasses all processes designed to build the COGS account when interfacing transactions from Order Management to Inventory.  The following is an example of a generic order header workflow process belonging to the OEOH item type:

2

 

Figure 1a: Generic Order Header Workflow Process  The Order Flow – Generic is the most commonly used header flow. This process includes activities that book and close the order header. It can be used with any line flow for any item type, with outbound lines and with return lines.  The following is an example of a generic order line workflow process belonging to the OEOL item type:

Figure 1b: Generic Order Line Workflow Process  The Line Flowfor – Generic G flow manages several ite item m types. It can be used alleneric itemsline including assemble-to-order (ATO) items, ATO models, kits, and pick-to-order (PTO) models. This flow will not work for configured items generated from assembleto-order models.  The following is an example of the generic Generate Default Account process belonging to the OECOGS item type:

3

 

Figure 1c: Generic Generate Default Account Process  The Generic Generate Default Account Process derives the Cost of Goods Sold account for a transaction interfaced to Inventory from Order Management/Shipping. It comes se seeded eded with th the e function Get CCID (account ID) for a line. This function will return the CCID from the Cost of Goods Sold assigned to the item on the sales order line within the shipping inventory organizati organization. on. To generate the COGS Account from the Order Type, please review Note.414314.1 for detailed instructions. Note: Workflow processes starting with UPG_** are upgraded workflows for use in processing upgraded orders from prior releases. These workflow workflows s should n never ever be used for new orders after the upgrade as they contain inefficient or obsolete activities in 11i. Process Dependencies

 There is a parent and child dependency between orders and lines. Example: 1. Orde Orderr lines sho should uld wai waitt for the ord order er to book b befor efore e progressing in their individual Line flows. 2. All order lines shou should ld close, before the order header closes. Viewing Workflows in Oracle Order Management

From within Order Management you can view the active workflow processes discussed in this paper and their associated functions, messages, sub-processes, notifications, and properties. These processes must be in an active running state and also associated with a sales order or sales order line in order to view them.  To view processes for specific orders within Order Management, complete the following steps: 1. Open the de desired sired or order der in Or Oracle acle Ord Order er Mana Managemen gement. t. 2. Navig Navigate ate to the Tools men menu u and select Wor Workflo kflow w Status Status.. 3. A new wind window ow open opens s and displ displays ays the wor workflo kflow w statu status s as an activities list. 4

 

 The following image depicts the Activities List window in Oracle Order Management:

Figure 1d: Activities List Window 4. Select the View Dia Diagram gram button to view the actual workflow diagram.  The following image depicts the View Diagram window in Oracle Order Management:

5

 

Figure 1e: View Diagram Window

6

 

2 Processing Orders Using Workflow  There are three modes in which orders or lines can be progressed: Synchronous, Synchronous, Manual or Deferred. When an or order der (or line)Workflow is created, the application starts a header (or line) flowas forthe it.  The engine will push the order/line ahead as long activities are synchronous. The flow stops when it hits block activities, notification notification activit activities ies or wait activities. activities. The flow gets deferred to the background when it hits 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 the WF activities are executed synchronously or online until it reaches the end of  the flow or reaches some kind of block activity or is deferred. Example: You create a line th that at uses the seeded “Line Flow Generic”. This has the seeded “Schedule - Line” sub-process. Provided that there are no holds, once the order is booked, the line will will automatically schedule. The fl flow ow will then continue on and stop at the “Ship” activity, making the line eligible for Pick Release.  Manual Completion

If the order/line hits an “Eligibility Block”, then you can move the order/line forward via the Progress Order LOV (Actions > Progress Order). This LOV displ displays ays the functions functions that the order or or line is eligible for (and can be manually completed). Example: You create an order that uses the seeded “Book – Order, Manual” Manual” sub-process. When an or order der is eligi eligible ble for Booking, the flow flow will stop at the “Book – E Eligible” ligible” block. The Progress Order LOV on the Sales Order Header form displays that the order is eligible eligible for Booking. Booking. Clicking Ok on tthe he LOV will trigger completion completion of the “Book – Eligible” block. block. The flow wil willl move to the “Book” activity and execute it, thus booking the order.

7

 

Deferred Completion

An order or line flow can also stop because the flow was deferred to the Background Engine. Example: Fulfillment Fulfillment is deferred in all all the seeded line fl flow. ow. The Workflow Background Engine Process concurrent program needs to be scheduled to run at periodic intervals to be able to fulfill and invoice interface lines (otherwise it would have to be manually executed). executed). The Workflow Background Engine Engine also processes Wait activities and Timed-Out activities. Activity Results

Most Order Management function activities use the standard seeded lookup “OM Sub-Process Results, handles Holds”. This lookup has the the following result codes: Complete, In Incomplete, complete, On Hold and Not Eligible. 1. Complete - A fu function nction activity completes with the the “Complete” result when it executes successfully. Example: When the seeded “Book” function successfully books an order, it will complete with a “Complete” result. Please refer to Figure 1d. 2. Incomplete - A function activity com completes pletes with the “Incomplete” result when it runs into expected errors that it is built to handle. The “Incomplete” result normally transitions to an “Eligibility” block or a Wait Activity. Example: When the seeded “Book” function finds that the order line does not have a Ship To on the order line, it will complete with an “Incomplete” result and transition to the “Book -Eligible” activity.  The following image depicts the Incomplete Result at Booking:

8

 

Figure 2a – Incomplete Result at Booking When an activity is completed via the Sales Order window, the Processing Messages window appears to display messages that indicate errors. The error message can be retriev retrieved ed from the Header or the Line using Actions > View Open Messages.  The following image depicts the Process Message Window for the Incomplete Result at Booking:

9

 

Figure 2b – Process Message Window for Activities Completed via the Sales Order After providing the missing information you can repeat the Book activity via the “Book” button or the Progress Order LOV. For activities processed by the Workflow Background Engine (the activity is deferred), the error messages are stored in the Order Management processing processing message message table. View th these ese messages via the Processing Message window (OM Responsibility > Orders, Returns > Process Messages) using the concurrent program request number, the workflow activity, and/or order or line basis.  The following image depicts the Process Messages window error messages for the Workflow Activity Purchase Release:

10

 

Figure 2c – Process Message Window for Deferred Activities When an activity is completed via a concurrent program, its output file lists all the error messages that were posted. 3. On Hold - A fu function nction activity completes the “On “On Hold” result when it runs into a gener generic ic or activity specific Hold. The “O “On n Hold” result normally transitions to an “Eligibility” block or a Wait Activity. Example: When the seeded “Book” function finds that there is generic hold on the order, it will complete with an “On Hold” result and transition to the “Book -Eligible” activity.  The following image depicts the “On Hold” H old” result at Booking:

11

 

Figure 2d – “On Hold” Result at Booking After releasing the hold you can repeat the Book activity via the “Book” button or the Progress Order LOV. 5. Not Eligible - A function activity activity completes w with ith the “Not Eligible” when it does sense for the Order Header or Line toresult be processed by a not thatmake activity. Example: When the Invoice Invoice Interface Activity Activity proc processes esses a noninvoiceable item line, it completes with the “Not Eligible” result and transitions to the end of the Invoice Interface sub-process.  The following image depicts the “Not Eligible” result at Invoice Interface:

12

 

Figure 2e - “Not Eligible” Result at Invoice Interface Only on a successful completion (Complete or Not Eligible result) of a business function, does a flow exit out of the respective functional sub-process and continues on to the next activity. Order or Line Processes that are Workflow Enabled

Some functions are seeded in multiple variants (Synchron (Synchronous, ous, Manual & Deferred). Deferred). Following is is list (not comprehensive) of  business functions that are workflow enabled: 1. Book Booking: ing: An or order der c can an be booke booked d man manually ually or it it can be deferred to the Work Workflow flow Back Background ground Proc Process. ess. Order Management uses native WF co-ordination activities to ensure that order lines wait for the order to book before progressing 2. Sched Schedulin uling: g: The Sc Schedul heduling ing fu functi nction on all allocate ocates s sup supply ply tto o demand and makes the Order line visible to MRP (as demand). Order Management provides two variations on

13

 

Scheduling, one where it is performed synchronously and another one where it is deferred. 3. Creat Create e Sup Supply: ply: The s seeded eeded “Crea “Create te Su Supply” pply” sub-p sub-proce rocess ss has the intelligence to route Order Lines differently based on the item type and whether they are internally or externally sourced. 4. ATO Proc Processing essing:: The e entir ntire e ATO proc process ess iis s wo workfl rkflow ow enabled. There are various seede seeded d sub-processe sub-processes s to support functions such as creating the configuration item, the BOM & routings, calculating lead time and rolling-up cost, creating the work order, etc. 5. Ship: Pick Relea Release, se, S Ship hip Confir Confirm m and Inven Inventory tory Inter Interface face are part of the seeded “Ship - Line, Manual” sub-process. Each of the the shipping functions is n not ot Workflow enabled. The “Ship” activity is a block activity that waits until the line is picked, shipped and interfaced to Inventory and Shipping and communicates that information to Order Management. 6. Purc Purchase hase Relea Release: se: The seede seeded d Purcha Purchase se Re Release lease subprocess interfaces information to Purchasing when order lines need to be drop-shipped. 7. RMAs RMAs:: The Returns Returns re receipt ceipt and a accept cceptance ance ffunct unction ion iis s workflow enabled using block activities. 8. Fulfillment: The seeded “Fulfill” activity ensures that lines do not move forward in their flows until they are fulfilled. 9. Invoice Interface: Interface: The seeded ‘‘Invoice Invoice Interface Interface – Line’ su subbprocess interfaces line information to Invoicing. 10. Close Order and Close L Line: ine: Closing Order Orders s and Lines is workflow enabled. The seeded “Close - Order” sub-process uses native WF co-ordination activities (wait for Flow) to ensure order header closes after allthe theen lines closed. that It isthe designed tto o close the or order der at end d ofhave the month.  Extending Workflow

Instead of providing flows and activities to meet every possible business rule and need, Order Management integrates with Workflow to provide easy customizing capability. Oracle Workflow provides a complete set of PL/SQL APIs and public views that can be used to make any any application function function workflow enabled. Care

14

 

must be taken to follow certain guidelines when modifying workflow. Following are some ex examples: amples: 











Do not modify modify seeded da data. ta. Instead, alway always s copy the seeded process and rename both the internal and display names before modifying the workflow. Dependencies should not be vi violated. olated. Order lines wait for booking before before continuin continuing g their flow flow.. Order lin lines es should not invoice until after booking occurs. Always specify RETRY_ONLY as the default error process for any workflow activity you define. Use seeded WF functions whenever possible, like the “Reprice – Line” process which enables you to reprice an order line at any point in the order life cycle. Do not issue a commit or rollback with a custom WF function as this can lead to data corruption. Use Wait activities with very small relative times carefully as these can cause the Workflow Background Process to go into an infinite infinite loop. See Note.345090. Note.345090.1 1 for mor more e information.

15

 

3 Error Handling  There are two kinds of errors that Order and Line flows can run into: Expected Errors and Unexpected Errors. Expected Errors

 These are errors that business processes expect to run into and handle. These error errors s are e easy asy to recover from. 

 The Incomplete Result at Booking (See Figure 2a) example is an expected error handled by Order Management with the Incomplete Activity result. The missing information can be provided via the form and the order or line can be progressed from Actions > Progress Order. 

Unexpected Errors

 These are errors that a business process does not expect under normal circumstances. circumstances. Causes of unexpected unexpected error errors s include the following:   



Data Integrity errors  The table does not exist Rollback segments cannot be extended  The package does not exist

All Order Management seed WF data is defined to use the “Retry Only” error process. This process determines th the e notificati notification on flow that Oracle Workflow starts when a workflow activity runs into an unexpected error.  The activity that encountered an unexpected error is marked with an Error status (in WF_ITEM_ACTIVITY_STATUSES) and a notification listing the error details is sent to the role specified in the OM Workflow Workflow Admini Administrator strator item attribute. The Role item attribute WF_ADMINISTRATOR is defined for the header and line

16

 

work item, and is set as SYSADMIN. The error process sends notifications about the error to this role. Once the problems have been corrected, the administrator can select the Retry option on the notification and complete it. This initiates a retry retry of the activity activity in error. The administrator administrator can also opt to retry the activity from the Workflow Monitor. Exception Management Feature

 The Exception Management feature provides visibility of the Workflow errors errors to functional users. After correct correction ion of the issues recorded in the Message Framework, you can “Retry” the Workflow activity from the Sales Order/Quick Sales Order Window. It iis s av available ailable for Release 11.5.9 with Patch.3731146 and comes seeded seeded in Release 11.5.10. All seeded fl flows ows started after this patch will use the OM Standard Error Process with Retry (OMERROR Item Type) Type) as the Err Error or Process. Following ar are e some of the activities of this Order Management specific error handling process: 





Update Process Messages – Adds the concurrent request ID to the message stack. Check if Error Still Active – Check to see if the Error is still active. Retry Error Activity – If the activity is still in error, it retries the activity.

 The OMERROR flow must be added for customized activities in order to use the “Retry Activities in Error” functionality.  The following image depicts the OMERROR Item Type:

17

 

Figure 3a – OMERROR (OM Standard Error Process with Retry) Process View Open Messages

When the OM Profile Option “OM: Show Process Messages Flag” is set to Yes, the Open Messages checkbox will display a checked value indicating that at least one message exists for the order.  The following image depicts the Open Messages checkbox:

18

 

Figure 3b – Open Messages Check Box is Checked  The following image depicts the Open Messages viewed from Actions > View Open Messages:

Figure 3c – View Open Messages from the Sales Order form Some notActivities have Open Messages but are still in error when viewedlines fromdo the window. Example: Order 2245 line 5.1 is at “Shipped” Status and has not progressed to “Closed” despite the Workflow Background Process for Deferred Activities being scheduled to run at periodic intervals.  The following image depicts an order line “stuck” at “Shipped”:

19

 

Figure 3d – Line “Stuck “Stuck” ” at “Shippe “Shipped” d” – Open Messages not Checked  The Workflow status view from the Activities Window shows the Fulfill activity in error status:

Figure 3e – Fulfill Activity in Error

20

 

Clicking on the red X to the left of the status column lists the error:

Figure 3f – Workflow Errors for the Fulfill Activity It is unknown how the Fulfill act activity ivity resulted in error. However, Retrying the Activity in Error from the Sales Order form worked without taking any further action:

Figure 3g - Retry of the Fulfill Activity in Error 21

 

If the activity completes successfully, you will get a success message. Otherwise, you will see the error error messages an and d the Retry will have to be repeated after fixing the errors.  The following image depicts a successful Retry of the Fulfill Activity in Error:

Figure 3h - Successful Retry of the Fulfill Activity in Error  The following image depicts the line in closed status after successfully retrying the Fulfill Activity in Error:

22

 

Figure 3i – Line after Retry of the Fulfill Activity in Error For more information on the Exception Management Feature, please refer to Note. Note.113492.1. Retry Activities in Error Concurrent Program

When a large number of workflows go into error, the Retry Activities Concurrent Program provides the ability to retry more than one workflow workflow across orders orders in batch mode. It also purges WFERROR/OMERROR WFERROR/OMERRO R child workflows of OEOH/OEOL that are active but shouldn’t be (when the parent OEOH/OEOL don’t currently have any open errors). errors). This enhancem enhancement ent to the Exception Management functionality was introduced in Patch.4420026 for Release 11.5.10. For Releases Releases 11.5.9 and below, Patch.5248424 provides this functionality.  The Retry Activities in Error Concurrent Program can be run in Preview and Execute Execute mode. The Preview mode is the default and

23

 

never executes the errored errored flow. It gives a report and count of  the errored activities activities along with the errors in the log file. Users should use the messages included in the log output to identify and remedy as many errors as possible before resubmitting the program. In the Execute Mode the errored flows are actually retried and then it displays the result of the Retry and any error messages in the log file. Example: When there is an extent problem with the table ASO.ASO_ORDER_FEEDBACK_T ASO.ASO_ORDER _FEEDBACK_T large numbers of workflows can go into error upon booking and the following exception message will be logged: ORA-20001: OE_Order_WF.Book_Order(OEOH,29058, OE_Order_WF.Book_ Order(OEOH,29058, 110960, RUN) Wf_Engine_Util.Function_Call Wf_Engine_Util.Fun ction_Call (OE_BOOK_WF.B (OE_BOOK_WF.BOOK_ORDER, OOK_ORDER, OEOH, 29058,110960.RUN) After fixing the table extent problem p roblem new records will successfully book. For the existent rrecords ecords in error, error, the Retry Act Activities ivities in Error Concurrent Program can be used to mass retry the Book Activity. Note: COGS Account generation can fail during Interface Trip Stop or RMA Receipt. The cause is usual usually ly improper setu setup p or improper customization of the Gen Generate erate Default Account pro process. cess. In this case, use the cogs_11i.sql diagnostic script, available in Note.159998.1, to debug the process.

24

 

4 Data Corruption Data corruption occurs when Order management Status is not in sync with OEOH OEOH or OEOL wor workflow kflow item stat status. us. It means that the integrity of the data h has as been cor corrupted rupted in so some me way. Order headers or lines with data corruption cannot be retried successfully using the Exception Management functionality. functionality. The invalid data must be fixed via direct direct update using SQ SQL. L. In such cases, it is important to identify the exact nature of the d data ata corruption and and the number of affected transactions. Customers should not attempt to fix the data themselves but request a data fix script from Development/Support. Development/Support. Note: Data fixes received from Support/Development via bugs are not generic, meaning they should not be applied for other similar issues without approval of Support/Development. Support/Development. Causes of Data Corruption

Any process that is Workflow enabled may theoretically encounter data integrity issues. See the li listing sting of lin line e and header processes that are workf workflow low enabled in Chapter 2. Without a reproduceable test case it is not possible to determine root cause. Often, the issue only becomes evident after the fact when the activity that needs to be performed cannot be completed (e.g. invoice not generated or inventory not decremented). Proactively, you can run the data validation script, BDE_OMSuiteDataChk.sql, BDE_OMSuiteDataChk .sql, available in Note.353991.1 for a comprehensive list of most known data integrity issues and take action before they become critical. Data Corruption can be caused by not following standard customization practices when extending seeded OM Workflow Processes. Development has introduced introduced a ffunctionality unctionality called “OM Workflow Validation” to help OM customers evaluate and validate their proposed workflow extensions and customizations before implementing implementing them. The validati validation on can be done in tthe he  Transactions form concurrent program “Validate OM Workflow”. Workflow” . Fororathrough detailedthe description desc ription of the functionality, 25

 

please review Note.312535.1. It is highly recommended that that customers run this validation when implementing customized Workflows. Workflow should never be expedited or skipped on problematic lines or headers. Workflow Activities that have been expedited will show a result of  Force in the Status Monitor Monitor.. Expediting or skipping wor workflow kflow forces a violation of business rules and frequently causes data corruption (e.g. order lines close without shipping or invoicing). Improperly retrying (rewinding) the workflow activity can also lead to data corruption. Workflow data or any other OM data should not be manually purged via SQL, as the link between OM and Workflow data will be lost. Furthermore, iitem tem properti properties es should not be modified when there are open sales orders. Patches to Prevent Skipping of Workflow

Patch.3968068 prevents users from skipping activities from the Workflow Status Status Monitor. After applicat application ion of this patc patch, h, Users will only be able to skip activities of type Notification and Compare Activities such as Compare Date, Compare Time, etc.  This patch is included in Release 11.5.10 Patch.2979522 sends a Workflow notification to the sysadmin and User when he/she skips skips a Workflow activity. activity. It alerts and advises advises them not11.5.10 to skip skip CU2. activities in tthe he future. This patch is iincluded ncluded in Release Patches to Fix Known Data Corruption Issues

OM Development has released patches to fix known data corruption issues issues – these are not root root cause fi fixes. xes. Note.398822.1 maintains a current listing of all the data fix patches available. Sometimes when an order line is cancelled the corresponding delivery line is not canceled. canceled. This results in data c corruption orruption between the Order Order Management and Shipping tables. tables. Order

26

 

Management Development has created Patch.5590106 for Release 11.5.10. It ensures th that at all de dependent pendent transacti transactions ons are consistently marked canceled when a Sales Order line is canceled. For the case where the Ship Line activity errors out (or is progressed to a state other than “Notified”) “Notified”)  after the line is progressed AND has a corresponding closed delivery detail, retrying the activity activity will always always fail. The Retry Activities Activities in Error Concurrent Program for the SHIP_LINE Activity in Error will set the activity to Notified instead of retrying.

27

 

Data Corruption in Order Management

Following is a list of some of the known data corruption issues in Order Management:   

 





Cannot book orders. Included ATO/PTO option lines cannot be progressed. RMA lines cannot cannot be pr progressed: ogressed: RMAs are stu stuck ck at ‘Awaiting Return’ or ‘Awaiting Return Disposition’ status when the quantity has already been received in Inventory. Apply Patch.5358811. Lines in Fulfillment and Shipping Sets cannot be progressed. Missing line fl flows: ows: Workflow is c created reated but n not ot started. started. The order lines will stay in Entered or Book status and cannot be progressed. Data Fix needed. Orphan OEOL OEOL workflow workflows: s: wil Workflows exist st for no non-existing n-existing order lines. The headers will l wait forexi n non-existing on-existing lines tto o close resulting resulting in order orders s that cann cannot ot be closed. Apply Patch.5601973. Cannot invoice order/lines: Invoice Interface populates the ra_interface tables. tables. The workfl workflow ow error when this pr process ocess fails looks like this: Invoice Interface – Line, Deferred Invoice Interface Exception Error –2001 ORA-20001: OE_Invoice_WF.Invoice_Interface OE_Invoice_WF.Invoi ce_Interface (OEOL,114252, 165668,RUN) WF_Engine_Util.Function_Call (OE_INVOICE_WF.INVOICE_INTERFACE, OEOL, 114252, 165668, RUN)

Data Corruption in Shipping

 The concurrent program Interface Trip Stop (ITS) interfaces delivery details to Order Management and Inventory. Data integrity issues will result in ITS failing leaving pending transactions in OM, OM, Inventory int interface erface or both. Following is a llist ist of of theTrip known integrity issues resulting in failure of  thesome Interface Stopdata concurrent process: 28

 







Order line is closed but the delivery details are not yet interfaced. Order line is cancelled but the delivery detail is not yet cancelled. Lines with SHIP activity in ERROR status. The error message looks like this: ORA-20002: 3133: Activity instance 'SHIP_LINE' is not a notified activity for item 'OEOL/9341448’.





Delivery details are shipped but the order lines are in “Awaiting Shipping” status. Delivery details release status is ‘Shipped’ but the shipped quantity is 0 or null. ITS will complete with the ‘Bat ‘Batch ch is not yet fully interfaced to OM’ error.

Unprocessed Shipping Transactions

Unprocessed Shipping Transactions is perhaps the most critical type of data corruption in Shipping Execution because it prevents users from closing the Inventory Accounting Period at the end of  the month. These are records that have been Ship Confirmed in the period being closed, but have not yet been interfaced to Inventory. When this occurs, occurs, order lines are c closed losed but th the e Inventory Interface Interface flag is set to P (pending). Running Inter Interface face  Trip Stop with debug on will provide Users visibility to the exception/error. Please refer to Note.290432.1 for instructions instructions on enabling debug. Providing the missing information can result in successfully clearing the records. If re-executin re-executing g Inventory Interface Interface fails to clear the transactions, the issue would most likely require a data fix from Development. For a full detailed listing of the pending Shipping Transactions use the diagnostic script BDEprdcls.sql available in Note.246467.1.

29

 

5 Workflow Performance Degradation Oracle Workflow accesses several tables that can grow quite large over time. The size o off these tables and indexes can can adversely affect performance. Order Managem Management ent leaves a lot runtime obsolete data in the Workflow tables that needs to be purged on a periodic basis using the ‘Purge Obsolete Workflow Runtime Data’ concurrent request. request. Only complet completed ed workflow workflows s that have no pending parent and children workflow can be purged. For exampl example, e, the OEO OEOH H item type is the parent parent and OEOL is the child. child. Any WFERROR for the line or header header is a child. child. Improper workflow customization can lead to the workflow tables growing rapidly in size affecting affecting performance. When care is not taken during customization, the workflow may iterate or loop unnecessarily creating a row in the tables wf_item_activity_statuses wf_item_activity_st atuses and wf_item_activi wf_item_activity_statuses_h ty_statuses_h each time. This results in llarge arge activity stat status us item keys and and the tables growing rapidly in size. Example: Wait activities with very small relative wait times can cause the WFBG to go into an infini infinite te loop. Please refer to Note.345090.1. The followin following g excerpt fr from om the Or Oracle acle Order Management Workflow Validation White Paper explains (See Note.312535.1): “Workflow Background process for deferred activities operates in a loop that dequeues activities from the deferred activity queue as long as there are any available. If a WAIT activity is defined in a loop within its parent process, and if there are only a few activities in the loop with it, they may all complete very quickly, and the same WAIT activity will be enqueued again in the deferred activity queue. If the Relative Time (for the Wait Mode of  Relative Time) of the activity is short enough, it is  is plausible that the time will have expired before that very same Workflow Background process is done processing all other deferred activities ahead in the queue. In that case, it will process the WAIT activity again. If there are enough active workflow items in the same situation, it can lead to the infinite loop and the

30

 

concurrent program never completing, just like in the previous scenario.”

31

 

6 Data Needed to Request Data Fix Should you encounter data integrity issues that cannot be resolved using Exception orNote.398822.1 the Retry Activities Error concurrent program,Management please review for in available data fix patches that might address your issue. Otherwise, please log a Service Request with Support and request a data fix script.  You will be asked to provide the following: 













 The Diagnostics AppsCheck for Order Management, Shipping Execution and Advanced Pricing.  The Diagnostics OM Order Information output and/or HTMomse11i for for the entire or order. der. Use Note.133464. Note.133464.1. 1.  The OM Debug Debug file for the failing process. See Note.121054.1 for enabling debug instructions.  The Interface Trip Stop debug file if the issue deals with ITS failing. See Note. 29 290432.1 0432.1 for instructions instructions for enabling debug in Shipping.  The BDEprdcl.sql output, if issue deals with inability to close inventory period because of unprocessed Shipping   Transactions. Use Note.246467.1.  The workflow definition files (.wft) if encountering issue in custom workflow. workflow. Execute the following command to retrieve the .wft files: WFLOAD @