Friday, September 26, 2025
6 changes · 17.0
Resolved issues and error corrections
The Spanish Mod 349 tax report now correctly shows the underlying invoice lines when users audit the summary for intra-community operations. This helps accounting teams verify reported EU transaction amounts without missing supporting details.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813
Website product pages now show the correct price when a customer's tax rules change how taxes are applied. This prevents small rounding errors, such as a $10 item appearing as $10.01, improving price accuracy for shoppers.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Configure website to display prices tax-included; 2. have two 15% taxes, one price-included, one price-excluded; 3. create a $10 product that uses the price-included tax; 4. create a fiscal position that maps the included tax to excluded one; 5. assign the fiscal position to the public partner; 6. open the product's shop page as public user. Issue ----- The price gets displayed as $10.01. Cause ----- When applying the taxes to the price, small errors are introduced by rounding the base price before doing the tax calculations. Solution -------- To circumvent issues like these, commits 143ec3739196f and 6045061f818a0 added the `round` & `round_base` context values respectively. By settings these to `False`, we can prevent intermediate rounding that may introduce errors like these. opw-4945752
A timesheet attendance report query now correctly identifies the employee field it needs to use. This prevents database comparison errors that could block affected Odoo upgrade requests.
Original PR description
In the affected query, the variable "employee_id" is undefined in the scope where it is used. This leads postgres to interpret it as a variable with default type VARCHAR and to the impossibility to compare it against an integer. We just qualify the variable name so it now works as expected. Failing upgrade requests: [3103245](https://upgrade.odoo.com/odoo/request/3103245) [3121291](https://upgrade.odoo.com/odoo/request/3121291) Fixes https://github.com/odoo/odoo/pull/192434/commits/c97ecfa7fc091f763329af589b69db2292931163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225401
Sales orders now ignore archived projects when deciding whether to show the project shortcut button. This prevents users from seeing a project indicator when only inactive projects are linked, reducing confusion in order follow-up.
Original PR description
Issue: ----- When a project is archived, the project stat button still appears on the sale order. Fix: --------- This commit excludes archived projects from the project count. As a result, the project stat button will be hidden when only archived projects are linked. Steps to reproduce: -------- - Install sale_project module - Create a product with service type, linked to a project and task - Create a sale order with the above product and confirm it - Archive the linked project - Return to the sale order and check the project stat button task-4780817
Payment terminal messages printed at the bottom of POS receipts now use the correct font sizing. This makes the text easier to read on printed receipts and keeps it consistent with the on-screen preview.
Original PR description
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a…
When you pay with a payment terminal, it can produce some text which gets appended to the bottom of the POS receipt. Before this commit, this text appears too small to be legible when printed on a receipt printer. This is because the font size styling was in the wrong place, and in the UI it fell back to bootstrap's CSS which makes it fairly large, but html2canvas renders it very small. After this commit, the problem is fixed by moving the font size styling to the correct place to apply to the text. In the UI, the text is actually slightly smaller than before, but when printed it is bigger and consistent with the UI. Before/After (UI): <img width="346" height="325" alt="image" src="https://github.com/user-attachments/assets/0a9dceb3-e224-473f-b02f-ff94b81b0a8d" /> <img width="349" height="319" alt="image" src="https://github.com/user-attachments/assets/b096172a-4a98-4249-a5d4-00c8a46ab4d0" /> Before/After (Receipt): <img width="513" height="503" alt="image" src="https://github.com/user-attachments/assets/e1d6ba27-1ff6-4853-b617-1c010857f1eb" /> <img width="516" height="528" alt="image" src="https://github.com/user-attachments/assets/82cb2431-707f-40c7-a9a5-f439d3934e16" /> task-5116506 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Project task lists now keep the allocated hours field visible and editable even when its value is zero. This makes it easier for users to update multiple task allocations without being blocked by hidden cells.
Original PR description
Before this commit, when the user would like to edit the allocated hours field of multiple tasks inside the list view, he cannot when the allocated hours is equal to 0. The reason is because the cell is hidden once the value is equal to 0. This commit makes that field is always editable in the list view of tasks even if the value is 0. task-5093288