Issue:
Cancelled journal entries were visible in the "Journal Items to Reconcile" view (action_move_line_posted_unreconciled) because the action domain had no filter to exclude them. This caused reconciliation failures, no reconciliation happened, and the cancelled record remained in the view.

This regression was introduced during a refactor to allow draft entries in the reconciliation view, where the posted-state condition was removed from the domain:

Enterprise commit: https://github.com/odoo/enterprise/commit/003cffabda7d91a6d10d58942ed972ca5e17366d

As a result, cancelled journal items also became visible, causing reconciliation attempts to fail while the records remained in the view.

Also, we are not allowed to reconcile cancelled move lines, and we already
have the validation for this [here](https://github.com/odoo/odoo/blame/a236f67776616f6facdefb0117a6ffdde9b7c84c/addons/account/models/account_move_line.py#L2627)

Issue is reproducible on runbot. Here is the video reference: https://drive.google.com/file/d/1ojIDxHn5Yst8gVFy8JyhwtJoDSSSJsmK/view?usp=sharing

- OPW: 6247870

Forward-Port-Of: odoo/enterprise#119017
Forward-Port-Of: odoo/enterprise#118773

Refund orders use a display name based on the original ticket. The rectificativa was then submitted with a duplicate Serie/NumFactura and rejected with TicketBAI error 5040.

Steps to reproduce:
-------------------
* Enable TicketBAI for a Spanish company with POS
* Create an order and complete payment (TicketBAI sent)
* Refund that order from the POS and complete payment
* Open the new TicketBAI XML (downloadable on the order in the backend)

> Observation:
`CabeceraFactura` `NumFactura` matches the original sale; tax authority returns 5040 (duplicate invoice for same issuer/series/year).

Why the fix:
------------
The TicketBAI document `name` was set from `pos.order.name`, so `_get_tbai_seq_from_name` extracted the same numeric part as the original sale. `l10n_es_edi_tbai.document` derives Serie/Num from `name` via `_get_tbai_seq_from_name`. Refund POS names intentionally echo the original order label, so we derive the document name from the same components as non-refund orders (`get_reference_last_part()`), which is unique per receipt.

opw-6067965

Forward-Port-Of: odoo/odoo#257475

Steps to produce:
---
- Install `website_sale` module.
- Create a product with a variant and add the images from the sale tab.
- Go to the product on the e-commerce and change the variant.
- Attempt to scroll through the product images (using the mouse wheel).

Issue:
---
- After changing a product variant on the eCommerce product page, attempting to scroll through the product images (using mouse wheel) has no effect.

Root cause:
---
- When a product variant is changed, `_updateProductImage` dynamically replaces the product image carousel DOM element (`#o-carousel-product`) by injecting new HTML and removing the old one.
- The old CarouselProduct interaction instance remains in memory, causing a resource and event listener leak on the detached old DOM element.
- The newly inserted `#o-carousel-product` element is ignored by the interaction service, meaning that the CarouselProduct interaction is never initialized on the new carousel. This leaves the new carousel static and unresponsive to user interactions.

Solution:
---
- Before replacing the carousel DOM node, manually notify the public.interactions service to clean up any active interactions on the old element. After the new DOM node is queried, start the interactions on the new element.

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

Forward-Port-Of: odoo/odoo#265537

**Description of the issue/feature this PR addresses:**

When generating a SEPA QR code for a vendor bill payment, the embedded 
amount could occasionally contain excess decimal places instead of 
respecting the currency's expected precision.

This occurs because the `amount` variable in `_get_qr_vals` was being 
converted directly using `str(amount)`. Due to Python's floating-point 
arithmetic, the float value in memory can contain decimal drift.
Directly casting it to a string exposes this drift in the payload.

This commit resolves the issue by replacing `str(amount)` with 
`float_repr(amount, currency.decimal_places)`. This safely bypasses 
the float representation issue, ensuring the string strictly respects 
the currency's configured decimal precision before being injected 
into the QR code.

opw-5504258

**Steps to reproduce:**

- Select company “My Belgian Company”
- Create a 23% purchase tax
- Create vendor bill
   - Select Vendor “BE Company CoA”
   - Choose any single product, change price to 37.18 and choose the 23% tax. The Untaxed Amount should be 37.18, VAT tax should be 8.55, and Total should be 45.73
   - Confirm > Register Payment > scan QR code. EUR45.730000000000004 should show

**Current behavior before PR:**

- When generating a SEPA QR code for a payment, the embedded amount can contain excess decimal places due to floating-point drift.

**Desired behavior after PR is merged:**

- The SEPA QR code is generated with the correct number of decimal places.

Forward-Port-Of: odoo/odoo#267293

Steps to Reproduce
---
1. Open the Planning module
2. Create an open shift with allocated_hours
3. Click Auto Plan
4. Click Undo on the auto-plan notification

Issue
---
Undoing an auto-plan operation triggers recomputation of allocated_hours,
causing the shift to lose its original workload value.

Current Behaviour
---
When resource_id is set to False during undo:
- _compute_allocated_hours is triggered (depends on resource_id)
- _compute_allocated_percentage is triggered (depends on allocated_hours)
- Both fields are recalculated, potentially changing allocated_hours
  from its pre-assignment value

Expected Behaviour
---
Undoing auto-plan should preserve allocated_hours at its pre-assignment
value while allowing allocated_percentage to adapt to the new context
(open slot vs assigned resource).

Fix
---
Use protecting context manager in action_rollback_auto_plan_ids
to prevent allocated_hours from being recomputed when resource_id is
removed. This allows allocated_percentage to recalculate naturally based
on slot duration while keeping allocated_hours stable.

task - 4952149

Forward-Port-Of: odoo/enterprise#119772
Forward-Port-Of: odoo/enterprise#102864

Steps to reproduce
---
1. Register a grouped customer payment over several invoices, leaving one of them only partially paid.
2. Register a second grouped payment over two invoices: the partially paid one and a brand new invoice.
3. Open the first payment, its "Reconciled Invoices" smart button now lists the new invoice from the second payment, which it never paid.

Issue
---
The smart button is built from the stored `invoice_ids` many2many, which shares its relation table with `account.move.matched_payment_ids`. After reconciling, the register wizard links the payment to its invoices with `lines.move_id.matched_payment_ids += payment` at https://github.com/odoo/odoo/blob/f726393267a28cedd5febd2106de17ae3838f3ff/addons/account/wizard/account_payment_register.py#L1212.

When the payment groups several invoices, `lines.move_id` is a multi-record recordset. Reading `matched_payment_ids` on it returns the union of the payments already linked to all those invoices, and `+=` writes that union back to every invoice as a `(6, 0, ...)` replace command. So an invoice already paid by an earlier payment spreads that earlier payment onto every other invoice grouped in the new one, including brand new invoices, which then wrongly appear on the earlier payment.

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

Forward-Port-Of: odoo/odoo#267968

Issue:
When the sales price is changed from the product variant form for a product without configured variants, the price is updated only on `product.product.lst_price`. The main product form, opened from Inventory > Products, displays `product.template.list_price`, which remains unchanged. The same issue is visible from Purchase Orders because the product internal link on a purchase order line opens `product.product`, while the product page opens `product.template`.

Steps to reproduce:
- Create or open a product without configured variants
- Open product variant form from the internal link in a purchase order
- Change the Sales Price on the product from there
- Open the product from Inventory > Products (`product.template`)
- The template Sales Price still shows the old value

Cause:
Since version 19.1, `product.product.lst_price` is an editable stored field, allowing variant-level prices to differ from the template price. This is correct for products with multiple variants, where each variant may have its own sales price. However, for products with only one variant (the product itself), no synchronization was performed from `product.product.lst_price` back to `product.template.list_price`, leaving both product forms inconsistent.

Solution:
- Add `_inverse_product_lst_price` on `product.product.lst_price` so that When `lst_price` is written and the template has exactly one variant, set `list_price` to `lst_price` (delegates to the template)

opw-6260015

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

Steps to reproduce:
- Create a storable product “P1” with Lot tracking
- Enable routes: MTO + Manufacture
- Create a BoM for the product:
    - Component: C1
- Configure the warehouse with 3-step manufacturing
- Have on-hand stock in WH/Stock with Lot 001
- Confirm a Sales Order for the product
- Confirm the generated Manufacturing Order and produce Lot 002
- In the "Store Finished Products" transfer, change the destination location from WH/Stock to WH/Stock/Shelf 1 and validate
- Check the Delivery Order reservation

Problem:
The move is reserved with Lot 001 instead of 002

When using a 3-step manufacturing flow (MTO + Manufacture), if the user manually changes the destination of the "Store Finished Products" transfer to a sublocation of WH/Stock (e.g. WH/Stock/Shelf 1), the MTO link between the production and the delivery order was incorrectly broken, causing the delivery to reserve existing stock instead of the freshly produced lot.

Root cause: `_skip_push()` only skipped push logic when the downstream move's source was a child-or-equal of the current move's destination (`m.location_id._child_of(self.location_dest_id)`). When the destination was changed to a sublocation (WH/Stock/Shelf 1), this check failed, so `_push_apply()` ran, found the delivery's source (WH/Stock) was not a child of WH/Stock/Shelf 1, and called `_break_mto_link()`, clearing `move_orig_ids` on the delivery move. The delivery then fell back to make-to-stock reservation and picked an unrelated lot.

opw-6197212

Forward-Port-Of: odoo/odoo#268783

### Issue
Since the introduction of the Tax Returns feature in 18.3, it was no longer possible to generate a Closing Entry as the button has been replaced by Returns
The Return mechanism implies that you need a Return Type in order to make a Closing Entry using the Validate button

Additionally, using the Generic Tax Report by default creates a risk in Multi-VAT environments, as it mixes taxes from all countries instead of isolating Peruvian taxes

### Cause
The new 18.3 accounting workflow requires at least one active Return Type associated with a country-specific report variant to display the Return options and process the closing entry Peru was relying on the Generic Tax Report, without a dedicated report variant
No Return Type was configured, which blocked Odoo's automatic VAT closing workflow and prevented the system from prompting the user to configure the required closing accounts

### Steps to reproduce
- Install `l10n_pe_reports` and `accountant`
- Switch to a PE Company
- Go to the Tax Report

Before the fix, no Returns button is available for any of the existing reports, making it impossible to use Odoo's automatic process to configure the tax accounts and trigger the closing entry

### Notes
This is fixed by creating a dedicated Peruvian tax report variant directly in Enterprise that inherits from the generic tax report A custom handler is added to force the domain filtering on Peruvian taxes only, and a corresponding Return Type is defined to restore the full closing entry process safely

opw-5978673

Forward-Port-Of: odoo/enterprise#117891

Scenario:

- set up turnstile
- with recent safari mac os or ios (reproduced from 26.2) go to
  /web/login page in a private window
- enter login and password and pass the turnstile challenge
- click on Log in

Result: nothing happens and there is an error in the console "An invalid
form control with name='' is not focusable."

Cause:

By default Safari has the Settings > Advanced > "Use advanced tracking
and fingerprinting protection" set to "in Private Browsing".

If this options is enabled in private browser or in all browsing, you
can't login to Odoo with turnstile because safari is preventing the
update of the element that is preventing to send the form:

<input style="display: none;" class="turnstile_captcha_valid" required>

When turnstile challenge succeeds, a value should be set to this input
that will unlock the form, the .value property is updated but the
browser Shadow Content is not (and if we remove display:none, the input
is empty).

Fix:

I've not been able to reproduce the issue without turnstile using same
situation and iframe. We don't know Safari heuristic but the unlocking
is working if:

- we use setProperty instead of .value
- we unset required
- we remove the input
- we display the turnstile_captcha_valid input before challenge

This fix replaces setting .value by setProperty, and add a failsafe of
unsetting required.

opw-5917286
fixes #247536

Forward-Port-Of: odoo/odoo#253367

## The Problem
When computing a future leave balance, `_get_future_leaves_on` triggers
`_process_accrual_plans`, which iterates period by period and calls
`_get_leaves_taken` at each step. `_get_leaves_taken` re-enters
`_get_consumed_leaves` with `ignore_future=True`, but other accrual
allocations on the same employee were not guarded by `precomputed_allocations`,
causing `_get_future_leaves_on` to fire again for each of them, launching
another full accrual run recursively. With N periods and K allocations,
total work grew as $O(N^K)$.

## The Solution
Adding `not ignore_future` to the guard prevents future projection in any
nested context where it is both semantically incorrect and the source of
the blowup.

---

## Benchmarks
*Tested on a customer database with an employee having 2 accrual allocations and
pending future leave requests 6 months out:*

| | Queries | Request Time | Improvement |
| :--- | :--- | :--- | :--- |
| **Before** | 220K | 145.0s | — |
| **After** | 2.7K | 2.8s | **-98%** |

**Note:** More optimizations could be done to reduce the queries to a constant. However given the current design, it would be a bit big change and the current performance is already acceptable.

**OPW-6115804**

Forward-Port-Of: odoo/odoo#261172

**Steps to reproduce:**

- Install pos_mrp
- Make a BoM for a product
- The product must have a custom attribute, of type always
- Go to the PoS
- Make a sale, with a customer, enable Ship Later
- Go to the created MO
- The Custom Description field is not showing

**Why the fix:**

This fix was previously done by e53dae2 but it did not account for the other variants and only did the fix for the never attributes.
This is because it seemed to work with other kinds of attributes until 19.0

We now also compute the move description if we have a custom attribute. We need the never variants to have a description as well, as it is done in the sale module. This commit basically aligns the behavior to the on done in the sale module.

A test had to be changed, as we now write the description in a different way, to make it the same regardless of where the picking and moves were created from. We now won't see a difference on the MO between one created from the POS and one created through the sale module.

opw-6169257

Forward-Port-Of: odoo/odoo#263350

The display name of the account.report.line in the general ledger report has the format of:

INVOICE NAME (invoice refs)

In the case where a client has hundreds of sales orders batched to a single invoice, the ref can
become extremely long, e.g.:

INV/2026/00001 (S12123, S12152, S12159, S12140, S12165, S12161, S12162, S12110, S12099, S12124, S12145, S12128, S12114, S12131, S12097, S12185, S12154, S12133, S12190, S12118, S12116, S12102, S12155, S12153, S12158, S12150, S12100, S12142, S12121, S12122, S12111, S12187, S12172, S12177, S12095, S12117, S12144, S12137, S12092, S12138, S12186, S12182, S12112, S12148, S12183, S12101, S12178, S12119, S12169, S12115, S12146, S12093, S12126, S12160, S12163, S12129, S12098, S12151, S12096, S12174, S12120, S12130, S12147, S12180, S12191, S12164, S12141, S12105, S12136, S12139, S12109, S12106, S12104, S12103, S12175, S12179, S12188, S12113, S12173, S12167, S12171, S12134, S12094, S12184, S12166, S12170, S12125, S12135, S12143, S12176, S12189, S12156, S12181, S12107, S12157, S12132, S12149, S12127, S12108, S12168...)

Because the length of the account.report.line is unchecked in account_general_ledger.py label
builder, the pdf can clog to one or two account.report.lines per page, skyrocketing the pdf page length.

As wkhtmltopdf processes the report from html to pdf it makes a system call openat() to the /tmp/report.footer.tmp.x.html file for EACH page of the pdf. You can see the TODO comment in the spoolTo function in wkhtmltopdf (both in Odoo and the original repo) saying that the header and footer need to be freed, on each page processing, not just null pointed.

https://github.com/odoo/wkhtmltopdf/blob/2c884bd1545b8a639847de22f24754ee5a6fc44c/src/lib/pdfconverter.cc#L794

I verified that that the number of openat calls to the /tmp/report.footer.tmp.x.html file equals the exact number of pages in the pdf to be generated if the report HAD generated successfully by setting the footer input into
_run_wkhtmltopdf to None, generating the report without footers, then separately running an strace on wkhtmltopdf when the report fails to generate. See related ticket linked at bottom.

The linux machine used on sh instances has a ulimit -n of 1024 file descriptors. Because
the footer file descriptors accumulate, once a pdf has about 1010+ pages (~a dozen fd's are allocated for other purposes), over 1024 file descriptors are opened and the system fails with:

Wkhtmltopdf failed (error code: -6). Message:
QEventDispatcherUNIXPrivate(): Unable to create
thread pipe: Too many open files
QEventDispatcherUNIXPrivate(): Can not continue
without a thread pipe

Since wkhtmltopdf is archived and Odoo has a replacement in development, I suggest that we limit the display_name of the account.report.line to 200 to keep the bloat minimized, preventing one account.report.line's name from taking up an entire page of the general ledger pdf. This allows many more batched invoices to be shown in the report and a much greater time range of data to be printed without hitting the fd limit.

I suggest changing it at the general ledger report level rather than in the account.move.line
_compute_display_name function, as we probably still want to see the full display_names at the invoice level.

On runbot, the machine has different memory constraints than on sh / local, so it hits the following error before the one above:

Wkhtmltopdf failed (error code: -11). Memory limit too low or maximum file number of subprocess
reached. Message :

Steps to Reproduce on 19.0 newdb:

1. newdb -n test_gl -v 19.0
2. ensure ulimit is set to 1024 in shell that runs odoo instance by running ulimit -n 1024 to
mimic ulimit of sh environment
3. run db with python3 odoo-bin, ensuring high enough memory constraints to simulate multi
worker sh instance, i.e.
--limit-memory-soft=12884901888
--limit-memory-hard=1288490188
4. install sales, accounting, stock
5. install demo data
6. create invoices with 100+ associated sales orders
7. generate the pdf
8. Increase the amount of invoices till the general ledger page count hits ~1010+, where you will
hit the error.

Notes:
opw-ticket-6201508

closes #118067

Forward-Port-Of: odoo/enterprise#118067