Added 3 improvements to the process of updating the state of an invoice in Odoo, according to the state in DGI:
**For invoices that have been rejected by DGI:**
 - Added logic to automatically notify relevant users when an electronic invoice (CFE) is rejected by the DGI and, as a result, canceled in the system. The goal is to ensure that there is always someone responsible who is informed to correct and resend the receipt.
 - Added logs in the terminal to make the debug easier in case we want to identify rejected invoices. 
 
**Particular case of an invoice that had been rejected by DGI but the user somehow fixes it and then DGI accepts it:** 
- Added logic to verify both DGI state and Invoice state and adjust it accordingly when updating invoice DGI status.
- Make 'Update DGI status' button always visible to be able to adjust invoices states.

**== Context of the Problem ==**

Previously, when Odoo detected that a CFE had been rejected by the DGI, the system proceeded to cancel the invoice automatically. However, this process was carried out silently, without generating any notification. This could mean that if no user or salesperson was actively monitoring the status of the receipts, the cancellation would go unnoticed, resulting in invoices that were never corrected or reissued.
For the case of a previously rejected and then accepted invoice, we always thought that 'Rejected' state in DGI was a definite state and could not suffer any change. But recently it has been a case that this state changed, creating inconsistencies in Odoo invoices states as they appear as cancelled. With these changes, the user can adjust the invoices state by clicking 'Update DGI status' button.



**== Automatic Notification Logic ==**
With the new functionality, every time an invoice is automatically canceled due to a DGI rejection, the system posts a message in the document chatter to report the situation. The logic for determining who is notified is as follows:

_Scenario 1: Invoice with Internal Followers_

- If the canceled invoice has at least one internal follower (an Odoo user), the system will perform the following actions:
- It will post a message in the invoice chatter.
- It will tag (@) all internal followers to notify them directly.


_Scenario 2: Invoice without Internal Followers_

- If the invoice does not have any internal followers, the system will search for a more general but relevant audience to ensure that the notification is addressed:
- It will post a message in the invoice chat.
- It will tag (@) all users who belong to the “Accounting Manager” permission group (technical name: group_account_manager).


Task ODOO: #[1362](https://latam-localizations.odoo.com/web?debug=1#id=1362&cids=1&menu_id=88&action=131&active_id=16&model=project.task&view_type=form)
Task ADHOC: #[54799](https://www.adhoc.inc/odoo//project.task/54799)

Forward-Port-Of: odoo/enterprise#100523
Forward-Port-Of: odoo/enterprise#94502

<h1><strong>Standardize Floating Toolbar Layout </strong></h1>
<p>This PR unifies the look and feel of the floating toolbars inside the website builder.<br>
Over time, subtle inconsistencies slipped in — animation dropdowns looked different from font popovers, highlight pickers used custom layouts, scrollbars behaved differently depending on the browser, and sublevel options in highlight configuration had no hierarchy.</p>
<p>This work brings all those elements together into <strong>one cohesive design</strong>, improving usability and giving the editor a more mature, polished visual identity.</p>
<hr>
<h1><strong>Key Changes Before and After </strong></h1>

1. Animation Dropdown Styling
<img width="290" height="290" alt="image" src="https://github.com/user-attachments/assets/35f31160-1ece-4bc6-9d2a-6ac055ef80ca" />|<img width="290" height="290" alt="image" src="https://github.com/user-attachments/assets/5cf42575-cb6b-4480-a665-505aeb022f24" />

2. Highlight Picker Grid & Scroll Behavior
<img width="270" height="299" alt="image" src="https://github.com/user-attachments/assets/da732527-03ea-42b0-8a46-514eabfa66b0" />|<img width="269" height="304" alt="image" src="https://github.com/user-attachments/assets/9a55eba5-7c2f-4441-9699-847e276938aa" />

3. Highlight Configurator Sublevels
<img width="266" height="123" alt="image" src="https://github.com/user-attachments/assets/5aa7422c-e07c-476f-a770-aa3290cdd728" />|<img width="271" height="125" alt="image" src="https://github.com/user-attachments/assets/35a80c61-ce23-45f8-af36-ea6a6709a10e" />

4. Row Labels alignment
<img width="312" height="231" alt="image" src="https://github.com/user-attachments/assets/4d014c03-1e81-44eb-8980-69f7cd065577" />
<img width="305" height="228" alt="image" src="https://github.com/user-attachments/assets/7056700e-71a2-4b05-b6ae-a07d7fec5b23" />




<hr>
<h1><strong> What This PR Solves</strong></h1>
<h3><strong>Before</strong></h3>
<ul>
<li>
<p>Floating toolbar components each had their own styling quirks.</p>
</li>
<li>
<p>The animation dropdown looked visually disconnected from other popovers.</p>
</li>
<li>
<p>Highlight picker used a custom popover with inconsistent scroll behavior.</p>
</li>
<li>
<p>Nested highlight options lacked indentation or visual hierarchy.</p>
</li>
<li>
<p>Font size selector didn’t use the system font.</p>

</ul>
<h3><strong>After</strong></h3>
<ul>
<li>
<p>All floating toolbar dropdowns now share a <strong>standardized design</strong>.</p>
</li>
<li>
<p>Animation options match the layout and behavior of the <strong>font style popover</strong>.</p>
</li>
<li>
<p>Highlight picker now uses <code inline="">dropdown-menu</code> styling with consistent scrollbars.</p>
</li>
<li>
<p>Sublevel rows in highlight configurator now show a clear hierarchy.</p>
</li>
<li>
<p>Font size selector uses system fonts for typographic consistency.</p>
</li>
<li>
<p>Scrollbars are thin, predictable, and uniform.</p>
</li>
</ul>
<hr>
<h1><strong> Technical Breakdown</strong></h1>
<h3><strong>1. Unified Dropdown &amp; Popover Styling</strong></h3>
<ul>
<li>
<p>Added thin-scrollbar styling at the web level for consistent behavior.</p>
</li>
</ul>
<h3><strong>2. Floating Toolbar Awareness</strong></h3>
<ul>
<li>
<p>Introduced <code inline="">dropdownClass</code> logic to let floating toolbars override default select styling.</p>
</li>
<li>
<p>Removed the <code inline="">o-hb-select-dropdown</code> class when not needed to match the font popover.</p>
</li>
</ul>
<h3><strong>3. Sublevel Rows in Highlight Configurator</strong></h3>
<ul>
<li>
<p>Added <code inline="">hb-row-sublevel-1</code> to represent nested highlight styles.</p>
</li>
<li>
<p>Updated <code inline="">--o-hb-row-bg-color</code> to align with sidebar styling and improve contrast.</p>
</li>
</ul>
<h3><strong>4. System Font in Font Size Selector</strong></h3>
<ul>
<li>
<p>Font size preview now uses the system font defined in CSS variables.</p>
</li>
</ul>
<h3><strong>5. Improved Test Coverage</strong></h3>
<ul>
<li>
<p>Ensures highlight picker grid scrolls correctly.</p>
</li>
<li>
<p>Confirms animation dropdown matches the font popover visually.</p>
</li>
<li>
<p>Verifies correct indentation of nested highlight configurations.</p>
</li>
</ul>
<hr>
<h1><strong>Affected Modules</strong></h1>
<ul>
<li>
<p><code inline="">website</code></p>
</li>
<li>
<p><code inline="">web</code></p>
</li>
<li>
<p><code inline="">html_builder</code></p>
</li>
<li>
<p><code inline="">html_editor</code></p>
</li>
</ul>
<hr>
<h1><strong>Task</strong></h1>
<p><strong>task-5075191</strong></p>

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