Issue:
Doing down payment up to 100% can create a -0.00 PayableAmount that won't match the QR Code value, as it's set to absolute.

Step to reproduce:
1 Install l10n_sa_edi
2 Navigate to Accounting > Configuration > Taxes.
3 Select the 15% tax and copy it.
4 In the Advanced Configuration tab, select the "Included in Price" option. 5 Navigate to Sales.
6 Select NEW
7 Add ARAMCO (default customer in l10n_sa) as a customer
8 Click into ARAMCO and change contact type to an Individual. 
9 Navigate back to Sale Order.
10 Add the following products:
-  a 	Booking Fees.              1 quantity. Unit price  225.4 	15% tax (price included)
-  b  Burger Menu Combo. 1 quantity. Unit price  180 	15% tax (price included)
-   c  Booking Fees.              1 quantity. Unit price  300 15% tax (price included)
-  d  Burger Menu Combo.   1 quantity. Unit price -101.43 	15% tax (price included)

11 Select Confirm.
12 Select Create Invoice, then Down payment of 100%.
13 Confirm the invoice.
14 Navigate back to Sale order.
15 Select Create Invoice, then Regular Invoice.
16 Confirm the invoice.
17 Select "Process now" in the blue banner.
18 Receive error.

Current behavior:
- Message: "Invoice was rejected by ZATCA"
- ZATCA return an error 400 and states the QR Code is invalid as the BT-115 in the invoice (XML) and QRCode doesn't match

Expected behavior:
- Message: "Invoice Successfully Submitted to ZATCA"

Cause of the issue:
- Some issues with floating point operations create a difference in value between a 100% down payment and the value of the invoice it covers. This results in a -1e-13 `payable_amount` that ends up being a -0.00 PayableAmount after going through `float_rounding`.

Solution:
- By rounding the `payable_amount` as per currency limit, the `payable_amount` fall back to -0.00. Then it goes through `float_rounding` which return 0.00.
opw-5059795

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

Chrome iOS wraps some text nodes (like measures, email...) with a
`<chrome_annotation>` tag, which breaks OWL rendering.

This commit works around it by adding the (undocumented) `<meta
name="chrome" content="nointentdetection">` tag to disable this Chrome
behavior. The tag has to be set before the onDOMContentLoaded event to
be taken into account.

Note: Looks like this behavior was present in Chrome iOS 127 and
disabled afterward (because it already had issues) but it appeared again
in version 140-141.

References:
- https://issues.chromium.org/issues/353650041
- https://issues.chromium.org/issues/388718411
- https://stackoverflow.com/questions/78207646/how-do-i-disable-chrome-annotation-tags
- https://stackoverflow.com/questions/78575970/prevent-auto-detection-of-phone-numbers-in-chrome-mobile
- https://stackoverflow.com/questions/78725191/stop-chrome-ios-auto-detecting-numbers-followed-by-letter-m-as-metre-units-an
- https://github.com/solidjs/solid/issues/2235

opw-4969197

Steps to reproduce:
1. Install Time Off (hr_holidays).
2. Go to Time Off → Configuration → Mandatory Days.
3. Create a mandatory day.
4. Open the user profile (top right corner) and change the language to Hebrew.
5. Open Time Off and view the calendar.

Issue:
The mandatory day marker is displayed on the incorrect date when the interface is in Hebrew.

Cause:
https://github.com/odoo/odoo/blob/ea9cd8357e148654458e3505963ae847d181776e/addons/hr_holidays/static/src/views/hooks.js#L18-L32
This is because the code was using 'info.el.dataset.date' directly which is based on the rendered DOM element and can be influenced by locale formatting, instead of the canonical ISO date, leading to incorrect selectors when trying to add the hr_mandatory_day CSS classes to the date.

solution:
Use the correct date value derived from info.date via Luxon’s toISODate() method Replaced info.el.dataset.date in the DOM selectors with the normalized ISO date to ensure that the correct element is targeted
regardless of the current language or locale.

opw-4979274

This bug is in France localization. In some cases employee schedule seems ignored in timesheet entry
(`account.analytic.line`) creation, and the duration field is created using the company schedule.
The reason is the case which the employee schedule starts before company scheudle or ends after it.

To reproduce the bug:
1- Make a db with fr company (install l10n_fr)
2- Make two working schedule:
- Company schedule with working day on Monday from 8:00-12:00 13:00-17:00
- Employee schedule with working day on Monday from 8:30-12:25 13:30-17:15

3- Assign company schedule to company in `Company Working Hours` in Setting and apply employee schedule to an employee from `Payroll` tab of employee
4- Allocate some time off to the employee and take a time off on Monday
5- Check the work entries for the day you took the day off on timesheet app
6- 7:24 `Worked Hour` is shown instead of 7:40

The bug occurs because in calling `adjust_date_range`, the case which employee's schedule ends after company schedule is not considered.

opw-4868643

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