Handle `carryover_origin_report_line_id` for report line having `code = 'VP14b`, since the line does not exist in the new monthly VAT report after this commit: odoo/odoo@51a72ab42d118d6fb0eb3e3545a09e10019b9140

As the line is not present in the monthy vat report while mapping it will raise keyerror:

```py
File "/home/odoo/src/odoo/19.0/addons/l10n_it/migrations/0.7/post-map_carryover_to_new_report.py", line 52, in migrate
    data_to_insert = [
  File "/home/odoo/src/odoo/19.0/addons/l10n_it/migrations/0.7/post-map_carryover_to_new_report.py", line 53, in <listcomp>
    (code2expression_id[report_line_code], old2new_origin[carryover_origin_report_line_id], *other_external_vals)
KeyError: 80
```

```sql
apan_3806634=> select id,carryover_origin_report_line_id,target_report_expression_id from account_report_external_value;
 id | carryover_origin_report_line_id | target_report_expression_id
----+---------------------------------+-----------------------------
  3 |                              80 |                         102
  4 |                              80 |                         105
  7 |                              80 |                         102
  8 |                              80 |                         102
  9 |                              80 |                         102
 10 |                              80 |                         102
 11 |                              80 |                         102
(7 rows)

apan_3806634=> select id,name->>'en_US',code from account_report_line where id=80;
 id |           ?column?           | code
----+------------------------------+-------
 80 | VP14b - VAT payable (credit) | VP14b
(1 row)
```

Note this error will only appears in the dbs without this commit: odoo/odoo@a220a28595dbfacce2d8322222d1961547bb4b07

opw-5494959
upg-3806634
tbg-2272


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

It is possible to run a cron via the "Run Manually" button of the ir.cron form view. In 18.4 and before, in case the cron failed due to an exception, that exception would appear in the web client. Since 19.0 and commit 78c00d2, the exception no longer bubbles-up to the web client. It is only logged in the server logs.

Many system admins and also the Odoo support use on the "Run Manually" to quickly test a cron and make sure it works. The change done in 19.0 is considered as a nasty surprise. They want their exceptions back!

When running a cron manually, we now track the logs that are emitted on the cron logger and search for an error with an exception. May we find one, we raise it with a proper traceback chain, which bubbles up to the web client and is shown in the "An error occured" modal.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/bd44f59a66 [REL] 19.0.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/7b6469f3de [PERF] evaluation: fast predicate path for empty strings [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/49a8ade732 [FIX] range: add result changeType [Task: 5095364](https://www.odoo.com/odoo/2328/tasks/5095364)
https://github.com/odoo/o-spreadsheet/commit/c1d5ddafc9 [FIX] range: adapt string XC on sheet rename [Task: 5095364](https://www.odoo.com/odoo/2328/tasks/5095364)
https://github.com/odoo/o-spreadsheet/commit/b148744709 [FIX] range: rename parameter [Task: 5095364](https://www.odoo.com/odoo/2328/tasks/5095364)
https://github.com/odoo/o-spreadsheet/commit/dcd419a83e [FIX] range: add range to NONE [Task: 5095364](https://www.odoo.com/odoo/2328/tasks/5095364)
https://github.com/odoo/o-spreadsheet/commit/a2e329cfb3 [FIX] Actions: ensure the sequence is applied on action children [Task: 5452669](https://www.odoo.com/odoo/2328/tasks/5452669)
https://github.com/odoo/o-spreadsheet/commit/edc5f21755 [FIX] composer: prevent autocomplete from closing on grid icon drag [Task: 5392156](https://www.odoo.com/odoo/2328/tasks/5392156)
https://github.com/odoo/o-spreadsheet/commit/8446e90c25 [PERF] evaluation: don't spread single element matrix [Task: 5491138](https://www.odoo.com/odoo/2328/tasks/5491138)
https://github.com/odoo/o-spreadsheet/commit/63c002a1ee [FIX] evaluation: remove spread relation [Task: 5491138](https://www.odoo.com/odoo/2328/tasks/5491138)
https://github.com/odoo/o-spreadsheet/commit/1642f79973 [FIX] vectorization: fix error message on size mismatch [Task: 5331324](https://www.odoo.com/odoo/2328/tasks/5331324)
https://github.com/odoo/o-spreadsheet/commit/c7c2baabfb [FIX] chart: ignore NoChanges in gauge/scorecard side panel errors [Task: 5478288](https://www.odoo.com/odoo/2328/tasks/5478288)
https://github.com/odoo/o-spreadsheet/commit/4589afc1fd [IMP] xlsx: export clip [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130)
https://github.com/odoo/o-spreadsheet/commit/9f4416e6f1 [IMP] export: export align left when the cell content is a number; [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130)
https://github.com/odoo/o-spreadsheet/commit/c8c01a1fe1 [FIX] header_size: wrong row size from wrapped number [Task: 4878338](https://www.odoo.com/odoo/2328/tasks/4878338)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export

Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that, and always reported all bills in the period. Solving this requires using an SQL query so that cash basis can be properly computed, like in the report. This also makes the export much more efficient, and resilient to bigger amount of data.

Steps to reproduce:
- Install `l10n_ma_reports` and switch to the MA company
- Create and confirm a bill:
	Bill Date: 10/01/2025
	Vendor: Azure Interior
	Invoice Lines: Price 100, Taxes 20% (S 140)
- Go to `Bank Reconciliation`
- Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo)
- Select the transaction and the invoice, then click Validate
- Open the Tax Return for November.
	Section D should show data linked to the created invoice
- Export the XML using the Gear → XML
	The created bill is missing in the XML and others may be present, showing inconsistent data

opw-5002779


[IMP] l10n_ma_reports: call the report to compute the prorata value

Searching explicitly for external values is a bad practice ; calling the report ensures consistency between the data displayed, and the one exported into the file.

Forward-Port-Of: odoo/enterprise#104667
Forward-Port-Of: odoo/enterprise#104619

When a preparation printer is configured to print only specific product categories (e.g., drinks only), adding items from other categories (e.g., food) would cause the printer to reprint the previous order with a "NEW (DUPLICATE!)" label.

Steps to reproduce:
-------------------
* Configure a restaurant/bar POS with a preparation printer set to print only drinks
* On a table, order a drink item → printer correctly prints "NEW" ticket with the drink
* On the same table, add a food item (not in printer categories)
* Trigger sending to preparation (e.g., validate order or send to kitchen)

> Observation: The printer prints a duplicate of the previous drink order showing "NEW (DUPLICATE!)" instead of staying silent.

Why the fix:
------------
The `sendOrderInPreparation` method was automatically reusing `order.uiState.lastPrint` when no preparation category changes were detected, causing an implicit reprint. This behavior is incorrect when the order only contains items outside preparation printer categories - the printer should simply not print anything.

The fix:
- Prevents automatic reprint when there are no prep category changes
- Still calls `updateLastOrderChange()` to mark the order as "sent" and prevent the restaurant popup warning about unsent orders
- Only allows explicit reprints via `opts.explicitReprint` flag for future use cases

Forward-Port-Of: odoo/odoo#239003

When printing many receipts quickly using a USB printer, this error was occasinally occuring:

```
WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS status
ERROR   ? root: Could not set configuration: [Errno 16] Resource busy
```

This would cause `python-escpos` to be disabled and fallback to just CUPS printing.

The issue was caused by two threads trying to access the printer at the same time, which could happen in two ways:
- IoT thread with `python-escpos` and CUPS try to access the printer at the same time.
- Two IoT threads with `python-escpos` try to access the printer at the same time (this can happen if two receipt actions are received at the same time).

Both of these scenarios should now prevented:
- Now, if we are using `python-escpos`, we also use it to print the receipt as well as checking the status. CUPS is never used so there should be no interference from it.
- We now have an `escpos_lock` (per printer, not global) that is acquired when accessing the printer via `python-escpos`. This ensures that different threads cannot both try to access the printer at the same time.

task-5490942

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

Forward-Port-Of: odoo/odoo#244031

**Steps to reproduce:**
* Install the **l10n_ch** module for a Swiss company.
* Create a vendor bill for a **foreign vendor**.
* Apply a reverse charge tax:
  * **8.1% R C** (figure **383a**), or
  * **7.7% R C** (figure **382a**).
* Confirm the vendor bill.
* Go to **Accounting → Reporting → Tax Report**.
* Generate the VAT report for the relevant period.

**Observed behavior:**
* Figure **383a** (8.1% reverse charge) is reported as **negative**.
* Figure **382a** (7.7% reverse charge) is reported as **negative**.
* This results in incorrect VAT reporting.

**Cause:**
* Reverse charge taxes use **negative tax rates** to model the reverse mechanism.
* The base amounts were tagged with **positive** signs, leading to negative values in the report.

**Fix:**
* Invert the base formula signs for 383a and 382a:
  * **382a**: change base formula from `-382a` to `382a`.
  * **383a**: change base formula from `-383a` to `383a`.
* Reverse charge base amounts now appear as **positive** values in the VAT report.

opw-5257445

Forward-Port-Of: odoo/odoo#244707
Forward-Port-Of: odoo/odoo#244452

Issue Before This Commit:
================================
Previously, the delivery carrier was only propagated between pickings when it
was set from the sale order. If the carrier was manually set on a picking
(e.g., during the packing step in a multi-step delivery flow), it was not
propagated to the consequent pickings, even when the stock rules had
`Propagation of carrier` enabled.

Steps to reproduce:
================================
1. Activate Multi-Step Routes and Delivery Methods.
2. Configure a 3-step delivery route in the warehouse and enable Propagate
   Carrier on all rules.
3. Create a sale order with a product but without setting a delivery carrier.
4. Confirm the sale order to generate picking.
5. On the first picking (i.e., pick), manually set a delivery carrier
   (e.g., Local Delivery) and validate.
6. On the next transfer (i.e., pack), observe that the delivery carrier is not
   propagated.

After this commit:
================================
The delivery carrier set on any picking is propagated to subsequent transfers
when the corresponding stock rule has `Propagation of carrier` enabled and no
carrier is already configured on the next picking.

This ensures consistent carrier propagation across all routing configurations
(all pull rules, all push rules, and mixed push/pull flows), even when the
carrier is configured at the picking level rather than on the sale order.
This behavior is required because, in many business scenarios, carrier selection
is managed by the logistics team rather than the sales team.

task-4454313

Forward-Port-Of: odoo/odoo#242334
Forward-Port-Of: odoo/odoo#202700

Summary:
Refactor `preserveSelection()` to use a stack-based approach (`preservedCursors` array) instead of a single cursor reference. This allows nested calls to `preserveSelection()` to operate independently while keeping cursor updates synchronized across active contexts.

Problem:
Using a single stored cursor caused issues in nested calls to `preserveSelection()`:

1. **State overwrite:** Inner calls could overwrite or clear the outer cursor.
2. **Stale references:** If an inner function replaced a DOM node, the outer cursor could still point to a removed node and fail on restore.

Solution:
Use an array of cursor subscribers

- **Shared updates:** When calling `remapNode` on a cursor, it iterates over all active subscribers in the stack. This ensures node replacements performed in inner contexts also update outer cursor references.
- **Scoped cleanup:** `restore()` now removes only the corresponding cursor instance from the stack, ensuring proper lifecycle management.

Example:
The key improvement is that outer scopes receive updates performed by inner scopes.

```javascript
// Function A (outer)
function wrapperFunction() {
    const cursor = this.preserveSelection();
    replaceTextWithSpan();
    cursor.restore();
}

// Function B (inner)
function replaceTextWithSpan() {
    const innerCursor = this.preserveSelection();
    const oldNode = document.querySelector('text');
    const newNode = document.createElement('span');
    oldNode.replaceWith(newNode);
    innerCursor.remapNode(oldNode, newNode);
    innerCursor.restore();
}
```
opw-5386862

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

Forward-Port-Of: odoo/odoo#243876
Forward-Port-Of: odoo/odoo#238989