Daily updates from Odoo
Friday, December 12, 2025
11 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 ensures that a 'partner ID' is always set when processing SEPA payments. Previously, a missing partner ID could cause errors, preventing the creation of batch payments. This change improves the stability and reliability of our payment processing system.
Original PR description
When doing a payment with SEPA as the payment method, and then create a batch payment out of it. It could happen that the partner_id of the payment was not set. That would cause a traceback because in the _get_CdtTrfTxInf we do a browse on the partner to use it later on. But since the partner is False, we have an empty record set. task-5213880 Forward-Port-Of: odoo/enterprise#98249
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#100014This update resolves a limitation preventing non-administrator users from utilizing the delivery_usps_rest module. By implementing sudo() calls, the module now grants necessary access to the USPS Rest API, expanding functionality without requiring elevated user permissions. This improves usability for a wider range of users.
Original PR description
Non-admin users are currently unable to use the delivery_usps_rest module because several fields are limited to the "base.group_system" group. It's obviously not feasible to give everyone the "Role / Administrator" role. This PR makes necessary sudo() calls the same way that delivery_ups_rest does. Forward-Port-Of: odoo/enterprise#101163
This update fixes a potential error that could prevent invoices from being confirmed when specific currency and pricing settings are used. The fix adds a check to ensure invoice amounts are non-zero before currency calculations, preventing a division-by-zero error. This ensures smoother invoice processing and avoids disruptions to financial transactions.
Original PR description
Steps to reproduce: -------------------- 1. Install l10n_cl and switch to the CL company 2. Create a new invoice: - Change the currency to a value different from the company currency (e.g., from CLP to USD) - Add an invoice line with a price value of 0 - Remove the default tax value 3. Try to confirm the invoice Issue: ------ A traceback occurs: `ZeroDivisionError: float division by zero` Cause: ------ Since the price value is 0, the `amount_total` of the move becomes 0. When computing the currency rate, it tries to divides by `amount_total`, resulting in a ZeroDivisionError. Solution: --------- Add a conditional check before division to ensure the `amount_total` is non-zero Related community PR: https://github.com/odoo/odoo/pull/235252 opw-5247058 Forward-Port-Of: odoo/enterprise#101587 Forward-Port-Of: odoo/enterprise#99518
This update resolves an issue where long text inputs within the Odoo Web Studio application would overflow, causing display problems. Now, long text is automatically truncated, ensuring a clean and usable interface for users. This improves the overall stability and user experience of the Web Studio module.
Original PR description
**Before this commit:** Long input text overflowed and was not truncated. **After this commit:** Long input text is now properly truncated, preventing overflow. task-5240113 Forward-Port-Of: odoo/enterprise#99535
This update fixes an issue where internal transfers using barcode scanning wouldn't correctly assign a result package when the package already contained items. The fix ensures that all packages, regardless of content, can be assigned as the result package during internal transfers, improving the efficiency of inventory management.
Original PR description
Issue ===== When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work. How to reproduce ================ 1. Enable…
Issue ===== When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work. How to reproduce ================ 1. Enable "Packages" and "Storage Locations" settings; 2. Create two packages with some content in WH/Stock/Shelf 1; 3. Create an empty package; 4. Create an internal transfer directly from the Barcode app; 5. Scan Shelf 1 barcode and scan first package; 6. Scan the empty package => It's assigned as the result package; 7. Confirm the operation; 8. Create another internal transfer; 9. Scan Shelf 1 barcode and scan second package; 10. Scan the no more empty package => This time, it's not assigned as the result package. Reason ====== A package was assigned as the result package only if one of the following conditions is matched: 1. The scanned package is empty (it's what's happening in 6.); 2. The selected line has no result package yet and the scanned package is in the selected line's destination location. Here, it doesn't work because since we move a package, the barcode line has already a destination package (the same then the source package.) Fix === For the condition 2., adapt the condition to make it works too if the selected line has the same package as the source and result package. [opw-5326234](https://www.odoo.com/odoo/project/49/tasks/5326234) Forward-Port-Of: odoo/enterprise#101853 Forward-Port-Of: odoo/enterprise#101357
This update removes messages indicating the POS system's certification status. Currently, the POS is only certified by the LNE in version 18.0. This change ensures consistent messaging until a higher version with full certification is released.
Original PR description
The POS in only certified by the LNE in version 18.0. Until such time that we receive the certification in a higher version, we will disable the certification status messages. task-5386904
This update prevents HR users from receiving unnecessary reminder emails. Previously, reminders were triggered by time-off requests or public holidays, even if the user didn't need to submit a timesheet. Now, reminders are only sent for active timesheet entries requiring user input, streamlining the process.
Original PR description
**Steps to reproduce:** - Install timesheet_grid_holidays - Create a user with no timesheet access - Create a leave and approve it as a manager - Set up employee reminders in timesheet settings - Run the timesheet reminder scheduled action **Issue:** HR users without timesheet app access or who haven’t submitted timesheets in the past 3 months were still receiving reminder emails. **Cause:** When a time-off is approved or a public holiday is recorded, it generates timesheet entries, which causes reminder emails to be sent incorrectly. **Fix:** Filter out time-off and public holiday entries when sending reminders. Now, reminders are only sent for actual timesheets that require user input. task-5085790 Forward-Port-Of: odoo/enterprise#95450
This update fixes an issue where unscheduled shifts weren't immediately reflected in the Gantt view, requiring a page refresh. The change ensures that shifts are updated in real-time after being unscheduled, improving scheduling accuracy and reducing user frustration. This enhances the overall planning process.
Original PR description
**Steps to reproduce:** Go to planning gantt view. Click on shift. Click on unschedule button on popover. **Issue:** When clicking on Unschedule button on a shift popover, sometimes the shift still appears and again clicking on that it cause missing error occured until the page is refreshed. **Cause:** The record wasn’t updating in the view after a shift was unscheduled, so the unscheduled shift was still showing. **Fix:** Modified the method to reload the model and notify the view immediately after calling action_unschedule, ensuring shifts reflect the latest server state without requiring a manual refresh. task-5075381 Forward-Port-Of: odoo/enterprise#97108