## Dependent PR
https://github.com/odoo/enterprise/pull/98463

## Description of the issue/feature this PR addresses:
Users are blocked when trying to use the **Settle Due** feature in Point of Sale if the ZATCA (l10n_sa_edi_pos) integration is enabled.

## Current behavior before PR:
When a PoS order is created using a "Pay Later" payment method, an invoice is correctly generated and sent to ZATCA.

However, when the user later tries to settle that customer's due balance (using the **Settle Due** option), the l10n_sa_edi_pos module incorrectly forces the Invoice option to be enabled and makes the field read-only. This blocks the user because:

- Settlement orders do not contain any lines, so a new invoice cannot be generated.
- The original invoice was already sent to ZATCA, and the settlement payment should not be sent as a new e-invoice.

Thus, the user cannot proceed with the settlement.

## Desired behavior after PR is merged:
After this fix, the **Invoice** checkbox will no longer be forced or marked as read-only during **Settle Due** operations. The field will default to False, aligning with standard Odoo behavior for settlements and allowing the user to complete the payment.

task-5144679

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

Forward-Port-Of: odoo/odoo#244654
Forward-Port-Of: odoo/odoo#233769

## Description of the issue/feature this PR addresses:
The `is_settling_account` flag on a Point of Sale order is not reset to False if the user cancels a **Settle Due** operation.

## Current behavior before PR:
When a user initiates a **Settle Due** payment for a customer, Odoo creates a new order and sets the `is_settling_account` flag to True. If the user proceeds to the payment screen but then navigates back (to the product screen) instead of completing the payment, the flag remains True.

This is problematic because the user can then add regular products to this same order and check out. The order is processed as a normal sale, but it is incorrectly flagged as a settlement, which can lead to error on codes depending on this.

## Desired behavior after PR is merged:
After this fix, if a user leaves the payment screen during a **Settle Due** operation, the `is_settling_account` flag on the order will be correctly reset to False. 

task-id - 5144679

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

Forward-Port-Of: odoo/enterprise#104866
Forward-Port-Of: odoo/enterprise#98463

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

### Steps to reproduce:

- In the settings enable By-Products
- Create a product with an color attribute and 2 values: white, black
- Create a bom for that products and add 2 by product lines:
    - 1 x comp1 with a cost_share of 50% specific to the white att-value
    - 1 x comp2 with a cost_share of 70% specific to the Black att-value
#### > Try to save and you will raise a UserError: The total cost share for a BoM's by-products cannot exceed 100.

### Expected behavior:

The error should not be raised as the total cost_share is 50% for the white variant and 70% for the black one but none of them exceeds the 100% cost share.

### Cause of the Issue:

Currently the constraint does not take attribute values into accounts and simply sums the value of the cost share of all by-product lines: https://github.com/odoo/odoo/blob/bcc1397c7d694dbe61ecbd44d0320b9518df84cb/addons/mrp/models/mrp_bom.py#L201-L202

### Fix:

Just as for the total cost_share on kit products, we rely on the exclusion util and check for each existing product variant if the cost share set up is valid:
https://github.com/odoo/odoo/blob/7e81c528ae350aab4432207f5655dcfadf6ec627/addons/purchase_mrp/models/mrp_bom.py#L20-L23 see 3832793e3ce61aff0c7cf4673de84645a3469b3a

opw-5499773


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

Forward-Port-Of: odoo/odoo#245441

### Issue:
The payment method `99 – Por Definir` was used as the default value for invoices, sale orders, and POS orders
This leads to fiscal inconsistencies, especially when invoices use the `PUE` payment policy, where this payment method is invalid

### Cause:
In the `_compute_l10n_mx_edi_payment_method_id` methods, the default value was always set to `Por Definir`

### Fix:
After discussion with the PO (MIAL), the chosen solution is to archive the payment method `99 – Por Definir`and remove it as a default value
All valid cases should already be handled explicitly, making it clear to the user that something is missing when the data is blank

### Steps to reproduce:
- Install `l10n_mx_edi` and switch to the MX company
- Create an invoice with today’s invoice date
- The payment policy is set to PUE
- Before the fix, the payment method is set to `Por Definir`

For Sale Order and POS Order tests, it's the default value as soon as you create an order

opw-5406038

Forward-Port-Of: odoo/enterprise#105220
Forward-Port-Of: odoo/enterprise#104164

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

**Steps to reproduce:**
1. Install the `Accounting` module.
2. Enable cash basis taxes in
   `Accounting → Configuration → Settings → Taxes → Cash Basis`.
3. Create a tax, set `Tax Exigibility` to `Based on Payment`, and assign a
   `Cash Basis Transition Account`.
4. Create an invoice with the cash basis tax and a payment term such as
   `30% now, balance in 60 days`.
5. Record a full payment on the invoice instead of just the first installment.
6. Review the generated cash basis journal entries.

**Observed behavior:**
* Cash basis entries are created for the full tax amount, not proportionally.
* Paying the full invoice with payment terms causes duplicated tax entries.

This came from the fact that we didn't consider a move would be fully paid by
several lines at the same time, like with installments.

We now only put the leftover amount when the move is fully paid and we're on
the last partial.


Also fix the fact that paying 2 invoices at the same time in full does not benefit from the batches

opw-5061136




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

Forward-Port-Of: odoo/odoo#244733
Forward-Port-Of: odoo/odoo#236536

### Issue:
When a product has multiple attributes and one variant is archived, the product page may appear grayed out and the product cannot be added to the cart.

#### Steps to reproduce (with demo data):
1- Create a product with two attributes:
   - attribute with 3 values
   - Brand: Adidas

2- Save product to generate variants. Publish the product.
3- From variant list, archive the first variant
4- Back in product page, from attributes & variants tab, remove
   the first value. This sets `ptav_active` to False.
5- Navigate to website shop page, and add the Brand Adidas to filter
6- This should show the created product active.
7- Open the product. You will see the product is grayed out and it's
   shown inactive and cannot add it to the cart.

### Cause:
In this scenario, `attribute_value_ids` only contains values from the single-value attribute:
https://github.com/odoo/odoo/blob/da88d0a72bf4c0ec6887e53d35bf4c28b68a6a2b/addons/website_sale/controllers/main.py#L814-L824

For the multi-value attribute, no ptav matches `attribute_value_ids`, so the code falls back to selecting the first ptav: https://github.com/odoo/odoo/blob/da88d0a72bf4c0ec6887e53d35bf4c28b68a6a2b/addons/website_sale/controllers/main.py#L823

If this ptav corresponds to an archived variant, the resulting combination resolves to an inactive product.

### Fix:
Ensure the fallback logic only considers active ptavs, preventing archived variants with prav inactive from being selected.

opw-5352224

Forward-Port-Of: odoo/odoo#244049

This PR fixes 2 bugs in self order when we are dealing with variants.

The first bug in commit https://github.com/odoo/odoo/commit/0cd3a64955052b7fb5507f8fbb3414e0a894250d
The order pricelist_id was not taken into accounting when adding a line corresponding to a product variant. So any price rules acting on the variant, that are specific to the current pricelist, will not be applied.

The second bug in commit https://github.com/odoo/odoo/commit/77dbf4b2cf1b1dea3bb5ba107da83e13e5283afb
The product page was displaying the price of the default product, instead of that of the selected variant.

A third commit https://github.com/odoo/odoo/commit/bf2e3d90e3f3405db9be78acfdf2558bf47b449a was to fix `price_extra` calculations and make it consistent between the product page and the rest of the app.

I have included the steps to reproduce and more details about the fixes separately in each commit.

However, the reproduction steps are the same:
1. Make a product with 2 variants, size S and M for example.
2. Create 2 pricelists, A and B, and make them available in PoS. The
   default one should be A.
3. For the created product, create 2 price rules:
    1. One changing the price of the variant S for the pricelist B
    2. One changing the price of the variant M for the pricelist B
4. Enable mobile self order and create a peset that applies the
   pricelist B
5. Open self order, and select that preset (it should apply the
   pricelist B).
6. Select the product of step 1, and choose the variant M.

opw-5467593

Forward-Port-Of: odoo/odoo#243304

The Austrian tax report computes line 7 by subtracting the deductible input tax instead of adding it, leading to an overstated VAT payable or understated credit.

### **Steps to reproduce:**
- Install `Accounting` app with `l10n_at` localization and switch to AT Company.
- Create a customer invoice for some product with price 1000 and 20% Tax.
- Create a vendor bill for some product with price 100 and 20% Tax.
- Open the Austrian tax report for the corresponding period.

### **Observed behavior:**
section-7 shows `-220` instead of the correct amount `-180`. because value of,
section-4 = -200
section-5 = 20
section-6 = 0

Current calculation for **section-7 = section-4 - section-5 + section-6** which is equal to `-220`

### **Expected behavior:**
1) Section-4(VAT Computation (U1/U30))- negative value is correct as this is the amount of
sales tax which needs to pay to the tax office.

2) Section-5(Deductible input tax computation) and section-6(Other corrections) - are positive
values and are added to section-4 as this is the input tax which is get back from the tax office.

hence the correct calculation for **section-7 will be section(4+5+6).**
### **Root cause**
Since [commit](https://github.com/odoo/odoo/pull/224604/commits/06666fc55a7a3f569a0d15f0827ed8e2199cf51c), introduced a formula that subtracts the deductible input tax(section-5) in section-7, causing the
miscalculation.

### **Fix**
Update the section-7 aggregation formula to add deductible input tax instead of subtracting it.

**opw-5476604**

Forward-Port-Of: odoo/odoo#245174

This reverts commit 0ffb96dedc776552564cec28140340ec38dee9d1.

The commit was incomplete and while it prevented the crash, the resulting table did not match the expected layout.

Original issue:

Problem:
The grid conversion logic only finalized a row when iterating through the last column in the input list. If a row reached exactly 12 grid spans while more columns remained (e.g., a `col-12` in the middle), the logic did not start a new row. As a result, remaining columns overflowed the current row visually.

Cause:
In a single row, if a column had a size 12 and was followed by another column of any size, it would crash because the algorithm did not reset the index to the start of the next row.

Steps to reproduce:
- Add a Marketing block.
- Reduce the size of the left card from the left side.<img width="719" height="580" alt="image" src="https://github.com/user-attachments/assets/1e62eaf7-6ab1-4120-b643-62427ce3ec3a" />
- Save.
- Traceback.

Solution:
This more thorough fix properly handles all problematic aspects:
- filter conflicting `col-x` instructions on a single element to keep only one size
- ensure that a gridIndex of 12 does not cause a crash in the algo
- properly add all effective `td` in a row in all circumstances (there where cases where the final row could be omitted)

opw-5439481

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

Forward-Port-Of: odoo/odoo#245674