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

Issue
-----
If the account on which stock revaluation is registered has a default tax, the account moves generated by changing the price of the product include the tax.

For context, the issue was reported because some l10n modules use accounts with default taxes (eg l10n_de).

Steps to reproduce
-----
- Install a localisation to have default accounts set up
- Create a product category (Cat1)
	- Set Inventory Valuation to "Automated"
	- Set a default tax on the Expense Account
- Create a product Prod1
	- Storable
	- Category set to Cat1
	- Cost set to 500
- Update the on hand quantity of Prod1 to 1
- Change the price of Prod1 to 300
- Go to Accounting > Accounting > Journal > Journal Entries

--> There is an AM for 200 + tax instead of just 200

Discussion
-----
When manually changing the cost of the product, we call

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/stock_account/models/product.py#L354

Where we create the AMs

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/stock_account/models/stock_valuation_layer.py#L294

This creates the corresponding debit/credit AMLs. Afterwards, we go through

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move.py#L3210

Which calls `_sync_tax_lines` where AMLs are created for the taxes

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move.py#L3088

Solution
-----
The AML's `tax_ids` field is precomputed

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move_line.py#L192-L198

and takes the taxes from the account

https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move_line.py#L894

By explicitly stating an empty value when we create the AM in `_change_standart_price_accounting_entries`, we avoid the compute so tax lines don't get created.

-----
Ticket:
opw-5929774

Forward-Port-Of: odoo/odoo#256024

Steps to reproduce
------------------
1. Create a sale order with 2 products, confirm it
2. Cancel the SO, then click "Set to Quotation"
3. Open PoS, settle the order and pay
4. Check the delivery order linked to the PoS order

The delivery is empty, yet the products still show as "delivered" on
the sale order.

Why it's happening
------------------
When the SO is cancelled, its moves go to 'cancel' state. After
resetting to quotation, those moves stay cancelled. When PoS creates
the delivery, the filter in `_create_move_from_pos_order_lines` checks
`has_valued_move_ids()` which returns False (all moves are cancelled),
and `not move_ids` is also False (cancelled moves still exist). So the
lines coming from the SO are excluded from the delivery.

The fix
-------
We now also create deliveries for lines whose SO moves are all
cancelled. These are lines coming from a cancelled SO that now need
to be shipped after we have settled their order from PoS.

Note
----
The commit c0f338711f028088c98ea459f27c1669b29738d7 fixes this starting from saas-18.2, by introducing a separate `pos_repair` module which simplifies the main `pos_sale` code. In 18.2+, only the test will be forward ported.

opw-6055856

Forward-Port-Of: odoo/odoo#263369
Forward-Port-Of: odoo/odoo#256693

When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.

Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me

Observed Behavior:
All the documents are fetched.

Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.

Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown

From:
`('need_my_signature', '=', True)]`

To:
`[('need_my_signature', 'in', [True])]`

This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.

As a result, instead of filtering documents, all documents are returned.

[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108

[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177

Fix:
Corrected the return domain logic to fetch the correct documents.

opw-6026935

**Steps to reproduce:**
- On a new company, activate automatic valuation and anglo-saxon accounting.
- Create a new product, and set the cost to 5.
- On the product category, set the costing method to AVCO and the valuation to automatic.
- Create a Purchase Order for the product, confirm it and recieve it, but don't create a Bill yet.
- Create a sales order with the same quantity as the purchase order, and deliver it.
- Now create a bill for the original Purchase Order, and change the price to 6.
- Manually change the total tax amount on the Bill, and then post it.

**Issue:**
After posting the Bill, the value set manually on the total tax is recomputed and overwritten.
This is because the price difference between the bill and the original cost creates two new price difference lines on the bill, and this triggers the move sync to recompute the tax.

**Solution:**
Set the context `skip_invoice_sync` to True when creating the price difference lines.

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

Forward-Port-Of: odoo/odoo#259331