Before this fix:
The credit limit warning calculation only considered credit notes but ignored outstanding bank payments 
when computing the partner's effective outstanding balance. For example, if a customer had a credit limit
of 1,000 and an invoice of 2,000 was created, then a bank payment of 1,500 was received, the warning 
would still incorrectly appear showing the customer exceeded their limit (2,000 > 1,000), even though the
actual outstanding amount was only 500.

After this fix:
The credit limit warning now properly includes outstanding bank payments in the calculation. Two cases 
are handled:
- Bank payments received but not yet matched to any invoice, these are identified by their open suspense
  account entry and deducted from the partner's outstanding exposure.
- Bank payments already matched to the invoice, the reconciled amount is read from the invoice's receivable
  line and deducted accordingly.

So with this fix, after a 1,500 bank payment, the system correctly recognises the outstanding amount as 500
and does not show a warning since it is within the 1,000 credit limit.

task-5427613

Forward-Port-Of: odoo/enterprise#119829
Forward-Port-Of: odoo/enterprise#118957

Issue:
Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused reconciliation failures, no reconciliation happened, and the cancelled record remained in the view.

This regression was introduced during a refactor to allow draft entries in the reconciliation view, where the posted-state condition was removed from the domain:

Enterprise commit: https://github.com/odoo/enterprise/commit/003cffabda7d91a6d10d58942ed972ca5e17366d

As a result, cancelled journal items also became visible, causing reconciliation attempts to fail while the records remained in the view.

Also, we are not allowed to reconcile cancelled move lines, and we already
have the validation for this [here](https://github.com/odoo/odoo/blame/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/account/models/account_move_line.py#L2627)

Issue is reproducible on runbot. Here is the video reference: https://drive.google.com/file/d/1ojIDxHn5Yst8gVFy8JyhwtJoDSSSJsmK/view?usp=sharing

- OPW: 6247870

Forward-Port-Of: odoo/enterprise#119017
Forward-Port-Of: odoo/enterprise#118773

Currently, an error occurs when user tries to select a property field in auto field.

Steps to replicate:
- Install `sale_management` and `sign`.
- Open Sales > Products > Products > Open any product.
- From the Gear icon, Click Edit Properties and save the record.
- Enable Debug mode if you are using a version lower than 19.0 .
- Open Sign > Configuration > Field Types.
- Create a new Field > Give a name > Select model as `Product`.
- Select Field as `Property > Property 1` and click save.

Error:
- saas-18.3 and later:
```
  File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py', line 57, in _check_auto_field_exists
    auto_field_value = record.mapped(sign_type.auto_field)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5472, in mapped
    field = records._fields[field_name]
            ^^^^^^^^^^^^^^^
AttributeError: 'Property' object has no attribute '_fields'. Did you mean: 'field'?
```

- saas-18.2:
```
  File '/home/odoo/odoo18/enterprise/sign/models/sign_item_type.py, line 41, in _check_auto_field_exists
    auto_field_value = record.mapped(sign_type.auto_field)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File '/home/odoo/odoo18/community/odoo/orm/models.py', line 5744, in mapped
    if len(records) > PREFETCH_MAX:
       ^^^^^^^^^^^^
TypeError: object of type 'bool' has no len()
```

Cause:
- As the user gave auto fill field as a Property field the [line] called `mapped()` to access its value, this caused the error to occur.

- This occurs because `mapped()` expects a `recordset` (models.Model), but instead it receives a Property object, which does not have `_fields`.

Solution:
- Using `'allow_properties': 'False'`, the property fields wont appear in the list of field selection.

[line]: https://github.com/odoo/enterprise/blob/cdaeb79e1f623831fffa553dbb658698367c7e19/sign/models/sign_item_type.py#L41

sentry-7378769090

Forward-Port-Of: odoo/enterprise#119535
Forward-Port-Of: odoo/enterprise#113091

**Steps to reproduce:**
1. Log in as a portal user.
2. Open a shared project and then open any task within it.
3. Observe the vertical spacing above the Follow/Unfollow button and the chatter 
component.

**Issue:**
The chatter UI has incorrect vertical spacing, causing elements like the
Follow/Unfollow button to sit too far down and appear misaligned.

**Cause:**
The pt-2 padding class was hardcoded in two separate locations: 
1. The compileChatter wrapper in project_sharing_form_compiler.js.
2. The portal.Chatter XML template.
When combined this caused a double-padding effect forcing excessive space.

**Fix:**
Removed the hardcoded pt-2 class from both the JavaScript compiler wrapper and 
the core XML template. This eliminates the double-padding conflict. This resolves 
the alignment issue in Project Sharing and does not affect the layout or 
functionality of other portal components.

task-4203362

Forward-Port-Of: odoo/odoo#268977
Forward-Port-Of: odoo/odoo#257490

Refund orders use a display name based on the original ticket. The rectificativa was then submitted with a duplicate Serie/NumFactura and rejected with TicketBAI error 5040.

Steps to reproduce:
-------------------
* Enable TicketBAI for a Spanish company with POS
* Create an order and complete payment (TicketBAI sent)
* Refund that order from the POS and complete payment
* Open the new TicketBAI XML (downloadable on the order in the backend)

> Observation:
`CabeceraFactura` `NumFactura` matches the original sale; tax authority returns 5040 (duplicate invoice for same issuer/series/year).

Why the fix:
------------
The TicketBAI document `name` was set from `pos.order.name`, so `_get_tbai_seq_from_name` extracted the same numeric part as the original sale. `l10n_es_edi_tbai.document` derives Serie/Num from `name` via `_get_tbai_seq_from_name`. Refund POS names intentionally echo the original order label, so we derive the document name from the same components as non-refund orders (`get_reference_last_part()`), which is unique per receipt.

opw-6067965

Forward-Port-Of: odoo/odoo#257475

Steps to reproduce:
---
- Install `website_sale`.
- Create a product and from the Sales tab, add alternative products, making sure all products are published on the website.
- Open the main product on the website.
- In the alternative products section, open the editor, click the `brush` icon under `card design`.
- Under Actions > Buttons, click on the `cart` icon.
- Save the changes and click the `Add to Cart` button on an alternative product.

Issue:
---
- Clicking the `Add to Cart` button on alternative products does nothing.

Root cause:
---
- At [1], the `AddToCart` interaction uses the selector `.oe_website_sale button[name="add_to_cart"]` to find and attach click handlers. When the dynamic snippet renders alternative products, `startInteractions` is called on the `.dynamic_snippet_template` div. It searches for the button inside that div, but at [2], no element wrapping the button has the `oe_website_sale` class in the rendered product card template. So the selector matches nothing, and no click handler is attached.

Fix:
---
- Add `oe_website_sale` to the `o_wsale_product_btn` wrapper div in the product card template so the button becomes a descendant of `.oe_website_sale` within the injected content, allowing the interaction to attach correctly.

[1]https://github.com/odoo/odoo/blob/cbc446bfcaeeb4787cb512ddffbbeb2a154a6dde/addons/website_sale/static/src/interactions/add_to_cart.js#L5
[2]https://github.com/odoo/odoo/blob/cbc446bfcaeeb4787cb512ddffbbeb2a154a6dde/addons/website_sale/templates/snippets/product_snippet_template_data.xml#L95-L113

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

Forward-Port-Of: odoo/odoo#263253

Steps to Reproduce:

* Create a Hungarian company on 19.0 (or earlier).
* Configure NAV credentials through Settings.
* Upgrade the database to saas~19.2.

Issue:

* The upgrade fails while reloading the Hungarian chart template.

```python3

Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-19.2/odoo/service/server.py", line 1626, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/tools/func.py", line 65, in locked
    return func(inst, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/registry.py", line 202, in new
    load_modules(
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/loading.py", line 502, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/migration.py", line 215, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, version)
  File "/home/odoo/src/odoo/saas-19.2/odoo/modules/migration.py", line 253, in exec_script
    mod.migrate(cr, installed_version)
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu/migrations/3.1/end-migrate_update_taxes.py", line 7, in migrate
    env['account.chart.template'].try_loading('hu', company)
  File "/home/odoo/src/odoo/saas-19.2/addons/account/models/chart_template.py", line 181, in try_loading
    return self._load(template_code, company, install_demo, force_create)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/template_hu.py", line 11, in _load
    company._l10n_hu_edi_configure_company()
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_company.py", line 79, in _l10n_hu_edi_configure_company
    res_config_id = self.env['res.config.settings'].create({
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.2/hr_payroll/models/res_config_settings.py", line 39, in create
    return super().create(vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
    return method(self, vals_list)
           ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_config_settings.py", line 48, in create
    record.company_id._l10n_hu_edi_test_credentials()
  File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_company.py", line 107, in _l10n_hu_edi_test_credentials
    raise UserError(
odoo.exceptions.UserError: Helytelen NAV hitelesítő adatok! Ellenőrizze, hogy a cég adószáma helyesen van-e beállítva.
Hiba részletei: HTTPSConnectionPool(host='api.onlineszamla.nav.gov.hu', port=443): Max retries exceeded with url: /invoiceService/v3/tokenExchange (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x798a970f1fd0>: Failed to establish a new connection: [Errno 111] Connection refused'))
```

Cause:

* Since the introduction of the Hungarian tax migration using `account.chart.template.try_loading('hu', company)` in saas~19.1, upgrades reload the Hungarian chart template.
* When `l10n_hu_edi` is installed, chart template loading triggers `_l10n_hu_edi_configure_company()`, which performs NAV credential validation through `_l10n_hu_edi_test_credentials()`.
* The credential validation performs a live request to the NAV service, making the upgrade dependent on an external service. https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_hu_edi/models/res_company.py#L99-L109 https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_hu_edi/models/template_hu.py#L11

Fix:

* Bypass NAV credential validation during the migration.
* The migration only updates localization data and does not modify the configured EDI credentials.
* This prevents temporary NAV connectivity issues from aborting the upgrade process.

see https://github.com/odoo/odoo/pull/253556

opw-6253523
upg-4326247

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

### Issue before this commit:
When reversing an invoice in a Peruvian company, the "Cancel Reason" entered in the credit note window is not propagated to the Peruvian EDI tab of the resulting Credit Note. Only the Credit Reason is successfully reported.

### Steps to reproduce the issue:
1. Download Accounting and l10n_pe
2. Switch to PE company
3. Create an invoice and confirm it
4. Create a credit note for the invoice with a cancel reason and a credit reason and click the reverse button
5. See that in the Peruvian EDI tab only the Credit Reason is reported but not the Cancel Reason

### Cause of the issue:
In the l10n_pe_edi module, the override of the _prepare_default_reversal method maps the l10n_pe_edi_refund_reason to the new move's values, but completely omits the mapping of the wizard's textual reason field to the l10n_pe_edi_cancel_reason field of the resulting credit note.

### Reason to introduce the fix:
To ensure the generated credit notes contain all required information for the Peruvian EDI (SUNAT). Mapping the cancel reason guarantees that the electronic document accurately reflects both the refund code and the descriptive cancellation text provided by the user.

opw-6238525

Forward-Port-Of: odoo/enterprise#119610
Forward-Port-Of: odoo/enterprise#118479

Steps to reproduce
---
1. Register a grouped customer payment over several invoices, leaving one of them only partially paid.
2. Register a second grouped payment over two invoices: the partially paid one and a brand new invoice.
3. Open the first payment, its "Reconciled Invoices" smart button now lists the new invoice from the second payment, which it never paid.

Issue
---
The smart button is built from the stored `invoice_ids` many2many, which shares its relation table with `account.move.matched_payment_ids`. After reconciling, the register wizard links the payment to its invoices with `lines.move_id.matched_payment_ids += payment` at https://github.com/odoo/odoo/blob/f726393267a28cedd5febd2106de17ae3838f3ff/addons/account/wizard/account_payment_register.py#L1212.

When the payment groups several invoices, `lines.move_id` is a multi-record recordset. Reading `matched_payment_ids` on it returns the union of the payments already linked to all those invoices, and `+=` writes that union back to every invoice as a `(6, 0, ...)` replace command. So an invoice already paid by an earlier payment spreads that earlier payment onto every other invoice grouped in the new one, including brand new invoices, which then wrongly appear on the earlier payment.

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

Forward-Port-Of: odoo/odoo#267968

### Issue:
In DATEV customer and supplier exports, partners outside the European Union still had the `EU-Land` and `EU-UStID` fields filled

However, these fields must only be used for EU countries

For non-EU countries, the `Land` field should be filled instead, and is required whenever the country is not Germany https://developer.datev.de/en/file-format/details/datev-format/format-description/debitorskreditors

### Cause:
`_l10n_de_datev_get_partner_list` did not distinguish between EU and non-EU countries

As a result, any partner with a VAT number could populate `EU-Land` and `EU-UStID`, even if the country was outside the EU

Greece also requires a special case: its VAT prefix is `EL` so the `EU-Land` too, while the country code used in `Land` must remain `GR`

### Steps to reproduce:
- Install `l10n_de_reports` and switch to the DE company
- Create a customer in Switzerland with a valid VAT number
- Create and confirm an invoice for that customer
- Go to Accounting → Audit Reports → General Ledger
- Select the full year
- From the gear menu, export DATEV DATA (zip)
- Open the `EXTF_customer_accounts` file

### Before the fix:
`EU-Land` and `EU-UStID` are filled for the Swiss customer, while `Land` is empty

### After the fix:
`EU-Land` and `EU-UStID` are empty for non-EU countries such as Switzerland, while `Land` is correctly filled

`Land` is filled using the following priority:
1. Partner country_code
2. Country extracted from the VAT number
3. Empty

opw-5902565

Forward-Port-Of: odoo/enterprise#119780
Forward-Port-Of: odoo/enterprise#113835

### Issue
Since the introduction of the Tax Returns feature in 18.3, it was no longer possible to generate a Closing Entry as the button has been replaced by Returns
The Return mechanism implies that you need a Return Type in order to make a Closing Entry using the Validate button

Additionally, using the Generic Tax Report by default creates a risk in Multi-VAT environments, as it mixes taxes from all countries instead of isolating Peruvian taxes

### Cause
The new 18.3 accounting workflow requires at least one active Return Type associated with a country-specific report variant to display the Return options and process the closing entry Peru was relying on the Generic Tax Report, without a dedicated report variant
No Return Type was configured, which blocked Odoo's automatic VAT closing workflow and prevented the system from prompting the user to configure the required closing accounts

### Steps to reproduce
- Install `l10n_pe_reports` and `accountant`
- Switch to a PE Company
- Go to the Tax Report

Before the fix, no Returns button is available for any of the existing reports, making it impossible to use Odoo's automatic process to configure the tax accounts and trigger the closing entry

### Notes
This is fixed by creating a dedicated Peruvian tax report variant directly in Enterprise that inherits from the generic tax report A custom handler is added to force the domain filtering on Peruvian taxes only, and a corresponding Return Type is defined to restore the full closing entry process safely

opw-5978673

Forward-Port-Of: odoo/enterprise#117891

## Issue
When scheduling a sign request, the request appears immediately on the portal for the requested signer.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Create and send a sign request
    - Signer 1: Any portal user (e.g., Joel Willis)
    - Use the clock icon to schedule the signature request to a future date
3. Log in as the portal user used in step 2
4. Navigate to Signature Requests
5. **The signature request already appears in the list, even though it was scheduled for a future date.**

## Cause
The portal filters the sign requests shown based on the `is_mail_sent` field, which does not properly reflect when the signature request is shared to the user.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/controllers/portal.py#L40

In fact, when scheduling a signature request, the `is_mail_sent` field is unconditionally set to `True`, even if the signature request will only be sent later.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/models/sign_request_item.py#L289

## Fix
Since the `"scheduled"` `sign_request_item.state` option introduced by https://github.com/odoo/enterprise/commit/ed8d5a653e01b1378f0020e2f7a7c2d39fadf3e9 in 19.1, we can easily filter out the sign request items that are scheduled. That state is automatically updated by the `_cron_update_state`, introduced by the same commit as the `"scheduled"` option.

https://github.com/odoo/enterprise/blob/9898272f17809decf6c5bb4600aca46f9ffae6f0/sign/models/sign_request.py#L493-L503

opw-6227472

Forward-Port-Of: odoo/enterprise#118491

### **Steps to reproduce:**
- Install Payroll and Attendance apps.
- Create an employee with a flexible working schedule and work entry source as attendance.
- Create an attendance record for this employee.
- Create and compute a payslip for this employee.

### **Observed Behavior:**
 Worked Day lines are not generated, and Basic Wage is calculated as 0.

### **Expected Behavior:**
Worked Day lines should be populated based on attendance records.

### **Root Cause:**
During payslip computation, [_compute_worked_days_line_ids](https://github.com/odoo/enterprise/blob/4339010eb1e1633a67573d08e032f3922b0bec49/hr_payroll/models/hr_payslip.py#L1846) only generated work entries for versions having a `resource_calendar_id`  at [1]. As a result, fully flexible employees without a working schedule were excluded from work entry generation, preventing worked day lines from being computed.

[1]- https://github.com/odoo/enterprise/blob/4339010eb1e1633a67573d08e032f3922b0bec49/hr_payroll/models/hr_payslip.py#L1890-L1898

### **Fix:**
Remove the `resource_calendar_id` filter when calling `generate_work_entries` in `_compute_worked_days_line_ids` so work entries are also generated for fully flexible employees using attendance-based work entries.

**opw-6146452**

Forward-Port-Of: odoo/enterprise#117409

Scenario:

- set up turnstile
- with recent safari mac os or ios (reproduced from 26.2) go to
  /web/login page in a private window
- enter login and password and pass the turnstile challenge
- click on Log in

Result: nothing happens and there is an error in the console "An invalid
form control with name='' is not focusable."

Cause:

By default Safari has the Settings > Advanced > "Use advanced tracking
and fingerprinting protection" set to "in Private Browsing".

If this options is enabled in private browser or in all browsing, you
can't login to Odoo with turnstile because safari is preventing the
update of the element that is preventing to send the form:

<input style="display: none;" class="turnstile_captcha_valid" required>

When turnstile challenge succeeds, a value should be set to this input
that will unlock the form, the .value property is updated but the
browser Shadow Content is not (and if we remove display:none, the input
is empty).

Fix:

I've not been able to reproduce the issue without turnstile using same
situation and iframe. We don't know Safari heuristic but the unlocking
is working if:

- we use setProperty instead of .value
- we unset required
- we remove the input
- we display the turnstile_captcha_valid input before challenge

This fix replaces setting .value by setProperty, and add a failsafe of
unsetting required.

opw-5917286
fixes #247536

Forward-Port-Of: odoo/odoo#253367

Importing attendees on an event that has an `after_sub` mail scheduler (the default on every event) fails with `savepoint "..." does not exist` and the import is aborted.

[`_update_mail_schedulers`](https://github.com/odoo/odoo/blob/b2f3270271f6/addons/event/models/event_registration.py#L298) runs the attendee scheduler synchronously on every registration create. The scheduler commits after each mail batch, which is fine from cron but problematic during an import: since [29460b723f49](https://github.com/odoo/odoo/commit/29460b723f49) [`load`](https://github.com/odoo/odoo/blob/b2f3270271f6/odoo/orm/models.py#L884) uses a single savepoint for the whole run, and any commit underneath releases it, so the next `ROLLBACK TO` / `RELEASE SAVEPOINT` raises `InvalidSavepointSpecification`.

When `import_file` is in context, trigger the cron like the async path already does so the mails are queued instead of running inline.

Steps to reproduce:

0. Have Contacts and Events installed
1. Events > Events, create a published event
2. Open the event, Attendees tab > Favorites > Import records
3. Upload a file with new attendees (Name, Email, no external id)
4. Click Import

=> "savepoint ... does not exist", import fails

Ticket [link](https://www.odoo.com/odoo/project.task/6124741)
opw-6124741

Forward-Port-Of: odoo/odoo#267586
Forward-Port-Of: odoo/odoo#260648

## The Problem
When computing a future leave balance, `_get_future_leaves_on` triggers
`_process_accrual_plans`, which iterates period by period and calls
`_get_leaves_taken` at each step. `_get_leaves_taken` re-enters
`_get_consumed_leaves` with `ignore_future=True`, but other accrual
allocations on the same employee were not guarded by `precomputed_allocations`,
causing `_get_future_leaves_on` to fire again for each of them, launching
another full accrual run recursively. With N periods and K allocations,
total work grew as $O(N^K)$.

## The Solution
Adding `not ignore_future` to the guard prevents future projection in any
nested context where it is both semantically incorrect and the source of
the blowup.

---

## Benchmarks
*Tested on a customer database with an employee having 2 accrual allocations and
pending future leave requests 6 months out:*

| | Queries | Request Time | Improvement |
| :--- | :--- | :--- | :--- |
| **Before** | 220K | 145.0s | — |
| **After** | 2.7K | 2.8s | **-98%** |

**Note:** More optimizations could be done to reduce the queries to a constant. However given the current design, it would be a bit big change and the current performance is already acceptable.

**OPW-6115804**

Forward-Port-Of: odoo/odoo#261172

Opening the Inventory Valuation report iterated every storable product to compute total_value, which on large catalogs used several GB of RAM and timed out workers.

The report now searches only products that have stock (under the same valuation context that total_value uses) or that are lot-valuated, and feeds that smaller set into stock_value and stock_accounting_value. For historical (at_date) reports the search runs with to_date in context so qty_available is scoped to that date. _get_accounts_by_product() also switches to search_fetch so only categ_id is loaded upfront.

Benchmarks were measured on a customer database restore with ~360k storable products. After filtering, ~2.5k products feed into the valuation today and ~2.2k for a historical date.

Benchmark opening Inventory Valuation report (Accounting)
| Date       | Before | After  | Speed up |
|------------|--------|--------|----------|
| Today      | ~88s   | ~2s    | 41x      |
| Historical | ~245s  | ~173s  | 1.4x     |

The historical improvement is more modest because stock_value still has to compute total_value at the historical date for the remaining products, which traces SVL/stock.move history; the filter eliminates the dominant per-product overhead today but only the tail in the historical case.

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#265931
Forward-Port-Of: odoo/odoo#254010