Hold Until Complete
From NewHaven Software Wiki
Russ horton (Talk | contribs) |
Russ horton (Talk | contribs) |
||
| Line 4: | Line 4: | ||
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 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. | ||
| - | 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 | + | 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. |
=Proposal= | =Proposal= | ||
| - | The proposed "Hold Until Complete" feature 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 | + | 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). |
| - | CMS would | + | 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.) |
| - | Consider which should be the default behavior and if it would be a setting. 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. | + | 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. |
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. | 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. | ||
| - | *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. | + | *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. |
=Options/Features= | =Options/Features= | ||
| Line 32: | Line 32: | ||
*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. | *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= |
| - | + | Future enhancements to HUC that are likely out of scope for the first iteration include: | |
| - | * | + | *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. |
Revision as of 01:54, 3 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 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.
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.
Proposal
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).
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.)
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.
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.
- 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.
Options/Features
- Default to put any bo invoice on Hold Until Complete (HUC) automatically
- Button to tell CMS to update allocations on such HUC orders (e.g. as inventory is received)
- 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.
Challenges
- Allocating to held items
- Financial changes as allocations change (HUC is always bill delayed maybe - yes)
- Exposing Allocation - how to indicate in the interface that stock is allocated in order entry, stock manager, reports (sent_qty)
- Allowing de-allocation - From within the order, allow the user to de-allocate without canceling/returning - no
- 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
Future enhancements to HUC that are likely out of scope for the first iteration include:
- 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.
