Daily updates from Odoo
Thursday, March 5, 2026
16 changes · 18.0
Enhancements to existing features
This update addresses a significant change in the format required for Spanish VAT reports, specifically for the 2026 tax year. The update includes a new field for petrol and adjustments to the report structure, ensuring compliance with updated tax regulations. This change impacts the accuracy of reported VAT data.
Original PR description
The format for 2026 changed quite significantly. There is an extra field for the petrol, which we basically do not touch and a lot of casillas that changed places. opw-5990405 Forward-Port-Of: odoo/enterprise#109503
This update enhances the account_edi_ubl_cii module by completely separating the BIS3 export process. It deprecates several older functions related to BIS3 UBL generation, streamlining the process and improving efficiency. This change ensures consistent and accurate UBL export for BIS3 invoices.
Original PR description
Deprecate: _ubl_add_base_line_ubl_values_item _ubl_get_line_item_node _ubl_add_base_line_ubl_values_price _ubl_add_values_payable_amount_tax_withholding _ubl_add_values_payable_rounding_amount _ubl_add_values_allowance_charge_early_payment _ubl_add_values_tax_currency_code_company_currency_if_foreign_currency _ubl_add_values_tax_currency_code_company_currency _ubl_add_values_tax_currency_code_empty _ubl_add_values_tax_currency_code --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Previously, users couldn't search for tasks assigned to specific team members within the Odoo portal. This update fixes a bug that prevented the 'Search In Assignees' feature from returning accurate results. Now, users can effectively find and manage tasks assigned to their team.
Original PR description
Description of the issue/feature this PR addresses: - On the portal task, "Search In Assignees" always returns no tasks. <img width="1482" height="979" alt="Screenshot 2026-02-04 at 23 02 53" src="https://github.com/user-attachments/assets/263429b4-0c32-4323-bf88-2dfaf2115181" /> <img width="1430" height="943" alt="image" src="https://github.com/user-attachments/assets/3c196cc1-f12d-4064-838d-8e29914e5fab" /> Current behavior before PR: - Cannot search for tasks in the portal by assignee. Desired behavior after PR is merged: - Can search for tasks in the portal by assignee. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where large file uploads to forms would fail, resulting in error messages. The fix ensures that the system correctly handles request body size limits imposed by our reverse proxy servers, preventing errors and improving the user experience when uploading files.
Original PR description
# How to reproduce - A reverse proxy needs to be set up between the client and the backend (for localhost, you can use nginx) - This reverse proxy needs to have a request max body size set below…
# How to reproduce - A reverse proxy needs to be set up between the client and the backend (for localhost, you can use nginx) - This reverse proxy needs to have a request max body size set below 128mb (for nginx : client_max_body_size) - If the system parameter web.max_file_upload_size is set, delete it and refresh your page - Pick any form view and add a file field with studio - Upload a file larger than the limit set in the proxy, but smaller than 128mb - Save the form # The problem The form is not saved and depending on the version, a Traceback will be shown (18.X) or a Connection Lost notification will be shown for a short period of time (19.0+) # Why When the system parameter web.max_file_upload_size is not set, the check for file size uses the default 128mb. A binary field added to a form via studio will upload its file in the json of the post request. This is done by encoding the file in base64. Our nginx servers set a limit for the request body size (usually 64mb). So if you add a file between 64mb and 128mb, it will bypass the default front-end size check but be stopped by the nginx reverse proxy. The proxy will send back an HTTP response with error code 413 to the client. Theses http responses are not correctly handled by the framework and are interpreted as a Connection Lost error because the response content cannot be parsed to json. Additionally, since we use base64 for the encoding and then use gzip to compress the json request, it's not really feasible to synchronize the front-end limit with the nginx one. opw-5891662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an error in how project budget spending is calculated. Previously, the system incorrectly displayed negative percentages and inflated remaining budget figures. The fix ensures accurate spending and remaining budget calculations for expense budgets, providing reliable financial reporting.
Original PR description
Steps to reproduce: --------------------------- 1. Install the `project_account_budget` and `account_accountant` modules. 2. Create a new project and add an Analytic Account for it from the settings…
Steps to reproduce: --------------------------- 1. Install the `project_account_budget` and `account_accountant` modules. 2. Create a new project and add an Analytic Account for it from the settings page 3. Open the Project Kanban, click the three dots on the project card, and select Project's Updates. 4. Click Add Budget button and open the budget wizard. 5. Add a budget line in the wizard with a planned amount expressed as a negative value for an expense (for example: -10000). 6. Create a Vendor Bill using the same analytic account with an amount of 1000. 5. Confirm the bill. 6. Go back to Project's Updates and click New button to view the budget summary. Observation: --------------------------- The budget summary displays incorrect signs and percentages in Activities summary, for example: ``` -10.0% (-1,000.00) of the -10,000.00 budget has been spent. 110.0% (-11,000.00) of the budget is remaining. ``` This incorrectly shows -10% spent and 110% remaining instead of 10% spent and 90% remaining (-9,000). Issue: --------------------------- The project cost (already negative) was negated again when computing the spent amount in https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/project_account_budget/models/project_update.py#L16 Double-negating the cost makes it positive, which then gets added to the expense budget instead of reducing it, producing inverted percentages and signs. Solution: --------------------------- For expense budgets (negative budgets), do not apply an extra negative sign when calculating the project cost so the spent, remaining, and percentage values are computed correctly. After the fix: ``` 10.0% ($ 1,000.00) of the $ -10,000.00 budget has been spent. 90.0% ($ -9,000.00) of the budget is remaining. ``` opw-5357854 Forward-Port-Of: odoo/enterprise#102126
This update fixes an issue where currency exchange difference values were missing from DATEV exports. The fix ensures that the correct exchange rates are accurately reflected in the exported data, providing more reliable reporting for DE clients. This improves the accuracy of financial reports generated for DATEV.
Original PR description
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has…
**Steps to reproduce: 1. Create DE company (EUR currency) 2. Add USD -> EUR exchange rates for XX/01/26 and XX/15/26 (XX is target month) 3. Install l10n_de_reports 4. Make sure bank journal has 'outstanding receipts' set for incoming manual payment [Accounting -> Config -> Journals -> Bank] 5. Create USD invoice for XX/02/26 and confirm it 6. Register a Payment for XX/16/26 and confirm it (you should see the exchange difference entry matched alongside the payment) 7. Go to [Accounting -> Reporting -> General Ledger] and export DATEV data **Description of issue: The currency exchange rate difference entries in the exported file are shown as 0 **Expected behavior: The actual currency exchange difference values should be displayed **Why this happens? The DATEV export currently sets the amount based on 'amount_currency'. For currency exchange difference entries, this value is 0.0 in the General Ledger, resulting in 0 values in the export. **The fix: Updated the logic to use the line balance when the entry is identified as a currency exchange difference. opw-5358954
This update optimizes the ZATCA journal onboarding process by reducing memory usage. Previously, a lengthy check looped through all journal moves, causing errors with large journals. Now, the check directly targets relevant 'to_send' documents, significantly improving performance and stability.
Original PR description
Behavior before: Sanity check looped over all account moves of the journal, filtering in Python for ZATCA documents. This caused memory errors when the journal had hundreds of thousands of moves. Behavior after: The check now searches directly on l10n_sa.edi.document with a domain that filters only relevant moves with state 'to_send', reducing memory usage and avoiding Python-level loops. Root cause: Loading all moves and their One2many edi_document_ids in memory for filtering caused excessive memory usage and MemoryError on large journals. OPW-5972073 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251732
This update fixes an issue where instructions added to Work Orders weren't correctly linked when creating a Manufacturing Order (MO) via the mobile app. The fix addresses a previous change that removed a key data field, preventing the proper connection between the BOM and the MO. This ensures instructions are accurately reflected when creating MOs on mobile devices.
Original PR description
# How to reproduce - Create a BOM for a product with a Work Order - Add instructions to the WO - Using mobile, create a new MO for the product # The problem The instructions are not linked to the MO. This can easily be seen via the shop floor application # Why This issue is identical to https://github.com/odoo/odoo/pull/197889. This commit https://github.com/odoo/odoo/commit/b1ceec4c616d8ad2fee5b0fa1ce76c85cacbb344 removed the operation_id field from the workorder kanban mobile view, which is used in the MO form on mobile. operation_id is then not passed to the server in vals_list when creating the MO but it is required to link the instructions from the BOM to the MO. opw-5950983 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where editing recurring events synced from Outlook would trigger excessive and unwanted email notifications to attendees. The change prevents Odoo users from directly modifying Outlook-created recurring events, streamlining the event management process and reducing potential communication overload. This improves user experience and reduces unnecessary email traffic.
Original PR description
## Issue: Recurring events created from Outlook should not be able to be edited from Odoo, this is because the changes made are going to be sending unwanted emails to the attendees. ## Steps to…
## Issue: Recurring events created from Outlook should not be able to be edited from Odoo, this is because the changes made are going to be sending unwanted emails to the attendees. ## Steps to reproduce: 1. Connect to Outlook and Sync for user A. 2. Create a recurring event from Outlook. 3. Connect into a user B with access to the event and edit all the events from the series. 4. Run the scheduled action to sync user A. 5. Many emails are going to be sent to the attendees from Outlook. ## Solution: With the current implementation, we are going to avoid editing for the users connected to Outlook, however any user with the access to that event in Odoo and that it has not synced with Outlook is going to be able to edit the event. To avoid this, we should check if the event is recurring and it has been created from Outlook, for this we are going to be looking for the event `microsoft_recurrence_master_id` which will be available only for the recurring events created from Outlook. opw-4374503 Forward-Port-Of: odoo/odoo#199663
This update resolves a bug where manufacturing orders using BoMs with mismatched UoMs would cause errors and incorrect calculations. Now, the system correctly uses the BoM's UoM settings when creating manufacturing orders, ensuring accurate stock management within the barcode app.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196) Forward-Port-Of: odoo/enterprise#90408
This update resolves a technical issue where payment processing through Authorize.Net was occasionally failing due to a conflict between updates. By adding a temporary lock to the payment transaction record, Odoo now ensures that tokens are used only once, preventing errors and correctly recording successful payments.
Original PR description
Currently, when processing a payment through Authorize.Net, a concurrent update (e.g., from a background cron job) can trigger a PostgreSQL `SERIALIZATION_FAILURE` right after the API request succeeds. Because Odoo automatically retries the request upon this failure, the second attempt sends the same One-Time-Use (OTS) token. Authorize.Net rejects the reused token ("Invalid OTS Token"), causing a successful charge to be incorrectly marked as failed in Odoo.
This commit introduces a pessimistic lock (`FOR NO KEY UPDATE`) on the `payment_transaction` record before making the call to Authorize.Net. This serializes access to the transaction row, ensuring that any lock waits or serialization failures occur *before* the single-use token is consumed, allowing Odoo's automatic retry mechanism to succeed safely.
opw-5475032
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves a bug where users could repeatedly cancel subscription invoices even after they were marked as closed. The fix prevents the system from allowing cancellations on subscriptions that have already been churned and still contain outstanding invoices, ensuring data integrity and preventing potential revenue discrepancies. This improves the reliability of the subscription management process.
Original PR description
Steps to reproduce: -------------------------------- 1. Install Subscription module 2. Create a new subscription quotation and confirm it 3. Generate an invoice for the subscription 4. Attempt to cancel the subscription * A ValidationError is correctly raised 5. Close the subscription by selecting any close (churn) reason 6. Attempt to cancel the same closed subscription again Observation: -------------------------------- The subscription is successfully cancelled even though it already has invoices Issue: -------------------------------- In the following code: https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/sale_subscription/models/sale_order.py#L741-L742 The cancellation logic does not check whether a subscription is already churned and still has active invoices Solution: -------------------------------- Added an additional condition to prevent cancelling churned subscriptions that still have active invoices opw-5479719
This update fixes an issue where backorders were incorrectly doubling labour costs in the accounting system. When ‘Create Backorder’ is always enabled, a process triggered a duplicate labour entry. The change ensures labour costs are only recorded once per workorder time, preventing inaccurate accounting and maintaining correct financial reporting.
Original PR description
When the Manufacturing operation type is configured with Create Backorder = Always, `mrp.production.pre_button_mark_done()` re-enters `button_mark_done()` in the same server execution path. This can trigger `_post_labour()` twice, causing two posted “<MO> - Labour” journal entries and doubling labour costs in Accounting. Labour costs should be posted only once per workorder time entry. Ensure labour is only posted once by skipping workorder times that were already linked to an accounting entry. This prevents a second execution from creating a duplicate labour journal entry. A test was added to cover the partial production flow when backorder is set to “Always.” Related ticket: opw-5931754 ---
This update resolves an issue preventing users from correctly setting up Amazon accounts when using multiple companies within Odoo Enterprise. The change expands the onboarding process to allow access to all company data, eliminating a mismatch error and ensuring a smoother setup experience. This improves usability for businesses managing multiple sales channels.
Original PR description
The onboarding return route is a website route with access restricted to the website company only. This causes an error when the company doesn't match the Amazon account being connected. This commit allows users to access all their companies during Amazon account setup to avoid this mismatch error. opw-5944078
This update fixes an error in how outstanding amounts are calculated when a down payment is reversed with a credit note. Previously, the system incorrectly resulted in negative amounts, leading to incorrect settlement calculations. This change ensures accurate outstanding balances are displayed and processed.
Original PR description
When having a down payment that is reversed by a credit note, the amount unpaid is wrongly computed. This is because we take the sum of invoice lines price total, regardless they come from invoice or credit note. Therefore we end up with negative value. Steps: - Have a SO for 500 - Make a downpayment for 300, confirm - Make a credit note for the downpayment invoice, confirm -> SO's amount unpaid is -100, it should be 500. If you now settle the SO, the amount unpaid will be -300 instead of 0. opw-5175562 Forward-Port-Of: odoo/odoo#233248
A recent update caused a disruption in our SEPA direct debit payment processing. Customers were unable to complete payments using this method due to an error related to company identification. This fix resolves the issue, restoring reliable SEPA direct debit functionality.
Original PR description
Issue: --- The SEPA direct debit is broken. Steps to reproduce: --- 1- Enable SEPA direct debit in payment providers. 2- Add something to cart and try paying using SEPA direct debit. You get the error: `payment.provider object has no attribute company.` Cause: --- This is introduced after #250326. opw-5993720 Forward-Port-Of: odoo/enterprise#109672