Thursday, February 26, 2026
10 changes · saas-18.3
Enhancements to existing features
This update streamlines the creation of bank accounts for partners and companies, particularly for accounts created through automated processes. It introduces a new method to avoid conflicts and prompts users to manually verify accounts, ensuring accuracy and preventing errors in payment reconciliation.
Original PR description
Forward-Port-Of: odoo/odoo#249983
Resolved issues and error corrections
This update resolves an issue where restarting the chatbot after a page reload caused duplicate actions, leading to a confusing user experience. The fix removes a redundant startup call within the chatbot's restart process, ensuring a smoother and more reliable chatbot interaction. This enhances the overall support experience for users.
Original PR description
Since [1], restarting the chat bot after reload could lead to multiple steps being executed at the same time. Steps to reproduce: - Go to the `/im_livechat/support/2` page. - Chat with the support bot until the end of the conversation. - Reload the page. - Click on the restart button. - Two question selections are displayed at the same time. This occurs because the bot starts from the `_toggleChatbot` field's `onUpdate` method. The `restart` method also calls `start` on the chat bot. To fix this issue, the call to `start` is removed from the `restart` method. [1]: https://github.com/odoo/odoo/pull/194399 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 resolves an issue where the correct currency wasn't consistently applied when transferring CODA payments between multiple journals with the same IBAN but different currencies. The fix ensures payments are routed to the appropriate journal based on its currency, improving financial accuracy and reducing potential errors.
Original PR description
When having multiple journals with the same IBAN, but different currencies, upon fetching and dispatching the CODA into the right journals, the currency of the journal was not correctly taken into account as the condition was incorrect. This commit fixes this condition which was introduced in [^1] such that the right journal, with the right currency is correctly chosen. [^1]: 4fda4fb5353ed9c14dbc023ab7d07fabd3c06e98 opw-5723017
This update fixes a bug that prevented users from accessing certain fields within the AI module. The issue stemmed from a missing error handling mechanism in the code, specifically around fetching regular fields dependent on restricted fields. This change ensures all field access is handled, preventing access errors and improving AI functionality.
Original PR description
Prior to this fix, when accessing some fields to add to the ai context, we would get an access rights error bubble up to the user. The original intention was for the code to fetch all fields for a record, catch access rights errors and if one was caught skip the field from the context. For some reason though, the try-catch was only added around where we are handling the values of relational fields and not when fetching the value of all the fields. That meant that for reguluar fields which are computed using a restricted field, the access rights error would not get caught and bubble up to the user. In this commit we add the regular field accessing inside the try-catch. Task-5948687
This update fixes an issue where Verifactu invoices were incorrectly generated as 'F1' after a full invoice was created. The change ensures that when replacing a simplified Verifactu document, the new invoice type is set to 'F3', aligning with Spanish tax regulations. This ensures accurate reporting and compliance.
Original PR description
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then…
To reproduce ------------- 1. Install `l10n_es_edi_verifactu_pos`, and select the ES company 2. Make an order in PoS with a price less than 400, and don't invoice it. 3. Close the PoS session, then go to PoS > Orders, and select the previously made order 4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order. 5. Click invoice to invoice the order; the invoice is no longer simplified. Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead. The fix ------- When fully invoicing, we check if the order had a linked Veri*factu document of type F2, which means we are now replacing it and should set the type of the new invoice to F3 instead of F1. Sources: -------- Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD opw-5343973 Forward-Port-Of: odoo/odoo#242274
This update fixes a bug where custom analytic distribution settings on sales order lines were being overwritten when using project-based sales. Previously, the default analytic distribution model always took precedence. Now, custom settings will be preserved, ensuring accurate tracking of project costs.
Original PR description
*: project_purchase, sale_project --- Decription of the issue this commit addresses: When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned,…
*: project_purchase, sale_project --- Decription of the issue this commit addresses: When confirming a sales order with a product-partner combination that has an Analytic Distribution Model assigned, any custom analytic distribution done on the line of the product will be lost, resetting the analytic distribution to the default value set on the Analytic Distribution Model. --- Steps to reproduce: 1. Install sale_project,project_purchase. 2. Activate "Analytic Accounting" in the settings. 3. Create a new Product "test"; Type: Service, Create on Order: Project. 4. Create a new Analytic Distribution Models; Partner: Acme, Product: test, Analytic Distribution: anything but blank. 5. Create a new Quotation in the Sales apps; Partner: Acme. 6. Assign the Product test to the first order line. This will automatically set the analytic distrib of the Analytic Distribution Model. 7. In the Analytic Distribution cell, add a line with any non null distribution. 8. Confirm the Quotation. 9. The analytic distribution that was anually added has been removed. Only the default analytic distribution of the model remains. --- Desired behavior after this commit is merged: Any custom analytic distribution done on a line is never lost. The Analytic Distribution Model's distribution serves as a template but never overrides the values set by the user. --- opw-4934291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249747
This update fixes an issue where refund calculations for orders with multiple line items in the Mexican VAT (l10n_mx_edi_pos) module were inaccurate due to incorrect summing of line amounts. The change ensures accurate comparisons against the original order total, preventing refund processing errors and improving financial reporting.
Original PR description
Before this commit, the some of individual line amounts were being summed to compare against the original order total when processing a refund. This could lead to incorrect comparisons due to rounding issues, resulting in errors when attempting to refund orders with multiple lines. <img width="626" height="288" alt="image" src="https://github.com/user-attachments/assets/e1bdc126-64d9-4b9a-bd16-2b97ac75e40c" /> opw-5433201 Forward-Port-Of: odoo/enterprise#105829 Forward-Port-Of: odoo/enterprise#105301
This update corrects a bug where invoices created by users in Saudi Arabia timezones could be incorrectly dated in the future, leading to rejection by ZATCA. The fix normalizes invoice dates to ensure they are always created within the correct Saudi Arabian time zone, resolving this compliance issue.
Original PR description
In odoo/odoo#236865 we decided to allow clients to backdate invoices by letting them use the `invoice_date` field for the invoice date and use the current time as the issue time because we are not supposed to use a dummy value for time. This created an issue where if a user in a timezone before SA tries to invoice a document around midnight using the current date in SA the datetime created will be in the future which will lead to the invoice being rejected by ZATCA. This commit makes sure we normalize the selected date wrt to the current datetime in saudi arabia so that we never accidentally invoice into the future. task-5890423 opw-5373067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250366 Forward-Port-Of: odoo/odoo#246311
This update fixes an issue where VAT calculations were incorrectly set to zero when generating XML reports from manual journal entries. The fix removed a faulty condition in the SQL query, ensuring accurate VAT amounts (MHT, TVA, TTC) are now correctly included in the exported XML files. This ensures accurate reporting for tax compliance.
Original PR description
## Issue: When creating a manual journal entry with a deductible tax, the entry was included in the XML export, but the VAT amounts were all set to 0 ## Cause: The SQL query used to compute VAT amounts included an extra condition on display_type to be 'tax' However, journal entry lines are standard product lines and should not be excluded by this condition As a result, the amounts (MHT, TVA, TTC) were incorrectly computed as 0 in the XML ## Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA Company - Create a Journal Entry (Any account, Debit: 100, Taxes: 10% 150) - Open the Tax Report for the current month - Export the XML using the gear icon Before the fix, the value for mht, tva and ttc where all 0 opw-5226529 Forward-Port-Of: odoo/enterprise#108644
This update resolves an issue preventing child companies from utilizing the parent company's SDI proxy user. The fix ensures child companies can correctly send invoices by allowing them to leverage the existing parent proxy, addressing a previous software update oversight. This improves functionality for clients using the account_edi_proxy_client feature.
Original PR description
This fix implements the same change made in PR #209120 to allow a child company to use the parent proxy user. It seems the record rules modification was missed during the FW, causing issues for clients using this feature in 18.2+ Steps to reproduce: - Create company A and a child company B sharing the same fiscal and VAT information - Register company A in the SDI (creating a proxy user) - Go to company B and try to send an invoice. You will get an error because Odoo will try to create a new proxy user as the parent proxy is currently inaccessible due to record rule constraints. Ticket [link](https://www.odoo.com/odoo/project.task/5927104) opw-5927104 Forward-Port-Of: odoo/odoo#249821