In the form view of a unit of measure,
if the unit of measure was of type
"Bigger than the reference unit"
The help in the tooltip of the ratio field was wrong
Besides, this help message was contradictory
with the formula written just below the field.
opw-631672
Improve commit bf31ab6718a8b9c8afdd29120e5056533b0a2ade:
- do not use the product.product name_search() when there is no
search term (it's only useful with a search term
- do not use the product.product name_search() when the extra
domain (args) has a criterion on IDs - these will be *template*
ids, not *variant* ids, so the results would be wrong
- Since templates and variants use a different natural `_order`,
perform an extra name_search() on templates after gathering the
ids to return, to apply the proper sort ordering. Increases the
penalty by doing 2 name_search() calls.
This issue could be seen e.g. in the breadcrumbs where the
display_name variable is displayed for templates, and indirectly
relies on name_search() due to an old hack in call_kw in order to
implement the "future_display_name".
When generating the list of all needed variants, the attributes are sorted based
on the order in field attribute_line_ids while, when comparing with existing
variants, the order of the attributes on the product.product is the order
on the field attribute_value_ids. As both order could be different (no direct
relation), variants could be wrongly recreated instead of keeping existing one.
Make sure the attribute lists are always sorted.
Fixes#4361
The natural order was discarded when merging results with a set,
and this was actually un-necessary as the second search()
excludes the previously found `ids`.
In the rare places with a m2o field to product.template
(e.g BoMs), it is necessary to be able to search on product
codes, EAN, etc, the way it works on product.product.
This is done by delegating the name_search to product.product
and then returning the corresponding templates.
This has a small penalty of executing name_get() twice,
but is simpler and more robust for future changes.
An alternative would have been to extract the name_search()
method into a mixin and mix it on both product.product and
product.template. However this would be more brittle and
only work as long as the name_search implementation strictly
uses fields that are present in both tables.
OPW 626662
The precision 'Product Unit of Measure' was defined after the declaration of kg.
Since fc85a7ee, the precision of kg is set in data to 0.001.
As the Product Unit of Measure was not defined yet, the rounding was stripped to
(16,2) precision, so getting a rounding of 0.0 for the kg unit of measure.
[FIX] product: the declaration of decimal precision was done after
the declaration of uom precision, preventing uom precision from going above
the default decimal precision. + made the Kg unit precise up to grams by default.
Not passing the context should be exceptional, in almost all cases you should pass it.
In this specific case, not passing it will, for instance,
prevent the use of the key 'active_test' in the context,
and there is therefore no way to count all variants, including disabled ones.
For companies not working with variants,
it is important to be able to search in the
Products menu (product.template) using
product codes.
It is useful as well to see the codes
in the default kanban view too, even if
it is only the code of the first variant.
Takes care of resetting it from older versions
e.g. rev d97e7a6a4e
and c0076916f3, as
the old `variants` field that was used does not
exist anymore, crashing at opening.
When adding an extra price for a variant (through the button variant prices in the product template form) with a digits precision greater than 2 (4 for instance), the computed public price did not keep the digits precision of the extra price
Granting read-only access to Sales/Accounting Users is useless
as all employees already have it - removed. On the other hand
Sales Managers need write access to it in order to create
products, and they need it even when `sale` is not installed,
e.g. with `account` only.
Moved this access right to `product` module. The Sales
Manager group is defined in `base`, so that works.
Add restriction on product_id field to prevent the suppression of the product
if already present in an invoice.
This is to avoid the suppression of a used product variant when modifying
the list of attributes.#
Due to the constrain, the variant will be disabled instead of deleted.
Fixes#4129
Add warning message on the product form to warn users about the potential impact
of modifying variants.
Pricelist computations need to consider 2 different Units
of Measure:
- The default product UoM (product.uom_id), used as reference
for the various quantities and amounts specified in each
pricelist rules.
- The `context UoM` is the UoM in which the result is requested,
that is the list price UoM.
For example the 'price_min_margin' amount is meant for the unit
price of 1 x default UoM. When the context UoM is not the default
product UoM, it can be any UoM of the same UoM Category, and the
various quantities and amounts specified on the rule need to
be adapted accordingly:
- min_quantity (expressed in terms of the default UoM)
- price_surcharge (specified for 1 x default UoM)
- price_min_margin (specified for 1 x default UoM)
- price_max_margin (specified for 1 x default UoM)
The UoM corrections were not done consistently and resulted in
wrong prices when computing the price using a non-default UoM.
The cases were a conversion was needed or not were not properly
identified within the _price_rule_get_multi().
After this commit, the various code branches in _price_rule_get_multi
always ensures that:
- price requested for: `qty` of `qty_uom_id`
- `qty_in_product_uom` is the requested `qty` converted to default UoM
- current (intermediary) price: `price` for `price_uom_id`
Therefore `price` and `price_uom_id` are always in sync, and `price_uom_id`
can always be compared with `qty_uom_id' in order to know whether
a conversion is still needed.
This patch also corrects and extends the regression tests
introduced at revision 79ebe10.
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
Christophe Simonis
Denis Ledoux
Commandant Custo
Jeremy Kersten
Antony Lesuisse
Olivier Dony
Leonardo Donelli
Anton Chepurov
Leonardo Pistone
Frédéric van der Essen
Christophe Matthieu
moylop260
David Monjoie
Fabrice Henrion
Xavier Morel
Martin Trigaux
Aaron Bohy
fka-odoo
Cedric Snauwaert
Josse Colpaert
Raphael Collet
Mohammad Alhashash
Martin Trigaux
Lionel Sausin (Numérigraphe)