> Commit 1:

[FIX] web_editor: prevent infinite bounce loop when clicking undo

Steps to reproduce:
1. Click an inner snippet without dragging it.
2. Observe that the "Drag building blocks here" section starts bouncing.
3. Drag any snippet and wait for the Undo option to appear.
4. Click Undo, then Redo.

Issue:
- This leads to an infinite bounce loop when using Undo/Redo.

Expected behavior:
- Infinite bouncing should not occur.

This PR prevents unnecessary history steps by disabling history tracking during this phase using `observerUnactive` and `observerActive`. This ensures that the editor does not record redundant changes, preventing infinite bounce loops.


> Commit 2:

[FIX] web_editor: fix dropdown options value

Steps to reproduce:
1. Go to the website and drag and drop the form snippet.
2. Change the action to 'Subscribe to Newsletter'.
3. Click on multi-checkbox field to view its options.

- Even after selecting an option, it remains in the dropdown, allowing multiple selections of the same option.

Expected behaviour:
- Once an option is selected, it should be removed from the dropdown.

Solution:
This PR removes the count from the display name, ensuring correct form behavior.

task-4583314

Forward-Port-Of: odoo/odoo#203454

**Steps to reproduce:**
* Install the *Accounting* module.
* Install localisation modules for two different regions:
  * *Belgium* (**l10n_be**)
  * *Luxembourg* (**l10n_lu**)
* Configure two companies, each assigned to one of the above regions.
* Create fiscal positions:
  * In the Belgium company, create a fiscal position for Luxembourg.
  * In the Luxembourg company, create a fiscal position for Belgium.
* Go to *Accounting > Configuration > Settings*. Enable *Inter-Company Transactions*. Enable synchronization of *Vendor Bills and Invoices* for both companies.
* Create an invoice in the Luxembourg company. Select a partner belonging to the Belgium company. Add a product with applicable taxes.

**Observed behavior:**
* A validation error is raised: 'This entry contains taxes that are not compatible with your fiscal position. Please check the country set in the fiscal position and in your tax configuration.'

**Cause:**
* During intercompany bill creation, a foreign fiscal position is applied before recomputing taxes.
* If no mapped foreign taxes exist, the system keeps domestic purchase taxes.
* This leads to a mismatch between taxes and fiscal position, triggering the validation error.

**Fix:**
* Add a safeguard in *_inter_company_create_invoices()*.
* After *_inter_company_sync_invoice_line_taxes()* recomputes taxes, *_inter_company_has_incompatible_fiscal_position_taxes()* checks whether the fiscal position is incompatible.
* If incompatible, the fiscal position is removed and taxes are recomputed without it.

opw-6103671

Forward-Port-Of: odoo/enterprise#115085

Currently, after validating a transaction with a manual operation, the
aml resulting from the manual operation can still be selected and
matched with other transactions.

Steps to reproduce:
- Create a transaction for 500 dollars
- Create a manual counterpart line for the bank statement line with
  label "test123" and validate
- Create another transaction of -1000 dollars and label "test123"

Issue: The manual counterpart line matched before is being suggested
against the new transaction. The perfect match reconciliation model will
reconcile the manual counterpart line with the new bank statement line.

Analysis:
During the retrieval of possible aml to match we only look at the aml
reconciliation state. Manual counterpart lines created during the
validation of a previous statement line are still selectable candidates,
causing false positive matches in automated reconciliation models.
Test in Enterprise: https://github.com/odoo/enterprise/pull/115847

opw-6045050

Forward-Port-Of: odoo/odoo#262295

Backport of 7c68c3dbb29eaad4e09d59ef7c86bd525969caec Including its fix: e490c0c66561715853a3f80658f47c940bc453dc

### Issues:

Cancelling the move dest of a manufacturing order does not cancel the MO nor log's an activity warning for the responsible to update the manufacturing demand manually.

Additionally, when selling MTO manufactured products, cancelling the delivery and then changing the sol's demand will update the MO for an incorrect amount.

### Steps to reproduce:

- In the settings: Enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive the MTO route
- Create an MTO, amnufactured product with BOM
- Create and confirm an SO for 3 units of that product
- Cancel the delivery of 3 units
#### > There is no notification on the unrelevant MO linked to the SO
- Adapt the quantity of the SOL from 3 to 0
#### > The delivery is cancelled but no activity is logged what's so ever

### Expected behavior:

Both of these operations should log an activity as the demand of the MO is not updated on quantity decrease.

opw-6010109
opw-6105366
opw-6100043
opw-6087909

X-original-commit: 796316c341c4346152ad9610c30679f47aaa2ff8

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

## Issue 1:

Backport of 7654c558c4d517807884b0a82323dd160feeda2a

For Colombia, Envia expects the municipality/DANE-style code in the address payload, not the raw postal code.
    
When `l10n_co_edi` was not installed, the Envia integration fell back to the partner zip code and padded it locally before sending it as both `postalCode` and `city`. This produced incorrect values such as turning the Ibagué zip code `730001` into `73000100`, while Envia geocodes resolves that zip code to `73001000`.
    
Use Envia geocodes to resolve the Colombia zip fallback and retrieve the `stat_8digit` code expected by Envia instead of deriving it locally.

## Issue 2:

### Steps to reproduce:

  - Install delivery_envia
  - Website > Configuration > eCommerce > Delivery Methods > Envia
  - Enable the delivery method, sync the carrier and Publish it
  - With a portal user > Shop > Add any product to your cart > Checkout
  - Register an address a valid 'Chile' address and confirm say:
      'street and Number': Avenida Providencia 1432, Depto 402
      'city': Santiago 'zip': 8320000
      'country': Chile 'state': Metropolitana
  > Envia Error: Invalid Option - String is too long at #->properties:destination
  
### Cause of the issue:
  
The problem is caused by the fact that Envia's api expects a 2-3 digits to represent state codes: https://docs.envia.com/reference/state-by-code
The mapping from Odoo's code state representation to envia's one is expected ot be performed by this mapping:
https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L27-L43
when the address is converted here:
  https://github.com/odoo/enterprise/blob/75cba6d5a88ebc4e0f35040a173ac1c443638daf/delivery_envia/models/envia_request.py#L535-L542
That being said, the `Chile`'s code states of have been changed in 6694a3942c58ff1a56c9e4b36edbe126dd1e66f8 to match the official Iso but not in the Envia's mapping leading a failling match keeping the 4 charracter long `CL-RM` of the `Metropolitan` state provided in to the Envia's api as address data.

opw-6083181
opw-6210007

The delivery transfer for a product tracked by serial number is not linked to the POS order when there is no available stock. When validating a POS delivery in real time, stock can split the transfer into a completed picking and a backorder (e.g. one line fully delivered with lots, another serial-tracked line with no stock and no serial number).

Steps to reproduce:
-------------------
* Setup two products: one tracked by qunatity with some quantity on-hand an other tracked by SN but no quantity on-hand
* Open Pos
* Sell in one order, both products without providing SN
* Validate payment
* Open Inventory: two deliveries sould exist under Inventory Overview of PoS Orders

> Observation:
The first picking shows the POS order as Source Document but the backorder has no source document and is not linked to the POS order.

Why the fix:
------------
Pos Origin (Source Document, POS order, session) was only written on the pickings returned by `_create_picking_from_pos_order_lines`, which did not include pickings created during `_action_done()`. Extend the write to the initial pickings and their backorders so every transfer stays tied to the originating `pos.order`.

opw-6090606