To reproduce the issue, on a large db:
- Open the form view of a res.partner
- Click on the "Due" smart button, to open the Followup Report

==> The opening of the report takes much longer in 19.1 than it used to in 19.0. This is a problem when processing the followup with the cron, as it can cause it to time out.

This situation happens because we now use a subquery computing the partner from the account.partial.reconcile objects linked the the move lines (because the Partner Ledger needs to consider move lines made without any partner as well). in 19.0, a domain on the partner_id field was directly executed, taking hence advantage of the index existing for that field.

While this makes sense for the Partner Ledger, it's not relevant for the Followup Report. Indeed, in that report, when filtering on a single partner, we only want to show the open invoices and unreconciled payments made for that partner, so we'll never need to consider the lines without partner. We can therefore use the standard domain on partner_id in that case, like before, solving the perf issue in the meantime.

Forward-Port-Of: odoo/enterprise#110966

**Description of the issue/feature this PR addresses:**
This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service.

**Current behavior before PR:**
When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice.

**Desired behavior after PR is merged:**
For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error.

Forward-Port-Of: odoo/enterprise#106881

Currently, an error occurs when user creates a payment for an invoice.

**Steps to Reproduce:**

 - Install `l10n_uk_bacs` with demo data.
 - Switch to the `UK company`.
 - Go to `Journals`, select the `Bank Journal`, and remove the `Bank Account Number`.
 - Go to `Invoices` and create an invoice by adding an `invoice line` with price greater than zero.
 - `Confirm` the invoice.
 - Click `Pay`, select `Bacs Direct Debit` as the payment method, and click `Create Payment`.

`ValueError: Expected singleton: res.partner.bank()`

This error occurs when creating a payment for an invoice using the Bacs Direct Debit payment 
method. The constraint check bacs bank account trigger [1], but since the journal has no bank 
account number, it raises an error here [2].
Similar error also occurs when validating a batch payment [3].

This commit ensures that if the journal has no bank account, or if the bank account is invalid, 
the system raises the same validation error. In batch mode, it raises a UserError when the 
account is missing.

[1]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/account_payment.py#L52-L58

[2]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/res_partner_bank.py#L18-L19

[3]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/account_batch_payment.py#L74

sentry-7259107152

Forward-Port-Of: odoo/enterprise#107235

Currently, an error occurs when configuring tax return periods for a Netherlands company.

- This PR [97615](https://github.com/odoo/enterprise/pull/97615) introduced the `_get_tax_tags_for_nl_sales_report()` function
- In the 19.1 fw port, the implementation is different. 
  This function is neither added nor called.
  Instead, `_get_ec_sales_tax_tags()` is called in its place.
- In the 19.2 fw the function is still missing, but it is called, so it does `Traceback`
  `AttributeError: 'l10n_nl_reports.ec.sales.report.handler' object has no attribute '_get_tax_tags_for_nl_sales_report'`

We fix this by using `_get_ec_sales_tax_tags()` in `19.2`, just as `v19.1` does.

**Steps to reproduce:**
- Install `l10n_nl_reports` and `accountant` modules
- Set up an `NL company`.
- Go to `Accounting > Tax Returns > Set Periods`.
- Set the date 
- Click `Apply`

Tickets links: [6035534](https://www.odoo.com/odoo/project.task/6035534), [6045553](https://www.odoo.com/odoo/project.task/6045553), [6045241](https://www.odoo.com/odoo/project.task/6045241), [6037249](https://www.odoo.com/odoo/project.task/6037249)

opw-6035534
opw-6045553
opw-6045241
opw-6037249

Forward-Port-Of: odoo/enterprise#110820

Steps to reproduce:
------------------------------------------
1. Install Planning module
2. Click on any shift in Gantt view > Edit
3. In the Resource field, click on Search More to open the selection dialog
4. In the pop-up window, observe that a default filter is already applied
5. Click on the Roles filter in the search panel

Observation:
------------------------------------------
The filter on the Roles field applies an 'Invalid Record ID' in the domain

Issue:
------------------------------------------
the default filter on `role_ids` passes the role ID as a string (e.g., 4) instead of an integer (4). This happens because the `filter_domain` uses `[self]`, and `self` is substituted with `label.trim()` in `_getFieldDomain`, which is always a string even when the underlying value is a numeric ID

https://github.com/odoo/odoo/blob/accaa246d5818572996660f967624978e906b5c3/addons/web/static/src/search/search_model.js#L1747-L1750

Solution:
------------------------------------------
Replace `[self]` with `[raw_value]` in the `filter_domain` of the `role_ids` search field, the `raw_value` variable holds the actual typed value (integer ID) instead of the string label.

opw-6003611

Forward-Port-Of: odoo/enterprise#109781

Before this commit, the `Softphone` component was instantiated as part of the `SoftphoneContainer`, main component of the backend. After this commit, the `SoftphoneContainer` now renders nothing and manages the `Softphone` component by showing it, or not, as an *overlay*.

This comes with several functional and technical advantages / fixes.

TECHNICAL:

The z-index of the main softphone component changed multiple times over the years. Commit [1] forced the softphone on top of all modals always, commit [2] changed it to be below of all modals always without any kind of explanation, big refactorings at [3] and [4] kept kinda the same "below all modals" behavior, then finally commit [5] recently made it more complex by forcing the softphone on top of modals during calls and, to keep things working, it forced all "voip dropdowns" on top of *everything* at all times... all of that messing with z-indexes which is basically never a good idea.

The result is that it was now needed to identify "voip dropdowns" with a specific "o-voip-dropdown" class, which is a source of mistake and complexity especially when using standard components that could open standard dropdowns themselves.

With this commit: no more extra classes and no more messing with z-indexes at all.

FUNCTIONAL:

A) Stacking bug

Messing with z-index as explained above led to wrong stacking order:
- Open the softphone
- Open the availability dropdown at the top left (in prod mode)
- Open the user preferences modal (in Odoo navbar) (or any other) => Bug: it is between the softphone and its dropdown (this can be seen
   by moving the modal or being on a smaller screen but also by the fact
   the dropdown is not faded and can still be interacted with).

B) Softphone / Modal / Calls flow

As proven by the [1] -> [5] series, there is no good "softphone always at the bottom/top" rule. What is really wanted is the softphone to act as any other overlay in Odoo: when it opens, it is at the top. Then if other things are opened, they also open at the top. The only exception at the moment being "what if I receive a call while I have dialogs that are opened?": simple, this commit closes the softphone and re-opens it so it is now at the top of overlays again, just like if the user asked that overlay to open. Then during the call, if the user wants to open a modal again, it opens above the call to be usable (which [5] "broke"). Then if the user wants to access what is below (the modal or the softphone), just like always, the user must close what is on top (the modal / the softphone).

We could also later have a button to "move the softphone on top" just like when receiving a call, that might also be a good idea to not have to close top modal to use the softphone... but in general we just rely on users closing what is in front of them. Recently we also introduced the PiP mode at [6] which minimizes the need of wanting to keep the whole softphone on top.

[1]: https://github.com/odoo/enterprise/commit/12b3c8d1cdfda64bbe13528f08c0cb11bcbfb466
[2]: https://github.com/odoo/enterprise/commit/767e9123fe627313c75f8eb2c324ea9d8e6e09f6
[3]: https://github.com/odoo/enterprise/commit/bbdb033031720365c448c6f3de40906ee0c4243e
[4]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd
[5]: https://github.com/odoo/enterprise/commit/eb5a1e9b41f5b08821ad5e8a6e6e32d7bad07f46
[6]: https://github.com/odoo/enterprise/commit/2170ada30120f9d60bb039d5b384d5a081c85509

task-6052118