Tuesday, June 9, 2026
5 changes · 17.0
Resolved issues and error corrections
This update resolves a technical issue preventing users from confirming DHL deliveries when the scheduled date was missing or in the past. The system now automatically sets the delivery date to one hour in the future, eliminating the error and ensuring successful order confirmation.
Original PR description
When confirming the delivery of an order using DHL shipping method we get an error that the date must be in the future. This happens when the scheduled date was not set, or set for a time in the past. This commit automatically sets the time to 1 hour in the future and bypasses the user error. opw-6148927
This update resolves a technical issue that caused the restaurant order tour to fail. The fix ensures the system waits for order requests to fully complete before proceeding, preventing duplicate requests and improving the reliability of the test. This ensures a smoother experience for users placing restaurant orders.
Original PR description
The tour could fail because `sendOrderInPreparationUpdateLastChange` is asynchronous when sending the order to the kitchen. The test was continuing to the next steps before the request was fully resolved, which could lead to sending the order again while the previous call was still in progress. This commit updates the tour to explicitly wait for the async call to complete before continuing, by adding a delay step after clicking the order button. This prevents race conditions during the test. --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/181846
This update corrects a bug in the journal report that prevented accurate display of tax grids when multiple countries were selected. Previously, the report layout was broken, and country options were missing when using more than two tax countries. This ensures accurate reporting across various international business scenarios.
Original PR description
When more than 2 country are used in the taxes, the colspan of the header is wrong. When more than 2 country are used in tax grids, the country isn't displayed anymore.
This update resolves an issue where SEPA QR codes were occasionally displaying incorrect decimal places due to floating-point calculations in Odoo. The fix ensures the QR code amount accurately reflects the currency's precision, improving payment accuracy and preventing potential errors during scanning. This impacts vendor bill payments.
Original PR description
**Description of the issue/feature this PR addresses:** When generating a SEPA QR code for a vendor bill payment, the embedded amount could occasionally contain excess decimal places instead of…
**Description of the issue/feature this PR addresses:** When generating a SEPA QR code for a vendor bill payment, the embedded amount could occasionally contain excess decimal places instead of respecting the currency's expected precision. This occurs because the `amount` variable in `_get_qr_vals` was being converted directly using `str(amount)`. Due to Python's floating-point arithmetic, the float value in memory can contain decimal drift. Directly casting it to a string exposes this drift in the payload. This commit resolves the issue by replacing `str(amount)` with `float_repr(amount, currency.decimal_places)`. This safely bypasses the float representation issue, ensuring the string strictly respects the currency's configured decimal precision before being injected into the QR code. opw-5504258 **Steps to reproduce:** - Select company “My Belgian Company” - Create a 23% purchase tax - Create vendor bill - Select Vendor “BE Company CoA” - Choose any single product, change price to 37.18 and choose the 23% tax. The Untaxed Amount should be 37.18, VAT tax should be 8.55, and Total should be 45.73 - Confirm > Register Payment > scan QR code. EUR45.730000000000004 should show **Current behavior before PR:** - When generating a SEPA QR code for a payment, the embedded amount can contain excess decimal places due to floating-point drift. **Desired behavior after PR is merged:** - The SEPA QR code is generated with the correct number of decimal places.
This update fixes an issue where refunding a partially paid Point of Sale order resulted in incorrect total and line amounts being displayed. The fix ensures that refund calculations accurately reflect the original order's items, preventing financial discrepancies. This improves the reliability of the PoS refund process.
Original PR description
When refunding an order that has already been partially refunded, the line amount and total amount where incorrect. They would be the total amount of the original order. Steps to reproduce: ------------------- * Open PoS and make an order with 3 quantity of a product. * Close the session * In the backend, refund 1 quantity of the order and validate the refund * Refund again the same order with the 2 remaining quantities > Observation: The total amount and line amount are not correct opw-6215019