**Steps to reproduce:**
 - Install l10n_din5008 and accountant.
 - Enable Snailmail from Accounting → Settings.
 - Create a German customer (Fiscal Country: Germany).
 - Create and post a customer invoice using the DIN5008 report layout.
 - Select Send by Post.
 - Enable Developer Mode and navigate to `Settings → Technical → Email → Snailmail Letters`.
- Open the generated letter and send it.

**Current behavior:**
The letter fails to be sent to Pingen with the following error: An error occurred when sending the document by post.
Error: ` The attachment of the letter could not be sent. Please check its content and contact the support if the problem persists.`

**Cause:**
For Snailmail documents, Pingen validates that the recipient address is located within the DIN5008 address window. The current l10n_din5008 report renders additional document information instead of the address in the address area, preventing the compliance validation to fail.

**Fix:**
When rendering the report for Snailmail, ensure that only the recipient address is displayed in the DIN5008 address window while suppressing the additional information that would otherwise occupy this area. This preserves the standard DIN5008 layout for regular reports while generating a Snailmail-compliant PDF that passes Pingen’s validation.

**Reference:** [Pignen Recipient Address Validation Rule](https://help.pingen.com/en/fix-and-enhance-letters/issue-with-recipient-address#040201)

Ticket [link](https://www.odoo.com/odoo/project.task/6387869)
opw-6387869

Forward-Port-Of: odoo/odoo#280320

### Steps to reproduce: 

- Create a subcontracted product P1
- Create a storable product P2
- Buy 5 units of both products from your subcontractor
- On the receipt set both moves quantity to 2 Units
- Validate the receipt and create a backorder
#### > Only the subcontracted move has been kept on the receipt and a backorder was created for 3 units of P1 and 5 of P2.

### Cause of the issue:

Setting the quantity of the subcontracted move will automatically record the quantities on the subcontracted MO: 
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/stock_move.py#L83
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/stock_move.py#L123
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/mrp_production.py#L91
However, the `_update_finished_move` method adds and update the related subcontracted move lines marking them as *picked* to adapt the related reservation:
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/mrp_subcontracting/models/mrp_production.py#L118-L164
This is problematic since picking a move line will also pick the move:
https://github.com/odoo/odoo/blob/9440ff9064c77af0159a427de8f5e5721aec0de5/addons/stock/models/stock_move.py#L261-L267
And only picked moves are considered to be processed at picking validation.

### Note:

The exact same issue had already been fixed in 17.0: db8b33ebb9fe23507bcba30b12741e4d688ae549
However, the fix had an issue concerning the barcode behavior as it removed the picked computation for subcontracted moves which made  hybrid pickings such as the above one (with one subcontracted and one non-subcontracted move) impossible to process in the barcode app. As such, the fix and test where reverted in cf2d18c92bee55ef79db1a338e9baf12f258ee5b

The present commit provides an alternative fix of the original issue keeping subcontracted moves unpicked by quantity changes without affecting the picked computation of subcontracted moves (e.g. adding  a picked move line on a subcontracted move will still pick that move).

Enterprise: https://github.com/odoo/enterprise/pull/123884

opw-6330584

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

Forward-Port-Of: odoo/odoo#275304

### Steps to reproduce:

- In the settings: Enable Storage Locations
- Create a customer location "Customer stock" with "Customers" as its parent location
- Create a delivery operation type "Deliver Super Customer" and set its default destination location to "Customer stock"
- Go to Inventory > Overview > Deliver Super Customer > New
- Set a contact on the transfer
#### > The destination location switches from "Customer stock" to "Customers"

### Cause of the issue:

The `location_dest_id` of `stock.picking` depends on its `partner_id`. So that changing the partner recomputes the locations of the transfer. However, as soon as the destination of the operation type has a `customer` usage, the `property_stock_customer` of the contact replaces it unconditionally:
https://github.com/odoo/odoo/blob/04f3a7bca99d0144a4ea871be9625db368b196ca/addons/stock/models/stock_picking.py#L949-L963 
However, the `property_stock_customer` falls  back to an `ir.default` pointing at the default `Customers` location when nothing is set on the contact:
https://github.com/odoo/odoo/blob/1c40fab04b71def8f3645c4c4bb0c1441057f307/addons/stock/data/stock_data.xml#L71-L72vs

The override comes from 8a0775aa1dd9, which replaced an `elif` fallback on the contact by an "unconditional" substitution as this fallback had become unreachable once `default_location_src_id` and `default_location_dest_id` were made required:
https://github.com/odoo/odoo/blob/04f3a7bca99d0144a4ea871be9625db368b196ca/addons/stock/models/stock_picking.py#L34-L41

opw-6421090

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

Forward-Port-Of: odoo/odoo#280016

**Steps to reproduce:**

-  Install the Serbian EDI module `l10n_rs_edi`.
-  Configure eFaktura credentials on the company.
-  Create and confirm a Serbian customer invoice.
-  Send the invoice to eFaktura.

**Observed Behavior:**

When the eFaktura API returns an HTTP error, Odoo only displays the generic exception generated by `requests`, for example an HTTP 400/500 error.

The actual error information returned by eFaktura in the response body is not shown to the user, making it difficult to understand why the invoice was rejected.

**Cause:**

`_l10n_rs_edi_send` catches `HTTPError`, `Timeout`, and `ConnectionError`, but the error message is built only from the Python exception.

For HTTP errors, the eFaktura API may return a response containing more precise information such as:

```json
{
    ErrorCode: ...,
    Message: ...
}
```

This response was not being used when displaying the error in Odoo.

**Fix:**

When an HTTP response is available and contains an eFaktura error payload, use the returned `ErrorCode` and `Message` as the error displayed on the invoice. Fallback to the existing connection/HTTP exception message when no usable API response is available.

opw - 6453653

Forward-Port-Of: odoo/odoo#281490

### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Put your warehouse in manufacture in 3 steps
- Create a storable product P
- Create and confirm an MO for 1 unit of P
- Go to Inventory > Operations > Procurement > Replenishment
- Create a new one for P in WH/stock
#### > The forecasted quantity in stock is still 0 but should be at 1

### Cause of the issue:

This is the exact use case already fixed in
85dd3369ed17b98b2ce485be04f140cf4cfa8aa3, which stamped the finished move with a `location_final_id` pointing at WH/Stock so that the move contributes to the forecast there even though its `location_dest_id` is the intermediate WH/Post-Production.

That fix was reverted in practice by 42275f83dc5350822a625e19d65148e8b41ab1d4, which replaced the value with `mo.location_dest_id`:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_move.py#L466-L467

Its reasoning was that in a single-warehouse setup `location_dest_id` equals the warehouse stock location, so the behaviour would be unchanged. That holds in 1 and 2 steps, where the extra step is on the component side and only moves `default_location_src_id` to the pre-production location. It breaks in 3 steps, the only mode that also moves `default_location_dest_id`, to the post-production location: https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_warehouse.py#L246-L247 and `_compute_locations` propagates it to the MO:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/mrp_production.py#L334-L341

WH/Post-Production is a sibling of WH/Stock under the warehouse view location, not a child of it. Since `location_final_id` takes precedence over `location_dest_id` for the non-done part of the move chain:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/product.py#L331-L334 the finished move stopped being counted in the WH/Stock forecast.

Why the test did not catch it:

`test_3_steps_manufacturing_forecast` stayed green through the whole regression, because it scoped `virtual_available` with a `location_id` context key. `_get_domain_locations` only reads `location` and `warehouse_id`; `location_id` is silently ignored: https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/product.py#L284-L287 The call therefore fell through to the branch scoping the forecast to every warehouse view location:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/product.py#L303-L309 and the warehouse view location is the common parent of both WH/Stock and WH/Post-Production. The assertion held regardless of where `location_final_id` pointed, so the test was a false positive from the start: it also passes with 85dd3369ed17b98b2ce485be04f140cf4cfa8aa3 fully reverted. Using the `location` key makes it fail without the fix and pass with it.

### Fix:

Neither fix proposition was right on its own; each one was correct only in its own scenario. The`mo.warehouse_id.lot_stock_id` resolves the warehouse from the components, so it points at the wrong warehouse as soon as the finished product is produced for another one. `mo.location_dest_id` is the post-production location as soon as the warehouse manufactures in 3 steps, so it drops the quantity from the forecast of the manufacturing warehouse itself.

What separates the two is not the warehouse but whether the destination is a transit step. In 3 steps the finished product only reaches the stock through the post-production push rule: https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_warehouse.py#L57 so the final location is the stock of the warehouse owning that destination. Any other destination is already final and is kept as is, which leaves cross-warehouse MOs and destinations set to a sub-location of the stock untouched.

The rule's destination is read rather than `warehouse.lot_stock_id` because a push move takes its destination from the rule and not from the operation type:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/stock_rule.py#L256-L260
so the forecast stays correct when the store step is reconfigured to land somewhere else than the warehouse stock.

The rule is looked up on `pbm_route_id` by its `picking_type_id` instead of through `warehouse.sam_rule_id`, because that field is no longer set. It used to be an entry of `_generate_global_route_rules_values`, and it is that entry which made the generic warehouse machinery create the rule and store it back on the warehouse:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/stock/models/stock_warehouse.py#L403-L410
11e69870db1c49d9a6af79ffd263e4e162b34b6b removed it when the post-production step stopped being a pull rule on the Manufacture route and became a push rule generated from `get_rules_dict`. Only the field declaration was left behind, and nothing writes it any more:
https://github.com/odoo/odoo/blob/6a56908e5febfdb4e6e0eacfb8655b092319819f/addons/mrp/models/stock_warehouse.py#L21-L22
so reading it would silently give an empty recordset. The lookup is not delegated to `_get_push_rule` to avoid a search per finished move.

opw-4882390

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

Forward-Port-Of: odoo/odoo#283234

Steps to reproduce
---
1. Create a quality control point on the Receipts operation type with Control per set to Operation.
2. Confirm a receipt of 2 units of the product: one pending operation quality check is created.
3. In the Barcode app, receive 1 unit and go back to the transfer with the back button.
4. The pending operation quality check is gone.

Issue
---
Going back from the Barcode app calls `post_barcode_process`, which on a partial reception splits the picked move into a done move and a remaining move, then merges the transient duplicate back with `_merge_moves`. https://github.com/odoo/enterprise/blob/b89614661682ecbd131d940539aac8afdd9d7289/stock_barcode/models/stock_move.py#L57-L60

`_merge_moves` cancels that transient duplicate through `_action_cancel` before unlinking it. https://github.com/odoo/odoo/blob/8f3100ca597559945cc42d9ef9517edbb40a900b/addons/stock/models/stock_move.py#L1400-L1401

The `quality_control` override of `_action_cancel`, picks the pending checks to drop from `is_product_canceled`, a `defaultdict(lambda: True)` keyed by `(picking, product_id)`. An operation check has no `product_id`, so its key is never computed by the loop and reads back the `True` default, so it is deleted even though the transfer still has a live move. Since an operation check covers the whole transfer, it must be dropped only when every move of its picking is cancelled. https://github.com/odoo/enterprise/blob/b89614661682ecbd131d940539aac8afdd9d7289/quality_control/models/stock_move.py#L68-L76

opw-6439179

Forward-Port-Of: odoo/enterprise#127427

Before this commit, it was impossible to use budget on the Moroccan P&L, for the following reasons:

- The feature was designed for one-column reports. MA's P&L uses 3, one of which is the total of the two others.

=> We remove that requirement, and make sure to always select the 'balance' column as the reference for the budget comparison.

- When trying to input a budget amount in the report, the amount disappeared entirely.

    => This was because the total column of report was not using 'balance' as its expression label. We fix that by rewriting the expression labels of that report.

The fact we hardcode the use of 'balance' is arguable. It is however not possible here to rely on some custom handler to change a specific option key that would be used to generate the budget comparison data, since some of those data need to be generated in the get_options, before _custom_options_initializer even gets called. This is the simplest approach, and this case is rare enough for us to deem it acceptable.

opw-6385229

Forward-Port-Of: odoo/enterprise#128266

### Issue before this commit:
When generating a SEPA Credit Transfer batch using the German XML format (pain.001.001.03), the <LEI> tag is erroneously included in the exported file if an LEI is configured on the company. This invalidates the XML, causing banks to reject the file.

### Steps to reproduce the issue:
1. Download Accounting and l10n_de
2. Go to Settins > Vendor Payments > SEPA Credit Transfer / ISO20022 and set Name Identification as 529900T8BM49AURSDO55 and Issuer as LEIMAN
3. Go to companies and set 529900T8BM49AURSDO55 as LEI in the DE company
4. Go to Accounting dashboard and click the 3 dots of the bank group, go to Configuration and set the Account Number and be sure in the Outgoing Payments tab XML Format is German
5. Create a new German company from Contacts with:
	1. Country as Germany
	2. VAT
	3. Account Number in the Bank Accounts by adding one line:
		1. example Account Number: DE65100500007201811026
		2. example Bank: BNP Paribas
		3. activate the Send Money button
7. Then go to Vendor > Payments and create a new one with Payment Method as SEPA Credit Transfer for the German company created
8. Go back and select the new payment from the list and click create batch and print it
9. In the XML of pain.001.001.03.(DE) file, the LEI tag should not be included.

### Cause of the issue:
The XML generation logic does not filter out the <LEI> element for older schema versions like pain.001.001.03, which do not support this tag.

### Reason to introduce the fix:
To ensure strict schema compliance and prevent bank rejections. The <LEI> element is now properly omitted from pain.001.001.03 files and restricted only to newer formats (e.g., pain.001.001.09) where it is valid.

opw-6428150

Forward-Port-Of: odoo/enterprise#127758