## Dependent PR
https://github.com/odoo/enterprise/pull/98463

## Description of the issue/feature this PR addresses:
Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled.

## Current behavior before PR:
When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA.

However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because:

- Settlement orders do not contain any lines, so a new invoice cannot be generated.
- The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice.

Thus, the user cannot proceed with the settlement.

## Desired behavior after PR is merged:
After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment.

task-5144679

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

Forward-Port-Of: odoo/odoo#243786
Forward-Port-Of: odoo/odoo#233769

## Description of the issue/feature this PR addresses:
The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation.

## Current behavior before PR:
When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True.

This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this.

## Desired behavior after PR is merged:
After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. 

task-id - 5144679

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

Forward-Port-Of: odoo/enterprise#104291
Forward-Port-Of: odoo/enterprise#98463

Versions
--------
- saas-18.3+

Steps
-----
1. In Accounting/Invoicing settings, enable "Add QR-code link on PDF";
2. create an automation rule for the `account.move` model;
3. set "Trigger" to "Create & Edit";
4. set "Apply on" domain to `[("state", "=", "posted")]`;
5. set "When updating" to "Status";
6. add an action to execute the following code:
    ```python
    env['account.move.send']._generate_and_send_invoices(records)
    ```
7. call `action_post` on an invoice via RPC or Odoo Shell.

Issue
-----
> odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
> RuntimeError: object is not bound

Cause
-----
In order to add a payment link QR code to the invoice[^1], it needs to generate an access token for the portal. This happens via the `generate_access_token` function from `odoo.addons.payment.utils`. Issue is that it relies on having access to a `odoo.http.request` object, so that it can use its `env` to retrieve the `database.secret` config parameter.

When this flow gets triggered via an API call (or Odoo Shell), the `request` object is unbound, causing the error.

[^1]: feature added via commit bcb73cd159885

Solution
--------
Introduce an optional `env` kwarg to `generate_access_token`, falling back on `request.env` if it's not provided.

opw-5487075

Forward-Port-Of: odoo/odoo#243528

**Steps to reproduce:**
* Install `Accounting` and `sales` modules.
* Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both companies.
* Create a **payment term** assigned to **Company A**.
* Create a **sale order** from Company A to Company B using that payment term.
* Confirm the sale order and create the **invoice**.
* Post the invoice to trigger the inter-company vendor bill.

**Observed behavior:**
* The generated **vendor bill** for Company B uses **Company A’s payment term**.
* Posting fails because the payment term is incompatible with Company B.

**Cause:**
* Inter-company document creation reuses payment terms without checking whether they belong to the **target company**.
* Payment terms from the source company can be propagated to the destination document.

**Fix:**
* Ensure only **company-compatible** payment terms are applied when creating inter-company sale orders, purchase orders, and invoices.
* Payment terms belonging to a different company are now ignored.

**NOTE**: test is not implemented due to technical limitations. Inter-company invoice synchronization relies on UI context propagation that cannot be replicated in unit tests. The payment term validation logic depends on web client context flags that are only set during real UI interactions, not programmatic execution.

opw-5392745

Forward-Port-Of: odoo/enterprise#102986

**Steps to reproduce:**
- Create a portal user
- Go to the documents app
- Click on the marketing folder
- Share the marketing folder through a link (Anyone with a link = viewer + discoverable)
- Copy the share link
- Login with the portal user in an incognito window
- Paste the share link in an incognito browser
- Click on "brand 1" folder, result nothing is showing while there should be a folder and a picture
- Click on "brand 2"
- Click back on "brand 1" and now the folder and picture are visible
- If you click on a subfolder of "brand 1" you also get an error

**Issue:**
Discoverable subfolders accessed using `accessToken` are not available on
the first read of a user and this happens for each level of the
hierarchy (refresh is needed each time).

When using sharing link to display folders with a user,
the subfolder document access is created on `/documents/touch/` using
`_from_access_token`.

But on the js side the call is delayed (with debounce) and occurs after
the `web_search_read`. This means that subfolders are only accessible
after a refresh or by switching back and forth between folders.
Also, even after the folder is displayed, if there are other subfolders
in it, going deeper in the hierarchy won't work as well without a refresh
due to the `search_panel_select_range` missing the new folder.

**Fix:**
Not sure on the best way to fix this, the issue will always be related to
performance. Current fix checks if a reload is needed by sending a flag in the
`/documents/touch/<access_token>` request result when a new document
access was created.

opw-5156297

Forward-Port-Of: odoo/enterprise#104585
Forward-Port-Of: odoo/enterprise#99820

**Problem:**
When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is especially a problem when unreserved products are added to a transfer, since each additional validate call will duplicate those products (and their lot/SNs).

**Steps to Reproduce:**
- In the Barcode app, create a new internal transfer
- Scan a product, then scan the destination location 'WH/Stock/Shelf 1' ('2601892' is the barcode)
- Click the "Validate" button (or scan 'O-BTN.validate') multiple times as quickly as possible
- See that the "The transfer has been validated" toast appears (and possibly warnings about validating a done transfer) -> On the transfer, see that there are duplicated stock.move and stock.move.line

**Fix:**
Prevents the 'validate' method from executing as usual by checking if a previous call is still executing (tracked by 'isValidate').

opw-4948696

Forward-Port-Of: odoo/enterprise#102465
Forward-Port-Of: odoo/enterprise#95329

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

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#240794
Forward-Port-Of: odoo/odoo#238989

On the iot box we check the number of printers connected rarely to avoid spamming the network.
This leads to some situations where if a printer is disconnected it becomes unusable for the next 2 minutes or even more if it disconnects again just before the next get_devices call in the interface.
The printers are often not listed by cups for short time which currently leads to them being deleted from our list of connected devices on the iot box.

However in reality the printer reconnects faster than 2 minutes and often becomes available again within a couple of seconds.
Currently if you print something on it you will get an error when checking the job status but the job will still be queud and printed whenever it reconnects.
The user in pos can then press "retry" which will lead to a double printing.


This PR adds a counter for the printer disconnections and only removes the printer from our list if it wasn't detected 3 times in a row by cups.
Now since not deleted from cups the print job is queud and whenever the printer reconnects it's printed.
The user will not get an error anymore which will avoid double printing and the printer will remain available unless it's really disconnected

Forward-Port-Of: odoo/odoo#244076

Problem:
When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines.

Solution:
We will convert the component cost to the invoice currency when computing price difference.

Steps to reproduce (runbot 18):
- Product with
	- Standard price auto
	- BoM: sbc, one component with nonzero value (e.g. $1)
	- Nonzero value (e.g. $5)
- Another currency
1. Create a PO for the subcontracted product
2. Set the Invoice currency to something other than the company default
3. Confirm the PO and validate the sbc and receipt
4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency)

A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference.

opw-5232917

Forward-Port-Of: odoo/odoo#243801
Forward-Port-Of: odoo/odoo#238428