#### This PR addresses 2 issues with the update of Manufacturing Order with kit products in the BoM (and subsequent bugs). Please see commits for details on the issues.

Issue 1
-----
When using the "Update BOM" button for a confirmed manufacturing order, quantities for components derived from kit products are incorrectly updated to the kit product's bom instead of the new required quantity.

Issue 2
-----
When using the "Update BOM" button for a confirmed manufacturing order, components used to produce a specific variant of a kit product are not added to the MO consumables.

Commit breakdown
-----
- Commit 1 (handle component quantities - first ticket):
  - use the correct exploded value for the quantity (divided by the original quantity as the ratio isn't done for the top-level bom)
  - update test_update_mo_from_bom_with_kit with correct values
  - extend test_update_mo_from_bom_with_kit for when the kit components' quantities are updated
- Commit 2 (handle components for specific variants - second ticket):
  - adapt the filtering of bom lines to keep them based on the kit's attribute instead of the end product one's
  - add a new test_update_mo_from_bom_with_kit_vraiants
- Commit 3 (handle confusion of multi-variants/UoM kits - additional issues):
  - change bom_lines_by_id to a defaultdict to consolidate quantity of components
  - update test_update_mo_from_bom_with_kit to test for multiple UoMs
  - update test_update_mo_from_bom_with_kit_variants to test for multiple variants

-----
Tickets:
opw-4473337
opw-4480039

Description of the issue this commit addresses:

When registering a SEPA payment, it is possible to get a UserError telling you
to validate therecipient bank account while it is validated.

---

Steps to reproduce:

1. Install account.
2. Activate SEPA Credit Transfer (SCT) in the settings.
3. On the Bank journal's settings, input an account number.
4. Make sure the accounts used for the transfer authorize sending money.
5. Create a move in the misc journal with multiple lines and distinct partners.
6. Post the move. Go in the journal entries. Select it. "Register Payment".
7. Change the Payment Method for SEPA Credit Transfer. "Create Payments".
8. A UserError shows up.

---

Desired behavior after this commit is merged:

No UserError shows up, the payments are created.

---

Note on the fix:

The error happened because one of the condition for raising the UserError is a
value of a record in a many2one relation which is a stored computed field. As
the payment is created with a list of values, the compute method is not
triggered and the many2one remains empty while it should not.

This fix makes sure the partner_bank_id is only put in the payment values once
it has been computed to avoid keeping it false.

---

opw-4518374

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

When a user tries to access a vendor bill where the vendor is their own company, Odoo displays a warning indicating that the user is trying to invoice themselves. To determine whether to show this warning, we check if the partner has any related `employee_ids`.

However, if the user does not have the `"Employees / Officer: Manage all employees"` access rights, they cannot check the `employee_ids`, leading to an access error when opening the vendor bill.

Steps to Reproduce:
1. Create a vendor bill where the vendor is set to your own company.
2. Try to access the vendor bill with a user who does not have `"Employees / Officer: Manage all employees"` access rights. Issue: An error occurs because the user lacks permission to check the related `employee_ids` for the vendor.
Refer to this [video](https://drive.google.com/file/d/1hIUTbNYhZxT4aOtNq8XE1z7uy7K_HJM1/view) for clearer steps.
opw-4539017

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

* stock{,_barcode, _barcode_quality_control}, quality_control

### Issue:

Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.

The above issue can be triggered in many situations. Here are the two major ones:

### Use case I:

Creating a delivery or an internal transfer on the fly from the barcode app.

### Steps to reproduce:

- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133

### Use case II:

Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailled operations.

### Steps to reproduce:

- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.

### Fix:

We ensure the creation of quality checks for moves that end up being created but will never be confirmed.

### Technical limitation:

Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.

Enterprise: https://github.com/odoo/enterprise/pull/81850

opw-4480104
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

**[FIX] Refunds counted twice in Modelo 390**

With https://github.com/odoo/odoo/pull/180029, refunds balance are now counted twice in the totals of modelo 390.

Prior to that change, refund had no tax grid for modelo 390, and the refund amount were pulled cross-report from modelo 303. When that PR added the negative tax grids for refunds, it made the refund balances count twice toward the totals in section 2 (once with the negative modelo 390 tag, then one more time pulled cross-report from modelo 303).

This PR aims to fix the modelo 390 refund by mimicking the behavior of Modelo 303, with tax grids dedicated to refunds for different categories of VAT.

To do so, the following changes were made to the tax grids

- Refunds with VAT receivable 
Replaced `-mod390[X]` tags on lines having -`mod303[41]` with `-mod390[62]` 
Replaced `-mod390[X]` tags on lines having -`mod303[40]` with `-mod390[639]`

- Refund with VAT accrued 
Replaced `-mod390[X]` tags on lines having -`mod303[14]` with `-mod390[29]` 
Replaced `-mod390[X]` tags on lines having -`mod303[15]` with `-mod390[30]`

- Refund with reverse charge 
Replaced `-mod390[X]` tags on lines having -`mod303[12]` with `-mod390[27]` 
Replaced `-mod390[X]` tags on lines having -`mod303[13]` with `-mod390[28]`

- Refund with surcharge equivalence 
Added `-mod390[43]` on lines with `-mod303[25]`
Added `-mod390[44]` on lines with `-mod303[26]`

And the balance expressions for the lines
`mod_390_casilla_62`
`mod_390_casilla_639`
`mod_390_casilla_29`
`mod_390_casilla_30`
`mod_390_casilla_27`
`mod_390_casilla_28`
`mod_390_casilla_43`
`mod_390_casilla_44`
were adapted to use these new tags instead of pulling the data cross-report from Modelo 303.

**[IMP] Split the remaining tax grids for Modelo 303 and 390.**

Modelo 390 report contains several cross-report reference to report 303. This can cause conflicts as both report receive changes at a different pace.

First, this PR adds the Modelo 390 tax grids on taxes, next to their corresponding Modelo 303 tax grid equivalent, and then adapts the Modelo 390 report line expressions to use these new tax grids.

The changes made all follow the same logic:

If a Modelo 390 report line `mod_390_casilla_XX` expression is a cross-report to a certain Modelo 303 `mod_390_casilla_YY` tax grid balance, then add tag `+mod390[XX]` on taxes that use `+mod303[YY]`, then adapt formula of line `mod_390_casilla_XX` expression to be the sum of that new tag.

Additionally, some lines missing from the report were added, for the surcharge equivalence section.

`[663] Base imponible 0%`
`[664] Cuota devengada 0%`
`[691] Base imponible 0.26%`
`[692] Cuota devengada 0.26%`
`[35] Base imponible 1%`
`[36] Cuota devengada 1%`
`[665] Base imponible 0.62%`
`[666] Cuota devengada 0.62%`
`[693] Base imponible 1%`
`[694] Cuota devengada 1% `

Then, two errors were fixed in some taxes

- Removed `+mod390[26]` from `account_tax_template_p_iva0_ic_bc` invoice base line, as that tag is for 21% tax line of intracom tax.
- Removed `+mod303[16]` from `account_tax_template_s_req0` as it is for surcharge equivalence 1%, not 0%.

Lastly, some cross-report reference to Modelo 303 were not adapted, as they use an external value (manual input) in the Modelo 303. In that case, a cross-report reference is better suited. Else, the user would have to manually input the data in both reports. These are:

`mod390[63]` from `mod303[43]`
`mod390[522]` from `mod303[44]`
`mod390[654]` from `mod303[62]`
`mod390[655]` from `mod303[63]`
`mod390[656]` from `mod303[74]`
`mod390[657]` from `mod303[75]`
`mod390[659]` from `mod303[67]`
`mod390[85]` from `mod303[77]`

opw-4520183

Currently, an error occurs when downloading e-Faktur if its `Luxury Good Taxes (ID)` record has been deleted. This results in preventing the user from generating the e-Faktur.

**Steps to produce:**
- Install the `l10n_id_efaktur_coretax` module.
- Change the  current company to `ID Company`.
- Navigate to `Settings > Technical > Sequences & Identifiers > External Identifiers`.
- Delete record with `External Identifier: l10n_id_tax_group_luxury_goods`
- Create a new invoice with the customer "ID Company".
- Click **Download e-Faktur**.
- Observe the error.

**Error:**
```
ValueError
ValueError('External ID not found in the system: account.1_l10n_id_tax_group_luxury_goods') while evaluating
'action = records.download_efaktur()'
```
The error occurs because the system attempts to fetch the tax group `l10n_id_tax_group_luxury_goods` at [1], but it is unavailable as the user has already deleted it.

This commit ensures that if the tax group does not exist, the function will return `None` instead of raising an exception.

[1] - https://github.com/odoo/odoo/blob/87d68fc6562504168bd0de8a5356bdebb4559e70/addons/l10n_id_efaktur_coretax/models/account_move_line.py#L20

Sentry-6309401666

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Currently an error occurs when the user tries to uninstall `Sales` or `helpdesk_sale_timesheet`
after creating a helpdesk ticket.

Steps to generate an error:
- Create a database without a demo and install helpdesk_sale_timesheet.
- Create a helpdesk ticket.
- Now try to uninstall sale_management (Sales).

Error `KeyError: 'helpdesk.ticket.sale_line_id'`

This issue was generated because in the helpdesk ticket we have the `use_helpdesk_sale_timesheet`
field (see [1]), which is a depends field of the  `compute_sale_line_id` method, which is the compute
method of the field sale_line_id (see [2] and [3]) in the helpdesk ticket.

In helpdesk code line [4] tries to update the value of the field `use_helpdesk_sale_timesheet` since this
field is related to the helpdesk ticket (see [1]) value of this field also changed in the helpdesk ticket,
and the value was changed the compute method trigger because this field depends on the compute method.

This commit will solve the above issue by executing an SQL query instead of writing the team
field so it doesn't trigger depending on that field.

[1]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L27 [2]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L31-L38 [3]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L77-L78 [4]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk/models/ir_module.py#L15

sentry-6308112739

* stock{,_barcode, _barcode_quality_control}, quality_control

### Issue:

Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.

The above issue can be triggered in many situations. Here are the two major ones:

### Use case I:

Creating a delivery or an internal transfer on the fly from the barcode app.

### Steps to reproduce:

- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133

### Use case II:

Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailed operations.

### Steps to reproduce:

- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.

### Cause of the issue:

For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.

### Fix:

We ensure the creation of quality checks for moves that end up being created but will never be confirmed.

### Technical limitation:

Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.

Community: https://github.com/odoo/odoo/pull/202725

opw-4480104