Issue:
Sending payments to CFDI before its full amount is reconciled allow sending the same invoice payment several times to CFDI. So some invoices are declared as paid several times and the total amount of the payment is seen as exceeding the real total.

This fix is a back port of odoo/enterprise#108355 and aim to prevent some things the backend allow, but the front end prevents.

Following steps could be used to reproduce from 18.3.

Steps to reproduce:
- In a Mexican company
- Create an invoice A of $40 to Inmobiliaria CVA
- Confirm and send to CFDI
- Go to bank, create a new Bank transaction of $80
- reconcile with Invoice A
- Go to invoice A => click on button "Update payments" (it doesn't appear before version 18.3)
- Then sheet CFDI and Download There is the first XML sent to CFDI with payment for invoice A
- Create an invoice B of $40 to Inmobiliaria CVA
- Confirm and send to CFDI
- reconcile the transaction with Invoice B
- Go to invoice B
- Click on button "Update payments"
- Then sheet CFDI and Download There is the second XML sent to CFDI with payment for invoices A and B

Invoice A payment was sent twice to CFDI

Expected behavior:
- The "Update payment" button should appear only once the invoice payment is fully reconciled.

Current behavior:
- The update payment button appear once the invoice is reconciled with a payment.

opw-5432421

### Context:
Clients can have some existing accounts with `reconcilable` flag set as True. Some of these accounts also have partially reconcilated transactions. In Odoo 19.0, it is not authorized to toggle the `reconcilable` flag from True to False on accounts that contain partially reconcilated transactions.

When the migration script `l10n_pl/migrations/2.1/end-migrate.py` is executed and try to update the CoA by adding/updating accounts, using the accounts in the file
`l10n_pl/data/template/account.account-pl.csv`. This CSV file contains a reconcilable flag per account.

### Problem:
Before this modification, the upgrade script was trying to update the CoA using `_load_data`, which try to overwrite the reconcilation flag of accounts in the client DB. A traceback occurs during the upgrade if an account's `reconcilable` flag is toggled to False while it still contains partially reconciled transactions.

### Solution:
I have sanitized the dict `data` using the _pre_reload_data method.

### Notes:
`_pre_reload_data` method sanitizes the dict `data` by avoiding the creation of duplicated accounts, the creation of duplicated fields for a given record, the toggling of the `reconcilable` flag, etcs.

Back port of: https://github.com/odoo/odoo/commit/23ed5448a13255e68ff4d3ca87884c2ca2f97ba3
Reason: the issue was originally introduced in `18.0` (see https://github.com/odoo/odoo/commit/d5109a45d610916530b4b74cf3e2fa440ee7ed63)
Related to: https://github.com/odoo/upgrade/pull/10266#discussion_r3402549250

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

The following error is raised in the POS when paying with an Adyen terminal:
```
TypeError: Cannot read properties of undefined (reading 'uuid')
at Proxy.handleAdyenStatusResponse
```

Adyen delivers webhook notifications at-least-once, so the ADYEN_LATEST_RESPONSE event can fire several times for a single payment, running handleAdyenStatusResponse concurrently. After the await on get_latest_adyen_status, a previous (duplicate) notification may already have resolved the payment line, so getPendingPaymentLine no longer returns it and the subsequent line.uuid dereference crashes.

opw-6237987 patched the same root cause on a single line by adding an optional chaining operator in isPaymentSuccessful, which only moved the crash to the next dereference.

Fetch the pending line once at the start of handleAdyenStatusResponse and bail out when it is gone, so every dereference below is safe. The same guard is added to the remaining branches of _adyen_handle_response for consistency with the existing Reject branch.

opw-6237987

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

**Steps to reproduce:**

To test this, you will need an official DIAN setup, because this error comes from the response to our API call to the DIAN.

- Setup the DIAN in a colombian company
- Open the PoS
- Order a product
- Before paying, make the amount we are paying bigger than the amount due
- We get an error response from the API, the error is saying that the total due does not match what we paid

**Why the fix:**

Currently, the xml is rejected because the sum of the **PaidAmount** in the **PrepaidPayment** tag is not equal to what we are trying to pay for.

This is happening because to avoid the fact that we can not send a line with negative amount, we used the **abs()** function on the line amount to make it positive.

The negative line comes from the fact that when we have a total due that is below the amount paid, we create a new payment line with a negative amount to balance it out. But as we can't send lines with negative amount, we needed to make it positive.

This does not work, as the sum of the lines' amount will then be too much compared to what we are paying for, because instead of substracting it we will be adding it.

To avoid this, we now group the amount in one single tag and send it this way. This ensures that the sent amount is correct and equals the amount due, and does not send a negative line.

opw-6232575

Fix a concurrency race condition in the product catalog where rapid quantity updates could result in incorrect final quantities on Sale Order Lines (SOL).

Steps to produce:
---
- We need a DB with too many products. Also it might not be easy to reproduce the issue locally. Try runbot.
- Open a Sale Order (SO) and open the Product Catalog.
- Rapidly change or paste quantities (e.g., changing from 1 to 100) across multiple records very fast.
- Return to the SO. Some lines intermittently retain an intermediate quantity (e.g., qty = 1) instead of the final entered value.

Cause:
---
- This is a concurrency issue. In the faulty cases, the `update_order_line_info` setting quantity to 1 takes a few seconds to resolve, while the update setting quantity to 100 resolves faster (around 200ms). This cause the SOL final quantity set to 1.

Fix:
---
- We can chain RPC calls to ensure that each request is completed before starting the next one.

Backport of ef9554ad95d5e39ab7b550db0d39454373f99aed

opw-6282877

---

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

Forward-Port-Of: odoo/odoo#269750