Odoo Changelog — 2026-05-26

Tuesday, May 26, 2026

9 changes · 19.0

Bug Fixes(9)

Resolved issues and error corrections

[FIX] l10n_in_reports: fix inward supplies domain in GSTR-3B table 5

Enterprise19.0l10n_inMedium

This update corrects a reporting issue in the GSTR-3B form by ensuring it only displays inward supplies, as required by tax regulations. Previously, both inward and outward supplies were incorrectly shown, leading to potential reporting inaccuracies. This change improves the accuracy of tax reporting.

Original PR description

Previously, both inward and outward composition supplies were appearing in table 5 of GSTR-3B, even though table 5 is meant only for inward supplies.

This commit adds a `move_type` condition to ensure only inward supplies are considered in the report line.

task-6239870

#GSTR-3B#tax#reporting#inward supplies

[FIX] sign: preserve bookmarks and links

PR #117994

Enterprise19.0signMedium

This update resolves an issue where signed PDF documents lost their original bookmarks and links. The fix ensures that signed documents remain fully navigable and preserve the original document structure and integrity, improving usability and data consistency.

Original PR description

Version
- 18.0

Steps to reproduce:
1. Upload a PDF document containing bookmarks and internal/external links.
2. Sign the document and download the signed PDF.
3. Open the downloaded file and check the bookmarks and links.

Issue:
When a signed document was downloaded, the original PDF bookmarks And the links were not working.
This broke structured navigation and affected document integrity.

Fix:
The PDF signing process has been updated to preserve the original bookmarks and ensure internal and external links remain functional after signing.

Impact:
- Signed documents remain navigable and consistent with the original PDF.
- Preserves document structure and integrity.

Task- 4915124

Forward-Port-Of: odoo/enterprise#117881
Forward-Port-Of: odoo/enterprise#108684

#pdf#bookmarks#links#signatures

[FIX] documents: prevent hidden chatter on kanban mobile view

PR #118134

Enterprise19.0documentsMedium

This update resolves an issue where the 'Info & Tags' chatter wasn't visible in the mobile Documents app's Kanban view. The fix adjusts CSS styling to ensure the chatter element is always accessible and scrollable, improving usability on mobile devices. This ensures users can easily access important document information.

Original PR description

**Steps to reproduce:**
- Go to Documents app in mobile
- Go to the kanban view
- Add some files and select one
- Click on `Info & Tags` button in the control panel
- Reload the page
- Chatter is not displayed but the button is still enabled
- Switching to the list view properly shows it

**Issue:**
We have two conflicting css styling on mobile:
- `overflow-hidden` was added for mobile to avoid multiple scroll bars
- `min-height: 100%` which is due to the default `o_kanban_ungrouped` in the controller css

This means that the element is present at the bottom of the page, but we can't get to it manually.
When re-enabling the action we are properly moved to the existing chatter (but we can't go back to the top).

Also the documents panel should have a single scrollbar to display all the records, but we still need a way to scroll the messages of the chatter.

**Fix:**
Set `min-height: 0;` for documents kanban to ensure the chatter is still visible and accessible on mobile by default. This makes the chatter take the full available height when displayed.

original overflow fix: https://github.com/odoo/enterprise/commit/945b9e2b1c6752bd905695aa40b0babcf38c50cd

opw-6061993

Forward-Port-Of: odoo/enterprise#113168

[FIX] l10n_hk_hr_payroll_empf: prevent error in contribution report

PR #116607

Enterprise19.0l10n_hk_hr_payroll_empfMedium

This update fixes a technical error that prevented users from reviewing eMPF contribution reports in the Hong Kong module. Specifically, the system would throw an error when a contribution line was created without an associated employee. The fix ensures a user-friendly error message prompts the user to add the employee information, improving report accuracy and usability.

Original PR description

Currently, an error occurs when the user checks the report line errors.

**Steps to Reproduce:**

 - Install the `l10n_hk_hr_payroll_empf` module with demo data.
 - Switch to the `Hong Kong` company.
 - Go to `Payroll` > `Reporting` > `Hong Kong` > `eMPF Contributions`.
 - Create a record by setting the `Scheme` and adding a `contribution line`.
 - Ensure that the employee and payslip fields are empty in the contribution line.
 - Click on `Validate`, then click on the `error icon` on the report line.

`ValueError: Expected singleton: hr.version()`

This error occurs when the user manually adds a line and checks the errors on it.. The system 
attempts to open the employee record from the version [1], but the version is not set [2] on the 
line because there is no employee. And it raise the error [3].

This commit ensures that when checking errors, if the version is not set on the line, a UserError 
is raised, prompting the user to set the employee on the line. It also corrects a typo in the status 
message.

[1]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L219

[2]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L142-L156

[3]: https://github.com/odoo/odoo/blob/98855c6b70df24500babe6027109aa9e17431ec1/addons/hr/models/hr_version.py#L609-L611

[FIX] hr_attendance_gantt: fix gantt view with public holidays

PR #117992

Enterprise19.0hr_attendanceMedium

This update resolves a bug where the Gantt view incorrectly displayed working hours for flexible employees during public holidays. The fix converts all time zone calculations to UTC, ensuring accurate representation of unavailable periods and preventing employees from being marked as available during holiday times. This improves the accuracy of employee scheduling.

Original PR description

[FIX] hr_attendance_gantt: fix gantt view with public holidays

Bug reproduction:
    1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026
    2 - Create a new public holiday on 01/01/2026 (from 00.00 to 23.59 or 23.55 (depends on version, it does not matter))
    3 - in attendance app the cell from 00.00 to 01.00 seems white for that day and for selected employee (this cell seems like not holiday and employee can work)

Bug cause:
    1 - After a long traceback, _gantt_unavailability in hr_attendance_gantt/HrAttendance, if an employee is flexible then unavailable_intervals is calculated with the Brussel time zone
    2 - All other unavailable intervals are converted to the UTC in the function of _gantt_unavailability except in the final lines of the function.
    3 - When the employee is flexible and since the conversion is not done in the final lines, it remains 1 hour more (UTC+1), it is from 1 am to 1 am of next day instead of 0 am to 23.59.

Bug solution:
    1 - I converted the timezone to UTC to solve the problem.

task - 6067070

Forward-Port-Of: odoo/enterprise#112493

[FIX] l10n_mx_edi: exclude cash rounding lines from CFDI concepts

PR #117395

Enterprise19.0l10n_mx_ediMedium

This update corrects a problem with Odoo's Mexican CFDI (electronic invoice) exports. Previously, cash rounding lines were incorrectly included, causing export errors. This fix ensures that only the pre-rounding amounts are reported, complying with SAT regulations and preventing export rejections.

Original PR description

When using the 'add_invoice_line' cash rounding strategy, Odoo adds a
journal line with display_type='rounding'. This line has no product and
therefore no ClaveProdServ, causing PAC to reject the XML with error
301.

Per SAT regulations, cash rounding is not a valid CFDI concept. The CFDI
must report the pre-rounding amounts (e.g. 99.80); the rounding
difference (e.g. 0.20) belongs only in the journal entry on the
accounting side.

opw-6024078

Forward-Port-Of: odoo/enterprise#112633

#CFDI#Mexico#Accounting#Export

[FIX] l10n_it_reports: handle periodic gaps and debit/credit columns

PR #117428

Enterprise19.0l10n_it_reportsMedium

This update fixes a bug that prevented accurate IT tax closing validation, particularly when dealing with quarterly VAT reporting in Italy. The changes ensure correct calculations across year boundaries and handle both balance and debit/credit columns in VAT reports, preventing errors and improving data reliability.

Original PR description

Description of the issue this commit addresses:

The IT tax closing validation compared month numbers only, which broke across year boundaries and could reject valid quarterly progressions. It also assumed a balance column existed in monthly VAT report lines, but this report uses debit/credit columns, which could trigger a traceback.

---

Desired behavior after this commit is merged:

This commit computes the period gap with year-aware month deltas and aligns the allowed gap with periodicity (monthly or quarterly). It also checks VP lines using balance when present, or debit/credit as fallback, preventing crashes and ensuring consistent tax closing validation.

---

opw-6131080

#tax#reporting#VAT#Italy

[FIX] stock_barcode: rework some scss rules to speed-up global rendering

PR #118362

Enterprise19.0stockMedium

This update optimizes the rendering speed of the Stock Barcode module, specifically when viewing large reports or tables like in Accounting. By simplifying the CSS rules, the system now recalculates styles more efficiently, leading to faster loading times and a smoother user experience.

Original PR description

Avoid using `:has` selector with using a class on body to replace the has behavior.

This change made a gain of in the `(re)calculate style` step when we hover a node on large table like a `report selector` on `Accounting`. The recalculation time during actions like window resize, heavy scrolling, or table sorting. Replacing it with using the specific class reduces those global checks and improves rendering performance.

#performance#optimization#stock_barcode

[FIX] l10n_pe_edi: fixes withholding base amount

PR #113689

Enterprise19.0l10n_pe_ediMedium

This update corrects a rounding issue that previously resulted in the withholding base amount exceeding the total invoice amount. The fix ensures the withholding amount aligns with the invoice total, preventing potential discrepancies in financial reporting. This improves invoice accuracy and data integrity.

Original PR description

**PROBLEM** In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case. **STEP TO REPRODUCE** 1. Install…

**PROBLEM**
In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case.

**STEP TO REPRODUCE**

1. Install l10n_pe_edi
2. Create an invoice with those 2 lines: qty: 300, unit_price: 0.481936, tax: VAT 18% + 3% IGV Withholding qty: 300, unit_price: 0.747376, tax: VAT 18% + 3% IGV Withholding
3. Confirm the invoice, and send the xml (if this fail, you may have to change the name of the invoice, using odoo inspector or other means).
4. Open the xml, and notice the base amount for the allowance on the document level is 435.18 which is bigger than the invoice payable amount.

**CAUSE**
We exclude the withholding taxes to compute the invoice taxInclusiveAmount. When computing this amount, we round the line base and the tax total of the VAT 18% tax leading to the result of 435.17. When creating the allowance node for the Withholding taxes, the base used for the withholding taxes is the sum of the line base, and the tax total of previous tax NOT rounded. There is no easy way to change the withholding tax computation, so we just limit the base to not be bigger than the invoice total when there is rounding issues.

opw-6010388

Previously, both inward and outward composition supplies were appearing in table 5 of GSTR-3B, even though table 5 is meant only for inward supplies. This commit adds a `move_type` condition to ensure only inward supplies are considered in the report line. task-6239870

Version - 18.0 Steps to reproduce: 1. Upload a PDF document containing bookmarks and internal/external links. 2. Sign the document and download the signed PDF. 3. Open the downloaded file and check the bookmarks and links. Issue: When a signed document was downloaded, the original PDF bookmarks And the links were not working. This broke structured navigation and affected document integrity. Fix: The PDF signing process has been updated to preserve the original bookmarks and ensure internal and external links remain functional after signing. Impact: - Signed documents remain navigable and consistent with the original PDF. - Preserves document structure and integrity. Task- 4915124 Forward-Port-Of: odoo/enterprise#117881 Forward-Port-Of: odoo/enterprise#108684

**Steps to reproduce:** - Go to Documents app in mobile - Go to the kanban view - Add some files and select one - Click on `Info & Tags` button in the control panel - Reload the page - Chatter is not displayed but the button is still enabled - Switching to the list view properly shows it **Issue:** We have two conflicting css styling on mobile: - `overflow-hidden` was added for mobile to avoid multiple scroll bars - `min-height: 100%` which is due to the default `o_kanban_ungrouped` in the controller css This means that the element is present at the bottom of the page, but we can't get to it manually. When re-enabling the action we are properly moved to the existing chatter (but we can't go back to the top). Also the documents panel should have a single scrollbar to display all the records, but we still need a way to scroll the messages of the chatter. **Fix:** Set `min-height: 0;` for documents kanban to ensure the chatter is still visible and accessible on mobile by default. This makes the chatter take the full available height when displayed. original overflow fix: https://github.com/odoo/enterprise/commit/945b9e2b1c6752bd905695aa40b0babcf38c50cd opw-6061993 Forward-Port-Of: odoo/enterprise#113168

Currently, an error occurs when the user checks the report line errors. **Steps to Reproduce:** - Install the `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Reporting` > `Hong Kong` > `eMPF Contributions`. - Create a record by setting the `Scheme` and adding a `contribution line`. - Ensure that the employee and payslip fields are empty in the contribution line. - Click on `Validate`, then click on the `error icon` on the report line. `ValueError: Expected singleton: hr.version()` This error occurs when the user manually adds a line and checks the errors on it.. The system attempts to open the employee record from the version [1], but the version is not set [2] on the line because there is no employee. And it raise the error [3]. This commit ensures that when checking errors, if the version is not set on the line, a UserError is raised, prompting the user to set the employee on the line. It also corrects a typo in the status message. [1]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L219 [2]- https://github.com/odoo/enterprise/blob/7889b2b0b3d13b32e6e36e616e20379d8c8f8812/l10n_hk_hr_payroll_empf/model/l10n_hk_empf_contribution_report_line.py#L142-L156 [3]: https://github.com/odoo/odoo/blob/98855c6b70df24500babe6027109aa9e17431ec1/addons/hr/models/hr_version.py#L609-L611

[FIX] hr_attendance_gantt: fix gantt view with public holidays Bug reproduction: 1 - Select flex schedule employee (or change its schedule to 40h flex one) and make its contract before 01/01/2026 2 - Create a new public holiday on 01/01/2026 (from 00.00 to 23.59 or 23.55 (depends on version, it does not matter)) 3 - in attendance app the cell from 00.00 to 01.00 seems white for that day and for selected employee (this cell seems like not holiday and employee can work) Bug cause: 1 - After a long traceback, _gantt_unavailability in hr_attendance_gantt/HrAttendance, if an employee is flexible then unavailable_intervals is calculated with the Brussel time zone 2 - All other unavailable intervals are converted to the UTC in the function of _gantt_unavailability except in the final lines of the function. 3 - When the employee is flexible and since the conversion is not done in the final lines, it remains 1 hour more (UTC+1), it is from 1 am to 1 am of next day instead of 0 am to 23.59. Bug solution: 1 - I converted the timezone to UTC to solve the problem. task - 6067070 Forward-Port-Of: odoo/enterprise#112493

When using the 'add_invoice_line' cash rounding strategy, Odoo adds a journal line with display_type='rounding'. This line has no product and therefore no ClaveProdServ, causing PAC to reject the XML with error 301. Per SAT regulations, cash rounding is not a valid CFDI concept. The CFDI must report the pre-rounding amounts (e.g. 99.80); the rounding difference (e.g. 0.20) belongs only in the journal entry on the accounting side. opw-6024078 Forward-Port-Of: odoo/enterprise#112633

Description of the issue this commit addresses: The IT tax closing validation compared month numbers only, which broke across year boundaries and could reject valid quarterly progressions. It also assumed a balance column existed in monthly VAT report lines, but this report uses debit/credit columns, which could trigger a traceback. --- Desired behavior after this commit is merged: This commit computes the period gap with year-aware month deltas and aligns the allowed gap with periodicity (monthly or quarterly). It also checks VP lines using balance when present, or debit/credit as fallback, preventing crashes and ensuring consistent tax closing validation. --- opw-6131080

Avoid using `:has` selector with using a class on body to replace the has behavior. This change made a gain of in the `(re)calculate style` step when we hover a node on large table like a `report selector` on `Accounting`. The recalculation time during actions like window resize, heavy scrolling, or table sorting. Replacing it with using the specific class reduces those global checks and improves rendering performance.

**PROBLEM** In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case. **STEP TO REPRODUCE** 1. Install l10n_pe_edi 2. Create an invoice with those 2 lines: qty: 300, unit_price: 0.481936, tax: VAT 18% + 3% IGV Withholding qty: 300, unit_price: 0.747376, tax: VAT 18% + 3% IGV Withholding 3. Confirm the invoice, and send the xml (if this fail, you may have to change the name of the invoice, using odoo inspector or other means). 4. Open the xml, and notice the base amount for the allowance on the document level is 435.18 which is bigger than the invoice payable amount. **CAUSE** We exclude the withholding taxes to compute the invoice taxInclusiveAmount. When computing this amount, we round the line base and the tax total of the VAT 18% tax leading to the result of 435.17. When creating the allowance node for the Withholding taxes, the base used for the withholding taxes is the sum of the line base, and the tax total of previous tax NOT rounded. There is no easy way to change the withholding tax computation, so we just limit the base to not be bigger than the invoice total when there is rounding issues. opw-6010388