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

resource_calendar was not being when calculting virtual leaves, it leads to a singleton error here:
https://github.com/odoo/odoo/blob/11b0195dddad5055fc33fa3e28b2d2ca60f24935/addons/l10n_fr_hr_holidays/models/hr_leave.py#L163

```
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 519, in _table_sql
    table_query = self._table_query
                  ^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/addons/hr_holidays/report/hr_leave_employee_report.py", line 40, in _table_query
    self._compute_leave_duration(report_records)
   File "/home/odoo/src/odoo/saas-19.2/addons/hr_holidays/report/hr_leave_employee_report.py", line 94, in _compute_leave_duration
    leaves_durations = virtual_leaves._get_durations(additional_domain=[('holiday_id', 'not in', leave_ids)])
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/addons/l10n_fr_hr_holidays/models/hr_leave.py", line 160, in _get_durations
    while not leave.resource_calendar_id._works_on_date(date_start):
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   File "/home/odoo/src/odoo/saas-19.2/addons/resource/models/resource_calendar.py", line 877, in _works_on_date
    self.ensure_one()
   File "/home/odoo/src/odoo/saas-19.2/odoo/orm/models.py", line 5253, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
 ValueError: Expected singleton: resource.calendar()
```

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#266084

When importing a Peppol/UBL vendor bill containing a line with a 100% discount, the line was created in Odoo with quantity=1 and discount of 100*original_qty, instead of the
expected quantity=qty_original and discount=100%.

This happened because the line-level branching in
`_import_ubl_invoice_line_add_price_unit_quantity_discount` relied on the truthiness of `line_extension_amount` to detect whether the `LineExtensionAmount` node was present in the XML. a line with a genuine `<cbc:LineExtensionAmount>0</...>` was indistinguishable from a line where the node was missing, and fell
through to the fallback branch intended for incomplete XML. That fallback reconstructs the quantity from `<cbc:BaseQuantity>`, ignoring `<cbc:InvoicedQuantity>`, and then computes the discount percentage against the wrong denominator.

a `LineExtensionAmount` of 0 is the only legal way to express a fully discounted line, so this case must be distinguished from the node being absent.

the fix is simply checking if the line exist not if its True

opw-6176349

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

Forward-Port-Of: odoo/odoo#269322
Forward-Port-Of: odoo/odoo#265261

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

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 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

When a Time Off Type is created, it inherits the country of the current company. If there are leaves or allocations created from this Time Off Type and the company's country is then changed, various parts of Time Off will throw access errors as the leaves and allocations are still tied to the former country. The goal of this PR is to constrain
the company country from being changed unless there are no such leaves or allocations.

**Steps to Reproduce on Runbot:**
1. Ensure the current company has a `country` set, e.g. "My Company (San Fransisco)" has country set to "United States". 
2. Access Time Off as Mitchell Admin.
3. Create a new Time Off Type, for simplicity's sake without a need for allocation or approval, ex: "Gone Fishing". Note this Time Off Type will have the `country` set to the company country by default. 
4. Take "Gone Fishing" time off. 
5. Change or set blank the company's `country` value. 
6. Ensure the record rules cache is flushed.
7. Try to access Time Off. 

opw-6206359, opw-6140496

closes #263950

Forward-Port-Of: odoo/odoo#263950

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

Steps to reproduce:
1. Install Knowledge.
2. Create an article.
3. Open the more actions menu.
4. Click "Add Cover".
5. Upload a cover image.

Issue:
- The upload crashes with the following traceback:
`Uncaught Promise > this.props.setAbortUploadsCallback is not a function`

Cause:
- `KnowledgeCoverSelector` extends the html_editor `ImageSelector`, whose upload flow registers an abort callback through setAbortUploadsCallback. The generic MediaDialog provides this callback, but KnowledgeCoverDialog renders KnowledgeCoverSelector directly and did not pass it. As a result, the inherited upload flow called a missing prop.

Solution:
- Pass setAbortUploadsCallback from KnowledgeCoverDialog to KnowledgeCoverSelector and abort pending uploads when the cover dialog is discarded.

Alternative approach: 
- Make ImageSelector tolerate callers that do not provide
  setAbortUploadsCallback by calling it with optional chaining.

opw-6176716

Forward-Port-Of: odoo/enterprise#120134
Forward-Port-Of: odoo/enterprise#116906

### 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

This commit ensures product images follow their visual order in the
product image viewer when using the grid layout.

Steps to reproduce:
- Open a product page with multiple images (or add Extra Media to the 
  product)
- Change layout mode to "Grid" and click save
- Click any image to open the product image viewer
- Navigate between images

Images do not follow the visual left-to-right order. This regression was
introduced by [commit], which replaced the row-based grid with a
column-first layout. As a result, `querySelectorAll` returns images in
DOM order, which no longer matches the visual order.

To fix this, images are now reordered based on their visual placement in
the grid so navigation matches the order seen by the user. Images are
traversed in visual left-to-right order while also accounting for
varying image heights and multi-column alignment.

[commit]: https://github.com/odoo/odoo/commit/9a3628b9735550bf8ecc2252ea1b7338f68ab966
task-[4364143](https://www.odoo.com/odoo/project/974/tasks/4364143)

Forward-Port-Of: odoo/odoo#270513
Forward-Port-Of: odoo/odoo#254077

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

### Context:
Clients can have some existing accounts with `reconcilable` flag set as True. Some of these accounts also have partially reconcilated transactions. In Odoo 19.0, it is not authorized to toggle the `reconcilable` flag from True to False on accounts that contain partially reconcilated transactions.

When the migration script `l10n_pl/migrations/2.1/end-migrate.py` is executed and try to update the CoA by adding/updating accounts, using the accounts in the file
`l10n_pl/data/template/account.account-pl.csv`. This CSV file contains a reconcilable flag per account.

### Problem:
Before this modification, the upgrade script was trying to update the CoA using `_load_data`, which try to overwrite the reconcilation flag of accounts in the client DB. A traceback occurs during the upgrade if an account's `reconcilable` flag is toggled to False while it still contains partially reconciled transactions.

### Solution:
I have sanitized the dict `data` using the _pre_reload_data method.

### Notes:
`_pre_reload_data` method sanitizes the dict `data` by avoiding the creation of duplicated accounts, the creation of duplicated fields for a given record, the toggling of the `reconcilable` flag, etcs.

Back port of: https://github.com/odoo/odoo/commit/23ed5448a13255e68ff4d3ca87884c2ca2f97ba3
Reason: the issue was originally introduced in `18.0` (see https://github.com/odoo/odoo/commit/d5109a45d610916530b4b74cf3e2fa440ee7ed63)
Related to: https://github.com/odoo/upgrade/pull/10266#discussion_r3402549250

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

Forward-Port-Of: odoo/odoo#269794

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

### 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

- 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

* 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
```

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