Steps to reproduce the bug:
- Install mrp and purchase
- Create a new user “U1” > give him only the “purchase” user access
- Log in as “U1”
- Go to purchase app > create a new PO
- Try to select any product

Problem:
A user error is triggered because we check if the product has a BOM
but since the user does not have access to MRP, an error is raised

opw-2885982

closes odoo/odoo#94183

closes odoo/odoo#121371

Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

In multi-steps receipt, when running a procurement, using "Buy" as
preferred route does not always work because the route is not
correctly configured

To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Edit the warehouse:
   - Incoming: 2 steps
3. Create a product P:
    - Type: Storable
    - Vendors: a vendor V
    - Routes:
        - Manufacture
        - Buy
4. Update on hand quantity:
   - -1 at WH/Stock
5. Open the Replenishment page
   - There should be a line with 1 x P
6. Set the Preferred route to "Buy"
7. Order Once

Error: a user error is displayed "There is no Bill of Material of
type manufacture [...] Please define a Bill [...]". This is
incorrect, it should generate a PO

The problem is simple: the Buy route is composed of one rule:
- Action: Buy
- Source Location: /
- Destination Location: WH/Input

But, when running the procurement, we first look for a rule to
fulfill the need at WH/Stock. We prioritize the rules of the
preferred route, but as explained above, the route does not contain
such a rule. Therefore, we use the other routes of the product:
https://github.com/odoo/odoo/blob/ba3bb9b701a382c4052ddb57392baeee32625937/addons/stock/models/stock_rule.py#L461-L466


And, because of step 3, it then finds the manufacture rule. This is
the reason why it tries to create a MO and why an error is raised
because of the missing BoM

OPW-3006960

closes odoo/odoo#108550

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

The current behaviour does not filter the cancelled moves when
evaluating if the product of the purchase order line is a kit.
This causes that, in cases where you have a cancelled wrong receipt
where the product was being received as a kit, if a new receipt is
created without receiving as a kit Odoo will always expect it as a kit.

After the fix, the cancelled moves will not be considered, as this is what
should be expected from cancelled operations.

closes odoo/odoo#107025

X-original-commit: 496f67ce
Signed-off-by: William Henrotin (whe) <whe@odoo.com>

If the module `l10n_de` is installed, the test
`test_kit_anglo_saxo_price_diff` will failed. This is because the flag
`use_anglo_saxon` is not enabled by default in the chart template of
German companies. Therefore, when posting the invoice, we skip the
anglo-saxon lines generation:
https://github.com/odoo/odoo/blob/f3ae759f2d54829f91badd32cacf70e8a8211288/addons/purchase_stock/models/account_invoice.py#L40-L42


This explains why the test fails.

OPW-2843861

closes odoo/odoo#94466

X-original-commit: 5af6d037
Signed-off-by: Adrien Widart <awt@odoo.com>

When changing the structure of a kit, it lead to undesirable behaviors
on Odoo

Issue 01:
1. Create 3 products P_kit, P_compo01, P_compo02
    - Type: Storable
    - Category: PC
2. Create a bill of materials:
    - Product: P_kit
    - Type: Kit
    - Components:
        - 1 x P_compo01
3. Create a purchase order PO with 2 x P_kit
4. Confirm PO and process the receipt
5. Edit the bill of materials of P_kit:
    - Add 1 x P_compo02 in components
6. Return 1 x P_compo01
7. Go back to the PO

Error: The received quantity is 0 while it should be 1.0

When processing the return, the received quantity is recomputed, which
lead to:
https://github.com/odoo/odoo/blob/59fcb31f5a0b8136dae26b70ca0087f9b5cf3d24/addons/purchase_mrp/models/purchase_mrp.py#L29
However, since in the mean time the user added a new line in the BoM,
`_compute_kit_quantities` doesn't find any associated SM
(`bom_line_moves` is empty in [3]) and thus returns 0.

Issue 02:
(Need account_accountant. Use demo data)
1. Create a product category PC:
    - Costing Method: AVCO
    - Inventory Valuation: Automated
    - Set up the Price Difference Account
2. Create 3 products P_kit, P_compo01, P_compo02
    - Type: Storable
    - Category: PC
3. Create a bill of materials:
    - Product: P_kit
    - Type: Kit
    - Components:
        - 1 x P_compo01
4. Create a purchase order PO with 1 x P_kit
5. Confirm PO and process the receipt
6. Edit the bill of materials of P_kit:
    - Add 1 x P_compo02 in components
7. Create and Post the bill

Error: an Odoo Error is raised "ZeroDivisionError: float division by
zero"

While confirming the bill, some anglo saxo lines are generated. To do
so, the valuation of the kit is computed: [1]. In the above case, it
will lead to [2]. However, since in the mean time the user added a new
line in the BoM, `_compute_kit_quantities` doesn't find any associated
SM (`bom_line_moves` is empty in [3]) and thus returns 0. Back to [1],
the quantity is used to divide the total price -> it will raise an error
if this quantity is zero

Suggestion:
Such situations should not happen: once a product is used at least once,
it should not become a kit nor have a new structure (if it was already a
kit). Otherwise, `_compute_kit_quantities` will not correctly work since
it is not possible to take the BoM changes into consideration.

[1]
https://github.com/odoo/odoo/blob/abfe37fcea5b20f77799d9331d4d011530880669/addons/purchase_stock/models/account_invoice.py#L72-L74
[2]
https://github.com/odoo/odoo/blob/75191404788ab83645ee35b779991ea6fcdfa406/addons/purchase_mrp/models/stock_move.py#L19
[3]
https://github.com/odoo/odoo/blob/7d1af314320547ab5e37c1d97cad22992c98565b/addons/mrp/models/stock_move.py#L275-L294



OPW-2780855

closes odoo/odoo#86731

X-original-commit: 34ed0746
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

In automated-AVCO configuration, buying a kit at a higher price than its
cost can create inconsistencies in the accounting.

To reproduce the issue:
(Need account_accountant. Use demo data)
1. Create a product category PC:
    - Costing Method: AVCO
    - Inventory Valuation: Automated
    -  Set up the Price Difference Account PDA
2. Create 3 products P_kit, P_compo01, P_compo02
    - Type: Storable
    - Category: PC
    - P_compo01:
        - Cost: 10
    - P_compo02:
        - Cost: 20
3. Create a bill of materials:
    - Product: P_kit
    - Type: Kit
    - Components:
        - 1 x P_compo01
        - 1 x P_compo02
4. On P_kit's form, "Compute Price from BoM":
    - The cost should be $30
5. Create a purchase order PO with one line:
    - Product: P_kit
    - Quantity: 1
    - Unit Price: 100
6. Confirm PO and process the receipt
7. Create and Post the bill

Error: There is an error in the journal items of the bill: the value for
PDA is $85

When posting the bill, for each account move line, the module computes
the stock valuation of the associated product and the price difference.
To do so, it sums the valuation of all related outgoing stock moves and
divides by the quantity to get the value per unit, then it compares with
the unit price used on the PO's line. Here is the issue: in case of a
kit, there is one outgoing move per component while the PO's line is
linked to the kit itself.

Therefore, in the above case, it uses the outgoing moves of P_compo01
and P_compo02, adds up their value ($10 + $20 = $30) and then divides by
the total quantity (one P_compo01 and one P_compo02, thus $30 / 2 =
$15). This is the reason why it considers that the unit value of P_kit
equals $15. Then, since the unit price on the PO's line is $100, it gets
a price difference value equal to $85.

When comparing the unit value of the kit and its unit price, the unit
value should not be divided by the quantity of components ($30 should
not be divided by 2). Moreover, when buying such a kit at $100, the
surplus ($70) should be distributed among each component. However, it is
difficult to define a rule to correctly weight this distribution.
Therefore, this surplus will be considered as a price difference.

OPW-2566546

closes odoo/odoo#82318

X-original-commit: 75191404
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Not sure why, some translations are missing sometimes.
Force a pull to get everything that was missing from the weekly sync

closes odoo/odoo#78369

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Steps to reproduce the bug:
- Create a BOM kit for “product K”  with:
    - 2 * “product A”
    - 1 * “product B”
- Create a PO for 1 unit of “product K” > confirm
- A receipt delivery with 2 units of “product A” and 1 unit of B will be created
- Modify the ordered Qty to 2 units of “Product K”

Problem:
The receipt delivery will not be updated correctly (4 units of product A and 3 of product B)
because the `"_prepare_stock_moves"` function computed the previous quantity wrong based on the moves quantities
since the moves are for products A and B, not product F.(do not take into account the products in kit)

Solution:
For kit products, do not calculate from the `"stock.move"`, calculate the difference between the quantity before and after the change

opw-2645719

closes odoo/odoo#77580

X-original-commit: 2fd87885
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>

This commit removes the action_confirm from the run_manufacture to do it
only after all the orderpoints have been processed.

In case a production, created in run_manufacture, triggers procurements
for one of its component. And those procurements have the same
parameters than another one still not run because after the manufacture
one in the queue. This new procurement will replenish its quantity plus
the other procurement's one.

That means too much quantity will be replenished.

closes odoo/odoo#76549

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

And forced sync of pos_discount

opw-2612642

closes odoo/odoo#74394

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.

closes odoo/odoo#74231

Related: odoo/enterprise#19850
Related: odoo/design-themes#43
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>