Odoo/addons/mrp/models/mrp_production.py, branch 14.0

[FIX] mrp: use correct UoM for each component in MO

2021-05-26T13:36:42+00:00

In a Manufacturing Order, the components' quantities are rounded using
the rounding precision of the produced product's UoM. This leads to
incorrect values.

To reproduce the error:
1. In Settings, enable "Units of Measure"
2. In UoM, edit Units:
    - Rounding Precision: 1
3. Create two products P_finished and P_compo
    - P_compo's Product Type: Consumable
    - P_compo's UoM: L
    - P_finished's UoM: Units
4. Create a Bill of Materials
    - Product: P_finished
    - 1 Component:
        - Product: P_compo
        - Quantity: 0.2
        - UoM: L
5. Create a Manufacturing Order:
    - Product: P_finished
6. Confirm, Mark as Done

Error: Qty to consumes became 0 and consumed qty is 0. Both values
should be 0.2L, but they have been rounded using the rounding precision
of Units

OPW-2529462

closes odoo/odoo#71146

Signed-off-by: Steve Van Essche

[FIX] mrp: prevent MO validation with no consumption

2021-05-17T15:54:21+00:00

If a MO is validated with all of its (component)
move_raw_ids.quality_done = 0, then when trying to validate the
nonsensical "The quantity to produce must be positive" validation error
will occur. This is due to all move_raw_ids being marked as Cancelled,
which auto-updates the MO state to cancelled, which prevents the
validation from properly completing.

To avoid this error, we prevent the user from having 0 consumption for
all components.

Task: 2422698
Related (v13 fix + bug description) Task: 2463893
ENT PR (test fixes): odoo/enterprise#18355

closes odoo/odoo#70900

Signed-off-by: Arnold Moyaux

[FIX] mrp: fix multi plan MO

2021-04-19T09:42:08+00:00

The button plan of in the manufacturing order tree view doesn't
confirm correctly the draft MO selected (but only the related moves).

task-2479111

closes odoo/odoo#69409

Signed-off-by: William Henrotin

[FIX] mrp: set default product on unbuild order

2021-05-02T19:52:53+00:00

Before this commit, Creating Unbuild order using
 Unbuild Button was resetting Bom as it was calling
`_onchange_product_id` after setting `mo_id` which was
resetting Bom on Unbuild order.

To Fix Issue, We setting `default_product_id` so It would not
reset `bom_id` when `_onchange_product_id` is called.

Fixes: #70216
Odoo Ticket: 2521788

closes odoo/odoo#70218

Signed-off-by: Rémy Voet

[FIX] mrp: remove workorder_ids on removing bom_id

2021-04-20T16:27:58+00:00

Method `_onchange_workorder_ids` will create workorder_ids
for the the selected bom but it was not re-setting it on removing
BoM.
It was causing issue on `_action_confirm` as Bom for the selected
WO will not be found.

closes odoo/odoo#69564

Fixes: #68261
Signed-off-by: Rémy Voet

[FIX] mrp: avoid dynamic domain for product_id in MO form

2021-03-12T06:48:22+00:00

Issue:
On DB with a lot of product (e.g. 50K) the MO form is very slow
open/modify. It is due to the `_compute_allowed_product_ids` which
will set the `allowed_product_ids` fields with all product ids possible
(32K), then the `convert_to_record` will take a bunch of time to filter
out no-active product.

Fix:
In your case, to avoid to send bunch of ids to the web framework and
bypass the costly `convert_to_record`, we decided to simply (static) the
domain of `product_id` (`mrp.production`). The flow will be slightly
different (doesn't filter depending of `bom_id`) but still good and
maybe better (we can now modify the product without removing the
BoM/product in the MO form).
The `_compute_allowed_product_ids` remains unchanged (for stability)
but we remove the `allowed_product_ids` from the form view
(then a upgrade is needed to be effective).

opw-2475151

closes odoo/odoo#67696

Signed-off-by: Arnold Moyaux

[FIX] mrp: update date on move when editing date after planning WO

2020-12-31T10:56:10+00:00

Behavior prior to this commit:

 - normally when editing the Scheduled Date on a MO, the date on the
 related stock moves is updated.  However this does not happen once the
 MO is planned
 - if the date is edited and the MO is planned, the MO is automatically
 unplanned, but the date on the stock moves is not automatically updated

Behavior after this commit:

 - when the date is updated on the MO and it is planned, the dates on the
 stock moves will automatically update, so that the behavior is
 consistent with how it would work if you clicked Unplan first then
 updated the date.

opw-2417108

closes odoo/odoo#63652

Signed-off-by: Nicolas Galler

[FIX] mrp: avoid traceback on company reset

2020-12-29T15:50:12+00:00

- Create a new MO
- Remove the company name

The user see a traceback

This occur because the compute method does not check if the company is
set

opw-2422441

closes odoo/odoo#63889

Signed-off-by: Nicolas Lempereur (nle)

[FIX] mrp: cancel WO from backorder when no quantity to produce.

2020-12-23T11:26:54+00:00

- Have a finished Product FP (quantity 1) processed in
2 workcenters: A and B
- Create manufacturing order for FP1, raise the quantity to produce to
10
- process first workorder with lower quantity (i.e. 5)
- process second workorder with even lower quantity (i.e. 4)
- Mark MO as completed, creating a backorder
- There will be 2 backorders for the original MO.
- Process the workorder A of the last MO (record 0 quantity).
Now check the work orders report

Work orders report is showing incorrect qty for A (i.e. 6 and not 5)
The last workorder processed display Quantity 1.
This occur because the report display the quantity handled by the
workorder (1), not the actual produced quantity (0), but this is a
technical limitation of the pivot view.

A solution is to cancel the workorder when we detect a quantity to
produce equal to 0. This will also avoid users starting by accident the
workorder timer when there is no work to do.

opw-2411203

closes odoo/odoo#63728

Signed-off-by: agr-odoo

[FIX] stock: make `do_unreserve` faster than ever

2020-11-18T10:32:09+00:00

`do_unreserve` is a action that can be made in the tree view of
`stock.picking` but it was very slow and not batched.
For 80 picking with -/+ 10 `stock.move.line` related each
(calculate on 5 sample of 80 pickings):
It took 17947 +- 2741 SQL requests, 7.37 +- 1.09 sec of SQL
and 8.13 +- 1.31 sec of python execution (+- 15.5 sec in total)

Make some  change to speed up the unreservation of
multiple picking/move:
- Batch the call of `_do_unreserve` of move in picking
- Use OrderedSet instead of RecordSet to reduce the complexity of
`_do_unreserve`. (Become significant when len(recordset) > 1000)
- Add `.with_prefetch()` in the unlink of stock move line
to patch issue with prefetching + unlink + cache.
- Batch `_recompute_state`
- Also batch the `do_unreserve` of MO

Result after change in the same samples:
It take now 1438 +-	20 SQL requests, 0.45 +- 0.02 sec of SQL
and 0.68 +- 0.02 sec of python execution (+- 1.13 sec in total,
13 times faster). Note that the gain increase proportionally.

task-2383111

closes odoo/odoo#61879

Signed-off-by: Arnold Moyaux