Monday, February 16, 2026
4 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 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 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