Friday, September 4, 2026
2 changes · 18.0
Enhancements to existing features
Argentine companies can now choose an invoice PDF legend required by ARCA regulations from accounting settings. The selected legend appears on eligible A and M invoices, while other invoice types and related reports remain unchanged.
Original PR description
Backport to 18.0 of odoo/enterprise#102032. Before: - 18.0 has no legend at all below the Document Type letter on the invoice PDF for documents 'A' and 'M'. After ARCA's new regulation RG 5762/2025,…
Backport to 18.0 of odoo/enterprise#102032. Before: - 18.0 has no legend at all below the Document Type letter on the invoice PDF for documents 'A' and 'M'. After ARCA's new regulation RG 5762/2025, two legend options are needed. After: - Now we have two options for the invoice PDF legend string. 1. 'Payment on Informed CBU.' 2. 'Operation Subject to Withholding.' - The user can set the value of the legend from the accounting settings. Field, compute and setting are kept as close as possible to the master PR so that the 18.0 patch can be dropped once the feature ships upstream. Two things cannot be copied because they do not exist in 18.0: - `l10n_ar.custom_header` has no `span#withholding_legend` to xpath into, so the template extends `//div[@name='center-upper']/span` instead. - The invoice report does not set `document_type_code`, so the condition reads `o.l10n_latam_document_type_id.code`. Since `l10n_ar.custom_header` is shared by reports whose record is not an `account.move` (sale order, delivery slip, payment receipt), the record model is checked first. Test scenarios: 1) Accounting > Settings > Argentinean Localization shows the "Add Legend to Invoice PDF" setting with the "Legend" selection, only for AR companies. 2) With no legend selected, the PDF of an A invoice is unchanged. 3) With "Payment on Informed CBU" selected, the PDF of an A invoice (codes 1/2/3) and of an M invoice (codes 51/52/53) shows the legend below the document letter. 4) The PDF of a B/C invoice shows no legend. 5) Printing a delivery slip, a sale order and a payment receipt of an AR company still works (they share `l10n_ar.custom_header`). Task Adhoc side: 62315
The preparation display now finds relevant POS orders much more efficiently when databases contain large volumes of orders. This reduces waiting time and keeps the screen responsive for businesses with high POS activity.
Original PR description
The preparation display filters its stageless orders by POS configuration. The `pos_config_id` domain is a non-stored related field,so it becomes an `IN (SELECT ...)` query on `pos_order`. On databases with many POS orders, PostgreSQL materializes that complete subquery and rescans it for every preparation-display order. Replace it with a correlated `EXISTS`, allowing the linked POS order to be checked through its primary key instead. #### Speedup Database with 2,114 preparation-display orders. Each value is the average of five calls after invalidating the Odoo ORM cache. POS orders | Before | After (10 runs) -- | -- | -- 5,481 | 148 ms | 6.767 ms (5.334–17.292 ms) 184,904 | 292 ms | 3.680 ms (3.395–4.275 ms) 320,493 | 23.228 s | 4.437 ms (4.187–4.964 ms) 565,685 | 39.950 s | 4.342 ms (3.356–5.258 ms) After the rewrite, execution time is effectively independent of the eligible POS-order cardinality in this dataset. opw-6438446