### Bug

`odoo.tools.date_utils.float_to_time` builds the minutes with a rounding step:

```python
return time(int(integral), int(float_round(60 * fractional, precision_digits=0)), 0)
```

When the fractional part of the hour is high enough, `round(60 * fractional)`
rounds up to a full **60**, and `time(hour, 60)` is invalid:

```python
>>> float_to_time(16.9959)
ValueError: minute must be in 0..59, not 60
>>> float_to_time(8.999)
ValueError: minute must be in 0..59, not 60
```

Any hours value whose fractional part is ≥ ~0.9917 hits this — which happens
easily with computed/aggregated work-hour floats.

### Fix

Carry the rounded-up minute into the hour, and return `time.max` when that carry
reaches the end of the day (mirroring the existing `hours == 24.0` case):

```python
if minute == 60:
    hour += 1
    minute = 0
if hour >= 24:
    return time.max
```

`float_to_time(16.9959)` now returns `time(17, 0)`, `float_to_time(23.9959)`
returns `time.max`, and regular values are unchanged.

Adds `TestFloatToTime` in `test_date_utils.py` covering the carry, the
end-of-day carry, and regular values.

Forward-Port-Of: odoo/odoo#280807

The following commit resets qty_invoiced to zero on sale order lines paid by a POS order when that order is refunded.
https://github.com/odoo/odoo/commit/ac39aa4f68dfc77011c39e468e3f60e0338a3c69

However, it does not handle the sale order line created for a refunded POS down payment. That line keeps `qty_invoiced` = -1, which causes the refunded amount to be included again when settling or invoicing the sale order.

Steps to reproduce:
- Create a sale order.
- Pay a down payment through the POS.
- Refund the down payment order from the POS.
- Settle the remaining amount from the POS or invoice the sale order from the backend.

Result:
- The generated invoice includes the sale order total plus the refunded down payment.
- Sale order `amount_invoiced` will be the down payment amount.

Fix:
- Delete the refunded downpayment to match the sale flow.
- Include refunded down payments in the amount_invoiced computation.

opw-6378891

Forward-Port-Of: odoo/odoo#283308
Forward-Port-Of: odoo/odoo#278011

Issue:

- DATEV does not support multiple foreign currencies on a single journal line.
- This can occur when reconciling a bank transaction where:
  - the payer uses one currency (C1),
  - the bank journal is held in another currency (C2),
  - the company uses a third currency (C3).
- The existing export logic could not represent the bank liquidity and
  foreign AR/AP currencies separately in such cases.

Fix:

- Detect 3-currency cases from bank statement transactions and their
  liquidity line.
- Use the DATEV clearing account (1360 SKR03 / 1460 SKR04) to split the
  transaction into two logical legs:
  - Bank → Clearing (bank journal currency)
  - AR/AP → Clearing (payer currency)
- Emit the liquidity leg only once when multiple foreign AR/AP lines are
  reconciled against the same bank transaction.
- Keep regular 1- and 2-currency transactions on the existing export path.

Impact:

- Correctly represents 3-currency bank settlements in DATEV.
- Keeps each exported line in a single foreign currency.
- Leaves manual entries and payment transactions outside this specific
  handling, as the scenario is specific to the bank liquidity line.

taskID-5457547

Forward-Port-Of: odoo/enterprise#128876
Forward-Port-Of: odoo/enterprise#109010