**Issue**
In shopfloor, a traceback occurs when clicking on the add button if the associated operation has a `quality_check` of type `register_consumed_materials`.

**Steps to reproduce**
1. Create two products (product and component)
2. Create a BOM for this product that consumes that component
3. Create an operation linked to that BOM (Manufacturing > Configuration > Operations)
4. Add a quality check of type “Register Consumable Material” for this operation
5. Create a MO from that BOM and confirm it
6. Click on the shopfloor smart button → If debug mode is activated, a traceback occurs → Otherwise
7. Click on the 'add' button → A traceback occurs

**Cause**
In the method [`subRecordProps`](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L190C9-L194C14), when a quality check of type `register_consumed_materials` is done, the variable `production` is not propagated into the props. And [this](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L184) tries to access the production in the props, which is [called](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163) when the user clicks the 'add' button.

**Solution**
Add the `production` variable to the props.

opw-5165259

**Steps to Reproduce:**

1. create test ``Float`` field in model ``A`` with ``digits`` args
2. create ``Many2One`` field with comodel ``A``  and then create Float Field in ``B Model`` with related ``A`` model test and store True

**Issue:**
  1. ``column_type`` for both model table will be different. For ``test field in model A`` the ``column_type`` will be ``numeric``. But for the related field ``column_type`` ``float`` it should be ``numeric``. This happen because the @lazy_propery it hold the ``column_type`` which is ``float8`` and other related attributes from ``setup_related`` before that ``_digits`` have the null value. So, from [here](https://github.com/odoo-dev/odoo/blob/a9398502260fa57573b88fd62ca3f554e0685c7b/odoo/fields.py#L772) it remains ``float8`` it should update with ``numeric``

   **Second issue comes From odoo 18.3**:=

during upgrade if any new ``module`` is intalled due to dependency change and inherits the same model that is ``A``. 
Due to ``_auto_init`` it will recompute this related field  because due to this newly [commit](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808) clear the columns column becomes [``False``] and [``not column``] becomes true  from ``update_db`` and same reason as above  it didn't return from [here](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808#diff-956d895aa67961bac940841f7c3d1e10eb8ecabec82ef017803c4a6a3bb7cd22R1074) because column type is ``float8`` which leads to  memory of unecessary compute which shouldn't do in first place.

**FIX:**

Remove the ``column_type`` and let it get again as soon ``_digits`` attribute add.

before fix:-
```
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id';
 column_name  |    data_type
--------------+------------------
 test_line_id | double precision
(1 row)

```

After fix:-
```
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id';
 column_name  | data_type
--------------+-----------
 test_line_id | numeric
(1 row)

```
opw-5222760
upg-3253635

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

Forward-Port-Of: odoo/odoo#237050
Forward-Port-Of: odoo/odoo#235112

**Steps to reproduce:**
1. Install Inventory.
2. Open Inventory → Configuration
3. Barcode Nomenclature and select the default GS1 Nomenclature.
4. Open Barcode → scan the code:154105510000000244.

**Observation:**
- Scanning a GS1 barcode with an invalid date crashes Odoo and raises a traceback.

**Cause:**
- The translated ValidationError message uses the wrong interpolation syntax:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L58
and therefore fails during rendering.

- Correct syntax should be:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/account/models/account_move.py#L5647

**Fix:**
- Fix faulty interpolation placeholder in  ValidationError message to use `%(error_message)s` instead of `'%(error_message)'`, preventing the traceback and allowing the error message to display correctly.

**opw-5253564**

Forward-Port-Of: odoo/odoo#236858

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

In the Accounting app, users can print checks created to
pay Vendor Bills. When using any of the US Checks Layout (from
`l10n_us_check_printing`), the payment date would overlap
the table beneath it when the journal's manual sequencing option was
disabled.

<img width="1201" height="624" alt="image" src="https://github.com/user-attachments/assets/cd3aa46a-1952-4652-9034-e4bc2ea9a44d" />

This occured because the `.summary_line` container collapsed to a height
of 0 whenever its first child wasn't displayed, as the remaining child
elements are absolutely positioned and therefore do not contribute to
the parent's height.

https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/l10n_us_check_printing/report/print_check.xml#L24-L34

By assigning a minimum height to the `.summary_line` class, we make sure
that it always occupies space above the table, even when only the date
is shown.

### Steps to reproduce:
**/!\ To reproduce the bug locally, you must have a version of wkhtmltopdf with patched qt. Use `wkhtmltopdf -V` and make sure that _"(with patched qt)"_ is specified after your wkhtmltopdf version.**
1. Install Accounting (`accountant`) and US Checks Layout (`l10n_us_check_printing`)
2. In Settings > Accounting, toggle on *Checks* if it is not, and set *Check Layout* to any "US" layout.
3. Go to Accounting > Vendors > Bills
4. Create a new Vendor Bill:
    - Set any Vendor
    - Set any Bill Date
    - Add any Product (with a positive price, the total price of the bill must be positive)
    - Confirm
5. Click *Pay*, set the *Payment Method* to *Checks* and click *Create Payment*
6. Click on the *Payments* smart button
7. Click *Print Check* > *Print* (> *Continue*)
8. In the generated PDF, the date overlaps the table beneath it.

This fix moves the date right above the table.

<img width="1189" height="634" alt="image" src="https://github.com/user-attachments/assets/8858098e-b39b-4ad2-aa65-cc0cea550343" />


opw-5165112

Forward-Port-Of: odoo/enterprise#100487

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

### [FIX] website: copy the whole document to fallback iframe

Since da85d7f8f39f43bd21603b40f357dfc572036d27, the style in head and
the body of the website preview are copied to the fallback iframe's
document. This did not copied the attributes on the `html` node, which
somtimes impacted the appearance.

With this commit, the whole document is copied to the fallback iframe.

Steps to reproduce:
- Activate "Mobile preview" when viewing the website
- Go to a page that is long enough for a scrollbar to appear
- Navigate to another page
- Bug: During the transition, the fallback is shown, and its scrollbar
  is wider than the one of the page that was shown just before

task-5212287

### [FIX] website: remove content of fallback iframe after load

Since commit 7b19831e1c624b483008feb526ba773ec8b23009, an fallback
iframe is shown behind the website preview to avoid flicker on
navigation. Since commit 3036c7dc4720a88f2717b96a29d45d923eb6ec75, the
preview for mobile has some transparency on its scrollbar. Thus the part
of the fallback iframe behind the scrollbar when previewing mobile was
slightly visible.

This commit fixes it by removing the fallback iframe's content after the
website has loaded (and the fallback is not needed anymore).

Steps to reproduce:
- On website, activate "Mobile preview"
- Navigate to a page long enough to have a scrollbar
- Navigate to another page long enough to have a scrollbar
- Scroll a bit
- Bug: The scrollbar of the fallback is slightly visible

task-5212287

Forward-Port-Of: odoo/odoo#233373