Daily updates from Odoo
Wednesday, February 11, 2026
2 changes · saas-18.2
Resolved issues and error corrections
This update resolves a bug where incorrect order quantities were sometimes sent to the kitchen when using the numpad in the POS. The fix ensures the system waits for quantity updates before submitting orders, preventing errors that caused test failures. This improves order accuracy and reliability for restaurant operations.
Original PR description
TASK: [#5897381](https://www.odoo.com/odoo/project/1737/tasks/5897381) --- Inside tour tests environment for POS Restaurant Preparation Display module, when using the numpad to change the quantity of a product in the POS and sending the order to the kitchen immediately after, there is a chance that the quantity is not updated in time. This could lead to sending an order with an incorrect quantity to the kitchen display. As a result, the test `test_payment_does_not_cancel_display_orders` was failing. We are waiting for the orderline to be updated with the correct quantity before submitting the order. X-original-commit: 5ebd1ca99dddbbc62aff90202491562114c0c0dc
This update resolves an issue where reports for Peruvian VAT returns were occasionally failing due to inconsistent data selection. The fix ensures the reports always pick the correct data by sorting purchase and sales order IDs, making the process predictable and reliable. This improves the accuracy of financial reporting for our Peruvian clients.
Original PR description
Occasionally the test_kardex_report test fails: ``` Traceback (most recent call last): File "/data/build/enterprise/l10n_pe_reports_stock/tests/test_ple_kardex_report.py", line 126, in…
Occasionally the test_kardex_report test fails:
```
Traceback (most recent call last):
File "/data/build/enterprise/l10n_pe_reports_stock/tests/test_ple_kardex_report.py", line 126, in test_kardex_report
self.assertSequenceEqual(
AssertionError: Sequences differ: ['M1|[18 chars]|1||02/01/2024|01|FBILL202401|0002|02|product_[313 chars], ''] != ['M1|[18 chars]|1||01/01/2024|01|FBILL202401|0001|02|product_[313 chars], '']
First differing element 0:
'M1|0[17 chars]|1||02/01/2024|01|FBILL202401|0002|02|product_[21 chars]0|1|'
'M1|0[17 chars]|1||01/01/2024|01|FBILL202401|0001|02|product_[21 chars]0|1|'
- ['M1|0000|1|99|FURN9999|1||02/01/2024|01|FBILL202401|0002|02|product_order_no|NIU|3.00|0.00|1|',
? ^ ^
+ ['M1|0000|1|99|FURN9999|1||01/01/2024|01|FBILL202401|0001|02|product_order_no|NIU|3.00|0.00|1|',
? ^ ^
```
The issue was reproducible locally by disabling nested loop joins: `self.env.cr.execute("SET LOCAL enable_nestloop = off")` to nudge Postgres to use a different join strategy.
The test creates a PO that is picked and invoiced in two steps (first quantity 3, then the remaining 2). As a result, the `stock.valuation.layer` ends up being linked to two `account.move.line`s because the join goes through the same `purchase_order_line`. So it will appear twice in the `_get_ple_reports_data()` query. A `DISTINCT
ON (stock_valuation_layer.id)` was already there with the goal of picking one of them. Which one depends on the order, but it's not deterministic: the valuation layer's `id`, `product_id`, and `create_date` will all be the same.
This commit makes the behavior deterministic by sorting on PO line and SO line ids.
runbot-error-238888
Forward-Port-Of: odoo/enterprise#107047