Hi TTO
As mentioned in a prior post I believe this problem is not easy to fix and that running a script over the inventory to zero items that are not EXACTLY ( double precision) zero - to zero.
Here is the problem that appears to be the root of it - and from your perspective - hard to fix.
And this problem reared its ugly head to confound me with the API - where I was comparing website quantities (for an e-commerce live site) with the backend definitive quantity (a live MYOB perpetual inventory file).
To ensure quantities on the website matched actual available I always checked every 30mins during the day (as there was a built in rounding for cutting) that any order ALWAYS rounded to the next 0.25 length - therefore ensuring there was always a bit over for loss during cutting.
i.e. the web showed 2.5 lengths - and MYOB showed 2.5 lengths - and order came through for 0.4 lengths - the web now shows 2.1 lengths left - the order is rounded to 0.5 - POSTED to MYOB - MYOB now shows 2.0 lenfths in stock - web is updated to available 2.0. (not 2.1)
All well and good EXCEPT - MYOB quantity (in the backend is stored as double precision) however it is displayed as (single precision) - to explain 2.00 shows in the inventory window Quantity on Hand but in reality in the backend 2.00 (single precision) becomes 2.00xxxxxxxxxxxxxxxxxxx rounded in double precision - i.e it is never EXACTLY zero.
The problem with mixing and matching in science and maths with double and single precision - except in the computer - single precision is cheaper to store than double precision - and if you don't need double don't use it.
However, MYOB needs it in allowing up to 6 decimal places in prices - so it comes around and bites them in the rear end.
And by the way - that doesn't work in the API POST of an invoice - there is a bug - and you can only get 1 to 2.
Anyway - that is the explanation - simply - but until I corrected in my code for this - my system constantly thought every web item 1500 was different from MYOB - my API would get the qunatity on hand from MYOB before the comparision (but it was in double precision) - and it just never was right.
Here is the other twist (depending on the CPU and mathematics component) the double precision value can vary.
i.e. quantity of item (NOW) in double precision is slightly different to (NOW) + time a bit!!!!!
So it is almost impossible to get to ZERO.
My cure - very simple - always download Quantity on Hand as Single precision - problem was cured instantly and never went wrong again.
For you - the problem is you cannot do what I have done - the problem is hard wired.
The script just cleans up these errors - today - but they recur.
Sorry for the long winded explanation.
The Doc
