Sie sind auf Seite 1von 9

Audit history in OM

Back to Back Orders

In today’s environment where lead times are often only a matter of 24
hours, many companies want to create a specific supply order linked to
each customer order and they want these supply order created as soon as
the customer orders have been booked. These companies want to have
the supply order “hard pegged” to the customer order that it is supplying,
and once the supply reaches the warehouse they do not want it
inadvertently taken by another order or demand. They also need v isibility
to where the Sales Order line is in the process at all times, so they can answer
customer service inquiries. We call this process ‘Back-to-back orders’,
indicating that the Sales Order and the supplying Purchase Order are very
closely linked, often where one PO is tied to one Sales Order. This paper shows
you how you can model this process using Oracle Order Management and
Oracle Configure-to-Order workflows.

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 (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.
This paper attempts to explain how this business process has been
implemented in Order Management using Configure-to-Order workflows, and
offers some insight into putting it to use.

To satisfy this business need, we have modeled a process called ‘supply-to-
order’ which includes both the familiar ‘assemble-to-order’ process in
which a specific work order is created to build the item and ‘procure-to-
order’ (or back-to-back orders) whereby a specific purchase order is created
to fulfill the sales order demand.
‘Supply-to-order’ items are either standard items or (with OM Family Pack H)
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
have the shippable options of a PTO model be fulfilled via back-to-back orders
by checking the ‘assemble-to-order’ item attribute of those components.

Oracle Order Management and the Oracle eBusiness suite provide you with
the features you need to meet and exceed your requirements around back-to-
back orders. With release 11i7, 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
• Have the requisition converted into a Purchase Order or a release of a
blanket Purchase Order, and have the PO or release sent to the supplier.
• View the requisition number or PO number and its status from the Sales
• 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 the Sales
Order once the PO is received.
• Pick, ship and finally invoice the customer for the product.

The following must be done to use Back-to-Back orders in Oracle Order
Define Items
Use the familiar Inventory Master Items form 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. (This attribute is actually called ‘replenish to order’ in the
database. There is an enhancement pending to change the prompt for
this field on the Master Items form, to reduce confusion now that this
flag also controls procure-to-order’.)
• Item must be marked as ‘Build in WIP’ on the BOM tab. There is an
enhancement pending to remove the dependency of this attribute
being checked, but for now, you have to do this to make this process
• 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.

Define Sourcing Rules

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 then 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
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 will error out, and will put details about what
the problem was in the log file.

Sales Order Process

Entering orders using ‘supply-to-order’ items is easy and straightforward. Here
are the steps:

1. Enter the item on the Sales Order line as usual.

2. When the line is 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.

3. Next, 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 if you desire.
The requisition column ‘Note to Buyer’ is populated by the AutoCreate
Requisition process with a message ‘Supply for sales order: <order number>’,
so you can see what order number this line is for. You can add additional
custom text to the note by editing the message dictionary for 'CTO Note to
Buyer'. There are also message dictionary entries for 'CTO Note to Receiver’
which can be populated with custom text.

Purchasing Process
Once the purchase requisition is created and identified as ‘CTO’, the regular
purchasing process takes place.

1. A Purchase Order can be created and approved and sent to the

necessary supplier, or else a release of a previously created Blanket PO
can be used.
2. In either case, once the PO or release is received, the items are
recorded in inventory and a reservation is automatically made to the
sales order line.
3. Throughout this process, you can know what sales order generated this
PO or release by viewing the ‘Note to Buyer’, as indicated above.
The Sales Order can now be pick released, shipped and invoiced just like other
stocked items.

Sales Order Line Status

There are several new line statuses that have been introduced as part of this
functionality. These statuses help you track where the line is in the process.
The new statuses are:

• 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 form to find
that information.

So 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? Or 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

What about Drop Ship?

How is this process different from Drop Shipments? In both cases, 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.

Optimizing Performance for the Order Management

Booking Process

The intent of this document is to discuss methods to consider when streamlining the booking process
within the Oracle Order Management application. There are a number of variables to consider when
trying to improve performance for booking, such as, tax calculation, pricing strategy, hold definitions,
etc. Therefore, this document will certainly grow as the booking process performance is refined. For
the inception of this paper, the first variable discussed involves scheduling.
Defer Scheduling
In order to pick release a sales order line, a schedule date is required. In release 11i, if no schedule date
is populated on the order then scheduling code must be run in order to populate this required field. The
scheduling routine uses pertinent information from the order line to derive the best schedule date. The
minimum information from the order line includes the Item, Quantity, Unit of Measure and Request
Optional information may include more detailed data such as the Inventory Organization (Warehouse)
and the requested Schedule Date. This information is used to perform a query mainly against the
MSC_DEMANDS, MSC_SALES_ORDERS and MSC_SUPPLIES tables to determine the appropriate
schedule date. The request and/or results are temporarily stored in the MRP_ATP_SCHEDULE_TEMP

Method 1 – AutoScheduling: If Autoscheduling is turned on, the scheduling function is

automatically run to populate the schedule date when the line is first saved to the database. To
determine quickly if the AutoScheduling is defaulted to on, query up a sales order line and choose
‘Tools’ from the Menu, if the ‘AutoScheduling’ is checked then it is turned on by default.

Method 2 – Specify a Schedule Ship Date - If a ‘Schedule Ship Date’ is specified on

the order line, it is validated through the scheduling routine when the order line is saved. For entering
and booking functions, the ‘Schedule Ship Date’ is an optional field. It is only required in order to Pick
Release the order line. The Schedule Ship Date may be manually entered or automatically populated by
the Defaulting Rules.

Method 3 – Workflow Function - Finally, Scheduling may be invoked through a function

call as part of a workflow activity. In the seeded workflow process, ‘Line Flow – Generic’, the
scheduling function is not deferred after the booking function is run. Therefore, scheduling is
immediately performed as the end user waits for control to return to the form. This is equivalent to
running the scheduling function as if AutoScheduling were turned on, only it is done after booking
and not upon the first commit of the line.
Configuring the system to defer scheduling requires the following steps:
 Turn AutoScheduling Off
 Ensure the Schedule Date is not populated by Default Rules or manually entered
 Modify the Line Process Flow to Defer Scheduling.

Turn AutoScheduling Of
OM: AutoSchedule is set to ‘No’.

Ensuring the Schedule Date is not populated

To prevent the scheduling code from being run requires that a schedule date not be populated on the
order line of the order. Direct the users not to insert the schedule date when entering order lines. The
other method of entering the schedule date is to allow the defaulting rules to populate the field. There is
no seeded defaulting rules for the schedule ship date, and you must be certain that a customized rule
was not entered. This can be easily confirmed by querying the Defaulting Rules form (OM: Setup +
Rules + Defaulting) for the ‘Order Line’ entity. With your cursor on the ‘Schedule Ship Date’ field
click on the ‘Defaulting Rules’ button. Validate that no rules exists as shown below: