### Issue:
Negative values in the Mod 390 report were not properly marked with the N indicator for several fields

### Cause:
The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export

### Note:
According to the official specification, negative amounts must be explicitly marked with N
Latest documentation:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` with demo data and switch to the ES company
- Create a Bill (Price: 100, Taxes: 21% G)
- Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year
- Open the VAT Deductible tab
- The last line (65) should be negative
- Export the BOE file using the gear menu
- Check the last value of section 4 in the file

### Before the fix:
Negative values were not marked with N

opw-5482706

Forward-Port-Of: odoo/enterprise#113200
Forward-Port-Of: odoo/enterprise#111262

### Issue before this commit:
Before this commit, validating an Italian withholding tax return could incorrectly include taxes that are not related to withholding. In particular, pension fund taxes such as 4% INPS were included in the computed total amount to pay, even though they should not be part of the withholding tax return. As a result, the final amount shown in the return was incorrect.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it and switch to italian company
2. Create an invoice and a bill with a witholding tax (ex. 20% RIT PF)
3. Mark them as paid and reconcile them
4. Open a tax return and validate it
5. See that the total amount calculated includes also other taxes than only witholding taxes

### Cause of the issue:
The issue was caused by a missing domain restriction when computing the tax closing entries. The method _get_vat_closing_entry_additional_domain did not properly apply a filter on tax tags for the withholding tax return type l10n_it_reports.it_withh_tax_return_type. Because of this, the query used to compute tax balances included all taxes matching the generic conditions (date, company, posted state, etc.), without restricting them to the relevant withholding tax tags. Consequently, unrelated taxes were included in the computation.

### Reason to introduce the fix:
To restore the correctness of the tax return totals.

opw-5905355

Forward-Port-Of: odoo/enterprise#112638

Steps to reproduce:
1. Install modules `account_batch_payment` and `l10n_ch`.
2. Configure SEPA Credit Transfer for a CH company.
3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer.
4. Create a batch payment with the SEPA payment and validate it.

Issue:
The `&` character is exported as `&amp` in the generated PAIN XML,
while according to the SIX specification it should be replaced with `+`

Cause:
The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed.

Solution:
Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML.

Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf

opw-5941724

Co-authored by @bhra-odoo

Forward-Port-Of: odoo/enterprise#110809

Since odoo/odoo#249455 the order payload from the self order frontend is being checked to ensure the data is valid. However, these checks did not account for the situation where payment data is included, as is the case when using a self order kiosk with a payment terminal connected. The result was that using the kiosk with a payment terminal would result in an error even though the payment was successful on the terminal.

Steps to reproduce:
- Configure a self order kiosk POS
- Connect a payment terminal (Adyen, Stripe, Viva etc.)
- Try to pay for an order from the kiosk

EXPECTED:
- The order is made successfully.

ACTUAL:
- A generic error message is shown and the order fails. The payment goes through successfully on the payment terminal.

The fix is to allow a payment to be included in the self order data, but only in Kiosk mode and only if the payment amount is valid.

We also now validate that the self ordering type is correct, this
ensures that a kiosk payment cannot be spoofed for a mobile self order
POS.

Finally, there is also a small change for Viva.com to use the PoS config
name instead of UUID, since UUID is no longer loaded in self order.

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

**Problem:**
cogs is 0 if the delivery is multi steps with only first 
picking validated. 

**Steps to reproduce:**
- set the warehouse as 2 steps delivery
- create a tracked product avco perpetual
- set a cost of 10$ and a positive quantity
- create and confirm a SO for 1 quantity
- validate only the first picking
- create and confirm the invoice

**Current behavior:**
there is no cogs lines in the invoice

**Expected behavior:**
there should be cogs line for a cost of 10$

**Cause of the issue:**
to compute the unit price of the cogs we use 
_get_cogs_value()
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move.py#L122
Inside _get_cogs_value(), because there is done moves, 
we use _get_cogs_price_unit()
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move_line.py#L67-L68
But because there is no valued quantity (because the done 
moves are internal), the return value will be 0.
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L251-L253
So the cogs will have an amount of 0 and no line will be created
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/account_move.py#L125-L126

**fix**
The fix for consigned products introduced by this PR https://github.com/odoo/odoo/pull/255043
was working for the wrong reasons. 
_get_valued_consigned_qty() only works if the 
moves are partially consigned. 
If the move is fully consigned, _is_consigned_value_line() 
will return False for every move line.
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L650-L651
That's because if the move is fully consigned, _is_in() 
and _is_out() will return False. 
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move_line.py#L72-L74
So it only works if the move is not fully consigned 
because _is_in() or _is_out() will be True thanks to 
the non consigned line.
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L511-L519

However, _get_cogs_price_unit() still worked fine for fully 
consigned moves because if the move is fully consigned, 
total_qty will be 0 and the return value will be 0
https://github.com/odoo/odoo/blob/5fd80a1fb8ef33cfa9261967cf14f6f0c421d45a/addons/stock_account/models/stock_move.py#L251-L253

But this was hacky and prevented us to address the issue of this PR. 
The logic should be:
If there is no quantity to value (consigned + not consigned) 
we fallback on the standard price (just as if there is no move).
This solves the issue of this PR because no moves were 
valued moves in our use case.
If there is a quantity to value (and we're in a case where we want
the average move value), we use the average move value (which 
will be 0 if all the moves are consigned)

opw-6001694

Forward-Port-Of: odoo/odoo#256383

Steps to produce:
---
- Install `website_sale` module.
- Go to `website > shop`.
- Open the `Customizable Desk` product page.
- From the website editor, `enable the search bar` for the product page.
- Now search for `drawer`.

Issue:
---
- Searching from a product page always scopes results to the product's category, even when the user navigated directly to the product without selecting any category.

Root cause:
---
- The issue occurs because `_prepare_product_values()`[1] always assigns a category using the fallback `product.public_categ_ids[:1]` when no category is explicitly provided. As a result, the `keep` object is generated with `_get_shop_path(category)`[2], which produces a category-based shop URL. Since the search form action is defined as `keep(search=0)` [3] in the template, the generated search URL always includes `/shop/category/<slug>`, even when the user accessed the product page directly. This unintentionally scopes all searches to the product’s first public category instead of performing a global `/shop` search.

Solution:
---
- Separate the breadcrumb logic from the search context logic. Before automatically assigning a default category for breadcrumb display, store the originally requested category (which is None when navigating directly to a product).
- Use the auto-assigned category only for breadcrumb display.
- Use the originally requested category to build the keep QueryURL

[1]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/controllers/main.py#L796-L799 
[2]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/controllers/main.py#L806-L812
[3]https://github.com/odoo/odoo/blob/242afb9ca3a76e3628260ac81a9f5ddcd5d445dd/addons/website_sale/views/templates.xml#L360-L372

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

Forward-Port-Of: odoo/odoo#251751