Daily updates from Odoo
Wednesday, February 11, 2026
5 changes · saas-18.2
Resolved issues and error corrections
This update resolves a crash that occurred when using the budget filter in accounting reports. The fix ensures the system handles report configurations without necessary budget columns gracefully, preventing errors and allowing users to create budget filters without disruption. This improves report stability and usability.
Original PR description
**Steps to reproduce:** * In **Accounting**, create a new accounting report. * Set **Root Report** to **Profit and Loss**. * Add a report line with **Figure Type = Percentage**. * set **Computation…
**Steps to reproduce:** * In **Accounting**, create a new accounting report. * Set **Root Report** to **Profit and Loss**. * Add a report line with **Figure Type = Percentage**. * set **Computation Engine = External Value** and **Formula = 0** on report line. * Add a report column with **Figure Type = Monetary**. * Create a menu item for the report. * Open the report and click **Budget**. * Create a new budget filter and click **Create**. **Observed behavior:** * The system crashes with `TypeError: 'NoneType' object is not subscriptable`. * The error occurs while accessing budget column values. **Cause:** * Budget comparison logic assumes required budget columns always exist. * When the report configuration lacks compatible budget columns, internal variables remain unset and are accessed anyway. **Fix:** * Add a safety check to skip budget comparison when required columns are missing. * Prevents the crash and allows budget filters to be created safely. opw-5357339 Forward-Port-Of: odoo/enterprise#104162
This update resolves an issue where branch companies in Guatemala were incorrectly flagged with a 'Missing required field' error when saving settings. The fix ensures the 'Service Provider' field is only required for the main company, streamlining the process for branch office management. This prevents unnecessary disruptions for users.
Original PR description
Currently, saving the General Settings in a branch of a Guatemalan company raises a "Missing required field" error for the 'Service Provider' field (`l10n_gt_edi_service_provider`), even if no…
Currently, saving the General Settings in a branch of a Guatemalan company raises a "Missing required field" error for the 'Service Provider' field (`l10n_gt_edi_service_provider`), even if no changes were made. ### **Steps to reproduce:** 1) Install `l10n_gt_edi` and switch to a GT company. 2) Create a branch of the GT company. 3) In the parent company, go to Accounting Settings, set the Guatemala Localization to 'Demo', and save. 4) Switch to the branch company. 5) Open Accounting Settings and click Save. ### **Observed Behavior:** An error occurs because `l10n_gt_edi_service_provider` is empty but required. ### **Root Cause:** The `l10n_gt_edi_service_provider` field is marked as `required` whenever `country_code == 'GT'` (see[1]). However, the field is hidden in branch companies via the `invisible="not l10n_gt_edi_is_root_company"` domain on the settings block. Because the field is required but empty (and invisible to the user), the form validation fails. [1]- https://github.com/odoo/enterprise/blob/6f3265aad51a264bee754ca239e8a5019487b38c/l10n_gt_edi/views/res_config_settings_views.xml#L19-L22 ### **FIX:** Update the `required` domain to include `l10n_gt_edi_is_root_company`. This ensures the field is only mandatory in the root company where it is actually visible and configurable and also set the `l10n_gt_edi_service_provider` for branch company same as parent company. **opw-5385819** Forward-Port-Of: odoo/enterprise#106323
This update incorporates new statistical trade codes (2026) to comply with European reporting requirements. These codes, sourced from official Belgian statistics, ensure Odoo Enterprise accurately reports international trade data for compliance purposes. This change supports accurate reporting for businesses involved in cross-border transactions.
Original PR description
This commit adds 2026 codes based on https://www.nbb.be/en/statistics/foreign-trade/nomenclature-and-codes opw-5504187 Forward-Port-Of: odoo/enterprise#106896
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