COLLABORATE 11

1

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

2

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

3

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

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 Autoprocess to autocreate 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 SOURCE_TYPE set to External, where which is external to the selling company. shown below and makes the line eligiblefor drop ship.

Fig. 7 Order Line Workflow for Drop Ship

Subsequent running of the Workflow Background Process forshown above and insert lines into the REQUISITIONS_INTERFACE_ALL table.generates an approved requisition. For some clients, the Autocreate process to convert a requisitiOrder 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 andReceipt, you must populate the OM System Parameter with a person who has an HR record and is therefore an employee. dummy HR record will suffice for the CREATED_BY record in the workflow. drop ship orders created by iStore customthe 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 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 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

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-Sourcing must be checked for the sourcing

create Standard POs from the requisitions associated with a drop ship sales order.

Purchase Requisition Document Type

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

ternal to the selling company. The Line Flow Generic line workflow branches on thisshown below and makes the line eligible for Purchase Release, which is the integration between OM and Purchasing

Order Line Workflow for Drop Ship

Subsequent running of the Workflow Background Process for OM: Order Line will complete the deferred activity and insert lines into the REQUISITIONS_INTERFACE_ALL table. Requisition Import is run which

requisition. For some clients, the Autocreate process to convert a requisitiOrder 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 Userwith a person who has an HR record and is therefore an employee. This does not have 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,

p orders created by iStore customers (i.e. external users) will not be allowed to progress in the workflow

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 procesthe 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

of the Workflow Background Process for OM: Order Line will update the line status 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-hours.

4

In order to fully integrate the Contract PO solution, a key setup was required on the Purchase Requisition document st be checked for the sourcing

create Standard POs from the requisitions associated with a drop ship sales order.

flow in Oracle. It starts with a sales order line with external indicates the source of the supply is from a Supplier

es on this source type as e, which is the integration between OM and Purchasing

OM: Order Line will complete the deferred activity Requisition Import is run which

requisition. For some clients, the Autocreate process to convert a requisition to a Purchase Order or release against a Blanket PO is done manually. However, for this client, that process needed to run in the

for the order line status to be updated from Booked to Awaiting Requestor For Drop Ship Orders Created by External User

ve to be a real user, since a Without this parameter being set,

) will not be allowed to progress in the workflow by

Typically, when the goods are shipped from the supplier to the customer against a Drop Ship order, an Advance fulfillment of the order. A PO receipt is processed for

the quantity that was shipped against the appropriate PO shipment line. The Ship step in the line workflow is from Awaiting Receipt to

of the Workflow Background Process for OM: Order Line will update the line status Invoice lines are inserted into the AR invoice interface to be processed by the next Autoinvoice Master

COLLABORATE 11

5

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. AUTOSOURCE_FLAG = N 2. SUGGESTED_VENDOR_ID = Supplier chosen by Second Call logic 3. SUGGESTED_VENDOR_SITE_ID = Site ID for the above Supplier 4. AUTOSOURCE_DOC_HEADER_ID = Contract PO ID

COLLABORATE 11

6

5. DOCUMENT_TYPE_CODE = 'Contract 6. 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 Insert Update Delete PO_REQUISITIONS_INTERFACE_ALL Y Y OE_DROP_SHIP_SOURCES Y OE_ORDER_LINES_ALL Y OE_ORDER_HEADERS_ALL Y PO_HEADERS_ALL Y PO_APPROVED_SUPPLIER_LIST Y Y PO_ASL_STATUSES Y PO_VENDORS Y QP_QUALIFIERS Y QP_LIST_HEADERS_B Y QP_LIST_LINES Y QP_PRICING_ATTRIBUTES Y QP_QUALIFIERS Y

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

7

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. Oracle B2B converts the native EDI format files/messages into EDIXML messages. 2. BPEL converts EDI XML into OAGXML and queues the messages. 3. Workflow deferred agent listeners un-queues the message. 4. XMLGateway populates interface tables from the OAGXML 5. 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. E-Business Suite Workflow will raise a specific business event 2. XMLGateway queues up the message 3. BPEL Process manager un-queues the message and converts OAGXML to EDIXML

COLLABORATE 11

8

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. Inbound 850 Purchase Order 2. Outbound 850 Purchase Order 3. Outbound 860 PO Change 4. Inbound 856 Advanced Ship Notice 5. Inbound 810 AP (Supplier) Invoice 6. Outbound 810 AR (Customer) Invoice 7. Inbound 846 Supplier Inventory 8. 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 over-arching 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

9

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 Trigger Type Description

XXNIB_UPD_856_AND_CARRIER_INFO 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.

XXNIB_UPD_ASL_QTY_FROM_846 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

10

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

11

Fig. 12 Order Fulfillment flow

COLLABORATE 11

12

Fig. 13 Invoice and Payment flow