Friday, December 12, 2025
3 changes · saas-18.2
Resolved issues and error corrections
This update fixes an issue where the EDI status for Brazilian e-invoices didn't accurately reflect cancellation requests. The change ensures the status is correctly set to 'Cancelled' after a cancellation is processed, improving the accuracy of EDI tracking and compliance with Brazilian regulations.
Original PR description
**Steps to reproduce:** * Install the **Accounting** and **l10n_br_edi** modules. * Create and post a Brazilian customer invoice using an **Avatax fiscal position** * [Guide to setup EDI for…
**Steps to reproduce:** * Install the **Accounting** and **l10n_br_edi** modules. * Create and post a Brazilian customer invoice using an **Avatax fiscal position** * [Guide to setup EDI for l10n_br](https://docs.google.com/document/d/1CSUKpnyhty5WBqUDBE-7dGvu0qxaC5vQ0loz0fYNg04/edit?tab=t.0) * Confirm the invoice and **send it to e-invoice (Brazil)**. * Confirm the **Brazil E-Invoice Status** shows **'Accepted'**. * Click **Request Cancellation**, enter a cancellation reason, and submit the request. **Observed behavior:** * The invoice moves to **Cancelled** state. * The cancellation XML is generated and attached in the chatter. * SEFAZ returns a successful cancellation response. * However, the **BR EDI Status** becomes **empty**, instead of reflecting **'Cancelled'**. **Cause:** * In the wizard `l10n_br_edi.invoice.update`, both `_finalize_update()` and `_submit_services()` assign `l10n_br_last_edi_status = 'cancelled'` **before** calling `button_cancel()`. * `button_cancel()` internally triggers `button_draft()` for posted invoices. * The Brazil EDI override of `button_draft()` resets `l10n_br_last_edi_status = False`. * This clears the status that was just set, leaving the field blank. **Fix:** * move `l10n_br_last_edi_status = "cancelled"` to `button_cancel()` method. opw-5378542 Forward-Port-Of: odoo/enterprise#101438
This update fixes an issue where the Partena export file incorrectly included the company code of the active company when generating exports for inactive companies. The change ensures the correct Partena code is used by referencing the specific company record instead of the active company, improving data accuracy for payroll reporting.
Original PR description
### Issue: In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file. ### Steps to reproduce: - Install…
### Issue: In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file. ### Steps to reproduce: - Install 'l10n_be_hr_payroll_partena' and switch to a Belgian company - Make sure the company has a "Partena Affiliation Number" - Create an employee for this company, with a "Partena code" - Create a contract for this employee, set it a running - Create a new Belgian company with a different "Partena Affiliation Number" - Activate both Belgian companies, but set the second one as active - Payroll > Reporting > Export work entries to Partena - Create a new one, populate it with the employee just created - Click "Generate Export File" ### Cause: When getting the data for the CSV file, we use `self.env.company` which is the active company. So when this company is not the one of the export record, we input the wrong code values. ### Solution: Use `self.company_id` instead of `self.env.company_id`. Also adds the test class with basic tests. opw-5345786 Forward-Port-Of: odoo/enterprise#101110
This update resolves an issue where exporting batch payments with mixed payment types (IBAN, Bankgiro, etc.) was generating incorrect XML files. The team reverted a faulty fix and now focuses solely on generating the necessary zip file, ensuring accurate XML formatting for Swedish payment exports. This improves the reliability of the payment processing workflow.
Original PR description
Here https://github.com/odoo/enterprise/pull/95463, we add the possibility to export
batch payments with mixed IBAN and Bankgiro/Plusgiro/BBAN payments, but this introduced
few bug in the xml format.
The reason is, we were using new custom logics and not the main one. The problem is
the custom logics is wrong, not the main one.
This commit remove most of the custom logics we added and use all the main one.
This has been done by:
1 - Reverting the original commit
2 - Adding only the zip file generation, passing a context key to know if we are
with bban or iban payments.
opw-5181340
Forward-Port-Of: odoo/enterprise#100014