As the system now starts to be used by real users, we noticed a few points of improvement that can easily be done in stable and will provide a better UX when interacting with the system.

The payment proof as a field was a consequence of multiple iterations of the system; but it ended up only as a way to input the proof and nothing else.
It is confusing, only allows one proof at a time, and is overall not nice to use.
To improve that, we will remove the field and replace it with an 'Attach Payment Proof' button similar to the expense app, allowing for a better experience.

The similar rental check was checking even if all the related fields were empty. On a database migrating from a previous version, this leads to ALL the rentals to be marked as similar, which isn't ideal.
The same check was also comparing multiple rentals from the same employee as long as they are active. As rentals for an employee cannot overlap, it makes no sense to check this case and cause false positives.

task-6448054

Forward-Port-Of: odoo/enterprise#126764

In this commit:
------------------
- Maintain separate Fiskaly transaction flows for retail (short tx) and restaurant (long tx)
  orders as discussed with the Fiskaly team.
- `Initialize order transactions` with an empty payload when the `first product` is added.
- Start `receipt transactions` with an empty payload when the `first payment line` is added.
- For retail flows, no intermediate order updates are sent to Fiskaly before finalization.
- For restaurant flows, create additional transaction updates during kitchen synchronization.
  Ensure already synchronized products are not resent, and only newly added or updated
  quantities are included in the payload.
- `Finalize order and receipt transactions` with complete order lines and payment details
  when we validate the order.

task: 6208963

Reference:
<img width="1863" height="1285" alt="de_tss_flow" src="https://github.com/user-attachments/assets/9140788e-7948-4a08-9f11-27197b22ca8b" />

Forward-Port-Of: odoo/enterprise#120529
Forward-Port-Of: odoo/enterprise#117526

When using the click & collect option, the available qty for renting was not taking the selected warehouse into account.

Steps to reproduce:
-------------------
* Create 2 different warehouses with 2 different adresses
* Create a product available for renting
* Setup the product to use serial numbers
* Create 2 serial number, 1 in each warehouse
* Activate the click & collect option on the website
* Create a first sale order to collect in warehouse 1
* In the backend, confirm the order and pick it up
* Go back to the website and make a second order for the second warehouse
> Observation: When clicking on the "Add to cart" you get an error
  saying that there is no quantity available

Why the fix:
------------
When computing the `product_rented_quantities` it would look for `sale.order.line` in all the warehouse. So it would find the line from the first order even if it's not linked to the selected warehouse. So we just add a new element to the domain to filter out the incorrect warehouses.

opw-6328475

Forward-Port-Of: odoo/enterprise#126817
Forward-Port-Of: odoo/enterprise#124969

**Before this change**
We have the potential to attempt to send a notification email from virtual records created by our `BaseModel.new()` method. This can happen during an `onchange` request, given that we'll be working with a virtual "snapshot" record to recompute potentially changed values for our origin record after a change to one or more values.

This issue manifests when using Studio to attach a many2many field to a form view, where the related model is "Approval Request". If an approval request record in either the "Approved" or "Refused" state is attached to our record via this new Studio field, any `onchange` requests will trigger this bug. This is because we can't send messages on a virtual record.

**After this change**
Prevent the creation and sending of a message if we are computing the request status of a virtual `approval.request()` record. The field `request_status` on this model is computed and stored, but the fact that it is a computed field means that it must be recomputed for a virtual record, even if the origin record already has a stored `request_status`. Thus, we may need to compute a `request_status` value for an ephemeral "snapshot" record.

Though the issue only manifests for the "Approved" and "Refused" states, this PR expands on a test that covers every approval request state.

opw-6390453

Forward-Port-Of: odoo/enterprise#125374

Issue:
In accrual list reports (Billed Not Received / Invoiced Not Delivered), selecting an "As of" date, opening a line, and returning with the breadcrumb resets the date filter to the default value (today's date)

Steps to reproduce:
1) Open an accrual list report ( Accounting > Audit > Purchases > Bill to receive / Billed Not Received OR Invoices to be issues / invoiced Not delivered)
2) Pick any "As of" date
3) Open any row
4) Click breadcrumb to return to the accrual list
5) Observe the "As of" date has been reset to today's date
To generate some data you could:
create a PO, then upload the bill, validate the receipt, then you'll find it in bills received

Cause:
`AccrualListController.setup()` always initialized state.date with a fresh default date and did not re-put the previously saved `accrual_entry_date` from restored context
https://github.com/odoo/enterprise/blob/899f0d45b2ae1dc4e5e06a2e0acb3d006d12d563/account_reports/static/src/views/accrual_list_controller.js#L10-L16

Although `setDate()` stored the selected date in context, `setup()` overwrote the UI state on controller recreation
https://github.com/odoo/enterprise/blob/899f0d45b2ae1dc4e5e06a2e0acb3d006d12d563/account_reports/static/src/views/accrual_list_controller.js#L61-L65

Solution:
- Persist `accrual_entry_date` in `AccrualListSearchModel` via `exportState()` / `_importState()`, so the date is restored in search context before the list model loads on breadcrumb navigation.
- Initialize the date picker through `setDate()` in `onWillStart()` instead of hardcoding `DateTime.now()` in `setup()`, so restoration and user changes share the same code path.
- In `setDate()`, reset grouped list caches (`currentGroups` and `groups`) before `root.load()`, because those caches are not keyed on `accrual_entry_date` and would otherwise show stale vendor groups after a date change or breadcrumb restore.

opw-6232263


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

Forward-Port-Of: odoo/enterprise#126688
Forward-Port-Of: odoo/enterprise#118669

Currently, an error occurs when user tries to install `website_sale_subscription` after deleting the monthly subscription plan.

Steps to replicate:
- Install `sale_subscription`.
- Open Subscription > Configuration > Recurring Plans.
- Delete the plan named `monthly`.
- Install `website_sale_subscription`.

Error:
```
ValueError: External ID not found in the system: sale_subscription.subscription_plan_month

odoo.tools.convert.ParseError: while parsing /home/odoo/odoo19/enterprise/website_sale_subscription/data/donation_data.xml:16, somewhere inside
<record id="product_recurring_donation_pricing_monthly" model="product.pricelist.item">
            <field name="plan_id" ref="sale_subscription.subscription_plan_month"/>
            <field name="product_tmpl_id" ref="product_recurring_donation"/>
            <field name="fixed_price">1.0</field>
            <field name="pricelist_id" eval="False"/>
        </record>
```

Cause:
- Error is raised when assigning the `Monthly` subscription plan in the `website_sale_subscription` master data because the user has deleted the `Monthly` subscription plan.

Solution:
- As the `plan_id` is not a required field, we can skip assigning the `plan_id` if it the record is not found.

sentry-7441124574

Forward-Port-Of: odoo/enterprise#125649

### Description of the issue/feature this PR addresses:
This PR fixes an issue in the Sign module where replacing a document breaks the link between a signer and their multiple signature fields, causing Odoo to erroneously generate separate signers for each individual field.

### Current behavior before PR:
When a document with multiple signature fields assigned to the same person is replaced, the _copy_sign_items_to function duplicates the sign.item records. During this duplication process, Odoo duplicates the old responsible_ids, creating copies with new ids. These new copies overwrite the old responsible_ids, ensuring that the newly created sign_items have entirely new responsible_ids. 
Because a shared responsible_id is the primary key Odoo uses to group multiple signature items under a single signer, this change in ID causes the system to lose the grouping. As a result, Odoo treats each copied field as belonging to a completely new, separate signer. 

_Note_:
Because of the limitation mentioned before, any responsible_id that is passed through the copy function, and thereby the copy_data function, is overwritten with new ids. The only work-around then is to update the responsible_id value attached to the new_sign_item after the copy_data function has completed and the new_sign_item has been created. 

### Desired behavior after PR is merged:
The original responsible_id is explicitly carried over and assigned to the newly copied sign.item immediately after the copy operation completes. This ensures the copied signature fields retain their original role IDs and grouping, keeping them correctly assigned to the single original signer.

opw-6354334

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

Forward-Port-Of: odoo/enterprise#123628

Clicking a slot on an appointment type with a non-ASCII name (for example an Arabic title) puts the browser in an endless 301 loop, so the info form never opens.

### Steps to reproduce

- Create an appointment type with an Arabic name, e.g. `عنوان`.
- Open its page and pick a time slot.
- The browser keeps redirecting on `/appointment/<slug>/info` and fails with "too many redirections".

### Cause

The info URL is built from the slug `<name>-<id>`, here `عنوان-1`. We build a `URL` with `encodeURIComponent(slug)`, so `url.href` is already encoded once (`عنوان` becomes `%D8%B9...`). But we then navigate with `encodeURI(url.href)`, and `encodeURI` escapes the `%` signs a second time, so `%D8%B9...` becomes `%25D8%25B9...`. The slug is now encoded twice.

To canonicalize the URL, the server decodes the request path and the path it rebuilds from the route, once each, and redirects if they differ. For a normal URL they are equal. For ours they are not, because one side is decoded one step less than the other, so the server keeps answering 301 with the same double-encoded URL. An ASCII slug has no `%` for `encodeURI` to escape, so only non-ASCII names hit this.

### Fix

Navigate to `url.href` directly. It is already encoded, so the extra `encodeURI` only broke it. Same fix on the manual resource confirmation path.

opw-6409641

Forward-Port-Of: odoo/enterprise#126852
Forward-Port-Of: odoo/enterprise#125497

**Steps to reproduce:**
* Install the **Netherlands - SBR** (`l10n_nl_reports_sbr`) and **Netherlands - SBR OB Nummer** (`l10n_nl_reports_sbr_ob_nummer`) modules.
* Create two companies with Dutch localization.
* Go to **Accounting → Configuration → Tax Units** and create a Tax Unit with its own **Tax ID** (e.g. `NL826317558B01`), adding both companies.
* On the main company form, fill in the **Omzetbelastingnummer** field (e.g. `123456782B90`).
* Go to **Accounting → Reporting → Tax Return**, select the Tax Unit in the filter, and click **XBRL → Download XBRL File**.

**Observed behavior:**
* The `<xbrli:identifier>` in the exported XBRL file contains the company's **Omzetbelastingnummer** (`123456782B90`) instead of the Tax Unit's VAT (`826317558B01`).
* The tax authority rejects the return because the identifier does not match the fiscal unity registration.

**Cause:**
* `_get_sbr_identifier()` in `l10n_nl_reports_sbr_ob_nummer` unconditionally returns `self.env.company.l10n_nl_reports_sbr_ob_nummer` before consulting the Tax Unit.
* The `super()` call, which correctly routes to `tax_unit.vat` via `report.get_vat_for_export()`, is only reached when the company field is empty — so the Tax Unit's VAT is never used when a company OB-number is set.

**Fix:**
* When a Tax Unit is active in the report options, delegate immediately to `super()._get_sbr_identifier()`, which resolves `tax_unit.vat` through the existing `get_vat_for_export()` logic.
* The company-level `l10n_nl_reports_sbr_ob_nummer` override is preserved as a fallback for the `company_only` (no Tax Unit) case.

opw-6350840

Forward-Port-Of: odoo/enterprise#126999
Forward-Port-Of: odoo/enterprise#125167

**Steps to reproduce:**

- Enable "Move Entire Packages" setting on deliveries
- Make a product A, that has a package P1, on hand qty of 1
- Make product B that don't have a package, but on hand qty of 1
- Make a delivery that has both of those products, requested qty of 1 for both
- Mark it as todo
- Go to the barcode app, select the delivery
- Select the line with product B
- Select the line with product A
--> The line with product B is not unselected

**Why the fix:**

When we have a mix of packaged products and products without a package on the same operation, they are handled separately.
The products without a package are handled in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L388-L392 
that calls https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1277-L1284 
But as you can see, there are no mention of the selected package line, which is stored in **this.lastScanned.packageId**.

As we do not touch this variable, the selected package line stays selected.

The same is true for the other way around, when we select a package line we call https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L394-L398 
This function does not care for the **selectedLineVirtualId** which represents the selected line without a package.

To avoid this and make it so that only one line is selected even if they have different package, we now set the corresponding value to false to unselect the other line in all situation.

This is basically how it's done in https://github.com/odoo/enterprise/blob/98c79af3fb6cb354f46fd2f58e642a72a9271443/stock_barcode/static/src/models/barcode_model.js#L1202-L1208 
to unselect every line regardless of packages.

opw-6266203

Forward-Port-Of: odoo/enterprise#126790
Forward-Port-Of: odoo/enterprise#122038

When a user chooses the "Double Opt-in" template (or others using
`_create_records_with_xml_ids`), the system creates records like the
"Confirmed contacts" list and a server action. It also adds an
`ir.model.data` entry for them under the module, but sets
`noupdate=False`.

The problem is that during a module upgrade, Odoo's cleanup process
(`_process_end`) deletes any record marked `noupdate=False` if it
wasn't "reloaded" from a file. Since these records are created
manually in the code and aren't in any XML file, they never get
reloaded, so Odoo just deletes them and the records they point to.

By setting `noupdate=True` when these rows are created, we tell
the system to leave them alone during upgrades. Since these only
exist at runtime and don't have a data file, we don't need to
worry about them being updated later anyway.

The helper was added in
https://github.com/odoo/enterprise/commit/fd98660e352512e0b74d91958707687978154833.

Steps to reproduce:
1. Install Marketing Automation
2. Go to Campaigns > New and pick the "Double Opt-in" template, then save
3. Confirm the "Confirmed contacts" mailing list and server action exist
4. Go to Apps and Upgrade Marketing Automation
5. Try to find the mailing list and server action again

=> They disappear after the upgrade.

Ticket [link](https://www.odoo.com/odoo/project.task/6140191)
opw-6140191

Forward-Port-Of: odoo/enterprise#115444

### Issue:
When accessing the Bank Reconciliation view directly via URL or bookmark, auto-matching with reconciliation models may not trigger and the upload button may be visible on synchronized journals

### Cause:
`_action_open_bank_reconciliation_widget` injects two context keys:
- `auto_statement_processing`: triggers auto-reconciliation on statement creation
- `bank_statements_source`: hides the upload button for synchronized journals

When the view is accessed directly, these keys are not present, causing the UI to ignore them

`auto_statement_processing` is now set directly in the user context via `onWillRender`/`onWillDestroy` in `BankRecKanbanController` `bank_statements_source` requires an ORM call to fetch the journal's value and is resolved via `fetchBankStatementsSourceInto` on startup

Notes:
The fix for `bank_statements_source` was added opportunistically while addressing `auto_statement_processing`

Steps to reproduce:
- Install `accountant` with demo data
- Duplicate the Bank Journal and set Bank Feeds to Online Synchronization
- Open the Accounting Dashboard and open the Bank (copy)
- Create a transaction (Label: Test, any amount) and click Add & Close
- In the 3 dots menu, choose Manage Models
- Create a Reconciliation Model (Label contains: Test, Lines: any account, default values)
- Click Automate
- Go back to the Bank Reconciliation page and verify:
 -- The transaction is reconciled automatically
 -- No Upload button is displayed
- Create a new transaction, it should be reconciled automatically
- Copy the URL and open it in a new tab
- Create a new transaction

Before the fix, the transaction is not reconciled and the Upload button is present

opw-6391107

Forward-Port-Of: odoo/enterprise#127020
Forward-Port-Of: odoo/enterprise#126359