Friday, August 28, 2026
11 changes · saas-19.1
Enhancements to existing features
Settling sales orders in Point of Sale is now faster, especially for large orders. The update reduces repeated background calls and screen refreshes, so staff should experience less waiting and smoother checkout when converting sales orders.
Original PR description
In `settleSO`, two per-line bottlenecks were addressed: 1. `has_valued_move_ids` was called once per order line via a separate RPC, causing N sequential HTTP round-trips. It is now computed server-side inside `read_converted`, which is already called once for all lines. 2. `addLineToCurrentOrder` was awaited per line, yielding to the event loop each iteration and triggering a full Owl re-render for every line. Lines are now created directly, batching all mutations into a single render. `recomputeOrderData()` is called once after the loop. `updatePrograms` is moved to a `pos_sale_loyalty` patch on `settleSO` so the loyalty concern belongs to the bridge module. opw-6319922 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282571 Forward-Port-Of: odoo/odoo#271742
Accounting now uses a more suitable database index when finding the latest or earliest journal entry by date. This can dramatically reduce wait times in affected accounting screens, turning a previously very slow read operation into a near-instant one in the reported case.
Original PR description
This commit adds an index on `(journal_id, date)` to speed up `_get_last_sequence_domain`. The slow part is `.search(domain, order='date [desc|asc]', limit=1)` Because of the order by date,…
This commit adds an index on `(journal_id, date)` to speed up `_get_last_sequence_domain`. The slow part is `.search(domain, order='date [desc|asc]', limit=1)` Because of the order by date, postgresql scans the index on `date`, assuming a row will be quickly matched. If this assumption is wrong though, it'll scan a large part of the index or all of it, which is slow. This is the case with account move 17102258 on odoo.com at the time of writing this. - before - 1st query https://explain.dalibo.com/plan/6b8ff62b1572ah1a - 2nd query https://explain.dalibo.com/plan/41243cgccg5798gb - after - 1st query https://explain.dalibo.com/plan/4fd2c7ed28g7b138 - 2nd query https://explain.dalibo.com/plan/2heh6c6965c88h71 - ~~1st query https://explain.dalibo.com/plan/f874a31f4b07hdeb~~ - ~~2nd query https://explain.dalibo.com/plan/e8h09725gfh4c2e9~~ full `web_read` - before ~1min 10s - after ~650ms task-6481393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#283159
The French e-invoicing PDP pilot phase option has been removed because the deadline to use it has passed. This simplifies the registration and settings screens so companies only see the current process going forward.
Original PR description
The pilot phase was there if people wanted to send before the deadline. The deadline has been reached, so we can remove the field from the view. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285268 Forward-Port-Of: odoo/odoo#284186
Companies sharing the same French SIREN in one database can now reuse a successful registration verification from another company. This reduces repeated KYC work for groups with many branches and speeds up onboarding to the French PDP e-invoicing process.
Original PR description
We have some clients that have several hundreds of companies/branches on the same db, with the same SIREN (incubateur or the like). They will need to do the kyc (that will be identical, as it's the same SIREN) for all the companies. It's especially cumbersome if it needs manual intervention So, if one company on that database, with the same SIREN, managed to register, then it means it has succeded the kyc. Meaning we can bypass the kyc for the other identifiers as well. task-6515315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#285236
Mail test checks that were waiting for interface text or field values now retry regularly instead of waiting until a long timeout. This reduces unnecessary delays in the mail test suite without changing customer-facing behavior.
Original PR description
Before this commit, a contains that does not match right away runs again only when its MutationObserver fires, and once more at the 10 seconds timeout. The problem is that the observer reports neither a text node updated in place nor an input value or checked property, so a check waiting for one of those sleeps 10 seconds and then passes: "Delete starred message decrements starred counter once" spends 10.2s of the 183s @mail suite waiting for a counter to go from "Starred3" to "Starred2". This commit turns that single timeout into a 500ms tick up to the same deadline, so that such a check costs 500ms. The tick uses the unmocked timer to stay out of the timer graph a test drives with runAllTimers, and only 32 of the suite's 4239 contains calls stay pending long enough to tick once. Forward-Port-Of: odoo/odoo#285129 Forward-Port-Of: odoo/odoo#284944
Deleting accounts is now faster in accounting and point of sale because related payment and analytic records can be checked more efficiently. This reduces delays for users or administrators cleaning up account records, especially in databases with a lot of transaction history.
Original PR description
Without these indexes, the foreign key check when deleting an account can take a long time. Forward-Port-Of: odoo/odoo#284780
Deleting accounts in the German reporting module is now faster in cases with many related accounting entries. This reduces waiting time and helps keep account maintenance smoother for users.
Original PR description
Without these indexes, the foreign key check when deleting an account can take a long time. Forward-Port-Of: odoo/enterprise#129403
New UAE-specific overtime work entry types make it easier to calculate overtime pay accurately. This helps payroll teams use clearer overtime categories for weekday, night, and day-off work when configuring salary rules.
Original PR description
Add UAE overtime work entry types (OVTWD, OVTWDN, OVTOD) to simplify overtime salary rule calculations using `worked_days['<code>'].amount`. Task: 6469393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282898
Large point-of-sale sessions with many invoiced bank payments now close much faster by processing accounting work in batches. This reduces the risk of session closing timing out for businesses with high transaction volumes.
Original PR description
Steps to reproduce ------------------ 1. On a bank payment method, enable "Identify Customer". 2. Create a lot of orders paid with this method and invoice them (the customer reporting the issue had…
Steps to reproduce ------------------ 1. On a bank payment method, enable "Identify Customer". 2. Create a lot of orders paid with this method and invoice them (the customer reporting the issue had 2081 orders). 3. Close the session. The close takes several minutes, and on a remote database the request is killed by the worker time limit before it completes. Cause ----- `_reconcile_account_move_lines` reconciles each group of lines with its own `reconcile()` call, one per payment. Every call creates its partials and triggers the recompute cascade of the ORM, which searches `account.move.line` over the whole set of payments of the session, so the cost of a single call grows with the number of payments. `_create_invoice_receivable_lines` has the same shape: the values are grouped per payment, so every group holds a single value and the lines are created one `create()` call at a time. opw-6242303 already batched the creation and the posting of the split bank payments, and the reconciliation of their receivable lines, but only for the orders that are not invoiced. Invoiced orders go through `split_inv_payment_receivable_lines`, which was left untouched. Fix --- Gather every reconciliation of the session into a single `_reconcile_plan` call. The entries of the plan are processed independently and in order, so the result is the same as reconciling them one by one, but the recompute cascade runs once instead of once per payment. Create all the invoice receivable lines in a single `create()` call and dispatch the records back to their payment method or payment afterwards. Benchmark --------- Closing a session of 2081 invoiced orders on a copy of the customer database: - before: 558s - after: 54s opw-6458271 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284783 Forward-Port-Of: odoo/odoo#281495
Pay later receivables in POS settlement are now reconciled in one grouped operation instead of repeated partner-by-partner processing. This keeps the accounting result unchanged while reducing system workload and improving performance for businesses with many pay later transactions.
Original PR description
The pay later receivable lines are reconciled with one `reconcile()` call per partner, and each call filters the whole set of lines again. Reconcile them in a single `_reconcile_plan` call grouped by partner instead: the result is the same, but the recompute cascade of the ORM runs once instead of once per partner. opw-6458271 Related: https://github.com/odoo/odoo/pull/281495 Forward-Port-Of: odoo/enterprise#129406 Forward-Port-Of: odoo/enterprise#127415
UAE payroll now includes updated overtime pay rules aligned with a newer Odoo version. This helps ensure overtime amounts are calculated more directly and consistently for working days, nights, and days off.
Original PR description
Backport overtime salary rules (OVTWD, OVTWDN, OVTOD) from 19.4 to 19.0, updating the computation logic to directly use `worked_days['<CODE>'].amount`. Task:6469393 Forward-Port-Of: odoo/enterprise#127911