After commit 3cbaad4,
the theme manifest is now looked up to find addon snippets for the configurator. However, during an upgrade, if a website is configured with a third-party/custom theme whose code is not present in the addons path, `Manifest.for_addon()` returns `None` and `_generate_primary_snippet_templates` raises an `AttributeError`:
```py
2026-06-16 03:27:47,155 24126 INFO db_4367932 odoo.modules.loading: loading website/views/new_page_template_templates.xml
2026-06-16 03:27:47,803 24126 WARNING db_4367932 odoo.modules.module: module theme_prime: manifest not found
2026-06-16 03:27:47,845 24126 WARNING db_4367932 odoo.modules.loading: Transient module states were reset
2026-06-16 03:27:47,846 24126 ERROR db_4367932 odoo.registry: Failed to load registry
2026-06-16 03:27:47,846 24126 CRITICAL db_4367932 odoo.service.server: Failed to initialize database `db_4367932`.
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 605, in _tag_root
    f(rec)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 273, in _tag_function
    _eval_xml(self, rec, env)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 197, in _eval_xml
    result = method(*args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/website/models/ir_module_module.py", line 704, in _generate_primary_snippet_templates
    theme_addons = theme_manifest.get('configurator_snippets_addons', {})
AttributeError: 'NoneType' object has no attribute 'get'
```
We also get the missing manifest logs right before the error.

TBG-2781

[`_generate_primary_snippet_templates`]: https://github.com/odoo/odoo/blob/19.0/addons/website/models/ir_module_module.py#L700





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

Forward-Port-Of: odoo/odoo#270217

Steps to reproduce:
----------------------------------------
- Have the company calendar work from 9 to 17 on weekdays
- In project gantt view, create tasks with dependencies like this:
```
- [Task 1] (June 08, 09:00 AM - 10:00 AM) ──┐
                                            ├─> [Task 3] (June 11, 09:00 AM - 10:00 AM)
- [Task 2] (June 10, 09:00 AM - 10:00 AM) ──┘
```
- Make sure the "Auto-Reschedule (Keep Buffer)" is selected
- Then reschedule task 1 to `(June 09, 09:00 AM - 10:00 AM)`
- Task 3 is rescheduled to `(June 15, 09:00 AM - 10:00 AM)`

**Expected behavior:**
To respect the buffers, task 3 should have been rescheduled to `(June 12, 09:00 AM - 10:00 AM)`:
- The buffer from task 1 is  23 working hours after `June 09, 10:00 AM` is `June 12, 09:00 AM`
- The buffer from task 2 doesn't affect the rescheduling.

Cause:
----------------------------------------
From `_web_gantt_update_next_candidates_dates()` we call `_get_new_dates()` with `seconds_between_tasks` being the duration of working hours between the end of task 1 and the start of task 3. We also call it with `first_possible_start_date_per_candidate` being the end of task 3 also depends on task 2.

Then `_get_new_dates()` counts the working hours from `first_possible_start_date_per_candidate` until it reaches `seconds_between_tasks`. Which means the buffer between task 1 and task 3 is actually applied between task 2 and task 3.

Solution:
----------------------------------------
The value contained in `first_possible_start_date_per_candidate` is irrelevant, the correct value to give to `_get_new_dates()` would be `compute_end_date` as we want to keep the buffer to be calculated from this datetime.
So we create a fake dictionary with only the task and `compute_end_date` and give it to `_get_new_dates()`.

The same logic applies when moving tasks backwards.

opw-5973597

Forward-Port-Of: odoo/enterprise#119161

Description of the issue/feature this PR addresses:
  In the combo configurator dialog, a combo item's extra_price and the price_extra of no_variant attributes are stored in the company/product currency but were sent to the
  front-end without conversion. When the order uses a pricelist in a different currency, the popup shows these extras at face value (e.g. an extra of USD 1700 appears as ARS
  1700 instead of being converted). The sale order line itself already converts these extras, so the popup price and the actual line price didn't match.

  Current behavior before PR:
  _get_combo_item_data and _get_selected_ptavs_data return extra_price / price_extra raw, in the company currency. With a foreign-currency pricelist the combo configurator
  popup adds them 1-to-1 to the already-converted base price, displaying an incorrect total that doesn't match the resulting sale order line.

  Desired behavior after PR is merged:
  The controller converts extra_price and price_extra to the configurator's currency (via currency._convert()) before serializing them, so the popup shows the correct amounts
  in the pricelist currency and matches the price computed on the sale order line. A test (test_sale_combo_multicurrency.py) covers combo extra-price conversion with a
  foreign-currency pricelist.

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

Forward-Port-Of: odoo/odoo#269905
Forward-Port-Of: odoo/odoo#269386

### Issue
When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid

If a user with only "Invoicing & Banks" rights tries to reconcile a Bank Statement with the same partner, amount, and the invoice name as the memo, the automatic reconciliation fails to properly match the payment
Instead, the invoice is incorrectly considered as Fully Paid with an unwanted extra Account Receivable line added

### Cause
When a new Bank Statement is created, `_try_auto_reconcile_statement_lines()` is called and matches the outstanding credit, which invokes `set_line_bank_statement_line()`
This function creates a balancing line and triggers `move._compute_checked()` to update dependencies

However, `move.checked` requires `_is_user_able_to_review()` to be True
A user with "Invoicing & Banks" rights lacks the `account.group_account_user` group, meaning the move is not marked as checked, preventing dependencies from computing correctly
Consequently, the statement line's `amount_residual` is not cleared and the line is not removed from `remaining_st_line_ids`

Later in the process, `_try_auto_reconcile_statement_lines()` is called again with `with_user(SUPERUSER_ID)`
Because the payment matching was never finalized in the previous step, the engine fallback matches against the full invoice, adding an incorrect Account Receivable line to close it

### Steps to reproduce
- Install `accountant`
- Go to Accounting / Configuration / Accounting / Journals
- Open the Bank, under Incoming Payments tab, set the Manual Payment method's Outstanding Receipts account to 101403 Outstanding Receipts
- Update the Demo user's accounting rights to Invoicing & Banks
- Log in with the Demo user
- Create and confirm an invoice for Acme Corporation (Amount: $1100)
- Register a payment on the invoice (Amount: $500, Keep open)
- Copy the invoice name
- Open the Bank Reconciliation widget from the Accounting Dashboard
- Create and add a new Bank Statement Line (Label: Invoice name, Partner: Acme Corporation, Amount: $500)
Before the fix, an unexpected Account Receivable line is created and the invoice is marked as Fully Paid

### Notes
Instead of processing the entire block under SUPERUSER_ID, which would hide the creator identity in logs and chatter, the context key `skip_account_review_check=True` is injected during the automated statement line reconciliation
This safely bypasses the group check inside `_is_user_able_to_review` for this specific automated flow

A fallback using `.with_user(SUPERUSER_ID)` is already implemented twice within the same `_try_auto_reconcile_statement_lines` method for this specific use case, but avoiding it here preserves data auditability

opw-6077137

Forward-Port-Of: odoo/enterprise#120217
Forward-Port-Of: odoo/enterprise#118023

### Issue
When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid

If a user with only "Invoicing & Banks" rights tries to reconcile a Bank Statement with the same partner, amount, and the invoice name as the memo, the automatic reconciliation fails to properly match the payment
Instead, the invoice is incorrectly considered as Fully Paid with an unwanted extra Account Receivable line added

### Cause
When a new Bank Statement is created,
`_try_auto_reconcile_statement_lines()` is called and matches the outstanding credit, which invokes `set_line_bank_statement_line()` In 19.0, this function creates a balancing line and triggers `move._compute_checked()` to update dependencies
Especially `_compute_is_reconciled`
But checked as been replaced by `review_state`
This FW port will use an update on the `review_state` instead of the `checked`

A user with "Invoicing & Banks" rights lacks the
`account.group_account_user` group, meaning the move is not marked as `reviewed`, preventing dependencies from computing correctly Consequently, the statement line's `amount_residual` is not cleared and the line is not removed from `remaining_st_line_ids`

Later in the process, `_try_auto_reconcile_statement_lines()` is called again with `with_user(SUPERUSER_ID)`
Because the payment matching was never finalized in the previous step, the engine fallback matches against the full invoice, adding an incorrect Account Receivable line to close it

### Steps to reproduce
- Install `accountant`
- Go to Accounting / Configuration / Accounting / Journals
- Open the Bank, under Incoming Payments tab, set the Manual Payment method's Outstanding Receipts account to 101403 Outstanding Receipts
- Update the Demo user's accounting rights to Invoicing & Banks
- Log in with the Demo user
- Create and confirm an invoice for Acme Corporation (Amount: $1100)
- Register a payment on the invoice (Amount: $500, Keep open)
- Copy the invoice name
- Open the Bank Reconciliation widget from the Accounting Dashboard
- Create and add a new Bank Statement Line (Label: Invoice name, Partner: Acme Corporation, Amount: $500)
Before the fix, an unexpected Account Receivable line is created and the invoice is marked as Fully Paid

### Notes
Instead of processing the entire block under SUPERUSER_ID, which would hide the creator identity in logs and chatter, the context key `skip_account_review_check=True` is injected during the automated statement line reconciliation
This safely bypasses the group check inside `_is_user_able_to_review` for this specific automated flow

A fallback using `.with_user(SUPERUSER_ID)` is already implemented twice within the same `_try_auto_reconcile_statement_lines` method for this specific use case, but avoiding it here preserves data auditability

opw-6077137

Forward-Port-Of: odoo/odoo#270080

Steps to produce:
---
- Install `website_sale_loyalty`.
- Go to `Website > ecommerece > Loyalty > DIscount & Loyalty`.
- Create a new discount & loyalty program > set program type as `promotions`.
- Under Rewards, select `Free Shipping` as the reward type.
- Create a product with a price of 1000 and publish it.
- Add the product to the cart from the website.
- Observe that free shipping is automatically applied on cart.
- Attempt to remove the free shipping reward from the cart.

Issue:
---
- Free shipping (and similarly, free product rewards) cannot be removed from the cart once applied.

Root cause:
---
- At [1], the `website_sale_loyalty_delete` context is only passed when the reward type is `discount`. As a result, for free shipping and free product rewards, the context is not set. At [2], the order line is removed, but the reward is not added to `disabled_auto_rewards`. The `_auto_apply_rewards` method runs immediately afterward, detects the missing reward, and re-applies it automatically.

Fix:
---
- Since there are three reward types (discount, free shipping, and free product), the condition restricting the context to only discount rewards should be removed.

[1]https://github.com/odoo/odoo/blob/5e90858fa91348f6aa33b4f8a246e77fbb8ea63f/addons/website_sale_loyalty/models/sale_order.py#L179
[2]https://github.com/odoo/odoo/blob/5e90858fa91348f6aa33b4f8a246e77fbb8ea63f/addons/website_sale_loyalty/models/sale_order_line.py#L15-L23

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

Forward-Port-Of: odoo/odoo#261732

Description of the issue/feature this PR addresses:
  In the combo configurator dialog, a combo item's extra_price and the price_extra of no_variant attributes are stored in the company/product currency but were sent to the
  front-end without conversion. When the order uses a pricelist in a different currency, the popup shows these extras at face value (e.g. an extra of USD 1700 appears as ARS
  1700 instead of being converted). The sale order line itself already converts these extras, so the popup price and the actual line price didn't match.

  Current behavior before PR:
  _get_combo_item_data and _get_selected_ptavs_data return extra_price / price_extra raw, in the company currency. With a foreign-currency pricelist the combo configurator
  popup adds them 1-to-1 to the already-converted base price, displaying an incorrect total that doesn't match the resulting sale order line.

  Desired behavior after PR is merged:
  The controller converts extra_price and price_extra to the configurator's currency (via currency._convert()) before serializing them, so the popup shows the correct amounts
  in the pricelist currency and matches the price computed on the sale order line. A test (test_sale_combo_multicurrency.py) covers combo extra-price conversion with a
  foreign-currency pricelist.

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

Forward-Port-Of: odoo/odoo#269905
Forward-Port-Of: odoo/odoo#269386

When validating a POS order containing a product tracked by lots, an error about duplicate lot numbers is raised if the lot name can be read as a GS1 barcode (e.g. "10156": "10" is the GS1 Application Identifier for Batch/Lot) while the company uses a GS1 nomenclature and the Barcode app is installed.

Steps to reproduce:
-------------------
* Install Barcode, POS and Inventory, enable lots & serial numbers
* Set the barcode nomenclature to "Default GS1 Nomenclature"
* Create a product tracked by lots and a lot named "10156" (any name starting with "10"), set an on-hand quantity for it with this lot
* On the "PoS Orders" operation type, enable both "Create New" and "Use Existing ones" for lots/serial numbers
* In POS, sell the product with lot "10156" and validate the order

> Observation:
The order fails to validate with a duplicate lot number error: the search for existing lots does not find lot "10156", so the POS tries to create it again and hits the unique constraint on stock.lot.

Why the fix:
------------
With stock_barcode installed, `stock.lot._search` preprocesses any domain on `name` with `_preprocess_gs1_search_args` so that scanned GS1 barcodes can match lot records. The lot names sent at order validation by `_create_production_lots_for_pos_order` are real lot names coming from the order lines, not scanned barcodes, but "10156" is decomposable as a valid GS1 lot ("10" + "156"), so the search domain became `('name', '=', '156')` and missed the existing lot. Skip the GS1 preprocessing in that search with the existing `skip_preprocess_gs1` context key, as already done in `product` and `stock`.

opw-6274744

Forward-Port-Of: odoo/odoo#269787

**Issue**
Reducing the PO quantity after performing a partial receipt, in multi-step receipts warehouse
can incorrectly update the remaining receipt quantity.

**Steps to reproduce**
- Setup 2-route receipt warehouse (Inventory > Configuration > Warehouse Management > Warehouses)
- Create a PO for 35 units and confirm it
- Click on receive products, set received quantity to 10 and create a backorder
- Validate the next transfer
- Go back to the PO and change the quantity to 20
- Check the receipt demand
-> The backorder picking demand become 35 instead of 10

**Cause**
Updating the quantity of a purchase order line, also updates the related picking:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L120
It updates the picking associated to the backorder since the other one is done:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L185-L187
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L197
This ultimately calls:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L228
To compute the new demand for the picking, it retrieves the `move_dest`:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L240
To compute `qty_to_push`:
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/purchase_stock/models/purchase_order_line.py#L247-L249
However, since we are in a 2-route receipt setup, `move_dest` is the move from Input to stock for the done picking.
Thus, `qty_to_push` is `20 - 10 = 10` instead of `20 - 35 = -15`

**Solution**
The previous logic assumes a pull flow, where downstream (move_dest_ids) quantities are always up-to-date and can be used as the source of truth to recompute demand.
In push flows (e.g., multi-step receipts), this assumption does not hold. 
To fix this, we instead base the computation on the quantity of the current moves (qty) if nothing has to be attached. 

**Additional information**
Known limitation: this does not address inconsistencies in return flows. When there're returns, units 
define in the pol and the one define in the sum of the picking can diverge, thus this pr won't fix that.

opw-5512172

Forward-Port-Of: odoo/odoo#265583
Forward-Port-Of: odoo/odoo#248626

Steps to reproduce:
----------------------------------------
- Have the company calendar work from 9 to 17 on weekdays
- In project gantt view, create tasks with dependencies like this:
```
- [Task 1] (June 08, 09:00 AM - 10:00 AM) ──┐
                                            ├─> [Task 3] (June 11, 09:00 AM - 10:00 AM)
- [Task 2] (June 10, 09:00 AM - 10:00 AM) ──┘
```
- Make sure the "Auto-Reschedule (Keep Buffer)" is selected
- Then reschedule task 1 to `(June 09, 09:00 AM - 10:00 AM)`
- Task 3 is rescheduled to `(June 15, 09:00 AM - 10:00 AM)`

**Expected behavior:**
To respect the buffers, task 3 should have been rescheduled to `(June 12, 09:00 AM - 10:00 AM)`:
- The buffer from task 1 is  23 working hours after `June 09, 10:00 AM` is `June 12, 09:00 AM`
- The buffer from task 2 doesn't affect the rescheduling.

Cause:
----------------------------------------
From `_web_gantt_update_next_candidates_dates()` we call `_get_new_dates()` with `seconds_between_tasks` being the duration of working hours between the end of task 1 and the start of task 3. We also call it with `first_possible_start_date_per_candidate` being the end of task 3 also depends on task 2.

Then `_get_new_dates()` counts the working hours from `first_possible_start_date_per_candidate` until it reaches `seconds_between_tasks`. Which means the buffer between task 1 and task 3 is actually applied between task 2 and task 3.

Solution:
----------------------------------------
The value contained in `first_possible_start_date_per_candidate` is irrelevant, the correct value to give to `_get_new_dates()` would be `compute_end_date` as we want to keep the buffer to be calculated from this datetime.
So we create a fake dictionary with only the task and `compute_end_date` and give it to `_get_new_dates()`.

The same logic applies when moving tasks backwards.

opw-5973597

Forward-Port-Of: odoo/enterprise#119161

Steps to produce:
---
- Install `website_sale_loyalty`.
- Go to `Website > ecommerece > Loyalty > DIscount & Loyalty`.
- Create a new discount & loyalty program > set program type as `promotions`.
- Under Rewards, select `Free Shipping` as the reward type.
- Create a product with a price of 1000 and publish it.
- Add the product to the cart from the website.
- Observe that free shipping is automatically applied on cart.
- Attempt to remove the free shipping reward from the cart.

Issue:
---
- Free shipping (and similarly, free product rewards) cannot be removed from the cart once applied.

Root cause:
---
- At [1], the `website_sale_loyalty_delete` context is only passed when the reward type is `discount`. As a result, for free shipping and free product rewards, the context is not set. At [2], the order line is removed, but the reward is not added to `disabled_auto_rewards`. The `_auto_apply_rewards` method runs immediately afterward, detects the missing reward, and re-applies it automatically.

Fix:
---
- Since there are three reward types (discount, free shipping, and free product), the condition restricting the context to only discount rewards should be removed.

[1]https://github.com/odoo/odoo/blob/5e90858fa91348f6aa33b4f8a246e77fbb8ea63f/addons/website_sale_loyalty/models/sale_order.py#L179
[2]https://github.com/odoo/odoo/blob/5e90858fa91348f6aa33b4f8a246e77fbb8ea63f/addons/website_sale_loyalty/models/sale_order_line.py#L15-L23

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

Forward-Port-Of: odoo/odoo#261732

After commit 3cbaad4,
the theme manifest is now looked up to find addon snippets for the configurator. However, during an upgrade, if a website is configured with a third-party/custom theme whose code is not present in the addons path, `Manifest.for_addon()` returns `None` and `_generate_primary_snippet_templates` raises an `AttributeError`:
```py
2026-06-16 03:27:47,155 24126 INFO db_4367932 odoo.modules.loading: loading website/views/new_page_template_templates.xml
2026-06-16 03:27:47,803 24126 WARNING db_4367932 odoo.modules.module: module theme_prime: manifest not found
2026-06-16 03:27:47,845 24126 WARNING db_4367932 odoo.modules.loading: Transient module states were reset
2026-06-16 03:27:47,846 24126 ERROR db_4367932 odoo.registry: Failed to load registry
2026-06-16 03:27:47,846 24126 CRITICAL db_4367932 odoo.service.server: Failed to initialize database `db_4367932`.
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 605, in _tag_root
    f(rec)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 273, in _tag_function
    _eval_xml(self, rec, env)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 197, in _eval_xml
    result = method(*args, **kwargs)
  File "/home/odoo/src/odoo/19.0/addons/website/models/ir_module_module.py", line 704, in _generate_primary_snippet_templates
    theme_addons = theme_manifest.get('configurator_snippets_addons', {})
AttributeError: 'NoneType' object has no attribute 'get'
```
We also get the missing manifest logs right before the error.

TBG-2781

[`_generate_primary_snippet_templates`]: https://github.com/odoo/odoo/blob/19.0/addons/website/models/ir_module_module.py#L700





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

Forward-Port-Of: odoo/odoo#270217

Description of the issue/feature this PR addresses:
  In the combo configurator dialog, a combo item's extra_price and the price_extra of no_variant attributes are stored in the company/product currency but were sent to the
  front-end without conversion. When the order uses a pricelist in a different currency, the popup shows these extras at face value (e.g. an extra of USD 1700 appears as ARS
  1700 instead of being converted). The sale order line itself already converts these extras, so the popup price and the actual line price didn't match.

  Current behavior before PR:
  _get_combo_item_data and _get_selected_ptavs_data return extra_price / price_extra raw, in the company currency. With a foreign-currency pricelist the combo configurator
  popup adds them 1-to-1 to the already-converted base price, displaying an incorrect total that doesn't match the resulting sale order line.

  Desired behavior after PR is merged:
  The controller converts extra_price and price_extra to the configurator's currency (via currency._convert()) before serializing them, so the popup shows the correct amounts
  in the pricelist currency and matches the price computed on the sale order line. A test (test_sale_combo_multicurrency.py) covers combo extra-price conversion with a
  foreign-currency pricelist.

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

Forward-Port-Of: odoo/odoo#269905
Forward-Port-Of: odoo/odoo#269386

When moving an order (Order A) to a table that already has an order (Order B), the merged order only reprints Order B's products. The products from Order A are missing from the preparation reprint.

Steps to reproduce:
-------------------
* Open a POS session on a Restaurant POS
* Create an order (Order A) for Table 1
* Create a second order (Order B) for Table 2
* Transfer/Merge Order A to Table 2
* Reprint the preparation order

> Observation:
Only the products that were already on Table 2 (Order B) appear on the reprint. Products from Order A are missing.

Why the fix:
------------
mergeOrders correctly transfers kitchen history
(last_order_preparation_change.lines) via handlePreparationHistory, but does not update uiState.lastPrints on the destination order. The reprint button uses lastPrints.at(-1) when there are no pending changes, so it only shows the destination order's last print batch — ignoring the merged lines entirely.

Implementation:
After the merge loop, build a consolidated lastPrints entry from the destination order's last_order_preparation_change.lines (which now contains lines from both orders) and push it onto
destOrder.uiState.lastPrints so that reprint reflects the full merged state.

opw-6060684

Forward-Port-Of: odoo/odoo#256309

When validating a POS order containing a product tracked by lots, an error about duplicate lot numbers is raised if the lot name can be read as a GS1 barcode (e.g. "10156": "10" is the GS1 Application Identifier for Batch/Lot) while the company uses a GS1 nomenclature and the Barcode app is installed.

Steps to reproduce:
-------------------
* Install Barcode, POS and Inventory, enable lots & serial numbers
* Set the barcode nomenclature to "Default GS1 Nomenclature"
* Create a product tracked by lots and a lot named "10156" (any name starting with "10"), set an on-hand quantity for it with this lot
* On the "PoS Orders" operation type, enable both "Create New" and "Use Existing ones" for lots/serial numbers
* In POS, sell the product with lot "10156" and validate the order

> Observation:
The order fails to validate with a duplicate lot number error: the search for existing lots does not find lot "10156", so the POS tries to create it again and hits the unique constraint on stock.lot.

Why the fix:
------------
With stock_barcode installed, `stock.lot._search` preprocesses any domain on `name` with `_preprocess_gs1_search_args` so that scanned GS1 barcodes can match lot records. The lot names sent at order validation by `_create_production_lots_for_pos_order` are real lot names coming from the order lines, not scanned barcodes, but "10156" is decomposable as a valid GS1 lot ("10" + "156"), so the search domain became `('name', '=', '156')` and missed the existing lot. Skip the GS1 preprocessing in that search with the existing `skip_preprocess_gs1` context key, as already done in `product` and `stock`.

opw-6274744

Forward-Port-Of: odoo/odoo#269787

Steps to reproduce:
----------------------------------------
- Have the company calendar work from 9 to 17 on weekdays
- In project gantt view, create tasks with dependencies like this:
```
- [Task 1] (June 08, 09:00 AM - 10:00 AM) ──┐
                                            ├─> [Task 3] (June 11, 09:00 AM - 10:00 AM)
- [Task 2] (June 10, 09:00 AM - 10:00 AM) ──┘
```
- Make sure the "Auto-Reschedule (Keep Buffer)" is selected
- Then reschedule task 1 to `(June 09, 09:00 AM - 10:00 AM)`
- Task 3 is rescheduled to `(June 15, 09:00 AM - 10:00 AM)`

**Expected behavior:**
To respect the buffers, task 3 should have been rescheduled to `(June 12, 09:00 AM - 10:00 AM)`:
- The buffer from task 1 is  23 working hours after `June 09, 10:00 AM` is `June 12, 09:00 AM`
- The buffer from task 2 doesn't affect the rescheduling.

Cause:
----------------------------------------
From `_web_gantt_update_next_candidates_dates()` we call `_get_new_dates()` with `seconds_between_tasks` being the duration of working hours between the end of task 1 and the start of task 3. We also call it with `first_possible_start_date_per_candidate` being the end of task 3 also depends on task 2.

Then `_get_new_dates()` counts the working hours from `first_possible_start_date_per_candidate` until it reaches `seconds_between_tasks`. Which means the buffer between task 1 and task 3 is actually applied between task 2 and task 3.

Solution:
----------------------------------------
The value contained in `first_possible_start_date_per_candidate` is irrelevant, the correct value to give to `_get_new_dates()` would be `compute_end_date` as we want to keep the buffer to be calculated from this datetime.
So we create a fake dictionary with only the task and `compute_end_date` and give it to `_get_new_dates()`.

The same logic applies when moving tasks backwards.

opw-5973597

Forward-Port-Of: odoo/enterprise#119161

### Issue
When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid

If a user with only "Invoicing & Banks" rights tries to reconcile a Bank Statement with the same partner, amount, and the invoice name as the memo, the automatic reconciliation fails to properly match the payment
Instead, the invoice is incorrectly considered as Fully Paid with an unwanted extra Account Receivable line added

### Cause
When a new Bank Statement is created,
`_try_auto_reconcile_statement_lines()` is called and matches the outstanding credit, which invokes `set_line_bank_statement_line()` In 19.0, this function creates a balancing line and triggers `move._compute_checked()` to update dependencies
Especially `_compute_is_reconciled`
But checked as been replaced by `review_state`
This FW port will use an update on the `review_state` instead of the `checked`

A user with "Invoicing & Banks" rights lacks the
`account.group_account_user` group, meaning the move is not marked as `reviewed`, preventing dependencies from computing correctly Consequently, the statement line's `amount_residual` is not cleared and the line is not removed from `remaining_st_line_ids`

Later in the process, `_try_auto_reconcile_statement_lines()` is called again with `with_user(SUPERUSER_ID)`
Because the payment matching was never finalized in the previous step, the engine fallback matches against the full invoice, adding an incorrect Account Receivable line to close it

### Steps to reproduce
- Install `accountant`
- Go to Accounting / Configuration / Accounting / Journals
- Open the Bank, under Incoming Payments tab, set the Manual Payment method's Outstanding Receipts account to 101403 Outstanding Receipts
- Update the Demo user's accounting rights to Invoicing & Banks
- Log in with the Demo user
- Create and confirm an invoice for Acme Corporation (Amount: $1100)
- Register a payment on the invoice (Amount: $500, Keep open)
- Copy the invoice name
- Open the Bank Reconciliation widget from the Accounting Dashboard
- Create and add a new Bank Statement Line (Label: Invoice name, Partner: Acme Corporation, Amount: $500)
Before the fix, an unexpected Account Receivable line is created and the invoice is marked as Fully Paid

### Notes
Instead of processing the entire block under SUPERUSER_ID, which would hide the creator identity in logs and chatter, the context key `skip_account_review_check=True` is injected during the automated statement line reconciliation
This safely bypasses the group check inside `_is_user_able_to_review` for this specific automated flow

A fallback using `.with_user(SUPERUSER_ID)` is already implemented twice within the same `_try_auto_reconcile_statement_lines` method for this specific use case, but avoiding it here preserves data auditability

opw-6077137

### Issue
When you have an invoice partially paid via a method using an Outstanding Account, the payment can be kept open, leaving the invoice considered as partially paid

If a user with only "Invoicing & Banks" rights tries to reconcile a Bank Statement with the same partner, amount, and the invoice name as the memo, the automatic reconciliation fails to properly match the payment
Instead, the invoice is incorrectly considered as Fully Paid with an unwanted extra Account Receivable line added

### Cause
When a new Bank Statement is created, `_try_auto_reconcile_statement_lines()` is called and matches the outstanding credit, which invokes `set_line_bank_statement_line()`
In 19.0, this function creates a balancing line and triggers `move._compute_checked()` to update dependencies
Especially `_compute_is_reconciled`
But checked as been replaced by `review_state`
This FW port will use an update on the `review_state` instead of the `checked`

A user with "Invoicing & Banks" rights lacks the `account.group_account_user` group, meaning the move is not marked as `reviewed`, preventing dependencies from computing correctly
Consequently, the statement line's `amount_residual` is not cleared and the line is not removed from `remaining_st_line_ids`

Later in the process, `_try_auto_reconcile_statement_lines()` is called again with `with_user(SUPERUSER_ID)`
Because the payment matching was never finalized in the previous step, the engine fallback matches against the full invoice, adding an incorrect Account Receivable line to close it

### Steps to reproduce
- Install `accountant`
- Go to Accounting / Configuration / Accounting / Journals
- Open the Bank, under Incoming Payments tab, set the Manual Payment method's Outstanding Receipts account to 101403 Outstanding Receipts
- Update the Demo user's accounting rights to Invoicing & Banks
- Log in with the Demo user
- Create and confirm an invoice for Acme Corporation (Amount: $1100)
- Register a payment on the invoice (Amount: $500, Keep open)
- Copy the invoice name
- Open the Bank Reconciliation widget from the Accounting Dashboard
- Create and add a new Bank Statement Line (Label: Invoice name, Partner: Acme Corporation, Amount: $500)
Before the fix, an unexpected Account Receivable line is created and the invoice is marked as Fully Paid

### Notes
Instead of processing the entire block under SUPERUSER_ID, which would hide the creator identity in logs and chatter, the context key `skip_account_review_check=True` is injected during the automated statement line reconciliation
This safely bypasses the group check inside `_is_user_able_to_review` for this specific automated flow

A fallback using `.with_user(SUPERUSER_ID)` is already implemented twice within the same `_try_auto_reconcile_statement_lines` method for this specific use case, but avoiding it here preserves data auditability

opw-6077137

Forward-Port-Of: odoo/enterprise#120125
Forward-Port-Of: odoo/enterprise#118023

Steps to produce:
---
- Install `website_sale_loyalty`.
- Go to `Website > ecommerece > Loyalty > DIscount & Loyalty`.
- Create a new discount & loyalty program > set program type as `promotions`.
- Under Rewards, select `Free Shipping` as the reward type.
- Create a product with a price of 1000 and publish it.
- Add the product to the cart from the website.
- Observe that free shipping is automatically applied on cart.
- Attempt to remove the free shipping reward from the cart.

Issue:
---
- Free shipping (and similarly, free product rewards) cannot be removed from the cart once applied.

Root cause:
---
- At [1], the `website_sale_loyalty_delete` context is only passed when the reward type is `discount`. As a result, for free shipping and free product rewards, the context is not set. At [2], the order line is removed, but the reward is not added to `disabled_auto_rewards`. The `_auto_apply_rewards` method runs immediately afterward, detects the missing reward, and re-applies it automatically.

Fix:
---
- Since there are three reward types (discount, free shipping, and free product), the condition restricting the context to only discount rewards should be removed.

[1]https://github.com/odoo/odoo/blob/5e90858fa91348f6aa33b4f8a246e77fbb8ea63f/addons/website_sale_loyalty/models/sale_order.py#L179
[2]https://github.com/odoo/odoo/blob/5e90858fa91348f6aa33b4f8a246e77fbb8ea63f/addons/website_sale_loyalty/models/sale_order_line.py#L15-L23

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

Forward-Port-Of: odoo/odoo#261732

Fix a concurrency race condition in the product catalog where rapid quantity updates could result in incorrect final quantities on Sale Order Lines (SOL).

Steps to produce:
---
- We need a DB with too many products. Also it might not be easy to reproduce the issue locally. Try runbot.
- Open a Sale Order (SO) and open the Product Catalog.
- Rapidly change or paste quantities (e.g., changing from 1 to 100) across multiple records very fast.
- Return to the SO. Some lines intermittently retain an intermediate quantity (e.g., qty = 1) instead of the final entered value.

Cause:
---
- This is a concurrency issue. In the faulty cases, the `update_order_line_info` setting quantity to 1 takes a few seconds to resolve, while the update setting quantity to 100 resolves faster (around 200ms). This cause the SOL final quantity set to 1.

Fix:
---
- We can chain RPC calls to ensure that each request is completed before starting the next one.

Backport of ef9554ad95d5e39ab7b550db0d39454373f99aed

opw-6282877

---

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

Forward-Port-Of: odoo/odoo#270844
Forward-Port-Of: odoo/odoo#269750

Issue:
Sending payments to CFDI before its full amount is reconciled allow sending the same invoice payment several times to CFDI. So some invoices are declared as paid several times and the total amount of the payment is seen as exceeding the real total.

This fix is a back port of odoo/enterprise#108355 and aim to prevent some things the backend allow, but the front end prevents.

Following steps could be used to reproduce from 18.3.

Steps to reproduce:
- In a Mexican company
- Create an invoice A of $40 to Inmobiliaria CVA
- Confirm and send to CFDI
- Go to bank, create a new Bank transaction of $80
- reconcile with Invoice A
- Go to invoice A => click on button "Update payments" (it doesn't appear before version 18.3)
- Then sheet CFDI and Download There is the first XML sent to CFDI with payment for invoice A
- Create an invoice B of $40 to Inmobiliaria CVA
- Confirm and send to CFDI
- reconcile the transaction with Invoice B
- Go to invoice B
- Click on button "Update payments"
- Then sheet CFDI and Download There is the second XML sent to CFDI with payment for invoices A and B

Invoice A payment was sent twice to CFDI

Expected behavior:
- The "Update payment" button should appear only once the invoice payment is fully reconciled.

Current behavior:
- The update payment button appear once the invoice is reconciled with a payment.

opw-5432421

Forward-Port-Of: odoo/enterprise#119357

### Context
The previous signer status header in the sign app relied on static QWeb injected from the backend and legacy DOM manipulation (jQuery/Vanilla JS) to handle state changes like "Resend" buttons. Additionally, the horizontal layout consumed too much screen space for documents with multiple signers, and users lacked quick visual context of the document's template tags.

### Summary of Changes
This PR completely modernizes the Sign Request Control Panel header, moving it to a pure OWL architecture while vastly improving the UI/UX.

1. Architectural Refactoring (Legacy JS to OWL)

Extracted the signer status wrapper into a modern, reusable OWL public component (SignerStatusBadge) that works flawlessly in both the backend and the portal.

Ripped out fragile querySelector DOM manipulation for the "Resend" buttons. Button state (e.g., swapping a paper-plane icon for a success checkmark upon clicking) is now fully managed via reactive OWL state and clean RPC calls.

2. UI/UX Redesign

Redesigned the signer list into a compact, native Odoo <Dropdown> when multiple signers are present, saving valuable horizontal space.

Replaced bulky text buttons with clean, semantic Bootstrap/FontAwesome icons (check/clock/cross for status, paper-plane for actions) for a more modern SaaS feel.

3. Added Template Context

Reused the existing SignTemplateHeaderTags component to display the original template's tags directly in the request control panel (in read-only mode). It gracefully hides itself if no tags or template exist.

Task: 6109365

Purpose
=======

This PR addresses many improvements in the social app, the two main
ones being allowing to link your personal LinkedIn account and to post
Facebook and Instagram "Stories".

We also made a lot of UX tweaks along the way to make the social app
easier to use, with a bit of much needed polish as the app has not been
worked on a lot since it was introduced (about 7 years before this PR).

Specifications
===========

Allow the users to add their personal LinkedIn account in Social (and 
not only the page for which they are admin), and to post on them.

During the authentication process of Social, if something went wrong
we need to manually go back or enter the Odoo database URL to retry.
It can be very frustrating, and so now we open the authentication URL
in a new window, and when the process is done we close the window
and refresh the view.

Show a loading page while doing the token exchange process (which can take some time depending on the number of pages).

Allow removing the accounts from the "Connect Account" modal.

Show the icons of the selected medias in the calendar view.

Improve the way we schedule posts.

Allow the users to comment their own posts right after posting.

Allow posting stories on Facebook and Instagram.

Allow sorting the image when posting on a social media.

Use AI to write social post. Show the chars count for all medias while typing the message.

Improve the computation of the tweet length (URL must count for 23 chars and emoji for 2).

In the post form view, show the media icon instead of the media name
when selecting the accounts.

Do some refactoring to unify the name for the social post message field.

Schedule the social post with a modal, like it's done in mass-mailing.

(see each individual commits for more details)

Task-5491124

- Step to reproduce: open the salary configurator for a belgian employee with only a car to order linked to its version. Car info and simulation button are not appearing and the page reactivity is broken
- Cause:
    - Broken page reactivity is due to a promise that never resolve in willStart super call because of race condition caused by overlapping calls to a debounced function
    - Car model description is computed and displayed only when a new value is passed
    - Simulation button is rendered only on select value change
- Solution:
    - Execute `updateGross()` and `setUpBenefits()` sequentially in parent willStart to prevent overlapping salary recomputations during startup
    - Implementing a condition that handle the case of the new car value being already set in the description computation function
    - Triggering the new car change function in willStart so that the simulation button is rendered on page load

Task: 6241194

Forward-Port-Of: odoo/enterprise#120614
Forward-Port-Of: odoo/enterprise#118647

Steps to reproduce
---
1. Set an employee to work 8 hours per day.
2. Open the timesheet timer in the systray, type a duration like 8:00 and save.
3. Open the My Timesheets grid for that day.

The day is marked as overtime (yellow) even though only 8 hours were logged.

Issue
---
While the entry is open the timer keeps running and, every second, writes the elapsed time into unit_amount down to the second. https://github.com/odoo/enterprise/blob/a3c9295cf28b47f43233ac6a9f4106810842e37a/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L89-L102

When the duration is set by hand, the save skips the usual rounding and keeps the value as it is. https://github.com/odoo/enterprise/blob/a3c9295cf28b47f43233ac6a9f4106810842e37a/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L120-L132

So the clean 8:00 the user typed gets a few extra seconds from the next timer tick (8h 1s, stored as 8.000277) and is saved with them. The seconds are hidden in the HH:MM display but are enough to push the day above its working hours, so the grid paints it as overtime. This timer form is new in saas-19.2 (c3dac6ccdb5), which is why earlier versions are not affected.

The fix ignores timer ticks once the duration has been set by hand, so the typed value is kept.

opw-6180676
---

Forward-Port-Of: odoo/enterprise#120931
Forward-Port-Of: odoo/enterprise#120601

Several related fixes around the AvaTax connection settings:

- Surface an unconnected "Avalara Included" setup instead of silently using Direct credentials. Filling Direct credentials, switching to Included, then not completing the connection (link/migrate/create) left the company looking configured through those leftover credentials: the user believed they were on Included while a request either silently used Direct or crashed on the unset IAP proxy user (ensure_one). Direct credentials now only count in Direct mode, so the not-connected state raises the usual RedirectWarning pointing to the configuration.

- Group nexus locations by country in the connection test result. The list dumped every nexus row flat, so countries appeared alongside their own regions and each jurisdiction repeated once per tax type (e.g. "California" dozens of times). Group by country, drop the country-wide rows, dedupe and sort, with a short summary line.

- Make the "Help me choose" documentation link version-aware via the documentation_link widget instead of the /latest/ alias, which redirects to the latest major release (19.0) where the AvaTax docs don't exist.

task-6295272

Forward-Port-Of: odoo/enterprise#120761

Currently, an error occurs when opening the gantt view of work orders.

**Steps to Reproduce:**
 - Install `mrp_workorder` with demo data.
 - Go to `Settings` > `Technical` > `Resource` > `Resources`.
 - Open the `Assembly 1` resource and remove its `working time`.
 - Go to `Manufacturing` > `Operations` > `Work Orders`.
 - Switch to the `Gantt view`.

`KeyError: 22`

when the user opens the Gantt view, the system checks the unavailability of work centers and employees 
based on their resource calendars. While computing unavailable intervals for resources [1], resources 
without a calendar are flexible resources. If no leave interval exists within the specified start and end 
range that matches the domain, the resource is not included in the result [2]. when updating the 
unavailable intervals dictionary [3], the resource is missing. As a result, when it later tries to access 
the unavailable intervals for that resource, it raises an error [4].

This commit prevents the error by safely handling resources that are not present in the unavailable 
intervals dictionary by using an empty list instead.

[1]: https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_resource.py#L186

[2]: https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_calendar.py#L532-L536

[3]:https://github.com/odoo/odoo/blob/1f666de440479dd3d30b7b6cf7c42862c5fcb37a/addons/resource/models/resource_resource.py#L187

[4] https://github.com/odoo/enterprise/blob/47f2e9e88fa0bbb8852fe7734c6bece4dca8b9d0/mrp_workorder/models/mrp_workorder.py#L692-L694

sentry-7525704808

Forward-Port-Of: odoo/enterprise#119385

### Steps to reproduce:

- In the settings enable: "Units of Measure & Packagings", "Storage Locations"
- Create a product in units and register 1 unit in stock
- Inventory > Operations > Adjustments > Physical Inventory
- Select your line and request a count > Set Current Value
- Inventory > Configurations > units of measures > UOM categories
- Select unit and archive it
- Go to the barcode app > Click Count inventory
### > Owl error: Uncaught promise

### Cause of the issue:

Since the uom used on the quant is archived, it is not found by the search used to fill the barcodeCache:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/models/stock_quant.py#L104-L106 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_model.js#L37-L39 However, if the uom is not present in the barcode cache the `BarcodeQautnModel` will fail to createLinesState whihc raises a missing error:
https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/models/barcode_quant_model.js#L712 https://github.com/odoo/enterprise/blob/26546bcd3beebc7f65ce08385441b6284b46598e/stock_barcode/static/src/lazy_barcode_cache.js#L107-L110

opw-6250090

Forward-Port-Of: odoo/enterprise#120683
Forward-Port-Of: odoo/enterprise#118813

This PR is one of many triggered by responses from Luxembourg auditors. See PR #113316 for a full list of these PRs.

As described in PR #117799, the \CustomerID and \SupplierID elements on \Transaction\Line elements is determined by a partner's `customer_rank` and `supplier_rank`.  This is a binary designation, one or the other.

The Luxembourg FAIA report requires that less than 30% of \Transaction\Line elements with payable accounts (class 6) can not have \SupplierID. The same applies for \Transaction\Line elements with receivable accounts (class 7) and the \CustomerID element.

TSB clarified that any partner on an receivable or payable line should be added to the Customer list or Supplier list respectively https://github.com/odoo/enterprise/pull/100749#issuecomment-3655127511. In addition, I verified that Luxembourg's analysis of four separate FAIA files (from ticket 5427296) aligns with this expectation. 

<img width="1322" height="690" alt="image" src="https://github.com/user-attachments/assets/1a82f99e-5b32-4dbb-96e1-1b25bab2629b" />

This commit adds partners to the \Supplier and \Customer lists if they have any payable or receivable lines, respectively. It also picks between the \CustomerID and \SupplierID based on a line's `account_type`. This logic is applied to `account_saft` and updates the other, country-specific SAFT reports where appropriate. 

It also retains the previous `customer_rank` and `supplier_rank` logic as a fallback for older XML reports and for accounts other than `asset_receivable` or `liability_payable`.

opw-6118024

Forward-Port-Of: odoo/enterprise#120790
Forward-Port-Of: odoo/enterprise#118714

* By removing the access right check, we often are able to remove a `JOIN` on `account_move`. This `JOIN` was forcing the planner to take a worse plan and do a lot more work.
* The new index allows many optimizations in the query plan, including removing the need for various `Scan`, `Nested Loop` nodes.

|            | Unallocated Earnings | Trial Balance | Code Engine |
|------------|----------------------|---------------|-------------|
| Before     |                  38s |           22s |         15s |
| W/O access |                  11s |            6s |          5s |
| & W Index  |                   6s |            6s |          7s |

Note that these timings are done on hot queries. The index would help in all the cases because it allows to avoid many Rows Removed by Filter.

Future work will also improve the cases where the domain contains:
```python
[
    '|',
    ('account_id.include_initial_balance', '=', True),
    ('date', '>=', fiscalyear_start),
]
```
When splitting this in two queries, the new index also helps keeping the number of rows filtered very low.

________________________________________________________________________

 # `_get_unallocated_earnings_lines`

 ## Before

```sql
  SELECT account_move_line.company_id,
         COALESCE(SUM((account_move_line.balance) * COALESCE(account_currency_table.rate, 1)), 0.0) AS balance,
         COALESCE(SUM((account_move_line.debit) * COALESCE(account_currency_table.rate, 1)), 0.0) AS debit,
         COALESCE(SUM((account_move_line.credit) * COALESCE(account_currency_table.rate, 1)), 0.0) AS credit
    FROM "account_move_line" LEFT JOIN "account_account" AS "account_move_line__account_id" ON ("account_move_line"."account_id" = "account_move_line__account_id"."id") JOIN "account_move" AS "account_move_line__move_id" ON ("account_move_line"."move_id" = "account_move_line__move_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 = '_trial_balance_middle_periods' OR account_currency_table.period_key IS NULL)
   WHERE (("account_move_line"."account_id" IS NOT NULL AND ("account_move_line__account_id"."account_type" IN ('equity_unaffected') OR split_part("account_move_line__account_id"."account_type", '_', 1) IN ('income', 'expense'))) AND "account_move_line"."company_id" IN (1) AND "account_move_line"."date" < '2026-01-01'::date AND "account_move_line"."date" <= '2026-04-30'::date AND "account_move_line"."display_type" NOT IN ('line_section', 'line_subsection', 'line_note') AND "account_move_line"."journal_id" IN (5, 181, 2, 407, 571, 570, 506, 169, 271, 167, 121, 6, 9, 241, 655, 623, 242, 63, 331, 123, 3, 18, 142, 4, 320, 170, 218, 236, 97, 143, 343, 64, 521, 660, 139, 344, 118, 119, 274, 179, 441, 619, 439, 89, 522, 91, 17, 8, 128, 135, 19, 10, 7, 180, 134, 124, 52, 53, 137, 98, 1, 96, 57) AND "account_move_line"."parent_state" IN ('posted')) AND (("account_move_line"."company_id" IN (1) OR "account_move_line"."company_id" IS NULL) OR ("account_move_line__move_id"."invoice_user_id" IN (1078415) OR "account_move_line__move_id"."partner_id" IN (1889993)))
GROUP BY account_move_line.company_id;

                                                                                                                                                                                                                            QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize GroupAggregate  (cost=1001.44..1409209.41 rows=1 width=100) (actual time=38461.802..38461.890 rows=1 loops=1)
   ->  Gather  (cost=1001.44..1409209.38 rows=1 width=100) (actual time=38461.786..38461.877 rows=2 loops=1)
         Workers Planned: 1
         Workers Launched: 1
         ->  Partial GroupAggregate  (cost=1.44..1408209.28 rows=1 width=100) (actual time=32388.314..32388.316 rows=1 loops=2)
               ->  Nested Loop  (cost=1.44..1407952.19 rows=17138 width=18) (actual time=0.371..31450.650 rows=2829550 loops=2)
                     ->  Nested Loop  (cost=1.00..1371951.59 rows=38651 width=22) (actual time=0.286..20582.850 rows=2829550 loops=2)
                           ->  Parallel Index Scan using account_account_pkey on account_account account_move_line__account_id  (cost=0.29..1862.11 rows=66 width=4) (actual time=0.210..5.952 rows=1936 loops=2)
                                 Filter: (((account_type)::text = 'equity_unaffected'::text) OR (split_part((account_type)::text, '_'::text, 1) = ANY ('{income,expense}'::text[])))
                                 Rows Removed by Filter: 2294
                           ->  Index Scan using account_move_line_account_id_date_idx on account_move_line  (cost=0.72..20697.02 rows=6191 width=26) (actual time=5.337..10.510 rows=1462 loops=3872)
                                 Index Cond: ((account_id = account_move_line__account_id.id) AND (account_id IS NOT NULL) AND (date < '2026-01-01'::date) AND (date <= '2026-04-30'::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 ('{5,181,2,407,571,570,506,169,271,167,121,6,9,241,655,623,242,63,331,123,3,18,142,4,320,170,218,236,97,143,343,64,521,660,139,344,118,119,274,179,441,619,439,89,522,91,17,8,128,135,19,10,7,180,134,124,52,53,137,98,1,96,57}'::integer[])))
                                 Rows Removed by Filter: 1570
                     ->  Index Scan using account_move_pkey on account_move account_move_line__move_id  (cost=0.43..0.92 rows=1 width=12) (actual time=0.004..0.004 rows=1 loops=5659099)
                           Index Cond: (id = account_move_line.move_id)
                           Filter: ((account_move_line.company_id = 1) OR (account_move_line.company_id IS NULL) OR (invoice_user_id = 1078415) OR (partner_id = 1889993))
 Planning Time: 9.433 ms
 Execution Time: 38461.932 ms
```

 ## Without access rights

```sql
  SELECT account_move_line.company_id,
         COALESCE(SUM((account_move_line.balance) * COALESCE(account_currency_table.rate, 1)), 0.0) AS balance,
         COALESCE(SUM((account_move_line.debit) * COALESCE(account_currency_table.rate, 1)), 0.0) AS debit,
         COALESCE(SUM((account_move_line.credit) * COALESCE(account_currency_table.rate, 1)), 0.0) AS credit
    FROM "account_move_line" LEFT 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 = '_trial_balance_middle_periods' OR account_currency_table.period_key IS NULL)
   WHERE (("account_move_line"."account_id" IS NOT NULL AND ("account_move_line__account_id"."account_type" IN ('equity_unaffected') OR split_part("account_move_line__account_id"."account_type", '_', 1) IN ('income', 'expense'))) AND "account_move_line"."company_id" IN (1) AND "account_move_line"."date" < '2026-01-01'::date AND "account_move_line"."date" <= '2026-04-30'::date AND "account_move_line"."display_type" NOT IN ('line_section', 'line_subsection', 'line_note') AND "account_move_line"."journal_id" IN (5, 181, 2, 407, 571, 570, 506, 169, 271, 167, 121, 6, 9, 241, 655, 623, 242, 63, 331, 123, 3, 18, 142, 4, 320, 170, 218, 236, 97, 143, 343, 64, 521, 660, 139, 344, 118, 119, 274, 179, 441, 619, 439, 89, 522, 91, 17, 8, 128, 135, 19, 10, 7, 180, 134, 124, 52, 53, 137, 98, 1, 96, 57) AND "account_move_line"."parent_state" IN ('posted'))
GROUP BY account_move_line.company_id;
                                                                                                                                                                                                                   QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 GroupAggregate  (cost=0.72..2326905.01 rows=1 width=100) (actual time=11392.164..11392.166 rows=1 loops=1)
   ->  Nested Loop  (cost=0.72..2325919.40 rows=65706 width=18) (actual time=0.753..9939.918 rows=5659099 loops=1)
         ->  Seq Scan on account_account account_move_line__account_id  (cost=0.00..919.07 rows=112 width=4) (actual time=0.011..4.111 rows=3872 loops=1)
               Filter: (((account_type)::text = 'equity_unaffected'::text) OR (split_part((account_type)::text, '_'::text, 1) = ANY ('{income,expense}'::text[])))
               Rows Removed by Filter: 4589
         ->  Index Scan using account_move_line_account_id_date_idx on account_move_line  (cost=0.72..20697.02 rows=6191 width=22) (actual time=1.180..2.469 rows=1462 loops=3872)
               Index Cond: ((account_id = account_move_line__account_id.id) AND (account_id IS NOT NULL) AND (date < '2026-01-01'::date) AND (date <= '2026-04-30'::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 ('{5,181,2,407,571,570,506,169,271,167,121,6,9,241,655,623,242,63,331,123,3,18,142,4,320,170,218,236,97,143,343,64,521,660,139,344,118,119,274,179,441,619,439,89,522,91,17,8,128,135,19,10,7,180,134,124,52,53,137,98,1,96,57}'::integer[])))
               Rows Removed by Filter: 1570
 Planning Time: 0.630 ms
 Execution Time: 11392.193 ms
```

 ## With the new index

```sql
                                                                                                                                      QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 GroupAggregate  (cost=0.72..1224754.13 rows=1 width=100) (actual time=6021.088..6021.090 rows=1 loops=1)
   ->  Nested Loop  (cost=0.72..1223768.52 rows=65706 width=18) (actual time=0.140..4563.265 rows=5659099 loops=1)
         ->  Seq Scan on account_account account_move_line__account_id  (cost=0.00..919.07 rows=112 width=4) (actual time=0.009..3.596 rows=3872 loops=1)
               Filter: (((account_type)::text = 'equity_unaffected'::text) OR (split_part((account_type)::text, '_'::text, 1) = ANY ('{income,expense}'::text[])))
               Rows Removed by Filter: 4589
         ->  Index Scan using idx_aml_reporting on account_move_line  (cost=0.72..10856.39 rows=6191 width=22) (actual time=0.002..1.080 rows=1462 loops=3872)
               Index Cond: ((company_id = 1) AND (account_id = account_move_line__account_id.id) AND (account_id IS NOT NULL) AND (date < '2026-01-01'::date) AND (date <= '2026-04-30'::date) AND ((parent_state)::text = 'posted'::text))
               Filter: (journal_id = ANY ('{5,181,2,407,571,570,506,169,271,167,121,6,9,241,655,623,242,63,331,123,3,18,142,4,320,170,218,236,97,143,343,64,521,660,139,344,118,119,274,179,441,619,439,89,522,91,17,8,128,135,19,10,7,180,134,124,52,53,137,98,1,96,57}'::integer[]))
               Rows Removed by Filter: 0
 Planning Time: 1.258 ms
 Execution Time: 6021.114 ms
```

 # `_report_custom_engine_trial_balance`

 ## Before

```sql
SELECT
    "account_move_line"."account_id" AS "groupby_key_account_id",
    COALESCE(SUM((account_move_line.balance) * COALESCE(account_currency_table.rate, 1)), 0.0) AS balance,
    COALESCE(SUM((account_move_line.debit) * COALESCE(account_currency_table.rate, 1)), 0.0) AS debit,
    COALESCE(SUM((account_move_line.credit) * COALESCE(account_currency_table.rate, 1)), 0.0) AS credit
FROM "account_move_line" LEFT JOIN "account_account" AS "account_move_line__account_id" ON ("account_move_line"."account_id" = "account_move_line__account_id"."id") JOIN "account_move" AS "account_move_line__move_id" ON ("account_move_line"."move_id" = "account_move_line__move_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 = '_trial_balance_middle_periods' OR account_currency_table.period_key IS NULL)
WHERE ("account_move_line"."company_id" IN (1) AND "account_move_line"."date" <= '2026-04-30'::date AND "account_move_line"."display_type" NOT IN ('line_section', 'line_subsection', 'line_note') AND "account_move_line"."journal_id" IN (5, 181, 2, 407, 571, 570, 506, 169, 271, 167, 121, 6, 9, 241, 655, 623, 242, 63, 331, 123, 3, 18, 142, 4, 320, 170, 218, 236, 97, 143, 343, 64, 521, 660, 139, 344, 118, 119, 274, 179, 441, 619, 439, 89, 522, 91, 17, 8, 128, 135, 19, 10, 7, 180, 134, 124, 52, 53, 137, 98, 1, 96, 57) AND "account_move_line"."parent_state" IN ('posted') AND (("account_move_line"."account_id" IS NOT NULL AND ("account_move_line__account_id"."account_type" NOT IN ('equity_unaffected') AND (split_part("account_move_line__account_id"."account_type", '_', 1) NOT IN ('income', 'expense') OR split_part("account_move_line__account_id"."account_type", '_', 1) IS NULL))) OR "account_move_line"."date" >= '2026-01-01'::date)) AND (("account_move_line"."company_id" IN (1) OR "account_move_line"."company_id" IS NULL) OR ("account_move_line__move_id"."invoice_user_id" IN (1078415) OR "account_move_line__move_id"."partner_id" IN (1889993)))
GROUP BY "groupby_key_account_id";
                                                                                                                                                                                                                 QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize GroupAggregate  (cost=3845774.51..3845891.36 rows=779 width=100) (actual time=22590.401..22953.611 rows=622 loops=1)
   Group Key: account_move_line.account_id
   ->  Gather Merge  (cost=3845774.51..3845864.10 rows=779 width=100) (actual time=22590.390..22952.586 rows=1116 loops=1)
         Workers Planned: 1
         Workers Launched: 1
         ->  Sort  (cost=3844774.50..3844776.45 rows=779 width=100) (actual time=22562.645..22562.672 rows=558 loops=2)
               Sort Key: account_move_line.account_id
               Sort Method: quicksort  Memory: 151kB
               Worker 0:  Sort Method: quicksort  Memory: 148kB
               ->  Partial HashAggregate  (cost=3844723.45..3844737.09 rows=779 width=100) (actual time=22562.148..22562.519 rows=558 loops=2)
                     Group Key: account_move_line.account_id
                     Batches: 1  Memory Usage: 1065kB
                     Worker 0:  Batches: 1  Memory Usage: 1065kB
                     ->  Hash Left Join  (cost=1139137.12..3819476.57 rows=1442679 width=18) (actual time=10306.112..21012.284 rows=4067550 loops=2)
                           Hash Cond: (account_move_line.account_id = account_move_line__account_id.id)
                           Filter: (((account_move_line.account_id IS NOT NULL) AND ((account_move_line__account_id.account_type)::text <> 'equity_unaffected'::text) AND ((split_part((account_move_line__account_id.account_type)::text, '_'::text, 1) <> ALL ('{income,expense}'::text[])) OR (split_part((account_move_line__account_id.account_type)::text, '_'::text, 1) IS NULL))) OR (account_move_line.date >= '2026-01-01'::date))
                           Rows Removed by Filter: 2829550
                           ->  Parallel Hash Join  (cost=1138175.75..3814586.90 rows=1494949 width=22) (actual time=6131.481..19429.577 rows=6897099 loops=2)
                                 Hash Cond: (account_move_line.move_id = account_move_line__move_id.id)
                                 Join Filter: ((account_move_line.company_id = 1) OR (account_move_line.company_id IS NULL) OR (account_move_line__move_id.invoice_user_id = 1078415) OR (account_move_line__move_id.partner_id = 1889993))
                                 ->  Parallel Index Scan using idx_wan on account_move_line  (cost=0.56..2667561.57 rows=3371483 width=30) (actual time=0.182..10737.129 rows=6897099 loops=2)
                                       Index Cond: ((company_id = 1) AND (journal_id = ANY ('{5,181,2,407,571,570,506,169,271,167,121,6,9,241,655,623,242,63,331,123,3,18,142,4,320,170,218,236,97,143,343,64,521,660,139,344,118,119,274,179,441,619,439,89,522,91,17,8,128,135,19,10,7,180,134,124,52,53,137,98,1,96,57}'::integer[])))
                                       Filter: ((date <= '2026-04-30'::date) AND ((parent_state)::text = 'posted'::text) AND ((display_type)::text <> ALL ('{line_section,line_subsection,line_note}'::text[])))
                                       Rows Removed by Filter: 303744
                                 ->  Parallel Hash  (cost=1085103.97..1085103.97 rows=4245697 width=12) (actual time=6087.945..6087.946 rows=4795563 loops=2)
                                       Buckets: 16777216  Batches: 1  Memory Usage: 539328kB
                                       ->  Parallel Seq Scan on account_move account_move_line__move_id  (cost=0.00..1085103.97 rows=4245697 width=12) (actual time=0.132..4719.857 rows=4795563 loops=2)
                           ->  Hash  (cost=855.61..855.61 rows=8461 width=16) (actual time=4.600..4.601 rows=8461 loops=2)
                                 Buckets: 16384  Batches: 1  Memory Usage: 535kB
                                 ->  Seq Scan on account_account account_move_line__account_id  (cost=0.00..855.61 rows=8461 width=16) (actual time=0.013..3.674 rows=8461 loops=2)
 Planning Time: 29.548 ms
 Execution Time: 22953.702 ms
```

 ## Without access rights

```sql
SELECT
    "account_move_line"."account_id" AS "groupby_key_account_id",
    COALESCE(SUM((account_move_line.balance) * COALESCE(account_currency_table.rate, 1)), 0.0) AS balance,
    COALESCE(SUM((account_move_line.debit) * COALESCE(account_currency_table.rate, 1)), 0.0) AS debit,
    COALESCE(SUM((account_move_line.credit) * COALESCE(account_currency_table.rate, 1)), 0.0) AS credit
FROM "account_move_line" LEFT 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 = '_trial_balance_middle_periods' OR account_currency_table.period_key IS NULL)
WHERE ("account_move_line"."company_id" IN (1) AND "account_move_line"."date" <= '2026-04-30'::date AND "account_move_line"."display_type" NOT IN ('line_section', 'line_subsection', 'line_note') AND "account_move_line"."journal_id" IN (5, 181, 2, 407, 571, 570, 506, 169, 271, 167, 121, 6, 9, 241, 655, 623, 242, 63, 331, 123, 3, 18, 142, 4, 320, 170, 218, 236, 97, 143, 343, 64, 521, 660, 139, 344, 118, 119, 274, 179, 441, 619, 439, 89, 522, 91, 17, 8, 128, 135, 19, 10, 7, 180, 134, 124, 52, 53, 137, 98, 1, 96, 57) AND "account_move_line"."parent_state" IN ('posted') AND (("account_move_line"."account_id" IS NOT NULL AND ("account_move_line__account_id"."account_type" NOT IN ('equity_unaffected') AND (split_part("account_move_line__account_id"."account_type", '_', 1) NOT IN ('income', 'expense') OR split_part("account_move_line__account_id"."account_type", '_', 1) IS NULL))) OR "account_move_line"."date" >= '2026-01-01'::date))
GROUP BY "groupby_key_account_id";
                                                                                                                                                                                                                                  QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize GroupAggregate  (cost=2875894.51..2876117.19 rows=779 width=100) (actual time=5505.661..5806.173 rows=622 loops=1)
   Group Key: account_move_line.account_id
   ->  Gather Merge  (cost=2875894.51..2876076.29 rows=1558 width=100) (actual time=5505.647..5804.748 rows=1622 loops=1)
         Workers Planned: 2
         Workers Launched: 2
         ->  Sort  (cost=2874894.49..2874896.43 rows=779 width=100) (actual time=5491.557..5491.581 rows=541 loops=3)
               Sort Key: account_move_line.account_id
               Sort Method: quicksort  Memory: 150kB
               Worker 0:  Sort Method: quicksort  Memory: 144kB
               Worker 1:  Sort Method: quicksort  Memory: 143kB
               ->  Partial HashAggregate  (cost=2874843.44..2874857.07 rows=779 width=100) (actual time=5491.055..5491.420 rows=541 loops=3)
                     Group Key: account_move_line.account_id
                     Batches: 1  Memory Usage: 1065kB
                     Worker 0:  Batches: 1  Memory Usage: 1065kB
                     Worker 1:  Batches: 1  Memory Usage: 1065kB
                     ->  Hash Left Join  (cost=962.09..2834512.35 rows=2304634 width=18) (actual time=6.720..4466.785 rows=2711700 loops=3)
                           Hash Cond: (account_move_line.account_id = account_move_line__account_id.id)
                           Filter: (((account_move_line.account_id IS NOT NULL) AND ((account_move_line__account_id.account_type)::text <> 'equity_unaffected'::text) AND ((split_part((account_move_line__account_id.account_type)::text, '_'::text, 1) <> ALL ('{income,expense}'::text[])) OR (split_part((account_move_line__account_id.account_type)::text, '_'::text, 1) IS NULL))) OR (account_move_line.date >= '2026-01-01'::date))
                           Rows Removed by Filter: 1886366
                           ->  Parallel Index Scan using account_move_line__company_id_index on account_move_line  (cost=0.72..2827275.65 rows=2388134 width=22) (actual time=0.080..3433.378 rows=4598066 loops=3)
                                 Index Cond: (company_id = 1)
                                 Filter: ((date <= '2026-04-30'::date) AND ((parent_state)::text = 'posted'::text) AND ((display_type)::text <> ALL ('{line_section,line_subsection,line_note}'::text[])) AND (journal_id = ANY ('{5,181,2,407,571,570,506,169,271,167,121,6,9,241,655,623,242,63,331,123,3,18,142,4,320,170,218,236,97,143,343,64,521,660,139,344,118,119,274,179,441,619,439,89,522,91,17,8,128,135,19,10,7,180,134,124,52,53,137,98,1,96,57}'::integer[])))
                                 Rows Removed by Filter: 202669
                           ->  Hash  (cost=855.61..855.61 rows=8461 width=16) (actual time=6.531..6.531 rows=8461 loops=3)
                                 Buckets: 16384  Batches: 1  Memory Usage: 535kB
                                 ->  Seq Scan on account_account account_move_line__account_id  (cost=0.00..855.61 rows=8461 width=16) (actual time=0.022..5.568 rows=8461 loops=3)
 Planning Time: 10.803 ms
 Execution Time: 5806.252 ms
```

 ## With the new index

```sql
                                                                                                                                                                                                                                                                QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize GroupAggregate  (cost=3804515.40..3804572.57 rows=200 width=100) (actual time=6225.615..6565.399 rows=622 loops=1)
   Group Key: account_move_line.account_id
   ->  Gather Merge  (cost=3804515.40..3804562.07 rows=400 width=100) (actual time=6225.605..6564.588 rows=853 loops=1)
         Workers Planned 2
         Workers Launched: 2
         ->  Sort  (cost=3803515.37..3803515.87 rows=200 width=100) (actual time=6211.591..6211.605 rows=284 loops=3)
               Sort Key: account_move_line.account_id
               Sort Method: quicksort  Memory: 71kB
               Worker 0:  Sort Method: quicksort  Memory: 68kB
               Worker 1:  Sort Method: quicksort  Memory: 126kB
               ->  Partial HashAggregate  (cost=3803504.23..3803507.73 rows=200 width=100) (actual time=6211.303..6211.503 rows=284 loops=3)
                     Group Key: account_move_line.account_id
                     Batches: 1  Memory Usage: 288kB
                     Worker 0:  Batches: 1  Memory Usage: 288kB
                     Worker 1:  Batches: 1  Memory Usage: 569kB
                     ->  Parallel Append  (cost=7.68..3778010.68 rows=2549355 width=100) (actual time=472.875..5759.570 rows=2937896 loops=3)
                           ->  Parallel Bitmap Heap Scan on account_move_line  (cost=380080.85..946147.41 rows=259602 width=100) (actual time=1418.158..3029.272 rows=1054880 loops=1)
                                 Recheck Cond: ((journal_id = ANY ('{5,181,2,407,571,570,506,169,271,167,121,6,9,241,655,623,242,63,331,123,3,18,142,4,320,170,218,236,97,143,343,64,521,660,139,344,118,119,274,179,441,619,439,89,522,91,17,8,128,135,19,10,7,180,134,124,52,53,137,98,1,96,57}'::integer[])) AND (company_id = 1) AND (date <= '2026-04-30'::date) AND (date >= '2026-01-01'::date) AND ((parent_state)::text = 'posted'::text) AND ((display_type)::text <> ALL ('{line_section,line_subsection,line_note}'::text[])))
                                 ->  BitmapAnd  (cost=380080.69..380080.69 rows=623044 width=0) (actual time=1321.505..1321.506 rows=0 loops=1)
                                       ->  Bitmap Index Scan on account_move_line__journal_id_index  (cost=0.00..158146.78 rows=14398682 width=0) (actual time=1100.520..1100.520 rows=14401687 loops=1)
                                             Index Cond: (journal_id = ANY ('{5,181,2,407,571,570,506,169,271,167,121,6,9,241,655,623,242,63,331,123,3,18,142,4,320,170,218,236,97,143,343,64,521,660,139,344,118,119,274,179,441,619,439,89,522,91,17,8,128,135,19,10,7,180,134,124,52,53,137,98,1,96,57}'::integer[]))
                                       ->  Bitmap Index Scan on idx_aml_reporting  (cost=0.00..221622.14 rows=1389653 width=0) (actual time=161.288..161.288 rows=1054880 loops=1)
                                             Index Cond: ((company_id = 1) AND (date <= '2026-04-30'::date) AND (date >= '2026-01-01'::date) AND ((parent_state)::text = 'posted'::text))
                           ->  Merge Join  (cost=7.68..2819116.49 rows=2289753 width=100) (actual time=44.892..4575.995 rows=2586269 loops=3)
                                 Merge Cond: (account_move_line_1.account_id = account_move_line__account_id.id)
                                 ->  Parallel Index Scan using idx_aml_reporting on account_move_line account_move_line_1  (cost=0.72..2853823.83 rows=2320470 width=18) (actual time=0.042..3730.932 rows=4598051 loops=3)
                                       Index Cond: ((company_id = 1) AND (account_id IS NOT NULL) AND (date <= '2026-04-30'::date) AND ((parent_state)::text = 'posted'::text))
                                       Filter: (journal_id = ANY ('{5,181,2,407,571,570,506,169,271,167,121,6,9,241,655,623,242,63,331,123,3,18,142,4,320,170,218,236,97,143,343,64,521,660,139,344,118,119,274,179,441,619,439,89,522,91,17,8,128,135,19,10,7,180,134,124,52,53,137,98,1,96,57}'::integer[]))
                                       Rows Removed by Filter: 173
                                 ->  Index Scan using account_account_pkey on account_account account_move_line__account_id  (cost=0.29..1071.81 rows=8349 width=4) (actual time=0.043..3.777 rows=4474 loops=3)
                                       Filter: (((account_type)::text <> 'equity_unaffected'::text) AND ((split_part((account_type)::text, '_'::text, 1) <> ALL ('{income,expense}'::text[])) OR (split_part((account_type)::text, '_'::text, 1) IS NULL)))
                                       Rows Removed by Filter: 3831
 Planning Time: 1.112 ms
 Execution Time: 6565.487 ms
```

 # `_compute_formula_batch_with_engine_account_codes`

 ## Before

```sql
SELECT
    account_move_line.account_id AS account_id,
    SUM((account_move_line.balance) * COALESCE(account_currency_table.rate, 1)) AS sum,
    COUNT(account_move_line.id) AS aml_count

FROM "account_move_line" JOIN "account_move" AS "account_move_line__move_id" ON ("account_move_line"."move_id" = "account_move_line__move_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 = 'None_2026-06-10' OR account_currency_table.period_key IS NULL)

WHERE ("account_move_line"."company_id" IN (1) AND "account_move_line"."date" <= '2026-06-10'::date AND "account_move_line"."display_type" NOT IN ('line_section', 'line_subsection', 'line_note') AND "account_move_line"."journal_id" IN (5, 181, 2, 407, 571, 570, 506, 169, 271, 167, 121, 6, 9, 241, 655, 623, 242, 63, 331, 123, 3, 18, 142, 4, 320, 170, 218, 236, 97, 143, 343, 64, 521, 660, 139, 344, 118, 119, 274, 179, 441, 619, 439, 89, 522, 91, 17, 8, 128, 135, 19, 10, 7, 180, 134, 124, 52, 53, 137, 98, 1, 96, 57) AND "account_move_line"."parent_state" IN ('posted')) AND (("account_move_line"."company_id" IN (1) OR "account_move_line"."company_id" IS NULL) OR ("account_move_line__move_id"."invoice_user_id" IN (1078415) OR "account_move_line__move_id"."partner_id" IN (1889993)))
GROUP BY account_move_line.account_id;
                                                                                                                                                                                                                                             QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize GroupAggregate  (cost=4119792.83..4119999.93 rows=779 width=44) (actual time=15387.279..15724.790 rows=839 loops=1)
   Group Key: account_move_line.account_id
   ->  Gather Merge  (cost=4119792.83..4119974.61 rows=1558 width=44) (actual time=15387.268..15723.982 rows=2202 loops=1)
         Workers Planned: 2
         Workers Launched: 2
         ->  Sort  (cost=4118792.81..4118794.76 rows=779 width=44) (actual time=15360.304..15360.333 rows=734 loops=3)
               Sort Key: account_move_line.account_id
               Sort Method: quicksort  Memory: 102kB
               Worker 0:  Sort Method: quicksort  Memory: 99kB
               Worker 1:  Sort Method: quicksort  Memory: 99kB
               ->  Partial HashAggregate  (cost=4118745.66..4118755.40 rows=779 width=44) (actual time=15359.911..15360.156 rows=734 loops=3)
                     Group Key: account_move_line.account_id
                     Batches: 1  Memory Usage: 553kB
                     Worker 0:  Batches: 1  Memory Usage: 553kB
                     Worker 1:  Batches: 1  Memory Usage: 553kB
                     ->  Parallel Hash Join  (cost=1138175.34..4107895.66 rows=1085000 width=14) (actual time=4293.304..14318.483 rows=4681102 loops=3)
                           Hash Cond: (account_move_line.move_id = account_move_line__move_id.id)
                           Join Filter: ((account_move_line.company_id = 1) OR (account_move_line.company_id IS NULL) OR (account_move_line__move_id.invoice_user_id = 1078415) OR (account_move_line__move_id.partner_id = 1889993))
                           ->  Parallel Seq Scan on account_move_line  (cost=0.16..2963297.25 rows=2446945 width=22) (actual time=0.113..8270.809 rows=4681102 loops=3)
                                 Filter: ((date <= '2026-06-10'::date) AND (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 ('{5,181,2,407,571,570,506,169,271,167,121,6,9,241,655,623,242,63,331,123,3,18,142,4,320,170,218,236,97,143,343,64,521,660,139,344,118,119,274,179,441,619,439,89,522,91,17,8,128,135,19,10,7,180,134,124,52,53,137,98,1,96,57}'::integer[])))
                                 Rows Removed by Filter: 6023968
                           ->  Parallel Hash  (cost=1085103.97..1085103.97 rows=4245697 width=12) (actual time=4266.392..4266.392 rows=3197042 loops=3)
                                 Buckets: 16777216  Batches: 1  Memory Usage: 539360kB
                                 ->  Parallel Seq Scan on account_move account_move_line__move_id  (cost=0.00..1085103.97 rows=4245697 width=12) (actual time=0.059..3265.827 rows=3197042 loops=3)
 Planning Time: 6.028 ms
 Execution Time: 15724.870 ms
```

 ## Without access rights

```sql
SELECT
    account_move_line.account_id AS account_id,
    SUM((account_move_line.balance) * COALESCE(account_currency_table.rate, 1)) AS sum,
    COUNT(account_move_line.id) AS aml_count

FROM "account_move_line"

    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 = 'None_2026-06-10' OR account_currency_table.period_key IS NULL)

WHERE ("account_move_line"."company_id" IN (1) AND "account_move_line"."date" <= '2026-06-10'::date AND "account_move_line"."display_type" NOT IN ('line_section', 'line_subsection', 'line_note') AND "account_move_line"."journal_id" IN (5, 181, 2, 407, 571, 570, 506, 169, 271, 167, 121, 6, 9, 241, 655, 623, 242, 63, 331, 123, 3, 18, 142, 4, 320, 170, 218, 236, 97, 143, 343, 64, 521, 660, 139, 344, 118, 119, 274, 179, 441, 619, 439, 89, 522, 91, 17, 8, 128, 135, 19, 10, 7, 180, 134, 124, 52, 53, 137, 98, 1, 96, 57) AND "account_move_line"."parent_state" IN ('posted'))
GROUP BY account_move_line.account_id;

                                                                                                                                                                                                                               QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize GroupAggregate  (cost=2852792.27..2852999.37 rows=779 width=44) (actual time=4663.910..4980.515 rows=839 loops=1)
   Group Key: account_move_line.account_id
   ->  Gather Merge  (cost=2852792.27..2852974.05 rows=1558 width=44) (actual time=4663.900..4979.680 rows=2214 loops=1)
         Workers Planned: 2
         Workers Launched: 2
         ->  Sort  (cost=2851792.25..2851794.20 rows=779 width=44) (actual time=4650.874..4650.905 rows=738 loops=3)
               Sort Key: account_move_line.account_id
               Sort Method: quicksort  Memory: 103kB
               Worker 0:  Sort Method: quicksort  Memory: 99kB
               Worker 1:  Sort Method: quicksort  Memory: 100kB
               ->  Partial HashAggregate  (cost=2851745.10..2851754.84 rows=779 width=44) (actual time=4650.446..4650.708 rows=738 loops=3)
                     Group Key: account_move_line.account_id
                     Batches: 1  Memory Usage: 553kB
                     Worker 0:  Batches: 1  Memory Usage: 553kB
                     Worker 1:  Batches: 1  Memory Usage: 553kB
                     ->  Parallel Index Scan using account_move_line__company_id_index on account_move_line  (cost=0.72..2827275.65 rows=2446945 width=14) (actual time=0.147..3636.824 rows=4681102 loops=3)
                           Index Cond: (company_id = 1)
                           Filter: ((date <= '2026-06-10'::date) AND ((parent_state)::text = 'posted'::text) AND ((display_type)::text <> ALL ('{line_section,line_subsection,line_note}'::text[])) AND (journal_id = ANY ('{5,181,2,407,571,570,506,169,271,167,121,6,9,241,655,623,242,63,331,123,3,18,142,4,320,170,218,236,97,143,343,64,521,660,139,344,118,119,274,179,441,619,439,89,522,91,17,8,128,135,19,10,7,180,134,124,52,53,137,98,1,96,57}'::integer[])))
                           Rows Removed by Filter: 119633
 Planning Time: 0.423 ms
 Execution Time: 4980.584 ms
```

 ## With the new index

```sql
                                                                                                                                         QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Finalize GroupAggregate  (cost=1000.74..2857192.00 rows=779 width=44) (actual time=3339.293..7476.511 rows=839 loops=1)
   Group Key: account_move_line.account_id
   ->  Gather Merge  (cost=1000.74..2857166.68 rows=1558 width=44) (actual time=3339.266..7475.827 rows=1136 loops=1)
         Workers Planned: 2
         Workers Launched: 2
         ->  Partial GroupAggregate  (cost=0.72..2855986.83 rows=779 width=44) (actual time=0.439..4673.216 rows=379 loops=3)
               Group Key: account_move_line.account_id
               ->  Parallel Index Scan using idx_aml_reporting on account_move_line  (cost=0.72..2831507.64 rows=2446945 width=14) (actual time=0.055..3919.782 rows=4681102 loops=3)
                     Index Cond: ((company_id = 1) AND (date <= '2026-06-10'::date) AND ((parent_state)::text = 'posted'::text))
                     Filter: (journal_id = ANY ('{5,181,2,407,571,570,506,169,271,167,121,6,9,241,655,623,242,63,331,123,3,18,142,4,320,170,218,236,97,143,343,64,521,660,139,344,118,119,274,179,441,619,439,89,522,91,17,8,128,135,19,10,7,180,134,124,52,53,137,98,1,96,57}'::integer[]))
                     Rows Removed by Filter: 173
 Planning Time: 0.485 ms
 Execution Time: 7476.576 ms
```

In POS, the Preparation Time report groups average preparation durations by hour. Those hour buckets were always computed with the timezone of the user who ran the module upgrade (OdooBot / superuser), not the timezone of the user viewing the report. Changing the user, company, or browser timezone had no effect on the graph until the module was upgraded again.

Steps to reproduce:
-------------------
* Configure a Preparation Display and create POS orders with measured preparation times.
* Open Point of Sale → Reporting → Preparation Time.
* Note the hour bucket used for the orders.
* Change your user timezone in Preferences and reload the report.

> Observation:
The hour buckets stay the same. Before the fix, they only changed after upgrading `pos_enterprise`, because the timezone was embedded in the SQL view created during `init()` as superuser.

Why the fix:
------------
Replace the static PostgreSQL view with a dynamic `_table_query` so `order_hour` is computed with the current user's timezone on each report read. `init()` now only drops the legacy view instead of recreating it with a frozen timezone.

opw-6220248

Version:
----------
- 18.0+

Steps to reproduce:
----------------------
1. Install `sale_management`, `purchase`, and `stock` module.
2. Go to Settings and enable Reception Report.
3. Create a storable product with tracking enabled and add
supplier information.
4. Create a Sales Order for the product with a quantity and confirm it.
5. Open the generated Delivery Order and note the deadline value.
6. Create a Purchase Order for the same product and quantity  using the vendor
set on the product and confirm it.
7. Open the generated Receipt and click on the Allocation smart button.
8. Assign the receipt to the delivery order.
9. Go back to the Purchase Order and change the Expected Arrival Date.

Issue
- Updating the Expected Arrival Date on the Purchase Order also updates
the deadline of the related Sales Order delivery.

Root cause:
------------
- Clicking Assign triggers `action_assign`, which links incoming and outgoing moves:
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/stock/report/report_stock_reception.py#L271

- Updating the PO Expected Arrival Date triggers purchase.order.line.write(),
which calls  _update_move_date_deadline(new_date).
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/purchase_stock/models/purchase_order_line.py#L100-L101

- Then this `_update_move_date_deadline` function updates the incoming move
`date_deadline` and this  triggers stock.move.write().
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/purchase_stock/models/purchase_order_line.py#L165

- Inside write(), _set_date_deadline() is called.
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/stock/models/stock_move.py#L748-L749

- Inside `_set_date_deadline()`, the method calls` _get_moves_to_propagate_date_deadline()`
to collect all related moves that should be updated.
- This method includes `move_dest_ids` in the returned moves.
Since the incoming move is manually linked to the delivery move,
the corresponding outgoing move (from the Sales Order) is part
of `move_dest_ids`, and its `date_deadline` is therefore updated as well.

https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/stock/models/stock_move.py#L553

https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/stock/models/stock_move.py#L545

Solution:
----------
- Limit propagation to moves that share the same `group_id` or
where no formal procurement group/picking link is established.
- This prevents unintended date shifts across unrelated documents (manual links)
 while preserving correct behavior for standard MTO and Manufacturing flows.

---

opw-6085890


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

The planning.slot model has the field timesheet_ids which is computed and non-stored. It also has a dependency on
`project_id.timesheet_ids.unit_amount`. As timesheet_ids is non-stored while it's a dependency of the field `effective_hours`, if a single timesheet is modified on a project, a recomputation is required on all planning slots on that same project. Before this commit, the dependency highlighted earlier was resulting in a huge unnecessary computation since otherwise there's no way for the ORM to scope this computation to only affected slots. This commit elimintates this dependency and manually invalidates the timesheet_ids field on only the associated slots which drastically improves performance. A recomputation should only be done in case of write/create since timesheet_ids is computed nonstored.

## Benchmarks:
### The time it takes to update or create a timesheet in a specific project:

| No. planning slots in project | Before  | After | 
| ----------------------------- | ------- | ----- |
| 699838                        | Timeout | <1s   |
| 107203                        | ~130s   | <1s   |
| 7812                          | ~9s     | <1s   |

opw-5082577

### Issue
A user cannot open their bank journal if some rules are too slow to compute or consumes too much memory.

### Solution
This commit refactors the `_is_eligible_for_early_payment_discount` method on `account.move` to improve performance during bank reconciliation. The method was designed to run on a single record and was being called inside a loop when generating reconciliation suggestions.

A new method, `_is_eligible_for_early_payment_discount_batched`, has been introduced to handle the eligibility check for a recordset of moves. The original `_is_eligible_for_early_payment_discount` method is preserved as a wrapper around the new batched method to maintain backward compatibility.

Enterprise PR: https://github.com/odoo/enterprise/pull/92401

### Benchmarks
Profiling `_get_invoice_matching_amls_result` when using a reconciliation model with a Partner mapping:
| # of amls | Before | After | % |
|:-------------:|:-----------:|:------:|:----:|
| 499           | ~3 min then MemoryError |  230 ms | 99.9 % |
### References
opw-4998109

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

## Problem

In `account_reconcile_wizard.py`, the internal helper `get_reco_currency` (inside `_compute_reco_wizard_data`) returned the single foreign currency found among the selected lines without checking whether any residual in that currency actually remained after the reconciliation plan ran.

When reconciling a company-currency line against a foreign-currency line where the plan fully consumed the foreign-currency residual (leaving only a small company-currency exchange-difference balance), the wizard still set `reco_currency_id` to the foreign currency, inflating the write-off amount by the exchange rate.

## Root cause

```python
elif len(foreign_currencies) == 1:
    return foreign_currencies  # ignores whether the plan left any residual in that currency
```

## Fix

In the `elif len(foreign_currencies) == 1:` branch, iterate over `aml_values_map` (post-plan residuals) and return the foreign currency only if at least one line still has a non-zero residual in it; otherwise fall back to company currency.

## Test

`TestAccountReconcileWizard.test_write_off_receivable_company_currency_vs_foreign_currency`

Reconciles a company-currency debit (111.0) against a foreign-currency credit (−110.0 / −330.0 EUR at rate 3.0). The real remaining difference is 1.0 in company currency. The test asserts that `reco_currency_id` is the company currency and `amount` ≈ 1.0.

Task reported at: https://www.odoo.com/my/tasks/6315581