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

This test shows that with `round_globally` set and invoices in foreign currency, tax amounts are not correctly rounded to 2 decimal places before conversion, causing differences between printed invoice amounts and actual postings.

**Description of the issue/feature this PR addresses:**

When invoicing in a foreign currency (e.g. USD), and using the global tax rounding method (round_globally), the system calculates taxes using more than 2 decimal places in the foreign currency. For example, a 0.2% perception on a 124 USD invoice is calculated as 0.248 USD instead of 0.25 USD. While the printed invoice rounds it correctly, the internal accounting uses the unrounded amount, which after currency conversion (e.g. FX = 1066.50) results in discrepancies (e.g. 2.13 TEST difference in this case).

T**hese rounding inconsistencies:**

Accumulate over time across invoices.

Cause mismatches between printed documents and accounting records.

Create issues in supplier reconciliations and tax reports.

**Current behavior before PR:**

Taxes in foreign currency are computed with excessive precision (e.g., 0.248 USD instead of 0.25).

The rounding is not applied before converting to the company currency.

Causes accounting and fiscal inconsistencies.


**Desired behavior after PR is merged:**

Taxes in foreign currency are rounded to the correct number of decimals (e.g., 2) before conversion to company currency.

The posted amounts in the company currency match the rounded foreign currency values, avoiding residuals and discrepancies.

Ensures printed invoice amounts align with posted journal entries, maintaining consistency for both partners and fiscal reports.



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

**Steps to reproduce:**
* Install the **Accounting** module.
* Open a **Journal Entry** in mobile view.
* Add a **Journal Item**, opening it in a form dialog.
* Select a tax in the **Taxes Applied** field.
* Click on the **Save and close** button.

**Observed behavior:**
* The web client crashes with `TypeError: Cannot read properties of undefined (reading 'resId')`.

**Cause:**
* The `autosave_many2many_tags` widget triggers `model.root.save()` immediately when a tag is selected.
* When executing this save from within a transient dialog (common in mobile views), the client fails to correctly handle the record reload/synchronization leading to a crash when accessing `resId`.

**Fix:**
* Replace the autosave widget with the standard `many2many_tags` widget for **Journal Items** for form.
* Tax changes are now kept locally in the dialog and saved only when the user explicitly saves and closes it.

**Note:**
* The crash happens when `autosave_many2many_tags` calls
  `model.root.save()` on a **new** `account.move` from within a dialog.
* In QUnit tests, the mock server (`mockWebSave`) [1](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L627). which creates records [2.](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L1936)
  in-memory and does not trigger form reloads or component destruction.
* As a result, the crash cannot be reproduced in tests.




opw-5497342

A recent PR improved the performance of the General Ledger Report XLSX export in v17 because it used to raise memory errors and crash when there were too many lines.

Task: 5476982
PR: [103329](https://github.com/odoo/enterprise/pull/103329)

After this change, we now search for the accounts to include in the file with `_get_accounts_with_move_lines`.

Some accounts are filtered out if the points below are all true:
1. The `account_type` != 'equity_unaffected'
2. The `account.include_initial_balance` is FALSE (or NULL after a recent fix)
3. There are no amls with a date within the date range of the report

This last point is problematic, the general ledger should include accounts with amls if they are dated in the financial year corresponding to the `date_from` value, unless the `general_ledger_strict_range` option is activated. We do not list the journal entries in the report if their date precedes the starting date of the report, but we still perform a sum of their balance/debit/credit with `_get_query_sums()`.

Steps to reproduce the issue:
1. Create a fresh db in v17 and install the accounting app with demo data
2. Navigate to the General Ledger and select tomorrow as a starting date
3. Export the report as an XLSX file
4. Some accounts are missing in the XLSX file and the report is unbalanced

Tickets:
opw-5868482
opw-5787298