Adds a new UoM category (surface) and two UoM: m² and ft²
Could be useful for some kind of products like paper or fabric.
task-2443585
closesodoo/odoo#66174
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Changed the uom of product package if product_length_in_feet_param
of ir config parameter for product is not 1. Previously its value
was meter.
For following fields updated the uom -
1) packaging_length
2) width
3) height
closesodoo/odoo#64735
Taskid: 2418421
Related: odoo/upgrade#2089
Related: odoo/enterprise#15848
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
In commit ab76c421c2 the Dozens unit of measure was moved to demo data.
Unfortunately, this data is used in enterprise module product_unspc in a
post init hook.
As a consequence, when installing this module without demo data, the
initialization crashes.
With this commit, the Dozens uom is moved back to regular data.
closesodoo/odoo#63120
X-original-commit: e194c39e044710cbf314427d77bd2b87795c34ff
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
1) forbid deletion of main uoms & categories
2) warn modifications of main uoms data.
Except for the working Hours uom, which isn't a strict UoM
representation and could change between countries (and/or be deleted).
3) Also move the Dozen UoM to demo datas, it's a confusing UoM and isn't
used by the majority of databases.
4) Restrict deletion of used uoms on main models.
On sale orders and account moves the uoms couldn't be deleted thanks to the
SQL constraint covering the display_type logic, but the generic error message
is more clear for a user when deleting an uom.
Change the default rouning digits of all UoMs to be two, also change the
decimal.precision of UoM to be two. Adapt all the tests.
Also to avoid hardcoded digits in `should_consume_qty` widget.
PR #56000
X-original-commit: 460ec0402a2352a5b179d81935f7230f6bc97cb7
This removes the measure_type field which has become unused and
causes issues when users try to add new uom categories.
Task-2043927
closesodoo/odoo#41056
Related: odoo/enterprise#6945
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose
=======
Parentheses in the label of units of measure sometimes make
reading needlessly uncomfortable.
Specification
=============
Remove parentheses in the name of every standard uom.uom and hardcoded
occurence on views/field names.
TaskID: 2030444
closesodoo/odoo#34492
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This reverts commit 43d51466c8.
Reasons:
- too complex having 2 UoM "Hours"
- impossible with UoM to modelise month: is that 30 days or 31 ?
Task-1971491
closesodoo/odoo#34497
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This commit introduces the duration (time) units of measures, flagged as internation
unit of measure. We already have the "working time" UoM, but those ones are customizable
and might differ from the International System of Units; indeed, one working day means
8 hours (more or less) for some company.
The rational here is, when we are handling datetime, we need to get the UoM in the Odoo
System to convert the result; for instance, computing the difference between 2 datetimes
will return the number of days (or hours). But you need to match it with an odoo UoM to
extract informations from that value.
This unit of measure 'duration' is like a master data, because existing in the real world
and that many module will depend on.
Task-1971491
closesodoo/odoo#32840
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This commit rename the measrurement_type 'time' into
'working_time' to be more precise, as time might means
duration.
This changes prepare the distinction between 'working time'
and international duration unit.
Task-1971491
Users can configure multiple references in a same
category. This might cause problems during conversion
and does not make sense.
Since this is a "late" constraint, we define it in
python to avoid conflict with existing data.
We allow user to have multiple unactive reference, but
force to have exactly one active. So when a new UoM
category is created, user have to encode the reference
unit first, and then the bigger/smaller ones.
This commit also update stock tests, since they were
redefining new reference UoM in the same category, and
finally, this commit provides some tests for this
uniqueness and custom UoM behavior.
Task #1820076
In order to restrict some uom field to some uom category, it is required to
add a measurement type on uom.category. Also, this will lessen the use of
master data.
Some technical justifications:
- measure_type is not required, to allow people creating their own
uom.category. Those ones will not interfere with addons business.
- measure_type is unique: we restrict to only one category containing
time, weight, ... in order to avoid mismatch category during conversion.
(2 different weight categories can not be converted).
- measure_type on uom.uom is stored: to allow search and domain on
field, we need to store it. Usually, UoM are not updated every day,
and the number of uom in a database is not that important.
To illustrate this mecanism, a domain is added on
'project_time_mode_id', in project module. This field
is use as timesheet default uom, and we obviously want to
restrict it to time category (timesheeting in liter does
not make sense ...)
Task #1820076
Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.
This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.
svs-odoo