fix for stock forecast quantity computation

[ced1, 2009-10-26 19:01:18]

http://codereview.appspot.com/140062/diff/1/2
File product.py (right):

http://codereview.appspot.com/140062/diff/1/2#newcode274
Line 274: 'done', 'assigned', 'draft', today, today,
I don't agree.
Draft moves in the past are moves that we must considered as missing and must
not be expected to be done.

[timitos, 2009-10-26 19:28:43]

On 2009/10/26 19:01:18, ced wrote:
> http://codereview.appspot.com/140062/diff/1/2
> File product.py (right):
> 
> http://codereview.appspot.com/140062/diff/1/2#newcode274
> Line 274: 'done', 'assigned', 'draft', today, today,
> I don't agree.
> Draft moves in the past are moves that we must considered as missing and must
> not be expected to be done.

This does not work. Think of a company that does only purchases on different
intervals. Because of this unplanable intervals the cron for purchase requests
must be executed every day. but without the proposed behavior there will be only
the quantity computed for the sale orders of today and the future but not the
old ones.

(for the moment there is without the proposed behavior even a different behavior
for products with supplier and products without supplier set)

[ced1, 2009-10-26 21:02:41]

On 2009/10/26 19:28:43, timitos wrote:
> On 2009/10/26 19:01:18, ced wrote:
> > http://codereview.appspot.com/140062/diff/1/2
> > File product.py (right):
> > 
> > http://codereview.appspot.com/140062/diff/1/2#newcode274
> > Line 274: 'done', 'assigned', 'draft', today, today,
> > I don't agree.
> > Draft moves in the past are moves that we must considered as missing and
must
> > not be expected to be done.
> 
> This does not work. Think of a company that does only purchases on different
> intervals. Because of this unplanable intervals the cron for purchase requests
> must be executed every day. but without the proposed behavior there will be
only
> the quantity computed for the sale orders of today and the future but not the
> old ones.
> 
> (for the moment there is without the proposed behavior even a different
behavior
> for products with supplier and products without supplier set)

I still don't agree. It must not have any draft move for sale in the past. The
fix is not good.
I think it is "generate_requests" that must eventually update the moves date of
customer shipment at the beginning of the run.

PS: please answer to the right comment.

[timitos, 2009-10-27 07:32:54]

i close this issue as this solution seems to be not the right way as ced says.