opw-617036:
In my current timesheet, if you add a a required field on the timesheet ids lines, and add data in the summary tab, it was possible to validate the timesheet lines while requried fields were missing.
When a line is not present in the partial delivery wizard, computation variables are initialized with generic values (zero quantity, zero price,...). Instead of setting the uom to False, keep the quantity of the move.
This makes a difference only when the quantity of the move is 0. That means that the move will be marked as complete and can be processed.
This avoids trying to update the stock.move with a uom at False. opw 616844
This is a workaround for an ORM limitation. A stored function field is
not updated when it should if the "source" field is also a stored function
field
In certain cases, before running an update unregistered models will try to
register hooks. Trying to wrap create and write on these will cause
AttributeError on model_obj which would be None
Signed-off-by: Sandy Carter <sandy.carter@savoirfairelinux.com>
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
General totals were not computed at all, due to the condition "if not self.ids" which was always true as self.ids wasn't set.
Besides, a parameter allows to display only partner with balance greater than 0, which was completely ignored by the totals computation methods: The totals always included all partners, even those having balance equals to 0
When generating the report 'Timesheet Profit', got a warning "The domain term '('user_id', '=', [...])' should use the 'in' or 'not in' operator."
This warning is due to the use of the '=' operator to compare the field 'user_id' while the reports sends a list of ids.
Fallback to still accept a single id in case of customised reports.
Source and destination locations are required and not displayed in the form view.
Adding new items when recieving a picking can not be easily guessed as we can put different locations for each line, using default locations may not be the expected result.
Instead should modify the original picking or create new one.
Fixes#2074, opw 612768
At the end of the onchange call product_id_change, the uom may have changed (e.g. if product in different category).
To compute the quantity, we need to use the new uom and not the first one (that may be Unit, default value)
The computation of the price without pricelist should take care of the unit of measure.
e.g. if computing discount for objects in dozen (on a product with price in unit), returned unit price should be (price*12) where 12 is the factor to go from dozen to unit.
Otherwise the compared prices (with and without pricelist) would not use the same unit of measure and the comparaison would be inconsistent. (opw 599727)
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.
Backport of 79bed94 (project user access to resource.calendar) and adding the access to resource.calendar.attendance.
It is needed to compute function fields such as day_open (present in form view of project.issue)
Fixes#3201
Sheth Sunny
Thibault Delavallée
Christophe Simonis
Paramjit Singh Sahota
Denis Ledoux
Martin Trigaux
Mohammad Alhashash
Julien Legros
Sandy Carter
Jeremy Kersten
Antonio Esposito
Ravi Gohil
Frederic van der Essen
Samus CTO
Christophe Simonis
Martin Trigaux
Cedric Snauwaert