Anda di halaman 1dari 4

Drop Shipments

Overview
Drop shipments occur when your customer orders product from you, you order the product from your supplier, and your supplier ships the
product directly to your customer. Order Management sends information to the Purchasing Application to create that PO, and then when
that PO is received (to indicate shipment from the supplier to your customer), the order line is automatically updated to indicate that it
was fulfilled.
In this process, the company running Order Management is modeled as the company to whom the end customer places the original order.
We call this process Vendor Drop Shipment, to indicate that we are defining the process from this point of view.
The Source Type attribute on the order line controls whether a line will be fulfilled internally or drop shipped. A source type of External
indicates Drop Ship. Drop ship order lines can be processed for standard items, ATO models, Non SMC PTO models and kits. SMC PTO
models cannot be used on drop ship order lines. You can define an Order Transaction type that specifies all of its lines be sourced
externally.
Required Setup
Warehouse
Consider establishing a logical warehouse to receive drop shipments. This will isolate the costs of drop shipped items from items you
physically stock. Order Management does not require you to use a special shipping organization for drop shipments, but you can choose
to do so. In that case, define the logical warehouse as a shipping organization, and enable the items you want to be drop shipped in that
warehouse.
Order Transaction Type/Line Transaction Type
Define line type/order types for your drop shipment orders that have a workflow containing the Create SupplyLine subprocess. This sub
process could have the ' Purchase Release Line Deferred' activity - so drop ship lines are automatically interfaced to Purchasing via a
workflow background process after Booking. You could include the ' Purchase Release Line - Manual' activity and allow Purchase Release to
be a manual activity i.e. run adhoc or in batch mode via the concurrent program.
Defaulting Rules
Define defaulting rules, based on conditions that make sense to your business process, for the source type attribute of the Order Line. If
you want a line to be drop shipped, make the source type equal to External. In addition, if you defined a special warehouse for drop
shipped items, you might want to create a defaulting rule to default that shipping organization to your order line.
Processing Constraints
Depending on your business needs you could use various constraints for example you could prevent changes once a PO is approved or
you could choose to disable this constraint provided you have a process to handle any exceptions from the supplier.
Depending on the status of the PO / Requisition - some typical changes allowed from the sales order are - Quantity Increases / Decreases,
Cancellations, Scheduled Ship Date, Ship To Location, or Referenced Data elements (ship method).
Depending on the status of the PO / Requisition / Sales Order Line - some typical changes allowed from the PO side are - Promise Date,
Delete Lines, or Cancellations.
Other restrictions imposed during the change management process are included in Oracle Order Management User's Guide.
Process Steps
Enter and book an order.
Defaulting Rules may set source type attribute to External through the organization level item attribute settingDefault SO source type
for the item, or you can manually choose External as the source type on the sales order line. Drop ship order lines can be processed for
standard items, ATO models, Non SMC PTO models, and kits. SMC PTO models cannot be used on drop ship order lines. The Create Supply
workflow step loads OM information into Oracle Purchasing's Requisition Import tables. Alternatively, a Purchase Release concurrent
program can be run to do the same.
Run Requisition Import in Purchasing to create the requisition.
Create a PO or autocreate a Sales Agreement PO release from the approved requisition.
When the vendor ships product to your customer, you may receive an ASN, or even an invoice, to indicate shipment to the customer.
If the vendor does not send an ASN, a receipt can be entered manually (passive receiving) to record a logical receipt.
You can set the profile PO: Automatically Deliver Drop Ship ASNs to trigger automatic receipt of the ASNs in Purchasing, or choose to have
manual intervention to receive the ASN. Inbound and outbound material transactions are automatically created for accounting purposes.
Order Management workflow proceeds to next step, typically invoicing of the end customer.
Workflow
The Generic Line workflow contains the Create Supply activity, which branches to various sub-processes based on different characteristics
of the item and sales order line.
Order Management's workflows streamline the process of loading order information into the Purchasing Requisition import tables,
eliminating the need to run the Purchase Release concurrent program. You can still run Purchase Release as a concurrent program, if you
prefer to batch up requisition lines.
Drop Ship Across Ledgers
Within a Centralized Distribution / Manufacturing environment Drop ship across Ledgers could be used for example, in a case where you
use a global/regional distribution center to gain tax advantages, you can now perform clear ' arms length' ownership transfer between the
operating unit shipping the goods and the operating unit which sold the goods and possibly one or more internal organizations.
Drop shipping across ledgers offers the ability to consolidate procurement functions for all global business units into one or multiple
Shared Service Centers. Central Procurement Organizations:
Leverage buying volume by consolidating demand across organizations
Standardize terms and conditions across all enabled organizations
Centralize supplier relationship management
Complete transactions across international borders through foreign subsidiaries/shared service centers
When goods are shipped or received, the financial ownership through these organizations does not necessarily follow the physical
movement of goods.
Drop Ship across Ledgers can fulfill drop shipments across multiple operating units (OU), ledger or legal entities, and automate intercompany transactions between multiple operating units, ledgers or legal entities.
Note: Only When using drop ship across ledgers/operating units, the requisition/purchase order is created in the operating unit of the
warehouse that has been referenced on the drop ship order line.
See: Oracle Purchasing Product and Functional Overviews,
Oracle Inventory & Cost Management Enhanced Intercompany Product and Functional Overviews

Change Management
Change management support between Order Management and Purchasing automatically propagates user initiated changes on the sales
order to the corresponding requisition/purchase order even if they are across ledgers or in different operating units.
See: Change Management for Drop Ship Orders in Oracle Order Management User's Guide.
Additional Information to Supplier
Enhanced integration between Oracle Order Management and Purchasing sends additional sales order data to the supplier.
See: Sales Order Elements in Oracle Order Management User's Guide.
Back-to-Back Orders
In an environment where lead times are often only a matter of 24 hours, you may need to create a specific supply order linked to each
customer order as soon as the order is booked, with the supply order hard pegged to the customer order that it is supplying. Once the
supply reaches the warehouse it must not be inadvertently taken by another order or demand. Additionally, where the Sales Order line is
in the process must be visible to you at all times so you can answer customer service inquiries. This process, Back-to-Back Orders, closely
links the Sales Order and the supplying Purchase Order, often where one PO is tied to one Sales Order. The following shows you how you
can model this process using Oracle Order Management and Oracle Configure-to-Order workflows.
Overview
Often customers order products that you do not typically stock but that you do not manufacture either. You may want to purchase that
item specifically for this order, have the supplier ship it to you, and then combine it with other items you may have purchased or stocked
to create one shipment to the customer. This is a common scenario for Wholesale Distributors who use the S3, or Sell-Source-Ship
business model as well as for other demand channels. We call this process back-to-back orders or procure-to-order.
Keys to making this business process work are automating the Purchasing document creation, having accurate status of where the line is
in the process, and pegging (or hard reservation) of the supply to the demand, so that the inventory isn't shipped to other customers once
it is received.
The supply-to-order process satisfies this business need through both the familiar assemble-to-order processin which a specific work
order is created to build the itemand the procure-to-order process whereby a specific purchase order is created to fulfill the sales order
demand.
Supply-to-order items are either standard items or models that have the assemble-to-order item attribute turned on. It is this attribute
that launches the ATO workflows that deliver this feature. PTO models by definition cannot be supply-to-order, since turning on the
assemble-to-order attribute would make them an ATO model. But you can fulfill the shippable options of a PTO model with back-to-back
orders by checking the assemble-to-order item attribute of those components.
Using this process, you can:
Designate the items you want to procure each time they are customer-ordered as supply-to-order.
Set up a Buy From sourcing rule for those items or, if you don't set up sourcing rules, indicate that the item is a buy item rather than a
make item.
Enter sales order lines for these items, and have the supply automatically created via a requisition. No user decision-making is required to
make this happen.
Have the requisition converted into a Purchase Order or a release of a Sales Agreement and have the PO or release sent to the supplier.
View the requisition number or PO number and its status from the Sales Order.
Accept changes to the Sales Order and have the ability to notify the buyer to take appropriate action on the associated PO.
Reserve the supply from the Requisition to the PO and finally to Inventory once the PO is received.
Pick, ship and finally invoice the customer for the product.
Features
To satisfy the above business needs, Oracle Order Management and Configure-to-Order have combined to deliver the back-to-back
business flow with the following set of features:
Auto Create Requisitions
An automatic process called Auto Create Requisition is available that creates the requisition in Purchasing for the Sales Order line. This
process takes information
from the sales order line and puts it in the requisition import interface tables so that a purchase requisition can be created. This process
can be run as a scheduled or on-request concurrent process, or can be initiated online from the Sales Order line using Progress Order'
action.
Flow of Reservation Supply from Requisition to PO to Inventory
The supply for the reservation is first linked to the requisition, then moves to the PO, and finally to Inventory as the PO is received.
Visibility to the supply for the reservation is provided in the View Reservations window.
Use of Workflow to Automate Process Steps
A branch of the existing Create Supply workflow subprocess in the seeded generic sales order line workflow initiates the autocreate
purchase requisition processing when there is a Buy result.
Setup
To setup Back-to-Back Orders in Oracle Order Management:
Use the Inventory Master Items window to define the items that you wish to supply to order. The following item attributes must be
specified:
Item must be marked as Customer Orderable on the Order Management tab and Purchasable on the Purchasing tab.
Item must be marked as Assemble-to-Order on the Order Management tab.
Note: The Assemble-to-Order attribute is actually called Replenish to Order in the database. The same flag also controls Procure-to-Order.
(This is not related to the Oracle Warehouse Management replenishment feature.)
Item must be marked as Build in WIP on the WIP tab.
Item must either have the make/buy flag on the General Planning tab set to Buy, or else have a sourcing rule saying that it is to be
sourced from a vendor.
If you define a sourcing rule for your Supply-to-Order items, then the sourcing rule must be of type Buy From. Also, you may only define
one single sourcing rule for your item, or this process will not work.
You must add this sourcing rule to the assignment set which is specified as the MRP default assignment set in the MRP: Default Sourcing
Assignment Set profile option.
Note: You may not have a combination of Buy From and Make sourcing rules or more than one sourcing rule in the assignment set for the
same item. If you do that, Auto Create Requisition errors out and puts details about the problem in the log file.
Sales Order Process

To enter orders using Supply-to-Order items:


Enter the item on the Sales Order line.
When the line is Booked/Scheduled, the Create Supply subprocess of the workflow will put the lines through the Buy ATO Item flow which
contains the autocreate purchase requisition activity. AutoCreate Requisition can be run as a concurrent program or can be initiated for an
individual order by using the Progress Order action on the sales order if it is in status Create Supply Line Eligible. As stated above,
AutoCreate Requisition takes information from the Sales Order line and loads the Requisition Import interface tables.
Requisition Import must be run to create the purchase requisition tied to the sales order line. This can be done by manually submitting the
Requisition Import concurrent program, or you can schedule it to run automatically. Requisitions created by this process all have an
interface source type of CTO so you can identify and segregate these requisitions as needed. There are also message dictionary entries
for CTO Note to Receiver that can be populated with custom text. The requisition column Note to Buyer is populated by the AutoCreate
Requisition process with a message Supply for sales order: <order number> that indicates the order number of the line. Add additional
custom text to the note by editing the message dictionary for CTO Note to Buyer.
Purchasing Process
Once the purchase requisition is created and identified as CTO, the regular purchasing process takes place:
A Purchase Order is created and approved and sent to the necessary supplier, or a release of a previously created Sales Agreement is
used.
Once the PO or release is received, the items are recorded in inventory and a reservation is automatically made to the sales order line.
Note: View the Note to Buyer at any point in this process to find out what sales order generated this PO or release.
The sales order can now be pick released, shipped and invoiced just like other stocked items.
Sales Order Line Status
The following line statuses help you track where the line is in the process:
PO Req Requested
PO Req Created
PO Created
PO Received
If you want to see the Requisition number or Purchase Order number created by your Sales Order line, you must go to the Reservations
Details window to find that information.
Reservations
A key in making this functionality work for you is how the inventory reservation is handled. This happens automatically, and can be traced
from the sales order window by using Tools->Scheduling->Reservation Details as well as by directly using Inventory's Supply/Demand
forms.
When Req Import processes, the purchase requisition is reserved to the sales order line. View the Inventory Reservations window supply
tab to see the reservation linked to a requisition, and the requisition number and line number.
When the requisition becomes a PO or a Sales Agreement release, the reservation moves with it. The Reservations window, supply tab,
then shows the reservation is linked to a PO or a Sales Agreement, and you will see the PO number or the PO and release number, as well
as the line number.
When the PO is received into inventory, the reservation is automatically transferred into Inventory, and it now looks like any other
reservation from a sales order to on-hand stock.
Just as in the regular ATO process, if you manually reserve the sales order line to inventory the Create Supply workflow step will not do
anything, and the line will progress to Awaiting Shipping without flowing through the requisition process.
Changes or Cancellations
What happens if you need to make changes to the sales order line that is in the back-to-back process? What if the order line is cancelled?
What if you need to make changes to the PO or the requisition?
If the sales order line is cancelled or the quantity is reduced, then the reservation is reduced and a notification is automatically sent to the
buyer explaining that there is now a PO outstanding for a higher quantity than what is needed for the sales order. The buyer can then
decide whether to cancel the PO line, or to buy the product anyway and put it into inventory.
If the schedule date on the sales order line is changed, again a notification is sent to the buyer, who can then decide to either change the
date on the PO or cancel it or do nothing. If the buyer decides to cancel the PO, then a new requisition will be created the next time
AutoCreate Requisition is run.
If the PO is cancelled or a partial quantity is cancelled, then the reservation is cancelled or reduced appropriately. The next time
AutoCreate Requisition is run, it will create another requisition for the unreserved amount on the sales order.
Note: User initiated splits are not enabled on a back to back sales order line that is purchase released and the reservations are against
Purchase Order or Purchase Requisition.
Miscellaneous
Drop Shipments
Drop Shipments is similar to this back-to-back process in that your sales order line creates a requisition line that becomes a PO sent to
your supplier. In a drop shipment; however, you instruct your supplier to send the item or configured item directly to your customer. The
items never physically pass through your warehouse, and therefore you do not pick, pack or ship them yourselves. In the back-to-back
scenario, you instruct your supplier to send you the goods, and then you ship them on to your customer.
Supply Type for Reservations
There is a Supply Type of External Requisition to inventory reservations that also shows the purchase order or requisition that the
reservation is made to in the Inventory Reservations window.
Debugging
The AutoCreate Requisition program uses the OM debug system. This means you can generate a debug file if you set the OM debug profile
and the OM debug log directory profiles and then run the program.
Purchasing has its own debug profile which is used by Requisition Import to log messages, but any messages regarding the reservations
are logged using OM's debug facilities.
Fulfillment
Order Management provides the functionality required to recognize fulfillment of an order line, and delays processing of some order lines
until related order lines have been fulfilled.
Introduction
Oracle Order Management enables you to group lines into a fulfillment set and to establish a gate activity in your workflow process. Lines
in a fulfillment set will wait until all lines in the set have been fulfilled to proceed through the gate. This gate is known as the fulfillment

activity. The fulfillment feature is primarily designed to allow the grouping of related lines and to keep any lines in the group from being
invoiced until all lines have been fulfilled.
Terminology
The following terms will be used to describe fulfillment:
Fulfillment activity: The synchronization point or gate in the workflow process at which lines wait for other lines to be fulfilled.
Fulfillment method activity: The activity in the workflow process which indicates that the line has been fulfilled.
Fulfillment set: A group of lines which must all be fulfilled before any of the lines proceed beyond the fulfillment activity in the workflow
How it Works
The fulfillment activity is a seeded workflow activity named FULFILL_LINE. This activity is the synchronization point between the lines of a
fulfillment set.
There are two activities that are considered fulfillment method activities in the seeded OM workflows. For a standard shippable line the
fulfillment method activity is the shipping activity. For a return line the fulfillment method activity is the receiving activity. You may define
any activity as the fulfillment method activity in a workflow process. The fulfillment activity must be between the fulfillment method
activity and the invoice interface activity in the respective workflows.
When a line workflow reaches the fulfillment activity, the activity checks to see if the fulfillment method activity (for example, shipping or
receiving) completed successfully. If so, it updates the fulfilled quantity on the line with the shipped or received quantity, and sets the
fulfilled flag to Yes. It then checks to see if the line is part of a fulfillment set. If not, then it completes the fulfillment activity and continues
with the next activity in the workflow process. If the line is part of a fulfillment set, it checks to see if the other lines in the fulfillment set
are fulfilled. If any lines are not fulfilled, it waits at the fulfillment activity. If all the lines are fulfilled it completes the fulfillment activity for
all the lines in the fulfillment set.
Service lines behave differently in Fulfillment Sets depending on the business scenario. The most common business scenario is to order a
product with an associated Service line on the same order. In this situation, it is not necessary to assign a Fulfillment Set to the Service
line as the Fulfillment activity takes care of fulfilling the product and Service line as a Fulfillment Set, implicitly. There are business
scenarios where Fulfillment Sets can be assigned to Service lines. One scenario is in the case of ordering a Customer Product with an
associated Service line. A second is when placing an order for a Service line associated to a product which is not in the same order.
PTO Models and ATO Models are treated as inherent Fulfilment Sets by the system. As an example, A PTO Model is ordered, the Fulfilment
Set field does not contain a value yet all nonshippable lines from the Model wait at the Fulfilment activity for the shippable lines prior to
progressing.
Setup
No setup is required to use the fulfillment functionality with the seeded workflows. If you create your own workflows, include the
fulfillment activity before invoicing in each process. This will provide two benefits: it will update the fulfilled quantity for the lines, and it
will allow you to use fulfillment sets. For each workflow process that you define, you will need to check the attributes of the FULFILL_LINE
activity. The FULFILLMENT_ACTIVITY attribute must be your fulfillment method activity, which in the seeded flows is either the shipping
activity or the receiving activity. The COMPLETION_RESULT should be the result with which the fulfillment method activity completes if it is
successful. This allows you to designate any activity as a fulfillment method activity.
If you have a workflow process with two separate branches, such as a single workflow process with separate branches for ordered items
and returned items, then you should have one fulfillment activity for each branch which relates to the fulfillment method activity for that
branch.
Implementation Considerations
You can have multiple fulfillment sets in a single order. If a line is a member of two fulfillment sets then all lines from both fulfillment sets
must be fulfilled for any of the lines to complete the fulfillment activity.
If a line workflow process with a notification is in a fulfillment set, and the notification is rejected, then the other lines will not progress in
their flows. You will have to delete or cancel the rejected line.
Example
Assume that you enter an order with four lines:
Standard Item 1
Standard Item 2
An item which is shippable
An extended warranty for that item.
You would like to send the customer two separate invoices: one for the two standard items; and a second for the item with an associated
extended warranty.
Put the two lines with standard items into a fulfillment set. Select Sets > Assign a Fulfillment Set Name, 2 from the context menu. The
Fulfillment activity recognizes the service item as associated to the shippable product and considers the two in a Fulfillment set even
though a Fulfillment Set name was not identified on either line. You would not want to bill for the service contract until the item was
shipped. The service item will wait at the fulfill line activity until the shippable line arrives there, and then both lines will continue to
invoicing at the same time.
When the order is booked, the shippable lines must complete the scheduling and shipping activities. These activities are not applicable for
the service contract, so they will complete immediately. The two standard items will progress through the Fulfillment activity as Fulfillment
Set 2. Similarly, the shippable line and the service contract will progress through the Fulfillment activity together as an implicit Fulfillment
Set.