In **l10n_ec**, negative lines are not accepted in the XML.
They must be dispatched as discounts on positive lines.
The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can cause rounding issues when the decimal accuracy for `price_unit` is increased.

## Steps to reproduce

With **l10n_ec**:
1. Change the decimal accuracy to 6 digits.
2. Set the rounding method to *global rounding*.
3. Create an invoice with the following lines:

| Quantity | Price    | Taxes     |
|-----------|----------|-----------|
| 20        | 1.4235   | VAT 0% G  |
| 20        | 1.6425   | VAT 0% G  |
| 20        | 1.2337   | VAT 0% G  |
| 20        | 1.2337   | VAT 0% G  |
| 20        | 1.4235   | VAT 0% G  |
| 6         | 3.747768 | VAT 15% G |
| 6         | 3.747768 | VAT 15% G |


In the generated XML, some product lines show a `descuento` of `0.01` or `-0.01`.

This happens due to rounding differences in how the `descuento` is computed in the
`common_details_info_template` from **l10n_ec_edi**:

format_num_2(line_edi_values['price_discount'] + abs(line.balance) - line_items[1]['base_amount'])

where `line.balance` and `line_items[1]['base_amount']` can differ by 0.01 due to global rounding applied during tax aggregation, and that difference must be redistributed somewhere.

This commit changes how negative lines are dispatched onto positive ones, aligning the behavior with **l10n_mx**.
Instead of using `tax_details_per_record` to build the XML, we now use `base_lines`, where the negative lines have already been distributed.

opw-5128612

Forward-Port-Of: odoo/enterprise#104659
Forward-Port-Of: odoo/enterprise#97337

## [FIX] sale_renting_planning: prevent user to do a conflict with rental shift

Before this commit, the user could update the shift linked to a rental
order and creating a conflict with another shift for the same resource
and so, it would be impossible for the resource to be in 2 spaces at the
same time (or it is impossible to rent a room to 2 different customers).

This commit returns an Validation Error if the user updates the planned dates
of a rental shift and creates a conflict.

## [FIX] sale_renting_planning: add problematic shifts only if rental order

Before this commit, the previous fix making sure the error, saying no
resource is available during the generation of a shifts when the user
confirms a sale order, is only displayed when the `Sync Shifts and
Rental Orders` is enabled, could potentially never display the error
when it should be expected because we only check if the last SOL of the
batch to generate shifts has the feature enable or not.

This commit makes sure the error is correctly displayed as expected.

## [FIX] sale_renting_planning: update condition of Rental buttons in shift

Before this commit, the user could click on Create order button for an
open shift is the role having the rental feature enabled. To problem is
a resource is required to make sure the rental order can be delivered.
About the other button shown, `Add to Last Order` one, this one could be
clicked even if the shift is in conflict with another shift and so, it
will display a warning saying no resource is available.

This commit makes sure
- `Create Order` button in shift form view is not
visible when the shift is a open shift.
- `Create Order` and `Add to Last Order` buttons in shift form view are
not displayed when the shift is in conflict.

task-5065930

Forward-Port-Of: odoo/enterprise#97024

Issue:
------
The database migration was blocked during the `config_parameter` [loading](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/config_parameter_whatsapp_template.xml#L6) phase. This occurred because several `ir.config_parameter` records used `ref()` to point to [whatsapp templates](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml) that were manually deleted in the production environment.

ValueError is raised:
```py
    raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: whatsapp_sign.sign_request_whatsapp_template
```
Cause:
-------
Since these whatsapp templates are defined with [`forcecreate="0"`](https://github.com/odoo/enterprise/blob/19.0/whatsapp_sign/data/sign_request_whatsapp_templates.xml#L3), Odoo does not recreate them automatically during migration. This left the External IDs (IMD) pointing to non-existent records, causing a `ValueError: External ID not found in the system` that blocked the migration.

Solution:
-----------
Updated the `ref()` calls in the XML for these configuration parameters to include `raise_if_not_found=False`. This allows the registry to initialize successfully by returning None instead of crashing if a template is missing.

tgb: [2448](https://upgrade.odoo.com/odoo/tbg/2448?debug=1)
upg: [3895200](https://upgrade.odoo.com/odoo/upgrade.request/3895200?debug=1)
opw: [5931388](https://www.odoo.com/odoo/project/70/tasks/5931388?debug=1)

Forward-Port-Of: odoo/enterprise#107477

Currently, it is possible to set a DateV identifier on a partner even if it is already assigned to an archived partner. This leads to duplicate identifiers if the archived partner is later unarchived.

###  **Steps to reproduce:**
1) Install **l10n_de_reports, Contacts** App with Demo Data. 
2) Switch to a **DE company**.
3) Create a contact 'Test-A' and set `'DateV Vendor' to 123456789` in the **Accounting Section**. 
4) Archive 'Test-A'.
5) Create 'Test-B' and set `'DateV Vendor' to 123456789`. 
6) Unarchive 'Test-A'.

### **Observed Behavior:**
'Test-B' is created successfully. After step 6, both 'Test-A' and 'Test-B' are active with the same DateV identifier.

### **Expected Behavior:**
A validation error should be raised when trying to save 'Test-B', stating that the identifier is already defined.

### **Root Cause:**
Since [this commit](https://github.com/odoo/enterprise/commit/733c4ba1fd5558891ffdbc67066c3a3a5938e2f0), company-dependent fields are stored as JSONB in the database. Due to this improvement, the previous SQL constraint (which enforced uniqueness across all records) was removed and replaced with a Python constraint.

However, the new Python constraint utilizes `search_count`, which by default filters out archived records (`active=False`). This allows the reuse of identifiers belonging to archived partners, breaking the uniqueness requirement that existed in previous versions.

Fix:
Update the `_check_datev_identifier` and `_check_datev_identifier_customer` constraints to use `with_context(active_test=False)`. This ensures that the uniqueness check considers all partners, including archived ones.

opw-5474106

Forward-Port-Of: odoo/enterprise#106146

Since [1], the voip calls infinite scrolling does not work anymore.

Steps to reproduce:
- Make sure to have at least 14 recent calls
- Open the softphone
- Go to the recent/history tab
- Scroll to the end => You are stuck seeing only the 13 last calls.

This was a Chrome-only issue, it works on Firefox. Weirdly, the infinite scrolling works on the contact tab on Chrome too, although this is the exact same implementation and configuration.

This is due to the unreliable behavior of IntersectionObserver regarding 0x0 elements. The infinite scrolling implementation in VoIP relies on the visibility of a "dummy" `<span/>` added at the end of the tab. That element has no width or height, making the implementation unreliable. As a stable minimal fix, this restores the feature by making the element have a width and height, without any visual/behavior changes thanks to negative margins and no pointer events on the item.

Note that [1] disabled a test that was testing the feature. This commit of course re-enables it.

[1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd

Forward-Port-Of: odoo/enterprise#106768
Forward-Port-Of: odoo/enterprise#106658