Friday, September 12, 2025
6 changes · saas-18.2
Resolved issues and error corrections
Swiss ISO 20022 payment files now place bank clearing numbers in the correct XML structure. This helps prevent payment file validation issues when companies generate batch payments for Swiss vendors.
Original PR description
### Steps to reproduce: - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor…
### Steps to reproduce: - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor bill for a Swiss partner - Pay with "Swiss ISO20022" - Create a batch payment with that payment and validate - In the XML the field `ClrSysMmbId` contains the clearing number, but it should be in a nested field ([src](https://www.mx-message.com/m/pacs-010-001-05/FIDrctDbt/CdtInstr/Cdtr/FinInstnId/ClrSysMmbId)) ### Cause: The code directly inputs the value of `clearing_number` in `ClrSysMmbId`. ### Solution: Add `MmbId` to contain the clearing number. ### Note: The field `MmbId` when alone is supposed to contain the country's payment system prefix and the clearing number. This commit only input the value of the field `clearing_number` in `MmbId`, so it may be invalid, but at least the architecture is valid. See [this link](https://knowledge.xmldation.com/support/iso20022/general_rules/clearing_codes) for the documentation of `ClrSysMmbId`. This [commit](https://github.com/odoo/enterprise/commit/c277ffa81644b79d95e67a70f7170f5f39c30898#diff-568a46f66108a66d58d845c0e1e00b22db21507ac52576f75b83398112ad10f5) implemented the correct way to set up `ClrSysMmbId` for the Swedish localization. To be always valid, we would need to implement this on all localizations. opw-4872507
Payments for Mexican electronic invoices could fail validation when invoices were issued in USD and paid in MXN because exchange-rate rounding was handled inconsistently. This fix aligns the payment calculation with the official rounded value, helping businesses successfully issue payment CFDIs and avoid tax document rejection.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to: - 0.049216958195 for day 1 - 0.053418803419 for day 2 - Create an invoice in USD as follows: - line 1: price_unit 91, quantity 64,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to:
- 0.049216958195 for day 1
- 0.053418803419 for day 2
- Create an invoice in USD as follows:
- line 1: price_unit 91, quantity 64, tax 16%
- Confirm and send CFDI
- Register full payment in MXN
- Send Payment CFDI
Issue: Payment validation will fail with error
Code : CRP20268
Message : El campo BaseP que corresponde a Traslado, no es igual a la suma de
los importes de las bases registrados en los documentos relacionados donde el
impuesto del documento relacionado sea igual al campo ImpuestoP de este elemento
y la TasaOCuotaDR del documento relacionado sea igual al campo TasaOCuotaP de
este elemento.
Message : Valor esperado: 109025.275956 valor reportado: 109025.275862
This occurs because the precision set in https://github.com/odoo/enterprise/commit/e642e4d6d35c79d02c799d12451f3e2d92ab96e9 is high and can lead to failed
verification due to rounding on our side, because we compute BaseP using
the full digits of EquivalenciaDR, but, according to the specs, we
send it rounded to 10 digits.
opw-4750981
Forward-Port-Of: odoo/enterprise#94465
Forward-Port-Of: odoo/enterprise#92768This fixes an access issue in the Approvals app that could prevent selected approvers from approving requests when they did not have the general Approvals user role. It ensures approval workflows continue smoothly for the people specifically asked to approve, reducing process delays.
Original PR description
Follow up on the previous PR odoo/enterprise#92309 , fixing access rights preventing approvers from approving in requests they are requested to approve in case they don't have the group approvals user. Task-4897775 Forward-Port-Of: odoo/enterprise#94316
UPS shipping rate checks now handle orders that include combo products correctly. This prevents valid orders from being blocked when requesting UPS delivery prices, improving checkout and sales order processing reliability.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit 59a79a5bc51 fixed a bug in 8 shipping connectors, preventing the retrieval of the shipping rate if combo products were present, but failed to fix it in `delivery_ups_rest`. Solution -------- Use `_get_invalid_delivery_weight_lines` helper method to check if there are any lines where a weight is expected, but is lacking. opw-4940973 Forward-Port-Of: odoo/enterprise#93737
Moving documents to another folder no longer removes existing member access when those members had previously visited that folder. This prevents accidental loss of access and keeps collaboration permissions consistent.
Original PR description
When moving documents with members to a folder which has been visited by those same members (or some of them) they are removed from those documents access. This is caused by the document.access which has an entry for the members but with a null role. Task-5075196 Forward-Port-Of: odoo/enterprise#94149
Signing fields can no longer be placed on a PDF page before that page is ready, preventing errors during document preparation. Cleanup of temporary page elements was also adjusted to avoid removing items incorrectly during page refreshes.
Original PR description
Fixed an issue where users could drag and drop sign items before the target PDF page was fully loaded, which caused runtime errors. The system now blocks adding new sign items until the target page has finished loading. Also fixed a problem with cleaning up dummy elements: these were sometimes removed incorrectly when the iframe re-rendered the pages, as the cleanup was already handled automatically. task-5065598 Forward-Port-Of: odoo/enterprise#94001