Invoices are sent after the transaction commits
When a portal payment creates and sends invoices, email and government EDI now go out after commit. A rollback can no longer leave a government-registered invoice that no longer exists in Odoo.
When a portal payment creates and sends invoices, email and government EDI now go out after commit. A rollback can no longer leave a government-registered invoice that no longer exists in Odoo.
| Branch | Pull request | Commit |
|---|---|---|
| 19.0 | odoo/odoo#236532 ↗ | 478f06a4fb ↗ |
| 20.0 | odoo/odoo#292145 ↗ | cf48e0a8df ↗ |
[IMP] account: send invoices in postcommit When a payment transaction creates invoices and then sends them, by email and through EDI to the government, a single concurrent update can make the whole process fail at once. This mostly happens when the customer pays through the portal, as the invoice is then created from the payment. Sending to the government is the dangerous part: invoice 01 can be sent to the government (e.g. with l10n_in_edi) and then the whole transaction gets rolled back, so the invoice does not even exist in Odoo anymore. The numbering on the government side and in Odoo then no longer match. To avoid that, the invoices are now only sent once the transaction that created them is committed, in a new cursor. Since the invoices are locked while being sent, the result of the sending is always recorded in Odoo. The invoices that cannot be sent after the commit (locked by another transaction, or failing) keep their `sending_data` and are processed later by the sending cron. A dedicated method is added in account and used in sale and sale_loyalty instead of `_generate_and_send_invoices`, because the latter returns the generated attachments, which the wizard uses to inform the user directly, and a postponed call cannot return anything. The sending cron now also uses the result of `try_lock_for_update`, so that it only processes the invoices it could actually lock. opw-5029676