Tuesday, September 15, 2026
6 changes · 17.0
Resolved issues and error corrections
Customers with AvaTax exemptions can now complete checkout when a discount or loyalty reward is applied. The fix ensures taxes are recalculated during final payment validation, preventing mismatches that blocked valid orders.
Original PR description
Steps to reproduce: - Activate AvaTax in db - Configure a discount for a product in Discount & Loyalty - Log in as a portal user that has a tax exemption set in the AvaTax portal (Avalara) - Add the product with the discount to your cart - Try to check out Current Behavior: - You can't check out due to validation error Expected Behavior: - You can check out Clarification: You are currently unable to checkout under these conditions because when you hit pay, the final check does not recompute taxes which will lead to a mismatch and thus an error opw-5285825
Customers using AvaTax with tax exemptions can now complete checkout when their cart includes loyalty or discount rewards. The fix ensures taxes are recalculated at final payment validation so discounted orders no longer fail because of a tax mismatch.
Original PR description
Steps to reproduce: - Activate AvaTax in db - Configure a discount for a product in Discount & Loyalty - Log in as a portal user that has a tax exemption set in the AvaTax portal (Avalara) - Add the product with the discount to your cart - Try to check out Current Behavior: - You can't check out due to validation error Expected Behavior: - You can check out Clarification: You are currently unable to checkout under these conditions because when you hit pay, the final check does not recompute taxes which will lead to a mismatch and thus an error opw-5285825
The website sitemap creation process now avoids loading large page design data that is not needed. This helps prevent out-of-memory failures on websites with many pages, improving reliability for larger sites.
Original PR description
- Before this commit: All fields of ir.ui.view were prefetched, including arch_db and arch_prev. This caused an out-of-memory issue when dealing with many pages. - After this commit: Only required fields are fetched, avoiding unnecessary memory consumption from view architecture data. opw-6470593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes incorrect Austrian tax tag assignments that caused amounts to be reported under the wrong categories. Businesses using the Austrian localization will get correct reporting amounts for tax tags 060 and 124.
Original PR description
**Description of the issue/feature this PR addresses:** The tax tags were configured wrong and not analog to the other 060 taxes and the same for 124 **Current behavior before PR:** Wrong reporting amount **Desired behavior after PR is merged:** Proper reporting amount for tax tag 060 and 124 Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Swiss payroll users can now manually enter an hourly wage factor on a draft ELM payslip and keep that value after saving. This prevents incorrect wage data from being reset to zero, reducing payroll corrections for hourly employees.
Original PR description
**Steps to reproduce:** 1. Create a draft Swiss ELM payslip for an hourly-paid employee with no automatic hourly work-entry/input 2. In the Wages tab, manually update the `Factor` (`rate`) field of the `Hourly Salary` line 3. Save the payslip **Issue:** The manually entered `Factor` is reset to `0.00` **Cause:** - `l10n_ch_swiss_wage_ids` is a stored computed field without explicit `readonly=False`, causing manual modifications to the line values to be discarded during field recomputation on save. opw-6536243
This fixes Mexican electronic payment complements so tax amounts use the decimal precision required for the payment currency, such as two decimals for MXN. It prevents payment complements from being rejected by certified providers like Quadrum and keeps reported tax totals consistent with SAT validation rules.
Original PR description
The 'ImpuestosP' node of the payment complement (Pagos 2.0) is reported with 6 decimals while the SAT expects the amounts to be expressed with the number of decimals supported by the currency of the payment ('MonedaP'), as published in the 'c_Moneda' catalog, for example 2 decimals for MXN.
Steps to reproduce:
- Have an MX Company setup with Quadrum as PAC.
- Create and sign a customer invoice in MXN with a 16% IVA tax.
- Register a full payment and send the payment complement to the PAC.
Issue:
Payment will be rejected
```
Code : CRPER654
Message : El importe del campo BaseP que corresponde a Traslado, no tiene la cantidad de decimales que soporta la moneda (MonedaP)
```
Analysis:
Quadrum recently aligned its validation on that rule and now rejects the document having fields with too much decimals and, currently, fields like BaseP, ImporteP are pinned to 6 decimals.
opw-6561617