[JIRA] Closed: (OFBIZ-774) FIFO stock reservation not being honoured

     [ http://jira.undersunconsulting.com/browse/OFBIZ-774?page=all ]
     
Marco Risaliti closed OFBIZ-774:
--------------------------------

    Resolution: Won't Fix

For the moment I will close it if someone interested on it can create a new issue.

> FIFO stock reservation not being honoured
> -----------------------------------------
>
>          Key: OFBIZ-774
>          URL: http://jira.undersunconsulting.com/browse/OFBIZ-774
>      Project: [OFBiz] Open For Business
>         Type: Bug
>   Components: order
>     Versions: SVN
>  Environment: NA
>     Reporter: Ray Barlow
>     Assignee: Jira Administrator

>
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.undersunconsulting.com/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[Ray Barlow]

Anybody assuming the framework is issuing stock on a FIFO basis and
retaining that allocation sequence should be interested in this bug!
This is still active in the current SVN code base, so orders can jump
the queue if changes occur to the inventory levels as described and
possible other ways not tested here.

Ray



Marco Risaliti (JIRA) wrote:

>      [ http://jira.undersunconsulting.com/browse/OFBIZ-774?page=all ]
>      
> Marco Risaliti closed OFBIZ-774:
> --------------------------------
>
>     Resolution: Won't Fix
>
> For the moment I will close it if someone interested on it can create a new issue.
>
>  
>> FIFO stock reservation not being honoured
>> -----------------------------------------
>>
>>          Key: OFBIZ-774
>>          URL: http://jira.undersunconsulting.com/browse/OFBIZ-774
>>      Project: [OFBiz] Open For Business
>>         Type: Bug
>>   Components: order
>>     Versions: SVN
>>  Environment: NA
>>     Reporter: Ray Barlow
>>     Assignee: Jira Administrator
>>    
>
>  
>> 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!
>>    
>
>  

[Jacopo Cappellato]

Hi Ray,

please reopen the issue in the new server here:

https://issues.apache.org/jira/browse/OFBIZ

We had to quickly resolve all the old issue since the old server will be
  unavailable soon: a lot of them have been migrated by Marco Risaliti
to the new server, some of them have been migrated by the reporters of
the issues...

Thanks,

Jacopo

Ray Barlow wrote:
> Anybody assuming the framework is issuing stock on a FIFO basis and
> retaining that allocation sequence should be interested in this bug!
> This is still active in the current SVN code base, so orders can jump
> the queue if changes occur to the inventory levels as described and
> possible other ways not tested here.
>
> Ray
>

[David E Jones-2]

Thanks for the feedback Ray. I created a new issue for this here:

https://issues.apache.org/jira/browse/OFBIZ-313

-David

On Sep 15, 2006, at 8:35 AM, Ray Barlow wrote:

> Anybody assuming the framework is issuing stock on a FIFO basis and  
> retaining that allocation sequence should be interested in this  
> bug! This is still active in the current SVN code base, so orders  
> can jump the queue if changes occur to the inventory levels as  
> described and possible other ways not tested here.
>
> Ray
>
>
>
> Marco Risaliti (JIRA) wrote:
>>      [ http://jira.undersunconsulting.com/browse/OFBIZ-774?page=all ]
>>      Marco Risaliti closed OFBIZ-774:
>> --------------------------------
>>
>>     Resolution: Won't Fix
>>
>> For the moment I will close it if someone interested on it can  
>> create a new issue.
>>
>>
>>> FIFO stock reservation not being honoured
>>> -----------------------------------------
>>>
>>>          Key: OFBIZ-774
>>>          URL: http://jira.undersunconsulting.com/browse/OFBIZ-774
>>>      Project: [OFBiz] Open For Business
>>>         Type: Bug
>>>   Components: order
>>>     Versions: SVN
>>>  Environment: NA
>>>     Reporter: Ray Barlow
>>>     Assignee: Jira Administrator
>>>
>>
>>
>>> 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!
>>>
>>
>>