Issue
-----
When shipping internationally with Easypost, the currency on the commercial invoice does not always match the one of the sale order.

Steps to reproduce
-----
- Install Easypost
- Create a new pricelist using a different currency from the company
- Create a SO
	- Some product with a weight & HS code
	- Customer must be in another country from company (for commercial invoice)
	- Use the new pricelist
	- Add easypost delivery
- Confirm SO
- Validate linked picking

> Commercial invoice uses company currency instead of SO's

Cause
-----
The currency being sent to Easypost is retrieved from the package in

https://github.com/odoo/enterprise/blob/4c540f450d4de8b59b871662123f85ed54cca2a9/delivery_easypost/models/easypost_request.py#L146

The package object is actually created by calling the carrier's `_get_packages_from_picking` method

https://github.com/odoo/enterprise/blob/4c540f450d4de8b59b871662123f85ed54cca2a9/delivery_easypost/models/easypost_request.py#L266-L270

Solution
-----
We could be fixing this in `stock_delivery` by creating the package with the correct currency when calling `_get_packages_from_picking`. The problem with this approach is that this might negatively affect other carrier services, as discussed in https://github.com/odoo/odoo/pull/268224.

Instead, we can apply a band-aid fix to take the currency from the picking's sale in the `delivery_easypost` module, which is the only one where the problem was reported.

-----
Ticket:
opw-6224883

### Steps to reproduce

- Install `sale_timesheet_enterprise`.
- Go to **Tasks → All Tasks**.
- Switch to the **Gantt** view.
- Group by **Sale Order Item** (`sale_line_id`).

### Issue

A traceback is raised when loading the Gantt view with group by `sale_line_id`:

```text
ValueError: Invalid field 'planned_hours' on model 'project.task' for 'planned_hours:sum'
```

### Root cause

The Gantt progress bar computation for the `sale_line_id` grouping performs a `_read_group()` aggregation on the `planned_hours` field of `project.task`.

However, `planned_hours` was renamed to `allocated_hours` during the saas-16.5 migration, so the former field no longer exists on `project.task`. As a result, the aggregation raises a `ValueError`.

Migration reference:
https://github.com/odoo/upgrade/blob/e638c6ce00d9d8936d034ad7130fef51565b9195/migrations/project/saas~16.5.1.2/pre-migrate.py#L10

Issued PR: https://github.com/odoo/enterprise/pull/49685

### Fix

Use `allocated_hours`, the renamed equivalent of `planned_hours`, when computing the Gantt progress bar. This restores the Gantt view when grouping tasks by **Sale Order Item** and prevents the traceback.

Forward-Port-Of: odoo/enterprise#122712
Forward-Port-Of: odoo/enterprise#122297

Issue
-----
When validating a delivery in a different company from the main one, the commercial invoice's number field is incorrect, which raises an error on DHL end.

`content/exportDeclaration/invoice/number: expected type: String, found: Boolean`

Steps to reproduce
-----
- Create a Belgian company
- Setup DHL
	- DHL Product D - Express Worldwide
	- Dutiable Material enabled
- Create an amrican customer
- Deliver a product to the american customer

> Validation Error

Cause
-----
The field is populated in

https://github.com/odoo/enterprise/blob/cf3c2fce8a6b7b2d7547d44a0e4423f887986d52/delivery_dhl_rest/models/dhl_request.py#L204

The problem is that `next_by_code` uses the company found in the env, whereas the sequence's company is the main one, so it is not found when doing

https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/odoo/addons/base/models/ir_sequence.py#L287

-----
Ticket:
opw-6171886

Forward-Port-Of: odoo/enterprise#122787
Forward-Port-Of: odoo/enterprise#118379

Steps to Reproduce
---
- Create two different working schedules with different public holidays
- Assign employees to specific working schedules
- Set company default working schedule to a different schedule
- Login as employee with specific working schedule
- Navigate to Timesheets app -> My Timesheets
- Observe public holidays and personal time-off displayed in the timesheet grid

Issue
---
- The timesheet grid displays unavailable dates (public holidays, weekends) from the company's default working schedule instead of the employee's assigned working schedule.
- Personal time-off requests are not reflected as unavailable dates in the timesheet grid.

Current Behaviour
---
- Public holidays shown are always from the company's default working schedule, ignoring employee-specific working schedule assignments.
- Employee's approved time-off requests don't appear as unavailable in the timesheet.

Expected Behaviour
---
- Public holidays should display based on the employee's assigned working schedule, with company schedule as fallback only when no specific schedule is assigned.
- Employee's personal time-off requests should appear as unavailable dates.
- This should align with Time Off app behavior.

Fix
---
- Included employee-specific work interval calculation with personal time-off requests.
- Added support for contract-based calendar changes and calendar validity periods.
- Implemented proper fallback when valid intervals are not found.

task-4997080

Forward-Port-Of: odoo/enterprise#95458

When an employee's Income Stream Type is changed after a payslip has been created,
computing the sheet for payslip will raise a traceback.

Steps to reproduce the  error:
- Install ``l10n_au_hr_payroll_account`` module with demo data
- Switch to ``My Australian Company`` company
- Create a new payslip for ``Dennis Cactus`` Employee > Save
- Go to Employees > Open the ``Dennis Cactus`` employee >
  In Payroll tab, Income Stream Type: Other specified payments > Save
- Go back to payslip > click the compute sheet button

Traceback:
```py
KeyError: 'OSP'
```

https://github.com/odoo/enterprise/blob/13e64e0cb7f566cbbb46109fe1c218eb7a14eead/l10n_au_hr_payroll/models/hr_payslip.py#L175-L178
The ``l10n_au_income_stream_type`` field on the payslip is a computed field that only depends on ``employee_id``.
As a result, changing the employee's Income Stream Type does not trigger a recomputation of the corresponding field on existing payslip.
So, when the ``payslip_ytd_totals`` field is computed, it uses the old value of ``l10n_au_income_stream_type`` field at [1], The resulting ``payslip_ytd_totals`` is then used to build the ``totals`` dictionary, and eventually, when the employee's current ``income_stream_type`` is used to access
``totals``, the mismatch key leads to the above traceback. https://github.com/odoo/enterprise/blob/13e64e0cb7f566cbbb46109fe1c218eb7a14eead/l10n_au_hr_payroll_account/models/hr_payslip.py#L75-L88

[1]: https://github.com/odoo/enterprise/blob/13e64e0cb7f566cbbb46109fe1c218eb7a14eead/l10n_au_hr_payroll/models/hr_payslip.py#L269-L272

solution:

I added ``l10n_au_income_stream_type`` to ``add_to_compute()`` in ``compute_sheet()``.
This ensures that stale values of ``l10n_au_income_stream_type`` on
existing payslips are recomputed when the payslip sheet is computed.

sentry-7536819310

Forward-Port-Of: odoo/enterprise#123183
Forward-Port-Of: odoo/enterprise#120143

### Steps to reproduce the issue:
1. Download Accounting
2. Go to Journal entries and create a new one
3. Click Toggle Studio button and go to the view to add the tax_base_amount field to the list of existing fields
4. Add 2 lines (example):
	1. account Product Sales with 1000 dollars credit and 15% tax under Tax column
	2. account Bank with 1000 dollars debit
5. Go to Dashboard > Bank > Click the 3 dots of one random bank matching line and click on Manage Models
6. Go to bank fees and add the 15% tax
7. Go back to bank reconciliation and create a new one of 2000 dollars with label bank fees (it will associate the tax automatically)
8. Go back to Journal Entries, group by Journal and search for the transaction of 2000 sollars for account Bank
9. Problem: see that the Base Amount for the 15% bank fees lines (251000 Tax Received account) is 0. Clicking on Reset to draft button the base amount column is automatically updated but this should happen automatically

### Cause of the issue:
This occurs because the _lines_prepare_tax_line method in account.bank.statement.line fails to map this field in its return dictionary.

### Reason to introduce the fix:
Currently, when applying a reconciliation model with taxes the generated tax lines incorrectly record a tax_base_amount of $0.00. Instead, it should be displayed and calculated.

opw-6220948

**Problem:**
On the website, a subscription product page returns a 500 error when a discount is set directly on the recurring plan (a time-based pricing rule with a plan but no pricelist).

**Steps to reproduce:**
1. Create a subscription product with a recurring plan.
2. Add a recurring price rule for that plan with no pricelist, set as a percentage discount (base = sales price).
3. Open the product page on the website.

**Current behavior:**
The page fails with a 500: Internal Server Error during price computation.

**Expected behavior:**
The page loads and shows the discounted recurring price.

**Cause of the issue:**
For a recurring price rule based on the sales price, `_compute_base_price` looks up "the no-pricelist rule for the plan" to use as its base, via `_get_applicable_rules_domain(plan_id=...)`. When the discount is set directly on the plan, the rule being computed has no pricelist itself, so that search returns the very same rule and calls `_compute_price` on it again, leading to infinite recursion.

**Fix:**
Excluding the rule itself from the base-rule lookup lets a no-pricelist plan rule resolve its base from the product's sales price (the super() fallback) instead of re-entering its own computation. A rule applied through a pricelist is unaffected, since its no-pricelist base rule is a different record.

opw-6306105

# How to reproduce
- Go to Inventory > Settings > Operation Types
- Pick any Operation and disable "Allow extra product"
- Create a picking for that operation type with atleast one product and click on "Mark as Todo"
- Go to the Barcode app and find the created picking
- Scan all the reserved products
- Exit the picking and re-enter

# The problem
The "Add Product" button is displayed and you can scan unreserved products even tough you sould not be allowed to

# Cause of the issue
The problem stems from the fact that even with "Allow extra product" disabled, we still allow to add unreserved products for immediate transfers (created directly in the barcode app). The issue is that we don't really have a way to distinguish immediate transfers from plannified ones made in the Inventory app. So we try to guess using the `_useReservation` attribute (If it is false, we allow additional products).

`_useReservation` is computed as follows : if any move lines from the inital state is not yet picked, set it to true :
https://github.com/odoo/enterprise/blob/ca4b369e4fc9f4655574cf1ca71c81faaadc3e88/stock_barcode/static/src/models/barcode_picking_model.js#L43

So in our case, once all the reserved products are scanned, all the initial move lines are picked and our guessing fails.

# Proposed Solution
Since immediate transfers are never validated and stays in draft mode, guess using the state of the current picking in addition to `useReservation`

opw-6231238