Currently the query to get the closing difference account move is done by searching for the reference of the move, which is not very efficient. This commit optimizes this query by adding the journal to the search criteria, which allows us to benefit from the index on the journal_id field.

Here is an example of the before after on a database with 39 million account_move records. Meanwhile only 10-20K account_move are linked to specific journals used in POS payment methods.

All measures are performed with a warmed up cache

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

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of am</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>38982635</td>
			<td>~17s</td>
			<td>~22ms</td>
		</tr>
	</tbody>
</table>

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

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

Forward-Port-Of: odoo/odoo#262148

**Problem:**
account move created by stock valuation layer 
does not take analytic account from PO

**Steps to reproduce:**
- make sure you have at least one analytic account
- create a storable product with categ standard automated
- set a positive cost
- create a PO for 1 quantity 
- on the PO line of the product, in the analytic distribution 
column (might need to be unfiltered) set an analytic account
- confirm PO and validate receipt
- click on the valuation smart button and on the book widget
of the stock valuation layer

**Current behavior:**
the account move lines have no analytic distribution

**Expected behavior:**
The account move lines should inherit the analytic account 
from the purchase order line like it's the case for the bill.

For the analytic distribution of the Bill, the selection is : 
1) take analytic distribution from PO if one
2) if not, take from distribution model if there is one
3) empty

Currently for the account move lines of the svl the selection is: 
1) take from distribution model if there is one
2) empty
But we should use same selection as for the bill

**Cause of the issue:**
When setting the analytic distribution we first 
try to use the one from PO/SO by calling 
_related_analytic_distribution()
https://github.com/odoo/odoo/blob/4cc1e6884be673523f768d5ec471a1ffa19c5fb4/addons/account/models/account_move_line.py#L1157
But since the account move lines have no purchase_line_id
no analytic distribution will be returned
https://github.com/odoo/odoo/blob/4cc1e6884be673523f768d5ec471a1ffa19c5fb4/addons/purchase/models/account_invoice.py#L540-L545


opw-6022695

Steps to reproduce
1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set `intrastat_supplementary_unit_amount` on it.
2. Post EU customer invoices for that product.
3. Export the DEBWEB2 XML from the Intrastat report.

Issue
The FR export collapses engine rows a second time in `_group_items`, because the DEBWEB2 format groups more aggressively than the SQL. The aggregator only declares `value` and `weight`: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/models/account_intrastat_report.py#L308-L313 Items are then rebuilt as `dict(zip(grouping_key, key_tuple)) | grouped_item_values`. `SU_code` survives (it is in the grouping key), but the numeric `supplementary_units` is in neither side and is silently dropped as soon as two engine rows merge. The template then skips the element because of its `t-if="item.get('supplementary_units')"` guard: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/data/intrastat_export.xml#L61

opw-6139657

Steps to reproduce
-----
- Modules: Sale, Purchase, Mrp, Accounting
- Enable automatic accounting & anglo-saxon valuation
- Create an AVCO Product category (AVCO automatic valuation)
- Create a Kit product storable & AVCO
    - Kit bom
    - Comp as a component (storable & AVCO)
- Settings > Decimal Accuracy > Product Price > set to 4 digits
- Purchase 3 units of Comp at 3.3333 piece & validate reception
- Make 2 sales for 1 unit of Comp each & validate both deliveries
- Create a SO for 1 Kit and 1 Comp & confirm
- Create & confirm invoice
- Go to the delivery, force quantity on the component and try to validate delivery

> Error message: "You are trying to reconcile some entries that are already reconciled."

/!\ Fun(?) fact: this error doesn't occur if the order of the moves is inverted.

Cause
-----
When the purchase delivery is validated, a stock valuation layer is created for 3 units with a value of 10. As they are sold individually, these 3 units generate a valuation layer for 3.33 per unit summing to 9.99.

When we validate the last delivery, the 0.01 difference is detected and an adjustment is made on the valuation layer in `_prepare_out_svl_vals`.

However this adjustment is made for the product when the invoice line concerns the kit. As a result, the first reconciliation fails and the line is added to the list to be reconciled later.

Then, when handling the line for COMP2, it will successfully reconcile the lines while it is still in the pool to be reconciled, resulting in an error when attempting to reconcile it later.

This is caused by `_stock_account_anglo_saxon_reconcile_valuation` where the `product_stock_moves` only contains the kit move when called with the kit product as argument, but it contains both moves when called with the component itself as argument. This leads to the same AML being reconciled twice.

https://github.com/odoo/odoo/blob/f0b9f4c234cd0101f5cb259e58620e1cf65bb2b7/addons/stock_account/models/account_move.py#L222-L225

-----
Ticket:
opw-5722072

Forward-Port-Of: odoo/odoo#258013