Daily updates from Odoo
Tuesday, July 28, 2026
4 changes · 18.0
Resolved issues and error corrections
This fixes an issue where employees could not defer a new time off request if an earlier deferred absence had already affected the same payroll period. Payroll teams can now correctly carry time off into the next month without being blocked by an incorrect missing work entry message.
Original PR description
# How to reproduce For an employee with full attendances for april and may: - Create payslip for the month of April, Compute Sheet & Confirm - Create a Time off request for that employee ffrom the…
# How to reproduce For an employee with full attendances for april and may: - Create payslip for the month of April, Compute Sheet & Confirm - Create a Time off request for that employee ffrom the 1st of April to the 10th of April, Approve & Validate > Since the April payroll is closed, you need to defer the Time Off - Report to Next Month - Create payslip for the month of May > The deffered time off should be there - Compute Sheet & Confirm - Create a Time off request for that employee for the 3rd of May, Approve & Validate > Again, the May payroll is closed, so you need to defer the Time Off # The issue You cannot defer the time off because "There is no work entries linked to this time off to report" # The cause When deferring a time off, we call `action_report_to_next_month` that will look for work entries generated during the leave period to defer : https://github.com/odoo/enterprise/blob/f93882555864a1f0a2a3e3863780096c78923bfa/hr_payroll_holidays/models/hr_leave.py#L94-L101 The issue is that, since [this commit], we search for work entries that are not leaves and the first deferring we did transformed the work entries at the start of may into leaves. [this commit]: https://github.com/odoo/enterprise/commit/13ce65b8ca61f9a825f2876e2727cddfae83f894 opw-6318809
Changing a payslip to a type that does not use worked day lines now correctly clears old worked day information, avoiding misleading payroll data. Belgian payroll reporting was also adjusted so off-cycle payslips without worked days are still counted correctly for remuneration reporting.
Original PR description
hr_payroll: Previously, changing to a structure with `use_worked_day_lines = False` (e.g., 13th month) caused `valid_slips` to be empty and return early, leaving stale worked day lines on the payslip. This commit resets the worked_days_lines before filtering for valid payslips. l10n_be_hr_payroll: After fixing the payroll bug and clearing worked_days_lines correctly, the DMFA report fails to correctly consider remunerations since the off-cycle payslips do not have worked_days_lines anymore. This commit backports a fix from odoo/enterprise#106689 to not skip remunerations for payslips with no worked days lines. task-6401942
This fix prevents payroll salary rule account settings from being reset when installing other apps such as Point of Sale. Businesses that customized payroll accounting, especially in Swiss localization setups, keep their manual configuration intact instead of having it overwritten by default values.
Original PR description
### Steps to reproduce: - In a database with Switzerland localization, install 'Accounting' and 'Payroll' - Manually change the debit and credit accounts on the Swiss ELM salary rules (rule code…
### Steps to reproduce: - In a database with Switzerland localization, install 'Accounting' and 'Payroll' - Manually change the debit and credit accounts on the Swiss ELM salary rules (rule code 1000) - Install 'POS' - Check the accounts you configured on the salary rules >The accounts are reset to their default values ### Cause of Issue: POS depends on the module `stock_account`. When `stock_account` is installed, the `_configure_journals` method in its `__init__.py` creates a new `account.journal` for inventory valuation. To apply default values to this journal, the method retrieves data from the chart template. https://github.com/odoo/odoo/blob/7d16ef88784e18e885b97dbded3231775f1349d2/addons/stock_account/__init__.py#L41 The `hr_payroll_account` module overrides `_post_load_data` and unconditionally calls `_load_payroll_accounts(template_code, company)`. https://github.com/odoo/enterprise/blob/fcf06997a0eb999af86e4b6917311a86f04a390e/hr_payroll_account/models/account_chart_template.py#L16-L18 This triggers the reinstallation of the default payroll accounts, which overwrites and discards any manual configuration changes the user has made to their salary rules. ### Fix: Ensure that default payroll accounts are only reset during a genuine chart of accounts loading process, and not during localized post-load operations triggered by other modules. opw-6251112
This fix prevents manufacturing orders from disappearing from the shop floor or barcode workflows when required lot numbers for manually consumed components are missing or newly scanned. Users can now see the validation issue and correct it instead of losing access to the order after an error.
Original PR description
For an MO with component tracked by lot is possible to close it without assigning the lot number even when they are marked for manual consumption. From the shopfloor this will close the MO that will…
For an MO with component tracked by lot is possible to close it without assigning the lot number even when they are marked for manual consumption. From the shopfloor this will close the MO that will disappear when it's gone it will throw a user error, without the MO reappearing. Steps to reproduce --------------------------- **Issue 1** 1) Create a product "final" 2) Create a product "component" tracked by lot 3) Update the on hand quantity and don't assign a lot number 4) Create a BoM for "final" with "component" as component and manual consumption 5) Create a MO and confirm it 6) Go to shopfloor 7) Set "final" quantity 8) Set "component" quantity 10) Close the MO -> The MO disappear (leaving a user error) -> Since the "component" does not have a lot number it should not disappear **Issue 2** Same steps as Issue 1 until step 6: 6*) Add "comp" as barcode to the product component 7*) Go to barcode 8*) Open the manufacturing order 9*) Add the quantity to final 10*) Scan "comp" 11*) Scan a non-existent lot number, ex: "12345" -> It raise the error Observation ---------------------- **Issue 1** When clicking on "Closing production" it will call [onClickValidateButton](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L481-L482)() that will lead us to validate, and validate will [call](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L511) the function [pre_button_mark_done](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L507) in python. in pre_button_mark_done, we will skip any check on the lot number, since we already have set qty_producing (when setting "final" quantity), it will avoid _set_quantities where a check for lot number is made: https://github.com/odoo/odoo/blob/9218d302b0fd56c1854d95d3756c0f5e9c9c8700/addons/mrp/models/mrp_production.py#L2235-L2239 https://github.com/odoo/odoo/blob/9218d302b0fd56c1854d95d3756c0f5e9c9c8700/addons/mrp/models/mrp_production.py#L2839-L2844 And it will also skip the consumption wizard since it doesn't check for lot number nor allow to set lot numbers: https://github.com/odoo/odoo/blob/35f804995118e6ffe150c9c7a7bad4844bd0e0ed/addons/mrp/models/mrp_production.py#L1658-L1660 After avoiding both checks we go back to validate. In validate and we update the variable underValidation which will [trigger the fadeout animation](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L154) When the [animation ends](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L662-L665), the call to realValidation will be triggered and will call productionValidation that will send a call to [button_mark_done](https://github.com/odoo/enterprise/blob/37b21f93828fae2caec87cfd8413e144751eefc0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L551) In button_mark_done, when calling _action_done on the move_lines, we will finally check that there is a lot number, which will trigger an error : https://github.com/odoo/odoo/blob/35f804995118e6ffe150c9c7a7bad4844bd0e0ed/addons/stock/models/stock_move_line.py#L664-L669 but because the fadeout animation is already over, the mo will have disappeared, which means we can't correct the userError that has been raised. **Issue 2** In barcode when scanning a lot after a product, it will not create a lot but only apply a lot_name : https://github.com/odoo/enterprise/blob/7b57a2927aeb8abf84d0f6acc64a7e9bbc8f608d/stock_barcode/static/src/models/barcode_model.js#L1306-L1311 this cause an issue with the existing condition since it only pass the check if there is a lot, but in this case there only is a lot_name. When we click on "Produce" in a Mo in barcode, it will call validate, that in this case, will call button_mark_done: https://github.com/odoo/enterprise/blob/80aaa507fd2196b90cea724ecab0fa0ed5f13db6/stock_barcode/static/src/components/main.xml#L163 https://github.com/odoo/enterprise/blob/80aaa507fd2196b90cea724ecab0fa0ed5f13db6/stock_barcode/static/src/models/barcode_model.js#L602-L605 https://github.com/odoo/enterprise/blob/80aaa507fd2196b90cea724ecab0fa0ed5f13db6/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L14 opw-6060310