Steps to reproduce:
1. Open database with version saas-18.4
2. Install module l10n_fr_hr_payroll_with_accounting
3. Make sure that your company's country is France.
4. Set `Salary Journal` in: `Configuration` -> `Structure` -> `FR: Employe Carde` -> `Employe Carde`
5. In Payroll app create a payslip for any employee having contract.
6. Make sure in `other inputs` you make new type and in that in the `availability in structure` has Employee cadre chosen.
7. Now with that Salary Input type click on `Compute sheet` button.
8. The `Invalid Operation` error card will appear.

**Description:**

In saas-18.4, the model hr.contract was [changed](https://github.com/odoo/upgrade/blob/fa44eb03c2b46d948e20dc6f5ac01dca2b625b90/migrations/hr/saas~18.4.1.1/pre-migrate.py#L41) to hr.version . All related code https://github.com/odoo/enterprise/commit/46052c4bc5ad1bd2549a6125202e0671b56beac8 was updated to use version instead of contract. in this commit.

However, in the module l10n_fr_hr_payroll, there where some fields which is still using `contract` to refer other fields .
https://github.com/odoo/enterprise/blob/e29aadef1a81c662d9a4d33879b440dbe4390c0b/l10n_fr_hr_payroll/data/l10n_fr_hr_payroll_employe_cadre_data.xml#L130 Because of this, Odoo raises the error `Wrong python code name 'contract' is not defined when evaluating the code`.

I have fixed the issue by updating the name from contract to version in that module contract to version.

opw: [5259362](https://www.odoo.com/odoo/project/70/tasks/5259362)

Forward-Port-Of: odoo/enterprise#100112

This issue requires a valid Colombia DIAN certificate and credentials to reproduce. Access to the Odoo Knowledge article *[CO] EDI – DIAN* is necessary for the setup. With `l10n_co_dian` installed and a Colombian company:

- Set up the DIAN Sales journal with the correct *Technical Key / Technical Control Key* as described in the article.
- Ensure that each invoice name follows the required format.
- Create a commercial invoice in the DIAN Sales journal (invoice date set in the past) and send it to DIAN.
- Create the corresponding bill by copying the invoice reference and the CUFE code, then acknowledge receipt.
- Run the server action **“Colombian EDI: Update Invoice Commercial States”**.

Repeat this process at least twice. The CUFE code on the older invoice is removed.

The server action calls `_l10n_co_dian_cron_update_event_status()`, which triggers `l10n_co_dian_action_update_event_status`. In this method, we remove `l10n_co_dian_document_ids` from moves considered duplicates. This deletion removes the `document_id` from the older move since it is treated as a duplicate of the newer one (both are in the “sent” state).

However, in the compute method for `l10n_co_edi_cufe_cude_ref` (`_compute_l10n_co_dian_cufe`), we always reset `l10n_co_edi_cufe_cude_ref` to `False` before checking documents. Since the oldest move ends up with no documents, it never enters the loop and the CUFE code is lost.

opw-5257129

**Description of the issue/feature this PR addresses:**
This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab during video calls.

**Current behavior before PR:**
When background blur is enabled during a video call, the user’s video stream freezes if they switch to another browser tab. This happens because currently frame scheduling relies on `requestAnimationFrame` and `setTimeout`, which modern browsers pause or throttle in inactive tabs to conserve system resources and battery life.

**Desired behavior after PR is merged:**
The user’s video stream continues to render with the background blur effect, even when the browser tab is inactive. This is achieved by moving the frame scheduling logic to a Web Worker, which runs in a separate thread and is not subject to browser throttling. As a result, a consistent frame rate is maintained at all times.

task-[4781227](https://www.odoo.com/odoo/project/1519/tasks/4781227)

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

Forward-Port-Of: odoo/odoo#226455

**Steps to reproduce:**
- In the config, click the ePos Printer checkbox
- Also check Automatic Receipt Printing and Skip Preview Screen
- Put a default preset with Name as it's identification
- Go in the restaurant and make a sale, pay for it
- When going back to the floor plan, a traceback appears

**Why the fix:**
This current problem arises because we are trying to access the current order, but we are on the floor plan, so there is no current order yet. The order is undefined, so we try to access *undefined.floating_order_name* and a traceback appears.

But the root issue is deeper than this. In the restaurant, the order is initialized when clicking a table, or when we create a floating order. But when the Skip Preview Screen option is enabled, we try to initialize the order right after the last order has been validated, like we do it in the normal PoS.

Doing this, we will try to handle the preset selection way too early, as the order is not fully initialized yet, and we will try to access data that have not been set yet.
The current error is not the only one we have with this setup, as other errors also arise if we bypass this specific error.

To fix this, we are now only initilizing the new order when we click on a table that has no order or when making a floating order. We do not create a new order after the validation of the last one, even if the Skip Preview Screen option is enabled. This is only true in the restaurant, as we keep on initializing a new order after the validation in the regular PoS.

Before this commit, we also tried to create a new order when opening the restaurant from the frontend (see image below), which resulted in a traceback.
We now only create a new order if the default screen is different from the Floor Screen.
<img width="375" height="249" alt="image" src="https://github.com/user-attachments/assets/e38520f6-81e2-471e-a987-98d9426a6493" />

Starting in version 19.0, there is another waiting screen after paying and before going back to the floor plan, which handles things, so the bug is not present anymore. But the traceback we get when opening the register from the frontend is still present in future versions.

opw-5131309

Forward-Port-Of: odoo/odoo#230796

It may occur that when using 'Set Account' to reconcile a bank statement the reconciliation fail due to error "The operation cannot be completed: A reconciliation model already bears this name"

Steps to reproduce:

1. Create a current liability, reconciliable account "455010 My Account"
2. Create 2+ with a common labels (TEST RECONCILIATION)
3. Use "Set Account" button to reconcile the first transaction with account 455010.
4. Repeat 2-3 with a shorter label
5. Open Reconciliation models for the Journal and delete the one named "455010 My Account"
6. Repeat 2-3 with an even shorted label

Issue:

Reconciliation will be blocked by error during automatic creation of reconciliation model

Analysis:

It occurs because we don't take into account that old reconciliation models may have been deleted, so even if we count a singe record it may have already been labeled "<account_name> (1)"
Improved the naming by looking at the existing models and increasing the counter if necessary

opw-5184696

Forward-Port-Of: odoo/enterprise#100468
Forward-Port-Of: odoo/enterprise#98785

When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial product.

The issue occurred because the average price computation was mixing stock moves of different products when consuming valuation layers, leading to a UoM singleton error.

Steps to reproduce:
- Create storable products P1 and P2:
  - Category: AVCO
  - P1 UoM: Unit
  - P2 UoM: Dozen
- Create a sale order with 1 unit of P1
- Confirm the SO
- Open the generated picking
- Duplicate it → a new picking is created and still linked to the same SO
- Change the product on the duplicated picking to P2
- Confirm and validate it
- Create a return on this picking and validate it
- Go back to the original picking of P1 and try to validate it

Problem:
A UserError is raised due to mixed products in the average price computation, resulting in a “Expected singleton: uom.uom(...)”

This fix ensures that average price is computed only using stock moves belonging to the same product.

opw-5027089

Forward-Port-Of: odoo/odoo#236706