Review Work Order pop up design:
- add mo reference and Components tab at first
Manufacturing Readiness:
- set 'When all components are available' as default
closesodoo/odoo#75675
Task: 2527408
Related: odoo/enterprise#20515
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
For improved cost analysis, byproducts can now have a "cost share" (out
of 100%) indicated. This cost share will by multiplied by the total BoM
cost (i.e. components + operations costs) and reflected in the stock
valuation. The final product will also have the byproducts cost
subtracted from its final stock valuation. This is of course only
applies when costing methods are appropriate (i.e. non-standard price).
Additionally, we can now "Compute Price from BoM" for byproducts (via
its product form) and the BoMs that it is a byproduct of are now counted
towards its # BoMs smart button (we will now also see these BoMs when
clicking on the smart button). Of course when there is no cost share for
byproducts then clicking on "Compute Price for BoM" will not change the
a byproduct's cost and if there are multiple BoMs the prodcut is a
byproduct of, the calculation will only be based on the first BoM it
finds (i.e. same as current logic for manufactured products).
BoM Cost report has been updated to include byproducts with cost shares
(byproducts with cost share = 0 will not show up in report).
Additionally we update the report to display operations only costs now
that BoMs are allowed to have no components in them.
Part 1 of Task: 2440068
Upgrade PR: odoo/upgrade#2727
Related ENT PR: odoo/enterprise#20169
Part-of: odoo/odoo#74951
Improve the UI for the MO and the WO with some new features, better readability and usability
- The forecast for the MO in draft makes the preparation of a MO easier. The behavior of `forecast_availability` depend of the state of the move
- The sum of expected duration and real duration in the MO, make the MO visually clearer
- The field Scheduled Date is rounding up to the next hour for less manipulation
- The automatic reference in a BOM if there is already a BOM for this product allows making less manipulation. I'm using this variable `number_of_bom_of_this_product` with the result of the query inside so I didn't need to do the query twice and the query doesn't take the current bom.
- A rounded value is better for the OEE in WO summary
- Have a tag for a workcenter can be a good idea to add more information to it. I'm using a random value for the color of the tag, we are doing it frequently to have a random color on multiple think.
- Knowing the final product of a WO is clearer
- To notify the user when creating a product with a reference that are already existing is a good idea.
- Change some color in the MO view for better readability
- And more minor tweak (like to align some part in the view)
--- Links ---
The PR: https://github.com/odoo/odoo/pull/74540
The PR on enterprise: https://github.com/odoo/enterprise/pull/20006
Task related: 2442895
closesodoo/odoo#74540
Related: odoo/enterprise#20006
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
On BoM, a component line can be filter out depending
of the product variant to manufacture
(with "Apply on Variant" field).
Extend this feature to operation and byproduct line.
task-2614126
closesodoo/odoo#74973
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Batch the bom_search of bom_lines in mrp_bom.explode.
If we represent the bom hierarchy as a graph, essentially
switch from a depth-first to a breadth-first search, allowing
to batch search boms for each depth level, hence improving
the overall performance.
closesodoo/odoo#71137
X-original-commit: 44ae26e4477e1b76b3dbb0f1acd50e8553b14d71
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Before this commit, It was always showing all
Unit of Measures in By Product lines.
With this commit, We are showing UoMs based on Category
of Selected Product's UoM.
closesodoo/odoo#70367
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
previous implementation works slowly for products with many variants.
Performance Test
================
* ~5 K product.template
* ~14 K product.variants
* ~12 K mrp.bom
* ~414 K mrp.bom.line
Reading time for the field on a product with ~1000 variants
Measuring total request time:
* Before 9,5 sec
* After:
** without module upgrade 1,5 sec
** with module upgrade 0,3 sec
Measuring query execution in psql:
* Before 7,2 sec
* After:
** without module upgrade 0,7 sec
** with module upgrade 0,001 sec
---
opw-2494423
closesodoo/odoo#69293
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Some usage of `_bom_find` are performance bottleneck (one request by
product). By example, when the mrp is installed, search products
with fields compute by `_compute_quantities` (e.g. 'Negative forecasted
quantity'). it is due to the override of `_compute_quantities`
in mrp which will make (in the worst case) a `_bom_find` for each
product in the DB.
To avoid this situation the `_bom_find` method become batched
which can handle several products in once. The signature of the method
has changed and uniformize in all module.
Example performance Gain:
------------------------
In a DB with 7000 products (type 'product'), 500 locations, 1800 BoM,
9000 Stock moves, etc. Search in the tree view with filter "Negative
forecasted quantity":
Before: 10879 (nb SQL request) 12.67 +- 0.11 sec (Total RPC Time)
After: 159 (nb SQL request) 1.82 +- 0.03 sec (Total RPC Time)
task-2439019
Because kits might never be in stock, it's impossible to fullfil the
quantity of a reordering rule: asking a mini/maxi quantity on a kit
makes no sense.
Odoo will continuously propose to order more to reach the quantity
necessary for the kit, but will never reach the asked qty, as it's a
kit, not a manufactured product.
OPW-2448878
closesodoo/odoo#68362
X-original-commit: c47a9319c081105e46e56f881b25fd6442266089
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Add two indexes (on `product_id` and `product_tmpl_id`)
on the `mrp.bom` model to speed up `_bom_find`
which is highly used and it uses always the `product_tmpl_id` and
sometime the `product_id` in the search domain.
Performance Gain:
With a DB with 2K BoM, a `_bom_find` search (`product_id` and
`product_tmpl_id` are in domain): The SQL execution time
is +- 5 times faster.
task-2390516
closesodoo/odoo#64934
X-original-commit: 64861aed03b616820d717bc08e7c38c56145e0f2
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
- make `bom_id` required. No sense to have a operation without BoM
- `company_id` of operation is now related
- Clean the multiple `allowed_operation_ids` into related
fields instead.
task-2373638
The `bom_id` field has a One2many inverse `byproduct_ids`
then it should by index to avoid bottleneck if byproduct is
highly used by a lot of different BoM
Performance improvements:
When there is 20K of Byproduct line, read a BoM is x1.8 faster.
task-2389380
`product_tmpl_id` of BoM line should be readonly,
there is no sense to change the product template from
the BoM line model. Also it avoids useless write on product
and inverse recomputation.
opw-2420830
closes#63631closesodoo/odoo#63890
Issue: odoo/odoo#63631
X-original-commit: 5a4746141670bdd241d85c7908a57ee9efa56c3f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
When select a BOM in the field, now we only search by the finished
product name. In this commit, we will also match the reference of the
BOM.
Task 2326786
PR #57945
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Current behavior before PR:
It is possible to create a BOM that has a BOM line that reference the
same product as the BOM itself. This is undesirable as when we create a
manufacturing order for this product we will have an error.
It is a regression bug that was introduced in commit
575353e251a0cce3bbff759edaeb56b5718beb11 between v12 and v13.
Behavior after PR is merged:
When saving a BOM it will validate that no product line references the
same product, or the same product variant, as the BOM itself. Note that
it is allowed to have a BOM for a product variant that references
another variant of the same product.
opw-2347941
closesodoo/odoo#59633
X-original-commit: 917e4c67b4aa14ca71ec6cba4bc6d20a86459f42
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Duplicate a BoM with operations and some BoM line consume in specific
operation. The operations are well duplicated but the 'consume in
operation' field still point to the original BoM's operations.
This commit search for the operation to replace based on the name and
the workcenter_id.
Task : 2278147
X-original-commit: 4c6d445dfd561a236b1b171ccbcc2ff2b6236640
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Now, by default, a Bill of Material have a flexible
consumption instead of strict consumption. Also
add new consumption choice: a flexible consumption
but with a warning when the bom isn't respected.
Also, now, the strict (a new warning option) consumption
is checked only when we try to mark as done the MO.
task-2241471
Set the operations directly on the Bill of Material.
Duplicate the demo data where a routing was shared.
Adapt the tests.
Remove the following feature:
- set the same routing on parent and kit child bom
- when planning, if the component of the kit have the same operation
than a component of the parent bom, merge these operations
task-2241471
1. Install MRP
2. Launch an Odoo shell on the database
3. Type the command
`print(env["mrp.bom.line"].browse(1).child_line_ids)`
Traceback will occur with exception
odoo.exceptions.CacheMiss: ('mrp.bom.line(1,).child_line_ids', None)
This occur due to the empty value that the computation of the field
yields, which is not saved in cache.
Fix by adding a default value.
opw-2226951
closesodoo/odoo#50950
X-original-commit: fc885499a3c75d8d564569ec4cea41a8a64f3164
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create products P1 & P2
- Create a BOM for P1
Operation O1
- Create a BOM for P2
Use 1 unit of P1
Operation O2
- Open the 'Structure & Cost' report for P2
The BOM of P1 is not taken into account in the report.
This happens because a 'Sub BoM' must have the same Operation than the
parent (or no operation set).
There is no real functional reason for this, so we remove the
limitation.
opw-2246370
closesodoo/odoo#50743
X-original-commit: 5d3e88aa919a69ad54076637e72b880552e2a0be
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Creation of production order from a bom with 0 quantity to produce will
fail. As there is already a constraint on the quantity to produce on MO,
this commit adds the same constraint on BoM.
closesodoo/odoo#48485
X-original-commit: 1330500885ae096372ab32fba4ffc9db252dd2d4
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- In inventory app, create an attribute that is dynamic
- Create a product with a variant with the dynamic attribute
- Create a bom for the product with some specific component for that variant
- Open structure and cost
A crash occurs.
In this case, the object is a `product.template`, so a condition
product-specific shouldn't be checked.
The template is set at:
https://github.com/odoo/odoo/blob/3588487ab4ef867f7fb981a395deaf298eb4a4e4/addons/mrp/report/mrp_report_bom_structure.py#L107
opw-2198976
closesodoo/odoo#47769
X-original-commit: 3c476dee5d3a0cc0fde0f9c6620507a07929e4fc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Usecase for example A black T-shirt made from a white T-shirt and
black color. This behavior was possible in 12.0 and 11.0 and was
removed by commit 77a8d92196Close#40540closesodoo/odoo#44084
X-original-commit: 575353e251a0cce3bbff759edaeb56b5718beb11
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
If a Bill of Material is created without code (eg. when created as a new
group from a kanban view grouped by BoM) we would get a traceback
instead of an error.
With this changeset, we get a "You cannot create a new Bill of Material
from here." error if it is being tried.
opw-2124162
fix#38904closes#40289closesodoo/odoo#40457
X-original-commit: 32c13cd7d1387c0ea81a9bb5968d18c2b8f32051
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
On Mobile the byproduct One2many only empty line.
It's due to default kanban view using the _rec_name
in order to display the byproduct name. On byproduct the
_rec_name is not defined nor the field name so the kanban
is empty.
closesodoo/odoo#37403
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Ensure proper domains are applied and enforced on relation fields thanks
to the `check_company` attributes.
Make sure unbuild have proper sequence for each companies.
The produce wizard and workorders company is the one of the production.
The BoM line company_id is the one of its bom_id.
Added some tests.
task-1985992
* account, hr_expense, mrp, sale, sale_product_configurator, stock_account,
website_sale, website_sale_comparison
Before this commit, the `product.attribute.value` were stored on the variants.
This required filtering of attribute lines to find the appropriate matching
`product.template.attribute.value` that were used in most of the business code,
such as when computing the `price_extra`.
This also prevented to have multiple attribute lines for the same attribute,
which is needed to handle use cases such as grape varieties for wine products.
This will be done in the following commit.
After this commit, the combination of `product.template.attribute.value` will be
directly stored on the product variant.
Other changes
=============
Add `combination_indices` on product, which allows to quickly find a variant
matching a combination (1 simple indexed equality query as opposed to 1 query
with as many joins as there are attribute lines), and to add an easy
SQL constraint to ensure active combination uniqueness.
Add active field on `product.template.attribute.line` and
`product.template.attribute.value`, with the same behavior as variants:
They become archived if they can't be unlinked. This allows to keep the database
consistent, such as archived variants correctly keeping all their values, sales
order lines keeping their custom and no_variant. This is done with the help of
`ondelete=restrict` on the corresponding m2m fields, and the `unlink` methods
falling back to archiving when `unlink` is restricted.
Part of task-1912579
PR: #32946
This commit avoid searching into quants and stock.moves, the quantities
(available, forecasted, ...), for service product in order to speedup the search
on big recordset
closesodoo/odoo#35920
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
Since previous commit moved decimal_precision module's feature into base,
use the new syntax for fields declaration
Remove the imports to the removed module
Remove the module from dependency in manifest
sed -i "s|digits=dp.get_precision('\([A-Z a-z]*\)')|digits='\1'|" **.py
sed -i "/from odoo.tools import decimal_precision as dp/d" **py
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Steps to reproduce the bug:
- Create a product template A with variant color: black and white.
- Create attribute : size : 16gb and 32 gb
- Create a bom with template A.
- Add a bom line L with product B
- Save the bom ,edit it and select an attribute value for L
Bug:
All attribute values of the database (color: white, color: black, size: 16 gb, size 32 gb)
were displayed.
opw:2006988
closesodoo/odoo#33949
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Nicolas Pierre