When planning a Manufacturing Order, if an operation takes place in work
center with a different time zone, the computed date may be incorrect
(the start date may be outside the working hours)

To reproduce the error:
(Use demo data. Current timezone: Europe/Brussels)
1. In Settings, enable "Work Orders"
2. Open an existing Work Center
3. Click on "Standard 40 hours/week"
4. Set Timezone to "Asia/Bangkok"
    - Note that all slots are between 8:00-12:00 and 13:00-17:00
5. Create two storable products P_compo and P_finished
6. Create a Bill of Materials BM:
    - Product: P_finished
    - BoM Type: Manufacture this product
    - Components: 1 x P_compo
    - Operations: 3 x Operation with existing work centers
7. Create a Manufacturing Order:
    - Bill of Material: BM
    - Quantity: 100
8. Save, Confirm, Plan

Error: (it depends on the time the test is done) The 'Scheduled Start
Date' of the second operation is incorrect. Adding the time zone
difference gives a time that is outside the work center's timetable
(i.e., outside 8:00-12:00 and 13:00-17:00).

The computations do not consider the time zone of the work center.

OPW-2393330

closes odoo/odoo#70841

Related: odoo/enterprise#18524
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

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 <svs-odoo@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.

closes odoo/odoo#70853

X-original-commit: 0a39cd7ddf0e95a12abc7fbb87f4701e5ab72716
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Aurelienvd <Aurelienvd@users.noreply.github.com>

When updating the quantities available for a product, an inventory move
is generated without setting the product_tmpl_id, as this field is related
to the product_id of the move. However, when creating the move, Odoo will
consider it a default missing value and will try to fill it in the method
default_get.

When navigating to the product variants of a template from the template form,
a default_product_tmpl_id is set in the context pointing to the template. This
context is propagated to the update quantity action to create/update quants for
the variant.

The problem when dealing with kits is that the products available to update
their quantities are the components of the kit. When navigating to a variant
and updating the quantities of a component of the kit variant, the default product
template in the context will be the kit template.

This is causing that, when generating the inventory move, the move is created with
product_id of the component, and product_tmpl_id of the kit template.

This issue creates a critical data inconsistency as the component's template is set
to the kit's template, which apart from making no sense generates a recursion error.

To fix this, when triggering the action to create/update quants for a kit product, it
must be ensured that no default product template is being set.

closes odoo/odoo#71055

X-original-commit: bdeea73dc1efb6ff7d02cc2f58347a69762bcc3c
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

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 <amoyaux@users.noreply.github.com>

To reproduce:
1. create and confirm a MO with register number checks on operations
2. duplicate the MO
The register number checks won't show up in the new MO

We didn't set copy=False for workorder_id on stock.move, when copy a
confirmed MO, the new moves are linked to old WOs on old MO. New WO
didn't link to any moves.
When create quality checks, we only create "register ..." checks for WOs
with move_id. As a result, new WOs without move_id won't have those
checks.
To fix, set copy=False on workorder_id of stock.move

Task 2484939

closes odoo/odoo#68348

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

On unbuild order creation, when the user selects a manufacturing order,
the UoM of the quantity will be defined with the product's UoM instead
of MO's UoM.

To reproduce the error:
(Use demo data)
1. In Settings > General Settings, enable "Units of Measure"
2. Create two products P_finished and P_compo
    - Both are storable
    - Qty on Hand of P_compo = 12
3. Create a Bill of Material
    - Product: P_finished
    - Component: 1 x P_compo
4. Create a Manufacturing Order MO
    - Product: P_finished
    - Quantity To Produce: 1 Dozen(s)
5. Check Availability, Produce, Mark as Done
6. Create an Unbuild Order:
    - Manufacturing Order: MO

Error: The unit of measure of the quantity is incorrect, this is
Unit(s), it should be Dozen(s)

The method `onchange_mo_id` defines the product, therefore the method
`onchange_product_id` is also called and here is the issue:
`onchange_product_id` will override the UoM using the product's UoM.

OPW-2467017

closes odoo/odoo#70904

X-original-commit: b80321acd5553466862b5c2c56cff014765ecf99
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

FW-Port of odoo/odoo#70675 (13.0)

closes odoo/odoo#70728

X-original-commit: 85c24961ab9ff5c1c79eb7415c97c46d9a77cca3
Related: odoo/enterprise#18283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>