*: im_livechat, mail, point_of_sale, pos_self_order, web, website_livechat.

When the client subscribes to new channels, it passes its last known
notification id as the starting point of the stream.

For the very first connection, the last id defaults to 0. In this case,
the server replays notifications from the last 50 seconds. This
heuristic can lead to missed notifications (e.g. if the WebSocket fails
to connect and retries exceed the window), or to a large useless
dispatch when reconnecting after a long period of inactivity.

This commit fixes both issues by having the client always start from an
explicit, known-good id instead of 0.

A topic fetches notifications starting from the lowest last id among
its subscribers. If a single subscriber joins with 0 as its last_id,
that 0 becomes the lower bound for the whole topic, and the 50s
heuristic then applies to everyone sharing it, possibly excluding
notifications the topic still needed. Providing a real id also fixes
this issue.

follow-up of task-5449503

enterprise: https://github.com/odoo/enterprise/pull/128917

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

Fetch-button and matching UX improvements for e-Dispatch (receipts & deliveries), plus a fix to commercial (TICARIFATURA) invoice status handling and its response banner on account.move.

## Current behavior before PR:

- "Upload e-Dispatch (XML)" is only available as a list-view toolbar button.
- There is no single action to fetch e-Dispatch XMLs and then their PDFs.
- "Update From GİB e-Dispatch (XML)" shows even when no XML is linked to the receipt.
- Updating a receipt from its XML does not (re)fetch the matching Nilvera PDF.
- Outgoing deliveries do not fetch the Nilvera PDF on status synchronization.
- Fetched XML attachments are hard to match (no customer name in the name).
- Commercial (TICARIFATURA) invoices that succeed without a recipient answer never reach the "succeed" status, and the commercial response banner (awaiting / approved / rejected) does not display correctly.

## Desired behavior after PR is merged:

- "Upload e-Dispatch (XML)" is moved to the Actions menu on the list view.
- A new "Fetch e-Dispatches" action fetches the XMLs and then the PDFs, in order (receipts and deliveries).
- "Update From GİB e-Dispatch (XML)" is hidden until an e-Dispatch XML is linked.
- Updating a receipt from its XML (re)fetches the matching Nilvera PDF.
- Outgoing deliveries fetch the Nilvera PDF (via the Sale channel) on a successful status sync.
- Fetched XML attachments carry the customer name for easier matching.
- Commercial invoices persist "succeed" while awaiting the recipient's answer, and the awaiting / approved / auto-approved / rejected banners display correctly.

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

Enterprise PR: odoo/enterprise#127664

[REF] web: rename the webIcon "iconClass" key to "icon"
---
__Before this commit__

- The `webIcon` object built from `ir.ui.menu.web_icon` exposed its first
  part as `iconClass`, a leftover from the FontAwesome era.
- Since the Material Symbols migration that part is a `data-icon` name,
  not a class: every reader passes it to `t-att-data-icon`.

__After this commit__

- The key (and the local variables around it) is named `icon`.

[IMP] html_editor: shorten icon search debounce
---
__Before this commit__

- `SearchMedia` hardcoded a 1000ms debounce, so the icon picker waited a
  full second after each keystroke before searching.

__After this commit__

- `SearchMedia` accepts an optional `delay` prop (still 1000ms by
  default, leaving the file/image selectors untouched).
- `IconSelector` passes `delay="250"` for a snappier pictogram search.

[IMP] html_editor, web: move ms icons list in backend
---
__Before this commit__

The Material Symbols list used by the media dialog's icon picker was a
generated JS module of ~152 KB for 446 icons, shipped in the assets
bundle to every browser on every page load. Most of that weight is the
`tags` search terms, only ever used to filter the list when the user
types in the picker.

__After this commit__

`generate_icons.py` writes a Python `MS_ICONS` dict in
`html_editor/controllers/ms_icons.py` instead of a JS module, and the new
`/html_editor/material_symbols_search` route searches it server-side
against a `name tags` index built once at import. It returns only
`{name, has_fill}`, so the tags never reach the browser.

The picker fetches the full list on start, then one filtered list per
search. Odoo UI icons (`oi_*`) are still read from the CSS rules and
searched client-side, since they are cheap to discover there.
`MediaDialog` rebuilds the pre-selected icon from the element's
`data-icon` attribute instead of looking it up in the full list.

[FIX] web, mail: make the icon font generation reproducible
---
__Problem__
Two runs of `addons/web/tooling/icons/generate_icons.py` on an unchanged
`icons_wishlist.txt` produce different font files, so a diff on those
binaries tells nothing about whether the icons actually changed.

__Reason__
- `detect_filled_variants` returns a `set`, whose iteration order varies
  from one process to the next (string hash randomization).  That order
  is what gets handed to `fontext` as its ligature list, and `fontext`
  numbers the glyphs it keeps in the order it is given them, so the
  filled half of `glyf` is reshuffled on every run -- 242 of the 717
  glyphs.
- `fontext` stamps `head.created` / `head.modified` with the current
  time, and the `TTFont` reading its output recomputed `modified` once
  more on save.

__Quick fix__
Sort the suffixed icon names before subsetting, and date the fonts only
when their content actually changed: `save_font` compares the newly built
font with the one already on disk, both with their `head` dates equalized,
and rewrites the same bytes when they match.  `created` is kept for the
lifetime of the file, `modified` only follows a real change.

Rebuilding on an unchanged wishlist now leaves every generated font
untouched, so any diff on them means the icons really moved.  The WOFF1
fallbacks and the `_pua_cmap` font are regenerated here, as they still
carried the old glyph order.

Customer credit/debit notes are often issued to adjust prices without any movement
of goods, for example, for a discount, rebate, or price revision without any change in
quantity.

This PR introduces an Adjustment Type field on customer credit/debit notes with two
options:

 - **Standard:** Used when the adjustment involves a change in quantity, such as goods
   returned, cancelled service contracts, or additional goods supplied.
 - **Price Adjustment:** Used when the adjustment only changes the amount, with no
   change in quantity, such as a discount, rebate, or price revision.

This distinction allows GST filing, EDI, and sales documents to correctly reflect whether
an adjustment involves movement of goods or is purely a value correction.

Changes included:

 - Add an Adjustment Type field on credit/debit notes.
 - Add the Adjustment Type field to the invoice report so users can clearly identify the
   type of credit/debit note.
 - Add Adjustment Type field on account move reversal wizard   
 - For Price Adjustment moves, the EDI reports quantity and unit price as zero on each
   line while preserving the actual taxable value and tax amounts.
 - Exclude Price Adjustment moves from invoiced quantity computation in sales documents.
  
  task-6370202

Related enterprise Pr - https://github.com/odoo/enterprise/pull/126929
Related Upgrade Pr - https://github.com/odoo/upgrade/pull/11013

Community PR: odoo/odoo#278149

[IMP] web_studio: use the html_editor icon selector
---
__Before this commit__

- Studio had its own icon picker (`StudioIconSelector`), a `SelectMenu`
  built on top of `IconSelector.initFonts()`. That helper is gone: the
  Material Symbols list now lives in the backend and the html_editor
  `IconSelector` fetches it on demand, so the whole list is no longer
  available client-side to feed a `SelectMenu`.

__After this commit__

- The Studio component is dropped and the html_editor `IconSelector` is
  reused directly, wrapped in a `Dropdown` in both places that picked an
  icon: the app icon creator and the "add a button box" dialog.
- The selection to highlight in the grid is rebuilt from the icon name
  alone, the same way `MediaDialog` does it since the list is fetched
  lazily.
- The picker also offers the filled variant of the icons. It is stored by
  suffixing the icon name with "_f", which is the ligature of the filled
  glyph in the font: no renderer has to know about it.

[REF] web_enterprise, web_studio: rename "iconClass" to "icon"
---
__Before this commit__

- The app icon name was carried around as `iconClass`, from the
  `webIcon` object down to the `IconCreator` prop, a leftover from the
  FontAwesome era.
- Since the Material Symbols migration that value is a `data-icon` name,
  not a class: every reader passes it to `t-att-data-icon`.

__After this commit__

- The key and the prop are named `icon`.

Description
===========

The bank reconciliation widget sends the bulk "Set Account" action as a single RPC, but the server still processes most of the work separately for every selected statement line.

Each iteration searches for recent statement lines and reconciliation models, writes the account on one move line, and posts its matching confirmation independently. The cost therefore grows linearly with the selection size.

Cache reconciliation-rule lookups for the duration of the bulk operation, while updating the cache when rules are created or deleted.

Also assign the account to all selected move lines in one recordset write, avoiding frequent calls to `_compute_reconciled_payment_ids` 1 by 1.

Finally, collect the lines requiring a matching confirmation and create their chatter entries in one batch.

Benchmark
=========

The benchmark measures one server-side bulk Set Account call; fixture creation is excluded from the timings.

| Selected lines | Before | After | Improvement      |
|----------------|--------|-------|------------------|
| 500            | 12.5 s | 2.5 s | 5x faster (-80%) |

Benchmark data cardinality:

- 1 company
- 1 isolated bank journal
- 3 accounts: liquidity, suspense, and target expense
- 500 unreconciled bank statement lines
- 500 suspense move lines passed to the method, one per statement line
- 1 target account shared by all selected lines
- 1 journal/company/account cache group
- 1 batched call, executed sequentially in one cursor
- Negative amounts, avoiding automatic bank-fee rule creation
- 500 distinct references shorter than 10 characters, preventing a new reconciliation model from being created
- No taxes on the target account

Blueprint
=========
```xml
<?xml version="1.0" encoding="utf-8"?>
<odoo>
    <!--
        ==========================================================
        BENCHMARK: Bulk Set Account on Bank Statement Lines
        ==========================================================
        Creates 500 unreconciled statement lines in one isolated bank
        journal, then calls set_account_bank_statement_line() once on the
        whole recordset, as the bank reconciliation widget's bulk action does.

        Negative amounts bypass the unrelated bank-fee rule path. Distinct
        labels shorter than 10 characters prevent an automatic reconciliation
        model from being created during the run. Without the bulk cache, the
        first line only runs the history search and every subsequent line runs
        both searches in _check_and_create_reconciliation_rule(). This keeps
        the query-count regression visible without changing the scenario.
    -->
    <record id="benchmark_bulk_set_account_bank_statement_line" model="populate.blueprint">
        <field name="name">Benchmark: Bulk Set Account on Bank Statement Lines</field>
        <field name="definition_xml" type="xml">
            <create model="account.account" count="1" id="bench_bulk_set_account_liquidity" scale="False" parallel="False">
                <value name="counter" generator="misc.counter" start="1"/>
                <field name="name" eval="f'Benchmark Bulk Set Account Liquidity {counter}'"/>
                <field name="code" eval="f'BSAL{counter:03}'" unique="True"/>
                <field name="account_type" eval="'asset_cash'"/>
            </create>

            <create model="account.account" count="1" id="bench_bulk_set_account_suspense" scale="False" parallel="False">
                <value name="counter" generator="misc.counter" start="1"/>
                <field name="name" eval="f'Benchmark Bulk Set Account Suspense {counter}'"/>
                <field name="code" eval="f'BSAS{counter:03}'" unique="True"/>
                <field name="account_type" eval="'asset_current'"/>
            </create>

            <create model="account.account" count="1" id="bench_bulk_set_account_target" scale="False" parallel="False">
                <value name="counter" generator="misc.counter" start="1"/>
                <field name="name" eval="f'Benchmark Bulk Set Account Target {counter}'"/>
                <field name="code" eval="f'BSAT{counter:03}'" unique="True"/>
                <field name="account_type" eval="'expense'"/>
            </create>

            <create model="account.journal" count="1" id="bench_bulk_set_account_journal" scale="False" parallel="False">
                <value name="counter" generator="misc.counter" start="1"/>
                <field name="name" eval="f'Benchmark Bulk Set Account Journal {counter}'"/>
                <field name="code" eval="f'BSA{counter:03}'" unique="True"/>
                <field name="type" eval="'bank'"/>
                <field name="default_account_id" ref="bench_bulk_set_account_liquidity"/>
                <field name="suspense_account_id" ref="bench_bulk_set_account_suspense"/>
            </create>

            <create model="account.bank.statement.line" count="500" id="bench_bulk_set_account_statement_lines" scale="False" parallel="False">
                <value name="counter" generator="misc.counter" start="1"/>
                <field name="journal_id" ref="bench_bulk_set_account_journal"/>
                <field name="date" eval="'2026-08-18'"/>
                <field name="payment_ref" eval="f'{counter:08x}'"/>
                <field name="amount" eval="-100.0"/>
            </create>

            <function model="account.bank.statement.line"
                      name="set_account_bank_statement_line"
                      ref="bench_bulk_set_account_statement_lines"
                      batched="True"
                      parallel="False"
                      context="{'account_default_taxes': True}">
                <value name="journal_id"
                       generator="relation.one"
                       comodel_name="account.journal"
                       ref="bench_bulk_set_account_journal"/>
                <value name="suspense_account_id"
                       generator="relation.one"
                       comodel_name="account.account"
                       ref="bench_bulk_set_account_suspense"/>
                <arg eval="[
                    line.line_ids.filtered_domain([
                        ('account_id', '=', suspense_account_id),
                    ]).id
                    for line in model.search([
                        ('journal_id', '=', journal_id),
                    ], order='id')
                ]"/>
                <arg generator="relation.one"
                     comodel_name="account.account"
                     ref="bench_bulk_set_account_target"/>
            </function>
        </field>
    </record>
</odoo>
```

Reference
=========
task-6480127

A price set manually on an order line is typed in the tax mode the prices are displayed in. It was then inverted through the taxes to recover a price expressed in the tax mode of the taxes, and that result was rounded to the "Product Price" precision before being stored. With a "Tax-Included Price" display, typing 100 on a product taxed at 15% stored 100 / 1.15 = 86.9565... as 86.96. The residual rounds away at a quantity of 1, but it is multiplied by the quantity, so 2 units total 200.01 and 10 units total 1000.50.

This commit stores the typed price as it was typed and adds a `document_tax_mode` field on the order line holding the tax mode that price is expressed in. The mode is passed when the base line is created, in the frontend as well as in the backend, so the taxes engine resolves the price inclusion per tax instead of the price being converted beforehand. It is reset as soon as the price is recomputed, so any other price keeps following the tax configuration of the product, and it is carried over to refund lines so that a refund matches what was sold.

task-6472425

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