Automated Drop Ship Order Processing in R12

Kenneth B. Montgomery
BizTech
Introduction: This presentation will demonstrate the functional and technical aspects of an automated sourcing
model for a non-profit enterprise in the commodity business. Sales Orders from iStore and the Electronic Data
Interchange (EDI) are automatically sourced using custom sourcing logic, with override capabilities included.
Outbound purchase orders utilize advanced pricing and the Approved Supplier List. Advance Ship Notices, supplier
and customer invoices and 846 Inventory feeds via EDI complete the end-to-end solution.
This paper is primarily a functional summary of the solution which was implemented for the above client. I will
touch on technical aspects, but will not include the SQL behind any of the customizations in this paper. That level
of detail is for another paper with a different focus.

Client Requirements
The solution described in this paper was implemented in R12.1.3 for a client with non-profit status serving a diverse
mix of government agencies. Their business model was strictly to act as a broker between government buyers and a
small group of Suppliers, never physically handling the goods being sold. This is consistent with the pure drop ship
model as shown in Fig. 1 below.

Fig. 1 Drop Ship Model

COLLABORATE 11
1

The challenge was to design a solution which streamlined the Drop Ship Order to Cash as well as Procure to Pay
cycles and required minimal human intervention.

Solution Overview
At a 10,000-foot level, the solution was designed for maximum use of EDI transactions, using the XML Gateway,
B2B Adapters and BPEL Processing which is part of the SOA Suite in R12. Front-office order processing was via a
customized iStore e-commerce site. Manual processes normally done to progress the Drop Ship workflow were
automated to streamline the various phases of the order fulfillment to cash cycle. Lets start with iStore features and
then move on to EDI.
Oracles iStore application was implemented as an e-commerce transactional website for government buyers. A
number of enhancements and customizations were developed to provide a more complete shopping experience,
utilizing custom section templates, JSP pages, JavaScript, html and various custom programs. Other custom features
included enforcement of MOQ, shop by brand partner, display of environmental icons based on descriptive
elements in an Item Catalog Group, and custom shipments tracking.

Order Status
One design challenge was how to control the order status once an iStore shopping cart was converted to a Sales
Order in Order Management. Standard functionality is to control this using the system profile IBE: Default Order
State which can have a value of Entered or Booked. However, for this client there was a need to import orders
with either status depending on certain order attributes. Dynamically flipping the profile was ruled out as a
solution, so the profile was set to default a status of Entered. In order to subsequently book orders as appropriate,
we developed a custom stored PL/SQL procedure which called the order booking API in OM for orders with
Source_Type = iStore Account as long as no exceptions were indicated on the order.
Exceptions are programmatically identified in iStore using custom java code. When so identified, an order header
DFF attribute is populated with the specific exception(s) and imported into OM with this value(s). Orders imported
with ANY exceptions are ignored by the booking program and left in Entered status for review by Customer Care
personnel. Examples of exceptions include large orders (qty > 400), APO/FPO orders for military destinations,
custom logo orders, and orders not satisfying MOQ, among others. Orders untouched by the booking program are
identified daily by Customer Care, updated and then booked manually to speed order fulfillment.

Sourcing Considerations
The client does business with about (100) approved suppliers, most of which are direct delivery providers of the
goods they assemble or manufacture. There are also (3) suppliers who are distributors or wholesalers, stocking
product from the other suppliers and offering shorter delivery intervals for a slight price premium. This mix of
suppliers comprised the potential sourcing of Purchase Orders which will be detailed later.
All items were required to use approved suppliers, so the Master Item attribute was checked to ensure this
requirement was always met. Each item has between 1 and 4 approved suppliers, with one always flagged as
primary on the Approved Supplier List (ASL).

COLLABORATE 11
2

See Fig. 3 below for a typical ASL entry, with each supplier having their own unique internal identifier for any
given Oracle item. All transactions with a supplier were required to include the corresponding Supplier Item or else
clear communication could not take place.

Fig. 3 Typical ASL Key Attributes entry for an item

Contract Purchase Orders are utilized as the ASL source document as shown below in Fig. 4. The decision to utilize
contract POs over Blanket POs and Blanket Releases was driven by the use of Advanced Pricing in Purchasing
which is new to R12.

Fig. 4 Typical Source Document setup on ASL

Separate supplier price lists are maintained for each supplier in Purchasing, where all approved items for a given
supplier are listed with their unit prices, effective dates, etc. In order for the pricing engine to utilize these supplier
price lists during PO creation, each must have a price list header qualifier which references that suppliers Contract
PO as shown below in Fig. 5. Note that the Value From on the qualifier is the same as the document Number in
the ASL attributes in Fig. 4 above. With the use of this qualifier, a particular suppliers price list would only be
called by the pricing engine if it met the qualifying criteria.
Separate supplier price lists also had the added advantage of maintaining pricing history, since the client conducts
quarterly pricing reviews and updates. This would not be easily accomplished if the sourcing document was a
Blanket PO.

Fig. 5 Supplier Price List Qualifier Contract PO

COLLABORATE 11
3

In order to fully integrate the Contract PO solution, a key setup was required on the Purchase Requisition document
type as shown below in Fig. 6. Use Contract Agreements for Auto
Auto-Sourcing must
st be checked for the sourcing
process to autocreate
create Standard POs from the requisitions associated with a drop ship sales order.

Fig. 6 Purchase Requisition Document Type

Drop Ship Review

It is appropriate to take a quick review of the drop ship order flow in Oracle. It starts with a sales order line with
SOURCE_TYPE set to External, where the term external indicates the source of the supply is from a Supplier
which is external
ternal to the selling company. The Line Flow Generic line workflow branches
es on this source type as
shown below and makes the line eligible for Purchase Release,
e, which is the integration between OM and Purchasing
for drop ship.

Fig. 7 Order Line Workflow for Drop Ship

Subsequent running of the Workflow Background Process for OM: Order Line will complete the deferred activity
shown above and insert lines into the REQUISITIONS_INTERFACE_ALL table. Requisition Import is run which
generates an approved requisition. For some clients, the Autocreate process to convert a requisition
requisiti to a Purchase
Order or release against a Blanket PO is done manually. However, for this client, that process needed to run in the
background and generate approved Standard POs for approved suppliers.
In order for the deferred activities to complete and for the order line status to be updated from Booked to Awaiting
Receipt, you must populate the OM System Parameter Requestor For Drop Ship Orders Created by External User
with a person who has an HR record and is therefore an employee. This does not have
ve to be a real user, since a
dummy HR record will suffice for the CREATED_BY record in the workflow. Without this parameter being set,
drop shipp orders created by iStore custom
customers (i.e. external users)) will not be allowed to progress in the workflow by
the Workflow Background Process.
Typically, when the goods are shipped from the supplier to the customer against a Drop Ship order, an Advance
Ship Notice (ASN) is sent to the selling company to indicate fulfillment of the order. A PO receipt is processed
proces
for
the quantity that was shipped against the appropriate PO shipment line. The Ship step in the line workflow is
completed and the order line status is updated the Receiving Transaction Processor from Awaiting Receipt to
Shipped. Subsequent running of the Workflow Background Process for OM: Order Line will update the line status
to Closed. Invoice lines are inserted into the AR invoice interface to be processed by the next Autoinvoice Master
Program, typically a daily batch process scheduled off
off-hours.

COLLABORATE 11
4

Shortly after the ASN is sent by the supplier, an AP invoice is sent to be matched on the receipt triggered by the
ASN. For this client, we set the match level to 3-Way for the AP invoices. This mandated the proper sequencing of
EDI transactions in AP to prevent invoice holds during validation.
If a partial shipment is processed based on the ASN data, then the Receiving Transaction Processor will split the line
in OM and interface the shipped quantity to AR and leave the unshipped quantity on a split line in Awaiting Receipt
status. This is standard functionality, the external equivalent of a partial ship confirm of an internal shipment
splitting the line in shipping execution. This was essential functionality for this client, as partial shipments were a
common practice for their suppliers and distributors in the event of insufficient onhand stock.

Custom Sourcing
The client requested a custom sourcing program be implemented which would utilize a multi-tiered approach to
determining the sourcing for any given sales order line. A simplified version of this program was implemented, but
a more complex algorithm is likely to be instituted in the future. Their sourcing program is referred to as Second
Call, the implemented version of which uses the 4-tier logic listed below. A sourcing decision is made upon the
first clear winner when cascading from Tier 1 down, subsequently ignoring the lower tier decision points when
that occurs. As such, it is unusual for Tier 4 (primary supplier) to be the deciding factor.
Tier 1 Look at onhand supplier inventory and source to the supplier with sufficient onhand to fulfill the order.
Note: Onhand quantities are populated from a daily Inbound 846 via EDI feed to be explained later.
Tier 2 In the event no suppliers have sufficient onhand or if multiple suppliers have sufficient onhand, source to
the highest Supplier Rank (as currently maintained in a Supplier DFF).
Tier 3 In the event the Supplier Rank is the same for competing suppliers, then compare supplier prices for the
item in question and source to the lowest-price supplier.
Tier 4 In the event Tiers 1-3 results are all the same (ie, there is a tie), then source to the primary supplier as
flagged on the ASL in DFF attribute1.
Grouping of PO lines on a Standard PO was also an issue with the client, with a requirement to never create a PO
with shipments to multiple customers. In other words, there could only be ONE customers shipments on any given
PO. Standard Oracle grouping of lines will use the Group By parameter in the Requisition Import concurrent
program and subsequently create POs with lines from multiple sales orders (and therefore multiple customers). By
using a unique generated sequence number, we were able to ensure this requirement was met.
The custom sourcing program was developed to use the Second Call logic described above, but also to meet the
grouping requirement as well. The fields listed below are updated by a stored PL/SQL procedure on lines in the
REQUISITIONS_INTERFACE_ALL table. Setting the autosource_flag field to N allows us to specify the
supplier and supplier site based on Second Call and source to the logical Supplier. By making the group_code
unique for a given Sales Order, we are able to ensure the clients requirement of not mixing Customers on a PO.
1.
2.
3.
4.

AUTOSOURCE_FLAG = N
SUGGESTED_VENDOR_ID = Supplier chosen by Second Call logic
SUGGESTED_VENDOR_SITE_ID = Site ID for the above Supplier
AUTOSOURCE_DOC_HEADER_ID = Contract PO ID

COLLABORATE 11
5

5.
6.

DOCUMENT_TYPE_CODE = 'Contract
GROUP_CODE = unique number based on Sales Order

A sourcing override was built into the solution, whereby a Customer Care representative could specify the supplier
on a Sales Order Line DFF. The LOV for the Sourcing Vendor DFF is a table-validated value set which limits the
values to only approved suppliers of the ordered item as shown below. The Second Call sourcing program will
update lines in the requisition interface table based on the DFF and ignore the 4-tier logic above.

Fig. 7 - Sourcing Override DFF on SO Line

The following tables are affected by the custom sourcing program, either by select or update statements as indicated
in Fig. 8 below:

Select
PO_REQUISITIONS_INTERFACE_ALL
OE_DROP_SHIP_SOURCES
OE_ORDER_LINES_ALL
OE_ORDER_HEADERS_ALL
PO_HEADERS_ALL
PO_APPROVED_SUPPLIER_LIST
PO_ASL_STATUSES
PO_VENDORS
QP_QUALIFIERS
QP_LIST_HEADERS_B
QP_LIST_LINES
QP_PRICING_ATTRIBUTES
QP_QUALIFIERS

Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y

Insert

Update

Delete

Fig. 8 - Table View and Usage for Sourcing

In order to enable automatic PO creation for Drop Ship orders, the following workflow attributes must be set on
CREATEPO and Requisition workflows. Otherwise, the Autocreate and PO approval submissions become a
manual process.

Is Automatic Creation Allowed = Yes

Is Automatic Approval Allowed = Yes

Send PO Autocreation to Background = No

COLLABORATE 11
6

EDI Transactions
If you Google EDI it will return a host of technical and non-technical results, but a general definition found on
Wikipedia reads as follows and it is a good starting point for the discussion. This paper will not delve too deeply
into the technical side of EDI, as that is a subject for a technical consultant to present.
Electronic data interchange (EDI) is the structured transmission of data between organizations by electronic
means. It is used to transfer electronic documents or business data from one computer system to another computer
system, i.e. from one trading partner to another trading partner without human intervention.
See Fig. 9 below for a basic schematic for a typical inbound EDI transaction. The net result, assuming all mapping
and configurations are in order, is for the transaction to be inserted into the appropriate Oracle interface table(s) such
that concurrent import programs can run to process the records and create the appropriate Oracle entities such as
Sales Orders, PO Receipt, or an AP Invoice.

Fig. 9 Inbound EDI Process Flow

Putting the above diagram into words, the following steps are accomplished for an inbound EDI transaction:
1.
2.
3.
4.
5.

Oracle B2B converts the native EDI format files/messages into EDIXML messages.
BPEL converts EDI XML into OAGXML and queues the messages.
Workflow deferred agent listeners un-queues the message.
XMLGateway populates interface tables from the OAGXML
Import programs run, utilizing standard validations in order to create an Oracle document.

The flow for an outbound EDI transaction is essentially the reverse of the above, except the interface tables are not
in the flow. This is because the entities (such as AR invoices or POs) already exist and are merely being sent to an
outside Trading Partner such as a Customer or Supplier.
1.
2.
3.

E-Business Suite Workflow will raise a specific business event

XMLGateway queues up the message
BPEL Process manager un-queues the message and converts OAGXML to EDIXML

COLLABORATE 11
7

4.

Oracle B2B converts the EDIXML to native EDI format message

This implementation involved the mapping of multiple EDI transactions in XML, B2B and BPEL as listed below:
1.
2.
3.
4.
5.
6.
7.
8.

Inbound 850 Purchase Order

Outbound 850
Purchase Order
Outbound 860
PO Change
Inbound 856 Advanced Ship Notice
Inbound 810 AP (Supplier) Invoice
Outbound 810
AR (Customer) Invoice
Inbound 846 Supplier Inventory
Inbound 997 Functional Acknowledgement (of EDI transmission receipt)

EDI Customizations
Besides the standard functionality of EDI, a number of customizations or extensions were implemented with the
solution as described below. All of them were designed to minimize manual intervention, consistent with the overarching goal of the implementation.
For an Inbound 850, a lookup was done to the existing customer base to see if the transmission was from an existing
or represented a new customer (which, in turn, needed to be created). In some cases, the transmission was from an
existing customer but for a new Ship To or Bill To address. There was a lookup to see if the addresses existed as
customer site, and if not, they were created via an EDI extension program. To ensure uniqueness, a convention was
established for the EDI Location Code assigned to a new customer site as follows:
Account Number + State + Party Site ID
So for a new site on account 15000 with a PA state address and site ID of 2222, the EDI location code is set as
15000PA2222.
For Inbound 850, there was a small subset of items which the GSA had different primary UOMs defined in their
systems relative to Oracles primary UOM. This was causing validation failures upon order import. Rather than
wait for GSA to correct their data, we developed a PL/SQL procedure that runs from a custom trigger on the
OE_LINES_IFACE_ALL table records. When a line contains one of a specified list of items, the program is called
to update to Oracles primary UOM, thus allowing those records to pass the previously failed validation for the next
scheduled order import.
Daily Inbound 846 files are not processed per standard Oracle EDI functionality which would normally be to
increment onhand quantities into the MTL_ONHAND_QUANTITIES tables. Instead, several custom DB triggers
were developed to the data to populate Attribute2 on the Approved Supplier List DFF as shown below in Fig. 10.
For suppliers without full EDI capabilities, we can receive a .csv file with their onhand quantities and a custom
program processes the records to the same ASL attribute2 as shown below.

COLLABORATE 11
8

Fig 10. ASL DFF for Supplier Onhand and Open PO Quantities
The Second Call custom sourcing program uses the above values to make sourcing decisions per the Tier 1 logic.
Any sourcing of new POs for a particular supplier-item combination will increment the Open PO Quantity as
ATTRIBUTE3 on the ASL record. ASNs received for the same supplier-item combination will be netted from the
On-Hand Quantity to indicate a reduction in the suppliers stock. The net available quantity for sourcing is
calculated as Qty Onhand Open PO Qty or ATTRIBUTE2 ATTRIBUTE3. If the difference is negative, it is
treated as zero(0) net quantity available for sourcing.
Below are the custom triggers which update the DFFs on the ASL records as shown above in Fig. 10

Trigger

XXNIB_UPD_856_AND_CARRIER_INFO

XXNIB_UPD_ASL_QTY_FROM_846

Trigger Type

Description

AFTER INSERT

This DB trigger is developed to decrement the

onhand quantity at approved supplier list DFF
based on the ASN received. This is also used to
populate carrier info at the sales order line
attribute10 DFF.

AFTER INSERT

This DB trigger is developed to populate the

onhand quantity DFF at the approved supplier.

For the Outbound 810 AR invoice, the GSA was unable to process invoices with multiple lines (created from partial
shipments) for a given Sales Order Line. A customization was developed as a scheduled concurrent request which
calls a custom stored PL/SQL procedure to consolidate the multiple lines to a single line for the outbound 810 file.
This was only done for the outbound EDI file, whereas the original AR invoice detail was untouched in the
application.

Summary
I think you can see from the prior explanations that this was a highly configured and customized solution for
automating the Drop Ship order to cash flow. However, it still made enough use of standard functionality to be of
general use to someone looking to implement in a similar environment. Extensive use of EDI transactions, utilizing
the XML Gateway mapping, B2B adapters and BPEL Processing Manager, greatly eased the manual burden on the
client for order and invoice processing. More conventional sourcing setups could be used, such as sourcing rules

COLLABORATE 11
9

and sourcing assignment sets. However, those were not necessary for the custom Second Call sourcing employed on
this implementation.
Below are several flow charts which summarize at a high level the solution at various stages of the Drop Ship order
to cash flow as integrated into this solution.

Fig 11 Sales Order through Purchase Order Sourcing flow

COLLABORATE 11
10

Fig. 12 Order Fulfillment flow

COLLABORATE 11
11

Fig. 13 Invoice and Payment flow

COLLABORATE 11
12