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

- for more then one records having same code it's raising an singleton error at fetching the name

- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```

- OPW-5450360

Forward-Port-Of: odoo/enterprise#103460

**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

# Description of the issue/feature this PR addresses

In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders.
In 18.0, settlement and deposit flows were both correctly excluded from mandatory ZATCA invoicing using the is_settling_account flag.

From saas-18.2, the Settle Due flow was refactored to include a dedicated settlement product line. 
As a result, is_settling_account now only covers account deposit flows, and is no longer sufficient to identify Settle Due orders.

# Current behavior before PR

With ZATCA enabled on saas-18.2:

- Account deposit flows are still correctly excluded from mandatory invoicing using is_settling_account.
- Settle Due orders are no longer detected by this flag and are treated as standard sales because they now contain order lines.
- This causes ZATCA invoice enforcement to be applied to Settle Due orders, even though the original invoice was already reported.
- Additionally, mixed orders combining settlement lines and new sale items would require partial ZATCA reporting, which is not supported.

# Desired behavior after PR is merged

After this fix:

- ZATCA invoice enforcement is skipped for account deposit flows using the existing is_settling_account flag.
- Even if invoice is checked, the invoice is not sent to ZATCA
- Settle Due orders are correctly identified using the isSettleDueLine() check on order lines and excluded from mandatory ZATCA invoicing.
- Mixed settlement and sale orders are explicitly blocked for ZATCA to avoid inconsistent or partial reporting.

This restores the intended settlement behavior from 18.0 while adapting it to the refactored Settle Due flow in saas-18.2.

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

**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 tax tag signs for reverse charge taxes:
  * **382a**: change base tag from `-382a` to `+382a`.
  * **383a**: change base tag from `-383a` to `+383a`.
* Reverse charge base amounts now appear as **positive** values in the VAT report.

opw-5257445

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

### Steps to reproduce:

- In the settings enable: Multi-Steps route
- Create a product tracked by SN
- In the barcode app > Operations > Internal transfers > New
- Scan you tracked product
- Click on Validate > Invalid operation
- Scan a Serial number
#### > You can not click on validate anymore

### Cause of the issue:

The issue has been introduced in 41c6e7a90fd4f0cf84e74cf0ed036f4da0ec6112 in a try to avoid concurrency issue when calling the barcode validation too quickly. To be more precise, this commit added a `isValidating` property to the barcode model that is set prior to the rpc call and suppose to remove after in order tobypass subsequence calls of the `validate` method when a call is already in progress: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L477-L494 However, in the present case and since  orm call returns an error the the call the validate method is interupted at this orm call and the line
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L494 is not executed so that the this.Validating stays true and the button can not be clicked nor executed anymore:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L131-L133

### Fix:

We revert the incorrect fix: 42d77e751cb5e049ea1e81b44fca0d07e8f45b32 and we rather rely on the Mutex class of the JS framework just as done in the `_processBarcode`:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L505-L507 This will ensure that the validation calls will be processed sequentially and since the `button_validate` of stock pickings is ignored on done pickings because of the first soft fix https://github.com/odoo/odoo/pull/204790 :
https://github.com/odoo/odoo/blob/1664daf894ec878b64af8ab75c0d10f05e00df80/addons/stock/models/stock_picking.py#L1134-L1135
we have the guarantee that the records will not be validated twice.

opw-5388297

Forward-Port-Of: odoo/enterprise#103999
Forward-Port-Of: odoo/enterprise#103835

Steps to reproduce:
===================
1. Enable the Cookies Bar in website settings.
2. Go to the website and enter Edit mode.
3. Select the Cookie Bar and change the button "I agree" style shape to "Default"  (this applies the `.btn-primary` class). & Save
4. Accept the cookies & refresh

-> The cookie bar appears again because the consent was not saved.

Cause:
======
The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup.

By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written.

Solution:
=========
Override the event to avoid side effects on hide.

opw-5484578

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

Steps to reproduce:
- Activate the GS1 nomenclature
- Create a product with barcode: 15099590483921
- Scan the product from the Barcode app main menu

Problem:
A ValidationError is raised:
"A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date."

Explanation:
GS1 barcodes must follow a strict nomenclature based on well-defined
rules.
For example, a GS1 product barcode should start with the Application
Identifier 01 followed by 14 digits.

The GS1 parser processes the barcode rule by rule and applies the first
matching rule. In this case, the barcode 15099590483921 is interpreted
as a date because it starts with "15", which corresponds to a GS1
Application Identifier for a date. As a result, the parser attempts to
convert the first six digits into a date and raises a ValidationError.

Solution:
Catch the ValidationError raised during GS1 date parsing in main_menu
and explicitly reset parsed_results to False, allowing the normal main
menu resolution logic to continue. This prevents GS1 parsing errors
from blocking valid barcodes and ensures that product, picking, or
location detection still works as expected.

opw-5357611

Forward-Port-Of: odoo/enterprise#104641