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, #2672Closes#2495, #2498
Set a default value for factor when creating a new uom.
Could not create a new UoM with type reference (if creates a reference uom, no need to pass a factor).
Change the readonly filter to (type = bigger) to make the field writable for reference uom.
This is needed to force the reset of the factor when switching of type (onchange_type).
As the field was readonly, kept the old value for factor.
First, name_search searches on default_code, then, if the limit is not reached, it searches on the product name
The results found from the default code search must be removed from the search domain when doing the search on the product name, to avoid having results already found by the search on the default_code
opw-618015
Some prices, as standard_price, being a property, are company dependent. Therefore, when browsing as superuser, force_company is mandatory to get the property of the user company
Implements the UoS TODO items on stock.picking.do_partial() to fix#1432.
Add a new method _compute_uos_qty() on product.product to computes
product's invoicing quantity in UoS from quantity in UoM.
The created invoice will use the product_uos of the stock.move, meaning keeping
the quantity specified on the partial picking and the unit of measure of the
original stock.move (e.g. recieving 1 dozen from a 12 unit picking should either
get uos=dozen, uos_qty=1 or uos=unit, uos_qty=12, not a mix of both)
Fixes#1432, opw 611479
Remove the hardcoded precision of 12 on factor and factor_inv,
to use the complete natural precision of NUMERIC types,
preserving all significant digits.
e.g. a UoM with a factor_inv of 6.0 used to be computed as:
factor_inv: 6.0 -> factor: 0.166666666667 (1.0/6.0, rounded to 12 digits) -> factor_inv: 5.999999999988 (1.0/factor)
which could lead to errors such 12*0.166666666667 = 2.000000000004 instead of 2.0
Slightly changed the way the ORM handles float fields to allow setting `digits=0`
as a way to explicitly require a NUMERIC value but without enforcing/rounding
the values at the ORM level, i.e. a truly full-precision field.
NUMERIC type has unlimited precision but is less efficient so should not be
used as the default behaviour, which is why we keep float8 as an alternative.
Modified the view to display the product UOM factor with a 5 digits value by default.
This value is for usability purpose only, the field still accepts bigger precision, by
setting the `digits` option on the field in the form view.
This change is safe in a stable series, the `digits=0` alternative is
treated the same as the default `digits=None` everywhere in the framework,
except when creating the database field.
The name_get of a product will use some information (e.g. default_code) based on the supplier.
The matching of the supplier should use the commercial_partner_id in case the supplier info are on the company and the partner_id in the context belongs to the company (e.g. creates quotation with a contact of the company).
Fixes#1219
Fixes problem when we try to sell 12 units of a product and change it to 1 dozen,
the algorithm was then trying to recompute the original amount and was getting
12,0000048 as a result which was then passed to the ceiling method, getting 13.0!
See also previous commit and issue #1125, PR #1126
When uninstalling/updating a module, we may execute unlink method on product.template before product.product. In such cases, the product is already removed after removeing the template (_inherits) and the chained unlink of the product would fail (traceback when browsing).
At the time of the context_wo_lang patch (7.0 revision 6577), the orm did not keep the language in copy_data, this patch intended to be more consistent.
Since server revision 5146 7.0, the new behaviour is to use the translated version in copy_data. Removign this change will be more consistent with the orm.
The expected behaviour is now the following:
In user lang: translated product name + translated '(copy)'
In other lang: same as original product
lp bug: https://launchpad.net/bugs/1159913 fixed
bzr revid: mat@openerp.com-20140508134937-7cbja3vsv311z5j4
changing the template is not possible anymore; create a new tempalte or a new
variant instead. When creating a new product, you will always create a new
template.
Added the link to the template from the product form view.
Cleaned some code (code move).
bzr revid: tde@openerp.com-20140122170218-6j2sixoxvvbbxvhd
computed based on the template price + margin and extra, use the
pricelist currency if a pricelist has been given. This alows for
example to have 'promo' prices on the ecommerce that are in the
same currency.
bzr revid: tde@openerp.com-20140122120042-ovh2mi70q0beeqwq
- added a is_only_child field on product.product, telling whether the
product is the only child of the product.template
- improved the product form view, to set readonly all fields coming fgrom
the template when the product is not the only child. This way, the user
is more aware that changing a value in the template changes the value
for all child products. He will have to do those changes on the template
form. A link to the template has been added in the product form view.
bzr revid: tde@openerp.com-20140122095826-8k0wl7af57iiyify
behavior for product variant. Users are either in group_product_mono or
group_product_variant, allowing to tune the form view according to the
group the user belongs to.
product: added group_product_mono group
sale: added set_group_product_variant method that adds or remove the
group_product_mono according to the group_product_variant being unchecked
or checked.
product: updated form view accordingly
bzr revid: tde@openerp.com-20140121105046-zkbs778upjg0lpyr
Christophe Simonis
Valencia Rodrigues Sah
Cedric Snauwaert
Olivier Dony
Denis Ledoux
Martin Trigaux
Mohammad Alhashash
Martin Trigaux
Thomas Groutars
Denis Ledoux
Raphael Collet
Antony Lesuisse
Christophe Simonis
Thibault Delavallée
Darshan Kalola (OpenERP)