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

Before this commit, a meeting holding a Discuss video call link had no channel until someone opened `videocall_location`: the meeting was absent from the Discuss "Meetings" tab, and its invitation link only started working once an attendee joined the call. The one way to get a meeting out of Discuss was the "Meeting" button, which starts an ad-hoc group call with no date attached to it.

This commit gives such a meeting its channel upfront, on create and as soon as the link is added afterwards, and keeps the two in line:

- the channel is named after the meeting and describes when it takes place (the recurrence rule for a recurring meeting, its date and time otherwise), and is pinned for every attendee having a user, so the meeting shows in the "Meetings" tab of each of them;
- its avatar shows the day of the meeting rather than the day the channel was created, in the reader's own timezone;
- every occurrence of a recurrence shares a single channel, which only goes away with the last of those meetings;
- deleting a meeting takes its video call away, unless the channel already hosted a conversation: that one is only unpinned, so the chat history stays reachable from Discuss while the video call drops out of the tab.

The channel is resolved from the meeting the recurrence machinery left live, rather than from the edited record: editing a whole recurrence archives the occurrence it was asked from and moves the new values to a freshly recreated one, which would otherwise write back the values from before the edit.

The "Meetings" tab gains a "Planned" filter, keeping only the video calls backed by a meeting, and its "Meeting" button becomes a menu offering "Start Now" next to "Schedule for later", which opens a `calendar.event` form prefilled with a 30 minute Discuss video call. The button is a menu whatever the modules contributing to it, so that starting a meeting is always found in the same place. Scheduling is only offered in the webclient, as the form view it opens is not part of the public Discuss page.

Both calendar parts come from hooks defined on `MessagingMenu` itself, `extraTabActions` and `extraTabFilters`, rather than from the /discuss/ patch declaring the tab: a bundle contributing to a tab may be patched in before the one declaring it, which would then discard the override.

task-6460543




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

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

In the previous [PR](https://github.com/odoo/odoo/pull/267980) we introduced relative filters (such as `today`, `this week`, ...) and removed the hardcoded filters that duplicated them (`3e7106201cfe`), for example:

```xml
<!-- BEFORE (planning/views/planning_views.xml) -->
<filter string="Start Date" name="start_datetime" date="start_datetime" end_month="1">
    <filter name="start_today" string="Today" domain="[
        ('start_datetime', '&lt;', 'today +1d'),
        ('start_datetime', '&gt;=', 'today'),
    ]"/>
    <filter name="start_this_week" string="This Week" domain="[...]"/>
    <filter name="start_next_week" string="Next Week" domain="[...]"/>
</filter>

<!-- NOW -->
<filter string="Start Date" name="start_datetime" date="start_datetime"/>
```
However this would now break if trying to target the new relative filter: 

```xml
<field name="context"> { 'search_default_start_datetime': 'custom_start_today' }</field>
```

(This example was not in production code but this PR tried to do it, and it broke on rebase: 
 https://github.com/odoo/enterprise/pull/125775)

In this PR we make it so that relative filters (not only today) can be activates through context keys and `default_period=`. We also make a number of small improvements / refactoring and 1 localisation fix.

**Commit 1** - [REF] web: tidy relative filter internals

- Make filter and option lookups throw on an unknown id instead of returning `undefined` and failing later.
- Centralize the "period + year" concatenation in one `joinWithYear` helper (2 call sites, one from the previous PR).
- Build `displayedFilterItems` in a single pass, attaching each date filter's relative twin to it.
- Drop a missed hardcoded "Today" in `stock_fleet`'s batch transfer view.
- Re-add the four range attributes to the RNG as deprecated-but-accepted, so a custo view no longer crashes.
(Will do a follow-up PR with an upgrade script to remove it)

**Commit 2** - [IMP] web, base: smart dates as date filter defaults

- Accept relative option ids in both `default_period` and `search_default_<filter>` (`today`, `this_week`, `this_month`, `this_quarter`, `this_year`).

**Commit 3** - [FIX] web: use the active numbering system for hand-built date labels

- The week number of the `formatLocalWeekRange` was not being translated to locale numbering system.

**Enterprise commit** -  [REM] helpdesk, frontdesk: drop Today filters duplicating the smart date

- Remove the Today filters on Closed On / Creation Date / Rated On (helpdesk) and next to Date (frontdesk), that are redundant with the relative filters we introduced in the previous [PR](https://github.com/odoo/odoo/pull/267980)

Follow up to: https://github.com/odoo/odoo/pull/267980
Enterprise: https://github.com/odoo/enterprise/pull/128934

Commit[^1] moved the badge's overlap styling out of a SCSS rule scoped to `.o_hr_employee_form_view … .o_employee_avatar` and into `additionalClasses` on the field registry entry. Those classes are applied unconditionally, so `position-absolute top-0 end-0 bg-light rounded-circle` leaked into every usage of the widget.

On the kanban card the field sits in a non-positioned `float-end` div, so the badge resolved against `.o_kanban_record` and pinned itself to the card corner as a grey disc. A later commit papered over the symptom with `mt-1` (Commit[^2]), removed here.

The overlap styling goes back to SCSS, scoped to `.o_employee_avatar` — the container marking the three "badge over picture" layouts, including the enterprise wizard the original rule missed. Also drops a `margin: unset !important` kanban rule left inert since the same refactor.

task-6487546

[^1]: https://github.com/odoo/odoo/commit/dc8f38b1054664a0e382530bb4fc73983e2085cb
[^2]: https://github.com/odoo/odoo/commit/fbae74ab0c6fa1d8fc0789b27bd60062a5bd29bf


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

**Problem:**
Starting the timer on a task that is linked to a sale order item produces a timesheet that is not linked to it, and the Billable toggle is missing from the timer.

**Steps to reproduce:**
1. Install Timesheets and Sales
2. Open a task whose Sales Order Item is set
3. Start the timer from the Timesheets systray
4. Save it and open the resulting timesheet

**Current behavior:**
The Sales Order Item is empty. The Billable toggle only appears after removing and re-adding the task in the timer.

**Expected behavior:**
The timer is billable on the task's sale order item as soon as it is opened.

**Cause of the issue:**
`_get_timesheet_pre_filled_form_data` returns only `project_id` and `task_id`. The timer form merges that pre-fill over `timesheet_default_values`, which `lazy_session_info` computes once per session from `account.analytic.line.new()`
- a record with no project and no task, so `so_line`, `allow_billable` and `has_available_so` are all `False` in it. Because the pre-fill carries none of those keys, they keep the task-independent session values: the timesheet stays unlinked from the sale order item, and the Billable toggle stays hidden since it is displayed from `has_available_so`.

**Fix:**
The pre-fill endpoint is the only place that knows which task the timer is being opened on, so it is where the task-dependent values have to be resolved. Reading them off a new timesheet built with that project and task keeps the endpoint generic - it returns whatever `_get_aw_timesheet_fields_specification` declares, so the sale fields stay owned by sale_timesheet_enterprise rather than being named in timesheet_grid.

Dropping the session defaults instead was rejected: they are also the only source of `date`, `user_id` and `company_id` for the timer record, and removing them makes saving fail on the required Date field.

opw-6423577

Forward-Port-Of: odoo/enterprise#127800

### Steps to Reproduce:
1. Create a sign request and have 3 total signers (User, Customer, Employee)
2. Enable Signing Order and make the order as follows: (1) User, (2) Customer, (3) Employee
But make the User and Employee the same contact
3. Send and sign the request > Notice that (1) is able to sign for (3) immediately after, (2) has not signed yet.

### Description of the issue/feature this PR addresses: 
**Issue:** The signing order is ignored when the same user has to sign multiple times on a document, even if it is configured for a different person to sign in between. This happens because all signature request items are initialized in the 'sent' state upon creation, rather than strictly advancing based on the order. As a result, the system prematurely allows users to sign out of order and prompts them with their next turn too early.

**Solution:** To resolve this,  the controller was updated to include an `is_mail_sent = True` domain filter. This ensures that the UI's post-sign popup only displays documents where it is explicitly the user's active turn, rather than prompting a premature sign.

### Current behavior before PR: 
Users are able to sign prematurely, and the system will disregard the configured signing order.

### Desired behavior after PR: 
Users will only be prompted and able to sign a document when it is explicitly their turn, per the `mail_sent_order`. This way, documents are signed in order.

opw-6417327

Forward-Port-Of: odoo/enterprise#128487
Forward-Port-Of: odoo/enterprise#125573

## Problem
If multiple valuation/variation accounts are used, the Inventory Valuation report will not show the balance of accounts attached to products that have 0 quantity available if a different account has quantity.

## Solution
In order to maintain the performance improvements intended by the commit that introduced the `qty_available != 0` filter, we will avoid calculating `total_value` for products with 0 quantity. We will still run `stock_accounting_value` on these products in order to capture interim accounting value on the Inventory Valuation report.

## Steps to Reproduce (Runbot v19)
(defer to the test for more info)
1. Create an extra set of valuation/variation accounts
2. Create a product, avco perpetual accounting the default valuation/variation accounts
3. Create a second product, avco perpetual accounting the new valuation/variation accounts
4. Purchase 1 unit of each of the products and receive, bill both
5. Sell 1 unit of the product attached to the new valuation/variation
6. Go to Accounting > Review > Inventory Valuation, and note that the new valuation/variation accounts are not present. If you click Generate Entry, you will see that these accounts need to be balanced

opw-6473319

Forward-Port-Of: odoo/odoo#283787
Forward-Port-Of: odoo/odoo#282819

The aim of this commit is to allow customer to make their batch payment
without facing a Traceback.

Context:
odoo/enterprise@35f5341b9b44cc16eaea311295a064189dd802cb introduced bug
during a badly handled forward port.
The method was removed in saas-18.3 in favor of a function. The forward-port
was half handled and now surfaces to Odoo's own production.

Generating a batch payment could generates the following Traceback:
```py
  File "/home/odoo/src/enterprise/saas-19.3/account_iso20022/models/account_journal_sepa_ct.py", line 69, in _get_PstlAdr
    return super()._get_PstlAdr(partner_id, payment_method_code)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.3/account_iso20022/models/account_journal.py", line 501, in _get_PstlAdr
    CtrySubDvsn.text = self._sepa_sanitize_communication(partner_address['state'][:35])
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'account.journal' object has no attribute '_sepa_sanitize_communication'
```

Task-id: None (internal issue)

Forward-Port-Of: odoo/enterprise#129084
Forward-Port-Of: odoo/enterprise#129006

**Steps to reproduce:**
- Make a rounding method, Nearest and 0.05 of rounding
- Make a product that costs $4.99, don't set a tax
- Go to the PoS
- Order the product
- Before paying click the +10 button, then pay
- The rounding line is not present on the ticket

**Why the fix:**

When making a normal rounded purchase, by just clicking the "Cash" button, the rounding line will be displayed.

This is because we do not try to apply the rounding if the rounding of the remaining is not equal to zero.
https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/point_of_sale/static/src/app/models/accounting/pos_order_accounting.js#L118-L123

When we try to over pay, the remaining will be negative by the amount we overpay, so the amount will be set to zero, and the rounding will not be set.

We now take the amount we overpay into account, and deduct it from the amount we paid to then correctly compute the remaining amount without having to deal with the amount overpaid.

Some tests were not taking the rounding as it was not working correctly, so it has now been changed now that it works as it should.

opw-6025807

Forward-Port-Of: odoo/odoo#283413
Forward-Port-Of: odoo/odoo#256117

Steps to reproduce
---
1. Install Sales (with Margins) and Project, and open a billable project linked to a sale order.
2. From the project's Expenses view, create an expense paid by the Company and post it.
3. Open the project's Actual Margins: the expense shows under Other Revenues as a positive amount.

Issue
---
Creating an expense from a project's Expenses view keeps `project_id` in the context until its journal entry is built. For a company-paid expense that entry is a payment, and `AccountMoveLine._compute_analytic_distribution` puts the project's analytic distribution on every line that is not receivable or payable, which also covers the Outstanding Payments liquidity line. An analytic amount is the opposite of the move line balance, so the negative liquidity balance becomes a positive analytic line, classified as Other Revenues, on top of the real cost already booked on the expense account.

The receivable/payable filter from b6200026ecf1 narrowed the override introduced in ac1995ad6ddf but ignored the liquidity counterpart of a payment; since only profit and loss lines make up a project margin, restricting the distribution to `income` and `expense` accounts keeps the settlement line out of the report.

https://github.com/odoo/odoo/blob/f037dead17eb6a74d1ea9c56b0861b285be17516/addons/sale_project/models/account_move_line.py#L10-L19

opw-6326551

Forward-Port-Of: odoo/odoo#283938
Forward-Port-Of: odoo/odoo#273273

When a relational property has a domain the server cannot evaluate, opening its definition editor crashes. The editor calls search_count on that domain to show how many records match, both when it opens and on every later render. The server raises a ValueError and the call has no error handling, so the whole editor goes down. The bad domain stays saved on the property, so reopening the editor fails the same way and the property can no longer be edited or deleted.

Wrap the search_count call in _updateMatchingRecordsCount (property_definition.js) in a try/catch and show no count when it fails. This is the only place the editor counts matching records, so guarding it here handles a bad domain from any source, the field selector or the code editor. The field selector still shows its warning on the invalid path, so the user can fix or delete the property.

Steps to reproduce:
1. On a model that has a Properties field, add a Many2one property and set its Model to a model that itself has a Properties field.
2. Open the property Domain and click New Rule.
3. In the field selector pick the Properties entry, then close the selector.

=> An error dialog appears and the property can no longer be edited or deleted.

Ticket [link](https://www.odoo.com/odoo/project.task/6101311)
opw-6101311

Forward-Port-Of: odoo/odoo#283802
Forward-Port-Of: odoo/odoo#259886

Problem:
When using horizontal groups in Aged Receivables / Aged Payables reports, the amounts shown in the Older periods are incorrect.

Steps to reproduce:
1. Activate debug mode
2. Go to Accounting > Configuration > Horizontal Groups
3. Add a new horizontal group that results in at least 2 groups
4. Go to Accounting > Reporting > Aged Receivables / Aged Payables
5. Apply the horizontal group created
6. Notice how the amount in the Older period is incorrect, different from before applying the horizontal group. (It may be coincidentally correct, you can check by applying different aging intervals until you find one that shows the issue)

Cause:
The periods were not correctly calculated. The number of periods was calculated based on the number of period columns, without taking into account the number of column groups. When using horizontal groups, period columns are duplicated for each group that exists after applying the horziontal group. This is not considered when calculating the number of periods, which results in calculating too many periods and therefore having incorrect durations for each period.

opw-6374639

Forward-Port-Of: odoo/enterprise#127570

Steps to reproduce:
---------------------------
1. Install `sale_planning` with demo data.
2. Create a SO with a planning product, set the quantity to 100 hours, and confirm the SO.
3. Click the "To Plan" button, then click "Auto Plan".
4. Make sure the "Month" filter is selected in the scale options and observe the planned slots.

Issue:
--------
When auto planning slots for a month, the last day of the month is excluded. For example, slots are scheduled only until July 30th, even though July 31st is a working day.

Cause:
--------
While preparing the context, `stopDate` is set to July 31st at 00:00. It is then passed to [serializeDateTime()](https://github.com/odoo/odoo/blob/dacaad91bba8f959daf5d89a046c5a1c11e48eec/addons/web/static/src/core/l10n/dates.js#L553-L560), which converts the datetime to UTC. Depending on the user's timezone, this can shift the date to the previous day, causing the last day of the month to be excluded.

Solution:
------------
Use `localEndOf()` to set `stopDate` to the local end of the selected range before passing it to `serializeDateTime()`. This ensures the last day of the month is preserved during UTC conversion.

**NOTE:**
Forward-port the solution from the 18.0 version, which was adapted to the publish shift use case in 18.3 and introduced this issue. Add a HOOT test case to prevent this regression in future versions.

References: [18](https://github.com/odoo/enterprise/commit/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e) and [saas-18.3](https://github.com/odoo/enterprise/commit/c81fba31780869940f726b695ad46a87f69798fb)

opw-6391495

Forward-Port-Of: odoo/enterprise#128775
Forward-Port-Of: odoo/enterprise#127950

Steps to reproduce:
-------------------
1. Install `l10n_mx_edi_pos` and set the company to Mexico.
2. In PoS, make an order with one product and pay it.
3. Open the order in the backend, click "Return Products" to make a refund, but don't pay it, cancel it instead.
4. From the same order, click "Return Products" again to make a second refund, and pay it normally.
5. Go to the orders list, select the main order and the paid refund (not the cancelled one), then Actions > Create Global Invoice.

-> Observation: error in the global invoice.

In the CFDI tab of the main order the line is "Send Global In Error", and hovering on it the detail says "Failed to distribute some negative lines".

Why:
----
When we make the global invoice, we remove the refunds from the order. A cancelled refund was never paid, so we should not count it. But we were counting it too. So we removed the refund amount twice in our case, one for the paid refund, and one for the cancelled one, and we end up with an order with negative amount that cannot be distributed.

The fix:
--------
We now skip the cancelled orders when we search the refunds, the same way it is done above when we collect the refunded orders.

opw-6261404

Forward-Port-Of: odoo/enterprise#128026
Forward-Port-Of: odoo/enterprise#120996

# Summary

Fixes incorrect rendering of Arabic/Persian/Hebrew (RTL) text in generated PDFs, especially when mixed with Latin digits or English (LTR). Uses python-bidi to compute display order and introduces a safe fallback when that dependency isn’t available.

# Problem

- RTL strings were displayed in reverse order in PDFs.
- Mixed content (e.g., Arabic + numbers/English) produced garbled ordering.
- Existing logic flipped text only when the first character was RTL and no LTR chars existed, which broke mixed cases.

# Solution

python-bidi follows the Unicode Bidirectional Algorithm and correctly handles real-world mixed strings (Arabic + Latin + numbers + punctuation).

Fallback ensures no hard runtime breakage on instances where new dependencies is missing.

If python-bidi is missing, behavior is similar to previous “hotfix”:

- Pure RTL: reverse text for legible display.
- Mixed RTL/LTR: don’t reverse (favor readable English segments over fully correct RTL order).


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

The product specifications table is displayed whenever the product has tags, even if none of them are visible on the ecommerce website.

The product tags template filters out non-visible tags, but the surrounding table remains rendered and appears empty.

Only display the tags table when at least one tag is visible on ecommerce.

@Tecnativa TT63855

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

The condition used to display the product tags table considers all tags associated with the product, including those that are not visible on ecommerce.

**Current behavior before PR:**

When a product only has non-visible tags, the tags table is displayed without any content.

<img width="669" height="350" alt="image" src="https://github.com/user-attachments/assets/4758ea76-5186-4035-a065-aa4c71ce7053" />


**Desired behavior after PR is merged:**

The tags table is only displayed when the product has at least one tag visible on ecommerce.




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

Forward-Port-Of: odoo/odoo#282348
Forward-Port-Of: odoo/odoo#278604

Before this commit:
---

When [`absence_management`](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_attendance/models/res_company.py#L42) is enabled, a [scheduled action](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_attendance/models/hr_attendance.py#L645) automatically creates an attendance record at [**12:00:00 AM**](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_attendance/models/hr_attendance.py#L649) to mark negative extra hours for employees with missing attendance.

<img width="1147" height="474" alt="image" src="https://github.com/user-attachments/assets/833a4387-bc20-4bb7-817d-9ebe9afa7d71" />


If an employee later creates a leave covering this autogenerated attendance, the extra hours should be reset to `0`. However, this does not happen.

#### Video demonstration:
https://drive.google.com/file/d/1DTNQuQ3uV5nOUVMBazCDo0hBZbKJZUIW/view

This happens because the [domain](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_holidays_attendance/models/resource_calendar_leaves.py#L8) used to fetch attendances for [`_update_overtime`](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_holidays_attendance/models/resource_calendar_leaves.py#L34) compares the attendance `check_in` and `check_out` datetimes with the leave `date_from` and `date_to` datetimes.

The leave datetimes are aligned with the employee's working schedule. For example, if the working hours are **8:00 AM–5:00 PM**, the leave is stored from `{date, 8:00 AM}` to `{date, 5:00 PM}`. In contrast, the scheduled action creates the autogenerated absence attendance at **12:00:00 AM** (in the user's timezone). Since this attendance falls outside the leave datetime range, it is excluded from the domain, and `_update_overtime` is never called for it.

After this fix:
---

Instead of building the domain using the leave datetime range, the domain is built using the leave date range. This ensures that all attendances for the affected dates, including autogenerated absence attendances created at midnight, are included and their extra hours are updated correctly.

OPW: 6385811




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

Forward-Port-Of: odoo/odoo#281123

* = account_invoice_extract, l10n_nl_reports

Example of steps:
- Install web_studio and `accountant`
- Open the corresponding form view in Studio
- With debug mode toggle "Show invisible Elements" and edit
"Invisible" on the second partner_id field
- Traceback

`normalize()` compares the combined arch without the studio
customization to the one with it, in order to compute the smallest
possible set of xpaths. To do so, it calls `apply_inheritance_specs`
(the low-level function from `odoo.tools.template_inheritance`)
directly on the statically combined arch.

Some models add or duplicate nodes dynamically in `_get_view()`
(Python postprocessing, run after the static view combination). A
studio operation can target such a node, since it is what the user
actually sees and clicks on. But that node has no counterpart in the
purely static combined arch used by `normalize()`, so
`apply_inheritance_specs` raises a ValueError.

`edit_view()` only catches `ValidationError` to fall back to an
un-optimized (but valid) studio arch instead of failing the request.
Since the low-level function raises a plain `ValueError` here, that
fallback never triggers, and the exception is not caught anywhere.

To fix this, we will keep the behavior from version 18.0 and catch the
ValueError raised by `apply_inheritance_specs` in
`normalize_with_keyed_tree` and re-raise it as a ValidationError, like
`ir.ui.view.apply_inheritance_specs` already does elsewhere. This lets
`edit_view()`'s existing fallback handle the case gracefully instead
of crashing.

Additionally, the two models responsible for the dynamically-added nodes
described above are fixed at the source. `account_invoice_extract`'s
duplicated `partner_id` field and `l10n_nl_reports`'s injected
`company_id` field are now marked with `data-used-by`, the same
attribute `_add_missing_fields` already sets in `ir_ui_view.py` for the
fields it adds.
Studio already skip rendering and computing xpaths for any node carrying
this attribute (since https://github.com/odoo/enterprise/pull/92862),
so these nodes are no longer exposed to the user and can no longer
produce a studio operation that `normalize()` is unable to locate.

opw-6332911

Forward-Port-Of: odoo/enterprise#127009
Forward-Port-Of: odoo/enterprise#122829

**Description of the issue/feature this PR addresses:**
----------------------------------------------
Currently, in Discuss > Channels, pressing the down arrow while the search bar
is focused raises a traceback instead of moving the focus to the first card.
The channels kanban is rendered by a custom template written from scratch,
which omits the t-ref="this.rootRef" of the standard kanban renderer, so
this.rootRef() is null when the focus-view handler looks for the first card. A
second traceback follows once the focus reaches a card, as focusNextCard looks
for .o_kanban_group wrappers whenever the list is grouped, while the categories
are rendered as plain rows, and the resulting empty list is then accessed by
index.

**Current behavior before PR:**
----------------------------------------------
- Pressing the down arrow from the search bar raises a traceback
- Pressing the arrow keys again from a card raises a second traceback
- Keyboard users cannot browse the channels kanban at all

**Desired behavior after PR is merged:**
----------------------------------------------
- Pressing the down arrow from the search bar moves the focus to the first card
- The arrow keys browse the cards in reading order, across categories
- Pressing the up arrow on the first card returns the focus to the search bar
- Pressing Enter on a card opens the corresponding channel
- Keyboard navigation is consistent with the other kanban views

Task-6439024

----------------------------------------------

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

### Steps to reproduce:

- Create a product with a bom and 2 operations
- Create an MO for 1 unit of that product
- Confirm the MO
- On the bom, delete the second operation and modify the first operation on anything else than the company, name or workcenter
- Go back to the MO, click the "Update Bom" button
> The second operation is not unlinked and the first operation is not updated

### Cause of the issue:

The `action_update_bom` updates the move raws and operations of the MO via the `_link_bom`:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L1214-L1218 For draft MO's all the work of these updates is done via the compute methods and by deleting all the records unrelevant to the new bom: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2603-L2626 And, in that case all the workorders that are not linked to an operation of the bom are expected to be deleted. However, when the MO is not in draft, the update of operations is expected to be performed here: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2647-L2664 However, since the operation of the bom has been deleted, the workorder that is expected to be deleted is not linked to any operation and hence does not satisfy the condition to be deleted:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2663-L2664
Concerning the non update of operations, it happens because the MO's operation are only updated on the three fields: `company_id`,
`workcenter_id`, `name`:
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2647-L2664
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2628-L2629
However, many other changes can and are actually relevant.

### Note:

Prior to commit 80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 operations were archived on boms rather than deleted:
https://github.com/odoo/odoo/blob/4a5270218fe6fd7d30edb6d684b3340dc7423bab/addons/mrp/views/mrp_routing_views.xml#L53-L55 As such they would still be linked to an operation (but unrelated to the present values of the bom) and hence would fall into the condition of being unlinked from the MO.

Since the bom operations are no longer archived there is no way to determine if an operation used to be linked to a bom and we therefore need to chose between deleting all operations unrelated to the present bom or to keep them all (when the MO has been confirmed).

Enterprise: https://github.com/odoo/enterprise/pull/120709

opw-6285878
opw-6261738

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

Forward-Port-Of: odoo/odoo#280803
Forward-Port-Of: odoo/odoo#269747

Steps to reproduce:

- Create a product with a bom and 2 operations
- Create an MO for 1 unit of that product
- Confirm the MO
- On the bom, delete the second operation and modify the first operation on anything else than the company, name or workcenter
- Go back to the MO, click the "Update Bom" button
> The second operation is not unlinked and the first operation is not
  updated

Cause of the issue:

The `action_update_bom` updates the move raws and operations of the MO via the `_link_bom`:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L1214-L1218 For draft MO's all the work of these updates is done via the compute methods and by deleting all the records unrelevant to the new bom: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2603-L2626 And, in that case all the workorders that are not linked to an operation of the bom are expected to be deleted. However, when the MO is not in draft, the update of operations is expected to be performed here: https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2647-L2664 However, since the operation of the bom has been deleted, the workorder that is expected to be deleted is not linked to any operation and hence does not satisfy the condition to be deleted:
https://github.com/odoo/odoo/blob/f66614193cce18f5a3298d03ce7e5f29d54f07e9/addons/mrp/models/mrp_production.py#L2663-L2664 Concerning the non update of operations, it happens because the MO's operation are only updated on the three fields: `company_id`, `workcenter_id`, `name`:
https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2647-L2664 https://github.com/odoo/odoo/blob/31df5033e31c193b4576ef37dfbc5fc683817bc5/addons/mrp/models/mrp_production.py#L2628-L2629 However, many other cahnges can and are actually relevant.

Note:

Prior to commit 80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 operations were archived on boms rather than deleted:
https://github.com/odoo/odoo/blob/4a5270218fe6fd7d30edb6d684b3340dc7423bab/addons/mrp/views/mrp_routing_views.xml#L53-L55 As such they would still be linked to an operation (but unrelated to the present values of the bom) and hence would fall into the condition of being unlinked from the MO.

Since the bom operations are no longer archived there is no way to determine if an operation used to be linked to a bom and we therefore need to chose between deleting all operations unrelated to the present bom or to keep them all (when the MO has been confirmed).

Community: https://github.com/odoo/odoo/pull/269747

opw-6285878
opw-6261738

Forward-Port-Of: odoo/enterprise#128120
Forward-Port-Of: odoo/enterprise#120709

Steps to reproduce:
===================
1. Add a video (e.g. a YouTube URL) to a product from the Sales app.
2. Open the product page on the website.
3. Slide the carousel to the video.

=> The video preview cover is blurry.

Root cause:
===========
The product images are rendered in a carousel (the shop_product_carousel template in ) where only the first slide  gets the "active" class; https://github.com/odoo/odoo/blob/af1b3ee2e7ac56a35bff5e030c3a831c27dbcf24/addons/website_sale/views/templates.xml#L3224-L3226 every other slide is "display: none".
A product video is rendered as a live <iframe> inside its slide, so when the video is not the first media its iframe loads while its container has no  dimensions (0x0). The embedded player then initializes as a small mobile player and loads a low resolution cover thumbnail (120x90), which looks blurry once the slide is shown at full size. Reloading only the iframe while the slide is visible fixes it, a full page reload does not.

Fix:
====
Defer loading the video iframes located on hidden slides their src is moved to a data-src attribute on start and restored once the slide becomes visible. The player then initializes at full size and loads a high resolution cover.

opw-6349394


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

Forward-Port-Of: odoo/odoo#282508
Forward-Port-Of: odoo/odoo#274002