### 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

## 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#286301
Forward-Port-Of: odoo/odoo#284470

Steps to reproduce the bug:
- Warehouse configured for 2-Step Manufacturing
- Component "C1":
    - Routes: MTO + Buy
    - Tracking: By Unique Serial Number
    
- Create a Finished product:
    - Route: Manufacture
    - Tracking: By Unique Serial Number
    - BoM:
        - component "C1": 1 unit
- Create and confirm the Manufacturing Order
- Generate/assign the serial number for the finished product immediately, before the related purchase order is even confirmed
- Confirm the Purchase Order
- Receive the component
- Transfer the component to WH/Pre-Production
- Click Produce All

Problem:
A Consumption Warning was displayed stating that the consumed quantity differs from the expected quantity, even though the consumed quantity was exactly equal to the BoM quantity and no manual quantity change was performed. Clicking "Set Quantities & Validate" completed the MO successfully, hiding the inconsistency.

`_get_consumption_issues()` only counts a raw move's quantity as "consumed" when `move.picked` is `True`
[(odoo/addons/mrp/models/mrp_production.py#L1791)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1791).
Generating the finished product's serial number calls `_set_qty_producing()` 
[(odoo/addons/mrp/models/mrp_production.py#L1402)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1402).
, which itself only sets `move.picked = True` when `move.quantity` is truthy 
[(odoo/addons/mrp/models/mrp_production.py#L1443)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L1443).

At that point the MTO component had not been received yet, so `move.quantity` was still 0 and `picked` was never set. Once the component was later received and transferred to Pre-Production, `_action_assign()` correctly reserved the raw move (`quantity` became correct), but nothing ever went back to flip `picked` to `True`, since `_set_quantities()` 
[(odoo/addons/mrp/models/mrp_production.py#L2932)](https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2932).

only calls `_set_qty_producing()` again when `qty_producing` is still falsy, which was no longer the case. `_get_consumption_issues()` therefore still counted the consumed quantity as 0 against the expected BoM quantity.

Solution:
In `pre_button_mark_done()`, for auto productions (single unit being produced), after `_set_quantities()` runs, also mark as `picked` any non-manual-consumption raw move that is not yet `picked` but whose reserved `quantity` already exactly matches its own `product_uom_qty`. This is scoped to auto productions only, since on a multi-unit production a raw move's aggregate `quantity` can equal its `product_uom_qty` by coincidence (reservation for future backorder steps) even though only part of it is meant to be consumed for the current step.

opw-6421531

Forward-Port-Of: odoo/odoo#285405
Forward-Port-Of: odoo/odoo#281258

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

Currently, an error occurs when the `sync_shopee_pickings` cron tries to fetch
shipment labels for multiple batches of shipments. If some shipments do not
contain the required data in the Shopee API response, the error causes the
cron to stop, preventing the remaining batches from being processed.

Error:
`ValueError: KeyError('status') while evaluating 'model._sync_shopee_pickings()'`

This issue was introduced by a recent refactoring commit [1] focused on linting
and formatting the Python file. The commit replaced the generic `Exception`
with `UserError` when handling errors during batch label printing.

As a result, errors other than `UserError` are no longer handled at the batch
level. When such an error occurs, the entire cron process stops instead of
failing only the affected batch and continuing with the remaining batches.

This commit fixes the above issue by handling generic `Exception` during
shipment label generation, ensuring that the error is handled for the
affected batch while the remaining batches continue to be processed.

[1]: https://github.com/odoo/enterprise/commit/cfe5d947579739ad770ac3f1525ce157af530846#diff-e072c3ecf980add685bb4a4f25cf2b0ab5d4625988e4afc2c4d4faeae687ca88R199

sentry-7685943988

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

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

Steps to reproduce:
-------------------
- Install `stock`, `purchase`, and `accountant`
- Create a storable product with:
  - Tracking Inventory enabled
  - Control Policy set to **Ordered Quantities**
- Create and confirm a Purchase Order with some unit price
- Do not receive or invoice the order
- From the Purchase Order gear menu, click **Accrued Expense Entry**

Issue:
------
The Accrued Expense Entry wizard opens, but no accounting lines are
generated.

For products invoiced on **Ordered Quantities**, the ordered quantity
should already be accrued even though nothing has been received.

Cause:
------
This issue was introduced after this changes [commit](https://github.com/odoo-dev/odoo/commit/81f25bc57b8433a65bf33950c64dc7582240a229)

Previously, the accrual wizard relied on the stored
`qty_to_invoice` field, whose computation already respected the
product's Control Policy.

For products invoiced on **Ordered Quantities**,
`_compute_qty_invoiced()` computes the quantity to invoice from the
ordered quantity:

https://github.com/odoo/odoo/blob/810a02a577c2811dc5c12f0abf45eebb9cf96d00/addons/purchase/models/purchase_order_line.py#L147-L152

The refactoring replaced this logic with the new
`amount_to_invoice_at_date` field, which always computes the invoicable
quantity as:

`qty_received_at_date - qty_invoiced_at_date`
https://github.com/odoo/odoo/blob/65dbcabcd243abf24d6d3c3788d2caff66485790/addons/purchase/models/purchase_order_line.py#L282-L285

This formula ignores the product's Control Policy.

For products invoiced on Ordered Quantities, before any receipt:

`qty_received_at_date` = 0
`qty_invoiced_at_date` = 0

therefore:

`amount_to_invoice_at_date` = 0

The Accrued Expense wizard filters out lines whose
`amount_to_invoice_at_date` is zero:

https://github.com/odoo/odoo/blob/65dbcabcd243abf24d6d3c3788d2caff66485790/addons/account/wizard/accrued_orders.py#L168-L178

As a result, the purchase order line is excluded entirely and the
wizard produces no accounting entries.

The same assumption is also used later in
`account.accrued.orders.wizard._compute_move_vals()` when computing
tax-included amounts, causing incorrect accrual values for
Ordered Quantities products whenever receipts and invoices differ.

Fix:
----
Introduce `_get_qty_to_invoice_at_date()`, mirroring the existing
purchase_method logic used by _compute_qty_invoiced().

The helper returns:

product_qty - qty_invoiced_at_date for Ordered Quantities
products;
`qty_received_at_date` - `qty_invoiced_at_date` for
Received Quantities products.

Now products invoiced on `Ordered Quantities` become
accruable as soon as the Purchase Order is confirmed;

---

opw-6290782

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

Forward-Port-Of: odoo/odoo#284507
Forward-Port-Of: odoo/odoo#276435

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