Daily updates from Odoo
Tuesday, March 24, 2026
11 changes · saas-18.4
Resolved issues and error corrections
This update prevents the entire report export cron job from stopping if an error occurs during a single report generation. Previously, a single failure would halt the entire process. Now, the cron will continue to attempt to export other reports, improving reliability and ensuring timely report delivery.
Original PR description
If an error is raised during the export of reports cron execution, the whole cron stops due to the fact that the error is never catched This commit will ensure that even if there is an error with one of the report export, the cron won't top and will try to send to other documents task-5469038 Forward-Port-Of: odoo/enterprise#111602 Forward-Port-Of: odoo/enterprise#105191
This update resolves two issues preventing new employee creation in the Belgian payroll module. The first prevented saving with a start date, and the second caused errors when adding wages. The fix ensures proper record creation and avoids duplicate activity triggers, improving employee onboarding.
Original PR description
First bug: Steps: - Switch to belgian company - Create new employee - Set contract start date - Click save manually -> boom Cause: in _trigger_l10n_be_next_activities, we create a new mail activity for the created employee which is already created in the default create function leading to duplicate follower records. Fix: in the super.create, pass the context variable mail_create_nosubscribe=True to disable adding the current user as a follower again to the same record Second bug: Steps: - Switch to belgian company - Create new employee - Set contract date - Add a wage then click anywhere -> boom Cause: _trigger_l10n_be_next_activities is called before the record is saved, hence trying to link to a null object Fix: check if the record is created before working on the activities
This update resolves an issue where the XML generated for Swiss payments (iso20022_ch) was using an outdated payment schema. The fix ensures the XML adheres to current banking standards, specifically the pain.001.001.09 format required by Swiss financial institutions. This improves payment processing accuracy and compliance.
Original PR description
**PROBLEM** According to documentation (https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2025-en.pdf) PstlAdr must be structured. This isn't the case when generating a xml for the payment method iso20022_ch. **STEP TO REPRODUCE** 1. install l10n_ch and account_iso20022. 2. Create a swiss contact with a full address. And activate payment on the bank account of this contact. 3. Select the Company CH, and set a bank account in the bank journal configuration. 4. Create a vendor payment to the swiss contact. 5. Create a batch payment with it, and validate to get the xml. 6. Open the xml, and notice the PstlAdr isn't structured. Ticket [link](https://www.odoo.com/odoo/project.task/5880247) opw-5880247 Forward-Port-Of: odoo/enterprise#111158 Forward-Port-Of: odoo/enterprise#107025
This update fixes an issue where currency rates for Bulgaria were incorrectly calculated after the country switched to the Euro. The system was using reversed rates from the XML data, leading to inaccurate unit conversions. This change ensures correct currency calculations for Bulgarian transactions.
Original PR description
Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database. Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both. task-6050519 Forward-Port-Of: odoo/enterprise#111275
This update resolves a problem where invoices with discounts and decimal values (over 2 decimals) were failing to send to ARCA. The fix uses a simplified unit price to calculate discounts, ensuring accurate decimal calculations for EDI invoice generation. This prevents errors and ensures proper invoice transmission.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value. Forward-Port-Of: odoo/enterprise#110706
This update resolves an issue where users were directed to the wrong document form view when configuring Peppol document synchronization settings. The change adds a dedicated Kanban view within the settings, ensuring users can easily manage their Peppol documents. This improves the user experience and streamlines the document synchronization process.
Original PR description
Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view. Task-6040802 Forward-Port-Of: odoo/enterprise#111712 Forward-Port-Of: odoo/enterprise#111341
This update fixes a misunderstanding regarding the W4 form filing date in the US payroll system. The change clarifies that the field represents the date the W4 is submitted to the employer, not the date it's initially completed by the employee. This ensures accurate payroll processing and compliance.
Original PR description
This field is about when the W4 is filed with the employer, not when it's filled in. opw-5096780 Forward-Port-Of: odoo/enterprise#111213
This update corrects a small, non-critical message displayed within the documents generated for employee payroll. The fix ensures consistent and accurate reporting for HR and payroll processes. This change does not impact functionality or user experience.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update fixes an issue in our tax reporting module where calculations for previous tax periods were inaccurate, particularly with trimester-based tax periods. The fix ensures correct period boundaries are used, preventing incorrect report values and improving the reliability of tax reporting data.
Original PR description
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly…
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example) - Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester - Open the report for the second month of the trimester => The line has value 42, while it should have 1. This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong. Forward-Port-Of: odoo/enterprise#111483 Forward-Port-Of: odoo/enterprise#110504
This update ensures that all attendees of an appointment – including internal users and organizers – receive booking notifications, regardless of whether the booking syncs with Google or Outlook. Previously, notifications were limited, but this change ensures consistent communication for all involved parties.
Original PR description
In [1] we prevented cancelation emails from being sent when the booking was synced via google or outlook calendar. However this means even followers who would not be notified by the mail provider (not assisting to the meeting) would not be notified. As well as the organizer who is doing to booking/cancelling from the perspective of the mail provider, as the meeting is created from their account. Instead we should keep sending the "appointment booked" template in all cases as it is only followed by internal users to whom it is always relevant. As for cancelation templates, it should stil be sent to internal users. Partners of the meeting however need not be notified and may be unsubscribed if syncing is enabled, as cancellation typically only happens once. task-5152917 [1]: https://github.com/odoo/enterprise/pull/60913 Forward-Port-Of: odoo/enterprise#111174 Forward-Port-Of: odoo/enterprise#96638
This update resolves an issue where users could inadvertently create 'Requested Documents' instead of folders when syncing Peppol documents through the accounting settings. To avoid a confusing folder location in My Drive, the ability to create or edit documents within the settings has been disabled, ensuring the correct document type is created.
Original PR description
Before this commit a user could create or edit a folder in the accounting settings to sync peppol documents to. The issue was that this created a 'Requested Document' instead of a folder. This commit removes the possibility to create or edit documents through the settings. An alternative would have been to add the contex to create a Folder instead of a Requested Document, however another problem then arises: the folder is created in My Drive, which does not make any functional sense. Therefore we are disabling creation and edit. This is the same logic applied in 8ada2a4f. Task-6063736 Forward-Port-Of: odoo/enterprise#111761