Wednesday, September 23, 2026
5 changes · saas-19.1
Enhancements to existing features
This update speeds up the setup of Argentine localization report tests by creating sample invoices more directly. It reduces test runtime and database queries while keeping the report results unchanged, helping development and release validation run more efficiently.
Original PR description
The use_current_date=False branch of _create_test_invoices_like_demo built 18 invoices through Form, which reruns the whole move onchange for every field of every line. It was two thirds of the l10n_ar_reports class setup. Create them with _create_invoice from the fields the Form set, like the other branch does. The accounting date is now the invoice date on every invoice, the report output is unchanged. With the l10n_ar_reports counterpart: | l10n_ar_reports, runbot 18.0 L10n | before (3 builds) | after | |------------------------------------|-------------------|-------| | TestArReports setUpClass | 78-103s | 31s | | module test time | 80-106s | 33s | | queries | 45.4k | 28.4k | Forward-Port-Of: odoo/odoo#290111
The Vietnam chart of accounts now includes dedicated accounts for revenue and costs from selling or liquidating investment property. This supports compliance with Circular 99/2025/TT-BTC and helps report these gains or losses separately in Profit & Loss statements.
Original PR description
Circular 99/2025/TT-BTC adds a dedicated Profit & Loss line for gains/losses on the sale and liquidation of investment property, computed from dedicated sub-accounts rather than the main revenue and cost-of-goods-sold accounts. Add the two accounts to the chart of accounts: - 5117 Revenue from sale and liquidation of investment property - 6327 Cost of sale and liquidation of investment property Task-6518304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287572
This update changes how sample vendor bills are prepared for Argentine reports tests, avoiding a slower setup method. It reduces test preparation time and database queries while keeping the report results unchanged.
Original PR description
Same as the l10n_ar fixture: the 10 demo vendor bills were built through Form, rerunning the whole move onchange for every field of every line. Create them with _create_invoice from the fields the Form set. The accounting date is now the invoice date on every bill, the report output is unchanged. With the l10n_ar counterpart: | l10n_ar_reports, runbot 18.0 L10n | before (3 builds) | after | |------------------------------------|-------------------|-------| | TestArReports setUpClass | 78-103s | 31s | | module test time | 80-106s | 33s | | queries | 45.4k | 28.4k | Forward-Port-Of: odoo/enterprise#132697
Point of Sale now calculates customer amounts due in batches instead of one customer at a time. This greatly reduces database load when opening a PoS session, improving responsiveness and reducing the risk of system slowdowns on large databases.
Original PR description
Issue ----- Opening a PoS sends every partner cached on the device to `get_all_total_due`. On a production database, six of those calls within 30 minutes ran 7061 queries, the worst one 4837 queries…
Issue ----- Opening a PoS sends every partner cached on the device to `get_all_total_due`. On a production database, six of those calls within 30 minutes ran 7061 queries, the worst one 4837 queries in 46.7 seconds, keeping a worker busy for the whole duration and slowing down the entire system. Cause ----- `get_all_total_due` loops over the recordset and calls `get_total_due` once per partner. Each iteration runs its own `pos.order` search for the open pay later orders and re-reads `point_of_sale.group_pos_user`, hence exactly two queries per partner. Every other value the method needs (`total_due`, `pos_orders_amount_due`, `invoices_amount_due` and the `_load_pos_data_read` payload) is already computed for the whole recordset at once by the ORM prefetching, so only those two remained unbatched. That search is also the expensive one: `commercial_partner_id` is not indexed, so each of them scans the whole set of orders in state 'paid'. Fix ----- Move the computation to `_get_total_due_data`, which queries the orders, the pay later payments and the partners data once for the whole recordset. `get_total_due` and `get_all_total_due` keep their signature and their return value, and both delegate to it. Measured on a database with 300k pos orders, for 1000 partners: 2193 queries / 3.98s before, 16 queries / 0.27s after. opw-6530561 Forward-Port-Of: odoo/enterprise#130334
Automatic payment reconciliation now matches payment references with invoice names even when uppercase and lowercase letters differ. This reduces manual reconciliation work and helps payments be matched correctly when bank references use different formatting.
Original PR description
Currently, when a payment reference isn't in the same letter case as the invoice name, it wouldn't automatically reconcile. task-6562440 Forward-Port-Of: odoo/enterprise#131418