**Steps to Reproduce:**
1. Install the "**Belgium - Accounting**" (`l10n_be`) module with demo data.
2. Switch to the company - **BE Company CoA**.
3. Remove the "**Tax Payable Account**" from all the tax groups.
4. In setting, under _EU Intra-community Distance Selling_ section, click on "**OSS Tax mapping**".

**Error:**
`ValueError - External ID not found in the system: account.1_oss_tax_group_20_0_SK`

**Note:** If only the "**Tax Receivable Account**" is removed from all tax groups. The following error occurs;
`TypeError: expected string or bytes-like object`

**Cause:**
At [1], the system searches for a tax group with a defined `tax_payable_account_id`.
Also, at [2], the `oss_tax_group_local_xml_id` is created only when the tax group (tg) exists. However, when no tax group is found, the code tries to fetch the missing xml id at [3], resulting in a ValueError.
Similarly, when the receivable account is missing, the execution also fails, leading to a TypeError.

**Fix:**
This commit updated the tax group search condition to include both `tax_payable_account_id` and `tax_receivable_account_id`. Also, added skipping further processing if the related tax group is not found.

[1] - https://github.com/odoo/odoo/blob/fb30a9b12667f6b1195e6bd6f8db69f44ad5ca2a/addons/l10n_eu_oss/models/res_company.py#L47-L49
[2] - https://github.com/odoo/odoo/blob/fb30a9b12667f6b1195e6bd6f8db69f44ad5ca2a/addons/l10n_eu_oss/models/res_company.py#L115-L146
[3] - https://github.com/odoo/odoo/blob/fb30a9b12667f6b1195e6bd6f8db69f44ad5ca2a/addons/l10n_eu_oss/models/res_company.py#L164

sentry-6932155430

Before this commit:
-------------------
When a user added an existing signature field to a view, Studio automatically assigned the default binary widget.
The expected signature widget did not appear in the widget selection list. As a result, users could not configure the field as a signature input.
<img width="1920" height="938" alt="image" src="https://github.com/user-attachments/assets/35893235-2541-4bd5-a7a5-4feab562acb2" />

Cause:
-----
Studio builds the dropdown of available widgets by computing a [widgetKey](https://github.com/odoo/enterprise/blob/17.0/web_studio/static/src/client_action/view_editor/editors/utils.js#L132) based on the field type.
Because the signature widget did not declare binary as a supported field type, it was always filtered out for fields of type binary. Thus Studio treated the field like any normal binary field and excluded the signature option.

After this commit:
------------------
The signature widget is correctly exposed as a supported widget for fields of type binary.
When adding an existing signature field to the view (with developer mode enabled), Studio now shows signature in the widget list.
<img width="1917" height="934" alt="image" src="https://github.com/user-attachments/assets/079e0a17-ff5a-4dc6-a12d-e02b9cad013e" />


Why this fix is needed:
----------------------
Signature fields are stored as binary, but they require the dedicated signature widget to render correctly.
By marking binary as a supported field type for the signature widget, Studio can
 properly detect and offer the widget during field configuration.
Given that this widget is very domain-specific and not intended for general binary fields, it was not added to
[web_studio/static/src/client_action/view_editor/editors/sidebar_safe_fields.js](https://github.com/odoo/enterprise/blob/17.0/web_studio/static/src/client_action/view_editor/editors/sidebar_safe_fields.js) though this may be reconsidered
after this fix the option is accessible only when the debugger mode is on, if want to show this widget 
to all the binary type fields even when the debugger mode is off the we'll have to add it to this file.

OPW : 5260188


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

Forward-Port-Of: odoo/odoo#237287

Before this commit:
-------------------------
- On the Purchase Dashboard, the 'Not Acknowledged' and 'Late Receipt' counters
  also included purchase orders whose receipts had already been done.
- For Not Acknowledged:
  - Such POs should be implicitly considered acknowledged once their receipts
    are done, but they were still shown at the counter.
  - Additionally, unacknowledged POs that were locked were incorrectly excluded
    from the counter.
- For Late Receipt:
  - POs with received products were incorrectly counted as late, even
    though their receipts were already done.
  - Locked POs with late receipts were also excluded from the counter, which was
    an incorrect behavior.

Steps to reproduce:
-------------------------
1. Install the 'purchase_stock' module.
2. Open Purchase module.
3. On the Purchase Dashboard, click on the 'Not Acknowledged' or 'Late
   Receipt' card.
4. Notice that POs whose receipts are already completed still appear in the
   counters and some locked POs that are unacknowledged or have late receipts
   are missing from the counters

Cause of the issue
-------------------------
- The domains for both Not Acknowledged and Late Receipt counters only relied on
  the purchase order state without checking whether the receipts were done.
- As a result, POs with done receipts were still included in the counters, while
  some locked POs were incorrectly excluded.

After this commit:
-----------------------
- Updated the search domains for both counters to properly exclude POs whose
  receipts are done.
- The action_done method now triggers action_acknowledged, ensuring that any
  unacknowledged POs with completed receipts are automatically marked as
  acknowledged and excluded from the Not Acknowledged counter. Locked POs that
  remain unacknowledged will still correctly appear in the counter.
- Now the POs with received products are no longer shown as late once their
  receipts are completed and Locked POs with late receipts will now correctly
  continue to appear in the counter.
- This ensures that the dashboard accurately reflects only pending
  acknowledgments and genuinely late receipts, helping users track POs in
  the correct state.

Task ID: 4874116

Forward-Port-Of: odoo/odoo#237305
Forward-Port-Of: odoo/odoo#224180

**Steps to reproduce:**
- Make a quotation in the Sales module
- Go to PoS, click Quotation/Order and select your quotation
- Select Settle the order
- Go through with the payment
- Go back to the Quotation in the Sales module
The Status widget still shows Quotation instead of Sales Order

**Why the fix:**
Since 18.3, the sale_order.state was not updated anymore when the state changed through the PoS.

This happened because we would only change the sale_order state if there was a downpayment involved. In 18.2, we
always recomputed the sale_order that was linked to the order we are currently settling.

The way it is done now is part of the same way it was done in 18.2 and before, meaning we add the linked sale_order
regardless of downpayments.

In 18.2, we did an action_confirm on the selected  sale_orders, but doing that in 18.3 will create another picking for this sale_order. This is not what we want as the picking is now handled and created by the PoS. 

This fix will just put the related sale orders in the "sale" state, so that users can no longer confirm it in the sales modules, which would create a second picking and create duplicates.

opw-5033979

Forward-Port-Of: odoo/odoo#237213
Forward-Port-Of: odoo/odoo#226008

When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the
`viva_wallet_latest_response` field of the payment method. The webhook request would be automatically retried later, but this could result in duplicate notifications being sent to the POS, or notifications being handled too late.

This commit stops using the `viva_wallet_latest_response` field, instead sending the information directly via the websocket to the POS. Only the required information is sent to reduce the size of the message.

In addition, there are two other minor fixes:
- In the event that the initial payment request to Viva failed, the POS will no longer poll the payment status (this resulted in a Session ID not found error).
- The webhook controller will now check the event type it receives, and only process the 'Transaction Payment Created' events. This should prevent any unintended behaviour if other webhooks are set up in Viva.

opw-5226966

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

Forward-Port-Of: odoo/odoo#237411
Forward-Port-Of: odoo/odoo#236454

## **Issue Before This Commit:**
When a work order is assigned to an employee (not linked to the current user),
and the current user marks it as done, the time log is wrongly created
under the current user’s employee instead of the assigned one.
This behavior caused confusion for the user as the
wrong person was shown as working on the order.

## **Steps to Reproduce:**
- Create an MO with work orders and confirm it.
- Assign another employee to a work order.
- Mark the work order as done with the current user from the work order line.
- Open the workorder and notice that the time log is created for the current user’s employee.

## **Cause of the Issue:**
The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790),
where the logic for assigning the main employee was overridden,
ignoring the case of an already assigned employee.

## **With This Commit:**
The time log is now created for the assigned employee,
This resolves the confusion by ensuring
the right person is tracked on the work order.

TaskID: 4983514

Forward-Port-Of: odoo/enterprise#100467
Forward-Port-Of: odoo/enterprise#93378

Currently, an error occurs when a user sets the partner on a statement line.

**Steps to Reproduce**([video](https://drive.google.com/file/d/1ZQBBh4yjSljeqqL_jT8dh_QJ6LtFZdPb/view)):
 - Install the `account_accountant` module.
 - Go to `Invoices` and create `two invoices` with the `same partner` and the `same total amount` by adding 
    an `invoice line`.
 - Go to the `Dashboard` and click `Last Statement` under the `Bank journal`.
 - Create a `new statement line` with the `same amount` as the `invoice amount`.
 - Click `Set Partner` and select the `same partner` used in the invoices.

`TypeError: '<=' not supported between instances of 'bool' and 'datetime.date'`

After [this commit], when a user sets the partner on the statement line, the system attempts to automatically reconcile the line. It then searches for a single invoice matching the statement line amount [1] and tries to select the one with the closest prior or equal date. However, draft invoices have not an invoice_date, and when the system attempts to filter on this field, and the error is raised [2].

This commit ensures that the comparison between invoice date and statement date occurs only when the invoice date is present.

[this commit]: https://github.com/odoo/enterprise/pull/98269

[1]- https://github.com/odoo/enterprise/blob/84ccb807852ab6b118466d12c8f02ea4da7fa3db/account_accountant/models/account_bank_statement.py#L585

[2]- https://github.com/odoo/enterprise/blob/84ccb807852ab6b118466d12c8f02ea4da7fa3db/account_accountant/models/account_bank_statement.py#L249

sentry-7063516380

When a snippet containing a `<form>` (e.g. “Contact us” form) is dropped
inside an existing form element, the inner form is invalid HTML
(see [1]).

Steps to reproduce:
===================
1- Go to a Shop page and open a Product page.
2- Drag and drop a “Contact us” form snippet inside the existing product
form (e.g. in description_ecommerce, which is an HTML field with
`sanitize_form=False`).
3- Save the page, re-enter edit mode.
4- Click on any field of the inserted “Contact us” form.
→ traceback.

Cause:
======
HTML does not support nested `<form>` elements.
As soon as the browser parses the dropped snippet inside an existing
`<form>`, it normalizes the DOM and strips or moves the inner `<form>`
tag, keeping only its contents. The inner form therefore loses its
attributes (action, method, data-model_name, etc.).
When editing a field, `fetchAuthorizedFields` needs the form’s model it
used to rely directly on `formEl.dataset.model_name`, which is missing
in this broken structure, causing a crash.

Solution:
========
Prevent dropping the snippets that contain a form inside another form,
by filtering out the `selectorSiblings/Children` (which are used to make
the dropzones appear) that are in forms, when they are dragged.

This commit also uses the `getModelName(formEl)` helper wherever we need
the form model instead of accessing `dataset.model_name` directly.

[1]: https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/How_to_structure_a_web_form

opw-5256576