Description of the issue/feature this PR addresses:
This PR addressed two issues, one related to pos_sale, and the other related to l10n_gcc_invoice that was found during testing.

the first and main issue this PR addresses is that _get_downpayment_lines and _is_downpayment don't work properly on downpayment and final invoices generated in POS since there is no link formed between them through the sale order.

the second issue occurs during when printing downpayment invoices that were made through POS. since there is no line.name for the downpayment line. an error pops up due to the dual language logic in place.

To reproduce the issue:
- install pos_sale & l10n_sa_edi_pos.
- configure downpayment product on pos.config
- generate an SO and confirm it in the backend
- create a downpayment for that SO through POS
- settle the SO on the POS or through the backend.
- you'll find that the final invoice generated doesn't reference the downpayment invoice
- you'll also find that the downpayment invoice doesn't have the correct invoice type code indicating that it's a downpayment. 
- printing the invoice will also give an error when l10n_gcc_invoice is installed (for the downpayment invoice)

Current behavior before PR:
xml documents generated from l10n_sa_edi don't carry the correct reference to the downpayment invoice when it's the final invoice. they also don't have the correct invoice type code when it's a downpayment invoice if generated through POS

Desired behavior after PR is merged:
the methods _get_downpayment_lines and _is_downpayment now correctly identify the downpayment lines & if it's a downpayment respectively.
the dual language product name now shows on the invoice pdf without raising an error if line.name is undefined.

Task-5135918

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

Forward-Port-Of: odoo/odoo#244443

when using signInOut with geolocation, slow or temporarily unavailable network connections could cause getCurrentPosition to hang indefinitely (default timeout is infinite). This led to:

- Frontend not updating, allowing multiple clicks and creating duplicate attendance entries
- Incorrect check-in/check-out data

__Steps to reproduce:__
1. check in while online and server reachable
2. disconnect network or make server unreachable
3. check out

Currently, getCurrentPosition would hang indefinitely. till the network is restored. then it will trigger the rpc call much later than the action time. in the meantime, the user could click multiple times, creating multiple attendance records.

With this fix, getCurrentPosition will timeout after 10 seconds, then it will proceed without position. and if the server is unreachable, it will show an error notification without allowing multiple clicks.

__FIX__
- Adds a timeout to getCurrentPosition
- Uses a `_attendanceInProgress` flag to prevent multiple clicks
- Ensures only the first callback (success or error) triggers the RPC

opw-5414044

Forward-Port-Of: odoo/odoo#247140
Forward-Port-Of: odoo/odoo#244477

### Issue:
Attendances overlapping on two days are ignored for hourly accrual plans based on attendances.

### Steps to reproduce:
- Install 'hr_holidays_attendance'
- In Time Off > Configuration > Accrual Plan, create a new plan
	- Based on worked time
	- Hourly rule
	- Attendances as Source
- In Management > Allocations, create an allocation for an employee using the new accrual plan
- Create an Attendance for this employee in the period of the Accrual Plan
	- Check-in at 22pm for example
	- Check-out at 7am
- Run the cron "Accrual Time Off: Updates the number of time off"
- The Allocation ignores the worked time from the attendance

### Cause:
`_get_accrual_plan_level_work_entry_prorata()` is called on each day of the accrual period. So `start_dt` is `datetime.datetime(2026, 1, 2, 0, 0)` and `end_dt` is `datetime.datetime(2026, 1, 3, 0, 0)` for example. This means that the search will always excludes attendances overlapping on two days.

https://github.com/odoo/odoo/blob/26f3026ed45cc409cd7f67fa219d44f1adbac9b7/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L79-L83

### Solution:
To count the attendances on several days, we need to split these attendances by day because `_get_accrual_plan_level_work_entry_prorata()` is only called with an interval of one day from midnight to midnight.

First we get all attendances overlapping with the day by changing the domain in the search.

Then we could simply take the difference between `max(attendance.check_in, start_dt)` and `min(attendance.check_out, end_dt)` but we also need to remove the lunch breaks (they were not counted in `attendance.worked_hours`). This would mean duplicating the code present in `_compute_worked_hours()`. To avoid this we create a new method for `hr.attendance` named `_get_worked_hours_in_range()`. That returns the number of hours worked due to this attendance in a given time frame. This new method can be used in both cases to get the needed value.

opw-5172669

Forward-Port-Of: odoo/odoo#246964
Forward-Port-Of: odoo/odoo#246270

### Issue:
The annual VAT report could not be legally validated because some mandatory parent fields were missing in the XML export

### Cause:
This PR add some required fields:
https://github.com/odoo/enterprise/pull/93357
However, for file validation, the following parent fields are mandatory if certain child fields are present:
```
- Field 129: Field 129 is mandatory if one of the following fields is filled : 771, 971, 772, 972, 774, 773, 973, 124, 128, 197
- Field 137: Field 137 is mandatory if one of the following fields is filled : 776, 976, 777, 977, 778, 978, 134, 136, 198
- Field 145: Field 145 is mandatory if one of the following fields is filled: 781, 981, 782, 982, 783, 983, 142, 144, 199
- Field 163: Field 163 is mandatory if one of the following fields is filled : 791, 991, 793, 993, 797, 795, 995, 158, 162, 200
- Field 175: Field 175 is mandatory if one of the following fields is filled: 396, 162
```
164 and 165 are also added according to this assertion: https://github.com/odoo/enterprise/blob/c93388741182f1873054557a6e7767186674fafa/l10n_lu_reports/models/l10n_lu_annual_tax_report.py#L167-L171

### Note:
This PR is related to the 18.0 PR: https://github.com/odoo/enterprise/pull/104785
It also fix issues in `_add_yearly_fields()` because the validation consider form as float instead of dict

### Steps to reproduce:
- Install `l10n_lu_reports` and switch to LU company
- Open the Tax Report `Annual VAT Declaration`
- Export the XML
- Notice that codes 396, 394 149, and 153 are present, but 129, 137, 145, 163 and 175 are missing

opw-5119920

Forward-Port-Of: odoo/enterprise#106457
Forward-Port-Of: odoo/enterprise#105143

Sending a WhatsApp message to a blacklisted number fails to be blocked if the recipient's phone number country differs from the sender company's country.

### Steps to reproduce

1. Configure a WhatsApp account.
2. Set the Company's country to Germany (+49).
3. Create a Contact with a Belgian phone number (e.g. +32456001122).
4. Send a template message to this contact.
5. Have the contact reply with "STOP" to opt-out (this correctly adds +32456001122 to the blacklist).
6. Send another message to the contact.
   - Expected: The message is blocked.
   - Actual: The message is sent successfully.

### Root cause

The blacklist search logic relies on implicit phone number sanitization which behaves incorrectly for international numbers without a `+` prefix.

1. `whatsapp.message` stores numbers as `CountryCode + NationalNumber` without a `+` (e.g. "32456001122").
2. `phone.blacklist` stores numbers in E.164 format with a `+` (e.g. "+32456001122").
3. When searching `phone.blacklist` with "32456001122", the system interprets it as a local number for the Company's country (Germany) because of the missing `+`.
4. It reformats the search term to German E.164 ("+4932456001122").
5. The query fails to match the actual blacklisted number ("+32456001122"), allowing the message to pass.

### Fix

Explicitly prepend a `+` to the recipient's number before searching the blacklist. This forces the validation logic to parse the number as international (E.164), bypassing the company-country bias and ensuring the search term matches the stored blacklisted number.

opw-5401789

Forward-Port-Of: odoo/enterprise#106395
Forward-Port-Of: odoo/enterprise#104556

**Issue**
When leaving the barcode MRP operation, `post_barcode_process()` may incorrectly update the move quantities.

**Steps to reproduce**
- Create a product with a BOM using a component with qty 6.
- Create an MO producing qty 1.
- Open the Barcode app > Manufacturing > open the MO (remove “MO Ready” filter if needed).
- Click “+1”.
- Edit the component qty from 6 to 3.
- Exit the operation.
- Re-enter the operation.
-> The component shows 3/3 instead of 3/3 and 0/3.

**Cause**
On exit, `_onExit`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1489
calls `post_barcode_process()`, which triggers `split_uncompleted_moves`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L16
correctly creating a `stock.move.line` with qty 3.

However, `_truncate_overreserved_moves`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L40
then reduces the move quantity to `max_reserved_qty = 3` and unreserves the remaining 3 units:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/models/stock_move.py#L49

This happens because the newly created move line is initialized with `reserved_uom_qty = 0`:
https://github.com/odoo/enterprise/blob/776848dc4e29d07a027847fde46a59f84dd35f56/stock_barcode/static/src/models/barcode_picking_model.js#L1256
leading to `max_reserved_qty = quantity_done = 3 < move.quantity = 6`, while `move.product_uom_qty` is still 6.

opw-5166763

Forward-Port-Of: odoo/enterprise#104199
Forward-Port-Of: odoo/enterprise#100314

For old databases that were created before 16.0, existing sign request might not have a communication company set.

Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to open such sign request will result in a crash:

```
Traceback:
  ...
  File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 354, in get_document
    context = self.get_document_qweb_context(request_id, token)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 88, in get_document_qweb_context
    date_format = posix_to_ldml(lang.date_format, locale=locale)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/data/build/odoo/odoo/saas-18.3/odoo/tools/misc.py", line 606, in posix_to_ldml
    for c in fmt:
TypeError: 'bool' object is not iterable
```

This commit fallback to the create user's company to determine the date language when there is not communication company set.

no-task (from feedback pad)

Forward-Port-Of: odoo/enterprise#87526

Link to Avalara (Avatax) documentation:
https://developer.avalara.com/api-reference/avatax/rest/v2/models/LineItemModel/

Expected Behaviour:
The itemCode sent to the AvaTax API should be 50 characters or fewer
to comply with Avalara's field length constraints.

Actual Behaviour before the Fix:
When an itemCode exceeded 50 characters, the system attempted to send
the request as-is. This resulted in the AvaTax API returning an error,
causing the transaction or tax calculation to fail.

Behaviour with the Fix:
The system now ensures that the itemCode adheres to the 50-character
limit before the API call is made, by trancating the code to the
first 50 characters if it exceeds 50 characters. This prevents API
rejection and ensures successful tax processing for items with
long identifiers.

Steps to reproduce:
1. Create or select a product/item with a reference (or barcode if
   using UPC) longer than 50 characters.
2. Trigger an action that calculates tax via the AvaTax
   integration (e.g., creating an invoice or updating a line item).
3. Observe the API response.

- Before fix: API returns a validation error regarding the
  itemCode length.
- After fix: Request is successful as the itemCode is
  properly handled/validated.

opw-5406451

Forward-Port-Of: odoo/enterprise#105017