Daily updates from Odoo
Thursday, May 21, 2026
7 changes · 17.0
Resolved issues and error corrections
This update resolves a potential error that occurred when importing bank statements with multiple journals using different currencies. The fix prevents a 'singleton error' by optimizing the process to only retrieve necessary data, improving the reliability of the bank statement import functionality. This ensures accurate financial data processing.
Original PR description
When having multiple journals with the same IBAN, but different currencies, we could have a singleton error if they are not all configured the same (besides the currency). This happens in the cron that fetches new CODAs as we first fetch all CODAs. Then, for each, we have to dispatch it in the right journal. To do so, we rely on `_parse_bank_statement_file` which is called on `self`, which itself calls `_get_coda_final_statements` that triggers the singleton error. However, at this point, we don't care about calling `_get_coda_final_statements` since we only want to retrieve the IBAN and the currency of the CODA, we don't care about the other details. Thus, the solution here is to ignore this call if we don't need it while just retrieveing the necessary info to match a journal before even creating the statements. This commit also backports 324b01de9cbe73f997423de4a02cb78a55c7f339 opw-6106509
This update corrects a technical issue where the FAIA report incorrectly referenced suppliers without matching supplier data. This ensures accurate reporting of financial information for the LU company, aligning with accounting standards. The fix resolves a validation error within the report generation process.
Original PR description
## Steps to reproduce: 1. Install `l10n_lu_reports`, swap to the LU company 2. Look at the partner Azure Interior. 1. They have no open balances on `asset_receivable` or `liability_payable` accounts.…
## Steps to reproduce:
1. Install `l10n_lu_reports`, swap to the LU company
2. Look at the partner Azure Interior.
1. They have no open balances on `asset_receivable` or `liability_payable` accounts.
2. Their `supplier_count` is higher than their `customer_count`.
3. Navigate to Accounting > Reporting > General Ledger.
4. Select the 2026 fiscal year.
5. Select gear > FAIA report.
6. Open the downloaded file. Notice:
1. Azure Interior is listed under /MasterFiles/Customers/Customer.
2. There are no /MasterFiles/Suppliers.
3. Azure Interior's ID (14 in this case) is referenced in a /SupplierID section.
7. Take a gander at the official XSD for LU [1]. The SupplierID must match an element in /MasterFiles/Suppliers.
Video: [2]
## Explanation
This is one of several errors found with the FAIA export. See PR #113316 for more.
It's possible to have a /SupplierID listed on a /Transaction/Line element but not have a /Suppliers/Supplier element that it refers to. This is not valid according to the FAIA report's schema [1].
This happens because /Transaction/Line and /MasterFiles use different criteria to determine if a partner is a Customer or a Supplier.
The element /Transaction/Line [3] determines this from the `partner_vals['type']` value [4]. This value is 'customer' or 'supplier' and is determined by comparing the ResPartner fields `customer_rank` and `supplier_rank`. In case of a tie, the partner is assigned as a 'supplier'.
The element /MasterFiles allows a partner to be both a Customer and a Supplier via `partner_vals['types']` [5]. Partners with an open `asset_receivable` balance at the start or end of the reporting period are listed as Customers [6]. Likewise, partners with an open `liability_payable` balance are listed as Suppliers [7]. If there are no open balances, partners are put in the Customer list by default.
The XSD validation error will not show up in a standard Runbot database because the namespace for the XSD is incorrect. If you manually fix the XSD namespace (`xmlns:doc` instead of `xmlns`) and use xmllint to check a generated XML against the XSD, it will raise the following error.
> No match found for key-sequence ['14'] of keyref 'RefGLTransactionLineSupplier'. Downloads/general_ledger (5).xml fails to validate
[1] https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip. I will note that there are three XSDs. Version A has a different namespace and appears to be more restrictive. The "full" XSD document does not raise these errors.
[2] https://drive.google.com/file/d/1xeULpCcGgZk-kYcCjBTKxcfv4ICYRzaB/view?usp=sharing
[3] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L244-L248
[4] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L299
[5] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L303-L309
[6] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L153
[7] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L173
opw-6107107This update resolves an issue where CFDI (Mexican electronic invoice) documents were being generated with incorrect length limits for key attributes like 'Folio' and 'Serie'. The values were swapped, which caused invalid documents. Importantly, this change does not affect existing valid invoices.
Original PR description
Issue: length limits for attributes `Folio` and `Serie` of the `<cfdi:Comprobante>` elements were swapped, which could result in generation of invalid documents. Solution: swapping the values. This should not affect anything for existing valid documents. task-6046738
This update fixes a memory error that occurred when searching for mail messages due to processing a very large number of records. The change improves performance and stability by processing mail records in smaller batches instead of loading everything into memory at once. This prevents the system from running out of memory and ensures smoother operation.
Original PR description
Memory error occurs due to the large number of data Iterate over mail message records using fetchmany() to process records in chunks instead of loading everything in memory. **PDB ouptput:** ``` >…
Memory error occurs due to the large number of data
Iterate over mail message records using fetchmany() to process
records in chunks instead of loading everything in memory.
**PDB ouptput:**
```
> /home/odoo/src/odoo/saas-19.1/addons/mail/models/mail_message.py(394)_search()
-> for id_, model, res_id, author_id, message_type, partner_id in self.env.cr.fetchall():
(Pdb) len(model_ids[model][res_id])
196421
```
**Traceback:**
```python
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 1256, in to_sql
return self._compute_sql_related(model, table)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields.py", line 739, in _compute_sql_related
sql = sql[fname]
~~~^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/query.py", line 371, in __getitem__
return self._field.property_to_sql(self, name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 477, in property_to_sql
cotable = self.join(field_sql._table)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/fields_relational.py", line 555, in join
coquery = comodel._search(Domain.TRUE, active_test=False)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/addons/mail/models/mail_message.py", line 401, in _search
model_ids[model][res_id].add(id_)
MemoryError
```
- OPW: 5933342
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where new tax settings for the Brazilian localization (l10n_br) were inadvertently overwriting existing customer configurations. The change ensures that only new tax records are created, safeguarding customer customizations and maintaining existing setups. This prevents disruptions to businesses using the l10n_br module.
Original PR description
Previously https://github.com/odoo/odoo/commit/9d965abb992d558ea4235ef5f87a7654c6f1ceae, new taxes, tax groups, and accounts for the l10n_br localization were loaded using try_loading. This caused existing customer configurations and customizations to be overwritten. This commit ensures that only newly introduced records are created, preserving all existing records and customer modifications. - OPW: 5917478 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error occurring when sending purchase bills with agricultural tax (ClaveRegimenIvaOpTrascendencia) through the TicketBAI system in Spain. The issue stemmed from an incorrect value being submitted, preventing proper invoice processing. This fix ensures accurate transmission of these bills.
Original PR description
…hase bills **STEP TO REPRODUCE** 1. Create a bill with a invoice line with a regimen agricultura tax. 2. send the bill using TicketBAI. 3. You will get the following error: Error:cvc-enumeration-valid: Value '19' is not facet-valid with respect to enumeration '[01, 02, 03, 04, 05, 06, 07, 08, 09, 12, 13]'. It must be a value from the enumeration. opw-6200686
This change reverts a recent update that allowed branch companies to be used as payment providers. The original assumption was incorrect, and enforcing this restriction could disrupt payment processing for existing Odoo databases. This ensures continued stability and functionality for all users.
Original PR description
The commit db1ec126386799932d5845a01ab3e890898bc770 is done under wrong assumption that it's not possible to set journal on branch companies. While currently it is possible to set a journal, hence payment provider in branch companies, even though it's not the preferred setup by accounting. Having that, applying such a restriction on stable might break the payment flow for the databases with such a setup. Therefore, it's better to revert it to prevent such a potential breaking issue. opw-6013978