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

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

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