Versions
--------
- 17.0+

Steps
-----
1. Set up 10% price-included tax;
2. copy the tax to a B2B version that's price-excluded;
3. create a B2B fiscal position mapping the first tax to the second;
4. create a $10 product using the first tax;
5. create a branch for the current company;
6. switch to the branch company;
7. set up a sale order with the fiscal position;
8. add the product to the order.

Issue
-----
While the line displays the correct B2B tax, the unit price displays $10, as if it was computed without any taxes, instead of a price-excluded tax.

Cause
-----
In the `_compute_price_unit` method, it filters out all tax records linked to the product that don't have the same company as the order line, so the parent company's tax does not get factored in.

Solution
--------
Rather than requiring strict equality between companies, also allow taxes that belong to a parent company of the line's company.

opw-4853042

Forward-Port-Of: odoo/odoo#217012
Forward-Port-Of: odoo/odoo#216124

reproduction:
18.0+18.1:
1. In Todo, insert an inline image, and create a link including the image and some text
2. click on the text part, click edit button, modify the label area and click apply
3. the image is removed

Test case 2:
1. go to Recruitment, and open an application and click "Send interview"
2. click on the link inside the template, change the url
3. apply, format of the button breaks

18.2:
same flow with test case 2, click apply causing a traceback

18.3:
same flow with test case 2, click on the link, do nothing and click away, the popover not close

Fix: a partial back port of https://github.com/odoo-dev/odoo/pull/4633 The idea is that when the link doesn't only contain text, we don't show the label input field nor apply the label to the link. Because the label field extracts/display the text content of the link element, the field doesn't support html fragment, applying the label on a link including another element inside will break it.

on 18.4+, we only rename the variable from isLabelHidden to showLabel

task-4881878

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

Forward-Port-Of: odoo/odoo#217226
Forward-Port-Of: odoo/odoo#215023

Steps to reproduce:
- Install Sales and Stock
- Activate the multi-step routes setting
- Go to a Delivery route in the warehouse
- Change the `location_dest_id` of the operation type set on the rule
- Enable the "Location Dest. Taken from Rule" checkbox
- Ensure `rule.location_dest_id` and `operation_type.location_dest_id`
  are different
- Create a Sales Order (SO) for a product with quantity = 5 and confirm
- Change the SO line quantity to 3 and save

Issue:
A second picking is created with a move taking the product from
`rule.operation_type.location_dest_id -> rule.operation_type.
location_src_id` with quantity = -2.

This happens because the decrease in the SO quantity triggers a
negative move, and this move is not merged with the existing
positive move. Instead, a new move is created in the opposite
direction.

In `_merge_moves`:
https://github.com/odoo/odoo/blob/3c4275fb00255e519f01bf5547eff1db3a59d4b5/addons/stock/models/stock_move.py#L1191-L1193

It checks if the negative move has similar characteristics to the
existing positive moves. However, the `neg_key(neg_move)` differs in
`location_dest_id`, so the merge fails. This happens because the
negative move does **not** read the `location_dest_id` from the rule —
unlike the procurement, which **does** use the rule and therefore
creates positive moves with the correct destination.

When the negative move is created with the procurement, it initially
has the correct `location_dest_id`. But then:

https://github.com/odoo/odoo/blob/b984c72df398c4fe942d8894442e4e893ca0660e/addons/stock/models/stock_move.py#L1191
triggers `_compute_location_dest_id`, which doesn't consider the
`rule.location_dest_id` and defaults to `operation_type.
location_dest_id`, causing the merge to fail due to mismatched
destination_locations.

The positive move has read the correct value, because when it
was assigned to a picking, the picking has the correct destination
from the procurement. But for the neg_move it has picking None so
it maps to the operation_type without consdiering the location from
rule checkbox.

opw-4793171

Forward-Port-Of: odoo/odoo#212355

**Steps to reproduce**
- Set "Extra Hours Validation" to "Automatically approved"
- Create an attendance for an employee
- Change the "Extra Hours" to a different value
- Create another attendance for this employee (not necessarily on the same day)
- See that the "Extra hours" of the previous attendance has been recomputed, resetting the value entered by the user.

**Cause**
When creating an attendance for an employee, we recompute the `validated_overtime_hours` for the other attendances of this employee
https://github.com/odoo/odoo/blob/cac96f5d3c391ea0d52da2e3433e7eabe07e8fb0/addons/hr_attendance/models/hr_attendance.py#L426 In case of attendances with no validation, this field is synced with the `overtime_hours`
https://github.com/odoo/odoo/blob/cac96f5d3c391ea0d52da2e3433e7eabe07e8fb0/addons/hr_attendance/models/hr_attendance.py#L156

**Solution**
We may still want to recompute the `validated_overtime_hours` of automatically approved attendances, since it is their default state, unlike manually approved attendances.

If the `validated_overtime_hours` field is different from `overtime_hours`, it means it has been modified. In that case, we avoid recomputing it. This doesn't guarantee a manually set value will never be overriden by a change in its dependencies, but it reduces the likelihood.

opw-4639230

Forward-Port-Of: odoo/odoo#207806

**Steps to reproduce:**
- Install accountant, l10n_ar and l10n_latam_check
- Switch to an Argentinian company (e.g. (AR) Responsable Inscripto)

- Make sure that USD currency has a rate different than 1

- Create a journal:
  * Journal Name: Checks journal
  * Type: Cash
- Save the journal
=> a Cash Account should be automatically created
- In "Incoming Payments" tab of the journal, set:
  * "New Third Party Checks" with the Cash Account
  * "Existing Third Party Checks" with the Cash Account
- In "Outgoing Payments" tab of the journal, set:
  * "Existing Third Party Checks" with the Cash Account

- Create an invoice:
  * Customer: [an Argentinian customer] (e.g. ADHOC SA)
  * Currency: ARS
  * Invoice Lines:
    - Quantity: 1
    - Price: 150000.00
    - Taxes: VAT 21%
- Confirm the invoice
- Pay the invoice:
  * Journal: [the created Checks journal]
  * Currency: ARS
  * Checks: [add a line with the amount of the invoice]

- Create a bill:
  * Vendor: [an Argentinian customer] (e.g. ADHOC SA)
  * Currency: USD
  * Invoice Lines:
    - Quantity: 1
    - Price: 500.00
    - Taxes: VAT 21%
- Pay the bill:
  * Journal: [the created Checks journal]
  * Payment Method: Existing Third Party Checks
  * Checks: [add a line and select the check used to pay the invoice]

**Issue:**
When the check (from the invoice) is selected to pay the bill, the original amount (in ARS) is used but the currency stays in USD, which is not correct.
If the currency is changed to ARS, the currency rate is applied on the amount that is already the amount in ARS, which generates a higher incorrect amount.

**Solution:**
Use the currency set on the existing check by default.
Also prevent adding several checks with different currencies. 

opw-4741607




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

Forward-Port-Of: odoo/odoo#215435

**Steps to reproduce:**
- Install accountant, l10n_be and account_winbooks_import
- Switch to a Belgian company (e.g. BE Company CoA)
- Go to "Accounting / Configuration / Settings"
- Click on "Import (for full history)" in "Accounting Import" section
- Click on "Import WBK" in "Winbooks" section
- Upload a Winbooks file containing several journals having their "DBKID" value longer than 5 characters with the 5 first characters being identical (e.g. "SALES001", "SALES002",...)
- Import

**Issue:**
Some journals are not imported.

**Cause:**
The code of a journal is limited to 5 characters and is unique per company.
When a code is longer than 5 characters, only the 5 first characters are kept.
In this case, several journals to create have the same 5 first characters.
Therefore, only one of them is created.

**Solution:**
If the code of a journal to create has the same first 5 characters of a journal that has already been created (and the same last 5 characters), we use a generic code formatted with a starting "*" char followed by a number that is incremented.
This format allows to quickly find it if we want to change its value once imported.
This solution is limited to 9999 journals that have a code that can starts with the same 5 characters than another journal, but it should be more than enough.

opw-4812655

Forward-Port-Of: odoo/enterprise#86068

### Background
In https://github.com/odoo/enterprise/pull/85026 we changed the behaviour of `l10n_mx_edi_post_time` so that it gets set during the CFDI sending process, rather than when the invoice is posted.

This was needed to ensure that the post time both reflects the sending time and is re-used if the invoice needs to be re-sent.

### Bug description
Since then, several Mexican customers have reported that some CFDIs are sent duplicated, with a difference of a few seconds in the CFDI's Fecha.

### Analysis
A disconnection might occur during sending of the CFDI. In that case, the PAC will process the CFDI, but in Odoo the transaction will be rolled back, and the `l10n_mx_edi_post_time` will be lost. When Odoo re-sends the CFDI, it will take a new `l10n_mx_edi_post_time`.

### Solution
Commit before performing the API call so that the `l10n_mx_edi_post_time` gets committed to DB.

opw-4780096

Forward-Port-Of: odoo/enterprise#89263
Forward-Port-Of: odoo/enterprise#89117

Currently a traceback is occurring when the user tries to create a Draft Entry, 
in the batch that contains payslips of multiple companies.

**To reproduce this issue:**

1) Install hr_payroll_account and switch to multi-company environment 
2) Create two employees with two running contracts respectively 
3) Now create a Batch record from payroll/payslips/batches 
4) Create two playslips with different companies with the created batch 
5) Compute both the payslips and open the batch
6) Now, try to click on the  Create Draft Entry

**Error:**
A traceback will occur.
```
ValueError: Expected singleton: res.company(1, 2)
```

**Cause:**
When the user created multiple payslips with multiple companies containing the same batch 
and tries to create a Draft Entry, we filtered out the payslips based on the payslip state, 
and try to change the state to Done using the action_payslip_done method.

https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll/models/hr_payslip_run.py#L70

So the self will contain multiple payslip recordsets with different company in each payslip. 
This leads to the above traceback when accessing company_id from self
https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll_account/models/hr_payslip.py#L61

**Solution:**

In payslips, the company_id field should be in readonly state, 
since the value of the company_id will  computed from the employee_id which is a required field.

Also raised a validation Error for the previously created record to handle the traceback.

Related Upgrade PR:- https://github.com/odoo/upgrade/pull/7763

opw-4797089

Forward-Port-Of: odoo/enterprise#88307
Forward-Port-Of: odoo/enterprise#86628