### Issue:
When creating an automatic reconciliation rule by assigning the same account to multiple bank statement lines, the rule incorrectly overrides the original payment reference of subsequent lines with the account name

This creates an inconsistent user experience
Using the "Set Account" button directly keeps the statement line payment reference as the journal item label
However, clicking the automatically generated reconciliation model button replaces that reference with the account name

Before the fix, clicking the automated rule button on a third matching line overrides its label with the account name instead of keeping its unique reference

### Cause:
In `_create_reconciliation_rule`, when an automatic model is generated, the dictionary used to create the counterpart line explicitly set `label` to `rule_data['account'].name`

When a reconciliation model line has a specific label defined, Odoo uses it to replace the statement line `payment_ref` on the generated counterpart move lines
Removing this default value allows the system to fall back on the original payment reference

### Steps to reproduce:
- Install `account_accountant`
- Go to the Bank Reconciliation widget from the Accounting Dashboard
- Create 2 statement lines without partners (e.g., Ref: "Test Ref 1" and "Test Ref 2")
- Set the same account on both lines using Set Account
- This automatically creates a Reconciliation Rule named after the account
- Create a 3rd statement line with a matching reference (e.g., "Test Ref 3")
- Click the newly available automatic reconciliation button for this line

Before the fix, checking the generated entry label shows the account name instead of "Test Ref 3"
To check unfold the details, click on the pencil icon of a line

opw-6246833

Forward-Port-Of: odoo/enterprise#119133

Steps to reproduce
------------------
Serial-tracked finished product:
1. Create a serial-tracked finished product and an un-tracked component.
2. Create a Manufacturing Order with quantity 2 and confirm it.
3. Open the Barcode app, scan the MO, then scan a first serial number SN_X1.
4. Scan a second serial number SN_X2.
5. Validate.

Lot-tracked finished product:
1. Create a lot-tracked finished product with a one-component BoM and an existing lot LOT_A.
2. Create a Manufacturing Order and confirm it.
3. Open the Barcode app, scan the MO, then scan the existing lot LOT_A.
4. Scan a different, not-yet-existing lot LOT_B.
5. Validate.

Issue
-----
Only the last scanned serial is registered on the MO, and validation then fails because the count of producing serials does not match qty_producing for a serial-tracked finished product.

updateLine overwrote lot_producing_ids with [args.lot_id] on every scan, so the first serial was dropped when the second one was scanned, and the same branch never staged a freshly typed
lot_name, so a brand-new serial typed on a serial-tracked MO was lost before reaching the backend.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L407

Two behaviours of the shared barcode dispatcher make a single accumulating branch insufficient.

The final-product line must keep exposing a producing lot, otherwise the base hasUnassignedQty check counts a scanned serial as zero once a quantity is already set, leaving qty_producing stuck below the demand.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L1446

But exposing a producing lot makes the dispatcher treat the next serial as a conflicting tracking number, since the base _canOverrideTrackingNumber considers a different lot name non-overridable.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L796-L798

So the scan is diverted to a new line through the override gate instead of updating the header line.

https://github.com/odoo/enterprise/blob/f622064871bf55b93890606d16407c50cf4419a6/stock_barcode/static/src/models/barcode_model.js#L1585

For a lot-tracked finished product the producing lot can be corrected by scanning a different value, but the lot branch only stored a freshly typed value in lot_name and overwrote lot_producing_ids with the single existing lot.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L404-L407

The header reads its lot from lot_producing_ids whenever that relation is set and only falls back to lot_name when it is empty.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/components/header.js#L45-L58

The save path only promotes lot_name to a producing lot when lot_producing_ids is empty, so scanning an existing lot then a new one neither displayed nor recorded the new lot and the finished product was produced under the old lot.

https://github.com/odoo/enterprise/blob/4a2f1da5466740b7758d1962e5241620845d616b/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L628

Solution
--------
Accumulate scanned serials by appending to lot_producing_ids instead of replacing it, and stage a freshly typed lot_name as a new producing lot when the finished product is tracked by serial, so every serial reaches the backend.

Keep the final-product line exposing the last producing lot so each scanned serial is still counted as one unit instead of resetting the quantity to zero once several serials are registered.

Override _canOverrideTrackingNumber for the final-product line so a serial scan updates the header line rather than being diverted to a new line, which is the only valid path for the finished product since it is a single header line backed by the lot_producing_ids relation.

Persist the producing serials with explicit x2many commands, separating already-existing lots from freshly typed ones, so both are written on the MO.

Reject a serial that is already registered on the MO so the same number cannot be produced twice in one session.

For a lot-tracked finished product, build a producing lot from the scanned value, using the existing lot or a freshly typed lot name, and store it in lot_producing_ids so the new lot is both displayed and persisted through the same x2many commands as the serial case.

Leave the produced quantity unchanged when the scanned lot differs from the one already registered, since replacing the lot is a correction and not an extra unit, and keep incrementing it when the same lot is scanned again.

opw-6189620

Forward-Port-Of: odoo/enterprise#116890

A tax created without a fiscal position (empty fiscal_position_ids) is conceptually an "All" tax: it should apply across every fiscal position, including the empty ones used for tax units.

Problem

map_tax drops every tax when the FP has no mapping, including the "All" ones that should pass through.
action_open_related_taxes only lists the FP's tax_ids, so "All" taxes are invisible from the FP form.
The Taxes stat button is hidden whenever the FP has no tax_ids.
action_update_fpos_values invokes the field computes directly, so tax and balance lines fall out of sync after an FP change.

Fix

map_tax: when the FP has no tax_ids, return the input taxes whose fiscal_position_ids is empty (the "All" ones) instead of an empty recordset.
action_open_related_taxes: extend the domain to also include taxes bound to no fiscal position.
partner_view: drop the invisible="not tax_ids" guard on the Taxes stat button.
action_update_fpos_values: route the deferred computes through _check_balanced and _sync_dynamic_lines so tax lines stay in sync after the update.

task-id [6231514](https://www.odoo.com/odoo/project/967/tasks/6231514)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#268273

## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
    - Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__

## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157

We obtain the following values:

```js
> monday = section.cells[1]

> monday.value
8.333333333333336

> workingHours[monday.column.value]
8.333333333333332

> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```

This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:

https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172

## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.

opw-6193181

Forward-Port-Of: odoo/enterprise#121463

Steps to reproduce
------------------
1. Set a default tax on the "Cash Difference Gain" account (e.g. a 25%
   sales tax) -- required in some countries like Denmark (cf 5972690).
2. Open a PoS session, count more cash than expected at closing.
3. Try to close the session.

-> Error message shows up "The journal entry reached an invalid
state..." ... "The journal entry must always have exactly one journal
item involving the bank/cash account"

What's happening
----------------
PoS creates a bank statement line with the gain account as counterpart,
resulting in 2 lines: cash +10, gain -10. Since the gain account has a
default tax, `_sync_tax_lines` adds a tax line of -2.5 on top, which
makes the move unbalanced by 2.5. Then `_sync_unbalanced_lines` adds a
4th line to fix it, on the line returned by
`_get_automatic_balancing_account`, which is `journal.default_account_id`,
i.e. the cash account itself for a cash journal.

So we end up with 2 lines on that same cash account, which a bank
statement line move doesn't allow -> Error.

The fix
-------
In `_post_statement_difference`, precompute the base and tax split
ourselves and build the statement line's `line_ids` directly (e.g. for
+10 and a 25% tax: cash +10, gain -8, tax -2). The move is balanced
from creation, so `_sync_tax_lines` and `_sync_unbalanced_lines` don't
have to touch it.

Note that we force the tax computation to be in 'force_price_include'
mode, as the counted cash difference is a gross amount (physical money
in the drawer). This way the tax is always extracted from the cash
amount, regardless of how the tax is configured (included or excluded
in price). Same pattern is already used by `hr_expense` (cf
`hr_expense.models.account_move_line._compute_totals`).

opw-5972690

Forward-Port-Of: odoo/odoo#271921
Forward-Port-Of: odoo/odoo#257892

Version:
--------
- 18.0+

Steps to reproduce:
-------------------
- Install `quality_mrp`
- Create a manufactured product with a BoM
- Create a Quality Point for the `Manufacturing` operation of that product
- Create and confirm multiple Manufacturing Orders
- Verify that each MO generates a quality check
- From the MO list view, select the MOs and merge them from the gear menu(merge)

Issue:
------
When Manufacturing Orders are merged, All MOs are cancelled but it keep their
quality checks in the 'To Do' state.

As a result:
- The quality checks remain linked to cancelled MOs
- The 'Quality Checks' smart button is still displayed on cancelled MOs

Expected behavior:
------------------
- Pending quality checks should be deleted when the MO is cancelled
- The 'Quality Checks' smart button should no longer be displayed

Cause:
------
A previous fix introduced logic to remove pending quality checks when a
Manufacturing Order is cancelled:
odoo-dev@db93bd2

This logic was implemented in `action_cancel()` by unlinking quality
checks associated with the cancelled MO:
https://github.com/odoo/enterprise/blob/20bc0eb5c2cec67eecd3b44450934e23370b48f2/quality_mrp/models/mrp_production.py#L94-L97

However, when MOs are merged, the merge flow does not call
`action_cancel()`. Instead, it directly invokes `_action_cancel()` on
the source Manufacturing Orders:

https://github.com/odoo/odoo/blob/aca0b7289c68fc7a75d47ab313f5f791ebf30f7d/addons/mrp/models/mrp_production.py#L2480


Since the quality check cleanup is implemented only in
`action_cancel()`, it is bypassed during the merge process.

As a result, the source MOs are cancelled but their pending quality
checks remain in place.


---

opw-6260735

Forward-Port-Of: odoo/enterprise#121717
Forward-Port-Of: odoo/enterprise#119525

The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates whether the real messages (as opposed to the empty phantom placeholder) are rendered. The mirroring effect both read `mountedAndLoaded` as a dependency and wrote it.

`useEffect` records its dependency array before running the body, so right after the effect sets `mountedAndLoaded` to true the recorded dependencies still hold the pre-write pair `[isLoaded=true, mountedAndLoaded=false]`; that update only settles on a later, microtask-deferred patch. When a second reload runs `reset()` in that window, it drives `mountedAndLoaded` back to false while `isLoaded` stays true. The settling patch then computes the very `[true, false]` pair that was already recorded, so the effect never re-runs: `mountedAndLoaded` is stranded at false and no message is ever rendered.

Depend on a monotonic `resetCount` bumped by `reset()` instead of on `mountedAndLoaded` itself. It is never written by the effect, so the recorded dependencies can no longer match the current ones after a reset and the effect always re-runs to re-sync `mountedAndLoaded` with `isLoaded`. `reset()` keeps clearing `mountedAndLoaded` as before (the false dip is needed for the reload scroll handshake), so the behaviour is otherwise unchanged.

https://runbot.odoo.com/odoo/error/940032

When a "Products" snippet is dropped above the variant selector on a product page, selecting a variant displays one of the snippet's products instead of the chosen variant (its image/price take over the page).

Steps to reproduce
===================
1. Create a product with 2+ variants and publish it.
2. Edit the product page, drag any block above the variant selector and add the "Products" dynamic snippet, then save.
3. Select a variant. => The page shows the snippet's first product instead of the variant.

Root cause
==========
`ProductPage._getCombinationInfo` reads the product ids from `parent.querySelector('button[name="add_to_cart"]')`, with `parent` being the whole `.js_product`. `querySelector` returns the first match in DOM order, and the dynamic "Products" snippet's cards reuse the same `button[name="add_to_cart"]` markup with their own product ids. When the snippet sits above the variants, its button comes first, so `/website_sale/get_combination_info` is called with the snippet product's ids and the page is updated with that product's data.

The interaction was introduced in saas-19.1 (See [1]) and the lookup switched from the unique `#add_to_cart` id to the by-name selector in (See [2]), which is what started matching the snippet's cards.

Fix
===
Pick the first `add_to_cart` button that is not inside a product card (`.oe_product_cart`), i.e. the main product's button.

[1]: https://github.com/odoo/odoo/commit/4682748e6e3c#diff-7e1a99da9e95d0c4df79ee4d7aa718e46bcb8b7f1ed78cde58782e075c833cd1R326
[2]: https://github.com/odoo/odoo/commit/1c732cf75a4a4faa960d6a98f08ae9dbe99b2b69#diff-7e1a99da9e95d0c4df79ee4d7aa718e46bcb8b7f1ed78cde58782e075c833cd1R329

opw-6248285

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

**Issue**
The quantity displayed in the Unit Cost History report can be incorrect when the move UoM differs from the product UoM.

**Steps to reproduce**
- Create an AVCO product Comp tracked in tons with a unit price of 100.
- Create another product with a BoM consuming 100kg of Comp
- Create, confirm and produce a MO for that product
- Open the Unit Cost History for Comp
-> Quantity is incorrect (100 instead of 0.1). As a consequence, the computed added value displayed in the report is also incorrect (10000 instead of 10).

**Cause**
The quantity and added value fields come from the `stock.avco.report` model, which is defined by this SQL view:
https://github.com/odoo/odoo/blob/aef190dbff365f4fe5d92a2c41c35f92b66ce5fd/addons/stock_account/report/stock_avco_audit_report.py#L36-L39 The view uses the `quantity` field of `stock.move`: https://github.com/odoo/odoo/blob/aef190dbff365f4fe5d92a2c41c35f92b66ce5fd/addons/stock_account/report/stock_avco_audit_report.py#L48 
without converting it in the right uom

opw-6271229

Forward-Port-Of: odoo/odoo#269846

**Step to Reproduce:**

1. Open the POS.
2. Add any product to the order.
3. Proceed to the payment screen and select `Pine Labs` as the payment method.
4. Observe that the Pine Labs terminal does not respond and no payment popup appears on the device.
5. Wait until the payment request is cancelled (either manually or due to timeout).
6. Click the `Force Cancel` button.
7. Observe that the POS throws a traceback.

**Video:**
https://drive.google.com/file/d/1A3QPdby-J12IWgOX_SfCLrauQ_QnbqvG/view

**Issue:**

When a Pine Labs payment request is cancelled (either through a cancel request or by timeout), clicking the `Force Cancel` button results in a traceback in
 the POS.

**Reason:**

During the cancellation flow, the payment line status is updated to `retry` so that the transaction can be marked as cancelled and retried if necessary.

Later, when the user clicks `Force Cancel`, `_paymentCancelRequestHandler()` attempts to retrieve the pending Pine Labs payment line using:

```javascript
const line = this.pendingPineLabsPaymentLine();
```

However, `pendingPineLabsPaymentLine()` only returns payment lines whose status is not `retry`, as defined here:

https://github.com/odoo/odoo/blob/19.0/addons/point_of_sale/static/src/app/services/pos_store.js#L1820

Since the payment line was already transitioned to the `retry` state during the cancellation flow, no `payment line` is found and `line` becomes `undefined`.

The handler subsequently attempts to update the status of this `undefined` `payment line`, resulting in the traceback when `Force Cancel` is executed.

**Solution:**

Add a condition in `_paymentCancelRequestHandler()` to verify that a payment line is available before attempting to update its status.

If no payment line is found, it indicates that the payment line has already been
 moved to the `retry` state during a previous cancellation attempt. In such
cases we clear `pollingTimeout`, `inactivityTimeout` and reset `this.payment_stopped` to `false`.

This prevents the traceback while ensuring that the `Force Cancel` flow properly cleans up the pending payment state.

opw-6297135

Forward-Port-Of: odoo/odoo#271397
Forward-Port-Of: odoo/odoo#271241

The chatter recipients input always added a "Create" option to its autocomplete dropdown, even when the field held no text. The feature that introduced this input, https://github.com/odoo/odoo/commit/3b985d2c4239fe702c1a56bef04fc112af39e954, wired that option to create a res.partner straight away. Selecting "Create" with an empty input therefore created a partner with no name, displayed everywhere as "Unnamed".

The email popover that opens for a recipient without an address then offered a Discard button, but the empty partner was already saved. The same sequence could be repeated to accumulate nameless contacts, which later raise a missing name error when opened in the Contacts app.

Only add the "Create" option when the typed term resolves to a name or an email, in getAutoCompleteSources of recipients_input.js. An input with no usable text has nothing to create from, which matches the standard many2one autocomplete that only offers creation once text is entered.

Steps to reproduce:
1. Open any record with a chatter
2. Click "Send message"
3. In the recipients field type a character then delete it, leaving the field empty with the dropdown still open
4. Click the "Create" option
5. On the "What's the email address of Unnamed?" popover, click Discard

=> A blank "Unnamed" contact is created, and repeating the steps creates more

Ticket [link](https://www.odoo.com/odoo/action-4043/5942428)
opw-5942428


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

Forward-Port-Of: odoo/odoo#250973

Steps to reproduce:
* Install `l10n_mx_edi` (or `l10n_sa_edi`).
* Go to **Accounting → Customers → Invoices**.
* Open **Studio** and, from the top bar, go to **Reports**.
* Duplicate the standard **Invoice PDF** report.
* Open the duplicated report and make any modification to it.
* Enable **Developer Mode**.
* Go to **Settings → Technical → Actions → Reports** and update the custom report's **Printed Report Name**.
* Go to **Settings → Technical → Email → Templates** and create a new invoice email template.
* Add the custom report to the template's **Dynamic Reports**.
* Create and confirm an invoice for a **Mexican company**.
* Click **Send** and select the newly created email template.

Observed behavior:
* The custom report attachment uses the CFDI-based filename instead of its own report name, making it appear as a duplicate of the standard invoice attachment.

Cause:
* `_get_placeholder_mail_template_dynamic_attachments_data` relied on the `invoice_report` context key to pass the extra report into `_get_invoice_report_filename`.  However, localization overrides (e.g. `l10n_mx_edi`, `l10n_sa_edi`) unconditionally return their own filename without checking the context, so the extra report's `print_report_name` was never evaluated.

Fix:
* Introduce `_get_invoice_mail_template_dynamic_report_filename` on `account.move` that directly evaluates a given report's `print_report_name`, bypassing the localization override chain.
* Call this new method in `_get_placeholder_mail_template_dynamic_attachments_data` instead of the context-based `_get_invoice_report_filename` call.

This avoids the need to patch every localization override and cleanly separates the concern of naming dynamic report attachments from the main invoice report filename logic.

opw-6228268

Forward-Port-Of: odoo/odoo#271489