### Issue before this commit:
When generating a tax closing entry for France, the VAT credit carryover from the previous period is missing from the journal entry lines.

### Steps to reproduce the issue:
1. Download Accounting and l10n_fr
2. Go to Vendor > Bills
3. Create a vendor bill with date in June and price > 0 (ex. 1000$) and the 20% G tax that produce a 200$ VAT tax
4. Go to Customers > Invoices
5. Create an invoice with price > 0 (ex. 9000$), the date in July and the 20% G tax that will produce a 1800$ VAT tax
6. Go to Tax Return and validate all opened months up to July and see that for June the balance is -200$
9. Then go to View Entries of July using the 3 dots next to the "submit" button and see that there is no mentioning of the 200$ carry over of credit from the month before

### Cause of the issue:
The issue stems from a structural change in the core code where the logic to evaluate and balance the tax receivable account was removed from the _add_tax_group_closing_items method. Consequently, the VAT closing entry now only processes the current period's taxes and there is no reporting of any carried-forward VAT credits.

### Reason to introduce the fix:
French accounting rules strictly require the carried-forward VAT credit to be explicitly integrated into the current period's tax closing entry.

opw-6438648

### Issue:
When an analytic plan has applicability lines with a company filter, the applicability is incorrectly applied on views that do not define a `business_domain`, such as Work Centers or Employee views

For example, if a plan has:
- Default Applicability: Unavailable
- A line with Domain: Invoice, Company: My Company, Applicability: Mandatory

Opening the analytic distribution on a Work Center shows `Mandatory` instead of the default `Unavailable`

### Cause:
In commit https://github.com/odoo/odoo/commit/ffcf2ee1a3185ef73db93bfd95625844506692c5 `_get_score` was updated to return `0.5` when the applicability line's company matches the caller's company, even when no `business_domain` is provided

In `_get_applicability`, the loop selects the first rule whose score exceeds the current minimum, which starts at `0`:
https://github.com/odoo/odoo/blob/710e056e5171af2ab72d7d7793da3518f12faf5e/addons/analytic/models/analytic_plan.py#L255-L264

A score of `0.5` is enough to win over the default applicability, so a company-only match on a domain-specific rule incorrectly overrides the default when no `business_domain` is passed

### Steps to reproduce:
- Install `mrp` and `accountant` with demo data
- Enable Analytic Accounting in Settings
- Open the Internal analytic plan and edit its applicability line:
  -- Remove the account prefix
  -- Default Applicability: Unavailable
  -- Domain: Invoice, Company: My Company (SF), Applicability: Mandatory
- Go to Manufacturing > Configuration > Work Centers
- Open any work center and click on Analytic Distribution

Before the fix, Internal is shown as Mandatory instead of Unavailable
Removing the company from the applicability line confirms the issue

opw-6404884

Forward-Port-Of: odoo/odoo#280312

Version:
--------
- 19.0+

Steps to reproduce:
-------------------
- Install `quality_control` module
- Create a picking order with a product
- From the gear menu, create an on-demand Quality Check
- Set the check to *Control per Quantity* and back to the picking
- Set the done quantity to 10
- Open the Quality Check wizard
- Try to fail 3 units

Issue:
------
Validating the partial failure raises a `ValidationError`:

    - Missing required value for the field 'Team' (team_id)

The quality check split is not performed and the picking cannot be processed.

Cause:
--------
Quality checks created on-demand from the picking (via the gear menu) have 
no associated `quality.point` or `stock.move.line` — only 
`picking_id` is set at creation time.

https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/quality.py#L457

In `_move_to_failure_location()`, the `move_line` branch assumes 
`check.move_line_id` is populated. Since it is empty for on-demand 
checks, the split logic operates on an empty recordset.

The new quality check for the split is then created via:

https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/quality.py#L493

At this point both `failed_move_line` (a copy of the empty move line) and
 `check.point_id` are empty. `_get_check_values(False)` cannot derive 
fields normally sourced from the quality point (`team_id`, `company_id`,
 `measure_on`, `test_type_id`, etc.), causing the `ValidationError` on record creation.

Fix:
----
- If the quality check is not linked to a move line, find the matching move line
 from the picking before splitting the failed quantity.

https://github.com/odoo/enterprise/blob/7d40d6b787511bf2fcbf581859ed2cd38ba3f658/quality_control/models/stock_move_line.py#L94-L97

- `_get_check_values()` normally takes values from a Quality Point. 
Since on-demand quality checks do not have one, fill the missing 
values (`team_id`,  `measure_on`) from the original quality check instead.

This allows manually created quantity-based quality checks to be 
split correctly after a partial failure.

---

opw-6428749

Forward-Port-Of: odoo/enterprise#126505

## Issue
When a use rmanually increases the invoiced quantity on a timesheet invoice, subsequent timesheets logged in future periods can no longer be invoiced. The system assumes that the most recent logged hours are already covered by the previously over-invoiced amount, blocking the billing of the most recent timesheet entries.

## Steps to reproduce
1. Install *Sales Timesheet* (`sale_timesheet`)
2. Create a Product P
    - Product Type: Service
    - Invoicing Policy: Based on Timesheets
    - Create on Order: (Project &) Task
3. Create an SO:
    - Customer: Any
    - Product: P (any quantity)
    - Confirm
4. Record hours on the task created:
    - 06/01/2026 (June 1st): 1 hour
    - 07/01/2026 (July 1st): 1 hour
5. Create the invoice for the June timesheet entry (by setting a timesheets period when creating the invoice), then **change the quantity to any value strictly greater than 2** and confirm.
6. Create the invoice for July
7. **An "Invalid Operation" error appears, stating that there's nothing to invoice, even though the timesheet entry from July was never invoiced.**

## Cause
Since https://github.com/odoo/odoo/commit/3b86ac3d180993239b63fd305ee0ba1f17f7eb20, the computation of the quantity to invoice changed to include the difference between the quantity delivered and the quantity already invoiced. In the flow described by the steps to reproduce above, the quantity to invoice is larger than the quantity delivered, making the `qty_to_invoice` equal to `0.0`.

https://github.com/odoo/odoo/blob/626d31fa0191bfe7ca8e1fcf177357eeeb60f2c7/addons/sale_timesheet/models/sale_order.py#L331-L334

The reason for the fix above being the partial refunding of timesheet-related invoices, we can keep that solution when working with refunded invoices, and keep the previous behavior for other cases.

This solution solves the issue in the steps to reproduce above, but was also manually tested on the issues from https://github.com/odoo/odoo/commit/3b86ac3d180993239b63fd305ee0ba1f17f7eb20 and https://github.com/odoo/odoo/commit/64cf4afabd0c5ef040cf87fc6f3125fe0bb81bbb.

opw-6485674

Forward-Port-Of: odoo/odoo#286116
Forward-Port-Of: odoo/odoo#284470

In Italy the periodic VAT return (LIPE) is filed quarterly, so `is_quarter_month` gates the XML export wizard on March, June, September and December. That field only looks at the date, never at the kind of return, so every Italian return locked on a quarter month was treated as a LIPE.

Submitting the withholding tax return therefore opened the LIPE export wizard. Depending on the record the wizard receives, it either crashes while reading the VP lines missing from the withholding report, or silently generates a LIPE file and attaches it to another return.

Add an `is_lipe_return` field telling whether the return actually produces the LIPE.

Steps to reproduce:
- Install `l10n_it_xml_export` and `l10n_it_edi_withholding_reports` on an Italian company with monthly returns
- Open Accounting > Reporting > Tax Return
- Review and submit the withholding returns up to February
- Review then submit the March withholding return --> The LIPE export wizard opens, and the export fails on the withholding report.

opw-6255016

Forward-Port-Of: odoo/enterprise#126676
Forward-Port-Of: odoo/enterprise#125263

Description of the issue/feature this PR addresses:

When `im_livechat` (or any page) boots the OWL web stack with no `[data-hotkey]` / `withOverlay` targets, pressing Alt still called `preventDefault()` in `hotkey_service`. That blocked browser shortcuts such as Alt+D (focus address bar) on websites that embed the livechat scripts.

See https://github.com/odoo/odoo/issues/267928

Current behavior before PR:

- Pressing the overlay modifier (Alt, or Ctrl on macOS mapped to `"alt"`) always set `overlaysVisible = true` and called `preventDefault()`, even when there were no hotkeys to overlay.
- A follow-up key (e.g. D while Alt is held) then also hit `preventDefault()` because overlays were considered visible.
- Loading `/im_livechat/loader/...` + `assets_embed.js` on an external site therefore broke browser Alt shortcuts.

Desired behavior after PR is merged:

- `addHotkeyOverlays` returns whether overlays were actually displayed.
- `preventDefault` on the overlay modifier runs only when there is at least one overlay target.
- Pages with no hotkeys (typical livechat embed) leave browser shortcuts alone.
- When hotkeys exist, Alt still shows overlays and cancels the default, same as before.

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

Forward-Port-Of: odoo/odoo#284145

Description of the issue/feature this PR addresses:

The unread counter feeding the PWA app badge is written to the `odoo-mail-unread-db`
IndexedDB database, through a connection opened once, at module load, and cached for the
life of the page by the bundled idb-keyval (3.2.0), which cannot reopen it. When the
browser drops the origin's storage (eviction under disk pressure, site data cleared, a
privacy extension purging it), that connection is closed for good, and as
`updateAppBadge()` discards the promise returned by `idbKeyval.set()`, the rejection
reaches the user as a client error dialog.

Reported in production on a backend tab left open overnight (Firefox, 19.0):

```
UncaughtPromiseError > InvalidStateError
Uncaught Promise > IDBDatabase.transaction: Can't start a transaction on a closed database
```

Reproduced on a demo database below, with `?debug=assets` so that the stack points at the
source: lines 23 and 24 of the vendored idb-keyval are the `db.transaction()` call of
`_withIDBStore`, on the connection cached at module load.

<img width="1600" height="590" alt="error-dialog-debug" src="https://github.com/user-attachments/assets/e2b1aa46-501a-43d4-b4c0-20def1f529ef" />

Current behavior before PR:

1. log into the backend and leave the tab open
2. in the devtools, Application > Storage, tick *only* "IndexedDB" and click "Clear site
   data", as the browser itself does when it evicts the origin (the session cookie is left
   untouched, so the tab keeps working)
3. receive a message, or do anything else that changes the unread counter

The dialog opens, and opens again on every counter update for the whole life of the tab,
since the dead connection is never replaced; the counter is not saved any more either.

Two variants of the same code: the write also rejects, without anything being cleared,
when the origin runs out of storage quota (`QuotaExceededError`), and when the browser
forbids storage for the origin, `indexedDB.open()` throws during module evaluation, so
`store_service_patch.js` fails to load entirely.

Desired behavior after PR is merged:

The store is opened lazily, dropped whenever saving the counter fails, and the write is
retried once on a new connection: a single counter update after the connection was closed
saves it again. Opening the database is guarded too, for the synchronous throw. When the
retry fails as well the error is ignored, the app badge being cosmetic.

`mail/static/tests/web/app_badge.test.js` covers the retry, the recovery of a permanently
closed connection, and the database that cannot be opened at all. The three tests fail on
the current code with the uncaught `IDBDatabase.transaction` error.

Introduced in 19.0 by c04c4cb715902fe95618a15e18233cd001bdb304, and identical from
saas-19.1 to master, hence this PR against 19.0.

The corporate CLA for ERPVibe Limited is submitted in #283477.

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

Forward-Port-Of: odoo/odoo#283480