Automated Drop Ship Order Processing in R12

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 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. Let s start with istore features and then move on to EDI. Oracle s 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 AN 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). 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 supplier s 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 supplier s 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 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-Sourcing must be checked for the sourcing process to autocreate Standard PO s 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_TPE set to External, where the term external indicates the source of the supply is from a Supplier which is external to the selling company. The Line Flow Generic line workflow branches 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 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 to be a real user, since a dummy HR record will suffice for the CREATED_B record in the workflow. Without this parameter being set, drop ship orders created by istore 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 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-hours. 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 customer s 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 client s 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 5

5. DOCUMENT_TPE_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 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 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 = es Is Automatic Approval Allowed = es Send PO Autocreation to Background = No 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. 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 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. 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 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 Oracle s 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 Oracle s 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. 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 PO s for a particular supplier-item combination will increment the Open PO Quantity as ATTRIBUTE3 on the ASL record. ASN s received for the same supplier-item combination will be netted from the On-Hand Quantity to indicate a reduction in the supplier s 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 XXNIB_UPD_ASL_QT_FROM_846 AFTER INSERT 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. 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 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 10

Fig. 12 Order Fulfillment flow 11

Fig. 13 Invoice and Payment flow 12