Friday, December 19, 2025
8 changes · 19.0
Enhancements to existing features
This update enhances the tracking of errors received from Intervat during tax return processing. Instead of just displaying notifications, error messages are now logged within the tax return chatter, providing better visibility and troubleshooting capabilities. This improves our ability to quickly identify and resolve issues related to Intervat tax returns.
Original PR description
When we receive an error from Intervat, we just display a notification. But it's not optimal to track the errors of a tax return. With this commit, we will also log the error messages in the tax return chatter. task-5425065
Resolved issues and error corrections
This update resolves a bug that occurred when multiple CAF documents were active within a document type, causing errors when opening invoices. The fix ensures the system selects the CAF with the lowest starting number, allowing for proper document sequencing and preventing database errors. This improves invoice processing reliability.
Original PR description
In #92208 the CAF system was improved to find the next starting value in the right sequence if there are multiple in the system. If no CAFs are found, it will reset to the document types starting…
In #92208 the CAF system was improved to find the next starting value in the right sequence if there are multiple in the system. If no CAFs are found, it will reset to the document types starting number. This worked except in the case where there are multiple CAFs that are currently marked active in a document type. As it tries to access `caf.start_nb` it hits an ensure_one() which throws a traceback whenever you open most account.moves on the DB. Steps to reproduce: - Modify the CAF for Doc Type 33 (Electronic Invoices) to have a smaller range than 1 - 999,999 (1 - 5) - Create Two new CAF files also for Doc Type 33 that start after this value (6 - 10 and 11 - 15 for example). - Mark the original to be spent via cancelling it and try to open an invoice. It will find both of the new CAFs and try to get the start_nb of the recordset. In discussion with the PO, when we have multiple CAFs, we should pick by the lowest start number as it will allow for any gaps that might exist be filled. opw-5414350 Forward-Port-Of: odoo/enterprise#102385
This update fixes an issue where users weren't seeing only relevant documents in the systray. The change ensures that activity filters (Late, Today, Future) are correctly applied when navigating from the systray, ensuring users only view documents with pending activities. This improves the user experience and data accuracy.
Original PR description
Clicking on activity counters (Late, Today, Future) in the systray relies on specific "search_default" keys to filter the target model's view. Previously, these specific activity filters were missing from the document search view or had the wrong name, causing the systray to fail to filter the documents correctly when redirected. This resulted in the user seeing all documents instead of only those with the relevant pending activities. Note: the 'My Activities' filter is set to invisible, to align with standard odoo behaviour. Task-5427921
This update resolves a problem where WhatsApp templates were incorrectly linked to the default company, preventing users from sending sign requests from other companies. The change filters templates based on user access rights, ensuring the correct templates are available for each company and eliminating access errors.
Original PR description
Currently, WhatsApp templates are linked to the default company, causing access errors when sending sign requests from other companies. This patch filters templates based on the user's access rights to avoid AccessErrors and clarify which templates are available per company. task-5424781
This update fixes an issue where the price displayed on Italian POS receipts for multiple product purchases was incorrect. The fix ensures that the unit price, rather than the total line price, is used when generating the receipt, resulting in accurate pricing for Italian customers. This improves the reliability of financial reporting and customer billing.
Original PR description
Currently, when buying multiple quantities of the same product, the unit price value sent to the italian printer is incorrect. Steps to reproduce: ------------------- * Set up italian printer for one shop * Open shop * Add a product to the order with a qty 3 and a price unit of 1 * Pay the order * Print italian receipt > The price total for the 3 product says 9 instead of 3 Why the fix: ------------ When computing the order lines details we were using `total_included` for the unit price which takes into account the quantity. Per definiton, it's not the price for 1 unit. opw-5404877
This update simplifies the handling of errors when using the AI's response generation feature in live chat. Previously, a technical traceback was displayed alongside a friendly AI-generated message. Now, errors are handled more gracefully, providing a better user experience and aiding support teams by removing technical details.
Original PR description
Before this commit, whenever we called `/ai/generate_response` from the fron-end we were catching any potential exceptions and calling the `ai/post_error_message`. The `post_error_message` function…
Before this commit, whenever we called `/ai/generate_response` from the fron-end we were catching any potential exceptions and calling the `ai/post_error_message`. The `post_error_message` function called from that controller endpoint would take the exception message, and ask the AI to explain the error to the user without the use of technical terms. The problem with this approach is two-fold. Firstly, in the `post_error_message` method, we use the `generate_response` method in order for the AI to beauty-fy the error message. But, the `post_error_message` method is called when catching exceptions of the `generate_response` method. Thus, the exception is caught, a nice message is posted in the chat, but then a traceback is shown regardless. Secondly, beautifying the error messages makes it more difficult for end users to understand what could be going wrong and making it also more difficult for our support to help them out. In this commit, we removed the `post_error_message` flow. We move the try-except to the `_generate_response_for_channel` method and if the user is an internal user we let the exception bubble up. If not (for website users on livechat), a generic message will be posted on the chat. task-5177169
This update resolves an issue where VAT reports for Belgian companies were incorrectly setting the 'Client Nihil' field to 'YES' outside of the year-end. The change reintroduces a checkbox option for this setting, aligning with Belgian regulations regarding when this option is permitted. This ensures accurate VAT reporting and avoids potential compliance issues.
Original PR description
## Issue: When exporting the XML for a VAT return, the client nihil field was incorrectly set to YES According to Belgian regulations, this is only allowed on the last report of the calendar year…
## Issue: When exporting the XML for a VAT return, the client nihil field was incorrectly set to YES According to Belgian regulations, this is only allowed on the last report of the calendar year https://finances.belgium.be/sites/default/files/downloads/165-625-directives-2019.pdf ## Cause: Prior to 18.3, nihil was a checkbox option on export Since 18.3, it is automatically selected based solely on a price formula, without checking the report’s date This PR brings back the Client Nihil checkbox in 19.0 But didn't change the default value Causing the issue to still be present https://github.com/odoo/enterprise/pull/99496 ## Steps to reproduce: - Select the Belgian company - Open the Tax Return and select the VAT Return - Click Returns and enter an opening date in January - Click Review for the first available report - Ignore errors and return to previous page - Click on Submit -> Download XML - Before the fix, ClientListingNihil is set to YES ## Potential remaining issue: The legal document specify that it should also be checked in case of "cessation d’activité" So it may be interesting to consider adding the option back opw-5184056 Forward-Port-Of: odoo/enterprise#98982
This update resolves an issue where subfolders within document categories weren't appearing in the search panel when accessed from other applications. Previously, users would see the full folder structure, but the search functionality wouldn't reflect it. This change ensures a consistent and accurate search experience for all document types.
Original PR description
...when coming from another app. Reproduce: 1. Go to a fleet vehicle record and open its 'Documents' stat button. 2. You end up in the Fleet folder, where you see subfolders as kanban cards, but they are not in the search panel. Task-5272030