Steps to reproduce:
-----------------------------------
1. Install Subscription module
2. Create and Confirm Subscription Order as follows: * Create 2 SOL with the same product with different quantities
3. Create and Confirm the Invoice of the Sale Order
4. Create an Upsell of the SO
5. Change the First line's quantity to any value (e.g, 3)
6. Confirm the Upsell Order
7. Go back to the original order

Observation:
-----------------------------------
The quantity added in Upsell is added to the quantity of the Second line of the Original Order.

Issue:
-----------------------------------
The `_compute_parent_line_id` method matches upsell lines to their parent lines based on product attributes (product_id, price_unit, product_uom_id, currency_id, plan_id). When multiple parent lines have identical attributes, the matching becomes ambiguous.

The algorithm processes upsell lines sequentially and removes each matched parent from the pool.
https://github.com/odoo/enterprise/blob/4c9682e9cf84a0e4e69b5b650833cbccc77b063e/sale_subscription/models/sale_order_line.py#L336-L337

Without a stable identifier like a sequence, the algorithm takes the LAST matching line arbitrarily, causing incorrect parent-child mappings.

Solution:
-----------------------------------
Using 'sequence' as the matching criteria in `_compute_parent_line_id`, Sequence provides a stable, predictable identifier that preserves line order. Lines with the same product attributes but different sequences will now match correctly based on their position in the order.

Added 'sequence' to line_values in `_get_renew_upsell_values` because the `parent_line_id` field is a COMPUTED field (with `store=True`). When creating upsell lines, even though we set `'parent_line_id': line.id` in the values, Odoo will recompute it using `_compute_parent_line_id`. If we don't preserve the sequence from the parent line, the newly created upsell line will get a default/auto-incremented sequence that doesn't match its parent's sequence. This breaks the sequence-based matching we just added.

opw-6083153

Problem:
The previous fix (replacing '&' with '+' in _replace_characters_SEPA) was applied globally, affecting both reference/identifier fields and human-readable fields such as <Nm> (partner name) and address lines.

As a result, a partner named "test & test GMBH" was exported as:
  <Nm>test + test GMBH</Nm>
instead of the expected:
  <Nm>test & test GMBH</Nm>

This caused bank file rejections because '&' is the correct XML encoding of '&' and is accepted by banks in human-readable fields.

Root cause:
ISO 20022 / EPC217-08 distinguishes two categories of data elements:

- Reference/identifier fields (InstrId, Ustrd, etc.): must use the restricted basic Latin character set — '&' is not allowed and must be replaced with '+'.

- Human-readable fields (Nm, AdrLine, etc.): may contain the extended Latin character set — '&' is valid and must be preserved so lxml can XML-escape it to '&' in the output.

Fix:
Revert the global '&' → '+' replacement in _replace_characters_SEPA so that '&' is preserved for name/address fields. The replacement of '&' with '+' for reference/identifier fields is already handled explicitly at the call sites in _get_CdtTrfTxInf (InstrId, Ustrd) via .replace('&', '+') before sanitize_communication is called.

ref commit : https://github.com/odoo/enterprise/pull/110809/changes/9e698e4ac9fdf66189ff6712f90a144560a1b484
documentation https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf:

## [FIX] core: lxml compatibility v2.14.0+ (HTML parsing)

In version 2.14.0, libxml2 fixed a long standing quirk in its HTML
handling where it always implies `<p>` start tags [1].

As a result, there is a difference in behavior between pre and post
2.14.0 produced HTML when no start tag is provided:
- pre: always has a `<p>` tag
- post: depending on the case, could have either a `<span>` or `<p>` tag.

This commit introduces a monkeypatch of the lxml's HTML parser when
built with libxml2 2.14.0+ to maintain a similar behavior with older
versions.

[1]: https://gitlab.gnome.org/GNOME/libxml2/-/commit/8cf6129bbd836e666e7eda8c9e61c00387ae388b


## [FIX] base,l10n_it_edi: catch TypeError/ValueError for lxml 6+ compat

Updates exception handling to account for stricter type checking
introduced in lxml 5/6 and libxml2 2.12+.

Note: Ubuntu 26.04 (Resolute) provides lxml 6.9.2/libxml2 2.15 while
Debian Trixie has lxml 5.4.0/libxml2 2.9.14. Don't be fooled by the
version `2.12.7+dfsg+really2.9.14-2.1+deb13u1` which actually means that
Debian has reverted/held back the core engine to 2.9.14 while adding
commits from 2.12.7.

Steps to reproduce
1. Create a serial-tracked product with a subcontract BoM.
2. Create a receipt from the subcontractor for e.g. 5 units and confirm it.
3. Change the quantity to 3 and validate the receipt and click "Create Backorder" in the wizard.

Issue
Clicking "Create Backorder" raises "The serial number has already been
assigned" because the remainder backorder MO was silently assigned the
same serial as one of the recorded MOs, causing a quant uniqueness
violation.

When validating a serial-tracked subcontract receipt, `_auto_record_components`
splits the original MO into one MO per unit plus a remainder backorder MO,
and assigns a fresh serial to each recorded MO. It then calls
`subcontracting_record_component` which writes `lot_id` on reserved
`stock.move.line` records via `_update_finished_move`. The write override in
`stock.move.line` is meant to sync the matching MO's `lot_producing_id` when
a user changes a serial from A to B on a move line. Its filter at

https://github.com/odoo/odoo/blob/f251139ab668651cbd359fdae73befaf1683085b/addons/mrp_subcontracting/models/stock_move_line.py#L26

  p.lot_producing_id == move_line.lot_id

degenerates when the move line's previous `lot_id` is `False` (a freshly
reserved line with no prior lot) into "any open MO with no lot yet", which
matches the untouched remainder backorder MO and writes the just-assigned
serial onto it. All recorded MOs end up sharing the same serial number from
the contaminated backorder, triggering the duplicate quant error.

Solution
Guard the sync with `move_line.lot_id` at

https://github.com/odoo/odoo/blob/f251139ab668651cbd359fdae73befaf1683085b/addons/mrp_subcontracting/models/stock_move_line.py#L24

so it only runs when the move line already had a lot — i.e. the user is
replacing an existing serial — and not when one is being assigned for the
first time.

opw-6018243

Steps to produce:
---
- Install `website_sale` with demo data.
- Go to `website > ecommerce > products > ecommerce categories`.
- Open `Desks/Components` category > Set website to `My website 2`.
- Open the shop page on website > Click on Desks category.

Issue:
---
- The Components subcategory is still displayed on Website 1.
- Clicking on it leads to a Not Found page since the category is not assigned to that website.

Root cause:
---
- At [1], In the category filmstrip template, subcategories are fetched without filtering based on website access.
- As a result, categories restricted to another website are still shown.

Solution:
---
- Filter categories using the `can_access_from_current_website` method to ensure only categories accessible from the current website are displayed.

[1]https://github.com/odoo/odoo/blob/900fc043064216c5943ea07392d8120be7b50b63/addons/website_sale/views/templates.xml#L758-L769

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