FIFO stock reservation not being honoured

Details

Description

This issue is from the old Undersun Jira server, submitted by Ray Barlow and described as below:

The default catalogue data suggests that orders should be prioritised on the FIFO priniciple for stock allocation. So when order1 comes in it should be allocated all the stock it requires for completion before order2 and stay that way.

I'm ignoring the business complications that can arise around picking order2 first as it is being held up by one item order1 has and order1 is being held up because of another item etc.

The FIFO allocation fails under the following scenario: (clean database against SVN seed data)
1) Place an order for 10 x WG-9943-S4. This allocates all ATP stock.
2) Create some more stock against WG-9943-S4, I've done 10/10 on ATP/QOH
3) Now create another order 10 x WG-9943-S4, which again should allocate all the stock.
4) Both orders should be ready to complete, nothing on back order.
5) In the order manager view order WS10000 (order1) and click on the inventory link, mine is showing as id 10000
6) Add an invariance to remove some stock i.e. -2/-2 ATP/QOH as damaged.
7) Back to the order view and now WS10000 is on back order. This means order2 has jumped the que and the balance routine did not honour the FIFO prinicple! WS10000 should get priority over the stock allocated to order2.

PS: When I clicked on "Find Order" and show all records, it displayed 1-2 of 2, but in the list there was only order number WS10000 visible, I'll investigate further, but it appears the view is showing one to few!

I was hopeful to tick this one off but it still fails for me using the above simple tests.

I don't doubt the FIFO fixes have helped in more complex scenarios but I'm thinking the issue here at the moment is more related to the amount of balancing done when the inventory is adjusted. When the adjustment is done against invId 10000 above it only triggers a balance against the first order WS10000 which doesn't knock onto adjust the inventory against order 2 even though it has a higher date priority.

Ray Barlow
added a comment - 20/Mar/07 12:49 Si,
I was hopeful to tick this one off but it still fails for me using the above simple tests.
I don't doubt the FIFO fixes have helped in more complex scenarios but I'm thinking the issue here at the moment is more related to the amount of balancing done when the inventory is adjusted. When the adjustment is done against invId 10000 above it only triggers a balance against the first order WS10000 which doesn't knock onto adjust the inventory against order 2 even though it has a higher date priority.
Ray

Jacopo Cappellato
added a comment - 21/May/07 09:44 Ray,
by the way, even if the name of the product store's field could create confusion, the FIFO rule should be applied to the inventory and not to the orders:
http://en.wikipedia.org/wiki/FIFO_and_LIFO_accounting
I mean that the system, with a FIFO method, should try to reserve and ship the oldest inventory items before.
Jacopo

OK I understand your point and maybe there is some confusion about inventory and order item reservations.

Personally I wasn't thinking in terms of which inventory item was being used first and because of that I've not been paying attention to it in terms of FIFO rules and this jira issue. In general system usage (without testing) I do believe the current allocation I see is oldest first which makes most sense to us and agrees with FIFO settings.

Are you saying that the label in the product store "Reserve Order Enum Id" relates to the inventory allocation sequencing rather than orders? If that is the case then the labelling really does need to be adjusted as it clearly suggests orders and not inventory items.

This jira issue though was intended to identify the problem experienced for order delivery in that the second order that comes in will be delivered first, which is not acceptable. Aside from the possible labelling confusion I believe it is still outstanding.

Ray Barlow
added a comment - 21/May/07 14:02 Jacopo,
OK I understand your point and maybe there is some confusion about inventory and order item reservations.
Personally I wasn't thinking in terms of which inventory item was being used first and because of that I've not been paying attention to it in terms of FIFO rules and this jira issue. In general system usage (without testing) I do believe the current allocation I see is oldest first which makes most sense to us and agrees with FIFO settings.
Are you saying that the label in the product store "Reserve Order Enum Id" relates to the inventory allocation sequencing rather than orders? If that is the case then the labelling really does need to be adjusted as it clearly suggests orders and not inventory items.
This jira issue though was intended to identify the problem experienced for order delivery in that the second order that comes in will be delivered first, which is not acceptable. Aside from the possible labelling confusion I believe it is still outstanding.
Ray

I really think that "Reserve Order Enum Id" refers to the order in which inventory items are reserved according to their creation date; but I could be wrong and it would be great to have feedback from others about this subject.

I was not suggesting to close this issue, I'm sure there is an issue that we have to fix. There is a small detail that I'd like to add to your example: the date or sequence in which the sales orders are created should not the only/main rule to set orders' priority. We should look instead at ship groups' ship before date etc...

Jacopo Cappellato
added a comment - 21/May/07 14:15 Ray,
I really think that "Reserve Order Enum Id" refers to the order in which inventory items are reserved according to their creation date; but I could be wrong and it would be great to have feedback from others about this subject.
I was not suggesting to close this issue, I'm sure there is an issue that we have to fix. There is a small detail that I'd like to add to your example: the date or sequence in which the sales orders are created should not the only/main rule to set orders' priority. We should look instead at ship groups' ship before date etc...