Thursday, October 23, 2025
3 changes · saas-18.2
Resolved issues and error corrections
Payslips now correctly show worked days for employees on fully flexible contracts, even when no fixed working calendar is set. This prevents payroll teams from seeing empty worked-day sections despite valid attendance or planning entries, reducing manual checks and payroll errors.
Original PR description
**Issue:** Payslips show blank worked days for employees with contracts without a `resource_calendar_id` (fully flexible, despite having valid work entries **Cause:** `_get_worked_day_lines()` skips worked day computation if the contract has no calendar https://github.com/odoo/enterprise/blob/1a10e0444fdb71a072262a1f14f0bfc766d109c6/hr_payroll/models/hr_payslip.py#L665-L674 **Steps to Reproduce:** - Assign an employee a fully flexible contract with attendance as work entry source. - Create work entries based on the attendance records of the employee record - Go to employees > contracts > new Payslip Worked Days section is empty, even though attendance shifts are showing up on top. **Fix:** removing the calendar requirement in the main method and adding a fallback calendar in the called utility method **Note:** same issue happens if work entry source of the contract is Planning opw-4931972 Forward-Port-Of: odoo/enterprise#93935
Fixed an issue where tapping an order line in the Point of Sale product screen no longer selected it when the certified EU IoT scale module was installed. This restores normal cashier workflow while keeping the long-press configurator behavior available.
Original PR description
Task: [5163235](https://www.odoo.com/odoo/project/1737/tasks/5163235) --- In the product screen, pressing an orderline was supposed to select this line and a long press was supposed to open the Configurator popup. However, since the feature of the long press, if we install the module `l10n_eu_iot_scale_cert`, pressing an orderline does not select it anymore. This was due to the fact that a `t-ref` was added in the orderline template and that in the `l10n_eu_iot_scale_cert` module, we were overriding this template completely.
The scheduled SAT status check now rotates through older updated Mexican e-invoice documents instead of repeatedly checking the same first batch. This helps ensure posted supplier invoices imported into Odoo continue to be monitored for possible cancellation or status changes on the SAT portal.
Original PR description
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return…
Currently one of the domains returned by the method `_get_update_sat_status_domains` is `[('state', '=', 'invoice_received'), ('move_id.state', '=', 'posted')]`. This domain is used to always return l10n_mx_edi_documents that have been imported from somewhere and whose invoice has been posted. This is because Odoo needs to always checked the value of the originator of an EDI document, in case it has been cancelled from the SAT Portal for instance.
Both `state = 'invoice_received'` and `'move_id.state = 'posted'` are mostly fixed value. The state needs to stay `invoice_received` as Odoo needs to always check the originator document's value. And once an invoice is posted, it's stays as so except in the case of cancellation.
This leads to an issue when the database contains more than 100 documents that are both `invoice_received` and `move_id.state = 'posted'`. In this case, the cron `_fetch_and_update_sat_status` will always process the same 100 documents. Once the limit of 100 is reached, the cron retriggers itself before terminating. Then on the next execution, the search call with the domain coming from `_get_update_sat_status_domain` will return the same 100 documents again.
This commit fixes this issue by ordering the documents in the cron method by `write_date asc`. Even if the SAT value of the documents does not change, the `write_date` should be updated as their is still a write that is triggered via `_update_document_sat_state`. This prevents the cron from always processing the same documents over and over again.
Forward-Port-Of: odoo/enterprise#93205