Change Orders in Oracle Shipping Execution
In the course of business, Customer Sales Representatives (CSR) enter sales order changes in Oracle Order Management (OM) or Oracle Project Contracts. Changes are required when customers ask to change quantity or shipping information, reschedule or cancel a sales order. The OM Change Management in Shipping design improves the synchronization of delivery lines and reservations with the order lines when they are changed.
Prior to the Order Management Change Management design, changes to pickable orders were allowed as long as the orders were not booked or interfaced with Oracle Shipping Execution. However, once the orders were interfaced into Shipping
and Pick Released, changes to the sales orders were limited. The objective of the Line Change Management design is to allow most of the sales order changes up until the delivery lines are Staged or Ship Confirmed. Only changes entered after the sales order lines are booked and interfaced with Shipping Execution are validated by the change logic in Shipping Execution. Order Attribute changes propagate in Shipping Execution based on the Shipping Execution change logic.
The following table lists sales order line changes resulting from Order Management updates. The change category letters correspond to Shipping Execution change logic as follows:
- ■ A: Change in Quantity
- ■ B: Change Organization, Inventory and Unschedule
- ■ C: Change in Schedule Date
- ■ D: Change in Ship Sets or Arrival Sets
- ■ E: Change in Delivery Grouping Attributes
Before changes are considered, all line imports and line splits must be processed. The WSH_INTERFACE holds, in any order, the 3 types of entries from Order Management interface API call:
■ Requests to Import lines and create matching deliveries (I - Import)
■ Split existing delivery lines (S - Split)
■ Order Management changes request to Update Shipping Attributes (U - Update)
Shipping scans all entries through WSH_INTERFACE to process Order Management entries in the proper order. The Shipping change validation logic is initiated for interface lines where the action flag value is set to U for Update.
When a change is requested, the attribute change category is evaluated to determine what type of validation and action is needed to successfully update the Shipping attributes.
Order and Delivery Status Mapping
The following table shows the correlation between Sales Orders in Order Management and the related Shipping Deliveries status. Changes to sales order lines not interfaced from Order Management to Shipping are not restricted by Shipping. For sales order lines interfaced from Order Management to Shipping, changes are allowed based on attributes updates if the deliveries are not closed. No changes are allowed for Confirmed or Shipped deliveries if the interface between Shipping and Order Management has not run to update the sales orders.
Order Management initiates a change by passing updated sales order data to Shipping and setting the Interface Action flag to the Update value. Shipping processes all interface data by:
■ Importing order lines to create delivery line details for newly inserted records. (I)
■ Processing Split request for existing delivery lines. (S)
■ Shipping change validation determines what attributes have been changed. (U)
Based on the attributes changed, distinct validations are applied to propagate the order changes to Shipping delivery lines.
Shipping Attribute Change Validation Logic
The change validation logic is initiated for WSH_INTERFACE.Update_Shipping_Attributes lines where the Action Flag is set to U. The distinct attribute changes that need validation are classified in the following categories:
■ Change in Quantity
■ Change Organization, Inventory, and Unschedule
■ Change in Schedule Date
■ Change in Ship Sets or Arrival Sets
■ Change in Delivery Grouping Attributes
Changes to other attributes are propagated if the delivery status is not Shipped or Staged/Pick Confirmed.
Existing and new inventory reservations are managed by Shipping as detailed in the following section.
Inventory Reservations Logic
The Inventory reservation logic was redesigned so shipped quantities can always be matched with existing reservations during Inventory interface after Ship-confirmation. The reservations tables are part of the Oracle Inventory product.
Inventory internal Applications Program Interfaces (APIs) are used to create, update, or cancel reservations stored in the Inventory tables. These APIs are called by Order Management and Shipping code to manage reservations and reservation
splitting.
Reservation management by Order Management and Shipping:
■ When an order is booked, the Order Management code creates reservations by calling Inventory APIs.
■ After the order lines are interfaced in Shipping, existing Inventory reservations are managed in Shipping by calling Inventory APIs.
■ Order Management does not update reservations with changes after booking.
Instead, Shipping updates, creates, or deletes reservations for changes originated in Order Management.
■ Overpicked quantities do not have existing reservations when orders are interfaced. Shipping creates additional reservations so all picked inventory items can be tied to the reservation.
Delivery Line Split
When an interfaced order line is split, Order Management requests a delivery line split by setting the OM-WSH interface API action flag to S for Split. As Shipping splits a delivery line, it also synchronizes the Inventory reservation and splits and the move order line. Split is allowed for delivery lines not ship confirmed.
■ Delivery lines Released to Warehouse are reset to Ready to Release and their move order lines are canceled
■ Reservations are split
■ Both proportional and non-proportional splits retain and split original serial numbers
Setups
There are no mandatory setups to enable the Change Management functionality. Order Management provides constraints that can be customized during implementation. These constraints are used to prevent sales order changes after the
associated delivery lines have been pick confirmed in Shipping. If you choose to remove these constraints, it is recommended that you implement a two-step shipping process (Confirm/Close Delivery then Ship Confirm) or to
always make sure the deliveries are ship confirmed as soon they are loaded or picked up by the carrier. If the system is not accurately updated in real-time, changes may be allowed after the deliveries are far-gone.
Comments
Post new comment