Saturday, December 13, 2025
4 changes · saas-18.3
Resolved issues and error corrections
This update optimizes how the loyalty program calculates potential free products. Previously, the system unnecessarily checked all reward products, even after a valid one was found, leading to slower performance. This change improves the speed and efficiency of the loyalty program, particularly when multiple rewards are involved.
Original PR description
Before this commit, the computation of potential free product quantities looped through all reward products even after finding a valid one. This led to unnecessary calculations and performance degradation, especially when multiple reward products were involved. opw-5268991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239442
This update corrects a bug in the l10n_es_edi_tbai module that prevented the correct generation of the `FechaOperacion` field in TBAI XML invoices. Specifically, when the invoice date and delivery date are set to a past date, the `FechaOperacion` was missing. This ensures compliance with Spanish tax regulations.
Original PR description
With l10n_es_tbai: - Create an invoice with an `invoice_date` and `delivery_date` that are the same and earlier than today. - In the generated TBAI XML, `FechaOperacion` is missing. In the TBAI XML, `FechaExpedicionFactura` corresponds to the date on which the XML is generated. `FechaOperacion` corresponds to the `delivery_date` and should appear whenever it differs from the issue date. The TicketBAI specs define `FechaOperacion` as: > “Date on which the transaction was carried out, whenever it differs from the issue date.” So when the invoice date and delivery date are equal but set in the past, `FechaOperacion` is not generated, even though it should be. opw-4477135 opw-4477135 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 Forward-Port-Of: odoo/odoo#239189
This update resolves an issue where exporting batch payments with mixed IBAN and Swedish payment methods (Bankgiro, Plusgiro, BBAN) was generating incorrect XML files. The team reverted a faulty fix and is now focusing solely on generating the necessary zip file, utilizing the correct payment type context.
Original PR description
Here https://github.com/odoo/enterprise/pull/95463, we add the possibility to export
batch payments with mixed IBAN and Bankgiro/Plusgiro/BBAN payments, but this introduced
few bug in the xml format.
The reason is, we were using new custom logics and not the main one. The problem is
the custom logics is wrong, not the main one.
This commit remove most of the custom logics we added and use all the main one.
This has been done by:
1 - Reverting the original commit
2 - Adding only the zip file generation, passing a context key to know if we are
with bban or iban payments.
opw-5181340
Forward-Port-Of: odoo/enterprise#101917
Forward-Port-Of: odoo/enterprise#100014This update resolves issues related to invoice attachments, specifically when using different EDI formats or sending invoices via email and Peppol. Previously, incorrect display and error messages occurred, now attachments function correctly regardless of the invoice format or sending method selected.
Original PR description
[FIX] account{_edi_ubl_cii, _peppol}: Attachment fix
2 scenarios fixed in this commit :
1:
When a user invoice_edi_format is not 'ubl_bis3' the attachment button is not displayed and the key doesn't exists in the invoice_data. This causes traceback when trying to access the key.
2:
When a user send and print an invoice, with 'email' and 'peppol' as sending_methods, warnings will be displayed next to attachments not supported by peppol.
But if the user uncheck 'peppol', warnings will stay while no sending method requires them anymore.
See odoo/odoo#234339
Forward-Port-Of: odoo/odoo#239769
Forward-Port-Of: odoo/odoo#239684