Currently, the recurring price table displays incorrectly when the user enables the one-time purchase option for a product.

**Steps to produce:**
* Install `website_sale_subscription` with demo data
* Products > Car Leasing > Recurring prices > Enable Accept One-time
* Go to that product's website page

**Observed behavior:**
The pricing table template [1] is appended inside the input radio button instead of replacing the entire pricing table.

**Root cause:**
* Initially, when the `sale_subscription_product_price` template is used, function [2] replaces the table inside `div` [3], which has the `plan_select` class.
* But  When one-time purchase is enabled, the template `subscription_one_time_sale` is used instead of `sale_subscription_product_price`.
* In that template, `div` [4] does not have the `plan_select` class.
* Because of this, the query selector [5] finds the first `plan_select` element inside `input` [6].
* As a result, function [2] renders the table inside that `input` element instead of the intended `div`.

**Solution:**
This commit ensures that:
* One time purchase price is changed dynamically based on variants.
* The pricing table is displayed correctly for both service and
  goods type products.
* The radio button selection works correctly by adding classes to the template
  and modifying its interaction accordingly.

| Before 'Service' type product page | After  'Service' type product page|
|--------|--------|
| <img width="1855" height="928" alt="image" src="https://github.com/user-attachments/assets/d662fbf5-cfce-45c5-b14c-043e982c63a6" /> | <img width="1851" height="933" alt="image" src="https://github.com/user-attachments/assets/8e510b27-6917-43bc-ac5d-b01ff1b187ad" />|

|  Before 'Goods' type product page | After  'Goods' type product page |
|--------|--------|
| <img width="1852" height="931" alt="image" src="https://github.com/user-attachments/assets/b9aa68e7-beef-413c-b99e-a71937e35e10" />| <img width="1851" height="932" alt="image" src="https://github.com/user-attachments/assets/d768edd9-2169-4d43-ac59-9893b55d5bcd" /> | 

[1]:
https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/static/src/xml/pricing_view.xml#L21-L63
[2]:
https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/static/src/js/variant_mixin.js#L32-L36
[3]:
https://github.com/odoo/enterprise/blob/77423e62d5b74d73cad86bf81fdfee2bea3ef2d1/website_sale_subscription/views/templates.xml#L61
[4]:
https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/views/templates.xml#L130
[5]:
https://github.com/odoo/enterprise/blob/7837a4497759dc9dd75aeac30083266798c5ce59/website_sale_subscription/static/src/js/variant_mixin.js#L18-L20
[6]:
https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/views/templates.xml#L138


opw-5380240

Forward-Port-Of: odoo/enterprise#102427

Currently, fields added using XPath expressions before or after the `VAT` field 
(such as `IE`, `IM`, and `SUFRAMA` from `l10n_br`) lose their labels and helpers in 
the Contacts form, making them hard to identify.

**Steps to reproduce:**
- Install the `l10n_br` module and switch to a `BR company`.
- Go to Contacts and open a contact form.
- Observe the Brazilian identification number fields (`IE`, `IM`, `SUFRAMA`).

**Obeservation:**
Missing labels and helpers for fields added around the `VAT` field in 
the `res.partner` form.

**Root Cause:**
After commit [1], `account.view_partner_property_form` inherits from
`product.view_partner_property_form` at [2], whose default priority (16) 
causes it to be applied after `base_vat.view_partner_base_vat_form`, 
which has priority (15) at [3].

As a result, the `base_vat` module moves the `VAT` field into the
`vat_vies_container` div. Consequently, any subsequent XPath
expressions targeting the `vat` field with position `before` or
`after`, when the view is inherited from `account.view_partner_property_form`, 
are applied inside this container instead of the original form layout.

The issue is not limited to the Brazilian localization, it impacts any module 
that inherits from the `account.view_partner_property_form` views and relies 
on XPath expressions positioned around the `VAT` field.

**Fix:**
This commit ensures that fields added before or after the VAT field remain
properly labeled and identifiable across all modules by assigning a higher
priority to `product.view_partner_property_form` than to
`base_vat.view_partner_base_vat_form`.

**Before:**
<img width="1908" height="616" alt="5443833_before" src="https://github.com/user-attachments/assets/f7d0819d-38bd-4fe8-8a22-5e22b342cd32" />

**After:**
<img width="1909" height="703" alt="5443833_after" src="https://github.com/user-attachments/assets/b205cb87-64ba-49fd-91c4-c20908d21429" />

[1]:
https://github.com/odoo/odoo/commit/4bff48d8233a9c1338252725f92ffcf580bd2b9d

[2]:
https://github.com/odoo/odoo/blob/229c2737edee601552ccceeed8602ec0e4686596/addons/account/views/partner_view.xml#L191

[3]:
https://github.com/odoo/odoo/blob/229c2737edee601552ccceeed8602ec0e4686596/addons/base_vat/views/res_partner_views.xml#L4-L26

opw-5443833

**Steps to reproduce:**
* Install the *purchase_stock* module
* Create new Product category.
* In the category, set the **Costing Method** to *Average (AVCO)*.
* Create a new product and assign a created product category. 
* Create a new Purchase Order.
  * Add a Purchase Order Line with the created product.
  * Set **Quantity** to 10.
  * Set **Unit Price** to 100.
  * Set **Discount** to 10%.
* Confirm the Purchase Order.
* Validate the generated receipt.
* Open the product form and check the *standard_price*(Cost) field.

**Observed behavior:**
The product standard price is updated to **100**, calculated from  the undiscounted unit price (1000 / 10), ignoring the discount applied  on the purchase order line. The expected value is *90* (900/10).

**Cause:**
With the new inventory valuation logic in v19.0, the standard price is updated via *_update_standard_price*, which calls *_run_avco* which uses the stock move *value* field set by *_get_value_from_quotation*:
https://github.com/odoo/odoo/blob/71195624008f8c1ba8b10e1b04433e34e08fb540/addons/stock_account/models/product.py#L340
However, the *_get_value_from_quotation* relies on *_get_stock_move_price_unit*, which returns the unit price **without considering the discount**, leading to an incorrect move value for AVCO computation.

**Note:** 
Prior to 19.0, the `price_unit` of the move was calculated in the `_get_price` unit using the `_get_gross_price_unit` using the discounted value of the line:
https://github.com/odoo/odoo/blob/24db73743d8bb4d678af7efb4d78a019e0953395/addons/purchase_stock/models/stock_move.py#L152-L154
https://github.com/odoo/odoo/blob/24db73743d8bb4d678af7efb4d78a019e0953395/addons/purchase/models/purchase_order_line.py#L383-L387
It should still be the case here as there is no discounted_unit_price on the move and, since we do not rely on the `_get_gross_price_unit` anymore, we should adapt the relative call:
https://github.com/odoo/odoo/blob/090c5a4d55e3fcd1b2840bc8afaed49efc8745d4/addons/purchase_stock/models/stock_move.py#L214-L218
https://github.com/odoo/odoo/blob/090c5a4d55e3fcd1b2840bc8afaed49efc8745d4/addons/purchase_stock/models/purchase_order_line.py#L238-L243


---
opw-5409226

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

Forward-Port-Of: odoo/odoo#241273

Description of the issue/feature this PR addresses:
This PR updates the company filtering logic in account balance computations to support Odoo's branch hierarchy. In multi-branch environments, a parent company should be able to see the aggregated balances of its child branches. Currently, the strict equality operator prevents this consolidation, creating a discrepancy between the expected "Global" view and the displayed balance.

Current behavior before PR:
The _compute_current_balance method in account_account.py uses the = operator for the company_id domain: domain=[('account_id', 'in', self.ids), ..., ('company_id', '=', self.env.company.id)]

This restricts the balance calculation exclusively to the current active company, excluding any transactions made in its branches (child companies), even when the user is positioned at the parent level.

Desired behavior after PR is merged:
The operator is changed to child_of. When a user is in a parent company/branch, the current_balance of the account will include the sum of all journal entries from that company and all its descendants in the hierarchy. This ensures consistency with how other parts of Odoo (like https://github.com/odoo/enterprise/blob/e29aadef1a81c662d9a4d33879b440dbe4390c0b/account_followup/models/res_partner.py#L230) handle company-related domains.





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

Forward-Port-Of: odoo/odoo#242576

**Problem:**
When ordering a combo product, you can order more products than the
combo requires, which will the add *base_price* to the combo price.
The problem is that when changing the preset, like going from eat in
to delivery, the pricelist is reconfigured, and it does not take the
extra products from the combo into account. This means that the price
will go back to the combo's price without the extra products.

**Steps to reproduce:**
- Have a combo that can take on multiple free products and has a limit above this free product number
- Order more than the free quantity
- Change the preset (from eat in to delivery)
- The price is recomputed without taking the extra products into account

**Why the fix:**
The extra articles were not accounted for when changing the pricelist,
meaning they would end up free and the price would change. We now
make a separation between the free products (that are from the combo) and
the extra products. The extra products cost the *base_price* of said combo.

To do that, we need to get the extra lines from the combo, which are the
products that are not free in the case where there are more products
selected in the combo than free products defined in the definition of
the combo. To make that happen, we add the non free lines to the
extra lines list once we have at least as many free products as
defined in the combo definition.

In the case where the quantity of a product is greater than the number
of free items, the lines are automatically split. Meaning if we have
a combo with 2 free items but we order 3, we will have a line with
a quantity of 2 and another line with a quantity of 1. In that case,
the first line will be free, but the second line will be an extra.
This logic is implemented here https://github.com/odoo/odoo/blob/0087cc96b2d2190ab107c3d50d3bdd48f7a687e9/addons/point_of_sale/static/src/app/components/popups/combo_configurator_popup/combo_configurator_popup.js#L88-L106
Which is then retrieved here to make the separation in the combo's price
https://github.com/odoo/odoo/blob/0087cc96b2d2190ab107c3d50d3bdd48f7a687e9/addons/point_of_sale/static/src/app/services/pos_store.js#L879

opw-4885574

Forward-Port-Of: odoo/odoo#241689
Forward-Port-Of: odoo/odoo#217082

Commit 04155a0 correctly increased the threshold for the VP7 line
of the monthly tax report from 25.82€ to 100.00€. However, a
subsequent commit (https://github.com/odoo/odoo/commit/51a72ab42d118d6fb0eb3e3545a09e10019b9140) accidentally reverted this change to
the outdated value.

This commit restores the threshold to the expected value of 100.00€.

---

The previous fix in https://github.com/odoo/odoo/commit/4e831999ed06e0e3c2f380414c5949db645f2f19 attempted to correct VP6 (VAT due/deductible)
but relied on an incorrect assumption regarding debit signs.

In the Italian tax report, values should remain positive regardless of
whether they are debits or credits. Displaying debits as negative caused:
1. Incorrect visual representation in the report columns.
2. Inconsistent totals for VP14 (VAT payable).

This commit ensures all debit column values are displayed as positive
and restores the correct calculation logic for the report totals.

opw-5357719
opw-5411706
opw-5421779

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

Forward-Port-Of: odoo/odoo#240705

### Steps to reproduce:

- Create a bom for a product with 2 component lines:
    - 1 x COMP1
    - 1 x COMP2
- Create an MO for your product (do not confirm it)
- Delete the second bom line of the bom
- On the draft MO, click on `update bom`
#### > This automatically modifies the `move_raws` of the MO but the un-linked move raws were neither deleted nor cancelled as shown by the move analysis

### Cause of the issue:

Clicking on `update bom` will launch a call of the `action_update_bom` which will itself call the `_link_bom` to update the record: https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418 Now the issue is that the `bom_id` is set to `False` before the value of the `move_raw_ids` and `workorder_ids` are stored to be unlinked in the `moves_to_unlink` and `workorders_to_unlink` variable. Now, the issue is that the `bom_id` is a dependency of both compute methods: https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L745-L746 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L563-L564 in particular, `moves_to_unlink` will always be an empty record set and the value of the `workorders_to_unlink` might be unreliable.

opw-5243203

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

Forward-Port-Of: odoo/odoo#242132
Forward-Port-Of: odoo/odoo#239654

When creating or editing Peruvian purchase invoices/credit notes, the l10n_latam_document_number field is formatted with zfill(8) (e.g., "F01-100" becomes "F01-00000100"), but the name field was not synchronized, causing data inconsistencies between these fields.

Steps to reproduce:
1. Create a purchase invoice for a Peruvian company
2. Select a document type (Factura, Boleta, or Credit/Debit Note)
3. Enter a document number like "F01-100"
4. Save the record
5. Observe that l10n_latam_document_number shows "F01-00000100" but name field may show a different format

This fix ensures that after formatting the document number, the name field is synchronized with the correctly formatted value, preventing inconsistencies in vendor invoices and reports.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#241948

Steps to reproduce:
====================
- Go to the website in chrome
- Create a Image Wall (gallery)
- Add a lot of images. See attachments for a .zip file in task to test it.
- Try to change the display mode or number of column

-> An error will appear when the cursor get on the dropdown options.

Cause:
======
In Google Chrome, calling img.decode() on a large set of images simultaneously (e.g., in an image wall) can result in `EncodingError: The source image cannot be decoded for some images`. This is a known Chromium issue (See [1]) where the browser's image decoder gets overwhelmed or hits a concurrency limit, causing it to reject valid images.

The current implementation uses Promise.all(imgLoaded), which utilizes a "fail-fast" mechanism. Consequently, if a single image fails to decode due to this browser limitation, the entire promise rejects immediately. This unhandled rejection interrupts the execution flow, preventing the display mode or column options from functioning correctly when the user interacts with them.

Solution:
========
Replace `Promise.all(imgLoaded)` with `Promise.allSettled(imgLoaded)`.

Unlike `Promise.all`, `Promise.allSettled` waits for all promises to finish regardless of whether they succeeded or failed.

[1]: https://issues.chromium.org/issues/40261318

opw-5249130

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

Forward-Port-Of: odoo/odoo#240062

Issue:
A TaxSubtotal node was blocking the XML validation for peppol invoices with Cash Rounding

Step to reproduce:
1. Select BE Company CoA
2. Enable Cash Rounding in the settings
3. Create a cash rounding method (in the settings where cash rounding can be enabled):
   - precision `1.00`
   - strategy: Add a rounding line
   - profit / loss account: any
4. Create an invoice
   - Set a Belgian partner (e.g. "BE Company CoA" is okay)
   - Set the cash rounding method from step 2
   - Single Line with price=70.00€ and a 21% tax
5. The total should be 85.00 € (84.70 € w/o the rounding) In the journal items there should be the following non-payment term items:
   - 70.00€ base
   - 14.70€ tax
   -  0.30€ rounding
6. Confirm & Send (with PEPPOL)

Current Behavior:
Look at the UBL BIS 3 XML in the `Invoice` element
   - `TaxTotal/TaxAmount`: 14.70€
   - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
   - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€
   - `TaxTotal/TaxSubtotal/TaxableAmount`: 0.30€
   - `TaxTotal/TaxSubtotal/TaxAmount`: 00.00€
   - `TaxTotal/TaxSubtotal/TaxCategory/TaxExemptionReason`: "Exempt from tax"
   - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
   - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€
   - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€
   - `LegalMonetaryTotal/PayableAmount`: 85.00€ This fails validation `BR-E-08`:
"In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount BT-116 [is equal to: `BT-116 = sum(BT-131) - sum(BT-92) + sum(BT-99)` i.e. `VAT category taxable amount = Invoice net - allowance + charge`] where all the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT""

Expected behavior:
Look at the UBL BIS 3 XML in the `Invoice` element
   - `TaxTotal/TaxAmount`: 14.70€
   - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
   - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€
   - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
   - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€
   - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€
   - `LegalMonetaryTotal/PayableAmount`: 85.00€

Solution:

Per the calculation of the VAT category taxable amount (BT-116). There should have a TaxSubtotal for tax Category having invoice lines.
https://docs.peppol.eu/poacc/billing/3.0/bis/#_calculation_of_totals 
As invoice lines should contain their item name. Rounding line won't have one.
https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-25/
As rounding appear in the LegalMonetaryTotal, removing the related TaxSubtotal doesn't remove information.
https://docs.peppol.eu/poacc/billing/3.0/bis/#_element_for_rounding_amount_the_payableroundingamount

Rounding base_lines are removed from `vals['base_lines']` as they need to have a product label. https://github.com/odoo/odoo/blob/366d7122ee30e16c157d026363b731c066a564c5/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L305-L310

As `_ubl_add_values_payable_rounding_amount` needs rounding lines within base_lines and `_ubl_add_values_tax_totals` shouldn't have them, this commit exchanges their processing order.

This commit also:
- fix the test file `test_invoice_cash_rounding_add_invoice_line.xml` as it failed the XML validation (BR-E-08).

opw-5434335


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

Forward-Port-Of: odoo/odoo#241717

Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the UNION, any filtering (like on specific budget_line_ids) happened after the full, unfiltered table was generated.

This post-filtering caused slowness, especially in nested loop joins with large tables like account.analytic.line. This commit optimizes performance by pushing the filter condition (using specific budget_line_ids) directly down into the three underlying queries. This reduces the number of budget.line records processed, speeding up joins and overall computation.

The benchmark below is done on a database that has **66396** `budget.line` records and **928567** `account.analytic.line` records. Opening a budget report for a specific year, only applied the filter with **40** `budget.line` records.

| Scenario | Execution Time |
| :--- | :--- |
| **Before this Commit** | **60.00 seconds**
| **After this Commit** | **1.84 seconds**

opw-5150569

Forward-Port-Of: odoo/enterprise#102918
Forward-Port-Of: odoo/enterprise#99096

### [FIX] purchase_mrp, mrp: correct BoM Kit valuation with nested kits

#### Issue:
When purchasing a BoM Kit (50/50) containing others BoM Kits (50/50), cost share was applied at each level (50% instead of 25%), leading to overvaluation (e.g., 200% total instead of 100%)

#### Cause:
`cost_share` was always applied fully during BoM explosion and as a portion of the full price on `_get_unit_price()`

#### Other bug fixed:
Fix `_get_cost_share()` to correctly return 0 when BoM total cost_share already equals 100%

#### Requirement:
AVCO (Average Cost) must be enabled on all components/BoMs

#### Steps to reproduce:
1. Recreate that hierarchy with AVCO Products
- A kit "Testing Kit Complete" containing:
-- "Component01", cost share 50%
-- A kit "Testing Kit 1", cost share 50%:
--- "Component02", cost share 50%
--- "Component03", cost share 50%
2. Create and validate a Purchase Order for "Testing Kit Complete" (unit price: 1000)
3. Receive the products
4. Go in Inventory > Reporting > Valuation and search for Component
5. All 3 components are set to 500, instead of Component01: 500 / Component02: 250/ Component03: 250

opw-4806023


### [FIX] purchase_mrp: correct BoM valuation with product variants or optional lines

#### Issue:
BoM valuation ignores variant-specific lines and does not skip lines with quantity 0

#### Cause:
The code only checks that the BoM adds up to 100%
But this can cause issues with variants that do not include all products or with optional lines
As a result, the total valuation may be incorrect

#### Steps to reproduce:
1. Recreate a kit hierarchy with AVCO products:
   - Kit "Variant Kit" (Variant Color: White and Wood) containing:
     -- "Component01", cost share 0%, only for variant White
     -- "Component02", cost share 0%
2. Create and confirm a Purchase Order for "Variant Kit" (variant: Wood, unit price: 1000)
3. Receive the products
4. Go to Inventory > Reporting > Valuation and search for the components
5. Only Component02 appears with 500$, so only half of the total value is shown

opw-4806023
opw-5085457

Forward-Port-Of: odoo/odoo#240425
Forward-Port-Of: odoo/odoo#218326