[
https://issues.apache.org/jira/browse/OFBIZ-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497439
]
Jacopo Cappellato commented on OFBIZ-313:
-----------------------------------------
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...
> FIFO stock reservation not being honoured
> -----------------------------------------
>
> Key: OFBIZ-313
> URL: https://issues.apache.org/jira/browse/OFBIZ-313
> Project: OFBiz (The Open for Business Project)
> Issue Type: Bug
> Components: product
> Affects Versions: SVN trunk
> Reporter: David E. Jones
> Assigned To: Ray Barlow
>
> 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!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
