Friday, March 13, 2026
7 changes · 19.0
Enhancements to existing features
This change optimizes the process of generating GST reports by streamlining the database query. Specifically, it removes a complex domain filter that caused performance issues with large datasets, resulting in faster report generation times. This improvement ensures smoother and more efficient report processing.
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#110334
Forward-Port-Of: odoo/enterprise#109795Resolved issues and error corrections
This update fixes an issue where certain salary deductions weren't being properly accounted for in payroll calculations. Specifically, the system now correctly incorporates 'ATTACH_SALARY' rules, ensuring accurate net pay figures for employees. This improves payroll accuracy and compliance.
Original PR description
**Behavior before this commit** Some salary rules (e.g. `ATTACH_SALARY`) were ignored in the NET calculation. **Behavior after this commit** - Four rules are now added to the "Total deductions" line: their sequence and category has been changed. - The sign of these lines has also been switched: an attachment of salary of a positive amount should be added to the amount of total deductions, which is then deducted from the net.  opw-5894647 Forward-Port-Of: odoo/enterprise#110071 Forward-Port-Of: odoo/enterprise#107033
This update resolves an issue where users were unable to correctly set start and end dates simultaneously within the Web Studio design tool. The fix prevents both date fields from being active at the same time, ensuring the date range field functions as intended and avoids invalid field markings. This improves the usability of the Web Studio interface for creating date-based forms and reports.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#108562
This update ensures Odoo invoices sent to the AFIP (Argentina tax authority) comply with their strict requirements for numeric fields like price and quantity. By limiting these values to a maximum of 3 decimal places, we prevent invoice rejections and maintain accurate financial reporting. This change aligns with the AFIP's specifications and ensures consistent data formatting.
Original PR description
… request ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects…
… request ARCA requires numeric fields such as unit price and quantity to have a maximum of 12 integer digits and 6 decimal places. If these fields are sent with more than 6 decimals, AFIP rejects the invoice with errors like: `Code 1814: Campo Cmp.Items.Pro_precio_uni invalido. El valor debe tener 12 enteros y 6 decimales como máximo.` To ensure compliance, values are formatted before sending the request to ARCA. **Precision rationale** ARCA WS documentation mentions 4 decimal places, while the WS error message itself refers to 6 decimals, and in practice the service accepts up to 6 decimals without rejection. In this implementation, we intentionally use 2 decimal places. The reason is consistency with the rest of the monetary amounts in the invoice: line totals, invoice total, taxes, and related amounts are all rounded to 2 decimals, even in cases where the documentation allows higher precision (e.g., 3 decimals). Before the changes in rounding precision, the stable version already rounded values according to line rounding. In real-world accounting scenarios, the vast majority of use cases operate with 2 decimal places. Keeping this behavior ensures consistency across calculations and avoids discrepancies caused by mixed rounding strategies. For a stable release, this was considered the safest and most predictable option, even though the WS technically allows higher precision. Stable version changes are covered in the following commits: https://github.com/odoo/odoo/pull/243987/changes/8a21ec45f9d72a7c80d9c1f8398fe01e298ae775 https://github.com/odoo/odoo/pull/246347/changes/79ceeed707ef274f19a04e741f6cb8ac60c44321 <img width="780" height="435" alt="image" src="https://github.com/user-attachments/assets/9f25a0e8-b9d2-4ad2-bbcf-e988c7f8a4c9" /> [WSFEX - Manual de desarrollador](https://www.afip.gob.ar/ws/WSFEX/WSFEX-Manualparaeldesarrollador.pdf) Forward-Port-Of: odoo/enterprise#106509
This update fixes an issue where equity reports were incorrectly using outdated currency rates for certain accounts. The change reordered a key statement within the report calculation to ensure the correct, most recent rate type ('current') is applied, leading to more accurate financial reporting. This improves the reliability of equity-related financial data.
Original PR description
Due to the order of the CASE statement, `equity_unaffected` accounts used 'historical' rate_type Change the order of the CASE statement. no-task Forward-Port-Of: odoo/enterprise#110112
This update ensures accurate subline total calculations in the barcode picking process. The fix addresses an issue where totals weren't being generated correctly when a specific setting (stock.group_production_lot) was inactive. This setting is now required for proper grouping and total calculation, particularly when using demo data.
Original PR description
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the…
This issue occurs on Single App and Single L10n, without demo data ### Summary This part of the test verifies that the sub line totals are calculated correctly, which from 18.3 requires the stock.group_production_lot setting to be active. Specifically, it validates that the sum accurately reflects the Unit of Measure (UOM) across various packagings. https://github.com/odoo/enterprise/blob/93e3c6f13fbab8d54694648d04908e451f1e97fc/stock_barcode/static/tests/tours/tour_test_barcode_flows_picking.js#L6472-L6498 ### Observation The grouping logic is contingent on the stock.group_production_lot setting. If this setting is inactive, the system fails to group lines, preventing the calculation of the aggregate total. Without the production lot group active, the conditional checks will bypass the grouping process: https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L53 https://github.com/odoo/enterprise/blob/d664e1f97f6e7fa462b4cf1806322a54762c0de4/stock_barcode/static/src/models/barcode_model.js#L224-L225 When the demo data are enabled [the group is implied](https://github.com/odoo/odoo/blob/8a7ca8beac521f41faf79a6022935fdbb605de76/addons/stock/data/stock_demo.xml#L185-L187) ### Impact When stock.group_production_lot is disabled: - Lines remain ungrouped. - The total sum of the grouped line is never generated. - The test fails as it cannot find or validate the expected sub-line totals. This issue originate from the 18.3 forward port of this [commit](https://github.com/odoo/enterprise/commit/84d4b1f144e8a437fe76ec5ef3bc9799cdf993b0) runbot-241109 Forward-Port-Of: odoo/enterprise#108908
This update ensures that quality checks for tracked products only run when a lot or serial number is assigned. Previously, attempts to run checks without this information resulted in an error message, guiding users to correctly set the product's identification. Additionally, the quality check display now intelligently filters checks based on whether any moves have been picked, improving efficiency.
Original PR description
This commit fixes the behavior when the user tries to do quality checks for tracked products without setting their lot/sn on the picking. Before this commit: Nothing happens if the user tries to do quality checks if lots are not set on the tracked products. After this commit: A User Error is raised telling the user to assign lots/sn to the tracked products. Additional improvement: Before this commit, when having quality checks and user click on `Quality Checks` button, all quality checks appear regardless of whether all moves are picked or only some of them are picked. After this commit, clicking on `Quality Checks` button will only show quality checks related to picked move lines if at least one move line is picked, otherwise it will show all quality checks. Task-5730239