Hold Until Complete

From NewHaven Software Wiki

(Difference between revisions)
Jump to: navigation, search
Line 2: Line 2:
=Overview=
=Overview=
-
When orders are placed on back order, in many situations it will make sense to hold the order until all of the items are available so it can ship complete. The current CMS behavior is designed to support a ship ASAP model generally preferred for cash flow and inventory movement but causes problems when trying to reduce the number of shipments for an order, be it for shipping expense or desire to deliver complete to the customer.
+
When orders are placed on back order, in many situations it will make sense to hold the order until all of the items are available so it can ship complete. The current CMS behavior is designed to support a "ship asap" model which is better for cash flow and inventory movement but causes problems when trying to reduce the number of shipments for an order, be it for shipping expense or desire to deliver complete to the customer.
-
While there is some merit to the idea of "Fulfill Complete" which seems more complimentary to our current fulfillment methodology (back orders and future ships), it would suffer the problem of never allocating stock to an order. This keeps CMS from being able to fulfill in a FIFO type manner (as it relates to allocating to the customers who requested the items first). Version 9.0 did introduce a Back Order All option to facilitate this "Fulfill Complete" concept but is understood to not address all needs.
+
In 9.0 we added a Back Order All function to make it easy to force an entire order onto back order but it does suffer the problem of never allocating stock to an order. This prevents the user from being able to fulfill/allocate in a [http://en.wikipedia.org/wiki/FIFO FIFO] manner (allocating to the customers who requested the items first).
-
=Proposal=
+
=Proposal for Phase 1=
-
The proposed "Hold Until Complete" feature (HUC) discussed here would work in conjunction with our existing Order Holds mechanism. If an order has any items on back order, the operator should be presented with or, at minimum, be able to select a "Hold Until Complete" option which would allocate what is available now and hold the invoice out of further processing (preventing printing, charge processing, etc. until released from hold).  
+
The proposed Hold Until Complete (HUC) feature would work in conjunction both with CMS's existing Hold mechanism and Fulfillment Manager. If an order has any items on back order, CMS can place the order on hold using a new HUC hold type when the order is saved. Whether or not the order is placed on HUC will be based on:
-
CMS would need a mechanism for allocating to held unallocated items as stock becomes available and then releasing the order without having to edit the order to manually allocate or update financials (shipping amount, payment amount, etc.)
+
*Order Entry option indicating if you want orders with back orders placed on HUC automatically
 +
**Consideration currently being given to making the use of HUC conditional based on a global user-specified threshold of Expected Delivery dates for back ordered items
-
Consider which should be the default behavior and if it would be a setting (i.e. always apply HUC or never automatically). Some customers will want to default to hold until complete, others will not. Either would want an override option to choose the other for certain orders.
+
User can override the default behavior and manually set or remove the HUC flag after the order is saved.
-
Have a queue or filter to show orders which are now complete that can be released. Presumably this would be in Fulfillment Manager where other Order Holds are managed.
+
HUC orders are released using the Fulfillment Manager's Back Order processing. This allows the user to have a single list of back order invoices, potentially a mix of HUC and non-HUC back orders, and can fulfill FIFO. No added filter is necessary, just click the radio button for All Orders Shown and then the button for Process Orders.
 +
*Those orders with no HUC flag will fulfill based on settings on the options shown (partial orders can fulfill, partial items can fulfill) and fulfill onto a -2 (or later) invoice as is standard behavior now
 +
*Those ''with'' a HUC flag (and no other hold flags) and all items available will fulfill onto the -1 invoice
 +
**This fulfillment will set the fulfill date of the invoice to today, allocate remaining stock needed, and create a new payment if needed (the same as any other back order fulfillment) and will remove the HUC hold flag
-
*Use cases should be documented illustrating different scenarios for holding and releasing to ensure all possibilities are considered. Consider how to handle payments pre and post hold and their dates, presuming that some hard payments (check, cash, money order, etc.) will be received against a held order where no money is yet due.
+
Orders set as HUC can be reviewed in the Fulfillment Manager under the tab for Invoices on Hold where hold can be individually reviewed and edited as needed.
-
=Options/Features=
+
Additional enhancements include:
-
*Default to put any bo invoice on Hold Until Complete (HUC) automatically
+
*Orders set as HUC cannot be returned/cancelled and the user will be warned if a return is attempted
-
*Button to tell CMS to update allocations on such HUC orders (e.g. as inventory is received)
+
*Employee permission will be added to indicate who can alter the HUC of an order
-
**Could prompt as stock is received but seems a simple global 'allocate all to HUCs' would be better for the phase 1 introduction of this feature.
+
*Option in Order Entry, (location tbd, perhaps in the Holds UI) to refresh allocation on the order (so if some new stock has become available, allocations can be updated)
 +
*Add filter to Batch Approvals to allow the limiting of processing to next X payments (display sequence should be FIFO) and should also show a total count of payments in the grid. Should the fulfillment of back orders (release of HUC) release more invoices into your fulfillment flow (printing, picking, shipping) than you want to deal with at once, you can limit how many you authorize which in turn limits how many will be printed (per CMS config.)
 +
*If a user removes a HUC flag, we must keep CMS from resetting it on save based on the order entry default
 +
*The HUC hold reason will be displayed on the order (location tbd, likely View Invoice)
 +
*Refreshing allocation option - to allocate newly available inventory when editing an order.
-
=Challenges=
+
=Related Exceptions and Comments=
-
*Allocating to held items
+
*Orders that are a mix of future ship and back order items will not be candidates for HUC
-
*Financial changes as allocations change (HUC is always bill delayed maybe - yes)
+
*After fulfillment, there is no record retained to indicate that the order was previously HUC
-
*Exposing Allocation - how to indicate in the interface that stock is allocated in order entry, stock manager, reports (sent_qty)
+
*No reporting changes are considered for phase 1 but will be evaluated on a case by case basis as requested
-
*Allowing de-allocation - From within the order, allow the user to de-allocate without canceling/returning - no
+
*No specific option to deallocate is included although an item or order can be forced onto back order with currently available controls which does deallocate
-
*Filtering Holds from fulfilling (need to make sure HUCs are not considered in bo/fuship fulfillments, likely inherently handled by our current hold mechanisms)
+
-
*Interaction with future ships? Concepts seem exclusive of each other. Maybe hold until a selected date, allow allocation up front and incrementally as with HUC, and then release on that date regardless of status...or continue to hold if HUC?
+
-
*'fulfilling' onto -1 - We are not really fulfilling onto -1, more allocating in several steps. Any concerns with having dated transactions or paper trail/exposure for these allocations? (lot_item)
+
-
*Allocating to HUCs as stock is received - After stock is received (immediately, using new lot type for holding_lots) allocate all available inventory to HUCs.
+
-
=Phase 2=
+
=Phase 2 possibilities=
-
Future enhancements to HUC that are likely out of scope for the first iteration include:
+
*Way to handle allocations so newly received stock can be committed to current HUC orders (those already saved but not yet fulfilled/released)
-
*Rules based HUC - CMS would automatically apply HUC when certain user-defined conditions are met. An example of this would be if a PO is open and expected to arrive within X days, orders waiting for that item might automatically go on HUC knowing that it could fulfill complete soon. Orders with items outside X days might not automatically move to HUC and be better suited to fulfilling as available.
+
*Treating future ships in a similar way with allocations and fulfillments onto -1 (future shipping vs future fulfillment)

Revision as of 20:09, 16 January 2013

Specification discussion for a CMS customization being considered.

Contents

Overview

When orders are placed on back order, in many situations it will make sense to hold the order until all of the items are available so it can ship complete. The current CMS behavior is designed to support a "ship asap" model which is better for cash flow and inventory movement but causes problems when trying to reduce the number of shipments for an order, be it for shipping expense or desire to deliver complete to the customer.

In 9.0 we added a Back Order All function to make it easy to force an entire order onto back order but it does suffer the problem of never allocating stock to an order. This prevents the user from being able to fulfill/allocate in a FIFO manner (allocating to the customers who requested the items first).

Proposal for Phase 1

The proposed Hold Until Complete (HUC) feature would work in conjunction both with CMS's existing Hold mechanism and Fulfillment Manager. If an order has any items on back order, CMS can place the order on hold using a new HUC hold type when the order is saved. Whether or not the order is placed on HUC will be based on:

  • Order Entry option indicating if you want orders with back orders placed on HUC automatically
    • Consideration currently being given to making the use of HUC conditional based on a global user-specified threshold of Expected Delivery dates for back ordered items

User can override the default behavior and manually set or remove the HUC flag after the order is saved.

HUC orders are released using the Fulfillment Manager's Back Order processing. This allows the user to have a single list of back order invoices, potentially a mix of HUC and non-HUC back orders, and can fulfill FIFO. No added filter is necessary, just click the radio button for All Orders Shown and then the button for Process Orders.

  • Those orders with no HUC flag will fulfill based on settings on the options shown (partial orders can fulfill, partial items can fulfill) and fulfill onto a -2 (or later) invoice as is standard behavior now
  • Those with a HUC flag (and no other hold flags) and all items available will fulfill onto the -1 invoice
    • This fulfillment will set the fulfill date of the invoice to today, allocate remaining stock needed, and create a new payment if needed (the same as any other back order fulfillment) and will remove the HUC hold flag

Orders set as HUC can be reviewed in the Fulfillment Manager under the tab for Invoices on Hold where hold can be individually reviewed and edited as needed.

Additional enhancements include:

  • Orders set as HUC cannot be returned/cancelled and the user will be warned if a return is attempted
  • Employee permission will be added to indicate who can alter the HUC of an order
  • Option in Order Entry, (location tbd, perhaps in the Holds UI) to refresh allocation on the order (so if some new stock has become available, allocations can be updated)
  • Add filter to Batch Approvals to allow the limiting of processing to next X payments (display sequence should be FIFO) and should also show a total count of payments in the grid. Should the fulfillment of back orders (release of HUC) release more invoices into your fulfillment flow (printing, picking, shipping) than you want to deal with at once, you can limit how many you authorize which in turn limits how many will be printed (per CMS config.)
  • If a user removes a HUC flag, we must keep CMS from resetting it on save based on the order entry default
  • The HUC hold reason will be displayed on the order (location tbd, likely View Invoice)
  • Refreshing allocation option - to allocate newly available inventory when editing an order.

Related Exceptions and Comments

  • Orders that are a mix of future ship and back order items will not be candidates for HUC
  • After fulfillment, there is no record retained to indicate that the order was previously HUC
  • No reporting changes are considered for phase 1 but will be evaluated on a case by case basis as requested
  • No specific option to deallocate is included although an item or order can be forced onto back order with currently available controls which does deallocate

Phase 2 possibilities

  • Way to handle allocations so newly received stock can be committed to current HUC orders (those already saved but not yet fulfilled/released)
  • Treating future ships in a similar way with allocations and fulfillments onto -1 (future shipping vs future fulfillment)
Retrieved from "http://wiki.newhavensoftware.com/index.php/Hold_Until_Complete"
Personal tools