Sponsored Development: Drop Ship

From ADempiere ERP Wiki

Jump to: navigation, search

Contents

Sponsors

Franchise Control Systems

Adaxa

Idalica


Developers

  • Paul Bowden

Proposed Specifications

Use Cases

  1. Simple Vendor Drop Ship: Jimbo, a skilled user of Adempiere, receives an order from Hans for 6 Frozen Yoghurts. Having none in stock, Jimbo wants to quickly raise a purchase order against Kwik-e-mart for them to supply the 6 Yoghurts. But in the interests of corporate efficiency, environmental benevolence and not melting the yoghurt, Jimbo decides that Kwik-E-Mart should deliver them directly to Hans rather than sending them to Jimbo's warehouse. In a simple drop ship, there is a direct one-to-one correspondence between a sales order and a purchase order. All the lines on the sales order will be delivered from the same supplier in a single delivery.
  2. Complex Vendor Drop Ship: In this scenario, Hans orders 10 Frozen Yoghurts, 9 bars of chocolate and 8 mineral waters. He asks Jimbo to deliver only complete order lines. Jimbo has the mineral water in stock, but he has to order the Frozen Yoghurt from Kwik-e-mart and the chocolate bars from Willy Wonka's Chocolate Factory. If Hans wanted to have the complete order delivered as one, Hans would have to have his suppliers deliver to him first, and then consolidate the goods into one shipment. But because Hans has specified only complete order lines, Jimbo can get both his suppliers to drop ship. In a complex vendor drop ship, a sales order can be supplied from multiple suppliers and from stock according to the customer's delivery rules.
  3. Customer Drop Ship: Freda runs an online store selling art prints. She carries no stock, but fortunately her single supplier, Monet Co., has chosen to implement Adempiere, and is able to ship goods on demand with very little overhead. Freda would like not to have to handle the prints at all, so she has requested that Monet ship directly to her customers -- she'll provide all the delivery details required with each order -- and Monet, anxious to make a good impression, has agreed that it's a very good idea. Freda receives an order on her webstore from Mr Escher for one of her tranquil waterfall prints. She laboriously re-enters that very order as a purchase order in Monet's webstore, and settles back to wait for notification that the goods have been sent so she can mock up an invoice in excel.

Current Functionality

It is already possible to (sort of) handle the customer drop shipment case using standard functionality: Monet could simply add Escher as a contact for Freda, and his address as one of Freda's delivery locations, and alter the print format to not print Freda's company name in the deliver to field. Of course, if Monet needed, for example, to send a shipment confirmation to Freda's real address he would need to perform various contortions to get the necessary information. It would probably be better if Freda's name, address and contact information were kept as the main order business partner details, and the delivery information was handled separately.

There is also some beta functionality inherited from Compiere that does some interesting things in the name of drop shipment. It is primarily directed at use case 1: the simple vendor drop shipment. Currently, Jimbo can raise a sales order to Hans for the frozen yoghurt, and mark the sales order as a drop shipment. On completion of the order, reservations are not made and it is not possible to raise a shipment for the order. (This makes some kind of sense as the "shipment" will come from the vendor. There does not, however, appear to be any mechanism for tracking open drop ship orders, or for triggering the invoice except as immediate.) Jimbo can then "Generate PO from SO" with the "Drop Shipment" parameter set to "Yes" to create a purchase order against the current vendor for each of the products on the Sales Order. This PO will be marked as a drop shipment, with the order BP details set to Hans and the Invoice to BP as Kwik-e-Mart.

There appears to be no further provisions for the entry of shipment confirmations from the supplier, or the production of a customer shipment, to signal to the system that the order has been fulfilled. In the light of these omissions and limitations, it seems that the current functionality is unusable and need not necessarily be maintained in its existing form for backwards compatibility.

Proposed Implementation

  1. Add a "Drop Ship" BP, location, and contact to the C_Order table for use by both sales and purchase orders. Use the "IsDropShip" flag to determine if these fields are displayed. The selected BP does not have to be related to the main order BP or invoice to BP, it is just an arbitrary reference for tidily storing shipping information. Individual implementations can choose whether they wish to create a BP for every customer drop shipment recipient, or consolidate them into a "dummy" BP, as is often done with an anonymous "cash sales" customer account. For vendor drop shipments, the "drop shipment BP" will obviously already exist as a customer. These fields will also be added to the document print views, with some logic to display the "Drop Shipment" values if they exist, otherwise the main order BP values. Warning: This is inconsistent with current usage of the IsDropShip flag on Sales Orders to indicate that a vendor drop shipment will be created from the sales order. It seems incorrect to expect the sales department to make decisions about how an order will be fulfilled and implicitly assumes that the whole order will be supplied by vendor drop shipments.
  2. All sales orders, including ones that may be partially supplied by drop shipment will reserve stock as normal against the selected order warehouse (and display insufficient stock warnings as normal). It seems reasonable to assume that vendor drop shipments will only be triggered for order lines that cannot be supplied from stock, according to the delivery rules.
  3. Add a "Drop Ship" BP, location and contact and "IsDropShip" flag to the M_InOut table. These values will be copied across from sales and purchase orders as needed. Add those fields to the document print views, as above.
  4. Add a drop shipment warehouse to the org info table. This represents a logical warehouse, selectable for each organization, where drop shipment receipts and shipments will be recorded without interfering with the "real" stock levels. This ensures that cost accounting occurs as normal.
  5. Add "Link_order_id" and "link_orderline_id" to the order and orderline tables respectively. These will be used to link a sales order and its lines to the generated purchase order/lines when a vendor drop shipment is created.
  6. Add a button to the sales order window calling "Generate PO from SO" process for the current sales order. It will initially be expected that the process will be run for single sales orders, rather than as a batch, to ensure control over the process.
  7. Alter the "Generate PO from SO" process:
    1. To use the IsDropShip parameter to specify that the created purchase orders should be vendor drop shipments. Warning: this is inconsistent with the current usage that uses this parameter to filter which Sales orders should have PO's generated. As discussed above, the IsDropShip flag on the sales order will no longer be used in this manner.
    2. If the IsDropShip parameter is specified, create the purchase order with vendor as the BP and invoice BP, the isdropShip flag selected, and the "Drop Ship" BP, location and contact fields populated with the sales order BP, location and contact. Set the PO warehouse to the organization Drop Shipment warehouse specified in the org info table.
    3. Only create a vendor drop shipment if the sales order delivery rule can be satisfied -- i.e. if delivery rule is complete order, the whole sales order must be supplier from a single vendor.
    4. Create purchase order lines for each sales order line that has qty on order <> 0, for which there are no unconfirmed shipments and there is a current vendor for the product. Update the link_orderline_id on both sales order line and purchase order line.
NOTE: For the Generate PO from SO process to work each product must have a current vendor
  1. Alter the M_InOut_Candidate_v to exclude sales order lines where there is a linked purchase order line from generating shipments. Include orders where isDropShip='Y' (Warning: this is inconsistent with current use).
  2. When confirmation of a vendor drop shipment is received from the supplier, a material receipt can be created as normal, with the warehouse set to the organization's drop shipment warehouse. Upon completion of the receipt, a customer shipment will automatically be generated that will relieve the reservations (which were against the normal warehouse) on the sales order, and update the quantity delivered.

Other Enhancements

  1. Display Link_orderline_id fields when they are non-null to allow zoom-across.
  2. Alter "Generate PO from SO" to create consolidated PO's (obviously only for non-drop shipments) that takes into account product replenishing rules.
  3. Add extra rules to determine when a drop-shipment is allowed. E.g. a flag on the vendor to say whether the vendor supports drop-shipping.
Personal tools