Tuesday, May 12, 2026
10 changes · 17.0
New functionality added to Odoo
This update allows users to correctly account for VAT credits carried forward from previous months when preparing French tax returns. Specifically, it adds the ability to adjust for line 25, which represents a VAT credit balance. This ensures accurate reporting and compliance with French tax regulations.
Original PR description
This commit will add the possibility to do an adjustment on the line 25. Useful when you start using Odoo but have a VAT credit carried forward from the previous month (which should appear in box 25 of your return). task-6072474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update fixes a bug that prevented the General Ledger CSV export from including data when accounts had a currency set. The issue stemmed from an error in how the code handled currency IDs, leading to a silent failure. Now, all account data is correctly exported, regardless of currency settings.
Original PR description
Current behavior: When any account (`account.account`) has `currency_id` set, the General Ledger CSV export silently outputs only the header row with no data. No error is shown to the user. Expected…
Current behavior: When any account (`account.account`) has `currency_id` set, the General Ledger CSV export silently outputs only the header row with no data. No error is shown to the user. Expected behavior: CSV export should include all data rows regardless of whether accounts have `currency_id` set. Required Modules - `account_accountant` (Accounting App) Steps to reproduce: 1. Start with a clean database with demo data loaded and only the Accounting app installed 2. Confirm only one active currency (e.g., USD) exists — no accounts have the "Currency" field (`currency_id`) set at this point 3. Go to Accounting → Reporting → General Ledger and export as CSV — it works fine, all data rows show up 4. Go to Settings → Currencies and activate a second currency (e.g., Hong Kong Dollar). Save 5. Go to Accounting → Configuration → Chart of Accounts (refresh the page). The "Account Currency" column now appears 6. Set a currency on any account (any currency works, even USD). Save 7. Go back to General Ledger and export as CSV again 8. Open the exported CSV — only the header row is there. All data rows are gone. No error is shown to the user Recorded video on reproducing this bug: https://www.loom.com/share/644f01a9f0df4230a4be4ae1f5ba79ba Cause of the issue: In `csv_format_account_line()` (line 885), the code does `col['currency'].id`, assuming `col['currency']` is a recordset. However, it can already be an integer, causing `AttributeError: 'int' object has no attribute 'id'`. This error is caught upstream, resulting in a silently empty CSV. Fix: Handle the case where `col['currency']` is already an `int` instead of a recordset before calling `.id`. opw-5974207
This update optimizes PDF report generation by compressing the final PDF files, reducing their size and improving performance. The change addresses a previous memory issue and leverages newer PDF library versions for better output, resulting in faster report creation and smaller file sizes.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786
This update resolves an issue where the SDWorx export process incorrectly flagged freelancer employees as missing SDWorx codes. The change removes a previous check and adds a filter to exclude freelancers, ensuring accurate export functionality for this employee type. This prevents users from encountering error messages during the SDWorx export process.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- In https://github.com/odoo/enterprise/pull/106065/changes/c19009c776349c3f5d8aebf99aff8efe987b54db The Check for Freelance Employee type was removed, which was earlier added in the fix https://github.com/odoo/enterprise/pull/102211/changes/96724c3cc55725e87e618443b96069921b8f3bda Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342
This update fixes a reporting issue in the Profit & Loss report for Peruvian companies. Previously, depreciation entries were incorrectly categorized as 'Other Income.' The change ensures that depreciation entries (expenses) are now correctly classified within 'Other Operating Expenses,' improving the accuracy of financial reporting.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_pe_reports - Switch to a Peruvian company (e.g. PE Company) - Create a MISC journal entry with a line using a depreciation account (e.g. 6841000) and a debit value (e.g. 1000) - Post the entry - Check "Profit and Loss" report" **Issue:** The "Other operation income" section has an amount of 1000, even though a depreciation account (i.e. expense) was used. The amount should be in "Other operating expenses" section. **Cause:** A unique formula including accounts starting with 61, 66, 68, 71, 73, 74, 75, 76, 78, 79 and 99900 is used for "Other operation income" and "Other operating expenses" and depending on the sign of the sum, the result is reported in one of the section. **Solution:** Only report entries on "Income" accounts in "Other operation income" section and those on "Expense" accounts in "Other operating expenses". opw-6073666
This pull request updates the o_spreadsheet library to its latest version (17.0.96). These updates include bug fixes and improvements to the library's performance and stability, ensuring continued functionality for spreadsheet-related features within Odoo.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9732401ebc [REL] 17.0.96 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9732401ebc [REL] 17.0.96 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/0eb25ad8eb [FIX] package: make it stop [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/6b1c6ac373 [REL] 17.0.95 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/521f558e9a [FIX] package: someday, it will work [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c64874af81 [REL] 17.0.94 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/8a86790a08 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/42a264ef1e [FIX] package: limit husky install when running `npm install` [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/bf42aca2c8 [REL] 17.0.93 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/8690bb9062 [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e47ce7607b [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ad0edfd078 [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update optimizes PDF report generation by compressing files after merging, reducing file sizes and memory usage. The change addresses a previous memory leak and leverages newer PDF library versions for better performance, particularly with large reports. This results in faster report generation and reduced storage needs.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786
This update resolves a technical issue that was causing database errors when calculating membership states. The change uses a more reliable method within Odoo's database system to handle these calculations, ensuring stability and preventing potential disruptions to membership features. This fix improves the overall reliability of the membership module.
Original PR description
SQL `IN %s` clause failed due to an empty tuple, causing a syntax error. By switching to `read_group`, the ORM handles empty domains gracefully. This also improves maintainability by using standard API methods instead of direct cursor execution. opw-6196166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where recomputing fields within Odoo could cause errors, particularly when accessing records. The fix ensures that all fields are correctly recalculated, even those triggered by 'many2one' relationships, by performing the computation in a privileged mode. This enhances the stability and reliability of data updates.
Original PR description
The existing implementation was incomplete when some recomputation creates a new record that has fields to recompute. The latter fields were not taken into account when recomputing "all fields". We also adapt the flushing loop in the same way. This fix revealed a related issue. Properties fields have a compute method, which is a technical artifact to update their default values when the many2one to their definition record is modified. For some weird reason, this method re-triggers its computation on the record. And in some of those cases (when the record becomes inaccessible) the second recomputation crashes (`AccessError`). The fix consists in computing the field in sudo mode. Backport of #219395.
This update resolves an issue where a command used to automatically update IoT drivers was causing problems with recent updates. The change now skips the update process if the command fails, preventing disruptions to IoT Box systems and ensuring compatibility with the latest Trixie version.
Original PR description
If `git ls-remote origin <db_branch>` randomly fails, we assume `db_branch` is `master`. It was useful for devs in the past, but now lead to update to Trixie on IoT Boxes 25_07 and previous, which is unwanted in such circumstances. We now skip upgrade if `db_branch` is `master`.