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
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
Olivier Dony
Fabrice Henrion
Xavier Morel
Commandant Custo
Martin Trigaux
Aaron Bohy
fka-odoo
Denis Ledoux
Christophe Simonis
Cedric Snauwaert
Josse Colpaert
Christophe Matthieu
Raphael Collet
David Monjoie
Mohammad Alhashash
Martin Trigaux
Lionel Sausin (Numérigraphe)
Grzegorz Krukar
Richard deMeester
Fabien Meghazi
Commandant Custo
rsi-odoo