Steps to reproduce:
1. Install website_sale_subscription
2. Enable Comparison Price from the settings
3. Create a Subscriptions product with a recurring plan and 'compare to price' > recurring price
4. Go to product page via smart button

Issue:
- The comparison price is not visible beside the recurring plan.

Cause:
- The product page updates the pricing display dynamically using client-side rendering when the subscription plan information is loaded. The XML template `website_sale_subscription.SubscriptionPricingSelect` used the <field> tag `<field name="product.compare_list_price"/>` to render the comparison price. The <field> tag is a server-side QWeb element and is not supported by the client-side Owl engine, causing the rendering to display nothing.
Additionally, client-side templates do not have automatic access to server-side field formatting (like currency symbols) when simply escaping raw values.

Solution:
- In `variant_mixin.js`, extract the already formatted comparison price text from the existing DOM element (the `<del>` tag inside the pricing selector) before the element is replaced and pass this formatted string to the rendering context. Update the XML template to use `t-esc` to display this pre-formatted string instead of using `<field>`

before:
<img width="426" height="79" alt="image" src="https://github.com/user-attachments/assets/fe34b4c5-5cd6-4877-80e3-9ed4481cd86f" />

After:
<img width="392" height="115" alt="image" src="https://github.com/user-attachments/assets/ed043fef-bfd3-46de-aeb2-1a48cacc89ed" />

opw-5248297

Forward-Port-Of: odoo/enterprise#100140

### Issue:
During the loading of fiscal position data for LATAMs the option "Use Documents" on Journals is not set-up.

### Steps to reproduce:
- Install 'l10n_ar'
- Settings > Accounting
- Make sure the "Fiscal Localization" have a value (not Argentina)
- Change the "Fiscal Localization" to "Argentine - Generic Chart of Accounts [...]"
- Go in Accounting > Configuration > Journals
- Click on "Ventas Preimpreso"
- The journal don't have "Use Documents" ticked but it should

### Cause:
When loading the data, `_get_chart_template_data()` calls `_get_ar_base_res_company()` and `_get_latam_document_account_journal()`.

The first one returns the data to change `res.company.account_fiscal_country_id` to `base.ar`. The second one [checks](https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/addons/l10n_latam_invoice_document/models/account_chart_template.py#L12) that [`self.env.company.account_fiscal_country_id.code == "AR"`](https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/l10n_ar/models/res_company.py#L36) before returning the data to change `l10n_latam_use_documents` to `True`. As `res.company.account_fiscal_country_id` has not been updated, it's not Argentina during the check and `_get_latam_document_account_journal()` returns nothing.

### Solution:
When loading the template, we cannot use `res.company.account_fiscal_country_id` to know if we are in LATAM or not. So instead we check on `chart_template`.

opw-5221931

Forward-Port-Of: odoo/odoo#237725
Forward-Port-Of: odoo/odoo#236217

Same issue already fixed for 18.4+ here:
https://github.com/odoo/odoo/pull/231399

Issue:
When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for res.bank.

Repro Steps:
1- Create invoice for romanian localization.
2- Link payment account to invoice.
3- Add bank to payment account.
4- Confirm and send invoice with "Send E-Factura SPV" checked.

Cause:
The state field is defined differently for res.bank and res.partner. res.partner uses state_id, while res.bank uses state. The code that retrieves addresses assumes the same field for both, leading to an exception when accessing state for res.bank.

Fix:
The fix checks the type of the input and selects the appropriate field (state or state_id) accordingly.

opw-5362000

(cherry picked from commit a2af8d434bfc7f77008959c8179e8f158bcf9e93)

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

Forward-Port-Of: odoo/odoo#237615

**PROBLEM**
If in an invoice you delete a taxed line, and then add an untaxed line the tax amount might not be up to date.

**STEP TO REPRODUCE**
1. create an invoice with 2 lines both taxed.
2. remove one of the line, and create a new line which is untaxed.
3. confirm the invoice and notice the tax amount is not correct (= to the tax amount with the 2 taxed lines).
Be sure to not click on the "journal items" tab, else the bug will not occur.

**ISSUE**
In _sync_tax_lines(), there is checks to know if we should recompute the tax amount, or keep the old one.
We enter the check that checks the changed lines and determine if we should recompute the tax amount. This check doesn't take into account the fact that a line could have been deleted. Because we are in a elif chain, we don't do other checks.

**FIX**
Moving up in the elif chain the check that test if a base line with tax was removed and recompute the tax amount if that's the case.

[opw-5157090](https://www.odoo.com/odoo/project/49/tasks/5157090)

Forward-Port-Of: odoo/odoo#237060

Steps to reproduce:
- Enable Multi-step routes & set warehouse to 3 steps delivery
- Make a SO for 5 qty of a stored product
- Validate the PICK
- Set the SO line qty to 3 & save
- Set the SO line qty to 5 & save

Issue:
While the first update to 3 creates a return PICK from Packing Zone -> Stock for 2 qty, the second updates does nothing.

When checking the outgoing/incoming moves to see which quantity should be set in the procurement, it only considered the outgoing quantity from the first step of the delivery.

Which means that the return wasn't taken into account, so since we only compare the new SO line qty to the already moved PICK, there was no difference thus no procurement made.

Now, we also consider less strict critera for incoming moves when checking in `strict == False` mode, as this is only used to compute the procurement quantity.

opw-5028794

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

Forward-Port-Of: odoo/odoo#237609
Forward-Port-Of: odoo/odoo#233796

**Description**

The Timesheet/Planning Analysis report (Timesheets > Planning Analysis) incorrectly calculates planned hours by not excluding employee time-off and public holidays. This results in leave days being assigned the average daily hours from planning slots and incorrectly attributed to projects.

**Steps to Reproduce**

1. Create a planning slot for an employee spanning a full month
2. Add employee time-off (resource.calendar.leaves) during that period
4. Navigate to Timesheets > Timesheets / Planning Analysis report
5. Filter by the employee and date range
6. Observe: Planned hours include leave days, incorrectly attributed to the planning slot's project

**Root Cause**

The SQL query filters by day of week (weekends) but never queries `resource_calendar_leaves`. While `working_days_count` correctly excludes leaves, the report still generates rows for those leave days and assigns them average hours per day, causing the discrepancy.

**Solution**

Filter out dates that have employee time-off or public holidays by joining to `resource_calendar_leaves` and excluding matching dates.

opw-5027070

Forward-Port-Of: odoo/enterprise#100516
Forward-Port-Of: odoo/enterprise#97657

**PROBLEM**
Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g, and it consumes 1000kg).

**STEP TO REPRODUCE**
1. create a product.
2. create a bom with:
 - a component tracked by lot, with kg as product uom, but g as the bom uom.
 - create a step, during which 50g of the component is consumed.
3. create two lots of the component, with 1kg each.
4. create a MO for the product with the bom.
5. in the shop floor, try consuming the component and select one of the lot as a source.
6. the consumed amount should be 50g, remove the move line created (pencil icon, then remove).
7. recreate the move line, the consume amount will be nonsensical (something like 1 000 000g).

**CAUSE**
1. The dialog opened for selecting the lot create a new `stock.quant` record, instead of returning the existing quant for the lot. This quant will have a quantity of 0, impacting the computation we do for the quantity we should take from this quant.
2. The formula for the quantity to take from the quant was : `max(min(remaining_qty, quant.available_quantity), 1)`. The `max(...,1)` doesn't work well when `remaining_qty` is between 0 and 1. For example, when using UoM like we do in the repro steps, `remaining_qty = 50g = 0.05kg`. But instead of taking 50g, because of the max we take 1kg = 1000g.
3. There was a double UoM conversion (`_prepare_move_line_vals` already does the conversion, so we don't need to do it before passing qty_to_take as parameter).

opw-5136050