**Problem:**
When an appointment is cancelled, the cancellation email is always sent in the organizer's (staff member's) language, ignoring the booking customer's language. The booking confirmation, by contrast, is correctly localized.

**Steps to reproduce:**
1. Set a contact's language to a non-default one (e.g. Romanian).
2. Book an appointment for that contact (they are the booker/attendee).
3. Cancel the appointment.
4. The customer received the confirmation in Romanian but the cancellation email arrives in English.

**Current behavior:**
The cancellation email is rendered in the organizer's language.

**Expected behavior:**
The cancellation email is rendered in the booking customer's language, like the confirmation/invitation email.

**Cause of the issue:**
The cancellation uses `appointment_canceled_mail_template`, whose `lang` is `{{ object.partner_id.lang }}`. On `calendar.event`, `partner_id` is `related='user_id.partner_id'`, i.e. the organizer, not the customer. The template is posted once per event (via `_track_template`), so its single rendering language applies to every recipient, including attendees whose own language differs. The confirmation email is unaffected because it is the per-attendee `attendee_invitation_mail_template` (model `calendar.attendee`), rendered once per attendee in that attendee's language.

**Fix:**
Deriving the language from `appointment_booker_id` makes the cancellation consistent with the other appointment mails, which are meant for the person who booked the meeting. It falls back to `partner_id` when there is no booker (e.g. an event not created through the appointment flow), preserving the previous behavior in that case.

opw-6323179

Forward-Port-Of: odoo/enterprise#125927
Forward-Port-Of: odoo/enterprise#124116

Steps to reproduce:-
- Open any report.
- Click on a particular line to unfold more than once very fast(or throttle network to 3G)
- Once line is unfolded click again to fold that line.
- Line is not folding.

Cause:-
- When we clicked multiple times to unfold line, duplicate child lines were created(as many times as many times we clicked).
- Because when first promise was not resolved so `unfolded = false` and we clicked again so new promise also tries to unfold  the same line, resulting in unfolding the same line multiple times.
- In version 17.0 these duplicate child lines are created but somehow not visible but it breaks `foldLine`. From version 18.0 onwards these duplicate child lines are visible.

Solution: In `unfoldLine` set the flag `unfolding`. So in all clicks other than first, we get `unfolding = true` and don't proceed further, preventing unfolding the same line multiple times.

task-6260425

Forward-Port-Of: odoo/enterprise#126765
Forward-Port-Of: odoo/enterprise#120392

Clicking a slot on an appointment type with a non-ASCII name (for example an Arabic title) puts the browser in an endless 301 loop, so the info form never opens.

### Steps to reproduce

- Create an appointment type with an Arabic name, e.g. `عنوان`.
- Open its page and pick a time slot.
- The browser keeps redirecting on `/appointment/<slug>/info` and fails with "too many redirections".

### Cause

The info URL is built from the slug `<name>-<id>`, here `عنوان-1`. We build a `URL` with `encodeURIComponent(slug)`, so `url.href` is already encoded once (`عنوان` becomes `%D8%B9...`). But we then navigate with `encodeURI(url.href)`, and `encodeURI` escapes the `%` signs a second time, so `%D8%B9...` becomes `%25D8%25B9...`. The slug is now encoded twice.

To canonicalize the URL, the server decodes the request path and the path it rebuilds from the route, once each, and redirects if they differ. For a normal URL they are equal. For ours they are not, because one side is decoded one step less than the other, so the server keeps answering 301 with the same double-encoded URL. An ASCII slug has no `%` for `encodeURI` to escape, so only non-ASCII names hit this.

### Fix

Navigate to `url.href` directly. It is already encoded, so the extra `encodeURI` only broke it. Same fix on the manual resource confirmation path.

opw-6409641

Forward-Port-Of: odoo/enterprise#125497

Currently, an error occurs when user tries to install `website_sale_subscription` after deleting the monthly subscription plan.

Steps to replicate:
- Install `sale_subscription`.
- Open Subscription > Configuration > Recurring Plans.
- Delete the plan named `monthly`.
- Install `website_sale_subscription`.

Error:
```
ValueError: External ID not found in the system: sale_subscription.subscription_plan_month

odoo.tools.convert.ParseError: while parsing /home/odoo/odoo19/enterprise/website_sale_subscription/data/donation_data.xml:16, somewhere inside
<record id="product_recurring_donation_pricing_monthly" model="product.pricelist.item">
            <field name="plan_id" ref="sale_subscription.subscription_plan_month"/>
            <field name="product_tmpl_id" ref="product_recurring_donation"/>
            <field name="fixed_price">1.0</field>
            <field name="pricelist_id" eval="False"/>
        </record>
```

Cause:
- Error is raised when assigning the `Monthly` subscription plan in the `website_sale_subscription` master data because the user has deleted the `Monthly` subscription plan.

Solution:
- As the `plan_id` is not a required field, we can skip assigning the `plan_id` if it the record is not found.

sentry-7441124574

When using the click & collect option, the available qty for renting was not taking the selected warehouse into account.

Steps to reproduce:
-------------------
* Create 2 different warehouses with 2 different adresses
* Create a product available for renting
* Setup the product to use serial numbers
* Create 2 serial number, 1 in each warehouse
* Activate the click & collect option on the website
* Create a first sale order to collect in warehouse 1
* In the backend, confirm the order and pick it up
* Go back to the website and make a second order for the second warehouse
> Observation: When clicking on the "Add to cart" you get an error
  saying that there is no quantity available

Why the fix:
------------
When computing the `product_rented_quantities` it would look for `sale.order.line` in all the warehouse. So it would find the line from the first order even if it's not linked to the selected warehouse. So we just add a new element to the domain to filter out the incorrect warehouses.

opw-6328475

Forward-Port-Of: odoo/enterprise#126817
Forward-Port-Of: odoo/enterprise#124969

**Before this change**
We have the potential to attempt to send a notification email from virtual records created by our `BaseModel.new()` method. This can happen during an `onchange` request, given that we'll be working with a virtual "snapshot" record to recompute potentially changed values for our origin record after a change to one or more values.

This issue manifests when using Studio to attach a many2many field to a form view, where the related model is "Approval Request". If an approval request record in either the "Approved" or "Refused" state is attached to our record via this new Studio field, any `onchange` requests will trigger this bug. This is because we can't send messages on a virtual record.

**After this change**
Prevent the creation and sending of a message if we are computing the request status of a virtual `approval.request()` record. The field `request_status` on this model is computed and stored, but the fact that it is a computed field means that it must be recomputed for a virtual record, even if the origin record already has a stored `request_status`. Thus, we may need to compute a `request_status` value for an ephemeral "snapshot" record.

Though the issue only manifests for the "Approved" and "Refused" states, this PR expands on a test that covers every approval request state.

opw-6390453

Forward-Port-Of: odoo/enterprise#125374

Steps to reproduce:
- set the company currency to XCG
- set the PoS sales journal currency and the PoS pricelist currency to USD
- configure a XCG <-> USD rate
- create a customer without any outstanding balance
- open the PoS, create an order of USD 100 and validate it with the Customer Account (Pay Later) payment method
- open the Customers screen and look at the Total Due of that customer

Issue:
The Total Due shows about USD 55.56, i.e. the amount converted once too many, instead of the expected USD 100.

Cause:
get_total_due() sums two amounts that are not expressed in the same currency before converting them. partner.total_due comes from the accounting entries, it is the sum of account.move.line.amount_residual and is therefore in company currency, while total_settled is the sum of pos.payment.amount of the still open sessions, which is in the currency of the order, so the PoS one. The addition is done first and the result is then converted from the company currency to the PoS one, so the pay later payments end up converted a second time.

opw-6403320

Forward-Port-Of: odoo/enterprise#126402
Forward-Port-Of: odoo/enterprise#125798

Before this commit, test_chatbot_stop_when_agent_joins failed at random in nightly builds:

    FAILED: [8/13] Tour chatbot_stop_when_agent_joins_tour -> Step
    .o-livechat-root:shadow button:contains(Try again).
    Element (.o-livechat-root:shadow button:contains(Try again)) has
    not been found.
    TIMEOUT step failed to complete within 10000 ms.

This happens because the test monkeypatches the chatbot_trigger_step route to make the email step fail once, while the routing map bakes the controller endpoints in when it is built and keeps them in the "routing" ormcache. Every later request reuses that map, so when it was already built with the original method the patch is ignored: the step never fails, the chatbot posts its last step and the retry button the tour clicks never appears.

This commit fixes the issue by invalidating the "routing" ormcache inside the patch, as done for meeting_view_tour, so the request reaches the patched route.

https://runbot.odoo.com/odoo/error/945351

Steps to reproduce:

1) Install hr_holidays & hr_attendance.
2) Enable "Display Extra Hours" & "Absence Management" in the Attendance app settings.
3) Make a new employee, in the form view click the "+" button to make a new hr version record for this employee.
4) Set the date to be the first of the last month.
5) In the Attendance app -> New -> Select the new employee.
6) Select the check in and out dates to be from last month, edit the times such that the time worked is between 7 and 8 hours (ex 9:00am to 4:55pm).
7) In the Attendance app -> Reporting -> Attendances -> the test employee should have a negative value for "Worked Extra Hours"
8) Create a new time off type, enable "Deduct Extra Hours" & disable "Requires Allocation" use hours as the Unit of measure.
9) Open the time off smart button menu from the test employee's form view.

Issue) The value seen in the report from step 7 is not the same as what the user sees in the dashboard.

Notes) This issue can occur when an employee scheduled to work for 8 hours a day only clocks in for 7:55 hours leading to a negative extra time.

The back-end has the correct value stored and sends it to the browser. The issue occurs because the JavaScript function that converts the decimal number of hours into a string (9.5 -> "9:30") does not work with negative input. This PR resolves that issue. 

opw-6417543 

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#280491

### Issue:
A user who can modify `tax_exigibility` but does not have `account.group_account_readonly` is blocked from switching to `on_payment`
There is no way to complete the operation as the account field is not visible and cannot be filled before saving
 
### Cause:
When `tax_exigibility` is set to `on_payment`, the view expects `cash_basis_transition_account_id` to be filled before saving`_constrains_cash_basis_transition_account` then validates that the account is reconcilable
 
`cash_basis_transition_account_id` was restricted to `account.group_account_readonly`, hiding it from other users
The field is never rendered, so it cannot be filled
The `required` constraint is never evaluated client-side and `_constrains_cash_basis_transition_account` raises a `ValidationError` on save because the account is empty
 
There is no reason to restrict `cash_basis_transition_account_id` independently — if a user can modify `tax_exigibility`, they must also be able to set the linked account
 
### Steps to reproduce:
- Install `account`
- Enable Cash Basis in Settings
  (On RunBot ensure no default account is set)
- Enable Developer Mode in Settings
- Go to Settings > Users & Companies > Users
- Open the current user and disable both:
  `Show Accounting Features - Readonly` and `Show Full Accounting Features` (if set)
- Go to Invoicing > Configuration > Taxes
- Open any tax and go to Advanced Options
- Change Tax Exigibility to Based on Payment

Before the fix, the account selector is not displayed and saving raises an error
 
opw-6359173

Forward-Port-Of: odoo/odoo#274728

Before this commit, the `empty a many2one field in list view` test sometimes failed, because the many2one value wasn't correctly unset (`first record` was selected). This happened because we cleared the input and automatically validated (typically with tab). However, it could happen that the validation occurred after the dropdown was opened, so the first value of the dropdown was selected. As a matter of fact, adding `await runAllTimers()` after clearing the input is a way to make the test fail deterministically.

This commit avoids the issue by emptying the many2one without validation, so it basically only set the input value to the empty string, but doesn't tab/enter or anything else, hence it never selects an unwanted value.

runbot error-941430

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#280351

This is rather an attempt of fix, as we couldn't reproduce the error locally or in a multi build., so we have no guarantee that this strenghtens the test.

The test sometimes fails as `.o_crop_icon` can't be found within 200ms. Before that, we wait for the video element to be ready (we rely on a patch of the `isVideoReady` method of the component to know that the video is ready). Once it is, the isReady flag in the state is set to true and the CropOverlay component renders its `o_crop_icon` element.

Our guess is that we may sometimes early return in `isVideoReady`, because the component has been destroyed (a new rendering might be on the way). To ensure that we don't take that as the ready signal in the test, we now only consider that we're ready if isVideoReady returned true (i.e. no early return).

runbot error-241798

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#280329

**Steps to reproduce:**
- Install Survey app
- Create a survey
- Share as e-mail
- Add some text in the body/subject
- Modify recipients
- The added text is automatically reset

**Issue:**
Behavior was previously introduced to match the content
of the composer body/subject to the recipient language.

If there was only one language among the recipients
it automatically adapted the template and changed the
rendered language (which also refreshed the content).

This logic was triggered by a depends on `partner_ids`
and triggered the compute on every recipient changes
which led to the subject/body reset.

**Fix:**
Revert commit: https://github.com/odoo/odoo/commit/b7bbb7b21f4848323666230b518cad9459726f67 in 18.0+
Also adapt commit: https://github.com/odoo/odoo/commit/c6f19e89cb6019e7dbaadbc7427fbb6ddd5661ed to avoid mixed language in resulting mail when the composer was modified
We could also try to prevent the compute when the subject or body is already modified instead of removing its logic.

opw-6020245

Forward-Port-Of: odoo/odoo#280162
Forward-Port-Of: odoo/odoo#254090

Motivation
----------
Each database served keeps a full registry in a process-wide LRU. The LRU is bounded by a count, so on a server hosting thousands of databases the number of retained registries follows traffic rather than memory pressure. Their combined footprint can push a worker past its virtual-memory soft limit, at which point it is killed and restarted.

On a server with ~2500 databases, the soft limit is reached at ~180 resident databases while the LRU could still hold ~210, so HTTP workers were being recycled under normal load.

Tracking usage
--------------
Every request for a registry goes through the single lookup in the registry constructor, which stamps it with a monotonic timestamp; the stamp is also set when a registry is first built.

Collecting idle registries
--------------------------
A collection pass drops every registry whose last use is older than the configured idle timeout. It runs at the end of registry loading, so it fires periodically as databases come and go.

Registries that are still loading are skipped, so a concurrent build is never collected. Dropping a registry only detaches it from the LRU: a request still holding a reference keeps working, and the next lookup rebuilds it.

The timeout is read from ODOO_REGISTRY_MAX_IDLE_TIMEOUT, in seconds; a value of zero, the default, disables the mechanism so behaviour is unchanged unless it is opted into.

Results
-------
With a five-minute timeout on the same ~2500-database server, the HTTP workers settle at around 40 resident registries instead of saturating memory on the long run. The gevent worker, which sees every web client reconnect at startup and briefly fills the LRU with ~150 databases, releases most of them on the first pass, reclaiming the memory.

On a real-life SaaS server with 64GB of RAM, that frees up to ~10GB which were previously taken by unused registries in the LRU. It comes at the expense of extra registry recomputes, but on the other hand workers do not reach their virtual memory limit anymore.

closes odoo/odoo#276581

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#278236

Steps to reproduce:

1) Install hr_holidays & hr_attendance.
2) Enable "Display Extra Hours" & "Absence Management" in the Attendance app settings.
3) Make a new employee, in the form view click the "+" button to make a new hr version record for this employee.
4) Set the date to be the first of the last month.
5) In the Attendance app -> New -> Select the new employee.
6) Select the check in and out dates to be from last month, edit the times such that the time worked is between 7 and 8 hours (ex 9:00am to 4:55pm).
7) In the Attendance app -> Reporting -> Attendances -> the test employee should have a negative value for "Worked Extra Hours"
8) Create a new time off type, enable "Deduct Extra Hours" & disable "Requires Allocation" use hours as the Unit of measure.
9) Open the time off smart button menu from the test employee's form view.

Issue) The value seen in the report from step 7 is not the same as what the user sees in the dashboard.

Notes) This issue can occur when an employee scheduled to work for 8 hours a day only clocks in for 7:55 hours leading to a negative extra time.

The back-end has the correct value stored and sends it to the browser. The issue occurs because the JavaScript function that converts the decimal number of hours into a string (9.5 -> "9:30") does not work with negative input. This PR resolves that issue. 

opw-6417543 

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#280491

### Issue:
A user who can modify `tax_exigibility` but does not have `account.group_account_readonly` is blocked from switching to `on_payment`
There is no way to complete the operation as the account field is not visible and cannot be filled before saving
 
### Cause:
When `tax_exigibility` is set to `on_payment`, the view expects `cash_basis_transition_account_id` to be filled before saving`_constrains_cash_basis_transition_account` then validates that the account is reconcilable
 
`cash_basis_transition_account_id` was restricted to `account.group_account_readonly`, hiding it from other users
The field is never rendered, so it cannot be filled
The `required` constraint is never evaluated client-side and `_constrains_cash_basis_transition_account` raises a `ValidationError` on save because the account is empty
 
There is no reason to restrict `cash_basis_transition_account_id` independently — if a user can modify `tax_exigibility`, they must also be able to set the linked account
 
### Steps to reproduce:
- Install `account`
- Enable Cash Basis in Settings
  (On RunBot ensure no default account is set)
- Enable Developer Mode in Settings
- Go to Settings > Users & Companies > Users
- Open the current user and disable both:
  `Show Accounting Features - Readonly` and `Show Full Accounting Features` (if set)
- Go to Invoicing > Configuration > Taxes
- Open any tax and go to Advanced Options
- Change Tax Exigibility to Based on Payment

Before the fix, the account selector is not displayed and saving raises an error
 
opw-6359173

Forward-Port-Of: odoo/odoo#274728

Before this commit, the `empty a many2one field in list view` test sometimes failed, because the many2one value wasn't correctly unset (`first record` was selected). This happened because we cleared the input and automatically validated (typically with tab). However, it could happen that the validation occurred after the dropdown was opened, so the first value of the dropdown was selected. As a matter of fact, adding `await runAllTimers()` after clearing the input is a way to make the test fail deterministically.

This commit avoids the issue by emptying the many2one without validation, so it basically only set the input value to the empty string, but doesn't tab/enter or anything else, hence it never selects an unwanted value.

runbot error-941430

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#280351

This is rather an attempt of fix, as we couldn't reproduce the error locally or in a multi build., so we have no guarantee that this strenghtens the test.

The test sometimes fails as `.o_crop_icon` can't be found within 200ms. Before that, we wait for the video element to be ready (we rely on a patch of the `isVideoReady` method of the component to know that the video is ready). Once it is, the isReady flag in the state is set to true and the CropOverlay component renders its `o_crop_icon` element.

Our guess is that we may sometimes early return in `isVideoReady`, because the component has been destroyed (a new rendering might be on the way). To ensure that we don't take that as the ready signal in the test, we now only consider that we're ready if isVideoReady returned true (i.e. no early return).

runbot error-241798

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#280329

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse deliveries in two steps
- Inventory > Operations > Tranfers > Internal > New
- Set the operation type as Pick, set a partner and add Partner: Bob
- In the sales & Purchase tab of the partner form set a customer location to be a child of the Customers location: Customers/Bob'Stock
- Confirm and validate the Pick for 1 unit of a product P
#### > A ship picking is created but the destination of the related move is still set to the default customer location.

### Note:

If the flow is performed by a sale order, the `property_stock_customer` location will appropriately be used as `location_final_id`: https://github.com/odoo/odoo/blob/7609b5805c3704034b4d7813e2f356381ed18771/addons/sale_stock/models/sale_order_line.py#L297 https://github.com/odoo/odoo/blob/7609b5805c3704034b4d7813e2f356381ed18771/addons/sale_stock/models/sale_order_line.py#L306-L309 https://github.com/odoo/odoo/blob/720598d0315dbb91628441078febfd43ffefb431/addons/stock/models/stock_rule.py#L263-L264 So that the bug does not occur in that case. By contrast if the pick move is created manually, we do not set its `location_final_id` and hence do not propagate the info. Even though it looks expected to be set set as location_dest_id of the ship move sas suggested by the `stock.picking.location_dest_id` compute method :
https://github.com/odoo/odoo/blob/fe3aea07a1964cd24f4c8ebf2bc93e483eca6b0b/addons/stock/models/stock_picking.py#L990-L1002

opw-6402483

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#279616
Forward-Port-Of: odoo/odoo#278838

**Steps to reproduce:**
- Install Survey app
- Create a survey
- Share as e-mail
- Add some text in the body/subject
- Modify recipients
- The added text is automatically reset

**Issue:**
Behavior was previously introduced to match the content
of the composer body/subject to the recipient language.

If there was only one language among the recipients
it automatically adapted the template and changed the
rendered language (which also refreshed the content).

This logic was triggered by a depends on `partner_ids`
and triggered the compute on every recipient changes
which led to the subject/body reset.

**Fix:**
Revert commit: https://github.com/odoo/odoo/commit/b7bbb7b21f4848323666230b518cad9459726f67 in 18.0+
Also adapt commit: https://github.com/odoo/odoo/commit/c6f19e89cb6019e7dbaadbc7427fbb6ddd5661ed to avoid mixed language in resulting mail when the composer was modified
We could also try to prevent the compute when the subject or body is already modified instead of removing its logic.

opw-6020245

Forward-Port-Of: odoo/odoo#280162
Forward-Port-Of: odoo/odoo#254090

Before this commit, contains() and its variants gave the client 3 seconds, and the bus helpers 2 seconds. The problem is that the first wait after openDiscuss pays for the whole mount, /mail/data and /discuss/channel/messages. Measured from openDiscuss resolving to the message being in the DOM:

- 250 to 460ms on an idle machine;
- 867 to 5258ms over 10 runs with the CPU throttled 4x, which is what a
  busy runbot looks like, 3 of the 10 over 2 seconds;
- 1474 to 6912ms with the CPU throttled 6x, 5 of 6 over 3 seconds.

"Reactions are ordered by id" fails 1 run in 60 at 4x for that reason.

Note that a longer timeout costs nothing on a green build: the timer is cleared as soon as the element is there, so it only delays the report of a test that was going to fail anyway.

This commit raises both to 10 seconds, the delay a tour step already gets in macro.js. test_js.py runs the presets with timeout=15000, so hoot fails the test itself at 15 seconds and 10 leaves room for the rest of the test.

This should also close most of the open runbot errors shaped like:

    Failed to find x of "..." (Timeout of 3 seconds). Found 0 instead.

The element does show up in those, just after the wait gave up.

https://runbot.odoo.com/odoo/error/944188

web companion https://github.com/odoo/odoo/pull/279984

Forward-Port-Of: odoo/odoo#280586
Forward-Port-Of: odoo/odoo#279983

Steps to reproduce:

1) Install hr_holidays & hr_attendance.
2) Enable "Display Extra Hours" & "Absence Management" in the Attendance app settings.
3) Make a new employee, in the form view click the "+" button to make a new hr version record for this employee.
4) Set the date to be the first of the last month.
5) In the Attendance app -> New -> Select the new employee.
6) Select the check in and out dates to be from last month, edit the times such that the time worked is between 7 and 8 hours (ex 9:00am to 4:55pm).
7) In the Attendance app -> Reporting -> Attendances -> the test employee should have a negative value for "Worked Extra Hours"
8) Create a new time off type, enable "Deduct Extra Hours" & disable "Requires Allocation" use hours as the Unit of measure.
9) Open the time off smart button menu from the test employee's form view.

Issue) The value seen in the report from step 7 is not the same as what the user sees in the dashboard.

Notes) This issue can occur when an employee scheduled to work for 8 hours a day only clocks in for 7:55 hours leading to a negative extra time.

The back-end has the correct value stored and sends it to the browser. The issue occurs because the JavaScript function that converts the decimal number of hours into a string (9.5 -> "9:30") does not work with negative input. This PR resolves that issue. 

opw-6417543 

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#280491

Version:
--------
- 19.0+

Steps to reproduce:
-------------------
- Install `purchase` and `stock`
- Create a Purchase Order for a storable or consumable product
- Set the ordered quantity to a negative value (e.g. `-10`)
- Confirm the Purchase Order.
- Open the Deliveries and search using the Purchase Order name

Issue:
------
An outgoing return picking is correctly created for 10 units, but an
additional empty incoming receipt is also generated and linked to the
Purchase Order.

Cause:
------
When a Purchase Order is confirmed, `purchase.order.button_approve()` calls
`purchase.order._create_picking()`:
https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/purchase_stock/models/purchase_order.py#L179

Inside `_create_picking()`, if no open picking exists yet,
Then first creates an incoming receipt using `_prepare_picking()`:
https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/purchase_stock/models/purchase_order.py#L382

The generated receipt is configured with:
- source location: Vendor
- destination location: Stock
- picking type: Incoming
- origin: Purchase Order reference

Stock moves are then created on that receipt through:
https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/purchase_stock/models/purchase_order.py#L387-L388

For negative PO quantities, the move is initially created with a negative
demand:

```
Vendor -> Stock, quantity -10
````

During `stock.move._action_confirm()`, stock identifies such moves in
`neg_r_moves`:
[https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/stock/models/stock_move.py#L1604](https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/stock/models/stock_move.py#L1604)

Those moves are automatically converted into return moves by:

* swapping source and destination locations,
* converting the quantity to positive,
* assigning the return picking type when available:
  [https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/stock/models/stock_move.py#L1612-L1614](https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/stock/models/stock_move.py#L1612-L1614)

The resulting move becomes:

```
Stock -> Vendor, quantity 10
```

The converted move is then reassigned through:
[https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/stock/models/stock_move.py#L1630](https://github.com/odoo/odoo/blob/ed0d1bd21131920cb9c7b2ae69d7baedc2818e85/addons/stock/models/stock_move.py#L1630)

This correctly creates the outgoing return picking.

However, the original incoming receipt created earlier by
`purchase_stock` is left without any moves, resulting in an empty
ghost receipt linked to the Purchase Order.

Solution:
---------
- Track whether `_create_picking()` created a new incoming receipt during
the current confirmation flow.

- After stock move confirmation, if that newly-created receipt no longer
contains any moves, unlink it and remove it from the pickings to
confirm.

- This preserves the valid outgoing return picking while preventing empty
incoming receipts from being generated.


NOTE:
------

This Issue not reproduce from saas-19.3. 
Fix in this [commit](https://github.com/odoo-dev/odoo/commit/81caaaa3f7212ad5d9d72cd446b65c5fb0a9bef9)

---

opw-6131329

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#265704

### Issue:
A user who can modify `tax_exigibility` but does not have `account.group_account_readonly` is blocked from switching to `on_payment`
There is no way to complete the operation as the account field is not visible and cannot be filled before saving
 
### Cause:
When `tax_exigibility` is set to `on_payment`, the view expects `cash_basis_transition_account_id` to be filled before saving`_constrains_cash_basis_transition_account` then validates that the account is reconcilable
 
`cash_basis_transition_account_id` was restricted to `account.group_account_readonly`, hiding it from other users
The field is never rendered, so it cannot be filled
The `required` constraint is never evaluated client-side and `_constrains_cash_basis_transition_account` raises a `ValidationError` on save because the account is empty
 
There is no reason to restrict `cash_basis_transition_account_id` independently — if a user can modify `tax_exigibility`, they must also be able to set the linked account
 
### Steps to reproduce:
- Install `account`
- Enable Cash Basis in Settings
  (On RunBot ensure no default account is set)
- Enable Developer Mode in Settings
- Go to Settings > Users & Companies > Users
- Open the current user and disable both:
  `Show Accounting Features - Readonly` and `Show Full Accounting Features` (if set)
- Go to Invoicing > Configuration > Taxes
- Open any tax and go to Advanced Options
- Change Tax Exigibility to Based on Payment

Before the fix, the account selector is not displayed and saving raises an error
 
opw-6359173

Forward-Port-Of: odoo/odoo#274728

Before this commit, the `empty a many2one field in list view` test sometimes failed, because the many2one value wasn't correctly unset (`first record` was selected). This happened because we cleared the input and automatically validated (typically with tab). However, it could happen that the validation occurred after the dropdown was opened, so the first value of the dropdown was selected. As a matter of fact, adding `await runAllTimers()` after clearing the input is a way to make the test fail deterministically.

This commit avoids the issue by emptying the many2one without validation, so it basically only set the input value to the empty string, but doesn't tab/enter or anything else, hence it never selects an unwanted value.

runbot error-941430

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#280351

This is rather an attempt of fix, as we couldn't reproduce the error locally or in a multi build., so we have no guarantee that this strenghtens the test.

The test sometimes fails as `.o_crop_icon` can't be found within 200ms. Before that, we wait for the video element to be ready (we rely on a patch of the `isVideoReady` method of the component to know that the video is ready). Once it is, the isReady flag in the state is set to true and the CropOverlay component renders its `o_crop_icon` element.

Our guess is that we may sometimes early return in `isVideoReady`, because the component has been destroyed (a new rendering might be on the way). To ensure that we don't take that as the ready signal in the test, we now only consider that we're ready if isVideoReady returned true (i.e. no early return).

runbot error-241798

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#280329

### Steps to reproduce:

- Create 3 AVCO products: Super Kit, Kit, Comp
- Super Kit BoM: 2 x Kit
- Kit BoM: 1 x Comp
- Create and confirm a purchase order for 1 X Super Kit at 100
- Validate the receipt of 2 Comp
- Go to the valuation
> Both units of Comp are valued at 100 for a total of 200

### Cause of the issue:

The issue has been introduced by:
https://github.com/odoo/odoo/pull/158849/changes/713701a5035d342263e3fef2a2819b5696b6d063 To be more precise, the price unit of each unit of Comp is expected to be computed by the `_get_price_unit`. This method used to rely on the `product_qty` appropriately:
https://github.com/odoo/odoo/pull/158849/changes/713701a5035d342263e3fef2a2819b5696b6d063#diff-687527af1723e60816358020c4d83687479df62ca0cfd71079f0a82afb4b3efeL27 However, backorder adapt the move demand and hence did not provide the appropriate demand in this flow that computation logic was changed to rely on the `bom` and `bom_line` quantities:
https://github.com/odoo/odoo/blob/29977a6a80442af49ecefa7fef54f085483d8f77/addons/purchase_mrp/models/stock_move.py#L20-L40 This new computation is not correct in case of nested boms since the `bom_line` only carries the unit demand on the last explosion stage.

### Additional issue:

If nested kit boms lead to the creation of 2 moves with the same `cost_share` and `bom_line_id`, these moves will be merged without summing their `cost_share` leading to an under pricing of the kit since its related `stock_move`'s `cost_share` will not sum up to 100 percents anymore.

This issue is tested in `test_avco_purchase_nested_kit_explode_cost_share_backorder_2` and fixed similarly to demand merging:
https://github.com/odoo/odoo/blob/613f3cb7b2f4813ce6c8f53718a6cca841b081ad/addons/stock/models/stock_move.py#L1122-L1134

### Note:

We also modify the test `test_valuation_with_backorder` to be understandable and to make appropriate asserts.

opw-6253776

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#279890
Forward-Port-Of: odoo/odoo#276242

**Steps to reproduce:**

- Install l10n_pl_edi and enable Allow KSeF integration from 
  **Accounting** settings. 
- Switch to a Polish company.
- Create an EU customer with a valid VAT number.
- Create a sale order containing a service product taxed 
  with 0% Steel (or any tax that has a tag of K11).
- Confirm the sale order and create a down payment invoice. 
- Send the invoice to KSeF and inspect the generated XML. 

**Observed behavior:**

The generated KSeF XML does not contain the `P_13_8` field. 

**Cause:**

For invoices involving the tax of tag `K11` (mainly these taxes are used for the supplies 
that are outside the territory of Poland), the value corresponding to `P_13_8` was not 
being assigned during XML generation, causing the tag to be omitted from the exported 
KSeF document.

**Fix:**

Populate the value of `P_13_8` during KSeF XML generation for invoices, ensuring the 
field is correctly included in the exported XML. 

This PR updates the computation of tag `P_13_10` with its test case to ensure consistency 
with the expected reporting logic, where the tag is computed solely from `K_31`.

Here is the [Documentation](https://ksef.podatki.gov.pl/media/gtjhkeek/information-sheet-on-the-fa-3-logical-structure-04032026.pdf) link for the reference of the Ksef structure. 

**opw**-6294181

Forward-Port-Of: odoo/odoo#276887

Before this commit, the `empty a many2one field in list view` test sometimes failed, because the many2one value wasn't correctly unset (`first record` was selected). This happened because we cleared the input and automatically validated (typically with tab). However, it could happen that the validation occurred after the dropdown was opened, so the first value of the dropdown was selected. As a matter of fact, adding `await runAllTimers()` after clearing the input is a way to make the test fail deterministically.

This commit avoids the issue by emptying the many2one without validation, so it basically only set the input value to the empty string, but doesn't tab/enter or anything else, hence it never selects an unwanted value.

runbot error-941430

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#280351

This is rather an attempt of fix, as we couldn't reproduce the error locally or in a multi build., so we have no guarantee that this strenghtens the test.

The test sometimes fails as `.o_crop_icon` can't be found within 200ms. Before that, we wait for the video element to be ready (we rely on a patch of the `isVideoReady` method of the component to know that the video is ready). Once it is, the isReady flag in the state is set to true and the CropOverlay component renders its `o_crop_icon` element.

Our guess is that we may sometimes early return in `isVideoReady`, because the component has been destroyed (a new rendering might be on the way). To ensure that we don't take that as the ready signal in the test, we now only consider that we're ready if isVideoReady returned true (i.e. no early return).

runbot error-241798

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#280329

Current Implementation:
=======================
The current implementation of _get_l10n_in_gstr1_json relies on multiple iterations over ORM recordsets. Since the ORM loads multiple fields rather than only the required fields, memory consumption grows significantly for large datasets (around 700 MB for 150K account move lines).

Additionally, the method builds a single large dictionary from _get_tax_details that is tailored for the Indian GST reporting logic. Constructing and holding this intermediate data structure further increases memory usage.

The combination of repeated Python loops, ORM overhead, and the large intermediate dictionary results in high execution time and memory consumption, causing the process to exceed the available time and memory limits for large exports.

Solution:
=========
Instead of processing tax details through the ORM, create a temporary table containing the GST tax details and query this subset directly for each GSTR-1 subsection.

This approach bypasses the ORM, fetching only the required columns instead of entire records. Eliminates the need to build the large _get_tax_details dictionary. Reduces the number of Python-side iterations and intermediate data structures. Pushes the data aggregation and filtering to SQL, where it is more efficient. Restricts Python's responsibility to formatting the final JSON output.

This significantly reduces memory usage, improves execution speed, and makes the implementation simpler and easier to maintain.

task-3941950

### Issue
When AI chat is used in views where `config.viewSwitcherEntries` is not initialized, sending a message raises a `TypeError` because the code attempts to call `.map()` on an undefined value.

### Steps to Reproduce
[Video](https://drive.google.com/file/d/1i7kWDnmv4mebGtf1to12BNHCG5omBTXl/view?usp=sharing)
1. Click the **Ask AI** button.
2. Open the AI chat.
3. Keep it open and navigate to the **Shopfloor** app.
4. Send a message in the AI chat.

### Error
```text
TypeError: Cannot read properties of undefined (reading 'map')
    at WithSearch.getCurrentViewInfo
```

### Fix
Safely handle cases where `config.viewSwitcherEntries` is undefined by using optional chaining and falling back to an empty array.

**Before**
```js
result.available_view_types = config.viewSwitcherEntries.map((v) => v.type);
```

**After**
```js
result.available_view_types =
    config.viewSwitcherEntries?.map((v) => v.type) || [];
```

opw-6414684

Forward-Port-Of: odoo/enterprise#126738
Forward-Port-Of: odoo/enterprise#125821

### Issue:
When an invoice has a down payment on a line with a withholding tax, the `PrepaidPayment/PaidAmount` in the UBL XML included the withholding tax amount, causing a mismatch with `LegalMonetaryTotal/PrepaidAmount` which correctly excludes it

### Cause:
`PrepaidPayment/PaidAmount` was set directly from `prepayment_move.amount_total`, which includes all taxes `LegalMonetaryTotal/PrepaidAmount` uses `_aggregate_base_line_tax_details` to exclude withholding taxes, but this was not applied to the `PrepaidPayment` node

### Fix:
Using `prepayment_move.amount_total` directly includes all taxes and does not match the rounding logic of `LegalMonetaryTotal`

Instead, `_aggregate_base_line_tax_details` is used with the same `total_grouping_function` as `LegalMonetaryTotal`, ensuring both nodes use the same rounding logic and exclude withholding taxes

Reversed down payment moves are also excluded from `AdditionalDocumentReference` to avoid referencing cancelled invoices

### Steps to reproduce:
- Install `l10n_pe_edi` and `sale_management` with demo data
- Switch to the PE company
- Create and confirm a Sale Order (Customer: PE Company, Product: Any, Unit Price: 200, Taxes: VAT 18% and 3% IGV Withholding)
- Create, confirm and pay a Down Payment Invoice (Fixed: 28.92)
- Go back to the SO and create the Regular Invoice
- Confirm it and click Process Now
- Open the EDI Document tab and download the XML

Before the fix, the sum of `PrepaidPayment/PaidAmount` did not match `LegalMonetaryTotal/PrepaidAmount`

opw-6273903

Forward-Port-Of: odoo/enterprise#126776
Forward-Port-Of: odoo/enterprise#121733

**Problem:**
When an appointment is cancelled, the cancellation email is always sent in the organizer's (staff member's) language, ignoring the booking customer's language. The booking confirmation, by contrast, is correctly localized.

**Steps to reproduce:**
1. Set a contact's language to a non-default one (e.g. Romanian).
2. Book an appointment for that contact (they are the booker/attendee).
3. Cancel the appointment.
4. The customer received the confirmation in Romanian but the cancellation email arrives in English.

**Current behavior:**
The cancellation email is rendered in the organizer's language.

**Expected behavior:**
The cancellation email is rendered in the booking customer's language, like the confirmation/invitation email.

**Cause of the issue:**
The cancellation uses `appointment_canceled_mail_template`, whose `lang` is `{{ object.partner_id.lang }}`. On `calendar.event`, `partner_id` is `related='user_id.partner_id'`, i.e. the organizer, not the customer. The template is posted once per event (via `_track_template`), so its single rendering language applies to every recipient, including attendees whose own language differs. The confirmation email is unaffected because it is the per-attendee `attendee_invitation_mail_template` (model `calendar.attendee`), rendered once per attendee in that attendee's language.

**Fix:**
Deriving the language from `appointment_booker_id` makes the cancellation consistent with the other appointment mails, which are meant for the person who booked the meeting. It falls back to `partner_id` when there is no booker (e.g. an event not created through the appointment flow), preserving the previous behavior in that case.

opw-6323179

Forward-Port-Of: odoo/enterprise#125927
Forward-Port-Of: odoo/enterprise#124116

The payment_move_ids CTE of the cash flow statement collapsed all the
liquidity move ids into a single array with array_agg(DISTINCT move_id),
and the consumer queries filtered with
move_id IN (SELECT unnest(payment_move_ids.move_id)).

PostgreSQL cannot estimate the cardinality of unnest() over a
non-constant array: the ProjectSet node is always planned with a fixed
guess (rows=10) regardless of how many moves the period contains. On the
affected database the CTE returns 30,307 moves for a single month, a
3,000x planner misestimation that is visible in the EXPLAIN below even
when the query happens to be fast. Whenever the surrounding statistics
degrade (e.g. right after a pg_restore, before any ANALYZE runs), that
guess collapses every downstream join into nested loops over
account_move_line (39M rows) and account_partial_reconcile (9.2M rows)
and the report never finishes (>5 minutes, killed). The unnest() call
was also repeated 7 times (3 in _get_liquidity_moves, 4 in
_get_reconciled_moves).

Make the CTE return a plain row set (SELECT DISTINCT move_id) and filter
with regular IN/NOT IN subqueries so the planner works with real row
estimates and can choose hash semi/anti joins or index nested loops
based on actual costs.

With healthy statistics both forms now perform the same (~0.6s for the
liquidity moves query below); the difference is that the new form
degrades gracefully when estimates drift instead of falling off a
cliff. Full report render on the 39M-line database: 6.4s.

Related operational findings on the affected database (not part of this
patch, applied at the DB level):
- The database had been restored without ANALYZE: pg_stats had 0 rows
  for account_move_line, which is what made the report hang for >5
  minutes regardless of this patch. Fixed with:
      vacuumdb --analyze -t account_move_line -t account_move
               -t account_partial_reconcile ... (6.5s)
- move_id n_distinct was estimated at 169,957 vs 9,844,904 real (58x
  off), pushing the planner away from the efficient move_id index
  probes. Fixed with:
      ALTER TABLE account_move_line
          ALTER COLUMN move_id SET (n_distinct = -0.25);
      ANALYZE account_move_line;
- account_partial_reconcile has no index on max_date; the intermediate
  plans seq-scanned 9.2M rows per UNION branch. Added:
      CREATE INDEX account_partial_reconcile__max_date_index
          ON account_partial_reconcile (max_date);



<details>
<summary>Problematic query BEFORE the change</summary>

```sql
(WITH payment_move_ids AS (
            SELECT
                array_agg(DISTINCT account_move_line.move_id) AS move_id
            FROM "account_move_line"
            WHERE ("account_move_line"."account_id" IN (1274, 15, 1941, 1942, 672, 673, 674, 675, 676, 37, 38, 677, 678, 679, 680, 681, 1079, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 1346, 1353, 1236, 1111, 1252, 1254, 1385, 1898, 1899, 1900, 1264, 1908, 1909, 1018, 1275) AND "account_move_line"."company_id" IN (1) AND "account_move_line"."date" <= '2026-07-31'::date AND "account_move_line"."date" >= '2026-07-01'::date AND "account_move_line"."display_type" NOT IN ('line_section', 'line_subsection', 'line_note') AND "account_move_line"."journal_id" IN (244, 245, 247, 249, 251, 252, 255, 377, 637, 256, 258, 259, 261, 651, 433, 511, 30, 8, 349, 11, 10, 370, 43, 679, 12, 13, 15, 14, 434, 598, 599, 648, 263, 248, 228, 229, 231, 234, 236, 238, 239, 241, 243, 22, 24, 25, 7, 405, 374, 28, 20, 23, 375, 27, 371, 19, 26, 425, 559, 373, 21, 607, 372, 542, 680, 5, 42, 36, 32, 522, 530, 529, 527, 516, 520, 521, 526, 519, 528, 531, 517, 29, 214, 215, 216, 217, 409, 218, 220, 191, 336, 6, 681, 38, 4, 45, 262, 264, 266, 268, 233, 237, 240, 246, 254, 260, 265, 270, 272, 273, 235, 242, 257, 267, 271, 274, 277, 278, 232, 253, 269, 276, 279, 281, 250, 275, 337, 338, 407, 280, 282, 230, 283, 284, 285, 219, 222, 224, 17, 16, 435, 286, 289, 290, 291, 297, 339, 340, 341, 342, 343, 344, 345, 346, 347, 348, 426, 611, 31, 35, 3, 33, 41, 37, 312, 313, 315, 316, 317, 318, 320, 311, 321, 323, 324, 326, 327, 328, 305, 306, 606, 376, 40, 34, 602, 294, 302, 287, 295, 296, 298, 303, 288, 299, 304, 225, 221, 226, 227, 307, 308, 309, 310, 314, 319, 322, 325, 329, 223, 403, 404, 676, 39, 18, 9, 292, 300, 293, 301, 406, 330, 331, 332, 333, 334, 195, 196, 197, 335, 198, 203, 208, 192, 204, 193, 205, 209, 199, 194, 200, 210, 211, 212, 206, 213, 201, 202, 207, 544, 545, 546, 547, 548, 549, 550, 551, 552, 553, 554, 555, 556, 557, 558, 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 390, 392, 393, 395, 397, 399, 401, 402, 400, 378, 389, 391, 394, 396, 398, 682, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369) AND "account_move_line"."parent_state" IN ('posted'))
            )
                -- Credit amount of each account
                SELECT
                    '((''forced_options'', ((''date'', ((''currency_table_period_key'', ''2026-07-01_2026-07-31''), (''date_from'', ''2026-07-01''), (''date_to'', ''2026-07-31''), (''filter'', ''custom''), (''mode'', ''range''), (''period_type'', ''month''), (''string'', ''Jul 2026''))),)), (''horizontal_groupby_element'', ()))' AS column_group_key,
                    account_move_line.account_id,
                    (COALESCE("account_move_line__account_id"."code_store"->'1',to_jsonb(NULL::VARCHAR))->>0)::VARCHAR AS account_code,
                    "account_move_line__account_id"."name"->>'en_US' AS account_name,
                    "account_move_line__account_id"."account_type" AS account_account_type,
                    account_account_account_tag.account_account_tag_id AS account_tag_id,
                    SUM((account_partial_reconcile.amount) * COALESCE(account_currency_table.rate, 1)) AS balance
                FROM "account_move_line" JOIN "account_account" AS "account_move_line__account_id" ON ("account_move_line"."account_id" = "account_move_line__account_id"."id")

                JOIN (VALUES (1, CAST(NULL AS VARCHAR), CAST(NULL AS DATE), CAST(NULL AS DATE), 'current', 1)) AS account_currency_table(company_id, period_key, date_from, date_next, rate_type, rate)
                    ON account_move_line.company_id = account_currency_table.company_id
                    AND (account_currency_table.period_key = '2026-07-01_2026-07-31' OR account_currency_table.period_key IS NULL)

                LEFT JOIN account_partial_reconcile
                    ON account_partial_reconcile.credit_move_id = account_move_line.id
                LEFT JOIN account_account_account_tag
                    ON account_account_account_tag.account_account_id = account_move_line.account_id
                    AND account_account_account_tag.account_account_tag_id IN (1, 3, 2)
                WHERE account_move_line.move_id IN (SELECT unnest(payment_move_ids.move_id) FROM payment_move_ids)
                    AND account_move_line.account_id NOT IN (1274, 15, 1941, 1942, 672, 673, 674, 675, 676, 37, 38, 677, 678, 679, 680, 681, 1079, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 1346, 1353, 1236, 1111, 1252, 1254, 1385, 1898, 1899, 1900, 1264, 1908, 1909, 1018, 1275)
                    AND account_partial_reconcile.max_date BETWEEN '2026-07-01' AND '2026-07-31'
                GROUP BY account_move_line.company_id, account_move_line.account_id, (COALESCE("account_move_line__account_id"."code_store"->'1',to_jsonb(NULL::VARCHAR))->>0)::VARCHAR, "account_move_line__account_id"."name"->>'en_US', account_account_type, account_account_account_tag.account_account_tag_id

                UNION ALL

                -- Debit amount of each account
                SELECT
                    '((''forced_options'', ((''date'', ((''currency_table_period_key'', ''2026-07-01_2026-07-31''), (''date_from'', ''2026-07-01''), (''date_to'', ''2026-07-31''), (''filter'', ''custom''), (''mode'', ''range''), (''period_type'', ''month''), (''string'', ''Jul 2026''))),)), (''horizontal_groupby_element'', ()))' AS column_group_key,
                    account_move_line.account_id,
                    (COALESCE("account_move_line__account_id"."code_store"->'1',to_jsonb(NULL::VARCHAR))->>0)::VARCHAR AS account_code,
                    "account_move_line__account_id"."name"->>'en_US' AS account_name,
                    "account_move_line__account_id"."account_type" AS account_account_type,
                    account_account_account_tag.account_account_tag_id AS account_tag_id,
                    -SUM((account_partial_reconcile.amount) * COALESCE(account_currency_table.rate, 1)) AS balance
                FROM "account_move_line" JOIN "account_account" AS "account_move_line__account_id" ON ("account_move_line"."account_id" = "account_move_line__account_id"."id")

                JOIN (VALUES (1, CAST(NULL AS VARCHAR), CAST(NULL AS DATE), CAST(NULL AS DATE), 'current', 1)) AS account_currency_table(company_id, period_key, date_from, date_next, rate_type, rate)
                    ON account_move_line.company_id = account_currency_table.company_id
                    AND (account_currency_table.period_key = '2026-07-01_2026-07-31' OR account_currency_table.period_key IS NULL)

                LEFT JOIN account_partial_reconcile
                    ON account_partial_reconcile.debit_move_id = account_move_line.id
                LEFT JOIN account_account_account_tag
                    ON account_account_account_tag.account_account_id = account_move_line.account_id
                    AND account_account_account_tag.account_account_tag_id IN (1, 3, 2)
                WHERE account_move_line.move_id IN (SELECT unnest(payment_move_ids.move_id) FROM payment_move_ids)
                    AND account_move_line.account_id NOT IN (1274, 15, 1941, 1942, 672, 673, 674, 675, 676, 37, 38, 677, 678, 679, 680, 681, 1079, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 1346, 1353, 1236, 1111, 1252, 1254, 1385, 1898, 1899, 1900, 1264, 1908, 1909, 1018, 1275)
                    AND account_partial_reconcile.max_date BETWEEN '2026-07-01' AND '2026-07-31'
                GROUP BY account_move_line.company_id, account_move_line.account_id, (COALESCE("account_move_line__account_id"."code_store"->'1',to_jsonb(NULL::VARCHAR))->>0)::VARCHAR, "account_move_line__account_id"."name"->>'en_US', account_account_type, account_account_account_tag.account_account_tag_id

                UNION ALL

                -- Total amount of each account
                SELECT
                    '((''forced_options'', ((''date'', ((''currency_table_period_key'', ''2026-07-01_2026-07-31''), (''date_from'', ''2026-07-01''), (''date_to'', ''2026-07-31''), (''filter'', ''custom''), (''mode'', ''range''), (''period_type'', ''month''), (''string'', ''Jul 2026''))),)), (''horizontal_groupby_element'', ()))' AS column_group_key,
                    account_move_line.account_id AS account_id,
                    (COALESCE("account_move_line__account_id"."code_store"->'1',to_jsonb(NULL::VARCHAR))->>0)::VARCHAR AS account_code,
                    "account_move_line__account_id"."name"->>'en_US' AS account_name,
                    "account_move_line__account_id"."account_type" AS account_account_type,
                    account_account_account_tag.account_account_tag_id AS account_tag_id,
                    SUM((account_move_line.balance) * COALESCE(account_currency_table.rate, 1)) AS balance
                FROM "account_move_line" JOIN "account_account" AS "account_move_line__account_id" ON ("account_move_line"."account_id" = "account_move_line__account_id"."id")

                JOIN (VALUES (1, CAST(NULL AS VARCHAR), CAST(NULL AS DATE), CAST(NULL AS DATE), 'current', 1)) AS account_currency_table(company_id, period_key, date_from, date_next, rate_type, rate)
                    ON account_move_line.company_id = account_currency_table.company_id
                    AND (account_currency_table.period_key = '2026-07-01_2026-07-31' OR account_currency_table.period_key IS NULL)

                LEFT JOIN account_account_account_tag
                    ON account_account_account_tag.account_account_id = account_move_line.account_id
                    AND account_account_account_tag.account_account_tag_id IN (1, 3, 2)
                WHERE account_move_line.move_id IN (SELECT unnest(payment_move_ids.move_id) FROM payment_move_ids)
                    AND account_move_line.account_id NOT IN (1274, 15, 1941, 1942, 672, 673, 674, 675, 676, 37, 38, 677, 678, 679, 680, 681, 1079, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 1346, 1353, 1236, 1111, 1252, 1254, 1385, 1898, 1899, 1900, 1264, 1908, 1909, 1018, 1275)
                GROUP BY account_move_line.account_id, (COALESCE("account_move_line__account_id"."code_store"->'1',to_jsonb(NULL::VARCHAR))->>0)::VARCHAR, "account_move_line__account_id"."name"->>'en_US', account_account_type, account_account_account_tag.account_account_tag_id)
```
</details>

<details>
<summary>EXPLAIN (ANALYZE, BUFFERS) BEFORE the change</summary>

note the ProjectSet rows=10 estimate vs 30,307 actual rows coming out of unnest

```txt
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Append  (cost=26694.10..26849.66 rows=40 width=148) (actual time=307.108..638.422 rows=62 loops=1)
   Buffers: shared hit=789523
   CTE payment_move_ids
     ->  Aggregate  (cost=26613.84..26613.85 rows=1 width=32) (actual time=96.170..96.172 rows=1 loops=1)
           Buffers: shared hit=18968
           ->  Sort  (cost=26552.25..26583.04 rows=12317 width=4) (actual time=92.110..93.591 rows=37545 loops=1)
                 Sort Key: account_move_line_3.move_id
                 Sort Method: quicksort  Memory: 1537kB
                 Buffers: shared hit=18968
                 ->  Index Scan using account_move_line_account_id_date_idx on account_move_line account_move_line_3  (cost=1.23..25715.41 rows=12317 width=4) (actual time=0.101..86.829 rows=37545 loops=1)
                       Index Cond: ((account_id = ANY ('{1274,15,1941,1942,672,673,674,675,676,37,38,677,678,679,680,681,1079,63,64,65,66,67,68,69,70,71,72,73,1346,1353,1236,1111,1252,1254,1385,1898,1899,1900,1264,1908,1909,1018,1275}'::integer[])) AND (date <= '2026-07-31'::date) AND (date >= '2026-07-01'::date))
                       Filter: ((company_id = 1) AND ((parent_state)::text = 'posted'::text) AND ((display_type)::text <> ALL ('{line_section,line_subsection,line_note}'::text[])) AND (journal_id = ANY ('{244,245,247,249,251,252,255,377,637,256,258,259,261,651,433,511,30,8,349,11,10,370,43,679,12,13,15,14,434,598,599,648,263,248,228,229,231,234,236,238,239,241,243,22,24,25,7,405,374,28,20,23,375,27,371,19,26,425,559,373,21,607,372,542,680,5,42,36,32,522,530,529,527,516,520,521,526,519,528,531,517,29,214,215,216,217,409,218,220,191,336,6,681,38,4,45,262,264,266,268,233,237,240,246,254,260,265,270,272,273,235,242,257,267,271,274,277,278,232,253,269,276,279,281,250,275,337,338,407,280,282,230,283,284,285,219,222,224,17,16,435,286,289,290,291,297,339,340,341,342,343,344,345,346,347,348,426,611,31,35,3,33,41,37,312,313,315,316,317,318,320,311,321,323,324,326,327,328,305,306,606,376,40,34,602,294,302,287,295,296,298,303,288,299,304,225,221,226,227,307,308,309,310,314,319,322,325,329,223,403,404,676,39,18,9,292,300,293,301,406,330,331,332,333,334,195,196,197,335,198,203,208,192,204,193,205,209,199,194,200,210,211,212,206,213,201,202,207,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,390,392,393,395,397,399,401,402,400,378,389,391,394,396,398,682,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369}'::integer[])))
                       Rows Removed by Filter: 117
                       Buffers: shared hit=18968
   ->  Subquery Scan on "*SELECT* 1_1"  (cost=80.25..80.30 rows=1 width=148) (actual time=307.108..309.550 rows=2 loops=1)
         Buffers: shared hit=320873
         ->  GroupAggregate  (cost=80.25..80.29 rows=1 width=152) (actual time=307.106..309.547 rows=2 loops=1)
               Group Key: account_move_line.account_id, (((COALESCE((account_move_line__account_id.code_store -> '1'::text)) ->> 0))::character varying), ((account_move_line__account_id.name ->> 'en_US'::text)), account_move_line__account_id.account_type, account_account_account_tag.account_account_tag_id
               Buffers: shared hit=320873
               ->  Sort  (cost=80.25..80.26 rows=1 width=95) (actual time=305.265..305.862 rows=14982 loops=1)
                     Sort Key: account_move_line.account_id, (((COALESCE((account_move_line__account_id.code_store -> '1'::text)) ->> 0))::character varying), ((account_move_line__account_id.name ->> 'en_US'::text)), account_move_line__account_id.account_type, account_account_account_tag.account_account_tag_id
                     Sort Method: quicksort  Memory: 1488kB
                     Buffers: shared hit=320873
                     ->  Nested Loop Left Join  (cost=1.63..80.24 rows=1 width=95) (actual time=105.455..300.078 rows=14982 loops=1)
                           Buffers: shared hit=320867
                           ->  Nested Loop  (cost=1.36..79.64 rows=1 width=100) (actual time=105.434..279.121 rows=14982 loops=1)
                                 Buffers: shared hit=290903
                                 ->  Nested Loop  (cost=1.08..79.35 rows=1 width=15) (actual time=105.423..265.444 rows=14982 loops=1)
                                       Buffers: shared hit=245957
                                       ->  Nested Loop  (cost=0.65..58.84 rows=38 width=12) (actual time=105.398..220.996 rows=23165 loops=1)
                                             Buffers: shared hit=162104
                                             ->  HashAggregate  (cost=0.10..0.20 rows=10 width=4) (actual time=105.370..111.578 rows=30307 loops=1)
                                                   Group Key: unnest(payment_move_ids.move_id)
                                                   Batches: 1  Memory Usage: 3625kB
                                                   Buffers: shared hit=18968
                                                   ->  ProjectSet  (cost=0.00..0.08 rows=10 width=4) (actual time=96.186..97.942 rows=30307 loops=1)
                                                         Buffers: shared hit=18968
                                                         ->  CTE Scan on payment_move_ids  (cost=0.00..0.02 rows=1 width=32) (actual time=96.183..96.184 rows=1 loops=1)
                                                               Buffers: shared hit=18968
                                             ->  Index Scan using account_move_line__move_id_index on account_move_line  (cost=0.55..5.82 rows=4 width=16) (actual time=0.003..0.003 rows=1 loops=30307)
                                                   Index Cond: (move_id = (unnest(payment_move_ids.move_id)))
                                                   Filter: ((company_id = 1) AND (account_id <> ALL ('{1274,15,1941,1942,672,673,674,675,676,37,38,677,678,679,680,681,1079,63,64,65,66,67,68,69,70,71,72,73,1346,1353,1236,1111,1252,1254,1385,1898,1899,1900,1264,1908,1909,1018,1275}'::integer[])))
                                                   Rows Removed by Filter: 1
                                                   Buffers: shared hit=143136
                                       ->  Index Scan using account_partial_reconcile__credit_move_id_index on account_partial_reconcile  (cost=0.43..0.53 rows=1 width=11) (actual time=0.002..0.002 rows=1 loops=23165)
                                             Index Cond: (credit_move_id = account_move_line.id)
                                             Filter: ((max_date >= '2026-07-01'::date) AND (max_date <= '2026-07-31'::date))
                                             Buffers: shared hit=83853
                                 ->  Index Scan using account_account_pkey on account_account account_move_line__account_id  (cost=0.28..0.29 rows=1 width=89) (actual time=0.001..0.001 rows=1 loops=14982)
                                       Index Cond: (id = account_move_line.account_id)
                                       Buffers: shared hit=44946
                           ->  Index Only Scan using account_account_account_tag_sh_auto_pk on account_account_account_tag  (cost=0.28..0.58 rows=1 width=8) (actual time=0.001..0.001 rows=0 loops=14982)
                                 Index Cond: ((account_account_id = account_move_line.account_id) AND (account_account_tag_id = ANY ('{1,3,2}'::integer[])))
                                 Heap Fetches: 0
                                 Buffers: shared hit=29964
   ->  Subquery Scan on "*SELECT* 2"  (cost=80.25..80.31 rows=1 width=148) (actual time=172.103..172.363 rows=10 loops=1)
         Buffers: shared hit=256017
         ->  GroupAggregate  (cost=80.25..80.30 rows=1 width=152) (actual time=172.102..172.359 rows=10 loops=1)
               Group Key: account_move_line_1.account_id, (((COALESCE((account_move_line__account_id_1.code_store -> '1'::text)) ->> 0))::character varying), ((account_move_line__account_id_1.name ->> 'en_US'::text)), account_move_line__account_id_1.account_type, account_account_account_tag_1.account_account_tag_id
               Buffers: shared hit=256017
               ->  Sort  (cost=80.25..80.26 rows=1 width=95) (actual time=170.281..170.572 rows=7235 loops=1)
                     Sort Key: account_move_line_1.account_id, (((COALESCE((account_move_line__account_id_1.code_store -> '1'::text)) ->> 0))::character varying), ((account_move_line__account_id_1.name ->> 'en_US'::text)), account_move_line__account_id_1.account_type, account_account_account_tag_1.account_account_tag_id
                     Sort Method: quicksort  Memory: 764kB
                     Buffers: shared hit=256017
                     ->  Nested Loop Left Join  (cost=1.63..80.24 rows=1 width=95) (actual time=8.816..167.962 rows=7235 loops=1)
                           Buffers: shared hit=256017
                           ->  Nested Loop  (cost=1.36..79.64 rows=1 width=100) (actual time=8.805..157.802 rows=7235 loops=1)
                                 Buffers: shared hit=241547
                                 ->  Nested Loop  (cost=1.08..79.35 rows=1 width=15) (actual time=8.801..151.024 rows=7235 loops=1)
                                       Buffers: shared hit=219842
                                       ->  Nested Loop  (cost=0.65..58.84 rows=38 width=12) (actual time=8.791..112.486 rows=23165 loops=1)
                                             Buffers: shared hit=143136
                                             ->  HashAggregate  (cost=0.10..0.20 rows=10 width=4) (actual time=8.774..14.897 rows=30307 loops=1)
                                                   Group Key: unnest(payment_move_ids_1.move_id)
                                                   Batches: 1  Memory Usage: 3625kB
                                                   ->  ProjectSet  (cost=0.00..0.08 rows=10 width=4) (actual time=0.011..1.752 rows=30307 loops=1)
                                                         ->  CTE Scan on payment_move_ids payment_move_ids_1  (cost=0.00..0.02 rows=1 width=32) (actual time=0.008..0.008 rows=1 loops=1)
                                             ->  Index Scan using account_move_line__move_id_index on account_move_line account_move_line_1  (cost=0.55..5.82 rows=4 width=16) (actual time=0.003..0.003 rows=1 loops=30307)
                                                   Index Cond: (move_id = (unnest(payment_move_ids_1.move_id)))
                                                   Filter: ((company_id = 1) AND (account_id <> ALL ('{1274,15,1941,1942,672,673,674,675,676,37,38,677,678,679,680,681,1079,63,64,65,66,67,68,69,70,71,72,73,1346,1353,1236,1111,1252,1254,1385,1898,1899,1900,1264,1908,1909,1018,1275}'::integer[])))
                                                   Rows Removed by Filter: 1
                                                   Buffers: shared hit=143136
                                       ->  Index Scan using account_partial_reconcile__debit_move_id_index on account_partial_reconcile account_partial_reconcile_1  (cost=0.43..0.53 rows=1 width=11) (actual time=0.001..0.001 rows=0 loops=23165)
                                             Index Cond: (debit_move_id = account_move_line_1.id)
                                             Filter: ((max_date >= '2026-07-01'::date) AND (max_date <= '2026-07-31'::date))
                                             Buffers: shared hit=76706
                                 ->  Index Scan using account_account_pkey on account_account account_move_line__account_id_1  (cost=0.28..0.29 rows=1 width=89) (actual time=0.001..0.001 rows=1 loops=7235)
                                       Index Cond: (id = account_move_line_1.account_id)
                                       Buffers: shared hit=21705
                           ->  Index Only Scan using account_account_account_tag_sh_auto_pk on account_account_account_tag account_account_account_tag_1  (cost=0.28..0.58 rows=1 width=8) (actual time=0.001..0.001 rows=0 loops=7235)
                                 Index Cond: ((account_account_id = account_move_line_1.account_id) AND (account_account_tag_id = ANY ('{1,3,2}'::integer[])))
                                 Heap Fetches: 0
                                 Buffers: shared hit=14470
   ->  HashAggregate  (cost=74.25..75.01 rows=38 width=148) (actual time=156.479..156.498 rows=50 loops=1)
         Group Key: account_move_line_2.account_id, ((COALESCE((account_move_line__account_id_2.code_store -> '1'::text)) ->> 0))::character varying, (account_move_line__account_id_2.name ->> 'en_US'::text), account_move_line__account_id_2.account_type, account_account_account_tag_2.account_account_tag_id
         Batches: 1  Memory Usage: 48kB
         Buffers: shared hit=212633
         ->  Nested Loop Left Join  (cost=1.20..73.58 rows=38 width=90) (actual time=9.037..145.306 rows=23165 loops=1)
               Join Filter: (account_account_account_tag_2.account_account_id = account_move_line_2.account_id)
               Buffers: shared hit=212633
               ->  Nested Loop  (cost=0.93..69.95 rows=38 width=95) (actual time=9.027..135.207 rows=23165 loops=1)
                     Buffers: shared hit=212631
                     ->  Nested Loop  (cost=0.65..58.84 rows=38 width=10) (actual time=9.022..113.369 rows=23165 loops=1)
                           Buffers: shared hit=143136
                           ->  HashAggregate  (cost=0.10..0.20 rows=10 width=4) (actual time=9.005..14.381 rows=30307 loops=1)
                                 Group Key: unnest(payment_move_ids_2.move_id)
                                 Batches: 1  Memory Usage: 3625kB
                                 ->  ProjectSet  (cost=0.00..0.08 rows=10 width=4) (actual time=0.080..1.829 rows=30307 loops=1)
                                       ->  CTE Scan on payment_move_ids payment_move_ids_2  (cost=0.00..0.02 rows=1 width=32) (actual time=0.077..0.077 rows=1 loops=1)
                           ->  Index Scan using account_move_line__move_id_index on account_move_line account_move_line_2  (cost=0.55..5.82 rows=4 width=14) (actual time=0.003..0.003 rows=1 loops=30307)
                                 Index Cond: (move_id = (unnest(payment_move_ids_2.move_id)))
                                 Filter: ((company_id = 1) AND (account_id <> ALL ('{1274,15,1941,1942,672,673,674,675,676,37,38,677,678,679,680,681,1079,63,64,65,66,67,68,69,70,71,72,73,1346,1353,1236,1111,1252,1254,1385,1898,1899,1900,1264,1908,1909,1018,1275}'::integer[])))
                                 Rows Removed by Filter: 1
                                 Buffers: shared hit=143136
                     ->  Index Scan using account_account_pkey on account_account account_move_line__account_id_2  (cost=0.28..0.29 rows=1 width=89) (actual time=0.001..0.001 rows=1 loops=23165)
                           Index Cond: (id = account_move_line_2.account_id)
                           Buffers: shared hit=69495
               ->  Materialize  (cost=0.28..2.78 rows=1 width=8) (actual time=0.000..0.000 rows=0 loops=23165)
                     Buffers: shared hit=2
                     ->  Index Only Scan using account_account_account_tag_account_account_tag_id_account__idx on account_account_account_tag account_account_account_tag_2  (cost=0.28..2.77 rows=1 width=8) (actual time=0.007..0.007 rows=0 loops=1)
                           Index Cond: (account_account_tag_id = ANY ('{1,3,2}'::integer[]))
                           Heap Fetches: 0
                           Buffers: shared hit=2
 Planning:
   Buffers: shared hit=1089
 Planning Time: 11.934 ms
 Execution Time: 639.826 ms
```
</details>



<details>

<summary>Query AFTER the change</summary>

```sql
(WITH payment_move_ids AS (
SELECT DISTINCT
account_move_line.move_id AS move_id
FROM "account_move_line"
WHERE ("account_move_line"."account_id" IN (1274, 15, 1941, 1942, 672, 673, 674, 675, 676, 37, 38, 677, 678, 679, 680, 681, 1079, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 1346, 1353, 1236, 1111, 1252, 1254, 1385, 1898, 1899, 1900, 1264, 1908, 1909, 1018, 1275) AND "account_move_line"."company_id" IN (1) AND "account_move_line"."date" <= '2026-07-31'::date AND "account_move_line"."date" >= '2026-07-01'::date AND "account_move_line"."display_type" NOT IN ('line_section', 'line_subsection', 'line_note') AND "account_move_line"."journal_id" IN (244, 245, 247, 249, 251, 252, 255, 377, 637, 256, 258, 259, 261, 651, 433, 511, 30, 8, 349, 11, 10, 370, 43, 679, 12, 13, 15, 14, 434, 598, 599, 648, 263, 248, 228, 229, 231, 234, 236, 238, 239, 241, 243, 22, 24, 25, 7, 405, 374, 28, 20, 23, 375, 27, 371, 19, 26, 425, 559, 373, 21, 607, 372, 542, 680, 5, 42, 36, 32, 522, 530, 529, 527, 516, 520, 521, 526, 519, 528, 531, 517, 29, 214, 215, 216, 217, 409, 218, 220, 191, 336, 6, 681, 38, 4, 45, 262, 264, 266, 268, 233, 237, 240, 246, 254, 260, 265, 270, 272, 273, 235, 242, 257, 267, 271, 274, 277, 278, 232, 253, 269, 276, 279, 281, 250, 275, 337, 338, 407, 280, 282, 230, 283, 284, 285, 219, 222, 224, 17, 16, 435, 286, 289, 290, 291, 297, 339, 340, 341, 342, 343, 344, 345, 346, 347, 348, 426, 611, 31, 35, 3, 33, 41, 37, 312, 313, 315, 316, 317, 318, 320, 311, 321, 323, 324, 326, 327, 328, 305, 306, 606, 376, 40, 34, 602, 294, 302, 287, 295, 296, 298, 303, 288, 299, 304, 225, 221, 226, 227, 307, 308, 309, 310, 314, 319, 322, 325, 329, 223, 403, 404, 676, 39, 18, 9, 292, 300, 293, 301, 406, 330, 331, 332, 333, 334, 195, 196, 197, 335, 198, 203, 208, 192, 204, 193, 205, 209, 199, 194, 200, 210, 211, 212, 206, 213, 201, 202, 207, 544, 545, 546, 547, 548, 549, 550, 551, 552, 553, 554, 555, 556, 557, 558, 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 390, 392, 393, 395, 397, 399, 401, 402, 400, 378, 389, 391, 394, 396, 398, 682, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369) AND "account_move_line"."parent_state" IN ('posted'))
)
-- Credit amount of each account
SELECT
      '((''forced_options'', ((''date'', ((''currency_table_period_key'', ''2026-07-01_2026-07-31''), (''date_from'', ''2026-07-01''), (''date_to'', ''2026-07-31''), (''filter'', ''custom''), (''mode'', ''range''), (''period_type'', ''month''), (''string'', ''Jul 2026''))),)), (''horizontal_groupby_element'', ()))' AS column_group_key,
      account_move_line.account_id,
      (COALESCE("account_move_line__account_id"."code_store"->'1',to_jsonb(NULL::VARCHAR))->>0)::VARCHAR AS account_code,
      "account_move_line__account_id"."name"->>'en_US' AS account_name,
      "account_move_line__account_id"."account_type" AS account_account_type,
      account_account_account_tag.account_account_tag_id AS account_tag_id,
      SUM((account_partial_reconcile.amount) * COALESCE(account_currency_table.rate, 1)) AS balance
FROM "account_move_line" JOIN "account_account" AS "account_move_line__account_id" ON ("account_move_line"."account_id" = "account_move_line__account_id"."id")

JOIN (VALUES (1, CAST(NULL AS VARCHAR), CAST(NULL AS DATE), CAST(NULL AS DATE), 'current', 1)) AS account_currency_table(company_id, period_key, date_from, date_next, rate_type, rate)
      ON account_move_line.company_id = account_currency_table.company_id
      AND (account_currency_table.period_key = '2026-07-01_2026-07-31' OR account_currency_table.period_key IS NULL)

LEFT JOIN account_partial_reconcile
      ON account_partial_reconcile.credit_move_id = account_move_line.id
LEFT JOIN account_account_account_tag
      ON account_account_account_tag.account_account_id = account_move_line.account_id
      AND account_account_account_tag.account_account_tag_id IN (1, 3, 2)
WHERE account_move_line.move_id IN (SELECT payment_move_ids.move_id FROM payment_move_ids)
      AND account_move_line.account_id NOT IN (1274, 15, 1941, 1942, 672, 673, 674, 675, 676, 37, 38, 677, 678, 679, 680, 681, 1079, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 1346, 1353, 1236, 1111, 1252, 1254, 1385, 1898, 1899, 1900, 1264, 1908, 1909, 1018, 1275)
      AND account_partial_reconcile.max_date BETWEEN '2026-07-01' AND '2026-07-31'
GROUP BY account_move_line.company_id, account_move_line.account_id, (COALESCE("account_move_line__account_id"."code_store"->'1',to_jsonb(NULL::VARCHAR))->>0)::VARCHAR, "account_move_line__account_id"."name"->>'en_US', account_account_type, account_account_account_tag.account_account_tag_id

UNION ALL

-- Debit amount of each account
SELECT
      '((''forced_options'', ((''date'', ((''currency_table_period_key'', ''2026-07-01_2026-07-31''), (''date_from'', ''2026-07-01''), (''date_to'', ''2026-07-31''), (''filter'', ''custom''), (''mode'', ''range''), (''period_type'', ''month''), (''string'', ''Jul 2026''))),)), (''horizontal_groupby_element'', ()))' AS column_group_key,
      account_move_line.account_id,
      (COALESCE("account_move_line__account_id"."code_store"->'1',to_jsonb(NULL::VARCHAR))->>0)::VARCHAR AS account_code,
      "account_move_line__account_id"."name"->>'en_US' AS account_name,
      "account_move_line__account_id"."account_type" AS account_account_type,
      account_account_account_tag.account_account_tag_id AS account_tag_id,
      -SUM((account_partial_reconcile.amount) * COALESCE(account_currency_table.rate, 1)) AS balance
FROM "account_move_line" JOIN "account_account" AS "account_move_line__account_id" ON ("account_move_line"."account_id" = "account_move_line__account_id"."id")

JOIN (VALUES (1, CAST(NULL AS VARCHAR), CAST(NULL AS DATE), CAST(NULL AS DATE), 'current', 1)) AS account_currency_table(company_id, period_key, date_from, date_next, rate_type, rate)
      ON account_move_line.company_id = account_currency_table.company_id
      AND (account_currency_table.period_key = '2026-07-01_2026-07-31' OR account_currency_table.period_key IS NULL)

LEFT JOIN account_partial_reconcile
      ON account_partial_reconcile.debit_move_id = account_move_line.id
LEFT JOIN account_account_account_tag
      ON account_account_account_tag.account_account_id = account_move_line.account_id
      AND account_account_account_tag.account_account_tag_id IN (1, 3, 2)
WHERE account_move_line.move_id IN (SELECT payment_move_ids.move_id FROM payment_move_ids)
      AND account_move_line.account_id NOT IN (1274, 15, 1941, 1942, 672, 673, 674, 675, 676, 37, 38, 677, 678, 679, 680, 681, 1079, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 1346, 1353, 1236, 1111, 1252, 1254, 1385, 1898, 1899, 1900, 1264, 1908, 1909, 1018, 1275)
      AND account_partial_reconcile.max_date BETWEEN '2026-07-01' AND '2026-07-31'
GROUP BY account_move_line.company_id, account_move_line.account_id, (COALESCE("account_move_line__account_id"."code_store"->'1',to_jsonb(NULL::VARCHAR))->>0)::VARCHAR, "account_move_line__account_id"."name"->>'en_US', account_account_type, account_account_account_tag.account_account_tag_id

UNION ALL

-- Total amount of each account
SELECT
      '((''forced_options'', ((''date'', ((''currency_table_period_key'', ''2026-07-01_2026-07-31''), (''date_from'', ''2026-07-01''), (''date_to'', ''2026-07-31''), (''filter'', ''custom''), (''mode'', ''range''), (''period_type'', ''month''), (''string'', ''Jul 2026''))),)), (''horizontal_groupby_element'', ()))' AS column_group_key,
      account_move_line.account_id AS account_id,
      (COALESCE("account_move_line__account_id"."code_store"->'1',to_jsonb(NULL::VARCHAR))->>0)::VARCHAR AS account_code,
      "account_move_line__account_id"."name"->>'en_US' AS account_name,
      "account_move_line__account_id"."account_type" AS account_account_type,
      account_account_account_tag.account_account_tag_id AS account_tag_id,
      SUM((account_move_line.balance) * COALESCE(account_currency_table.rate, 1)) AS balance
FROM "account_move_line" JOIN "account_account" AS "account_move_line__account_id" ON ("account_move_line"."account_id" = "account_move_line__account_id"."id")

JOIN (VALUES (1, CAST(NULL AS VARCHAR), CAST(NULL AS DATE), CAST(NULL AS DATE), 'current', 1)) AS account_currency_table(company_id, period_key, date_from, date_next, rate_type, rate)
      ON account_move_line.company_id = account_currency_table.company_id
      AND (account_currency_table.period_key = '2026-07-01_2026-07-31' OR account_currency_table.period_key IS NULL)

LEFT JOIN account_account_account_tag
      ON account_account_account_tag.account_account_id = account_move_line.account_id
      AND account_account_account_tag.account_account_tag_id IN (1, 3, 2)
WHERE account_move_line.move_id IN (SELECT payment_move_ids.move_id FROM payment_move_ids)
      AND account_move_line.account_id NOT IN (1274, 15, 1941, 1942, 672, 673, 674, 675, 676, 37, 38, 677, 678, 679, 680, 681, 1079, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 1346, 1353, 1236, 1111, 1252, 1254, 1385, 1898, 1899, 1900, 1264, 1908, 1909, 1018, 1275)
GROUP BY account_move_line.account_id, (COALESCE("account_move_line__account_id"."code_store"->'1',to_jsonb(NULL::VARCHAR))->>0)::VARCHAR, "account_move_line__account_id"."name"->>'en_US', account_account_type, account_account_account_tag.account_account_tag_id)
```
</details>

<details>

<summary>EXPLAIN (ANALYZE, BUFFERS) AFTER the change</summary>


the CTE scan is now estimated from real statistics

```txt
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Append  (cost=122015.01..291526.05 rows=47439 width=148) (actual time=346.625..638.772 rows=62 loops=1)
   Buffers: shared hit=675626
   CTE payment_move_ids
     ->  HashAggregate  (cost=25746.20..25869.31 rows=12311 width=4) (actual time=149.934..153.654 rows=30307 loops=1)
           Group Key: account_move_line_3.move_id
           Batches: 1  Memory Usage: 3601kB
           Buffers: shared hit=18968
           ->  Index Scan using account_move_line_account_id_date_idx on account_move_line account_move_line_3  (cost=1.23..25715.41 rows=12317 width=4) (actual time=53.024..140.718 rows=37545 loops=1)
                 Index Cond: ((account_id = ANY ('{1274,15,1941,1942,672,673,674,675,676,37,38,677,678,679,680,681,1079,63,64,65,66,67,68,69,70,71,72,73,1346,1353,1236,1111,1252,1254,1385,1898,1899,1900,1264,1908,1909,1018,1275}'::integer[])) AND (date <= '2026-07-31'::date) AND (date >= '2026-07-01'::date))
                 Filter: ((company_id = 1) AND ((parent_state)::text = 'posted'::text) AND ((display_type)::text <> ALL ('{line_section,line_subsection,line_note}'::text[])) AND (journal_id = ANY ('{244,245,247,249,251,252,255,377,637,256,258,259,261,651,433,511,30,8,349,11,10,370,43,679,12,13,15,14,434,598,599,648,263,248,228,229,231,234,236,238,239,241,243,22,24,25,7,405,374,28,20,23,375,27,371,19,26,425,559,373,21,607,372,542,680,5,42,36,32,522,530,529,527,516,520,521,526,519,528,531,517,29,214,215,216,217,409,218,220,191,336,6,681,38,4,45,262,264,266,268,233,237,240,246,254,260,265,270,272,273,235,242,257,267,271,274,277,278,232,253,269,276,279,281,250,275,337,338,407,280,282,230,283,284,285,219,222,224,17,16,435,286,289,290,291,297,339,340,341,342,343,344,345,346,347,348,426,611,31,35,3,33,41,37,312,313,315,316,317,318,320,311,321,323,324,326,327,328,305,306,606,376,40,34,602,294,302,287,295,296,298,303,288,299,304,225,221,226,227,307,308,309,310,314,319,322,325,329,223,403,404,676,39,18,9,292,300,293,301,406,330,331,332,333,334,195,196,197,335,198,203,208,192,204,193,205,209,199,194,200,210,211,212,206,213,201,202,207,544,545,546,547,548,549,550,551,552,553,554,555,556,557,558,410,411,412,413,414,415,416,417,418,419,420,421,422,423,424,390,392,393,395,397,399,401,402,400,378,389,391,394,396,398,682,350,351,352,353,354,355,356,357,358,359,360,361,362,363,364,365,366,367,368,369}'::integer[])))
                 Rows Removed by Filter: 117
                 Buffers: shared hit=18968
   ->  Subquery Scan on "*SELECT* 1_1"  (cost=96145.70..96153.45 rows=155 width=148) (actual time=346.624..348.928 rows=2 loops=1)
         Buffers: shared hit=290911
         ->  GroupAggregate  (cost=96145.70..96151.90 rows=155 width=152) (actual time=346.621..348.924 rows=2 loops=1)
               Group Key: account_move_line.account_id, (((COALESCE((account_move_line__account_id.code_store -> '1'::text)) ->> 0))::character varying), ((account_move_line__account_id.name ->> 'en_US'::text)), account_move_line__account_id.account_type, account_account_account_tag.account_account_tag_id
               Buffers: shared hit=290911
               ->  Sort  (cost=96145.70..96146.09 rows=155 width=95) (actual time=344.851..345.445 rows=14982 loops=1)
                     Sort Key: account_move_line.account_id, (((COALESCE((account_move_line__account_id.code_store -> '1'::text)) ->> 0))::character varying), ((account_move_line__account_id.name ->> 'en_US'::text)), account_move_line__account_id.account_type, account_account_account_tag.account_account_tag_id
                     Sort Method: quicksort  Memory: 1488kB
                     Buffers: shared hit=290911
                     ->  Hash Left Join  (cost=281.04..96140.06 rows=155 width=95) (actual time=163.798..339.652 rows=14982 loops=1)
                           Hash Cond: (account_move_line.account_id = account_account_account_tag.account_account_id)
                           Buffers: shared hit=290905
                           ->  Nested Loop  (cost=278.25..96135.52 rows=155 width=100) (actual time=163.762..333.768 rows=14982 loops=1)
                                 Buffers: shared hit=290903
                                 ->  Nested Loop  (cost=277.98..96090.18 rows=155 width=15) (actual time=163.745..319.832 rows=14982 loops=1)
                                       Buffers: shared hit=245957
                                       ->  Nested Loop  (cost=277.55..70646.77 rows=47129 width=12) (actual time=163.712..275.793 rows=23165 loops=1)
                                             Buffers: shared hit=162104
                                             ->  HashAggregate  (cost=277.00..400.11 rows=12311 width=4) (actual time=163.675..168.382 rows=30307 loops=1)
                                                   Group Key: payment_move_ids.move_id
                                                   Batches: 1  Memory Usage: 3601kB
                                                   Buffers: shared hit=18968
                                                   ->  CTE Scan on payment_move_ids  (cost=0.00..246.22 rows=12311 width=4) (actual time=149.936..157.948 rows=30307 loops=1)
                                                         Buffers: shared hit=18968
                                             ->  Index Scan using account_move_line__move_id_index on account_move_line  (cost=0.55..5.67 rows=4 width=16) (actual time=0.003..0.003 rows=1 loops=30307)
                                                   Index Cond: (move_id = payment_move_ids.move_id)
                                                   Filter: ((company_id = 1) AND (account_id <> ALL ('{1274,15,1941,1942,672,673,674,675,676,37,38,677,678,679,680,681,1079,63,64,65,66,67,68,69,70,71,72,73,1346,1353,1236,1111,1252,1254,1385,1898,1899,1900,1264,1908,1909,1018,1275}'::integer[])))
                                                   Rows Removed by Filter: 1
                                                   Buffers: shared hit=143136
                                       ->  Index Scan using account_partial_reconcile__credit_move_id_index on account_partial_reconcile  (cost=0.43..0.53 rows=1 width=11) (actual time=0.002..0.002 rows=1 loops=23165)
                                             Index Cond: (credit_move_id = account_move_line.id)
                                             Filter: ((max_date >= '2026-07-01'::date) AND (max_date <= '2026-07-31'::date))
                                             Buffers: shared hit=83853
                                 ->  Index Scan using account_account_pkey on account_account account_move_line__account_id  (cost=0.28..0.29 rows=1 width=89) (actual time=0.001..0.001 rows=1 loops=14982)
                                       Index Cond: (id = account_move_line.account_id)
                                       Buffers: shared hit=44946
                           ->  Hash  (cost=2.77..2.77 rows=1 width=8) (actual time=0.011..0.012 rows=0 loops=1)
                                 Buckets: 1024  Batches: 1  Memory Usage: 8kB
                                 Buffers: shared hit=2
                                 ->  Index Only Scan using account_account_account_tag_account_account_tag_id_account__idx on account_account_account_tag  (cost=0.28..2.77 rows=1 width=8) (actual time=0.011..0.011 rows=0 loops=1)
                                       Index Cond: (account_account_tag_id = ANY ('{1,3,2}'::integer[]))
                                       Heap Fetches: 0
                                       Buffers: shared hit=2
   ->  Subquery Scan on "*SELECT* 2"  (cost=96145.50..96153.64 rows=155 width=148) (actual time=159.664..159.903 rows=10 loops=1)
         Buffers: shared hit=241549
         ->  GroupAggregate  (cost=96145.50..96152.09 rows=155 width=152) (actual time=159.661..159.898 rows=10 loops=1)
               Group Key: account_move_line_1.account_id, (((COALESCE((account_move_line__account_id_1.code_store -> '1'::text)) ->> 0))::character varying), ((account_move_line__account_id_1.name ->> 'en_US'::text)), account_move_line__account_id_1.account_type, account_account_account_tag_1.account_account_tag_id
               Buffers: shared hit=241549
               ->  Sort  (cost=96145.50..96145.89 rows=155 width=95) (actual time=157.870..158.167 rows=7235 loops=1)
                     Sort Key: account_move_line_1.account_id, (((COALESCE((account_move_line__account_id_1.code_store -> '1'::text)) ->> 0))::character varying), ((account_move_line__account_id_1.name ->> 'en_US'::text)), account_move_line__account_id_1.account_type, account_account_account_tag_1.account_account_tag_id
                     Sort Method: quicksort  Memory: 764kB
                     Buffers: shared hit=241549
                     ->  Hash Left Join  (cost=281.04..96139.86 rows=155 width=95) (actual time=7.401..155.573 rows=7235 loops=1)
                           Hash Cond: (account_move_line_1.account_id = account_account_account_tag_1.account_account_id)
                           Buffers: shared hit=241549
                           ->  Nested Loop  (cost=278.25..96135.32 rows=155 width=100) (actual time=7.380..152.835 rows=7235 loops=1)
                                 Buffers: shared hit=241547
                                 ->  Nested Loop  (cost=277.98..96089.98 rows=155 width=15) (actual time=7.365..145.962 rows=7235 loops=1)
                                       Buffers: shared hit=219842
                                       ->  Nested Loop  (cost=277.55..70646.77 rows=47129 width=12) (actual time=7.349..107.795 rows=23165 loops=1)
                                             Buffers: shared hit=143136
                                             ->  HashAggregate  (cost=277.00..400.11 rows=12311 width=4) (actual time=7.329..11.783 rows=30307 loops=1)
                                                   Group Key: payment_move_ids_1.move_id
                                                   Batches: 1  Memory Usage: 3601kB
                                                   ->  CTE Scan on payment_move_ids payment_move_ids_1  (cost=0.00..246.22 rows=12311 width=4) (actual time=0.001..1.685 rows=30307 loops=1)
                                             ->  Index Scan using account_move_line__move_id_index on account_move_line account_move_line_1  (cost=0.55..5.67 rows=4 width=16) (actual time=0.003..0.003 rows=1 loops=30307)
                                                   Index Cond: (move_id = payment_move_ids_1.move_id)
                                                   Filter: ((company_id = 1) AND (account_id <> ALL ('{1274,15,1941,1942,672,673,674,675,676,37,38,677,678,679,680,681,1079,63,64,65,66,67,68,69,70,71,72,73,1346,1353,1236,1111,1252,1254,1385,1898,1899,1900,1264,1908,1909,1018,1275}'::integer[])))
                                                   Rows Removed by Filter: 1
                                                   Buffers: shared hit=143136
                                       ->  Index Scan using account_partial_reconcile__debit_move_id_index on account_partial_reconcile account_partial_reconcile_1  (cost=0.43..0.53 rows=1 width=11) (actual time=0.001..0.001 rows=0 loops=23165)
                                             Index Cond: (debit_move_id = account_move_line_1.id)
                                             Filter: ((max_date >= '2026-07-01'::date) AND (max_date <= '2026-07-31'::date))
                                             Buffers: shared hit=76706
                                 ->  Index Scan using account_account_pkey on account_account account_move_line__account_id_1  (cost=0.28..0.29 rows=1 width=89) (actual time=0.001..0.001 rows=1 loops=7235)
                                       Index Cond: (id = account_move_line_1.account_id)
                                       Buffers: shared hit=21705
                           ->  Hash  (cost=2.77..2.77 rows=1 width=8) (actual time=0.008..0.008 rows=0 loops=1)
                                 Buckets: 1024  Batches: 1  Memory Usage: 8kB
                                 Buffers: shared hit=2
                                 ->  Index Only Scan using account_account_account_tag_account_account_tag_id_account__idx on account_account_account_tag account_account_account_tag_1  (cost=0.28..2.77 rows=1 width=8) (actual time=0.007..0.008 rows=0 loops=1)
                                       Index Cond: (account_account_tag_id = ANY ('{1,3,2}'::integer[]))
                                       Heap Fetches: 0
                                       Buffers: shared hit=2
   ->  HashAggregate  (cost=72169.88..73112.46 rows=47129 width=148) (actual time=129.819..129.928 rows=50 loops=1)
         Group Key: account_move_line_2.account_id, ((COALESCE((account_move_line__account_id_2.code_store -> '1'::text)) ->> 0))::character varying, (account_move_line__account_id_2.name ->> 'en_US'::text), account_move_line__account_id_2.account_type, account_account_account_tag_2.account_account_tag_id
         Batches: 1  Memory Usage: 1585kB
         Buffers: shared hit=143166
         ->  Hash Left Join  (cost=320.08..71345.12 rows=47129 width=90) (actual time=7.557..119.457 rows=23165 loops=1)
               Hash Cond: (account_move_line_2.account_id = account_account_account_tag_2.account_account_id)
               Buffers: shared hit=143166
               ->  Hash Join  (cost=317.29..70811.23 rows=47129 width=95) (actual time=7.539..111.472 rows=23165 loops=1)
                     Hash Cond: (account_move_line_2.account_id = account_move_line__account_id_2.id)
                     Buffers: shared hit=143164
                     ->  Nested Loop  (cost=277.55..70646.77 rows=47129 width=10) (actual time=7.314..106.772 rows=23165 loops=1)
                           Buffers: shared hit=143136
                           ->  HashAggregate  (cost=277.00..400.11 rows=12311 width=4) (actual time=7.291..11.487 rows=30307 loops=1)
                                 Group Key: payment_move_ids_2.move_id
                                 Batches: 1  Memory Usage: 3601kB
                                 ->  CTE Scan on payment_move_ids payment_move_ids_2  (cost=0.00..246.22 rows=12311 width=4) (actual time=0.001..1.610 rows=30307 loops=1)
                           ->  Index Scan using account_move_line__move_id_index on account_move_line account_move_line_2  (cost=0.55..5.67 rows=4 width=14) (actual time=0.003..0.003 rows=1 loops=30307)
                                 Index Cond: (move_id = payment_move_ids_2.move_id)
                                 Filter: ((company_id = 1) AND (account_id <> ALL ('{1274,15,1941,1942,672,673,674,675,676,37,38,677,678,679,680,681,1079,63,64,65,66,67,68,69,70,71,72,73,1346,1353,1236,1111,1252,1254,1385,1898,1899,1900,1264,1908,1909,1018,1275}'::integer[])))
                                 Rows Removed by Filter: 1
                                 Buffers: shared hit=143136
                     ->  Hash  (cost=33.22..33.22 rows=522 width=89) (actual time=0.210..0.210 rows=522 loops=1)
                           Buckets: 1024  Batches: 1  Memory Usage: 72kB
                           Buffers: shared hit=28
                           ->  Seq Scan on account_account account_move_line__account_id_2  (cost=0.00..33.22 rows=522 width=89) (actual time=0.024..0.130 rows=522 loops=1)
                                 Buffers: shared hit=28
               ->  Hash  (cost=2.77..2.77 rows=1 width=8) (actual time=0.008..0.008 rows=0 loops=1)
                     Buckets: 1024  Batches: 1  Memory Usage: 8kB
                     Buffers: shared hit=2
                     ->  Index Only Scan using account_account_account_tag_account_account_tag_id_account__idx on account_account_account_tag account_account_account_tag_2  (cost=0.28..2.77 rows=1 width=8) (actual time=0.008..0.008 rows=0 loops=1)
                           Index Cond: (account_account_tag_id = ANY ('{1,3,2}'::integer[]))
                           Heap Fetches: 0
                           Buffers: shared hit=2
 Planning:
   Buffers: shared hit=1083
 Planning Time: 12.195 ms
 JIT:
   Functions: 114
   Options: Inlining false, Optimization false, Expressions true, Deforming true
   Timing: Generation 6.501 ms (Deform 3.916 ms), Inlining 0.000 ms, Optimization 3.079 ms, Emission 50.027 ms, Total 59.607 ms
 Execution Time: 668.775 ms
(137 rows)
```
</details>


UPDATED: In staging instance I have reproduced using the following code

<details>
<summary>code for odoo-bin shell</summary>

```python
report = env.ref("account_reports.cash_flow_report")
options = report.get_options({})
options["date"].update({"date_from": "2026-07-01", "date_to": "2026-07-31", "mode": "range", "filter": "custom"})
options = report.get_options(options)
handler = env[report.custom_handler_model_name]   # -> account.cash.flow.report.handler
payment_account_ids = handler._get_account_ids(report, options)
print("PAYMENT_ACCOUNT_IDS=", sorted(payment_account_ids))
import logging
logging.getLogger("odoo.sql_db").setLevel(logging.DEBUG)
logging.basicConfig()
report._get_lines(options)
```

</details>


UPDATED2:  The real solution was `vacuumdb --analyze`

Sharing a folder with a portal user with an expiration date cannot be done again after the access has expired. The sharing dialog reports success, but the user does not get access and is no longer listed.

### Steps to reproduce

- In Documents, share a folder with a portal user and set an expiration date.
- Wait until the expiration date has passed.
- Share the same folder with the same user again from the invite box.

=> The dialog says the member was added, but the user has no access and does not appear under "People with access".

### Cause

The invite box has no expiration field. When re-inviting a user, it updates the existing `documents.access` record and passes `None` for the expiration, which keeps the old `expiration_date`. If that date is already in the past, the user remains expired even though the invite reports success.

### Fix

Pass `False` instead of `None` when inviting a member so the existing record's expiration date is cleared. Re-inviting an expired user now restores access. Setting an expiration from the "People with access" list is unchanged.

opw-6387559

Steps to reproduce:
- Install pos_loyalty and pos_online_payment.
- Configure a nominative loyalty program (trigger=auto, applies_on=both) awarding points, and an online payment method.
- In the PoS, add a first-time customer and a product, then pay the order with the online payment method.

Issue:
The customer earns no point, and no loyalty.card is even created for a first-time customer. Orders paid in cash are not affected. The loss is intermittent for customers whose card is already cached.

Cause:
Once paid, the order is rebuilt from the server data and re-selected. `pos.order._export_for_ui` has no `couponPointChanges` field, so the rebuilt order starts with an empty one. `set_order` does schedule a recompute, but it does not await it, and `_postPushOrderResolve` reads `couponPointChanges` right after, before the recompute settles, hence sending nothing to `confirm_coupon_programs`. A first-time customer additionally needs a `fetchLoyaltyCard` RPC, so the recompute can never win the race.

Fix:
Wait for the pending recompute before compiling the coupon data. `Mutex.getUnlockedDef` is used rather than awaiting a new `_updateRewards` call, so that no extra recompute is queued on an order that is already finalized and saved on the server.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr