Sunday, October 5, 2025
2 changes · saas-18.4
Resolved issues and error corrections
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
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