P. 1
Order Management by ORACLEUG

Order Management by ORACLEUG

|Views: 988|Likes:
Published by PraveenReddyB

More info:

Published by: PraveenReddyB on Aug 18, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





Submitted by Anonymous on Mon, 12/21/2009 - 00:19

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

Change Logic

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.

OM-WSH Interface to Import Attribute Changes

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
■ 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
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
■ Delivery lines Released to Warehouse are reset to Ready to Release and their move order lines are
■ Reservations are split
■ Both proportional and non-proportional splits retain and split original serial numbers


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.

•OM Constraints

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->