'_generate_valuation_lines_data' in mrp_subcontracting_account was not made to handle OUT stock move, this would cause problems when the user unarchive the subcontracting picking type, access the subcontracting MO and scrap parts of the produced quantity.

# How to Reproduce
- Create Subcontract BoM, with 1 cmp at $10
- Create & Produce a subcontracting MO with a purchase and additional cost of $10 => Finished product cost is $20 ($10 + $10)
- Scrap 1 unit of finished product => Journal entry for scrapped layer contains 3 AML instead of 2 => The additional cost is incorrectly added to the Stock Valuation account, making the line balance at -$30, while the layer is still at -$20

OPW-4640650

---

Test result without fix:
```
2025-04-24 09:26:06,083 18424 ERROR oes_test_17 odoo.addons.mrp_subcontracting_account.tests.test_subcontracting_account: FAIL: TestAccountSubcontractingFlows.test_subcontracting_account_flow_1
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/mrp_subcontracting_account/tests/test_subcontracting_account.py", line 174, in test_subcontracting_account_flow_1
    self.assertRecordValues(amls, [
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/odoo/tests/common.py", line 667, in assertRecordValues
    self.fail('\n'.join(errors))
AssertionError: The records and expected_values do not match.
Wrong number of records to compare: 3 records versus 2 expected values.

==== Differences at index 0 ====
--- 

+++ 

@@ -1,3 +1,3 @@

-account_id:300
-debit:60.0
-credit:0.0
+account_id:301
+debit:0.0
+credit:60.0

==== Differences at index 1 ====
--- 

+++ 

@@ -1,2 +1,2 @@

-account_id:299
-debit:30.0
+account_id:300
+debit:60.0

==== Additional record ====
{'account_id': 301, 'credit': 90.0, 'debit': 0.0, 'product_id': 107}
 ```

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

Forward-Port-Of: odoo/odoo#207204

In this PR:
##  [FIX] tools: don't export attributes that aren't translated anyway
PR #162079 made the list of translated attributes shared between QWeb and OWL templates. In hindsight, this was not a good idea, since:

- some attributes are exclusive to QWeb (e.g.: string)
- t-attf- variants of attributes are not translated in OWL
- it does not reflect the list of attributes that OWL actually translates

## [IMP] tools: add missing ARIA attributes to OWL_TRANSLATED_ATTRS
https://github.com/odoo/owl/pull/1679 made human-readable ARIA attributes translated by Owl.
This commit updates OWL_TRANSLATED_ATTRS so that ARIA attributes are also correctly exported for translation, and will therefore be fully translatable when the next version of Owl is released.

## [IMP] tools: make 'confirm-label' and 'cancel-label' translatable
'cancel-label' and 'confirm-label' are missing from the list of attributes to export for translation. This commit adds them to the list.

Forward-Port-Of: odoo/odoo#204692

Description of the issue/feature this PR addresses:
The "Quantities Available" field (shown in the product form vie smart button and the prognosis) can sometimes over-estimate the amounts actually available due to rounding. For example in the following case:
Product-A is made via Kit-BoM from 2 Units of Product-B. There are 3 units of Product-B in stock. The precision of the "Unit" UoM, used for Product-A, is set to 1 (only integer amounts). The actual amount of units available is 1.5, this is rounded as Half-Up to 2 Units. This is misleading, since only one unit of Product-A could be shipped.

Current behavior before PR:
For Kit-BoM Products, the quantities in _compute_quantities_dict() are all rounded with HALF-UP, potentially rounding up and claiming a higher availability than actually supported.

Desired behavior after PR is merged:
_compute_quantities_dict() rounds down to ensure it doesn't over-promise.



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

Forward-Port-Of: odoo/odoo#208374

Issue:

On a database with large stock pickings (> 100 stock moves per picking), displaying the tree view of stock pickings can be slow, because of the computation of the availability fields, as these fields are computed from the availability of the moves: 80 pickings per page means ~8000 moves to consider. If we are lucky the number of products to consider is lower than that, but on the customer database for which this PR is being done, we still have 3000 products. Displaying the 80 pickings on the first page takes 8 to 10s.

One of the issues found when analyzing the issue is that the 3 SQL queries performed on stock_move in the beginning of _get_report_lines are slow:

```
        past_outs = self.env['stock.move'].search(AND([out_domain, past_domain]), order='priority desc, date, id')
        future_outs = self.env['stock.move'].search(AND([out_domain, future_domain]), order='reservation_date, priority desc, date, id')

        outs = past_outs | future_outs

        ins = self.env['stock.move'].search(in_domain, order='priority desc, date, id')
```

Further analysis and testing show that using a domain with a negative condition ('not in') on the `state` column of stock_move prevents PostgreSQL from using the existing index on that column. By changing the condition in the domain to use a positive condition on that column, the execution time of each of the three queries goes from 1000-1500ms to about 100ms, saving about 3s on the total loading time of the page, which is still slow but a bit less.

Without patch:

```
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 151 3.907 4.824
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 155 3.998 5.284
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 167 4.246 5.725
```

With patch:

```
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 151 0.619 4.639
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 155 0.643 5.143
POST /web/dataset/call_kw/stock.picking/web_search_read HTTP/1.1" 200 - 167 0.862 5.618
```


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

Forward-Port-Of: odoo/odoo#207022

- Configure a payment method (e.g. `"demo"`) with an outstanding receipt account in the bank journal used by the website (automatic invoicing enabled). Enable Automatic Invoice for online payment.
- Create a partner on the website using an incognito window. In the backend change their default property_account_receivable_id. Assign them a fiscal position where the receivable account is mapped to another account.
- Make a purchase using the `"demo"` payment method with the new partner.

The generated invoice and its corresponding journal entry do not share the same `account_id` (Account Receivable).

The invoice uses the `account_id` computed in `_compute_account_id` of `account.move.line`, which is not necessarily the same as the `account_id` set on the partner.

After this commit, the payment uses the same `account_id` as the related invoice, (same as _create_payment_vals_from_wizard)  avoiding any discrepancy.

opw-4669927

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#204489

### Steps to reproduce:

- Install both mrp and quality_control
- Create 2 products:
    - FP (Final Product)
    - COMP (Component) tracked by SN > pu SN1 to SN4 in stock
- Create a BOM for FP using COMP as component, add an operation with an instruction of type "Register Consumed Materials" for SN control per product.
- Create and conform an MO for 2 units of FP: SN1 and SN2 are reserved
- Click on the wheel icon > Split production > Split in 2
- On the MO-001, SN1 is reserved
- Open the operation in the shopfloor and proceed with the quality check
#### > It is currently refering to SN2 !!
- register SN3
#### > It did not alter the value of the lot referred to on MO-001. It did update the serial number present on MO-002 from SN2 to SN3.

### Cause of the issue:

Confirming the MO will in turn confirm the workorder and create a quality check for the consumed material registration of SN: https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L625-L628 https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L415-L421 At this point, the create quality check is linked to the MO but also to the first move line (sml1) of the raw move (m1) refering to SN in that MO:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/mrp_workorder.py#L495-L503 However, the `move_id`, `move_line_id` and `production_id` are all three stored non computed fields of the `quality.check` model. The issue will then be that when the production is split, MO will be renamed MO-001 the QC will still refer to MO-001, sm1, sml1 but sml1 will be reassigned to the raw move of the new production MO-002. In particular, while the QC is still accessed from MO-001 and still refer to the raw move sm1 of  MO-001, it actually updates the values MO-002 since performing these kind of quality checks actually updates the qty and lots on the move line it is related to:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/mrp_workorder/models/quality.py#L507-L508 Now, the reason why sml1 is reassigned to the mo to back order rather than staying on sm1 and hence on MO-001 is because the order of stock move line is altered to be reassigned by these lines during the `_split_production`:
https://github.com/odoo/odoo/blob/e4bd46930d1841fcd50bf426f5625e9495213ef7/addons/mrp/models/mrp_production.py#L1890-L1895 Currently, this order puts sml with an existing quality check after stock move lines without QC:
https://github.com/odoo/enterprise/blob/a26df8b50b923a2b23b8406d798febbdf1a72415/quality_mrp/models/stock_move_line.py#L36-L41 As such, they will end up being assigned with the latest backorder to assign.

### Fix:

Since these kind of QC's are created at confirmation and since the first MO will not be reconfirmed, it is important that the QC created for MO-001 stays linked to that MO. In order to achieve this, move lines associated with a QC should definitely stay assigned to the first MO and the sml should therefore be ordered by these without QC last.

opw-4656240

Forward-Port-Of: odoo/enterprise#84606

Steps to reproduce the bug:
- Create a quality point with the following settings:
    - Measure on: Operation
    - Picking Type: Manufacturing
    - Product Category: "All"

- Create a storable product “P1”:
    - Product Category: "All"
    - BoM: - components: - 1 unit of P1

- Create a manufacturing order to produce one unit of P1
- Confirm it

Problem:
The manufacturing order is confirmed, but the corresponding quality check is not created.

This issue occurs when a quality point is configured with "Measure on:
Operation". In that case, the quality check should be created for
manufacturing orders here:
https://github.com/odoo/enterprise/blob/18.0/quality_mrp/models/stock_move.py#L49-L51

However, an empty record is passed for the product parameter.
As a result, the domain defined here:
https://github.com/odoo/enterprise/blob/18.0/quality_mrp/models/stock_move.py#L19-L21

is evaluated with both product and category set to False, which
prevents the created quality point from being matched and thus no
quality check is created.

https://github.com/odoo/enterprise/blob/6ee3472937118e758399a9577251efad8c4c1195/quality_control/models/quality.py#L175-L177

opw-4762914

Forward-Port-Of: odoo/enterprise#84683