[FIX] product: remove unnecessary UoM rounding step, add missing test
authorOlivier Dony <odo@openerp.com>
Thu, 27 Nov 2014 11:36:28 +0000 (12:36 +0100)
committerOlivier Dony <odo@openerp.com>
Thu, 27 Nov 2014 15:44:34 +0000 (16:44 +0100)
commitfc85a7ee5c33eadc22652b6b26478c320e35b283
treeefa854baf9f30441305596c50dfcc03c10e88399
parent2080ea0f0acfb0e03372e8abd264a5fb72d7d431
[FIX] product: remove unnecessary UoM rounding step, add missing test

Remove the intermediate rounding inside _compute_qty(), as it
is not necessary after rev. fa2f7b86 and has undesired side-effects.

An extra float_round() operation inside _compute_qty()
had been added at rev. 311c77bb to avoid a float representation
error in UoM factors that could bias the ceiling() operation
done as the last conversion step.

Example 1:
Dozen has a factor of 1/12, which was previously stored in the
database with a decimal accuracy of 12 significant decimal digits.
This meant the factor was exactly stored as 0.08333333333333.
When reading this back into a Python float, the precision was not
sufficient, and the UoM conversion of 1 Dozen to Units gave a
result of 12.00000000000047961...
After the final ceiling() operation to Unit's rounding, the
converted value ended up as 13.

This problem was initially solved using an extra rounding.

However at revision fa2f7b86 the decimal precision used to store
UoM factors was increased to preserve all significant digits.
This added the extra precision necessary to read the Dozen factor
back into an accurate float value of 1/12, and the conversion of
1 Dozen now gives 12.0 Units, even without the intermediate
rounding operation. (Works for other factor values too)

At the same time that extra rounding operation has undesired
side-effects, as it requires a fixed precision derived from
the rounding precisions of the UoMs. But there is no given precision
that would work in all cases for this intermediate value. It is
always possible to find a valid combination of UoM roundings
that breaks that intermediate step, e.g. by forcing integer
roundings.

Example 2:
Let Grams have a rounding precision set to 1 because no smaller
quantities are allowed, and Kilograms a rounding of 0.001 to allow
representing 1 Gram. (gram factor = 1000 and kilogram rounding = .001
by default)
If we try to convert 1234 Grams into Kilograms, the extra rounding
introduced in 311c77bb will cause a rounding of 1234.0/1000.0 at
the precision of Grams (1), which gives 1.0 as a result.
The net result of this conversion gives 1234.0 Gram = 1.0 Kilogram,
while the correct result (1.234 Kilogram) is perfectly compatible
with the UoM settings.

Similar errors could be triggered with various rounding settings, as
long as the intermediate rounding needs a finite precision.

Two extra tests have been added to cover Example 1 and Example 2.

--
Related to #2072, #1125, #1126, #2672
Closes #2495, #2498
addons/product/product.py
addons/product/product_data.xml
addons/product/tests/test_uom.py