Wednesday, April 29, 2026
9 changes · 18.0
Resolved issues and error corrections
This update resolves a bug preventing website appointment syncs from appearing in Outlook calendars. Previously, a timing issue with the synchronization cron prevented events created through website appointments from being properly synced. The change ensures all calendar events, including those from website appointments, are consistently synchronized with Outlook.
Original PR description
Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of…
Before this change, the "Outlook: synchronization" cron would not create calendar events on Outlook's side in _sync_odoo2microsoft due to a filter for calendar.events written to within 5 minutes of microsoft_last_sync_date, when _sync_data is not called when a calendar.event is created, such as through website.appointment. microsoft_last_sync_date was set to datetime.now() at the beginning of _sync_microsoft_calendar, which would skip a large period of time between the last sync and now, if the only syncs were triggered through cron, and not _sync_data (by opening the calendar app). To reproduce, Default "Outlook: synchronization" is ran every 12 hours. 1) Calendar event is synced through "Outlook: synchronization" cron at 00:00, setting microsoft_last_sync_date to 00:00 2) A website.appointment is created for a resource with Outlook calendar sync enabled any time between 00:01 - 11:54. 3) "Outlook: synchronization" runs again at 12:00, which sets microsoft_last_sync_date to 12:00, and filters out calendar.events based on their write_dates in _extend_microsoft_domain that need syncing outside of 11:55 to 12:00. This change removes setting of microsoft_last_sync_date at the beginning of _sync_microsoft_calendar, where we need to use the old value before setting it at the end of _sync_microsoft_calendar. opw-5212908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the process for Dutch companies to manage their digipoort certificates within the accounting settings. Previously, users had to navigate to a separate menu to create a certificate before setting it in the main accounting configuration. Now, users can directly create and edit digipoort certificates within the existing settings, improving the user experience.
Original PR description
Description of the issue this commit addresses: In the Accounting settings on a Dutch company, the setting for the selection of the digipoort certificate only lets you choose amongst existing certificates so if you haven't created one yet, you need to go to the dedicated certificates menu to create one and then come back to the digipoort certificate setting to set it. This is poor UX. --- Desired behavior after this commit is merged: This is improved by letting the user Create and Edit inside the digipoort certificate setting directly. --- task-6065566
This update corrects a situation where invoices rejected by the tax system (SdI) were incorrectly marked as 'sent,' preventing users from resubmitting them. The change automatically clears this 'sent' flag when an invoice is rejected, allowing invoices to be re-submitted after the issue is resolved. This improves the invoicing process and reduces manual intervention.
Original PR description
When an invoice is rejected by the SdI or by a PA partner, the move remained flagged as sent, preventing the user from resending it after fixing the underlying issue. Override write() on account.move to clear is_move_sent whenever l10n_it_edi_state transitions to 'rejected' or 'rejected_by_pa_partner', so the invoice can be re-submitted. task-4490454 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where Sale Order Line descriptions were incorrectly displaying vendor-specific information instead of the standard product name. The change ensures the correct product name is used in the description, regardless of whether the customer and vendor are the same. This improves data accuracy and consistency in sales orders.
Original PR description
Steps to reproduce: ------------------------- 1. Install Sales and Purchase modules. 2. Create a product; in the Purchase tab, add a vendor with a vendor "Product Name" and "Product Code". 3. Create…
Steps to reproduce: ------------------------- 1. Install Sales and Purchase modules. 2. Create a product; in the Purchase tab, add a vendor with a vendor "Product Name" and "Product Code". 3. Create a Sale Order using this same vendor as the Customer. 4. Add the product to the Sale Order Line (SOL). Reference [video](https://drive.google.com/file/d/1wqsOoE00kOowm9puGXgDTGdV9Xkkwton/view?usp=sharing) Observation and issue: ------------------------ 1. Before clicking outside the SOL, the description remains unfilled despite the availability of a vendor product name and code. 2. Upon clicking outside the SOL, the description displays only the vendor product name and code incorrectly overriding the standard product name. Cause: --------- * The SOL description([_compute_name](https://github.com/odoo/odoo/blob/cbcfb93067f6a3ec6f87dfa5b05497777bead425/addons/sale/models/sale_order_line.py#L406)) depends on product's `display_name`, but missing dependencies prevent `_compute_display_name` from being triggered before saving. For reference, POL description: https://github.com/odoo/odoo/blob/a877beaeeb45a2ca3d68bf423f9948f58f6c64aa/addons/purchase/models/purchase_order_line.py#L369-L370 * When the customer and vendor are the same, the `display_name` is computed using vendor context (`partner_id`), causing vendor-specific values to override the product name. https://github.com/odoo/odoo/blob/cbcfb93067f6a3ec6f87dfa5b05497777bead425/addons/product/models/product_product.py#L538-L548 Solution: ----------- * Add the required dependencies to ensure the SOL description is computed correctly . * Skip vendor-based naming when the seller and customer are the same, and fallback to the default product name. opw-5262670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where expense or profit entries were incorrectly appearing in both the current and previous year's Profit & Loss statements. The underlying calculation was flawed, leading to inaccurate reporting. This ensures balance sheet reports accurately reflect financial data.
Original PR description
When generating an expense or profit entry for the current year and then opening the balance sheet for that same year, the entry appears in both the current year’s P&L and the previous years’ P&L. This happens because the previous years’ balance includes all entries and then subtracts the current year, but the subtraction was applied incorrectly (it was effectively doing the inverse). opw-6020381
This update resolves an issue where unit prices were not being rounded correctly when generating PEPPOL invoices. This fix ensures accurate pricing calculations for international trade transactions, improving data integrity and compliance with PEPPOL standards. The change reverts a previous commit that introduced this rounding problem.
Original PR description
This reverts commit d19223a148ab3476b83ed71346eb0712394b7de7. opw-6169870
This update resolves an issue where price rounding errors in Peppol were causing incorrect CUFE generation. The change ensures that all currency amounts are truncated to two decimal places, aligning with DIAN documentation requirements. This improves the accuracy of financial reports for Colombian businesses using Odoo.
Original PR description
**PROBLEM** PR https://github.com/odoo/odoo/pull/255358 fixed price rounding issues in Peppol. This could lead to LineExtensionAmount having more than 2 decimal places, which messed up the CUFE generation. This PR ensures we truncate to 2 decimal places as told in the DIAN documentation. opw-6169870
This update resolves an issue where the 'PayableRoundingAmount' was incorrectly calculated as a cash rounding. The fix creates the invoice first and then applies the necessary adjustments to the untaxed amount, aligning with how tax calculations are handled. This ensures accurate financial reporting related to UBL imports.
Original PR description
PayableRoundingAmount is not necessarily a cash rounding. It might also be the difference between the untaxed amount per line regarding the global untaxed amount due to the global tax rounding method. The idea in this commit is to create the invoice first and then, just like the code fixing the taxes, to post fix the untaxed amount after. opw-6151984 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the 'Backend' button in Point of Sale was causing a session to be deleted twice, leading to potential data inconsistencies. The fix ensures the session deletion method checks if the session has already been removed, improving stability and data integrity. This addresses a technical bug impacting session management.
Original PR description
Before this commit, when clicking on the "Backend" button of a session in "Opening Control" state, the delete_opening_control_session method was called twice, while the first call already deleted the session. The problem was that the method is overridden in the pos_urban_piper module, and it did not check if the session was already deleted. opw-6114420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr