[Erp5-dev] getNextNegativeInventoryDate - specification, implementation

[Jérome Perrin]

Łukasz Nowak a écrit :
> Hello,
> 
> At Ventis we are playing a lot[1] with warehouse movements - purchase,
> production, sale and internal packing lists and inventories.
> 
> To generate supply orders (purchase and production) we are using order
> builders (modified a little).
> 
> And those order builders are using getNextNegativeInventoryDate 
> (extended by min_stock property support in our implementation, but
> that's not that case).
> 
> getNextNegativeInventoryDate works all right almost all the time, but
> little problem rises with precision of dates in movement table. Let's
> imagine this situation:
> 
>  a) 2008/02/15 receive quantity=10.0 of resource
>  b) 2008/02/15 send    quantity=5.0  of resource
> 
> Of course a) will always happen before b) in reality. But our precision
> is one day.
> 
> getNextNegativeInventoryDate is querying sorting by date. With our
> precision there is possibility, that b) will be returned before a) and
> than 2008/02/15 will be day of next negative inventory date. What is of
> course wrong.
> 
> We were thinking about such solutions:
>  1) set more precision on all forms related to reciving/sending goods -
> eg. to one minute
>  2) relax "precision" on getNextNegativeInventoryDate to given time
> amount
> 
> 
> Solution 1) should be nice, but there is too detailed in our case - we
> are interested only in precision of a day.
> 
> So we chosen solution 2) - getNextNegativeInventoryDate is grouping
> movements in sets of given precision, sum amount on them and then
> starting to walking through such prepared list to give next negative
> inventory date. Well - it is working and hadn't destroyed our unit
> tests.
>
> So my questions:
> 
>  * Did anyone spotted such problem - any tips to share?

Hi,
I don't have experience with the use of getNextInventoryDate, but I 
would go for 2) too.
What if you pass group_by_date=1 to getNextInventoryDate ? if you don't 
set hour minutes on your movement, the date defaults to 0h0m, so it's 
the same second and it could work.
Then if we really want to group by day movements with differents hours 
and minutes, it's much more complex because we have to take timezone 
into account.

>  * What shall be Nexedish solution in this case?

testInventoryAPI contains test getNextInventoryDate

Jérome

>  * As this problem appears only in case getNextNegativeInventoryDate is
> it "good enough" to patch only this method, and left users with nicer
> interface (our warehouse manager would kill me, if I would tell him,
> that he would need to type minutes of goods receive/send)?
>  * Where I could find more deep technical information about border
> issues on stocks (code not counts as "deep technical information" ;) )
> 
> Please note that I wanted to left user interface with precision to
> one day, but provide some magic, which would insert data with more
> precision - maybe time when operation happens - but it would only
> introduce many hard to find bugs into system, and more - such data
> would be "lies", and we do not want to have lies in our system - from
> our point of view, better solution is to have little, but defined,
> inaccuracy of data, than to have them theoretically accurate, but
> wrong.
> 
> Regards,
> Luke
> 
> 
> [1]..."a lot" - from our point of view ;)