Friday, January 30, 2026
5 changes · saas-18.4
Resolved issues and error corrections
This update fixes an issue in the French Profit and Loss report where account 649 was incorrectly categorized. The change aligns the report with French accounting standards (PCG 2025 & 2026) by moving the account to the appropriate 'Wages and Salaries' section. This ensures accurate financial reporting for French businesses using the Odoo Enterprise solution.
Original PR description
## Issue In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"*…
## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).
## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
- *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
- *Wages and salaries*: **649 is not mentioned**
- *Social security charges*: **649 is not mentioned**
## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.
opw-5724559
Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474This update resolves a bug where the 'Today' filter in Frontdesk was incorrectly displaying visitors due to timezone differences. The fix converts all date/time comparisons to UTC, ensuring accurate filtering regardless of the user's location. This ensures all visitor records are correctly displayed.
Original PR description
Steps to reproduce -------------------------- 1. Install Frontdesk 2. Go to Frontdesk → Visitors 3. Create a visitor with a check-in time before today 05:30 (local timezone: Asia/Kolkata) 4. Check visitors Issue: -------- The created record is not displayed because "today" filter used the user's local date to build a datetime range but failed to convert those boundaries to UTC before querying the database, leading to incorrect filtering in non-UTC time zones. Solution ------------- Convert those datetimes to UTC using `.to_utc()` in the filter domain opw-5385995 Forward-Port-Of: odoo/enterprise#102865
This update corrects a bug where the serial number on delivery orders was incorrectly updated when adding new items in the 'ready' state. The fix ensures that the original serial number is maintained, preventing discrepancies in inventory tracking and improving order accuracy. This resolves an issue impacting product traceability.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. opw-5385993 Forward-Port-Of: odoo/enterprise#105420 Forward-Port-Of: odoo/enterprise#105338
This update corrects an issue where customer claims weren't being processed correctly due to a limitation in how VAT numbers were matched. Specifically, when a child invoice contact shares a VAT number with a parent partner, the system would incorrectly select a partner, preventing the correct account move from being found. This ensures claims are processed accurately.
Original PR description
When we process new customer claims, we need to search for the corresponding account moves in order to update their `l10n_cl_dte_acceptation_status`. Currently, we only expect 1 partner per VAT number when searching for a partner to match with the account move. However, this is not always true. For instance, a child invoice contact will share the same VAT number than the parent partner. This can lead to the selection of the wrong partner in the search domain and consequently, the account move not being found. Related ticket: opw-5257481 Forward-Port-Of: odoo/enterprise#105653 Forward-Port-Of: odoo/enterprise#103366
This update resolves a performance issue in the project timesheet report that was causing it to fail with large datasets. The team has optimized the query by using a more efficient join technique, resulting in a faster report load time (approximately 2 seconds).
Original PR description
After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left join which seems that it slowed down the query a lot. So the report…
After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left join which seems that it slowed down the query a lot. So the report doesn't load at all if we have a lot of records. In this PR we are introducing CROSS LATERAL JOIN as we want to generate only the the relevant dates not all dates between the min starting date and max ending date of all slots. Query plan after modification https://explain.dalibo.com/plan/eh5293ba2354f43c The testing cardinality of the tables: `planning.slot` 7178 rows `hr.employee` 332 rows `resource.resource` 332 rows `resource_calendar_leaves` 4061 rows `account_analytic_line` 267376 rows `generate_series()` will produce 206417 rows | Before | After | |-----------------------------------------|-------| | Query keep being active with no results | ~2s | opw-5089052 Forward-Port-Of: odoo/enterprise#105696 Forward-Port-Of: odoo/enterprise#102283