[Erp5-dev] getNextNegativeInventoryDate - specification, implementation

[Łukasz Nowak]

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?
* What shall be Nexedish solution in this case?
* 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 ;)

[Tomasz Brzezina]

Post by Łukasz Nowak
getNextNegativeInventoryDate works all right almost all the time, but
little problem rises with precision of dates in movement table. Let's
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.

You can assume, that all receives are always before any send (even if
it's not true).
This solve your problem.
--
Tomasz Brzezina

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3327 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.tiolive.com/pipermail/erp5-dev/attachments/20080229/f474f0ae/attachment.bin>

[Łukasz Nowak]

Hello,

On 2008-02-29, 14:51:44

Post by Tomasz Brzezina

Post by Łukasz Nowak
getNextNegativeInventoryDate works all right almost all the time,
but little problem rises with precision of dates in movement table.
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.

You can assume, that all receives are always before any send (even if
it's not true).
This solve your problem.

That's another solution - but from my point of view solution 2) from my
original email was easier to configure - we are able to be precise as
hour, half hour, minute, or something. (Of course - that's what we
implemented, and upgrading to *just right now* :) )

Regards,
?ukasz

[Jérome Perrin]

Post by Łukasz Nowak
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
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.
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.
* 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.

Post by Łukasz Nowak
* What shall be Nexedish solution in this case?

testInventoryAPI contains test getNextInventoryDate

J?rome

Post by Łukasz Nowak
* 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 ;)

[Łukasz Nowak]

Hello,

On 2008-02-29, 19:25:25
J?rome Perrin <jerome at nexedi.com> wrote:

(...)

Post by Jérome Perrin
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.

Indeed. I knew, that there have to be simpler solution that mine :)
Thanks for a tip.

Luke