Daily updates from Odoo
Sunday, October 5, 2025
4 changes · saas-18.4
Resolved issues and error corrections
Fixed an issue that caused an error when Italian users opened Tax Returns after switching the interface language to Italian. The Submit button is now identified reliably regardless of translation, improving access to Italian tax return workflows.
Original PR description
Steps: - Install 'l10n_it_xml_export' and switch to an Italian company - Install the Italian language - In Accouting Dashboard, configure the Tax Returns - Open the Tax Returns - Make sure you have a button 'Submit', review something if necessary - Switch the language to Italian - Traceback The xpath uses `text()` to select the element but the text in views is translated so the xpath does not work in all languages except English. We remove the check on text, `@name='action_submit'` should be enough. Ticket [link](https://www.odoo.com/odoo/project.task/5106966) opw-5106966 Forward-Port-Of: odoo/enterprise#96096
Romanian SAF-T reports now keep partner details even when their balance is zero, helping reports pass required customer/supplier identity checks. The update also avoids exporting empty general ledger lines while retaining the source document information and improves report processing efficiency.
Original PR description
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0”…
We need to know for each partner if it is a customer or a supplier, even more for Romania[^1] where it is enfored and validated. > 1. If the element SD.P.22 CustomerID is reported with value ”0” (zero), then the element SD.P.23 SupplierID must be different from ”0” (zero), meaning the identity of the partner from which the purchase was made (conventionally considered ”supplier”) is reported. Else if SD.P.22 CustomerID AND SD.P.23 SupplierID are concomitantly equal to ”0” (zero), then is return a semantic validation error. (CustomerID and SupplierID can not be concomitantly 0 (zero)) In order to fix this, we don't use the Partner Ledger anymore to query the balance per partner because it is removing the partners with 0 balance automatically. To keep it simple, we query manually and locally, allowing to reduce the number of queries from 3 to 1 for that part. For the performance, the `|=` operator done in a loop has also been removed, keeping the time complexity in `O(n)` instead of `O(n²)`. opw-5122910 [^1]: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/saf_t Forward-Port-Of: odoo/enterprise#96317 Forward-Port-Of: odoo/enterprise#95804
Mexican electronic invoices no longer replace a missing invoice date with the current Mexico City date when posted. This avoids mismatches between invoice and due dates and makes invoice behavior more predictable.
Original PR description
At the moment, when an invoice that uses a CFDI is posted, the invoice date (if not already existing) is set to the current date in the Mexico City timezone. This default behaviour is just weird, and even if there might have been technical reasons for it in the past, these are no longer valid. This can also cause the default invoice date to be different from the default due date, which causes unexpected behaviour in tests. We therefore remove this override. runbot-233041 Forward-Port-Of: odoo/enterprise#96303
The mail app now correctly recognizes incoming emails from existing contacts when resetting prior bounce flags. This helps prevent contacts from remaining incorrectly marked as bouncing and avoids related discussion access issues when replying by email.
Original PR description
Incoming bounce email linked to a partner in the db is incrementing (in `message_receive_bounce`) the message_bounce value during the handling of the bounces (in `_routing_handle_bounce`) If later, an email linked to a partner existing in the db (and having a message_bounce > 0) is received (and not bounce). The `_routing_reset_bounce` is called to reset the message_bounce. However, prior to this fix, due to not normalizing the `email_from` contained in the `msg_dict`, well, the record having this value was never found and thus, not reset to 0. In 4935208, some of the user were unlinked for mail.discuss.channel when replying to one of the received email. opw-4935208 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229889 Forward-Port-Of: odoo/odoo#227273