When a company has a shortened fiscal year defined via account.fiscal.year (e.g. May-December), the depreciation board computation for degressive assets incorrectly computes the start of the next fiscal year using `date_from + 1 year` instead of querying the actual next fiscal year. This causes entries for the months between the wrong and correct FY start (e.g. January-April) to be skipped entirely.

Step to reproduce:
- Create a company with a fiscal year starting in May (e.g. May 1st 2025 to 31st December 2025)
- Create an asset with a start date in the 1 December 2025, with a 24 months duration and degressive method
- Compute the board and observe that entries from January to April 2026 are missing

Fix the FY boundary detection in _recompute_board to query the fiscal year containing the day after the current period end, revert the effective_start_date logic in _compute_board_amount that was masking the root cause, and move the prorata date clamping to _create_move_before_date where it is needed for disposal.

opw-6016834

Forward-Port-Of: odoo/enterprise#113521

The invoice outstanding credits/debits widget currently displays all reconcilable items for a partner across the same account, regardless of the company they belong to.

In multi-company environments, specifically when accounts have been merged, this allows users to see
and try to reconcile payments from Company A into an invoice from Company B. This action eventually triggers a validation error stating that entries must belong to the same company.

This commit adds a company filter to the widget's logic to ensure only relevant outstanding payments are suggested, preventing cross-company reconciliation errors and improving UX.

**Description of the issue/feature this PR addresses:**
This PR fixes a validation error in multi-company environments where the invoice_outstanding_credits_debits_widget suggests payments or credit notes belonging to a different company than the current invoice.

The issue typically arises when a partner has outstanding transactions in multiple companies and the accounts (e.g., Account Receivable) have been merged, allowing the widget to query lines that are not valid for the current record's company context.

**Current behavior before PR:**
When viewing an invoice for Company A, the "Outstanding Credits/Debits" widget displays all reconcilable account.move.line records for that partner that match the account type, regardless of their company_id.

If a user clicks "Add" on a payment that belongs to Company B, Odoo attempts to reconcile them, resulting in a traceback or a validation error:

"Invalid Operation: All tracebacks/entries must belong to the same company."

This creates confusion for the end-user, as they are presented with "ghost" credits that cannot actually be applied.

**Desired behavior after PR is merged:**
The invoice_outstanding_credits_debits_widget (and the underlying logic in account.move) will strictly filter the suggested outstanding items by self.company_id.

Users will only see and be able to reconcile payments, credit notes, or debits that belong to the same company as the invoice they are currently processing. This ensures data integrity and a seamless UX in multi-company setups.

**Steps to reproduce:**
1) Enable Multi-Company: Ensure you have at least two companies (e.g., Company A and Company B) active in your database.

2) Chart of Accounts Setup:

In both companies, use the same account for Receivables (or merge them so they share the same ID/Code if testing a migrated environment).

3) Ensure the account is marked as Allow Reconciliation.

4) Create a Payment in Company B:

5) Post the payment so it remains as an "Outstanding Receipt".

6) Create an Invoice in Company A

7) Confirm/Post the invoice.

8) Check the Widget:
Scroll down to the bottom of the Invoice form in Company A.

9) Observe the "Outstanding Credits" widget.

The Error:
The payment from Company B will appear as an available credit for the invoice in Company A.

10) Click on "Add".

A validation error (UserError) will pop up: "All entries must belong to the same company."

**video**
https://drive.google.com/file/d/1PfBxupP8t-t21wsP2FIgNXFnTP0Zq140/view

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

Forward-Port-Of: odoo/odoo#255875

Concurrent processing of emails with the same `Message-Id` can create duplicate records.

### Steps to reproduce

1. Configure multiple mail aliases (e.g., two helpdesk teams).
2. Send one email with both aliases as recipient.

The Mail Transfer Agent may invoke `odoo-mailgate.py` once per recipient, resulting in concurrent processing of the same email in separate transactions.

We expect one record per alias/team, but duplicates may be created.

### Cause

This is a race condition in the `Message-Id` deduplication logic, caused by concurrent transactions and PostgreSQL snapshot isolation.

Odoo uses the `REPEATABLE READ` isolation level. This means that each transaction takes a snapshot of the database at its first query and cannot see changes committed by other concurrent transactions.

When two concurrent transactions process the same email:

1. Both enter `message_process` and take their snapshot.
2. Both search for the `Message-Id`. Because their snapshots don't include each other's work, both find nothing.
3. Both create records.

Even if one transaction commits before the other performs the check, the second transaction still uses its original stale snapshot and create duplicates.

### Fix

After the initial duplicate check, attempt to acquire a transactional advisory lock on a hash of the `Message-Id` using `pg_try_advisory_xact_lock`. If another transaction is already processing the same email and holds the lock, the call returns false and the email is treated as a duplicate. If the lock is acquired, processing continues as normal.

opw-5116492

Forward-Port-Of: odoo/odoo#258847
Forward-Port-Of: odoo/odoo#250027

Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries to assign both picks as the `return_id` because they share the same `sale.order.line` here: https://github.com/odoo/enterprise/blob/2212b3f3f3d90894dd6351defe0d3ca090584955/sale_stock_renting/models/sale_order_line.py#L404

Purpose: Use [:1] to safely handle the case where multiple pick transfers are created, avoiding a crash when assigning return_id which expects a single record.

Steps to Reproduce on Runbot:

1. Enable mutli-step routes and rental transfers.
2. Set the warehouse to 3-step delivery.
3. Copy the existing packing location.
4. Copy the existing pick operation type and set the destination location to the new packing location. 
5. Create a new route.
6. Create new rules on this new route with the following configurations:
   1. Rule 1
      1. Action: Pull
      2. Source location: WH/Stock
      3. Destination location: Partners/Customers
      4. Operation type: The new pick operation type
   2. Rule 2
      1. Action: Push
      2. Source location: New pack location
      3. Destination location: WH/Output
      4. Operation type: Pack
   3. Rule 3
      1. Action: Push
      2. Source location: WH/Output
      3. Destination location: Partners/Customers
      4. Operation type: Delivery
7. Create 2 component products tracked by inventory, and apply the new route on one of the component products.
8. Create a new rental product with a kit, which has the 2 component products.
9. Create a new rental order for the kit product and confirm it. 


opw-6026918

Forward-Port-Of: odoo/enterprise#112543

**Purpose:**
Since a stock.quant is a combination of the stock move lines of a product
and a location, it should be restricted by the product's company.

**Before this commit:**
In a multi-company environment. If a purchase order with product from
company 1 is being confirmed, received, and validated when company 2 is
being selected as the primary active company while company 1 is also
checked. It will create a stock.quant that is searchable for company 2.
However, it will raise an error when company 2 is trying to access it.

**After this commit:**
Even if the stock.quant is created when company 2 is the primary active
company, it will not be searchable for company 2 since the product's
company is company 1.

**Steps to Reproduce on Runbot:**

- Create a storable product exclusive to Company A
- Create & validate a receipt for that product in Company A.
- Switch to Company B -> Reporting > Locations > Remove all filters: The negative quant for the product in Partners/Vendors is visible.

opw-6082330

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

Forward-Port-Of: odoo/odoo#259195
Forward-Port-Of: odoo/odoo#257211