**Issue:**
```python
 File "/data/build/enterprise/l10n_cl_edi/models/account_move.py", line 744, in _l10n_cl_edi_post_validation
    raise UserError(
odoo.exceptions.UserError: The stamp date and time cannot be prior to the invoice issue date and time. TIP: check in your user preferences if the timezone is "America/Santiago"
```

**Cause:**
Posting an invoice at early local hours (e.g., 2025-12-11 04:00) is converted by the [Chilean timezone (America/Santiago)](https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/l10n_cl_edi/models/l10n_cl_edi_util.py#L117-L120) to the previous day (e.g., 2025-12-10 19:30).

**Solution:**
- Freeze the test time at a stable CL-safe hour
- Add a fixed `invoice_date` aligned with the frozen timestamp

Reference : [timezone converter](https://dateful.com/time-zone-converter?t=730pm&d=2025-12-10&tz2=Santiago-Chile)
Runbot error: [234755](https://runbot.odoo.com/odoo/runbot.build.error/234755)
Related PR: https://github.com/odoo/enterprise/pull/99518

Steps to reproduce:

- Create service product with UoM 'pack of 20 hours' and prepaid policy
- Sell the product and confirm the Sales Order
- Create a helpdesk ticket/task linked to the Sales Order Line
- Log 22:00 on timesheets

Current behavior:
Sales Order Line shows '-2:01 remaining'

Expected behavior:
Should show '-02:00' to reflect two hours overconsumed without rounding.

Root cause:
Python's float type follows the IEEE 754 double-precision standard,
where only base-2 fractions can be stored precisely. Base-10 fractions
cannot be represented exactly, introducing tiny rounding errors.  
During chained operations such as multiple conversions or subtractions,
these small errors accumulate into larger discrepancies.  
The float_round() function uses a small constant epsilon to correct
rounding noise, but as arithmetic chains grow, errors exceed epsilon's
tolerance and it can no longer correct them.  
Since a single global epsilon cannot handle every case (small vs. large
values, chained vs. single operations, or regressions), rounding drift
is inevitable when rounding happens repeatedly.

Fix:
To prevent these rounding errors from compounding, the solution is to
stop intermediate rounding altogether. By using conversions with
round=False, all arithmetic is done in the base unit (hours) with full
float precision, and rounding is applied only once when displaying the
final value. This eliminates error accumulation and ensures consistent,
drift-free results.

task-5090240

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