### Steps to Reproduce:
- Enable dropshipping in Inventory settings
- Create a product with inventory tracking enabled
- Enable dropship under the Inventory tab for the product
- Add a vendor and quantity under the Purchase tab
- Create a sale order for the product
- Go to the Purchase stat button and confirm the order
- Click on the Dropship stat button and validate the transfer
- Open Helpdesk and create a new ticket for the same partner

### Issue:
The "Returns" stat button is not visible for dropshipped deliveries.

### Current behaviour:
- The helpdesk ticket allows returns of customer orders only if the order is outgoing. However, this does not cover the usecase where the order was dropshipped and still needs to be returned to the vendor.
- With the current behavior, the user needs to find the customer's order to return the transfer as it is not possible to do from the ticket.

### Expected behaviour:
Helpdesk tickets should also allow returns of dropshipped transfers (done and linked to the SO).

### Fix:
The helpdesk return logic was limited to only 'outgoing' pickings. This commit extends the 'return' button should be visible if there is at least one delivery or dropship order linked to the partner of the ticket

Issue:https://github.com/odoo/enterprise/pull/81378

task-4881338

Forward-Port-Of: odoo/enterprise#91402

Currently to exclude valuation accounts from the reconciliation we modify the domain by adding a second condition on the field account_id of the account_move_line table to exclude these accounts while including them in a first condition in the method we override.

This is not very efficient as it prevents the use of indexes on that second NOT IN condition.
Indeed PostgreSQL prioritizes the use of the index on the IN condition and then applies the NOT IN condition in a filtering step, which is very costly when there are many account_move_line records belonging to the inventory valuation accounts.

Here is an example of the before after on a database with 87 million account_move_line records total and 9.5 million account_move_line records matching the first IN condition via an index while only 1 million remain after applying the filtering of the NOT IN condition.

All measures are performed with a warmed up cache

[Explain Before](https://explain.dalibo.com/plan/d0d14efbe51ch359)

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~9s</td>
			<td>~1.5s</td>
		</tr>
	</tbody>
</table>

[Explain After](https://explain.dalibo.com/plan/e882cf62d1ga6955)

## Potential further improvement:

Add a partial index: 
```SQL
CREATE INDEX CONCURRENTLY idx_aml_company_id_account_id_unreconciled_posted
ON account_move_line (company_id, account_id)
WHERE parent_state = 'posted' 
  AND (reconciled IS NULL OR reconciled = FALSE)
  AND (display_type IS NULL OR display_type NOT IN ('line_section', 'line_note'));
```

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~1.5s</td>
			<td>~900ms</td>
		</tr>
	</tbody>
</table>

[Explain After + Index](https://explain.dalibo.com/plan/56dfdh554668ed43)

Part of https://github.com/odoo/odoo/pull/261931

Forward-Port-Of: odoo/enterprise#116524
Forward-Port-Of: odoo/enterprise#115581

When generating a VAT return with an unclaimed tax amount carried to the
next month, the carryover reimbursement move amounts are computed with
an incorrect ratio.

Steps to reproduce:
- Create and post a bill in May containing a VAT amount.
- Create and post a bill in June containing a VAT amount.
- Create a VAT return for May to carry over the VAT amount to the next
  month.
- Create a VAT return for June, requesting the full VAT amount to be
  reimbursed.
- Validate and send the June VAT return.
- Check the generated reimbursement move

Issue: Line values does not correspond to anything real/tangible.  It
occurs because when computing the ratio for the move we check the last
tax report entry, where we find the amount of tax from the past months
and a line balancing the last month that should not be taken into
account.  The "Balance tax current account (receivable)" line from the
tax closing entry is mistakenly picked up as a tax carried forward line,
throwing off the amounts.

opw-5961836

Forward-Port-Of: odoo/enterprise#116187
Forward-Port-Of: odoo/enterprise#115451