Thursday, April 16, 2026
6 changes · saas-18.4
Resolved issues and error corrections
This fixes electronic invoice exports so VAT taxable amounts are calculated consistently across all tax categories, not just standard VAT. Businesses using Peppol are less likely to see invoices rejected when discounts and fractional prices create rounding differences.
Original PR description
Steps to reproduce: 1. Create an invoice with a 0% tax (Exempt from VAT, category E) 2. Add two lines with 20% discount and fractional prices: - qty=4, price_unit=39.615 and qty=4 with…
Steps to reproduce: 1. Create an invoice with a 0% tax (Exempt from VAT, category E) 2. Add two lines with 20% discount and fractional prices: - qty=4, price_unit=39.615 and qty=4 with price_unit=0.84 3. Send via Peppol 4. Peppol rejects with: [BR-E-08] VAT category taxable amount shall equal the sum of Invoice line net amounts The TaxableAmount recalculation in _ubl_get_tax_subtotal_node was only applied for tax category 'S' (Standard Rate). However, Peppol schematron has identical rules for all tax categories: BR-E-08 (Exempt), BR-Z-08 (Zero), BR-AE-08 (Reverse Charge), etc. When lines have discounts and fractional prices, the individually rounded LineExtensionAmount values can sum to a different total than the tax base_amount. This affects both rounding modes. For 'S' taxes this was already handled, but for 'E' (and others) it caused Peppol rejection. Remove the 'S'-only filter and match dynamically against the actual tax category code so the recalculation applies universally. opw-6093243 Forward-Port-Of: odoo/odoo#258909
This fixes an issue on mobile where opening the navigation menu could prevent users from typing in the chat composer. Users can now reliably tap into the message box and use the keyboard without needing to close the menu first.
Original PR description
**Description of the issue this PR addresses:** On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open.…
**Description of the issue this PR addresses:** On mobile devices, the chat composer becomes unresponsive when the navigation menu `navbar-toggler` is open. https://github.com/user-attachments/assets/8ef01ec6-4a44-41d3-8b86-74f68caf47ef Steps to reproduce: 1. Open the website in a mobile view. 2. Tap the navbar toggler to open the mobile menu. 3. Without closing the menu, open the chat window. 4. Tap on the message composer text area. → The composer is not accessible. This happens because the bootstrap `Offcanvas` (used by the `navbar-toggler`) traps focus by listening for `focusin` events bubbling up to the document. When the composer is tapped, the Offcanvas intercepts the event and immediately steals focus back to itself, dismissing the virtual keyboard. This commit stops the event propagation at the composer level, ensuring the composer can reliably retain focus in responsive views without interference from active menus. Task-[5954657](https://www.odoo.com/odoo/project/1519/tasks/5954657) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258974 Forward-Port-Of: odoo/odoo#250294
Saving a form could fail when related records from another company were reused from cache even though the current user was not allowed to access them. The web layer now checks those related records against the user's current access rules before showing them, preventing unnecessary access errors during saves.
Original PR description
**Description of the issue/feature this PR addresses**: web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record…
**Description of the issue/feature this PR addresses**:
web_read on x2many fields can reuse cached ids after write/web_save. Some of these cached ids may be inaccessible with the current record rules/context (cache pollution).
**Example**:
- **Context**:
- Two companies exist: Company A and Company B.
- Two users exist: User A and User B.
- User A can only access Company A (company_ids=[A], company_id=A).
- User B is linked to both companies (company_ids=[A, B], company_id=A).
- The "res.company" record rule is the standard one: [('id', 'in', company_ids)] (company_ids comes from allowed_company_ids).
- User A edits User B and saves the form.
- **Steps**:
- User A performs a web_read to load User B: company_ids contains only Company A.
- User A performs web_save (write + internal web_read in the same request): cached ids [A, B] are reused and the code attempts to read Company B.
**Current behavior before PR (without fix)**:
After saving a form with an x2many field, web_save calls write and then web_read. In this flow, web_read can include inaccessible x2many ids from cache and raise an AccessError.
**Desired behavior after PR is merged**:
x2many records are re-filtered with current read rules before formatting, and inaccessible ids are removed from values_list.
Forward-Port-Of: odoo/odoo#257517
Forward-Port-Of: odoo/odoo#250904This fix prevents unnecessary external tax checks during standard checkout and handles tax calculation issues more safely during express checkout. Customers using affected tax setups, such as AvaTax, should no longer encounter an unresponsive checkout confirmation button.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/odoo#259229 Forward-Port-Of: odoo/odoo#256692
This update resolves an issue where the checkout process became unresponsive when using Avatax with Brazilian tax identification. The previous code was unnecessarily calling external tax APIs, leading to errors that blocked the confirmation step. This fix removes the unnecessary API call, improving checkout stability and performance.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#113861 Forward-Port-Of: odoo/enterprise#112515
This update ensures that payments registered in the future are not processed according to Mexican tax regulations (CFDI). The system now filters out future payments, removing the 'Update Payments' button when only future payments are present, preventing incorrect tax signing and maintaining compliance.
Original PR description
To sign a payment registered in the future is not allowed by the government. See http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Guia_llenado_pagos.pdf Steps: - Create a PDD invoice (the due date should be at least 1 month later than the invoice date) - Send it to CFDI - Register a payment in the future -> We have the 'Update payments' button that appear on the invoice view, if you clik on it the payment will be signed With this commit, we filter out the payments with a future date, that way we don't have the 'Update Payments' button if there are only future payments, or the future payments won't be taken into account when clicking on the button. opw-5934753 Forward-Port-Of: odoo/enterprise#113945 Forward-Port-Of: odoo/enterprise#112320