Daily updates from Odoo
Monday, February 16, 2026
131 changes
4 changes
Resolved issues and error corrections
This update fixes an issue where the Employer File Number field was hidden in the payroll settings after installing the l10n_hk_hr_payroll module. The fix removes the setting that previously obscured this important data, ensuring users can now correctly input and view this required information.
Original PR description
Issue: - Employer File Number was hidden in Payroll settings after installing the l10n_hk_hr_payroll_empf module. Fix: - Removed the setting that hid the Employer File Number field. task-5476454 Forward-Port-Of: odoo/enterprise#103987
This update resolves several issues impacting the accuracy of Single Touch Payroll reporting in Australia, specifically related to opening balances and year-to-date calculations. The changes include rounding monetary amounts to the correct currency precision and correcting date discrepancies, ensuring compliance and reliable financial data.
Original PR description
- Unable to import opening balances when zeroed out. This should not require Previous Payroll and BMS IDs - Float creates an overflow while computing the YTD sums, which results in too many digits in decimal places. Round all monetary amounts reported to the rounding precision of the currency. - Issues with run date and submit dates for the prior fiscal year. - Fix payslips computation on update actions post finalisation Task - 5685790 Forward-Port-Of: odoo/enterprise#105952
This update fixes a misleading error message displayed when validating Argentine electronic invoices (ARCA). The message has been corrected to accurately reflect the requirement that the invoice date cannot be before the last validated invoice, preventing incorrect invoice processing. This ensures compliance with AFIP regulations.
Original PR description
WSFE error 10016-1 must be "The invoice date cannot be before the last invoice validated in AFIP." instead of "The invoice date cannot be after the last invoice validated in AFIP". Steps to reproduce: validate argentinean customer electronic invoice with invoice date before than the last invoice date validated in ARCA. Task Adhoc side: 44290 Task latam: 1376 Forward-Port-Of: odoo/enterprise#106687 Forward-Port-Of: odoo/enterprise#106305
This update fixes an issue where the activity menu in web_studio was incorrectly displaying all records for custom models, rather than just those with activities assigned to the current user. Now, the activity menu accurately filters records to show only those with associated activities, 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#107277 Forward-Port-Of: odoo/enterprise#106622
2 changes
Resolved issues and error corrections
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
1 change
Resolved issues and error corrections
This update resolves a technical error that prevented users from removing a date filter on the Booking Kanban view in the POS module. The fix ensures the Kanban view functions correctly, allowing users to efficiently manage their bookings. This improves the overall user experience and prevents potential data management issues.
Original PR description
Steps: - Install pos_appointment. - Open a POS session with bookings configured. - Open the Booking tab and click Remove date filter in the header. Issue: - A traceback occurs with `Invalid handler`. Cause: - The Remove date filter button’s onclick handler was not defined. Fix: - Define a valid onclick handler for the Remove date filter button. Task-5902656
9 changes
Resolved issues and error corrections
This update resolves a previous limitation where commission and achievement data for completed sales plans couldn't be displayed in reports. Now, sales reports accurately reflect performance against achieved goals, providing a more complete view of sales results. This enhancement improves reporting accuracy and supports better sales management decisions.
Original PR description
Before this commit, it was not possilbe to display commission/achievements of done plans. task-5937055
This update fixes a limitation in the payroll schedule wizard that prevented users from selecting resource calendars without a company assigned. The change expands the selection options to include all calendars, regardless of company affiliation, improving flexibility and usability for resource scheduling. This ensures all resources can be correctly assigned to payroll schedules.
Original PR description
Steps to reproduce: 1. Create a resource calendar without any company 2. Open the payroll set schedule wizard 3. The calendar without company is not selectable Bug cause: The domain on `resource_calendar_id` field only filtered for calendars belonging to the current company, excluding calendars with no company set. Solution: Update the domain to include both calendars from the current company AND calendars without any company using an OR condition. Task Id: 5912974
This update enables users to download accounting reports even when errors are detected. Previously, a system error would prevent download attempts. This change supports users who need to manually correct downloaded files, streamlining the report fixing process.
Original PR description
[IMP] account_reports, *: Allow user download invalid file modules: l10n_at_saft, l10n_lu_reports, l10n_ro_saft Before this commit, when a user try to export an accounting report, if an error with the level 'danger' is detected a wizard open and do not allow to download the file (the "Download Anyway" button is disabled). With this commit, the user will be able to download the file in any case. The target is the user that will modify the file manually to correct it. task-5487096
This update resolves an issue where the timesheet's systray label was not displaying correctly. The fix ensures the label accurately reflects the timesheet's status, providing a clearer visual indication for users. This improves the overall user experience and data accuracy.
This update resolves an issue where DMFA export reports were being rejected due to duplicate employee records sharing the same NISS. The fix groups employees with the same NISS and merges their payslips into a single record, ensuring accurate DMFA declarations and preventing errors.
Original PR description
In some real-life situations, multiple employee records can share the same NISS (e.g. a student contract followed by a regular contract after archiving the first employee). When exporting DMFA data, this resulted in multiple NaturalPerson nodes with identical identifiers.
This caused the DMFA declaration to be rejected with error 90017-006 ("Personne physique - Trop d'occurrences avec les mêmes identifiants").
To fix this, employees sharing the same NISS are now grouped in the DMFA export, and their payslips are merged into a single NaturalPerson node.
task-5470180This change prevents automatic transfer validation when quality checks are pending, giving users more control over the picking process. Previously, automatic validation blocked adjustments to quantities or lot numbers needed after failed quality checks. Now, users must manually validate the transfer after all checks are complete, ensuring a more flexible and predictable workflow.
Original PR description
*: stock_barcode_quality_control Before this change, when a picking with pending quality checks was validated, the system opened the quality check wizard. Once all checks were completed, the transfer…
*: stock_barcode_quality_control Before this change, when a picking with pending quality checks was validated, the system opened the quality check wizard. Once all checks were completed, the transfer was automatically validated. This behaviour caused issues in cases where some quality checks failed, as users might need to adjust quantities, correct lot numbers, or handle exceptions before finalising the transfer. Since the transfer was already validated automatically, users lost the opportunity to review or modify the picking. With this commit, validating a picking while some quality checks are still pending no longer triggers automatic validation of the transfer. Users must now explicitly validate the transfer manually after all checks are completed. The Validate button is also made secondary when there are pending quality checks to perform. This makes the validation flow more predictable and gives users better control and flexibility when handling pickings that include quality checks. Task ID: 4898373
This update corrects a recent change that exposed sensitive time-off type information to all users within the time-off overview. The change has been reverted to ensure employee time-off types remain private, maintaining data security and confidentiality.
Original PR description
This commit reverts back the change done to gantt color of time-off overview to be based on time off type instead of employee, which made private information (time off type) available to everyone. Task: 586835
This update fixes an issue where the salary calculator was incorrectly re-encoding values when changing budget types. The system now accurately preserves user input and calculates yearly costs based on the selected budget, ensuring more reliable salary projections. This change improves the accuracy of salary calculations within the applicant and offer stages.
Original PR description
Prevent the salary calculator from re-encoding value when switching budget type; preserving user input. The separate monthly_wage field has been repurposed into salary amount, it is used to calculate final_yearly_cost depending on budget_type. task-5030704
The Pay Run status bubble now correctly reflects the status of payroll processing. Previously, it incorrectly showed a green status even when no payslips had been generated. This update ensures the bubble remains grey until payslips are created, providing a more accurate visual representation of the payroll process.
Original PR description
Previously, the Pay Run status bubble appeared green even with 0 payslips. This commit updates the `StatusBubble` component to check `payslip_count`. The current stage bubble will now remain grey (`bg-secondary`) until payslips are generated, only turning green (`bg-success`) when `payslip_count > 0`. - JS: Added `payslip_count` to field dependencies. - XML: Updated class conditions to respect payslip count.
8 changes
Resolved issues and error corrections
This update corrects a bug in the salary configuration where changing a bank account would create duplicate entries, leading to incorrect allocation percentages. The fix now completely replaces existing bank accounts with the new one, ensuring accurate payroll processing. This resolves a potential issue with payments being misdirected.
Original PR description
When changing a bank account in the salary configurator, the system was adding the new bank account to the employee's existing bank accounts list, ending up having multiple bank accounts where the first retained 100% allocation and subsequent ones had 0% allocation. The fix replaces all existing bank accounts with only the new one. task-5905542
This update fixes an inaccurate count of employees with invalid bank account warnings displayed in the payroll dashboard. The issue stemmed from how multiple employee versions were handled, leading to a discrepancy in the reported warning records. The fix ensures a more precise count of employees with invalid bank accounts.
Original PR description
> note: to be r+'ed till `master` (`saas~19.2`) because the way we compute warning has been changed in `master` description: - `warning_count` for `hr_payroll_dashboard_warning_employee_invalid_bank_account` is wrong when there are multiple versions for a single employee. steps to reproduce: - install `hr_payroll_account_iso20022` - open Payroll (note: have atleast one employee with multiple versions) - find "Employees With Invalid IBAN Bank Accounts" warning on the dashboard - note the count and click on it, the record count differs fix: - returned unique employee ids from `_get_invalid_iban_employee_ids` - also optimized the query in `_get_account_holder_employees_data` method. reasoning: we do not need bank account data from all the versions, because all the versions share same bank account data. task-5407494
This update corrects a technical issue where the contract template was being unnecessarily created during salary configuration. This prevented certain calculations from running correctly. The fix ensures the template data is now correctly handled, improving the reliability of the HR contract process.
Original PR description
Writing the contract template on the new version created by the salary configurator is not necessary and caused some computes to not trigger. The contract template values are already included in the `_get_version` method. task-5324222
This update resolves a problem where the CDI - Experienced Developer (BE) contract template wouldn't save correctly. The issue was caused by an incorrectly checked inventory car field. This change removes the check, allowing users to successfully save the template.
Original PR description
Before this commit, when the CDI - Experienced Developer (BE) contract template is loaded, the inventory car is checked, but no car is selected, so you can't save. This commits unchecks the inventory car on the template to avoid this issue. Task: 5892344
This update removes the 'New' button from the DIMONA Declaration List view in the odoo/enterprise module. This simplifies the process for users to create DIMONA declarations, reducing potential confusion and improving usability. This change ensures the system operates as intended and aligns with best practices for user interface design.
Original PR description
. Remove the New button on DIMONA Declaration List view task-5471873
This update fixes an issue where the month displayed on global invoices linked to POS orders was incorrectly reflecting the creation date of the invoice, rather than the order date. This ensures accurate reporting and compliance with Mexican tax regulations, specifically for EDI POS invoices.
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
This update adjusts the calculation of sickness relapse periods for Belgian payroll, aligning with a new tax regulation effective January 1, 2026. The relapse period between sick leaves has been increased from 14 to 56 days, ensuring accurate payroll processing according to Belgian tax law. This change was implemented with new tests and data types to support the updated calculation.
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 leave work_entry type where work_entry use date_start . Add corresponding tests task-5476174 Forward-Port-Of: odoo/enterprise#104782
This update resolves an issue preventing the WhatsApp sign migration process from completing due to manually deleted template records. By adjusting how Odoo handles missing templates, the migration now proceeds smoothly, avoiding a critical upgrade block. This ensures consistent and reliable WhatsApp sign functionality.
Original PR description
Issue: ------ The database migration was blocked during the `config_parameter` [loading](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/config_parameter_whatsapp_template.xml#L6)…
Issue:
------
The database migration was blocked during the `config_parameter` [loading](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/config_parameter_whatsapp_template.xml#L6) phase. This occurred because several `ir.config_parameter` records used `ref()` to point to [whatsapp templates](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml) that were manually deleted in the production environment.
ValueError is raised:
```py
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: whatsapp_sign.sign_request_whatsapp_template
```
Cause:
-------
Since these whatsapp templates are defined with [`forcecreate="0"`](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml#L3), Odoo does not recreate them automatically during migration. This left the External IDs (IMD) pointing to non-existent records, causing a `ValueError: External ID not found in the system` that blocked the migration.
Solution:
-----------
Updated the `ref()` calls in the XML for these configuration parameters to include `raise_if_not_found=False`. This allows the registry to initialize successfully by returning None instead of crashing if a template is missing.
tgb: [2448](https://upgrade.odoo.com/odoo/tbg/2448?debug=1)
upg: [3895200](https://upgrade.odoo.com/odoo/upgrade.request/3895200?debug=1)
opw: [5931388](https://www.odoo.com/odoo/project/70/tasks/5931388?debug=1)4 changes
Resolved issues and error corrections
This update resolves an issue where archived employees were still visible in the attendance Gantt view. The change ensures that only currently active employees appear, improving data accuracy and presentation. This prevents confusion and outdated information from being displayed.
Original PR description
Steps to reproduce: 1. install `hr_attendance_gantt` 2. create an employee 3. make attendance records for the employee in the previous months 4. archive the employee When opening the gantt view of the attendance, a row appears for the archived employee, with no attendance showing up. This commit adds a constraint to only show the active employees. opw-5490119
This update clarifies the visibility of specific fields within the Belgian payroll and fleet modules. Previously, generic fields were consolidated across all countries, but this change restores the original design, keeping BE-specific fiscal logic contained within the l10n_be_hr_payroll_fleet module. This ensures accurate reporting and compliance for Belgian businesses.
Original PR description
This branch only hides BE-specific fields in l10n_be_hr_payroll_fleet (they remain defined/used there and are invisible for non‑BE companies). On master (19.3) those generic fields (can_be_requested, default_car_value) were refactored into hr_payroll_fleet so payroll+fleet consumers across all countries can use them; BE fiscal logic stays in l10n_be_hr_payroll_fleet task-5906656
This update enhances the accuracy of payment reference checks by tailoring validation to the bank account's country. Previously, a single check applied to all countries could lead to incorrect validations. Now, the system verifies the reference format against the specific country of the bank account, with a fallback for unsupported countries, ensuring more reliable payment processing.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269
This update corrects a bug where autofilling pivot cells with incorrect relational IDs caused a crash. The fix ensures that autofill functionality continues to work while preventing tooltips from triggering a system error. This improves the stability and usability of the pivot table feature.
Original PR description
If you try to autofill a pivot cell that has an invalid relational id in its domain (eg. `=PIVOT.HEADER(1, "stage_id", 99999999)`), the autofill actually works but the tooltip make everything crash. Task: [5913754](https://www.odoo.com/web#id=5913754&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#106601
3 changes
Resolved issues and error corrections
This update resolves an issue preventing payroll users from accessing the 'One-time payments' feature within Swiss company configurations. The fix allows payroll officers and managers to correctly open and manage these payments, ensuring proper reporting and compliance. The issue stemmed from restricted access to action records, which has now been addressed through a secure internal bypass.
Original PR description
Steps to reproduce: ------------------- 1. Install l10n_ch_hr_payroll_elm_transmission. 2. Switch to a Swiss company and create a new employee. 3. Create a new internal user with Payroll…
Steps to reproduce: ------------------- 1. Install l10n_ch_hr_payroll_elm_transmission. 2. Switch to a Swiss company and create a new employee. 3. Create a new internal user with Payroll Officer/Manager access. 4. Log in as that user, create a contract, and click on "One-time payments". Issue: --------- A Traceback with AccessError: ```You are not allowed to access 'Action Window' (ir.actions.act_window) records.``` Cause: ---------- https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/l10n_ch_hr_payroll_elm_transmission/models/hr_contract.py#L195 The code attempts to call `.read()` on an `ir.actions.act_window` record. Standard users typically do not have read access to window action records, resulting in an **AccessError** even if they have rights to the payroll data. Solution: ------------- Use [_for_xml_id](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L187) to return action content for the provided xml id in a safe way by doing [sudo](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L205) internally to bypass the access restriction. opw-5491467
This update fixes an issue where the 'Journal Items' view in the general ledger didn't correctly display journal information when a journal was selected as a filter. Now, when viewing journal items within the general ledger, both the invoice and the associated journal entry are accurately displayed. The update also includes support for multiple journals, though a refresh is required.
Original PR description
When opening the general ledger, if a journal was selected in the filter of the report, when clicking on "Journal Items" it would open the list view of account.move.lines without the journal in the filter. Also, the support for multiples journals is added but will require a -u of account to refresh the view. To reproduce: - Create an invoice on an Account such as Product Sales - Create a journal entry on the same account - Open the general ledger - Select "Customer Invoices" and click on "Journal Items" on the Account you choose. You can see both the move lines from the invoice and the journal entry.
This update corrects a discrepancy in payslip calculations for the private car daily allowance. The daily amount is now rounded to two decimal places, ensuring it precisely matches the 'Quantity × Amount' displayed on payslips. This improves payroll accuracy and reporting.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569