After an update, older browser tabs can keep using an outdated live connection in the background. This change detects those outdated tabs, stops them from reconnecting, and prompts users to reload so they move to the current version faster.

The WebSocket worker is tied to a specific version. When this version
changes, the worker's URL updates, creating a new worker. The old
worker remains active as long as clients are connected to it. The
updates may take time to propagate, leading to both the old and new
workers being active simultaneously.

This PR introduces a mechanism to ensure that client code updates are
applied quicker.

When the worker opens a WebSocket connection (typically after the
server comes back online following an update), it provides the server
with its version. If the version is outdated, the server closes the
connection. Consequently, the worker will no longer open new WebSocket
connections.

Clients connected to an outdated worker will receive a notification
prompting them to reload the tab. Additionally, outdated tabs will not
be considered for the main tab election process.

Fixed an issue where users could not open the manufacturing order overview when the same product was used as both a component and a by-product. This prevents an error screen and lets valid manufacturing orders be reviewed normally.

Steps to reproduce:
- Manufacturing > Products > Bills of Material > New
- Add any item as component then the same item as by-product
- Confirm
- Operations > Manufacturing Order > New
- Pick the product associated to your newly created BoM
- Confirm > Overview

What happens and why:
Odoo raises an RPC error due to an inifinite recursion between _get_components_data and _get_replenishment_lines. Both calls are made before the manufacturing order line is flagged as processed so the functions are mutually dependant on the other finishing first. The looping call is conitionally called when document_in and document_out are the same, which seems to be why the stock moves 'move_in' (component) and 'move_out' (by-product) need to be configured this way on the BoM.

Why is this an error:
This prevents the user from accessing the overview of a valid MO.

What this fix does:
Moves the flag to before the looping call can be made, so the recursive call does not propagate infiniely.

opw-4013371

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

This update fixes time selection and display issues for locales that use 12-hour clocks with AM/PM. It helps users avoid incorrect shift or rental times when working in affected regional settings.

A bug was fixed in the Field Service Management timesheet creation process where a return statement was missing from the save_timesheet function. This fix ensures the function properly completes its operation and returns the expected result, preventing potential errors when users save timesheets for field service tasks.

This update fixes a technical issue in the timesheet timer feature where certain initialization steps weren't completing properly, which could cause display problems. The fix also improves performance by streamlining code and running multiple data requests simultaneously instead of sequentially.

In TimerTimesheetGridRenderer, super.onWillStart was not awaited. We take the opportunity to factorize some code and parallelize some rpcs.

This fix resolves an issue where manufacturing order quantities of 1,000 units or more were being incorrectly truncated in the Shop Floor display (e.g., 2,500 units showed as "2"). The problem was caused by unnecessary data conversions in the display code. After this fix, quantities now display correctly and completely, improving accuracy in the manufacturing workflow.

Steps to reproduce:
- Manufacturing > Products > BoM
- Create BoM with at least 1 operation
- New MO with Quantity to produce >= 1000
- Shop Floor > Remove filters

What happens:
Work order card truncates number of units to produce by 3 digits, i.e. a quantity of 2500 displays as 2, 34000 as 34, etc... This is caused by the successive conversions in formatFloat, they go:
Number (quantityToProduce) > String (formatFloat) > Number (ParseFloat) > String (String())
Which looks to be a dirty solution to forcefully display the float as an integer value.

What this fix does:
Getting rid of the superfluous conversions fixes the truncating issue.
The decimal precision was set to default to integer values if the precision props is not defined to conserve the original behavior since manufacturing fractions of a product seems nonsensical, but it seems a precision was passed all along and simply failed to display because of the aforementioned issue. So now 2500 displays as 2500.00 not sure if that was intended or just ignored because of the previous display weirdness.

opw-4040457

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

This fix resolves an issue where the Belgian tax report posting wizard incorrectly checked the company's country code instead of the report's country code. This caused errors when users tried to create closing entries for foreign VAT fiscal positions (such as French tax reports on a Belgian company). The fix now properly detects the correct country code for the report being processed.

Currently we just check whether the company has 'BE' fiscal country code. But this can be incorrect:
We may want to create a report for a foreign VAT fiscal position. This situation can lead to a traceback (see below).

After this commit we use the dedicated helper function `_get_report_country_code` to determine the right country code.

Reproduce:
1. Install `l10n_be_reports` and `l10n_fr_reports`
2. On the Belgian company create a fiscal position with country 'France' and a 'Foreign Tax ID'
3. On the Belgian company open the tax report and select the French tax report
4. Click on the "Closing Entry" button to create a draft closing entry move
5. Try to post the move
6. Traceback (in which `l10n_be_reports_post_wizard` appears)

task-4063968

Forward-Port-Of: odoo/enterprise#67548
Forward-Port-Of: odoo/enterprise#67122

This update corrects how currency exchange rates are calculated when currencies have different conversion ratios (like Turkish lire at 100 TRY = 18.30 BGN). Previously, the system was not accounting for these ratio differences, leading to inaccurate exchange rates. The fix ensures all currency conversions are calculated correctly by properly factoring in the ratio multiplier.

Description of the issue/feature this PR addresses: Added parsing and multiplication of 'RATIO' field with 'REVERSERATE' for more accurate currency rate calculations. For example, Turkish lire is per 100 TRY 18.30 BGN. The current date is also adjusted to use today's date correctly within the function.

Current behavior before PR: Wrong calculation of currencies with different ratio <> 1.0

Desired behavior after PR is merged: