Monday, March 2, 2026
17 changes · 19.0
Resolved issues and error corrections
This update fixes an error in the Spanish Profit & Loss reports where specific accounts (7950 and 7957) were incorrectly placed in the wrong section. The change aligns with official Spanish tax documentation, ensuring accurate reporting for non-SME fiscal localization packages. This ensures compliance with Spanish tax regulations.
Original PR description
In the Profit & Loss reports, accounts 7950 and 7957 were incorrectly shown in section 10 instead of section 6 These accounts appear only for non-SME fiscal localization packages According to the official Spanish tax documentation, these accounts should belong to section 6 and not section 10: https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884 opw-5363664 Forward-Port-Of: odoo/enterprise#108820 Forward-Port-Of: odoo/enterprise#107949
This update fixes an issue where newly hired employees were incorrectly receiving their private email address as their work email. The change ensures that the employee's work email is properly cleared when the contract is signed, preventing data duplication and maintaining accurate employee records. This improves data consistency and reporting.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#108933 Forward-Port-Of: odoo/enterprise#106974
This update prevents users from canceling subscriptions if they don't have access to the associated invoices. Previously, a sales representative could cancel a subscription even if invoices were outstanding but not visible to them. Now, the system requires invoice visibility before allowing cancellation, ensuring accurate subscription management.
Original PR description
Before this commit, when a user had access to an invoiced subscription but not to the invoiced, he could cancel the subscription. Step to reproduce: - create a subscription in company A, with a pricelist available in company B. Sales person A belong to company A. - invoice the subscription and confirm the invoice - update the company (company B) and sales person of the subscription (B). The new salesperon don't see the invoice in the stat button. After this commit salesperson B can't cancel the subscription. task-5907345 Forward-Port-Of: odoo/enterprise#108321 Forward-Port-Of: odoo/enterprise#106441
This update resolves an issue where users weren't receiving clear guidance when attempting to process after-departure payments. Now, the system displays a helpful error message, requiring a previous payslip for these payments. This ensures accurate payroll processing and avoids technical errors.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607 Forward-Port-Of: odoo/enterprise#108980 Forward-Port-Of: odoo/enterprise#107386
This update resolves a minor issue within the Urban Piper settings where the arrow button was not functioning correctly. The fix ensures that the arrow is properly embedded within a button element, allowing users to navigate to the correct settings. This improves usability and prevents a potential frustration for users.
Original PR description
In the settings, under the Urban Piper section, the arrow was not clickable. This is because the arrow was not inside a button tag. task: 5972833
This update fixes an error that occurred when no tax type was selected in Argentinian reports (like ARBA profits). The change ensures the report functions correctly even without a tax type filter, preventing a JavaScript error. This ensures accurate reporting for Argentinian businesses.
Original PR description
Task Adhoc side: 56583 Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report.…
Task Adhoc side: 56583 Avoid js error when no tax type is selected in the argentinian report filter, when the report selected is different than vat book report, for example: ARBA profits report. Video showing the error: https://drive.google.com/file/d/1ecPOqL8DSp45rCT2QIATwYb0DB0RT_YP/view The error was this one: Odoo Client Error UncaughtPromiseError > OwlError Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property) Occured on 19.odoo.localhost on 2025-11-25 12:03:32 GMT OwlError: An error occured in the owl lifecycle (see this Error's "cause" property) Error: An error occured in the owl lifecycle (see this Error's "cause" property) at handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:762:101) at App.handleError (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1420:29) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:787:19) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29) Caused by: TypeError: Cannot convert undefined or null to object at Object.keys (<anonymous>) at get selectedTaxType (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:23629:758) at L10nARTaxReportFilters.slot3 (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:36:30) at callSlot (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:956:25) at Dropdown.template (eval at compile (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:1375:421), <anonymous>:8:12) at node.renderFn (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:905:207) at Fiber._render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:786:96) at Fiber.render (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:785:6) at ComponentNode.updateAndRender (http://19.odoo.localhost/web/assets/d2fb943/web.assets_web.min.js:875:29)
This update simplifies the salary simulation process by hiding temporary offers from the user interface. These offers are automatically removed after a month by a scheduled task, so this change prevents confusion and a cleaner experience for users. It ensures the backend calculations continue to function correctly.
Original PR description
The salary simulator creates temporary offers to compute salary configurations. These offers must still exist for backend computations, as the configurator relies on them when updating results. Simulation offers are already cleaned up by a cron job after one month, so this change simply hides them from the list view to avoid user confusion. task: 5498873
This update fixes an issue with invoices generated for SII (Chile's tax authority) by ensuring the correct XML tags are used for withholding information. The change updates the DTE template to align with SII's specific formatting requirements, preventing invoice rejection. This ensures compliance with Chilean tax regulations.
Original PR description
Link to SII API Documentation: https://www.sii.cl/factura_electronica/formato_dte.pdf Problem: The DTE template was using incorrect XML elements for withholdings when confirming an invoice with SII. This fix replaces: ImptRetOtrMnda -> ImpRetOtrMnda ValorImpOtrMnda -> VlrImpOtrMnda so the generated DTE matches SII specifications. OPW-5437484 Forward-Port-Of: odoo/enterprise#105152
This update fixes a problem where archived employee appraisal dates persisted, causing conflicts when updating appraisal plans. The change ensures archived employees no longer appear in appraisal calculations, preventing date errors and improving the accuracy of appraisal settings. This ensures a smoother experience for managing appraisals across the company.
Original PR description
**Steps to reproduce:** Based on this feedback https://www.odoo.com/odoo/project.task/5270281 companies with archived employees face an issue when they try to toggle Appraisals Plans from Appraisls -> Configuration -> Settings -> Appraisals Plans **Issue:** The propblem is that when employees with next appraisal date are archived, their next appraisal date is not cleared which leads to past date conflicts upon trying to set the next appraisals dates for all the employees (which is done through toggling the Appraisals Plans checkbox) **Solution:** - Unset the next appraisal date upon archiving an employee - exclude archived employees from _compute_next_appraisal_date method Task: 5354002 Forward-Port-Of: odoo/enterprise#108990 Forward-Port-Of: odoo/enterprise#100437
This update ensures the cash drawer opens automatically when the cash details popup is accessed in the Italian Point of Sale (POS) system. Previously, this functionality was missing, causing a discrepancy between the fiscal printer and cash drawer behavior. This fix provides consistent cash drawer operation for Italian users.
Original PR description
When opening the cash details popup the cash drawer should be opened. It was not the case for the Italian fiscal printer. Steps to reproduce: ------------------- * Setup a Italian fiscal printer with cash drawer support * Open PoS * Open the cash details popup > Observation: The cash drawer does not open * Try to close the PoS session * Open the cash details popup > Observation: The cash drawer opens Why the fix: ------------ The cash drawer opening function was simply not called opw-5391094 Forward-Port-Of: odoo/enterprise#109057 Forward-Port-Of: odoo/enterprise#107987
This update reverts a recent change to the name of the "Create Draft Entry" button on payslips to "Validate". This change ensures consistency and clarity for users when finalizing payroll processing, improving the overall user experience.
Original PR description
This commit reverts the payslip validation button name from "Create Draft Entry" back to "Validate". TaskID-5964329
This update introduces a new ‘Net Cost’ salary rule in the UAE payroll module to accurately track employer costs. Previously, a setting caused deductions to incorrectly reduce both employee and employer contributions. This change ensures employer costs are calculated correctly, improving financial reporting and compliance.
Original PR description
## Before: - Setting appears_on_employee_cost_dashboard to True on a salary rule uses the rule’s sign to compute employee cost. - For rules like Social Insurance Employee Contribution and DEWS Employee Contribution, the sign must be negative to deduct the amount from the employee, which incorrectly reduces the employer cost as well. ## After: - Introduced a new salary rule “Net Cost” to correctly reflect employer cost. - This allows employee contribution rules to keep a negative sign for deductions while still increasing the employer contribution amount. Task-5912761
This update fixes a technical issue preventing payruns from being created correctly for employees using the Hong Kong localization. The problem stemmed from a missing function name within the HK localization setup, which caused an error during payrun generation. This fix ensures payruns function as expected for all employees, regardless of their location.
Original PR description
In the big commit adding eMPF to the hk localization, a function was miss named and was causing an error when trying to create a payrun. Steps to reproduce: - Install belgian localization - Install HK localization - Select the belgian company - Create a payslip for a belgian employee (works fine) - Create a payrun and select the same employee from the list - Get an error In this commit we fix the naming of the function and everything goes back to working. Task: 5960503
This update resolves an issue where the 'Reset Selected Work Entries' button in the work entry Gantt view would fail when no employees were selected. The fix prevents a key error and ensures the button functions correctly, improving usability. The change addresses a technical bug identified through monitoring and testing.
Original PR description
This error occurs when clicking the `Reset Selected Work Entries` button while there are no employees in the work entries. Steps to reproduce: - Install `hr_payroll` module - Payroll > Work Entry >…
This error occurs when clicking the `Reset Selected Work Entries` button while there are no employees in the work entries. Steps to reproduce: - Install `hr_payroll` module - Payroll > Work Entry > Remove `Active` Filter - Select any cell and click on the reset button Traceback: `KeyError: 'employee_id'` This error occurs when the `Reset Selected Work Entries` button is clicked without an employee, causing `employee_id` to be missing at [1]. Solutions: - Raise a validation error when no employee is selected and the `Reset Selected Work Entries` button is clicked. - Fix the error that occurs when clicking the `Set` button to add or replace a work entry. - Fix the error that occurs when the `Active` filter is enabled and the `Reset` button is clicked. ``` Missing Record Record does not exist or has been deleted. (Record: hr.employee(2,), User: 2) ``` [1]: https://github.com/odoo/odoo/blob/4949a6272691c781d5ab5a8b06f88f58d5cea4df/addons/hr_work_entry/wizard/hr_work_entry_regeneration_wizard.py#L116 sentry-7140947833
This update ensures the 'Request Signature' menu item consistently appears on form views when a chatter is present. Previously, the system wasn't reliably checking for chatter, leading to the menu item sometimes being missing. This change improves the user experience by guaranteeing the signature option is available when needed.
Original PR description
****Behavior:**** **Current:** When selecting the cog menu on certain forms, the request signature item doesn't always show even though it should. The expected behavior of this menu item is to appear only on form views with a chatter, but the way the chatter's presence was verified is inconsistent. **Solution:** On form views with a chatter, we can check its presence directly from the viewArch using the selector from the compiler registry. **Steps to reproduce:** From Timesheets: - Go to Timesheets - Open a task - The cog menu will not contain "Request Signature" From Project: - Go to Project - Select a project and open a task - The cog menu will contain "Request Signature" opw-4817423 Forward-Port-Of: odoo/enterprise#108169 Forward-Port-Of: odoo/enterprise#97401
This update corrects a technical issue within Odoo's payroll system that could lead to inconsistencies between payslip data. The change ensures that all payroll calculations and reporting remain synchronized, improving the accuracy of employee payments and financial records. This resolves a potential source of error and enhances data reliability.
Original PR description
Forward-Port-Of: odoo/enterprise#108983 Forward-Port-Of: odoo/enterprise#108729
This update resolves an issue where the Colombian Electronic Invoicing module incorrectly processed invoices when the DIAN operation mode didn't match the company settings. The fix now generates a warning, preventing incorrect invoice generation and ensuring compliance. This ensures accurate electronic invoicing for Colombian businesses.
Original PR description
Steps to reproduce: - Install `l10n_co_dian` module(demo data) > Switch to `CO Company` - Settings > Colombian Electronic Invoicing > Change the Operation Mode: `DIAN 2.1: Support Documents`(eg:…
Steps to reproduce:
- Install `l10n_co_dian` module(demo data) > Switch to `CO Company`
- Settings > Colombian Electronic Invoicing > Change the Operation Mode: `DIAN 2.1: Support Documents`(eg: [Image](https://www.awesomescreenshot.com/image/58874464?key=0cb74e446dcdb0f087df6ed619f785c2))
- Vendors > Create a Bill > Confirm > `Acknowledge Reception`
Traceback:
```py
File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_move.py", line 293, in l10n_co_dian_send_event_update_status_received
self._l10n_co_dian_send_event_update_status('received')
File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_move.py", line 313, in _l10n_co_dian_send_event_update_status
document = self.env['l10n_co_dian.document']._send_commercial_event(self, commercial_state_next)
File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/l10n_co_dian_document.py", line 593, in _send_commercial_event
xml, errors = self.env['account.edi.xml.ubl_dian']._export_co_send_event_update_status_invoice(locked_move, commercial_state_next)
File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1208, in _export_co_send_event_update_status_invoice
return self.with_context(l10n_co_next_commercial_state=next_commercial_state)._dian_sign_xml(xml, invoice)
File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1524, in _dian_sign_xml
'software_security_code': self._dian_get_security_code(operation_mode, document_number),
File "/home/odoo/src/enterprise/saas-19.1/l10n_co_dian/models/account_edi_xml_ubl_dian.py", line 1443, in _dian_get_security_code
operation_mode.dian_software_id
TypeError: unsupported operand type(s) for +: 'int' and 'str'
```
We are getting this error because `_dian_get_operation_mode` [returns] an empty `l10n_co_dian.operation_mode()` record. This happens when the `Operation modes` do not match. As a result, [operation_mode] also contains an empty record.
[operation_mode]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1432
[returns]: https://github.com/odoo/enterprise/blob/84022deef3414096fcaf61f8d45c08393431e0ab/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1394-L1400
sentry-7273771732