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
Incorrect use of stock.move in product module + needs review.
This reverts commit 42f511405a4efe88e3903a4b4040ec9d83e462e2:
"[IMP] When no stock moves, change whatever you want, otherwise no change at all for UoM. #3440 Enhancement request richard-willowit"
The default UoM can only be changed when there are no stock moves (or only cancelled ones), but to any category.
The purchase UoM can be changed whenever you want, but has to be in the same category as the default UoM.
Closes#3440
[IMP] When no stock moves, change whatever you want, otherwise no change at all for UoM. #3440 Enhancement request richard-willowit
[FIX] Remove line
[FIX] Constraint should be applied when UoM or PO UoM is changed
When adding informational attribute, with only one possible value, it used to be skipped.
Instead keep it and add it on every variant.
To avoid dropping and recreating product (and lose eventual customisations), the attributes with only one possible value are set on every product.
This makes sure that in following test, these are not considered in variants_inactive variable.
Fixes#3204
Setting 0.0001 as precision used to be converted to 9.999999999999999e-05
precision_digits of 6 is the precision of the field 'rounding' on res.currency
Fixes#3875
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
name was confusing for bom and product if the value of the attribute is display without the attribute name
added key in context to keep the previous behaviour (e.g. in product view where the attribute name is present)
Otherwise the Search More view will crash for example for sale order line because it will fetch the price of all products and then try to convert uoms for pricelist rule application without checking uom compatibility
Without this, sale pricelists cannot be based on supplier prices as the partner is never a supplier so the price would be 0
Note: behavior change ok with fp
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
The price_surcharge attribute must be computed based on the reference unit of measure (divided by the factor).
This is to make sure than 12 units and 1 dozen have the same price after pricelist computation (opw 599727).
Added test checking the correctness of pricelist computation based on unit of measures.
Add readonly attribute to avoid sending both factor and factor_inv value to the backend when saving.
This was possible if the user switched between uom_type to fill the two fields.
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.
Add rounding_method parameter on float_round method to offer
HALF-UP (default, usual round) or UP (ceiling) rounding method.
Use the second method instead of math.ceil() for product
reservations.
For UP, the python math.ceil() method uses "torwards infinity"
rounding method while we want "away from zero".
Therefore we use the absolute value of normalized_value to make
sure than -1.8 is rounded to -2.0 and not -1.
Fixes#1125#2793
This is a cherry-pick of d4972ff which was reverted at 333852e due
to remaining issue with negative values.
Use group_production_lot for serial options, group_stock_packaging for packaging, use group_tracking_lot for pallet/parcel
Groups are removed completly from the view for stock.tracking as they render the view useless.
Always display weights on the product form
They really have nothing to do with the logistic units and we don't have another group to restrict them to.
Fixes#1443
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
This reverts commit d4972ffdb6.
Seems to break some cases, at least in _product_reserve from stock/stock.py
Actual use case:
SELECT product_uom, sum(product_qty) AS product_qty FROM stock_move WHERE location_dest_id=%s AND location_id<>%s AND product_id=3645 AND state='done' GROUP BY product_uom;
returning 1 | 6
SELECT product_uom,-sum(product_qty) AS product_qty FROM stock_move WHERE location_id=%s AND location_dest_id<>%s AND product_id=%s AND state in ('done', 'assigned') GROUP BY product_uom;
returning 1 | -6
results += cr.dictfetchall()
total = 0.0
results2 = 0.0
for r in results:
amount = uom_obj._compute_qty(cr, uid, r['product_uom'], r['product_qty'], context.get('uom', False))
results2 += amount
total += amount
Total = 1, amount = -5
It should actually be
Total = 0, amount = -6
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
Modified product ceiling() to use float_round() with special mode
for rounding UP (away from zero), avoiding pathological cases where
float representations errors were ceiling to the superior unit.
Also added correspding tests for rounding_method=UP
Fixes issue #1125, and replaces PR #1126.
At 96f038a product-related fields were removed due
to an important product.template/product.product
refactoring. As the field values were simply
dropped, they may not be nullified when upgrading an
existing database. Forcing them to False will take
care of it.
When no order is forced, it's more user-friendly if the products are ordered by alphabetical order.
This will mainly be applied:
* In the list view in the back-end
* In the eCommerce, for products with equal website_sequence
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).
This can give a performance boost on large databases
and should not be a concern in terms of access control
as the inheritance already grants access to the parent
records.
[FIX] product: user who don't use product variant can't edit the price of the product in product view. This behavior is not understandable. Add a function inverse to set the value (remove the variante price before change the list_price of the template)
product.product reuses most of the product.template views however some parts need to be excluded or replaced.
Instead of adding template only parts in base view and removing it for product, split the views in 'common' (product_template_form_view), 'template only' (product_template_only_form_view) and 'product only' (product_normal_form_view) where the first is inherited by the other two. The attribute mode='primary' on both second views allows to make sure that future inheritance of product_template_form_view and product_template_only_form_view will work with the full rendered product_template_form_view view.
This allows us to have valid buttons in crm for bill of material (filters based on active_id).
Also cleaning the mess with circular dependencies.
In new API, selection field value is checked (against the selection's possible
values) at both read and write. For pricelist.type this requires read access
to product.pricelist.type.
The lst_price field on product.template is a related to list_price. As we do not allow to set a value for related fields at creation (see orm.py , L4180), we display the list_price instead (float field).
On the product.product form, we display the lst_price (function field, readonly) as we don't want to allow changing the template price from the product. opw 609497
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
This is a temporary workaround until these fields are removed from the template or the view is more explicit about the meaning of this field (the one on the first variant)
Fix#542
[FIX] product: add module 'report' module in its dependencies
The product pricelist report model inherit from report.abstract_report but report was not present in dependencies.
sve-openerp
Christophe Simonis
Olivier Dony
Josse Colpaert
Christophe Matthieu
Denis Ledoux
Martin Trigaux
Raphael Collet
David Monjoie
Mohammad Alhashash
Martin Trigaux
Cedric Snauwaert
Lionel Sausin (Numérigraphe)
Grzegorz Krukar
Richard deMeester
Fabien Meghazi
Commandant Custo
rsi-odoo
Fabien Pinckaers
Hardik Ansodariya
kevin wang
Frederic van der Essen
Thomas Groutars
Richard Mathot
qdp-odoo
xmo-odoo
Xavier Morel
Atul Patel
Antony Lesuisse
Jaydeep Barot
Guewen Baconnier
Denis Ledoux
Martin Trigaux
Guewen Baconnier