Sunday, August 23, 2026
4 changes · master
Resolved issues and error corrections
Refunded point-of-sale down payments are now handled correctly when a sale order is settled or invoiced. This prevents customers from being invoiced again for an amount that was already refunded, keeping invoice totals and invoiced amounts accurate.
Original PR description
The following commit resets qty_invoiced to zero on sale order lines paid by a POS order when that order is refunded. https://github.com/odoo/odoo/commit/ac39aa4f68dfc77011c39e468e3f60e0338a3c69…
The following commit resets qty_invoiced to zero on sale order lines paid by a POS order when that order is refunded. https://github.com/odoo/odoo/commit/ac39aa4f68dfc77011c39e468e3f60e0338a3c69 However, it does not handle the sale order line created for a refunded POS down payment. That line keeps `qty_invoiced` = -1, which causes the refunded amount to be included again when settling or invoicing the sale order. Steps to reproduce: - Create a sale order. - Pay a down payment through the POS. - Refund the down payment order from the POS. - Settle the remaining amount from the POS or invoice the sale order from the backend. Result: - The generated invoice includes the sale order total plus the refunded down payment. - Sale order `amount_invoiced` will be the down payment amount. Fix: - Delete the refunded downpayment to match the sale flow. - Include refunded down payments in the amount_invoiced computation. opw-6378891 Forward-Port-Of: odoo/odoo#283308 Forward-Port-Of: odoo/odoo#278011
Overtime calculations now avoid counting a shift that ends exactly at midnight as part of the next day. This prevents incorrect overtime adjustments when employees have multiple attendances on the previous day and improves payroll-related accuracy.
Original PR description
When recomputing overtime, attendances overlapping the affected day are retrieved based on their check-in and check-out. An attendance whose check-out is exactly at the start of the following day is…
When recomputing overtime, attendances overlapping the affected day are retrieved based on their check-in and check-out.
An attendance whose check-out is exactly at the start of the following day is currently considered to overlap that day because the domain uses an inclusive lower bound on `check_out`.
This can cause overtime from the previous day to be recomputed using an incomplete set of attendances.
### Steps to reproduce:
* Configure an employee with a daily quantity overtime rule based on the expected hours from the contract.
* On the first day, create multiple attendances, with the last one ending exactly at midnight.
* Ensure the total worked hours on that day result in overtime.
* On the following day, create another attendance.
* Observe that recomputing the second day's overtime also retrieves the attendance ending at midnight.
* The previous day's overtime is then recomputed without the other attendances from that day, resulting in an incorrect overtime value.
* Regenerating the overtime ruleset restores the correct value.
For example, with 8.4 expected hours:
```
Day 1:
09:30 - 11:30
14:30 - 18:19
21:00 - 00:00
Day 2:
create/update an attendance
```
The `21:00 - 00:00` attendance is incorrectly included in Day 2's recomputation because its check-out equals the start of Day 2. The other Day 1 attendances are not included, so Day 1 is recomputed from only 3 hours of work.
To fix the issue we treat `check_out` as an exclusive interval boundary when determining overlap. An attendance ending exactly at the start of a day does not overlap that day, while attendances actually crossing midnight continue to be included.
opw-5474120
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#283894
Forward-Port-Of: odoo/odoo#283226Saudi Arabia POS receipts now embed the ZATCA QR code directly, preventing blank codes on first print from Safari and iPhone browsers. The QR code size was also adjusted so it is easier to scan on printed receipts while keeping the preview appropriately sized.
Original PR description
Fixing the QR code size and Robustness for ZATCA. 1. The QR code is now an embedded image SVG instead of an image fetched from the server, which makes it robust against Webkit quirks. 2. We set the QR size in the preview screen to 200px (back to what it was before https://github.com/odoo/odoo/pull/277813), and we make the QR size on the physical receipt 300px so it's big enough to be scanned easily. More info in the respective commit messages. opw-6399766 Forward-Port-Of: odoo/odoo#282637 Forward-Port-Of: odoo/odoo#282285
Message history now shows tracked date and time changes using the current user's timezone instead of falling back to UTC. The display format is clearer across languages and locations by matching the usual date-time field style and including the timezone.
Original PR description
Although the code was attempting to render the tracking values in the current user's timezone. It did not work. While fixing this, we also wanted to make the time clearer in multi-language/timezone settings: - Date(time) is now formatted in the same way it is for datetime fields in the frontend - The timezone is added after it, so we know exactly what time is meant - Those two fields are reprocessed in the chatter so that we simply show them in the user's locale task-6456370 Forward-Port-Of: odoo/odoo#283819 Forward-Port-Of: odoo/odoo#281769