Tuesday, March 10, 2026
5 changes · saas-18.4
Resolved issues and error corrections
This update resolves an issue where users without project access rights would encounter errors when modifying MOs associated with private projects. The fix ensures that workers can successfully update these MOs by granting necessary read permissions to project data, preventing access errors and improving workflow efficiency.
Original PR description
When working on a MO that is linked to a project in private, it will trigger a access error if the worker is does not have project access right Steps to reproduce: ------------------- * Install Project, MRP, Accouting * Create a private project * Create a MO and link it to this project * confirm this MO with a user that has no project access right Observation: ------------- When modifying the MO, we will pass through the write that has been overwritten: https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/project_mrp_workorder_account/models/mrp_production.py#L6-L10 we will call _get_analytic_distribution on project.project and since _get_analytic_distribution will [read fields from self](https://github.com/odoo/odoo/blob/436921c24a531eba6bf57ffe3f7c3b4978139d83/addons/analytic/models/analytic_line.py#L59-L64) we need project.project read rights. opw-4919576 Forward-Port-Of: odoo/enterprise#108148
This update ensures taxes are automatically calculated for charge and discount lines in UrbanPiper orders, even when tax data isn't initially provided by the UrbanPiper system. Previously, taxes weren't applied if UrbanPiper didn't send tax information, and it was limited to India. Now, the system uses standard product tax rules for these lines, ensuring accurate tax calculations across all regions.
Original PR description
Before this commit: --- - If UrbanPiper did not send tax data for charge and discount lines, taxes were not applied. - Tax data was only provided by UrbanPiper for the India region. After this commit: --- - When the payload does not include tax data, compute taxes for charge and discount lines using the product tax, the same way as for normal order lines. task-5895987 Forward-Port-Of: odoo/enterprise#108821 Forward-Port-Of: odoo/enterprise#106686
This update resolves an issue where the 'Submit' button for Dutch account returns didn't actually trigger the necessary XBRL export to the tax authorities. Now, when an account return is submitted, the correct XBRL data is generated and transmitted, ensuring accurate reporting and compliance with Dutch regulations.
Original PR description
Commit 647699eeb4b8a1cc37ca074fa57844871c5086c1 introduced account returns to the Dutch localization. However, the "Submit" action only updated the internal record state without triggering the actual XBRL export to the Dutch tax authorities. This led to a mismatch where the UI displayed "Submitted" despite no data being transmitted. This commit fixes the flow by: - Overriding `action_submit` on the account return to launch the XBRL wizard when the return type is a Dutch tax return. - Ensuring the SBR tax report wizard calls `_proceed_with_submission` on the associated account return to correctly finalize the process (including locking the period and generating the closing entry). opw-5974711 Forward-Port-Of: odoo/enterprise#109691
This update fixes a server error that occurred when merging tables in the Point of Sale (POS) system, specifically when a table was empty. The fix ensures the system waits for order synchronization before merging, preventing errors and improving table management functionality. This enhances the reliability of the POS experience.
Original PR description
Steps to reproduce: - On an empty table, change the guest count - Create an order and send it to the kitchen - Open another table without an order - Merge the first table with the second one Issue: - A server error occurs while merging the tables Fix: - Wait for the merge order to sync before returning the result Task-5502511 Related PR - https://github.com/odoo/odoo/pull/245162 Forward-Port-Of: odoo/enterprise#104577
This update resolves an issue where payments with outstanding receipts accounts weren't automatically matched in the bank statement reconciliation process. The fix allows for amount matching, ensuring payments are correctly linked to invoices and bank transactions when the outstanding receipts account is active. This improves the accuracy of financial reporting.
Original PR description
Steps to reproduce - Have a Bank journal with Outstanding Receipts accounts set - Create and confirm an invoice with a payment reference - Create the payment - Create a bank transaction with: - Label: any label - Partner: invoice partner - Amount: invoice full amount Issue: Transaction won't be matched automatically Analysis: Transaction will be automatically matched if the outstanding receipts account is not set. It occurs because in case it is set, the sytem will only try to match the communication pattern against the journal item of the payment, without trying amount matching Note: another solution could be to relax the communication matching. In the user case the invoice payment reference is something like `TEST-12345` and the payment communication `AAAAAAAAAAA /BBBBBBBBBBB TEST 12345` opw-5872387 Forward-Port-Of: odoo/enterprise#108564