Monday, February 16, 2026
9 changes · saas-18.4
Resolved issues and error corrections
This update resolves an error that occurred when users attempted to edit reconciled bank statement lines. The fix initializes necessary variables to prevent a runtime error, ensuring the bank reconciliation process functions correctly. This improves stability and prevents data inconsistencies.
Original PR description
Currently, an error occurs when user edits a reconciled line. **Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):** - Install the `Accounting`…
Currently, an error occurs when user edits a reconciled line. **Steps to Reproduce([Video](https://drive.google.com/file/d/18dSAsZCl---wfCkMBfyo9LviTqgq3qpK/view)):** - Install the `Accounting` module. - Create an `invoice` with an `invoice line` having an amount greater than zero. - `Confirm` the invoice. - Go to the `Bank journal` and create a `statement line` with the same amount as the invoice. - Click `Reconcile` on that `statement line` and select the newly `created invoice line`. - Click the `pencil icon` to edit the line, enter a `positive amount` in the Balance field, and save. `UnboundLocalError: local variable 'original_base_lines' referenced before assignment` The error occurs because, when a specific condition [1] becomes true, the variables original_base_lines and original_tax_lines are expected to be defined. However, if reconciled_lines_ids is present in move_line_to_edit, these variables are never initialized and are later referenced, causing the UnboundLocalError [2]. This commit ensures that original_base_lines and original_tax_lines are initialized to None, which prevents the error. [1]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1393-L1394 [2]- https://github.com/odoo/enterprise/blob/fa4bbc20f25ec12c609ebbf37885e48900619de5/account_accountant/models/account_bank_statement.py#L1410-L1411 sentry-7189027839 Forward-Port-Of: odoo/enterprise#104432
This update fixes an issue where the activity menu in web_studio was incorrectly displaying all records for custom models, rather than just those associated with the current user. Now, clicking the activity menu will only show records with activities assigned to the user, improving the user experience and data accuracy.
Original PR description
After commit odoo/odoo@5c5fbc10b7024c7227f03e37897d421bba64df82 , actions spawned by the activities menu have their domain managed by dynamic <filter /> rather than a plain readonly domain. Before this commit, clicking on the activity menu to go to a custom model showed every record, not just ones with activities after this commit, only records with activities assigned to the current user are showed opw-5778806 Forward-Port-Of: odoo/enterprise#106622
This update adjusts the calculation of sickness relapse periods for the Belgian payroll module (l10n_be_hr_payroll). Starting January 1, 2026, the allowed relapse period between sick leaves will increase from 14 to 56 days, aligning with new Belgian tax regulations. This change ensures accurate payroll processing for employees in Belgium.
Original PR description
**Spec :-** Since 01/01/2026, the period between two sick time off to consider it as a relapse has been increased from 14 days to 56 days. **Implementation :-** . Update sickness relapse period from 14 to 56 days if the leave starts from 2026 . Add corresponding tests task-5476174 Forward-Port-Of: odoo/enterprise#104769
This update ensures that the preparation display in the backend accurately reflects changes when a POS order is cancelled or deleted. Specifically, related preparation orders and data are now properly removed, maintaining data consistency and a more accurate view of order history.
Original PR description
**In this commit:** Ensure the preparation display UI is updated when a POS order is cancelled or deleted from the backend. - On order cancellation, the preparation display is refreshed accordingly. - On order deletion, related preparation orders, lines, and states are removed via notify call. Task-5373116 Related: https://github.com/odoo/odoo/pull/240523
This update resolves an issue where Employee Officers were experiencing access errors when editing employee records. By restricting access to salary offer information to HR Managers, the system now prevents unauthorized data access and ensures data security. This allows Employee Officers to continue their work without interruption.
Original PR description
Before: - Editing an employee form as an Employee Officer triggered an AccessError due to mail tracking attempting to read salary_offer_ids on hr.version. After: - salary_offer_ids is now restricted to HR Managers, preventing unauthorized reads during tracking when saving the employee form. Impact: - Employee Officers can edit employee records without encountering access errors. - Access to salary offers remains limited to appropriate managerial roles. Task: 5404676
This update corrects a critical issue in Australian payroll calculations by ensuring tax rules use the correct employee version (historical data) instead of current employee information. This prevents inaccuracies when generating payslips for past periods, particularly with changes to employee tax settings, and guarantees accurate withholding and deductions.
Original PR description
Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields…
Since the introduction of the employee versioning system, using `employee.field_name` in salary rules is no longer accurate for computations involving historical or specific periods. Accessing fields directly on the `employee` record returns the current values. This creates an issue when a future version exists. For example, if a new version is created for February 2026 with an updated Child Support amount, generating a delayed payslip for January 2026 would incorrectly use the February value (current state) instead of the January value (historical state). This commit updates the Python compute logic in the Australian salary rules to use `version.field_name` instead of `employee.field_name`. The `version` object ensures the data used corresponds strictly to the payslip's period. The following rules/fields are updated to use the version object: - Tax Treatment Category - Additional Withholding Amount - Extra Pay - TFN Declaration - Medicare (Reduction, Exemption, and Levy) - Training Loans - NAT 3093 Amount (Tax Offset) - Child Support (Garnishee and Deduction) A test case is added to verify that a payslip correctly retrieves the child support amount from the version valid during the payslip period, ignoring future updates. Task-5002697
This update resolves a minor issue related to the calculation of scale certificates for European VAT compliance. It synchronizes a key checksum value following a recent fix in the main Odoo project. This ensures accurate reporting and adherence to regulatory requirements.
Original PR description
This commit simply updates the expected scale checksum after the fix in the community PR odoo/odoo#248413. Forward-Port-Of: odoo/enterprise#107445 Forward-Port-Of: odoo/enterprise#107241
This update fixes a technical issue where the system was creating multiple, empty pay runs when generating payslips through the selection dialog. The fix ensures that only one temporary pay run is created per dialog attempt, preventing unnecessary database entries and improving system efficiency. This resolves a potential data inconsistency issue.
Original PR description
When generating payslips from the selection dialog the UI previously created a new hr.payslip.run on every attempt; server-side validation can fail and each failed attempt left an empty pay run in the database. Fixed by allowing the dialog to create at most one temporary pay run per dialog lifecycle, reuses it on retries, and removes it if generation fails or the dialog is closed. task-5920710
This update fixes an issue where Mexican POS invoices incorrectly displayed the invoice creation month instead of the order date month. This ensures accurate reporting and compliance with Mexican tax regulations for global invoices generated from POS orders. The fix corrects the 'Meses' attribute in the generated XML.
Original PR description
**PROBLEM** In accounting, if you create a global invoice with an invoice, the attribute `Meses` will be the month of the invoice date. In POS, if you do the same with an order, the attribute `Meses` will be equal to the month the day we create the global invoice, instead of the month of the order date. This is wrong. **STEP TO REPRODUCE** 1. Have an order from the month before (not sure how to do this on a runbot). 2. Create a global invoice. 3. Check the generated xml, and notice the month is wrong. opw-5381607 Forward-Port-Of: odoo/enterprise#107362 Forward-Port-Of: odoo/enterprise#106856