Behavior before:
Exporting the TPAR report could fail with an error indicating that the GST amount exceeded the
gross paid for certain vendors. Some payment lines were excluded from the SQL query,
leading to discrepancies in the report.

Behavior after:
The SQL query has been updated to include all relevant payment lines, including those in
asset_cash accounts. This ensures that the gross paid is calculated correctly, allowing the
TPAR report to be exported without errors.

Root Cause:
The previous query only considered asset_current and liability_current accounts, ignoring
asset_cash accounts. This omission caused the gross paid amount to be understated relative to
the total GST paid.

Steps to Reproduce:

1. Create a vendor bill.

2. Navigate to the Bank Reconciliation page (Accounting → Dashboard → Bank Journal).

3. Create a bank statement line for the bill amount.

4. Validate the statement line with the corresponding invoice line.

5. Generate the TPAR report — the payment amount should now be correctly included.

OPW: 5148697

Forward-Port-Of: odoo/enterprise#102700
Forward-Port-Of: odoo/enterprise#99874

Issue
-----
Commit 76196c4c5f2ff01354931df6ad615f1b2c4d9a22 introduced logic to select the rate based on the requested currency. This causes problems when the requested currency does not match the one set up on the Fedex account, because the 'actualRateType' gets set to payor instead of preferred for the rate's 'rateType', which means

`d['rateType'] == rating_result['actualRateType']`

is false, so `actual` is empty, leading to an error when doing `actual['totalNetCharge']`.

Solution
-----
In the request we send, we hardcode

`'rateRequestType': ['PREFERRED']`

so we can look for a match using 'PREFERRED' as a prefix of `rateType`.

The Fedex API lists all possible values of the enum `rateType`

https://developer.fedex.com/api/en-us/catalog/ship/v1/docs.html

<details>
<summary>Enum values as per the API</summary>

"enum": [
	"INCENTIVE",
	"NEGOTIATED",
	"PAYOR_ACCOUNT_PACKAGE",
	"PAYOR_ACCOUNT_SHIPMENT",
	"PAYOR_CUSTOM_PACKAGE",
	"PAYOR_CUSTOM_SHIPMENT",
	"PAYOR_LIST_PACKAGE",
	"PAYOR_LIST_SHIPMENT",
	"PAYOR_RETAIL_PACKAGE",
	"PAYOR_RETAIL_SHIPMENT",
	"PREFERRED_ACCOUNT_PACKAGE",
	"PREFERRED_ACCOUNT_SHIPMENT",
	"PREFERRED_CUSTOM_PACKAGE",
	"PREFERRED_CUSTOM_SHIPMENT",
	"PREFERRED_INCENTIVE",
	"PREFERRED_LIST_PACKAGE",
	"PREFERRED_LIST_SHIPMENT",
	"PREFERRED_NEGOTIATED",
	"PREFERRED_RETAIL_PACKAGE",
	"PREFERRED_RETAIL_SHIPMENT",
	"RATED_ACCOUNT_PACKAGE",
	"RATED_ACCOUNT_SHIPMENT",
	"RATED_CUSTOM_PACKAGE",
	"RATED_CUSTOM_SHIPMENT",
	"RATED_LIST_PACKAGE",
	"RATED_LIST_SHIPMENT",
	"RATED_RETAIL_PACKAGE",
	"RATED_RETAIL_SHIPMENT",
	"UNKNOWN"
],

</details>

There are only 3 possible prefixes: `PAYOR`, `PREFERRED` & `RATED`, so replacing the other 2 by `PREFERRED` should be safe.

-----
Ticket:
opw-5482949

Forward-Port-Of: odoo/enterprise#105156

Versions
--------
- 18.0+

Steps
-----
1. Have a way to check the `specific_property_product_pricelist` field;
2. create a pricelist for EU countries;
3. delete all other regional pricelists;
4. create a new partner in a EU country;
5. create a new partner outside a EU country;
6. create a new partner without a country.

Issue
-----
Inconsistent behavior:
- EU partner has no `specific_property_product_pricelist` value set, as it's identical to the default `property_product_pricelist`.
- The other partners do have a `specific_property_product_pricelist` value set to the default value, as if a user manually assigned them.

Cause
-----
In the `_inverse_product_pricelist` method, the `default_for_country` pricelist is an empty recordset if the partner has no `country_id` or none of the pricelists have a country groups with the partner's `country_id` in it.

Solution
--------
Introduce a `_get_country_pricelist_multi` method that can be used by `_get_partner_pricelist_multi` and `_inverse_product_pricelist` to ensure that they both return the same result for any given country (including none), and use this as the `default_for_country`.

> [!Note]
> An alternative approach could be to replace the `_inverse_product_pricelist` method with an `onchange` method, as the docstring of the `_get_partner_pricelist_multi` method states:
>> First, the pricelist of the specific property (res_id set), this one is created when saving a pricelist on the partner form view.
>
> This suggests a behavior that more closely resembles the purpose of an `onchange` method, instead of an `inverse`.

opw-5385213

Enterprise PR: https://github.com/odoo/enterprise/pull/103116 (only modifies a test)

Forward-Port-Of: odoo/odoo#245530
Forward-Port-Of: odoo/odoo#241736

### Steps to reproduce:

- In the settings enable: Multi-Steps route
- Create a product tracked by SN
- In the barcode app > Operations > Internal transfers > New
- Scan you tracked product
- Click on Validate > Invalid operation
- Scan a Serial number
#### > You can not click on validate anymore

### Cause of the issue:

The issue has been introduced in 41c6e7a90fd4f0cf84e74cf0ed036f4da0ec6112 in a try to avoid concurrency issue when calling the barcode validation too quickly. To be more precise, this commit added a `isValidating` property to the barcode model that is set prior to the rpc call and suppose to remove after in order tobypass subsequence calls of the `validate` method when a call is already in progress: https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L477-L494 However, in the present case and since  orm call returns an error the the call the validate method is interupted at this orm call and the line
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L494 is not executed so that the this.Validating stays true and the button can not be clicked nor executed anymore:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L131-L133

### Fix:

We revert the incorrect fix: 42d77e751cb5e049ea1e81b44fca0d07e8f45b32 and we rather rely on the Mutex class of the JS framework just as done in the `_processBarcode`:
https://github.com/odoo/enterprise/blob/099c7b94ad08f83873c05ec528e16fbf806f47f2/stock_barcode/static/src/models/barcode_model.js#L505-L507 This will ensure that the validation calls will be processed sequentially and since the `button_validate` of stock pickings is ignored on done pickings because of the first soft fix https://github.com/odoo/odoo/pull/204790 :
https://github.com/odoo/odoo/blob/1664daf894ec878b64af8ab75c0d10f05e00df80/addons/stock/models/stock_picking.py#L1134-L1135
we have the guarantee that the records will not be validated twice.

opw-5388297

Forward-Port-Of: odoo/enterprise#104352
Forward-Port-Of: odoo/enterprise#103835

**Issue**
When producing a large number of serial-tracked products, a RecursionError
can occur.

**Steps to reproduce**
- Create three products tracked by serial number (ensure MTO and Manufacture
  routes are enabled).
- Create a BoM for product A containing product B.
- Create a BoM for product B containing product C.
- Create a BoM for product C containing another product.
- Create a manufacturing order of 100 units for product A and confirm it.
- Produce the 100 units on the child MO of product C (100 backorders are created).
- On the main MO (product A), click on "Prepare MO".
- Attempt to produce product B.
→ RecursionError: maximum recursion depth exceeded.

**Cause**
While setting `move_finished_ids`:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/mrp/models/mrp_production.py#L806

the `deadline_date` of the final move is updated:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L742C1-L743C63

This deadline is then propagated to chained moves:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L539C1-L541C55
via:
https://github.com/odoo/odoo/blob/3056facc07024d02829bf2e27c9ee2f56695c99e/addons/stock/models/stock_move.py#L559C1-L562C61

This propagation retriggers the `move_finished_ids` setter recursively on other
moves. The recursion depth grows with the number of generated moves, eventually
exceeding Python's maximum recursion limit.

opw-[5265424](https://www.odoo.com/web#id=5265424&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#239648

Description of the issue/feature this PR addresses:
- A pricelist rule never apply to a product variant, always its template when edited in "expanded" mode
- This is because the `applied_on` field is missing on the `product.pricelist.item` form view.

Current behavior before PR:
- Install `sale_management`
- Enable "Pricelist" setting
- Go to Sales - Products - Pricelists and create a new "Sample" Pricelist.
- Create 3 rules for the same product (template), one with price at 6666, a second one at 6667 and the last one at 3333 <img width="1416" height="649" alt="image" src="https://github.com/user-attachments/assets/1d50499e-cb49-4341-971c-5a2a5111b9ca" />
- Next step, edit 2 first rules for price 6666 and 6667 to set a variant **BUT before starting editing, open the form in expanded mode using two-arrows button** <img width="1416" height="889" alt="image" src="https://github.com/user-attachments/assets/056cb862-3dc6-4868-b6d3-a0917f3e7242" />
- Set the variant to the first price rule (as you can see, the rule name is immediately updated with "Variant: [REF] Product name" <img width="1421" height="428" alt="image" src="https://github.com/user-attachments/assets/168ad5fb-902b-494f-888a-419983324607" />
- Save the price rule (_note that the display name incorrectly resets to default_) <img width="634" height="370" alt="image" src="https://github.com/user-attachments/assets/ec915985-b1a3-4a69-9153-7384abdb190d" />
- Same thing for second rule  <img width="695" height="375" alt="image" src="https://github.com/user-attachments/assets/69b9ae62-493c-4f0e-ae87-438975e1bceb" /> <img width="621" height="369" alt="image" src="https://github.com/user-attachments/assets/e1dc0342-7b87-42df-bf7d-6a3aace61253" />
- Create a new sale quotation with pricelist set to our "Sample"
- Add product [6666] <img width="1207" height="420" alt="image" src="https://github.com/user-attachments/assets/07d4fb94-03b3-45ae-aeb4-feca4fee9c2c" />
- Add product [6667] <img width="1209" height="431" alt="image" src="https://github.com/user-attachments/assets/03e3a76a-2bb1-44e9-a819-ce3ca35703c7" />
- Incorrect prices in sale order <img width="1415" height="828" alt="image" src="https://github.com/user-attachments/assets/3626028d-31d0-4687-b09d-094c0212042a" />


Desired behavior after PR is merged:
- Each variant must have its own price.
- The added test simply edit the pricelist item using its own form.
- The `applied_on` field is added to the pricelist item form to ensure that its value is saved.
- If we edit the rule without expanded mode, it works fine only because the `applied_on` field exists in the list view as an invisible column.

_Note 1_: `applied_on` is updated by `_onchange_rule_content` using `update` instead of `write` (for caching ?).
But if the `applied_on` field is not on the form, then its value is never sent to low level `_write_multi`.

_Note 2_: to clear the field value with the Form test component, we must set `=self.env["product.product"]` instead of `=False` ....

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

Forward-Port-Of: odoo/odoo#245444

Current behavior:
When a user selects multiple filters (attributes) that result in multiple pages of products, navigating to the second page causes some filters to be lost. Specifically, only the last selected attribute value is kept in the URL of the pager.

This happens because the `/shop` controller processes query parameters using a standard Python dictionary (**post). Since a dictionary cannot hold duplicate keys, an URL like `?attrib=1&attrib=2` is reduced to `{'attrib': '2'}`, losing all previous values.

Steps to reproduce:
1. Install `website_sale`.
2. Reduce "Products per Page" (e.g., to 4) to easily trigger pagination.
3. Go to the /shop page.
4. Select a first attribute (e.g., Color: White).
5. Select a second attribute (e.g., Size: M).
6. Ensure the result spans at least two pages.
7. Click on page "2".
8. Observation: The second attribute filter is lost, and the product list changes incorrectly.

Fix:
Ensure that `attribute_values` are stored as a list within the `url_args` passed to the pager. Since Odoo's `website.pager` uses `url_encode` internally, passing a list of values for a single key correctly generates repeated parameters in the resulting URL (e.g., `attrib=1&attrib=2`).

opw-4152637

Currently, an error occurs when a user creates an inherited view.

**Steps to Reproduce:**
  - Go to `Settings > Technical > User Interface > Views`.
 - Create a new view by entering `name` and selecting any `inherited view`.
 - In the `Architecture`, enter the below code:
```
        <xpath position="replace">
            <field name="name"/>
        </xpath>
```
 - Now save the view.

`TypeError: Argument must be bytes or unicode, got 'NoneType'`

Cause:

As we can see, when the user enters an xpath without the expr attribute, and when it goes to find the inherited node [1]. Since the expr is missing, its value becomes None [2]. Passing this None as an argument [3] causes the error.

This commit ensures that when a user creates or edits a view with an xpath that is missing the expr attribute, a ValidationError is raised indicating that the expr attribute is missing in the XPath.

[1]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L145

[2]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L76

[3]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L78

[4]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/addons/base/models/ir_ui_view.py#L377-L384

sentry-7161414430


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

Forward-Port-Of: odoo/odoo#242203