Wednesday, September 23, 2026
6 changes · 19.0
Enhancements to existing features
Users can now manage IAP-related settings, such as credit purchases, low balance warnings, auto-refill, and SMS options, from one dedicated page. This reduces switching between different configuration areas and makes paid service management easier to understand and maintain.
Original PR description
This commit aims at improving how users interact with IAP. Instead of having to configure some details (low balance warnings, auto-refill, SMS) on its db, and others on IAP (buying of credits), we will now present to the user a new IAP page (served by the IAP server) where he/she can manage everything in a single place. task-6128821 Partial backport of https://github.com/odoo/odoo/pull/269021
The Argentine localization test setup now creates sample invoices more efficiently, reducing the time and database work needed to run related report tests. This improves developer and validation speed without changing the resulting report output or business behavior.
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
This update reduces the number of products processed when preparing barcode stock data. It should make barcode-based inventory workflows faster and more efficient, especially when handling larger product sets.
Original PR description
`_get_stock_barcode_data` currently does a union to get a set of products to compute on, this set of products is currently much larger than it needs to be. I'll update with more when I can.
Point of Sale now calculates customer amounts due in one batch instead of repeating the same work for every cached customer. This reduces database load and helps stores open sessions faster, avoiding slowdowns on large production systems.
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
The Argentina reports test data setup now creates sample vendor bills more directly, avoiding unnecessary repeated processing. This reduces automated test time and database work while keeping 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
The Vietnam localization 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 businesses 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