Steps to reproduce:
- Install Contacts, Accounting and l10n_mx_edi_extended
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Go to company form and configure its address (*)
- Create a US customer (e.g. Foreign Customer) (*)
- In Accounting settings:
  * activate "Customer Addresses"
  * use Mexican Bank for automatic currency rates (*)
- Configure a product for external trade (e.g. Office Chair) (*)
- Create an invoice: (*)
  * Customer: Foreign Customer
  * Delivery Address: [different than customer] (e.g. Deco Addict)
  * Journal in: USD
  * Usage: Without fiscal effects
  * Product: Office Chair
  * Incoterm: EX WORKS
  * External Trade: Definitive
- Confirm the invoice
- Try to generate CFDI via "Send & Print" button (it will probably fail)

(*) https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade

Issue:
Check the generated CFDI in CFDI tab.
The data for element `<cce20:Destinatario><cce20:Domicilio /></cce20:Destinatario>` are incorrect.
"Calle", "NumeroExterior", "NumeroInterior", "Pais" and "CodigoPostal" are coming from the current company instead of the delivery address.

opw-3715960

Forward-Port-Of: odoo/enterprise#61088
Forward-Port-Of: odoo/enterprise#60829

# Introduction:

`JSON.stringify` was used to serialize the properties for the `/article`
command instead of the classical `encodeDataBehaviorProps` which also uses
`encodeURIComponent` above the `JSON.stringify`, to avoid having some special
characters as an attribute value.

# The issue:

`html_field.js:getEditingValue` is recovering the current value in the DOM using
`innerHTML` which converts some characters from tag attributes to HTML entities,
i.e.: `"` for `"`.

`mail.py:html_normalize` is using `lxml.html.tostring` is receiving such a
string with HTML entities, and is returning a string without HTML entities.

The database value (without HTML entities) is later given to the `html_field` as
a prop and is used as a comparison reference (`updateValue`) with the current
value in edition (that is still being converted to have HTML entities). Since
both values are different, the field is considered as dirty and in need of being
saved, which will trigger a write, even though the normalized value is the
same.

# Fix:

Using `encodeDataBehaviorProps` to serialize props as the Behavior anchor
attribute (like for any other Behavior) will prevent the use of characters that
are being converted to HTML entities.

In order to update existing `/article` blocks, the behavior will overwrite its
`data-behavior-props` attribute when it is mounted in edit mode.

task-3853291

Forward-Port-Of: odoo/enterprise#60985
Forward-Port-Of: odoo/enterprise#60177

# FIX] knowledge: remove useless popover

This commit fixes an issue where the popover would open inside the comments
panel when replying to a comment with a small enough window, even though in
this situation it's not useful at all.

Now when the panel is open and we have a small window, the popover will not
open when replying to a comment.

# [FIX] knowledge: show panel's comments in small windows

This commit fixes an issue with the comments panel when using it with a small
window.

Before, when you opened the panel when in a small enough window, the comments
aren't properly displayed meaning that you only have empty boxes inside the
panel. This was caused by a styling issue inside of the template that applied
a wrong style to the comment boxes inside panel, which is not necessary inside
it.

Now, we modified the inline style in the template so that it is not applied
inside the panel, showing back those comments in all circumstances.

task-3786282

Forward-Port-Of: odoo/enterprise#58045

Previously, it was easy to bypass the maximum_amount field on payment.provider by going to a subscription and clicking "Set Payment Method". The subscription would then be charged with the token, regardless of the maximum_amount set on the payment.provider.

This filters out ineligible acquirers through
_get_compatible_providers() so it's not possible to use them for new payment methods. The existing override wasn't working because sale_order_id was a string and sale.order('1').exists() always returns False. Casting sale_order_id to a string was added in a small /my/payment_method route override.

Filtering out already existing payment methods is harder because the sale order isn't available in _get_available_tokens(). Instead we raise a UserError when a user assigns an ineligible payment method. This is handled well in the frontend.

This focuses only on customer-facing flows. The maximum_amount field isn't checked either on e.g. account.payment but that's only accessible to internal users. Other customer-facing flows aren't affected because typically _get_available_tokens() is called with eligible payment providers as its first parameter.

Attempted alternative approaches:
- odoo/odoo#161021, odoo/enterprise#60294
- odoo/enterprise#60382

opw-3858340

Forward-Port-Of: odoo/enterprise#60482

Currently, receipts are not accounted for in the model 347 report (issue 1). The same happens for invoices for which a payment has been registered (issue 2).

### Setup

* install `l10n_es_reports`
* switch to a Spanish company

### Steps to reproduce issue 1

* with a new partner, create and confirm a customer receipt for more than €3005.06 (threshold for appearing in the report)
* open the model 347 tax report

We would expect the new partner to be listed in the report, but they aren't.

### Steps to reproduce issue 2

* with a new partner, create and confirm an invoice for more than €3005.06
* if you open the model 347 report, you will see the new partner listed there
* go back to that invoice and register a payment for it.
* open the model 347 report again

We expect the new partner to still be listed, but they are not.

### Cause

issue 1: receipts are missing in the corresponding domains.
issue 2: all account moves are used to calculate the threshold. This means that, for example, invoices and payments can cancel each other out in the calculation.

opw-3816370

Forward-Port-Of: odoo/enterprise#60432
Forward-Port-Of: odoo/enterprise#59343

Version:
-----------
saas-16.3

Steps to produce:
-------------------------
1. Open Sales or any other app.
2. Schedule an activity for Request Signature
3. Once the activity is scheduled, click on the Request Signature field
4. In the New signature Request pop-up click on cancel button ->Traceback occurs

Issue:
--------
A traceback occurs when we click on Request Signature after creating any Request Signature activity and click on cancel button.

Cause:
---------
The error occurs because when the cancel button is clicked, the onUpdate component is triggered to load and update the ID. However, a special parameter is passed incorrectly, leading to an error.

Fix:
-----
The issue can be resolved by changing the props from onUpdate to reloadParentView, the component correctly reload the parent view upon cancelation, This prevents the traceback error by ensuring that the activity is updated appropriately.

task-3768008

Forward-Port-Of: odoo/enterprise#60243
Forward-Port-Of: odoo/enterprise#58729

Currently, when trying to settle due accounts though the PoS session, the due balance doesn't change on the customer form.

Steps to reproduce:
-------------------
* Install **Point of Sale** and **Accounting**
* Go to the **Point of Sale** App
* Open a shop session
* Navigate to a customer with a due ammount and select **Details**
* Select **Settle due accounts**
* Select any payment method
* Validate
* Close session
* Under **Orders** select **Customers**
* Select the customer for which you just settled the due accounts
> Observation:  The due amount hasn't changed.

Why the fix:
------------
The following commit introduced a new relational system to be able to access data within the PoS frontend in the same way as it is done within the ORM in python: https://github.com/odoo/enterprise/commit/bb06fdead097bdec1582e3cdecb99fa63c2ff799

This commit modified the definition of `paylaterPaymentMethod`. Before the commit, it was defined as: https://github.com/odoo/enterprise/blob/4a5bb11bd59dd76f2df957225bf25d38ad5beb0c/pos_settle_due/static/src/overrides/components/payment_screen/payment_screen.js#L23-L26 and would return `{id: 3, name: 'Customer Account', is_cash_count: false, use_payment_terminal: false, split_transactions: true, …}`

Now it is defined as
https://github.com/odoo/enterprise/blob/daf09109a209f87e4f2fbb3275f55095e48d8b4d/pos_settle_due/static/src/overrides/components/payment_screen/payment_screen.js#L23-L26 and returns `undefined`.

We also notice a change in the value of `this.pos.config.payment_method_ids`. Where it previously returned
```js
Proxy(Array) {0: 1, 1: 2, 2: 3}
  [[Handler]]: Object
  [[Target]]: Array(3)
    0: 1
    1: 2
    2: 3
    length: 3
  [[Prototype]]: Array(0)
  [[IsRevoked]]: false
```

It now returns
```js
Proxy(Array) {0: Base, 1: Base, 2: Base}
  [[Handler]]: Object
  [[Target]]: Array(3)
    0:  Base {models: {…}, records: Proxy(Object), model: {…}, _raw: {…}, id: 1, …}
    1: Base {models: {…}, records: Proxy(Object), model: {…}, _raw: {…}, id: 2, …}
    2: Base {models: {…}, records: Proxy(Object), model: {…}, _raw: {…}, id: 3, …}
    length: 3
  [[Prototype]]: Array(0)
  [[IsRevoked]]: false
```

Thus we need to use `.some()` to retreive the id.

opw-3802560

Forward-Port-Of: odoo/enterprise#60655
Forward-Port-Of: odoo/enterprise#59626

**Steps to reproduce:**
- Install Contacts, Accounting and l10n_mx_edi_extended
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Go to company form and configure its address (*)
- Create a US customer (e.g. Foreign Customer) (*)
- In Accounting settings:
  * activate "Customer Addresses"
  * use Mexican Bank for automatic currency rates (*)
- Configure a product for external trade (e.g. Office Chair) (*)
- Create an invoice: (*)
  * Customer: Foreign Customer
  * Delivery Address: [different than customer] (e.g. Deco Addict)
  * Product: Office Chair
  * Incoterm: EX WORKS
  * External Trade: Definitive
- Confirm the invoice
- Generate CFDI via "Send & Print" button

(*) https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade

**Issue:**
A traceback is raised because an inexisting method (i.e. `_get_customer_cfdi_values`) is called.

**Cause:**
The missing method has been renamed from "_l10n_mx_edi_get_customer_cfdi_values" to "_get_customer_cfdi_values" during a refactoring, but the original method has been deleted without implementing the new one.

**Solution:**
"_l10n_mx_edi_get_customer_cfdi_values" method was used to generate the data for the delivery address without altering the existing CFDI values.
These data were used to populate the external trade data of the CFDI.
"_add_customer_cfdi_values" method is similar to removed "_l10n_mx_edi_get_customer_cfdi_values" method, except that it also updates "receptor" in the CFDI.
It is used with a copy of the cfdi values to compute the values for the delivery address.

opw-3849153

Forward-Port-Of: odoo/enterprise#60758