The error occurred because multiple POS orders with different `user_id` were grouped together for invoice creation, and the code attempted to access `self.user_id.id`, which expects a single record but received multiple (`res.users(1, 2)`).

Steps to Replicate:
- Open any POS shop (Ex: Furniture Shop) and select a Customer.
- Add any item to the order and complete the order.
- Close the session, go to Backend and open POS orders.
- Make sure the states of the orders are all in `to invoice` state, and check that salesperson should not be all the same (atleast one salesperson should be different and the customer should be same).
- Select all the Orders, click `Create Invoices` and click Create and see the error.

Error:
`ValueError: Expected singleton: res.users(1, 2)`

Solution:
-  Solved the error by grouping the POS orders by both `user_id` and `fiscal_position_id`, ensuring each group contains orders from only one user, which prevents the singleton error when accessing `user_id.id` during invoice creation.

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

Forward-Port-Of: odoo/odoo#217238
Forward-Port-Of: odoo/odoo#208833

**Steps to reproduce:**
- Install accountant
- In Accounting settings, activate "Audit Trail"

- Create an invoice:
  * Customer: [any]
  * Invoice Lines:
    - Product: [any]
    - Start Date: [2 months ago]
    - End Date: [2 months later]
- Confirm the invoice
=> Deferred Entries are created. Posted for the previous months and in draft for the future ones.

- Reset the invoice to draft

**Issue:**
The draft entires are correctly unlinked, but the posted ones are reversed instead of being cancelled.

**Cause:**
This fix https://github.com/odoo/odoo/commit/cc448bf77aa3d11e634e6bab6da1690a1b67a723 is supposed to cancel the deferred entries when the move is protected by the audi trail.
However we never get into the `elif move._is_protected_by_audit_trail():` branch because its condition is also included in the previous `if not move._can_be_unlinked():` branch.

Linked enterprise PR (test): https://github.com/odoo/enterprise/pull/88992

opw-4891975



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

Forward-Port-Of: odoo/odoo#217300
Forward-Port-Of: odoo/odoo#216628

**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**
- 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

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

**Problem:**
the split of the landed cost between lots doesn't
take into account if a lot has no quantity left
or if it has less than it's initial quantity

**Steps to reproduce:**
- enable the "lot & Serial Numbers" and "landed costs" settings
- create a storable product, tracked by lot
- in general information activate "valuation by Lot/Serial Number"
- select FIFO as the category
- create a request for quotation for this product for a quantity of 5 and a unit price of 10.000
- confirm and click on the receipt smart button
- on the move line click on the Lots/serial number widget on the right
- create 4 lots (L1 with 1 units, L2 with 2 units, L3 and L4 with 1)
- save and validate the picking
- create a sale order for a quantity of 2 of this product, confirm it and validate the picking
- create a new service product, in "purchase" check "is a landed cost"
- open accounting/vendors/bills, create a new one for the same vendor as the purhase order
- add a line with the landed cost and a price of 5000 (quantity of 1)
- set a bill date and save
- clik on "create landed costs"
- in the "transfers" field write the refernce of the receipt of the PO
- open inventory/reporting/valuation and type your product in the search bar

**Current behavior:**
4 lines were created :
a line of 600 for L1
a line of 1200 for L2
a line of 600 for L3
a line of 600 for L4

an additional issue, is that if we now sell the 3 remaining quantity and search our product in inventory/reporting/valuation the quantity will be zero but total value will be 600

**Expected behavior:**
the spliting should adapt to the remaining quantities like it does when lots are not involved
(for instance when there is a landed cost linked to a PO with a quantity of 5 but only 4 of those products are still in stock the value of the landed cost valuation line linked to this product is 4/5 of the landed cost)

So here it should be :
no line for L1 (no remaining quantity in L1)
a line of 1000 for L2 (only 1 remaining, so a third of the 3000 (3/5 * 5000)) a line of 1000 for L3
a line of 1000 for l4

**Cause of the issue:**
the quantity used is the one of the initial stock move line so it doesn't take into account the current number of product in the lot

opw-4828963

Forward-Port-Of: odoo/odoo#216857
Forward-Port-Of: odoo/odoo#215521

**Issue**:
When multiple invoices with different customer languages are sent and printed together, the invoice email button may appear with an incorrect translation for some of them.

**Steps to reproduce**:
- Open the Accounting app
- Go to Customers > invoices
- Create a new invoice with a customer with its language set to German
- Create a new invoice with a customer with its language set to English
- Go back to Customers > invoices
- Select the two invoices just created and click on action > Sent & Print and then click on the Sent & Print button
- Go to Settings > Technical > Email > Emails and check the two last emails. One of them should have the invoice email button wrongly translated

**Cause**:
Before sending an email, it retrieve the `type_name` using the lang of the customer https://github.com/odoo/odoo/blob/28c3b9cf10488536dce5a4927fdbe8fcd6e5a839/addons/account/wizard/account_move_send.py#L596C1-L605C14

This will trigger that compute method
https://github.com/odoo/odoo/blob/a6368e8a5787f3067d09d79516a2924b3f1207f0/addons/account/models/account_move.py#L841C1-L850C67

which set the `type_name` of all the records. Since the compute method only depends on move_type, it does not recompute type_name per record. As a result, all records may share the same type_name, regardless of language context. Please notice that `type_name` is used to display the invoice email button in the right language. 

**Solution**:
Make the compute method `_compute_type_name` depending to the lang parameter, thus it will use the right `type_name` for each email to send.

opw-4748741

Forward-Port-Of: odoo/odoo#216811

### 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

When the OCR parses documents from the same supplier concurrently, it can happen that it creates duplicated `res.partner` entry for it. This typically happen when the update of the documents is done through the webhook.
In that case, the different SQL transactions overlap each other and can't "see" the partner created by another request.

In order to prevent this, a new field `is_created_by_ocr` and a unique index are introduced to be able to detect duplicated partners created by the OCR.

This solution is quite costly as it requires introducing a new field and an index on `res.partner`...
Other alternatives were considered:
- Updating the documents through a cron instead -> introduces latency, especially on the SaaS where we can't force a cron to run immediately, even with a cron trigger.
- Introducing a new model on which we could add the uniqueness model -> also costly, requires a new model just to fix the issue, and we need a way to frequently clean the records, so probably a cron on top of it (or using autovacuum, but its frequency might be too low).
- Adding random delay on OCR side before calling the webhook -> introduces latency and no guarantee, it only reduces the chances of duplicated partners.
- Using explicit SQL locks -> no guarantee, we only know what should be locked late in the SQL transaction (after fetching the results from the OCR), it wouldn't be very effective. Locking the whole `res_partner` table from the start of the transaction would be too restrictive and equivalent to serializing the transactions. An attempt was made in #88830, but it was deemed too complicated.

task-[4904333](https://www.odoo.com/odoo/project/2068/tasks/4904333)