Thursday, March 12, 2026
4 changes · saas-18.2
Enhancements to existing features
This change optimizes the process of generating GST reports by streamlining the database query. The original query was slow due to a complex sub-query, which has been simplified. This results in faster report generation, particularly when dealing with large volumes of data.
Original PR description
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this ``` SELECT account_move.id FROM account_move WHERE (…
If account.move and account.move.line have big data then domain with create problme ORM create sub query like this
```
SELECT
account_move.id
FROM
account_move
WHERE
(
account_move.l10n_in_gst_return_period_id = 23
OR (
account_move.move_type IN ('in_invoice', 'in_refund')
AND account_move.invoice_date >= '2025-11-01'
AND account_move.invoice_date <= '2025-11-30'
AND account_move.company_id IN (1)
AND account_move.state = 'posted'
AND (
account_move.l10n_in_gst_treatment NOT IN ('composition', 'unregistered', 'consumer')
OR account_move.l10n_in_gst_treatment IS NULL
)
AND account_move.id IN (
SELECT
account_move_line.move_id
FROM
account_move_line
WHERE
EXISTS (
SELECT 1
FROM account_move_line_account_tax_rel AS account_move_line__tax_ids
WHERE account_move_line__tax_ids.account_move_line_id = account_move_line.id
)
)
)
)
ORDER BY
account_move.date DESC,
account_move.name DESC,
account_move.invoice_date DESC,
account_move.id DESC
```
See this EXPLAIN for big database
```
Gather Merge (cost=165759176482.82..2983665158687.50 rows=36 width=30)
Workers Planned: 2
-> Incremental Sort (cost=165759175482.80..2983665157683.32 rows=18 width=30)
Sort Key: account_move.date DESC, account_move.name DESC, account_move.invoice_date DESC, account_move.id DESC
Presorted Key: account_move.date
-> Parallel Index Scan Backward using account_move__date_index on account_move (cost=59.28..2983665157682.51 rows=18 width=30)
Filter: ((l10n_in_gst_return_period_id = 23) OR (((move_type)::text = ANY ('{in_invoice,in_refund}'::text[])) AND (invoice_date >= '2025-11-01'::date) AND (invoice_date <= '2025-11-30'::date) AND (company_id = 1) AND ((state)::text = 'posted'::text) AND (((l10n_in_gst_treatment)::text <> ALL ('{composition,unregistered,consumer}'::text[])) OR (l10n_in_gst_treatment IS NULL)) AND (SubPlan 1)))
SubPlan 1
-> Materialize (cost=58.84..1601427.18 rows=4994548 width=4)
-> Merge Semi Join (cost=58.84..1556944.44 rows=4994548 width=4)
Merge Cond: (account_move_line.id = account_move_line__tax_ids.account_move_line_id)
-> Index Scan using account_move_line_pkey on account_move_line (cost=0.44..1339780.32 rows=26611459 width=8)
-> Index Only Scan using account_move_line_account_tax_rel_pkey on account_move_line_account_tax_rel account_move_line__tax_ids (cost=0.43..88678.65 rows=4994548 width=4)
```
So removing this from domain and put it as condition it's faster
Forward-Port-Of: odoo/enterprise#109795Resolved issues and error corrections
This update corrects a technical issue preventing electronic invoices in the RIMPE Emprendedor regime from being properly processed. The change ensures the correct string value is used for the 'contribuyenteRimpe' tag, resolving a validation error that was causing invoice processing failures. This ensures compliance with SRI regulations and proper invoice submission.
Original PR description
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values:…
Corrected the hardcoded string for the RIMPE Emprendedor regime to match the SRI structure According to SRI technical specifications, the <contribuyenteRimpe> tag only accepts two specific values: CONTRIBUYENTE RÉGIMEN RIMPE (Fixed value) CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE Steps to reproduce: Install l10n_ec_edi module Go to Settings > Invoicing > Ecuadorian Localization In Electronic Invoicing > Regime, select rimpe_emprendedor In Electronic Invoicing > Regime, configure a SRI Connection Post an customer invoice **Validation error occurring during the electronic signing process (using .p12 certificates):** `35 - Se encontró el siguiente error en la estructura del comprobante: cvc-pattern-valid: Value 'CONTRIBUYENTE EMPRENDEDOR - RÉGIMEN RIMPE' is not facet-valid with respect to pattern 'CONTRIBUYENTE RÉGIMEN RIMPE|CONTRIBUYENTE NEGOCIO POPULAR - RÉGIMEN RIMPE' for type 'contribuyenteRimpe'.. - ARCHIVO NO CUMPLE ESTRUCTURA XML - ERROR ` Forward-Port-Of: odoo/enterprise#109147
This update resolves a bug where manufacturing orders created through the barcode app incorrectly used product UoMs instead of the specified BoM UoMs. Previously, this caused inaccurate stock movements. The fix ensures that BoM UoMs are correctly applied, improving the reliability of manufacturing order creation within the barcode app.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196) Forward-Port-Of: odoo/enterprise#108504 Forward-Port-Of: odoo/enterprise#90408
This update fixes an issue where the MPS wasn't accurately reflecting demand for dependent components. Previously, the system defaulted to the oldest BoM, regardless of the user's chosen configuration. This change ensures that component demand is correctly calculated and updated within the MPS, leading to more accurate production planning.
Original PR description
## Issue: When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which…
## Issue:
When computing the product tree, the system would use `_bom_find` to find the BoM. However, it's possible to have multiple BoM for the same product, and the user should have chosen which BoM he wants to use. `_bom_find` ignores the user configuration in MPS, and simply select the first (oldest) BoM in the list. This means that the components in the MPS would not be correctly updated.
---
## How to reproduce:
https://github.com/user-attachments/assets/c7e6f4d4-332a-4e2b-a40a-1b831daeb6c8
- Create Products FNS & CMP
- Create BoM for FNS without bom line (V1)
- Create BoM for FNS with CMP in bom lines (V2)
- Add FNS to MPS using bom V2
- Set Forecast Qty of FNS to 10
- => Indirect Demand Qty for CMP is not shown (because it's 0)
---
## Test Result without fix:
```
2026-03-05 15:00:24,601 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: Starting TestMpsMps.test_indirect_multiple_boms ...
2026-03-05 15:00:24,742 52396 INFO oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: ======================================================================
2026-03-05 15:00:24,742 52396 ERROR oes_test_18.0 odoo.addons.mrp_mps.tests.test_mrp_mps: FAIL: TestMpsMps.test_indirect_multiple_boms
Traceback (most recent call last):
File "/home/odoo/Odoo/src/18.0/enterprise/mrp_mps/tests/test_mrp_mps.py", line 1556, in test_indirect_multiple_boms
self.assertEqual(forecast_cmp['forecast_ids'][0]['indirect_demand_qty'], 10)
AssertionError: 0.0 != 10
```
---
OPW-5979738
Forward-Port-Of: odoo/enterprise#109693