Odoo Changelog — 2026-05-09

Saturday, May 9, 2026

4 changes · 19.0

Bug Fixes(4)

Resolved issues and error corrections

[FIX] planning: unlink working hours computation from progress bar

Enterprise19.0planningMedium

This update resolves an issue where the Planning Gantt view wasn't accurately calculating working hours when the view wasn't grouped by resources. The fix ensures the total row correctly reflects employee working schedules, regardless of grouping settings. This improves the accuracy of project time tracking.

Original PR description

Issue: ---------------------------------------- In the Planning Gantt view when we don't group by resources, the total row is not considering the working hours. Steps to reproduce:…

Issue:
----------------------------------------
In the Planning Gantt view when we don't group by resources, the total row is not considering the working hours.

Steps to reproduce:
----------------------------------------
- Open Planning
- Remove the default group by resources
- Have at least a planning slot for a non-flexible employee
- The total row doesn't take the working schedule into account

Cause:
----------------------------------------
Since [an improvement,](https://github.com/odoo/enterprise/commit/cc35e1a4729453e4f788034a94402ab048eadfcb) the working hours data in given to the `PlanningGanttRenderer` through the progress bars data. This is an issue because the progress bars are only there if we group by resources. ([src](https://github.com/odoo/enterprise/blob/423ab064847dd41d36778a812390e3bec53ba4dc/planning/models/planning_slot.py#L2669-L2678))

Solution:
----------------------------------------
In this commit we partially revert the commit adding the working intervals in the progress bars. Instead of doing it in `_gantt_progress_bar_resource_id()` we create a new method `_get_gantt_planning_data()` which is called directly in `get_gantt_data()` and returns useful information even when there are no progress bars.

opw-5507063

#planning#gantt#time tracking

[FIX] l10n_in_reports: fix import service RC in GSTR-3B

PR #116708

Enterprise19.0l10n_in_reportsMedium

This update fixes a reporting issue related to Goods and Services Tax (GST) filings (GSTR-3B) in Russia. Previously, service reverse charge tax entries were missing from a key report table. Now, these entries are correctly included, ensuring accurate tax reporting and compliance.

Original PR description

Previously, journal items for import of services with reverse charge tax were shown only in table 4(A)(2) and not in table 3.1(d). However, since table 3.1(d) is meant for supplies liable to reverse charge, those entries should also be reported there.

With this commit, import of service reverse charge entries are now correctly included in table 3.1(d) as well.

#gst#russia#tax#reporting

[FIX] l10n_in_reports: fix GSTR2B reverse charge line amount sign

PR #116740

Enterprise19.0l10n_inMedium

This update resolves an issue where tax reports (specifically for GSTR2B in Russia) were displaying incorrect amounts due to reversed sign handling. Now, bills are shown with positive values, and credit notes with negative values, ensuring accurate tax reporting and financial reconciliation.

Original PR description

In reverse charge taxes, tax tags are added on negative repartition lines, causing the amounts to appear with the opposite sign in reports. Due to this, credit notes were shown as positive amounts and bills as negative amounts.

This commit fixes the sign handling so that:
- bills are shown with positive amounts
- credit notes are shown with negative amounts

#tax#reporting#GSTR2B#Russia

[FIX] account_reports: fix AccessError on shared accounts

PR #115454

Enterprise19.0accountMedium

This update resolves a bug that prevented users from posting journal entries using accounts shared between companies when an open audit period was active. The fix ensures proper access controls are enforced, allowing users in Company B to correctly record transactions linked to shared accounts during audits. This improves reporting accuracy and prevents disruptions to financial processes.

Original PR description

Posting a journal entry using an account shared between multiple
companies during an open audit period raises an AccessError.

Steps to reproduce:
- Configure an account to be shared between Company A and Company B.
  - Add Company A and Company B in 'Companies'
  - In the mapping tab, add a code for each company
- In Company A, create a tax audit for a specific fiscal period.
- Switch to Company B and keep just Company B selected.
- Create and post a journal entry using the shared account within the
  same date period.

Issue: An AccessError is raised when posting the move. The system
attempts to check the status of the audit records linked to the
shared account, to which the user in Company B does not have read access.

opw-5993450

#accounting#reporting#audit#shared accounts

Issue: ---------------------------------------- In the Planning Gantt view when we don't group by resources, the total row is not considering the working hours. Steps to reproduce: ---------------------------------------- - Open Planning - Remove the default group by resources - Have at least a planning slot for a non-flexible employee - The total row doesn't take the working schedule into account Cause: ---------------------------------------- Since [an improvement,](https://github.com/odoo/enterprise/commit/cc35e1a4729453e4f788034a94402ab048eadfcb) the working hours data in given to the `PlanningGanttRenderer` through the progress bars data. This is an issue because the progress bars are only there if we group by resources. ([src](https://github.com/odoo/enterprise/blob/423ab064847dd41d36778a812390e3bec53ba4dc/planning/models/planning_slot.py#L2669-L2678)) Solution: ---------------------------------------- In this commit we partially revert the commit adding the working intervals in the progress bars. Instead of doing it in `_gantt_progress_bar_resource_id()` we create a new method `_get_gantt_planning_data()` which is called directly in `get_gantt_data()` and returns useful information even when there are no progress bars. opw-5507063

Previously, journal items for import of services with reverse charge tax were shown only in table 4(A)(2) and not in table 3.1(d). However, since table 3.1(d) is meant for supplies liable to reverse charge, those entries should also be reported there. With this commit, import of service reverse charge entries are now correctly included in table 3.1(d) as well.

In reverse charge taxes, tax tags are added on negative repartition lines, causing the amounts to appear with the opposite sign in reports. Due to this, credit notes were shown as positive amounts and bills as negative amounts. This commit fixes the sign handling so that: - bills are shown with positive amounts - credit notes are shown with negative amounts

Posting a journal entry using an account shared between multiple companies during an open audit period raises an AccessError. Steps to reproduce: - Configure an account to be shared between Company A and Company B. - Add Company A and Company B in 'Companies' - In the mapping tab, add a code for each company - In Company A, create a tax audit for a specific fiscal period. - Switch to Company B and keep just Company B selected. - Create and post a journal entry using the shared account within the same date period. Issue: An AccessError is raised when posting the move. The system attempts to check the status of the audit records linked to the shared account, to which the user in Company B does not have read access. opw-5993450