Interface Trip Stop (ITS) in Order Management

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 uncheck the ?Defer Interface? checkbox. By Default this check box is uncheck 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 it make update on oe_order_lines_all table as well as wsh-delivery_details and once this part executed successfully only then SECOND phase of ITS has 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 you data. Reason ? 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.

I have observed that in most of time 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 execute, workflow for Order line is remain at SHIP_LINE Notified 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.

One piece of advice that I will give here is, Never try to stop execution of this program, unless you have a very valid reason. Any halt in ITS will result in piling of data in SHIP_LLINE notified workflow status and once you start executing again after a stop it will take a deep dive in terms of your performance.

Oe_interfaced_flag and Inv_interfaced_flag in wsh_delivery_details table

This post is about 2 Important fields in wsh_delivery_details table from the Order Management and Inventory point of view.

These 2 flags/fields are

1.      oe_interfaced_flag

2.      inv_interfaced_flag

these plays very important role during the ship confirm process.
As I have stated in many of my posts on ITS that interface Trip Stop(ITS)has 2 parts

1.      Order Management and 

2.      Inventory. 

OM part will takes care of updating the fields in oe_order_lines_all tables like shipping_quantity , shipped_quantity etc and INV part take care of releasing the reservation once OM part is done.

NOTE - Inventort part of the ITS always exected once OM part exected successfully.

If OM part of ITS has executed , but INV is not yet exected because of some issues then oe_interfaced_flag = Y and inv_interfaced_flag remains = X(Pending) or N . In such case we have 2 options run the ITS again  ( but this time it will executed INV part only and release the reservation and decrement the stock) , or run the "Inventory Interface Concurrent Program"

But many a time I have noticed that delivery is shipped and shipped/shipping qty etc fields got populated , but oe_interfaced_flag = N and INV_interfaced-flag = N and every run of ITS try to ryn the OM Part and erroring out( as action that should be perofrmed by ITS has already completed). In such case one good option is update oe_interfaced_flag = Y and then run ITS gain or run inventory Interface.