Hi all,
I have a question about an issue that is happening when an order is edited. When the order is modified, all its inventory reservations are released and re-reserved. Unfortunately, if the inventory in stock is low and there are backorders, it could happen that an order that is modified becomes a backorder (because the items reserved by it could be 'stolen' by another order). I know that the inventory reservation routine assigns inventory to orders according to their 'priority' (order dates), so that older orders should take precedence over new ones... but there are situations where this priority is not enough. Sometimes it is really annoying to see a good order (no backorders) that after a change to the order item quantity (for example from 3 to 2 units) becomes a backorder... How can we resolve this issue? What about adding a link in the order view screen to recompute the inventory reservation routine, assigning a higher priority to the given order (I know that the inventory reservation routine already accept a priorityOrderId)? This could be a workaround for the problem: 1) the user edits a good order 2) the order becomes a backorder 3) the user runs the link and reservations are computed again, but this time to the order is given the highest priority and so it captures all the inventory required Does it make sense? Jacopo |
Hi Jacopo
I noticed this too (I think I mentioned it in a jira I opened somewhere), my plan to fix it was to change the way orders are edited so that only items which are removed from the order lose their reservations. I can't remember all the details but it seemed like the best way was to compare the shopping cart to the original order at the end of processing and make all the necessary changes then like canceling promos, reservations etc. Regards Scott On 12/07/07, Jacopo Cappellato <[hidden email]> wrote: > > Hi all, > > I have a question about an issue that is happening when an order is > edited. > > When the order is modified, all its inventory reservations are released > and re-reserved. > Unfortunately, if the inventory in stock is low and there are > backorders, it could happen that an order that is modified becomes a > backorder (because the items reserved by it could be 'stolen' by another > order). > > I know that the inventory reservation routine assigns inventory to > orders according to their 'priority' (order dates), so that older orders > should take precedence over new ones... but there are situations where > this priority is not enough. > > Sometimes it is really annoying to see a good order (no backorders) that > after a change to the order item quantity (for example from 3 to 2 > units) becomes a backorder... > > How can we resolve this issue? > What about adding a link in the order view screen to recompute the > inventory reservation routine, assigning a higher priority to the given > order (I know that the inventory reservation routine already accept a > priorityOrderId)? > This could be a workaround for the problem: > 1) the user edits a good order > 2) the order becomes a backorder > 3) the user runs the link and reservations are computed again, but this > time to the order is given the highest priority and so it captures all > the inventory required > > Does it make sense? > > Jacopo > > |
Hi Scott,
what you propose would be the ideal solution, maybe very complex to implement but the right way to go; however what I propose can be a good workaround/interim solution... what do you think? About your solution: I've recently changed some code in the loadCartForUpdate/saveUpdateCartToOrder that should really simplify the task you described. In fact now in the loadCartForUpdate service the cart is simply loaded from an order (nothing is changed in the db... no reservation release etc...); all the changes are done in the saveUpdateCartToOrder (this is where we could implement your changes). Jacopo Scott Gray wrote: > Hi Jacopo > > I noticed this too (I think I mentioned it in a jira I opened > somewhere), my > plan to fix it was to change the way orders are edited so that only items > which are removed from the order lose their reservations. I can't remember > all the details but it seemed like the best way was to compare the shopping > cart to the original order at the end of processing and make all the > necessary changes then like canceling promos, reservations etc. > > Regards > Scott > > On 12/07/07, Jacopo Cappellato <[hidden email]> wrote: >> >> Hi all, >> >> I have a question about an issue that is happening when an order is >> edited. >> >> When the order is modified, all its inventory reservations are released >> and re-reserved. >> Unfortunately, if the inventory in stock is low and there are >> backorders, it could happen that an order that is modified becomes a >> backorder (because the items reserved by it could be 'stolen' by another >> order). >> >> I know that the inventory reservation routine assigns inventory to >> orders according to their 'priority' (order dates), so that older orders >> should take precedence over new ones... but there are situations where >> this priority is not enough. >> >> Sometimes it is really annoying to see a good order (no backorders) that >> after a change to the order item quantity (for example from 3 to 2 >> units) becomes a backorder... >> >> How can we resolve this issue? >> What about adding a link in the order view screen to recompute the >> inventory reservation routine, assigning a higher priority to the given >> order (I know that the inventory reservation routine already accept a >> priorityOrderId)? >> This could be a workaround for the problem: >> 1) the user edits a good order >> 2) the order becomes a backorder >> 3) the user runs the link and reservations are computed again, but this >> time to the order is given the highest priority and so it captures all >> the inventory required >> >> Does it make sense? >> >> Jacopo >> >> > |
In reply to this post by Jacopo Cappellato
Jacopo,
As Scott says there has been Jira activity in the past on this problem and it is really linked to the need to a redesign/write the order editing, we shouldn't be dropping reservations unless items are removed or dropped in quantity. I think exposing the priorityOrderId feature so that the user can raise the priority is a good idea outside of the editing an order problem. It's a scenario in it's own right where order A with 1 item on backorder is being held up by order B that has other items on backorder. If you can see the supplier shipment for order A will arrive before the shipment for order B then it is reasonable to jump the reservation queue so you can dispatch order A earlier and order B will still go out at it's expected time. Your workaround suggestion makes sense but I suspect it wont work for all scenarios. The order could actually have an item on backorder before you start editing it, the edit could increase the number of items on backorder as you have found, but if you raise the order priority it might now jump the queue on the original items that were on backorder. Ray Jacopo Cappellato wrote: > Hi all, > > I have a question about an issue that is happening when an order is > edited. > > When the order is modified, all its inventory reservations are > released and re-reserved. > Unfortunately, if the inventory in stock is low and there are > backorders, it could happen that an order that is modified becomes a > backorder (because the items reserved by it could be 'stolen' by > another order). > > I know that the inventory reservation routine assigns inventory to > orders according to their 'priority' (order dates), so that older > orders should take precedence over new ones... but there are > situations where this priority is not enough. > > Sometimes it is really annoying to see a good order (no backorders) > that after a change to the order item quantity (for example from 3 to > 2 units) becomes a backorder... > > How can we resolve this issue? > What about adding a link in the order view screen to recompute the > inventory reservation routine, assigning a higher priority to the > given order (I know that the inventory reservation routine already > accept a priorityOrderId)? > This could be a workaround for the problem: > 1) the user edits a good order > 2) the order becomes a backorder > 3) the user runs the link and reservations are computed again, but > this time to the order is given the highest priority and so it > captures all the inventory required > > Does it make sense? > > Jacopo > > |
Yeah I think Ray's right, it would probably cause as many problems as it
solves, I can't really think of easy workaround for this. Regards Scott On 12/07/07, Ray Barlow <[hidden email]> wrote: > > Jacopo, > > As Scott says there has been Jira activity in the past on this problem > and it is really linked to the need to a redesign/write the order > editing, we shouldn't be dropping reservations unless items are removed > or dropped in quantity. > > I think exposing the priorityOrderId feature so that the user can raise > the priority is a good idea outside of the editing an order problem. > It's a scenario in it's own right where order A with 1 item on backorder > is being held up by order B that has other items on backorder. If you > can see the supplier shipment for order A will arrive before the > shipment for order B then it is reasonable to jump the reservation queue > so you can dispatch order A earlier and order B will still go out at > it's expected time. > > Your workaround suggestion makes sense but I suspect it wont work for > all scenarios. The order could actually have an item on backorder before > you start editing it, the edit could increase the number of items on > backorder as you have found, but if you raise the order priority it > might now jump the queue on the original items that were on backorder. > > Ray > > Jacopo Cappellato wrote: > > Hi all, > > > > I have a question about an issue that is happening when an order is > > edited. > > > > When the order is modified, all its inventory reservations are > > released and re-reserved. > > Unfortunately, if the inventory in stock is low and there are > > backorders, it could happen that an order that is modified becomes a > > backorder (because the items reserved by it could be 'stolen' by > > another order). > > > > I know that the inventory reservation routine assigns inventory to > > orders according to their 'priority' (order dates), so that older > > orders should take precedence over new ones... but there are > > situations where this priority is not enough. > > > > Sometimes it is really annoying to see a good order (no backorders) > > that after a change to the order item quantity (for example from 3 to > > 2 units) becomes a backorder... > > > > How can we resolve this issue? > > What about adding a link in the order view screen to recompute the > > inventory reservation routine, assigning a higher priority to the > > given order (I know that the inventory reservation routine already > > accept a priorityOrderId)? > > This could be a workaround for the problem: > > 1) the user edits a good order > > 2) the order becomes a backorder > > 3) the user runs the link and reservations are computed again, but > > this time to the order is given the highest priority and so it > > captures all the inventory required > > > > Does it make sense? > > > > Jacopo > > > > > |
Free forum by Nabble | Edit this page |