OM Order Processing

This post provides brief description on Order processing cycle and various stages. I always found workflow as gray area and was lazy to explore. But exercise with Ajay today made me dig it deeper. 

Order Processing Steps:

1) Create order
2) Book Order
3) Pick Release ( Request Set Stage )  to move inventory from Finished good to stage area..
                          Internal move order is created and pick slip is printed by the request run             
                          Deliveries are created apps.wsh_delivery_details , apps.wsh_new_deliveries
                          entries are made. Source_header_id is order header id.
                         This is applicable for Shippable Items only.
Order line status changes to "Awaiting Shipping" 
4) Background workflow fulfills the lines if there are non-shipable items. No Delivery lines are created for these items. Once delivery is closed ( ship confirmed ) workflow process cleans up flow status for lines. The prior  status can be      AWAITING_SHIPPING
5) Run GLOBAL OM IT SETUP->interfaces->run->Interface Trip Stop - SRS for making order line 'SHIPPED'
             
Behind the scene:

WSH_DELIVERY_DETAILS_PUB.Update_Shipping_Attributes is used to update shipping attributes
WSH_DELIVERIES_PUB.Delivery_Action is called to Ship Confirm the delivery . p_action_code:= 'CONFIRM' is set as input
'Workflow Background Process' is program for workflow and parameters are OEOH , OEOL

Glitch :

Our test order was getting back-ordered every time we ran pick release.
When dug further the reason was Inventory period was not open for order date.

Inventory period was opened using

Navigation: Inventory responsibility -> Accounting Close Cycles -> Inventory Accounting Period

    Select the Inventory ‘Period’
    Find  FUTURE status period
    Click ‘Change Status’
    Click ‘OK’ when prompted ‘Open this period?’

Supporting Queries:

SELECT *
  FROM apps.oe_order_headers_all
 WHERE order_number = '70005034'

SELECT oeol.flow_status_code, oeol.last_update_date, oeol.*
  FROM apps.oe_order_lines_all oeol
 WHERE header_id = 237175

SELECT *
  FROM apps.wsh_delivery_details
 WHERE source_header_id = 237175

SELECT *
  FROM apps.wsh_new_deliveries
 WHERE creation_date > TRUNC (SYSDATE) AND source_header_id = 237175

More on Interface Trip Stop:

Interface Trip Stop - Interface Trip stop plays very critical part in Oracle Order management application.
It is concurrent program that you can triggered from Interface > Submit Request . Interface Trip Stop.
Or you can also trigger this concurrent program at the time of ship confirm by un-check the "Defer Interface" check-box. By Default this check box is un-check only.

Interface trip stop has 2 parts
1.It process the data related to Order Management.
2.It Process data related to Inventory.(and we have separate CP for this too,Inventory Interface).

In First part does update on oe_order_lines_all table as well as wsh_delivery_details and once this part executed successfully only then SECOND phase of it is triggered. If FIRST part error out for some reason then 2nd part will not be triggered, and even if you try to submit Inventory Interface, it will not pick up the order line record. Reason is, it will validate and check if oe_interfaced_flag in wsh_delivery_details table is Y or not. If it is N or X inventory Interface will not pick that record for processing.

In most of cases user submit the interface trip stop while doing the ship confirm, but there are considerable cases when customer preferred to run this as a scheduled process without specifying the delivery# or Trip #, because their volume of order processing is very high and they want to run this process during some particular time of the day.

Please make a note that unless this process executes, workflow for Order line will remain at AWAITING_SHIPPING and will not progress to Fulfill and finally Invoicing .So while deciding when to trigger this program you have to make sure that when you want to Invoice customer.

Never stop execution of this program, unless you have a very valid reason. Stopping its schedule will result in piling of data in AWAITING_SHIPPING workflow status and once you start executing again after a stop it will take a time to complete.