There is an issue with the POS since 19.3, when a tour is running, the tour service would get the tour name from the backend with 0 steps, and because the JS bundle of the tours is not loaded by the POS frontend the tour would continue with 0 steps.

Most of the time the currentActionIndex would be > 0, so the check on line 87 of `tour_interactive.js` would pass
```
if (this.currentActionIndex === this.actions.length)
```
and later run into a
```
TypeError: Cannot read properties of undefined (reading 'step')
      at TourInteractive.play (http://localhost:8069/web/assets/debug/point_of_sale.assets_prod.js:121705:33) (/web_tour/static/src/js/tour_interactive/tour_interactive.js:95)
      at TourInteractive.start (http://localhost:8069/web/assets/debug/point_of_sale.assets_prod.js:121655:14) (/web_tour/static/src/js/tour_interactive/tour_interactive.js:45)
      at TourService.resumeTour (http://localhost:8069/web/assets/debug/point_of_sale.assets_prod.js:123226:39) (/web_tour/static/src/js/tour_service.js:260)
```

I'm not sure what's the correct fix,
- either what I did here
- change the condition on the `play()` to `this.currentActionIndex >= this.actions.length` instead of `this.currentActionIndex === this.actions.length`
- bundle the tours inside the POS front end (although they are not used there so it seems unnecessary)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

When editing an already-edited message, the `(edited)` span was included in the editor's editable content because `prepareBodyForEditing` (formerly `getNonEditableMentions`) passed the raw body directly to the composer.

This caused two issues:
- CTRL+A would select the `(edited)` label, allowing it to be styled, repositioned, or accidentally deleted.
- CTRL+A + Backspace + retype left the body empty after saving, because the self-closing `<span class="o-mail-Message-edited"/>` in the stored HTML was parsed by browsers as an open tag (spans are not void elements), swallowing subsequent content as its children.

Fix: strip `.o-mail-Message-edited` from the body before loading it into the editor. The server always re-appends a fresh `(edited)` span at the end when saving, so removing it from the editor content is safe and correct.

Also align the mock server with the real server behavior:
- Place the span *inside* the last `div`/`p` element instead of after it.

Rename `getNonEditableMentions` → `prepareBodyForEditing` to reflect that the function now covers both making mentions non-editable and stripping the edited label.

task-6172161



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

Forward-Port-Of: odoo/odoo#261772

Steps to reproduce:
Bug 1 (The Crash):
1. Open Documents app, select a PDF, and click Action > Sign.
2. In the Sign app, delete the newly created Sign Template.
3. Return to the Documents app.
4. A traceback occurs (`KeyError: <document_id>`) in `web_read`.

Bug 2 (The Broken Lineage):
1. Create two separate Sign Templates from the exact same Document.
2. Send a signature request from the second template.
3. The `reference_doc` on the signature request fails to link back to the original Document.

Current behavior:
When creating a sign template from a document, `documents_sign` intentionally unlinks the original `ir.attachment` (`res_model = False`) to pass custody to `sign.document`. If the template is deleted, the attachment is orphaned, permanently corrupting the original `documents.document` and crashing the UI. 
Furthermore, the lineage tracking (`reference_doc`) relies strictly on a 1:1 shared `attachment_id`. If a user creates multiple templates from one document, the system is forced to make a copy for the second template, natively breaking the lineage tracking because the IDs no longer match.

Expected behavior:
Documents should not be corrupted when generating or deleting sign templates. Furthermore, lineage tracking (`reference_doc`) should successfully link back to the original document regardless of how many templates have been generated from it.

Fix:
1. Replaced the `res_model = False` custody-handoff hack in `documents_sign` with a safe `.copy({'original_id': attachment.id})`. This sandboxes the Sign app's files, completely preventing the deletion crash and the multi-template conflicts.
2. Updated the `reference_doc` computation in `sign.request` to dynamically search for both the current `attachment_id` AND its `original_id` (utilizing a minimal-diff recordset union `|`). This perfectly preserves the lineage tracking for all templates without requiring database schema changes.

Task: 5432116

Forward-Port-Of: odoo/enterprise#114221
Forward-Port-Of: odoo/enterprise#113167

When writing on reconcile models, the ORM fetches all the unreconciled bank.statement.lines then calls filtered on
`unreconciled_statement_lines.line_ids`. In databases with a lot of unreconciled statement lines scattered across multiple models, this `filtered` can be heavy, both in memory (fetching all the amls fields) and in time.

This commit fixes this by using a search to prefilter the amls using the reconcile models in self. Then we filter the result on `suspense_account_id`. This greatly reduces the number of lines loaded up in memory and speeds up writing on reconcile models.

### speedup

In a customer database with 484 042 statement.lines, 141 000 unreconciled statement.lines, 37 account.reconcile.model. Time to write on a reconcile_model.

| Nbr linked unreconciled lines| Before PR | After PR | 
|:----------------------------:|:---------:|:--------:|
|              702             |    40s    |   3s     |
|              2000            |    40s    |   4.47s  |
|              10000           |    40s    |   11.28s |

Since most of the slowness comes from the `filtered` call, the number of unreconciled statement lines linked to the reconcile.model being updated has no impact on the timing before this patch.

### memory

For the 702 unreconciled lines case, the memory consumption goes
 - 2.2 Gb -> 200Mb.

Forward-Port-Of: odoo/enterprise#115583

This commit refactors the import code of BIS3 Invoice to fix various issues about unsynchronized values between the imported invoice and the source XML file.

The new way we import BIS3 invoice can be categorized as:

- collecting all the values from the XML to a dictionary object
- prepare the values and amounts to write to the invoice in its entirety using the tax computation engine helpers
- write the whole processed values to the invoice (as a single write)
- (in 18.0 ~ 18.2) recalculate discrepancies and update the invoice lines (if needed) with the corrected amounts

This commit also includes a new test suite for BIS3 import, and a new approach of import testing, "Partial Imports", is introduced to better atomize the big import test files (and make it understandable). In the long term, `l10n_account_edi_ubl_cii_tests` will eventually be removed in favor of these small-but-many partial tests.

task-id: 5058687

Co-authored-by: Yosua Nicolaus <yoni@odoo.com>

Forward-Port-Of: odoo/odoo#261052
Forward-Port-Of: odoo/odoo#250160

Applying a global order discount and then paying with a gift card (or eWallet) caused the POS to recompute the global discount as if the gift card deduction were part of the taxable merchandise base. The negative reward line was included in `isGlobalDiscountApplicable()`, so the percentage discount shrank and the order total increased by “global_discount% × gift card amount” (e.g. 10% of $50 → $5 added back).

Steps to reproduce:
-------------------
* Open PoS with global discount and a gift card / eWallet program.
* Add a product (e.g. $100), apply a global discount (e.g. 10%).
* Apply a gift card for part of the balance (e.g. $50).

> Observation:
Total is wrong (e.g. $45 instead of $40): the gift card amount is reduced, then a fraction of that amount is added back via the recomputed global discount line.

Why the fix:
------------

`pos_discount` only skips tip and discount-product lines; gift card reward lines use another product and were still “discountable”. The fix belongs in `pos_loyalty`: override `isGlobalDiscountApplicable()` to return false only for gift card and eWallet reward lines (`isGiftCardOrEWalletReward()`), and fall to `super` otherwise so promotion/loyalty reward behavior stay correct.

opw-6104090

Forward-Port-Of: odoo/odoo#259577