Wednesday, December 3, 2025
3 changes · saas-18.2
Resolved issues and error corrections
This update significantly speeds up the process of matching bank transactions with sale orders. By optimizing the query, the system now utilizes indexes, resulting in a much faster search time. This improves overall system performance and responsiveness.
Original PR description
Finding a match between the bank transactions and sale orders is currently done via an unoptimized query that is preventing postgres from using any index. This commit removes the unnecessary CTE by simply doing the query directly on the sale_order table. This way we can also use a trigram index on the regex used for matching and postgres will be able to utilize it for faster search. Benchmarks: | Num sale_order | Before | After | | -------------- | ------ | ------ | | 1391909 | 3.88 s | 0.27 s | Ticket [link](https://www.odoo.com/odoo/project.task/5139457) opw-5139457 Forward-Port-Of: odoo/enterprise#100623 Forward-Port-Of: odoo/enterprise#100470
This update resolves an issue where commas in payment memos for BNZ EFT files were causing errors and rejected payments. The fix removes commas from the generated files, ensuring correct formatting and preventing payment failures. This ensures seamless EFT processing for New Zealand customers.
Original PR description
The EFT file format BNZ is exported as a text file. As such, any commas in the field contents will be treated as a new field, resulting in incorrect formatting and a rejected batch file. This…
The EFT file format BNZ is exported as a text file. As such, any commas in the field contents will be treated as a new field, resulting in incorrect formatting and a rejected batch file. This behavior is due to the Odoo community commit [3082d3b](https://github.com/odoo/odoo/commit/3082d3bd0d7a8b45e647c441ba48adcb84a7a070), which partially reversed an improvement to the group payment memo field. - The original behavior was to concatenate the included invoices with spaces (e.g. 'INV/123 INV/124'). - The improvement replaced this with the batch payment reference (e.g. 'BATCH/IN/002'). - The behavior after 3082d3b is to concatenate the included invoices with a space and a comma (e.g. 'INV/123, INV/124' This commit strips the commas from all generated EFT files, instead of further altering the group payment memo field. It also alters existing unit tests to check that commas are removed from payment memo fields. While a fix that changes the memo generation would resolve some issues, this commit ensures that manually added commas will not cause rejected payments. [Ticket link](https://www.odoo.com/odoo/unassigned-tasks/5099220) opw-5099220 Forward-Port-Of: odoo/enterprise#100670 Forward-Port-Of: odoo/enterprise#98613
This update resolves an issue where the POS system incorrectly prevented users from setting invoices to public for Mexican customers without a country or ZIP code. The fix adds the necessary field to the ORM, allowing users to correctly set the invoice to public and preventing a misleading error message. This ensures proper CFDI invoice generation for Mexican sales.
Original PR description
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice…
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer does not have a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.
https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55
The said field is not properly updated because it is a compute field.
Such fields are not transferred to the ORM because of the two following
conditions from the POS: [[1](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206), [2](https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896)]
To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the serialization process.
Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.
Steps to reproduce the initial error:
1. Install the following app and module:
- Point of Sale (`point_of_sale`)
- Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name (no Country/ZIP Code)
- Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.
opw-5171035
Forward-Port-Of: odoo/enterprise#99871