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:

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