Issue description:
The profitability items for projects were not matching the numbers from analytic accounting reports due to discrepancies in currency rate calculations. This issue was traced to two main causes:

1. Profitability items were using the currency rate of today, even for old move lines.
```rates = self.env['res.currency'].browse(list(currency_ids))._get_rates(self.company_id, date.today())```
 While this was deemed acceptable for performance reasons in #113146,
 it caused mismatches with analytic accounting reports.

2. Some move lines use a changed currency rate that differs from
the rate stored in the currency table for the same date
(due to manual change in the currency rate), leading to further mismatches.

To resolve this:
- The `balance` is now used instead of `price_subtotal` for calculations.
This ensures accurate amounts without relying on conversion rates
when the project currency matches the company currency.

Steps to Reproduce:
1. Create a project with an associated analytic account.
2. Enable any foreign currency and add different rates for it for today and yesterday.
3. Create a new vendor bill with:
   - Date = yesterday
   - Currency = the new foreign currency
   - Analytic distribution set to the created project's analytic account.
4. Check the project dashboard profitability. You will see the numbers
are incorrect because it uses the currency rate of today.

opw - 4881380

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

Forward-Port-Of: odoo/odoo#222462
Forward-Port-Of: odoo/odoo#217337

When a combo contained a product that had variant with type 'no_variant' and 'always', if you added the product to the cart the product configuration popup would not open. Also, in the combo you can only select product_product and not product_template, so the product configuration popup should not propose the variant linked to the 'always' type, as you already selected a product template in the combo configuration popup.

Steps to reproduce:
-------------------
* Create a product attribute PA1 with type 'no_variant' and 2 values V1 and V2
* Create a product attribute PA2 with type 'always' and 2 values V3 and V4
* Create a product template PT1 with PA1 and PA2
* Create a combo choice PC1 with the 2 variants of PT1
* Create a combo product CP1 with PC1
* Open PoS and add CP1 to the cart
* The combo configurator popup opens, click on the version with V2
> Observation: The product configurator popup does not open
> Second fix: The product configurator allows you to select the
  variant linked to the 'always' type, which is not correct as you already selected it through the combo configurator popup

Why the fix:
------------
The first fix just make sure that the product configuration popup opens when it is necessary.
The second fix filters the variants proposed in the product configuration popup to only show the variants that are not linked to the 'always' type. But this only happens when we do it from the combo configuration popup.

opw-4719258

Forward-Port-Of: odoo/odoo#222252
Forward-Port-Of: odoo/odoo#215603

**Steps to reproduce**:
- install the `accounting` module.
- Go to `Settings -> Technical -> Actions -> Reports -> Invoice or Invoice without payment`
- Change the printed report name
- Try to print the report via the print menu (gear icon -> print) -> The report is shown with the new updated name.
- Try sending the invoice the regular way -> the attached invoice has the default name, Odoo ignores the changes.

**Observation**:
When printing the invoice manually, the file name correctly reflects the custom name configured in the report action. However, when sending the invoice by email, the attachment file name does not match the updated name and remains hardcoded.

**Issue**:
The email attachment file name is hardcoded in the mail sending logic. in the method:
```python
def _get_invoice_report_filename(self, extension='pdf'):
        self.ensure_one()
        return f'{self.name.replace('/', '_')}.{extension}'
```
It does not dynamically fetch the updated report name from the configured report action.

**Solution**:
When a custom report template is configured on the customer on field `(invoice_template_pdf_report_id)`, the system now dynamically uses the corresponding name from the report action for the email attachment.

opw-4923035

Forward-Port-Of: odoo/odoo#219279

With the French fiscal localization:
When an employee has a different working schedule than the company’s default one. If the employee’s daily working hours are greater than the company’s default hours. The timesheet for paid time off only displays the company’s default hours instead of the employee’s actual hours.

Steps to reproduce:
-------------------
* Install l10n_fr_hr_holidays
* Set the French fiscal localization
* Working schedule of the company -> 7:30 per day
* Working schedule of the employee -> 8 per day
* Create a paid time-off with this employee
* Check the Timesheet of this employee

> Observation:
Timesheet shows 7:30 instead of 8

Why the fix:
------------
We needed to ensure the hours are always calculated correctly (using the employee’s or company’s calendar when appropriate) while still forcing the correct day count (1 or 0.5) and extending it according to French law.

✅ Day count is forced (0.5 or 1) depending on the leave type.
✅ Hours are fetched from  `super()._get_durations()` so the timesheet keeps accurate hours.

This prevents timesheets from showing incorrect hours when the employee's work schedule differs from the company's work schedule.

opw-4744516

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

Forward-Port-Of: odoo/odoo#220511

- When migrating from `saas~18.3` to `saas~18.4` upgrade is blocked.

Issue
-
- The model `hr.contract` was [renamed](https://github.com/odoo/upgrade/blob/815644044a3cf9ec41b2cf7580da47abdf6d3553/migrations/hr/saas~18.4.1.1/pre-migrate.py#L25) to `hr.version`. The fields `date_start` and `date_end` were also [renamed](https://github.com/odoo/upgrade/blob/815644044a3cf9ec41b2cf7580da47abdf6d3553/migrations/hr/saas~18.4.1.1/pre-migrate.py#L30-L31) to `contract_date_start` and `contract_date_end` in the hr.version model.
- These fields were still referenced in this module, causing issues.

Solution:
-
- Updated the references from `date_start` and `date_end` to `contract_date_start` and `contract_date_end` to resolve the issue.
- Reference [PR](https://github.com/odoo/odoo/pull/202869/files)

Traceback:
-
```python3
Traceback (most recent call last):
  File "/home/odoo/src/odoo/saas-18.4/odoo/service/server.py", line 1410, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'])
  File "<decorator-gen-6>", line 2, in new
  File "/home/odoo/src/odoo/saas-18.4/odoo/tools/func.py", line 89, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/registry.py", line 175, in new
    load_modules(
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 450, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/saas-18.4/odoo/modules/loading.py", line 201, in load_module_graph
    registry.init_models(env.cr, model_names, {'module': package.name}, new_install)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/registry.py", line 719, in init_models
    model._auto_init()
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/models.py", line 2908, in _auto_init
    new = field.update_db(self, columns)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields_relational.py", line 284, in update_db
    return super().update_db(model, columns)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1120, in update_db
    self.update_db_notnull(model, column)
  File "/home/odoo/src/odoo/saas-18.4/odoo/orm/fields.py", line 1173, in update_db_notnull
    model._init_column(self.name)
  File "/home/odoo/src/odoo/saas-18.4/addons/hr_work_entry/models/hr_work_entry.py", line 82, in _init_column
    self.env.cr.execute("""
  File "/home/odoo/src/odoo/saas-18.4/odoo/sql_db.py", line 426, in execute
    self._obj.execute(query, params)
psycopg2.errors.UndefinedColumn: column hc.date_start does not exist
LINE 14:                         hwe.date_start >= hc.date_start AND
                                                   ^
HINT:  Perhaps you meant to reference the column "hwe.date_start".
```

- OPW - 4996246
- UPG - 3056379

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

**Steps to reproduce:**
- For simplicity, create a new account.
- Create a new journal entry, with one line on the newly created account.
- Set the date to today or older.
- Set auto-post to "At date".
- Make sure the journal has autocheck_on_post set to True.
- Keep the journal entry in draft, and duplicate it until you have 100 copies. (Make sure auto-post is set to "At date" on all of the copies aswell)
- Set the newly created account to 'Deprecated'.
- Manually execute the scheduled action "Account: Post draft entries with auto_post enabled and accounting date up to today"

**Issue:**
The scheduled action fails and then falls into an infinte loop, and logs an error on the chatter every minute, which could lead to thousands of mail_message records beign created.

**Cause:**
If the autopost scheduled action fails on a certain move, it marks it as 'move.checked = False'. So that when it is calls itself again (if the number of moves to post is greater than or equal to 100), it won't fetch the same move and fail again.
But having 'journal_id.autocheck_on_post = True' in the search domain allows autopost to fetch the same move it marked before (if the journal allows it), which leads to an infinite loop.

**Solution:**
If autopost fails on a move, set 'auto_post' to 'no' so it won't be fetched again.

opw-4815790

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

Forward-Port-Of: odoo/odoo#214946
Forward-Port-Of: odoo/odoo#213642

A non-deterministic error has been occurring across all versions starting from 18.0 when running the
`test_split_line_on_destination_scan`.

problem:
The issue lies in one of the steps of the tour, where the destination location of the remaining quantity is changed from WH/Stock to shelf1 (LOC-01-01-00). Right after this change, the test proceeds to assertLineDestinationLocation. However, the test step was previously waiting for the presence of the .o_validate_page.btn-primary element — an element that is already visible before the destination location update is actually applied. As a result, the tour sometimes skips to the next step prematurely, without ensuring the location change has occurred, leading to test failure.

Fix:
We replaced the trigger .o_validate_page.btn-primary with a more reliable condition: waiting for an element containing the destination text .../Section 1 (.o_line_destination_location:contains(".../Section 1")). This ensures that the step only proceeds once the destination update has been reflected in the UI.

Runbot-145458

Forward-Port-Of: odoo/enterprise#92006
Forward-Port-Of: odoo/enterprise#91927

Added to SURCHARGE_TAX_EQUIVALENT taxes 0.26% SE and 1% SE

When using the Odoo VAT book (location Spain) and we have an invoice with the taxes
0.26% SE (0,26% Recargo Equivalencia Compras)
1% SE (1% Recargo Equivalencia Compras).
a KeyError error occurs 

<img width="1147" height="517" alt="Captura desde 2025-07-30 09-37-13" src="https://github.com/user-attachments/assets/771fcf6e-efed-4e79-a1d4-a133c7072c2a" />


Steps to Reproduce this error:
1. Create a new database using Odoo version 18.
2. Activate the module: “Spain - Accounting (PGCE 2008)” (l10n_es).
3. Create a new company and set Spain as the country.
4. In the company’s “Sales & Purchase” tab, set the Fiscal Position to "Equivalence surcharge".
5. Create a new quotation and select the company created in step 3.
6. Add a product with the following taxes: 0.26% and 2% VAT (G).
7. Add another product with the following taxes: 1% (SE) and 7.5% VAT (G).
8. Confirm the invoice generated from the quotation.
9. Go to Accounting → Reporting → Tax Report and select "Generic Tax Report".
10. Click the gear icon and select "VAT Record Books (XLSX)".

OPW https://www.odoo.com/es_ES/my/tasks/4981807

@jco-odoo please review. Thank you!

MT-10457 @moduon

Forward-Port-Of: odoo/enterprise#92116

Steps to reproduce:
- Do not enable “Rental Transfer” in settings
- Create a storable product “P1”:
    - Enable “Can be rented”
    - update available quantity to 10 units

- Create a first rental order for 24h:
    - 9 units of P1
    - Confirm the order

- Create a second rental order for the same 24h period:
   - 1 unit of P1

-> Expected: The availability widget is green and indicates 1 unit available (correct).

Problem:
After picking up the first order, the widget on the second order turns red and incorrectly shows no availability.
The current logic checks virtual_available (1 unit) and subtracts rented_qty_during_period (9 units), resulting in -8. It then takes max(0, -8) → 0. However, the actual picked quantity should be taken into account, regardless of whether “Rental Transfer” is enabled, since disabling it merely omits the creation of a picking—not the move itself.

opw-4901017
opw-4906162

Forward-Port-Of: odoo/enterprise#92056
Forward-Port-Of: odoo/enterprise#91155