[
https://issues.apache.org/jira/browse/OFBIZ-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497380
]
Jacopo Cappellato commented on OFBIZ-313:
-----------------------------------------
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
> 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.
