Monday, May 4, 2026
21 changes · saas-19.2
Resolved issues and error corrections
This update enhances the accuracy of write-off reconciliation within the accounting module. It now filters reconciliation models to only display those that are manually created or directly linked to the statement lines' journal, preventing errors caused by unrelated journal associations. This ensures a cleaner and more reliable reconciliation process.
Original PR description
In the account reconciliation wizard: - Only show manually created reconciliation models. - Only display reconciliation models that are not linked to any journal or are specifically linked to the journal of the statement lines. task-6059342 Forward-Port-Of: odoo/enterprise#111644
This update resolves an issue preventing accurate overtime pay calculations. The system was failing to correctly associate work entry types with overtime rules, leading to missed overtime hours on payslips. The fix restores the necessary data file and corrects the system's reference to ensure overtime is properly accounted for.
Original PR description
Issue: The issue here is that work_entry_type is not associated with the overtime ruleset. That's why when creating a payslip, it is not considering overtime hours. From this PR - https://github.com/odoo/enterprise/pull/98952 the data file is missing from the manifest file. Fix: Added back file to manifest and fixed reference for work_entry_type_id. task-6073921 Forward-Port-Of: odoo/enterprise#112934
This update restores a previous system for tracking changes made to payslip lines, providing a clearer audit trail. Previously, changes were logged more comprehensively, now all affected lines are recorded when a user modifies a payslip. This enhances transparency and accountability for payroll adjustments.
Original PR description
purpose: We want to reintroduce the same way of logging payslip lines changes as previously done by the removed payslip edit wizard - changed the log in chat to include all affected lines by the user's change task-id: 6144266
This update fixes an issue where the namespace for DIAN credit notes was incorrectly configured, causing problems when submitting to the DIAN tax authority. The fix ensures that only the top-level node of the credit note has the correct namespace, aligning with DIAN requirements. This resolves a recurring problem identified and addressed previously.
Original PR description
Issue: Incorrect `sts` namespace raises several issues when sent to dian Steps to reproduce: - On a Colombian company - Create a credit note - Send to DIAN Current Behavior: - Credit note have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1` while their Extension node has another `sts` namespace to `http://www.dian.gov.co/contratos/facturaelectronica/v1/Structures` Expected Behavior: - Only the top level Node should have `sts` namespace defined to `dian:gov:co:facturaelectronica:Structures-2-1`. It was forgotten that Credit Note were part of the Invoices in the last refactor. As it's the second time(odoo/enterprise#68619 3rd commit) it happens, I updated the test. opw-6077050 Forward-Port-Of: odoo/enterprise#114725 Forward-Port-Of: odoo/enterprise#113643
This update adds a configuration setting to enable logging of order data during support investigations. This allows support teams to better understand and troubleshoot issues with point-of-sale orders. A new 'pos_reference' field is added to the logs for easier identification.
Original PR description
During support investigations, it can be useful to log the data of the orders being processed in `sync_from_ui`. This commit adds a configuration parameter `point_of_sale.log_order_data` that allows to enable this logging. By default, it is disabled to avoid filling the logs with potentially sensitive data. Also, the pos_reference field is added to the order representation in the logs, as it's printed in the receipt and can be useful to identify the order in the logs. opw-6145038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262109 Forward-Port-Of: odoo/odoo#261792
This update addresses a user experience issue where a Point of Sale session wouldn't automatically close when the user left the browser tab or navigated away. This prevented confusion for users and ensured sessions were properly terminated. The change removes the lingering session to improve clarity.
Original PR description
When the user closes the browser tab or navigates away after a session in opening_control, the session is not deleted and it causes confusion. opw-6114420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261207 Forward-Port-Of: odoo/odoo#258933
This update addresses a user experience issue where a lingering session in the opening_control POS module persisted after a user closed their browser tab or navigated away. This caused confusion for users. The fix ensures sessions are properly terminated, improving the overall POS experience.
Original PR description
When the user closes the browser tab or navigates away after a session in opening_control, the session is not deleted and it causes confusion. opw-6114420 Forward-Port-Of: odoo/enterprise#115056
This update optimizes how prices are calculated in the Point of Sale system. Previously, price recalculations were performed repeatedly, causing performance issues. This change consolidates these calculations into a single, efficient process, resulting in faster order processing and a smoother user experience. Additionally, the update improves the system's efficiency by preventing unnecessary data serialization in production environments.
Original PR description
Calling triggerRecomputeAllPrices() synchronously on every orderline mutation (create, merge, delete) caused the full tax/price computation to run 3 times per addLineToOrder call when a merge occurred, and triggered an expensive JSON.parse/JSON.stringify of the price data on each of those calls via logPosMessage. Replace the eager synchronous recompute with a microtask coalescer: the first call within a synchronous operation schedules a single Promise.resolve().then() microtask; subsequent calls within the same tick are no-ops. Because the microtask is queued before the outer await continuation (updatePrograms), _updatePrograms still reads fresh prices when it accesses line.prices. Also guard the args serialization in logPosMessage behind odoo.debug so the JSON deep-clone of the price data object is skipped entirely in production. opw-6091501 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#260436
This update resolves an issue preventing Winbooks import files from correctly mapping tax accounts. The fix re-enables a temporary workaround that allows Odoo to recognize the standard Winbooks account (411000) for Belgian companies, ensuring successful import and accurate data transfer. This prevents users from needing to manually adjust account settings.
Original PR description
Steps to reproduce: ------------------- 1. Install account_winbooks_import, and switch to a Belgian company 2. Open Accounting > Configuration > Settings and click "Import", then click "Import WBK"…
Steps to reproduce: ------------------- 1. Install account_winbooks_import, and switch to a Belgian company 2. Open Accounting > Configuration > Settings and click "Import", then click "Import WBK" 3. Upload a Winbooks zip whose chart of accounts uses 411000 typed as asset_current (Winbooks default for "VAT Recoverable") 4. Confirm the import The import fails with: "You must select a receivable account for 'Tax Receivable Account'." Why the issue ------------- In Winbooks, account 411000 is the V01 central account (tax receivable). In Odoo, 411000 comes from l10n_be (account "a411") with type "asset_current", not "asset_receivable". When the import wizard sets it on the existing tax groups via `manage_centralid` in import_wizard.py, the constraint `_constrains_payable_receivable_account` on account.tax.group rejects the write because the account is not "asset_receivable" + "non_trade". This case was already handled in 20804db6d87: we bypassed the constraints on accounts coming from Winbooks, as those are imported in draft anw and the user finishes the configuration after. However later, [2a38e771a826](https://github.com/odoo/odoo/commit/2a38e771a826) and ff5dee81080 removed the initial constraint and the code that bypassed it for account_winbooks_import. Finally, [746a06fab485](https://github.com/odoo/odoo/commit/746a06fab485) added back a similar constraint "_constrains_payable_receivable_account" to fix a NL issue (same account used as both payable and receivable on a tax group). The Winbooks bypass however was not added back, so the original Winbooks issue appeared again. The fix ------- Add back the same bypass originally introduced in 20804db6d87. opw-6092464
This update corrects a problem where existing ARCA connections persisted after duplicating an Odoo database. This prevented users from properly testing in a sandbox environment, potentially leading to production connections being used. The fix now clears these connections when credentials are updated, ensuring a clean testing environment.
Original PR description
Problem and Cause: When duplicating a database with existing ARCA connections, the connections to ARCA webservices are not cleared. Users using the duplicate database may not realize that the ARCA connections are still present. This may lead to production connections getting used while users are testing. Solution: Clear connections to ARCA webservices when updating the credentials. Forward-Port-Of: odoo/enterprise#115068
This update adds logging of Amazon's request identifiers to the SP-API responses. Previously, this information was missing, making it harder for support teams to troubleshoot issues with Amazon. Logging this identifier will significantly improve support efficiency and response times.
Original PR description
Each response from Amazon's SP-API includes a request identifier used by their support team for debugging. This identifier was not previously logged, making support investigations more difficult. Forward-Port-Of: odoo/enterprise#114483
This update fixes an issue where applying a global discount and a gift card resulted in an incorrect order total. The system was incorrectly recomputing the discount based on the gift card amount, leading to an inflated total. The fix ensures gift card deductions are handled properly, providing accurate order totals.
Original PR description
Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base.…
Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base. The negative reward line was included in `isGlobalDiscountApplicable()`, so the percentage discount shrank and the order total increased by “global_discount% × gift card amount” (e.g. 10% of $50 → $5 added back). Steps to reproduce: ------------------- * Open PoS with global discount and a gift card / eWallet program. * Add a product (e.g. $100), apply a global discount (e.g. 10%). * Apply a gift card for part of the balance (e.g. $50). > Observation: Total is wrong (e.g. $45 instead of $40): the gift card amount is reduced, then a fraction of that amount is added back via the recomputed global discount line. Why the fix: ------------ `pos_discount` only skips tip and discount-product lines; gift card reward lines use another product and were still “discountable”. The fix belongs in `pos_loyalty`: override `isGlobalDiscountApplicable()` to return false only for gift card and eWallet reward lines (`isGiftCardOrEWalletReward()`), and fall to `super` otherwise so promotion/loyalty reward behavior stay correct. opw-6104090 Forward-Port-Of: odoo/odoo#259577
This update corrects a previous issue where all employees could see each other's overtime hours. The root cause was a setting in the system's calculations that granted excessive access. The fix removes this setting and includes new tests to ensure this problem doesn't reoccur.
Original PR description
- Step to reproduce: everyone can see everyones overtimes. - Cause: total_overtime compute method is using `compute_sudo=True`. - Solution: removing compute_sudo and adding tests Task: 6125021 Forward-Port-Of: odoo/odoo#262107 Forward-Port-Of: odoo/odoo#261496
This update resolves an issue where the default email template body wasn't appearing in the full composer view within the chatter. The fix ensures that the correct default template body is loaded, regardless of whether the user manually enters content in the composer, improving email communication reliability.
Original PR description
**Issue:** - When opening the full composer from the chatter, the body of the default email template is not loaded. Only the subject line from the template appears, while the body remains empty or…
**Issue:** - When opening the full composer from the chatter, the body of the default email template is not loaded. Only the subject line from the template appears, while the body remains empty or contains only the user's signature. **Steps to reproduce:** 1. Install `contact` 2. Open any contact form. 3. In the chatter, click 'Send message' and then expand button 4. Write a something in body, then save this as a new template. 5. Set this new template as the default (using Debug Mode > Set Default Values). 6. Click 'Send message' in the chatter, 7. Click the 'Full composer' (expand) button without typing anything. **Observed behavior:** - The full composer opens with the correct subject from the default template, but the body is empty. **Cause:** - The `onClickFullComposer` method always passes a `default_body` value in the context to the mail.compose.message wizard. Even if the chatter input is empty **Solution:** - Forward isBodyEmpty in the context from onClickFullComposer. If the user typed content, do nothing. If the body is empty and a default template is available, allow the backend to apply the default template by removing default_body. opw-5405056 Forward-Port-Of: odoo/odoo#257277 Forward-Port-Of: odoo/odoo#239851
This update significantly speeds up the process of writing data to reconciliation models in the accounting system. By optimizing how the system retrieves and filters bank statement lines, the update reduces processing time and memory usage, particularly for large databases with many unreconciled transactions. This results in a smoother and faster user experience.
Original PR description
When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on `unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled…
When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on `unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled statement lines scattered across multiple models, this `filtered` can be heavy, both in memory (fetching all the amls fields) and in time. This commit fixes this by using a search to prefilter the amls using the reconcile models in self. Then we filter the result on `suspense_account_id`. This greatly reduces the number of lines loaded up in memory and speeds up writing on reconcile models. ### speedup In a customer database with 484 042 statement.lines, 141 000 unreconciled statement.lines, 37 account.reconcile.model. Time to write on a reconcile_model. | Nbr linked unreconciled lines| Before PR | After PR | |:----------------------------:|:---------:|:--------:| | 702 | 40s | 3s | | 2000 | 40s | 4.47s | | 10000 | 40s | 11.28s | Since most of the slowness comes from the `filtered` call, the number of unreconciled statement lines linked to the reconcile.model being updated has no impact on the timing before this patch. ### memory For the 702 unreconciled lines case, the memory consumption goes - 2.2 Gb -> 200Mb. Forward-Port-Of: odoo/enterprise#115583
This update fixes an issue where the tax return dashboard wouldn't display all tax return groups, showing only the first few. The change ensures that all tax return groups are expanded automatically, providing a complete view of tax return data. This improves usability for users generating and reviewing tax returns.
Original PR description
When navigating to the tax return list view from the accounting dashboard, only the first few groups were expanded, leaving subsequent groups appearing empty with only a date header visible. Steps to reproduce: - Generate several tax returns. - Open the main Accounting dashboard. - On a Tax Return card, click one of the generated buttons. - Scroll down the resulting list view. Issue: After 10 groups, following sections appear empty, showing only the header Analysis: By default, the web client limits the number of automatically opened groups. This change adds 'max_number_opened_groups' to the buttons context, aligning the behavior with the primary 'Tax Return' button action. https://github.com/odoo/enterprise/blob/1a2afda205c41773747ed5f174d75843effbbe9f/account_reports/views/account_return_views.xml#L183 opw-5769978 Forward-Port-Of: odoo/enterprise#114673 Forward-Port-Of: odoo/enterprise#113332
This update resolves a technical issue preventing the departure form from loading correctly when accessed through the payslip. The fix ensures the correct form view is used, eliminating a problem caused by incorrect context information. This improves the reliability of the payslip process.
Original PR description
The departure form could fail to load when accessed via payslip due to a leaked form_view_ref in the context. Explicitly set the correct form view in the action to avoid this issue. task-6167494
This update fixes an issue where discounts on purchase orders weren't being correctly reflected in the final accounting. The fix ensures that the total tax-excluding amount, including the discount, is accurately displayed when creating accrued expense entries. This improves the reliability of purchase order accounting.
Original PR description
Steps to reproduce: [purchase] - Create a purchase order - add a line with a discount - confirm and receive - create an accrued expense entry Issue: The full tax excl amount is displayed but no discount is applied opw-5049848 Forward-Port-Of: odoo/odoo#240887 Forward-Port-Of: odoo/odoo#225375
This update corrects a bug where invoices rejected by the Italian tax system (SdI) were incorrectly marked as 'sent,' preventing users from resubmitting them. The change automatically clears the 'is_move_sent' flag when an invoice is rejected, allowing for proper resubmission and streamlining the invoice processing workflow. This ensures Italian businesses can quickly resolve issues and avoid delays.
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 Forward-Port-Of: odoo/odoo#262075 Forward-Port-Of: odoo/odoo#260591
A bug was preventing custom loyalty program domains (using many2many fields) from functioning properly when accessing the point-of-sale (POS). This fix expands a previous change to support many2many fields, ensuring loyalty rewards can be applied correctly through the POS interface. This resolves a critical issue preventing users from utilizing custom loyalty programs.
Original PR description
When you set many2many fields in a custom loyalty domain, when opening the pos a popup will open saying that the domain must be compatible with the POS.
Steps to reproduce:
-------------------
* Setup a loyalty program, as the reward it should be something like: 10% discount on specific products.
* Set a discount product domain: [("product_tag_ids", "not ilike", "test")]
* Open the pos
> Observation: A popup appears saying that the domain is not compatible with
the pos.
As a result this reward can never be used.
Why the fix:
------------
There's already a function responsible for chnaging `ilike` and `not ilike` with compatible pos operators `in` and `not in`. However this was only applied to `many2one` fields. We extand that.
opw-5990415
Forward-Port-Of: odoo/odoo#258560This update fixes an issue where the 'Back to edit mode' link in the land portal invoice was incorrectly directing users to the wrong Odoo app. By switching to the correct action, the webclient now consistently directs users to the Invoicing app, ensuring accurate invoice management.
Original PR description
The "Back to edit mode" link used action_move_out_invoice_type, which isn't bound to any menu, so the backend fell back to whichever app happened to match (e.g. Website when installed) instead of Invoicing. Switch to action_move_out_invoice (the one referenced by the Invoicing menu) so the webclient resolves the correct app automatically. task-5882256 Forward-Port-Of: odoo/odoo#257841