This update improves the performance of the Spanish Model 347 tax report, especially when dealing with large numbers of partners. Instead of processing a potentially massive list of partner IDs, the system now uses a more efficient database query approach that significantly speeds up report generation and prevents slowdowns.

The model 347 report is adding a partner exclusion domain in the search call.
It is done by firstly retrieving those partner IDs to then add that list of IDs into a `not in` domain leaf.
The issue is that the list of IDs can be gigantic, leading to performance issues.

Before odoo/enterprise#61452, it was a blocking issue as if the list was too long (100,000 IDs raise the issue), it would simply make the code crash when loading the report.
That PR then simply bypassed the issue by passing the domain as `forced_domain` so it would not go through the `literal_eval()` call (which is the one crashing when the list is too long).

But even after that fix, we still provide the list of IDs into the domain and so ultimately in the SQL request, which can still be an issue if there are too many.

This commit improves that by passing the SQL subquery (the one fetching the partners to exclude) directly into the domain, so the SQL query won't contain any list of IDs but just a sub-select. It does have better performance within PostgreSQL for big lists.

Note that the `SQL()` query is surrounded by parentheses on purpose, as it doesn't work otherwise. This might be improved at the ORM level in the future with odoo/odoo#163560.

Task [link](https://www.odoo.com/web#model=project.task&id=3895983)
task-3895983

The shop floor app now includes a pager that allows users to navigate through all available work orders, not just the first 40. The pager only appears when needed and lets users adjust how many records they view at once, making it clearer when they're viewing a subset of available data.

In [1], a limit was introduced to the amount of records that can be displayed at the same time in the shop floor app. However, it was not always very clear to the user that they may only be viewing a subset of the available records. It was also impossible to show any records beyond the first 40 that conform to the filter criteria.

In this commit, we introduce a pager to resolve these issues. The pager will only be displayed when relevant (ie when not all available records are displayed). Using this new pager it is also possible for the user to dynamically increase or decrease the default limit of 40, which was not possible before.

[1] https://github.com/odoo/enterprise/pull/64551 (and forward ports)

Fixed an issue in the followup report where the Total Due and Total Overdue amounts were not updating when a user excluded a line item from the followup. The system was recalculating these totals from the database before the exclusion was saved, causing the display to remain unchanged. This fix ensures the totals reflect the current state of excluded entries.

Open followup report for a partner
Exclude a line from followup

Issue: Total Due will not change
This occurs because the system recompute Total Due and Total Overdue
from the db while the value has not been saved yet

opw-4037830

This fix corrects how the system determines whether to enable rental transfers in sales orders. A previous change inadvertently broke existing rental workflows by checking user permissions incorrectly. The fix ensures the system properly verifies permissions at the sales order level rather than individual line items, preventing issues when orders are created by system users.

Fixes a commit e3d7b06

Should look at the `self.order_id` creator instead of `self`.

opw-3933511

This fix resolves a technical error that occurred when users tried to view the accounting dashboard while working with multiple companies in French localization. The issue prevented the dashboard from loading properly in multi-company environments, and this update ensures the dashboard works correctly regardless of how many companies are selected.

We get a singleton error in multicompany setup when opening the
accounting dashboard

Steps:

- Have at least two companies, one with l10n_fr_reports installed
- Select the two companies in the caompany selector
- Go to accounting dashboard
-> singleton error

opw-4053554

This fix resolves an issue where intrastat report lines were appearing twice when archived units of measure were present in the system. The problem occurred because a recent code refactor accidentally removed a filter condition that excluded inactive units of measure. By restoring this filter, the report now correctly displays each line only once.

To reproduce:

- install l10n_be_intrastat and sale_management, switch to the company BE company CoA
- Settings > Sales > Product Catalog, activate the "Unit of Measure" setting
- Go to Sales/Configuration/Units of Measure/Units of Measure menu
- Create a new units of measure; set the category to "Weight" as Reference Unit of Measure, uncheck the Active checkbox to archive it
- Create an invoice for the contact having country Germany and with a product having commodity code, weight, etc set for the intrastate report
- Validate the invoice and check the intrastate report for "This Fiscal Year"

Result -  The report lines appear twice

Expected - The report shouldn't consider archived UoM, lines should appear only once

OPW - 3915784

Additional info:
This behavior happened because in the following refactor PR,
https://github.com/odoo/enterprise/pull/31893/files#diff-7b1b123893744b02df76c7fa971ebb68b9f59e26f619e3a7d8f290c0f45ed037L368
We forgot to re-add the following line as a condition in the where clause:
`ref_weight_uom.active`

Forward-Port-Of: odoo/enterprise#64500

A previous fix for WhatsApp message templates is being reverted because it was causing the system to ignore user-entered values and always use automatic values instead. The team is working on a better solution to address the original issue.

…dated on template change"

This causes issues as composer computed value is now always forced and user value is ignored. A better fix will come soon.

This reverts commit 8b7829469907b39d048a328dd3a939f1c3e1d21c.

Task-3996935

This fix ensures that when documents are automatically filled with OCR-extracted data, the system uses the correct company context. This prevents inconsistent values from being selected, particularly for company-dependent fields like supplier payment terms. The change ensures invoices are processed with the appropriate company settings.

When the document is filled in with the OCR values, we need to use the document's company context, otherwise it can lead to inconsistent values being selected.
For example, the payment terms of a supplier are company dependent, so we need the right company context to select the one from the company of the invoice.

Related task: [#3902741](https://www.odoo.com/odoo/project.task/3902741?cids=1)

This update resolves a technical error that occurred when subscription payments failed or expired. When customers attempted to pay for their subscription invoices and the payment was declined, the system would crash instead of properly recording the failed transaction. This fix ensures failed payments are handled gracefully without errors.

Currently, an error occurs when the payment status is failed, expired, or failed.

Steps to produce an error:
- Install `sale_subscription` and `payment_mollie`
- setup `mollie` payment provider in testing
- Create an invoice for the subscription and confirm it
- Click preview of the invoice and click Pay Now.
- fill card details, and on the on the next page, select failed or expired in payment status
- Confirm

error: 
`PaymentTransaction._set_canceled() takes 1 positional argument but 2 were given`

This is because at code [1], we have passed `**kwargs` as arguments in super call, and as a result, it sets all arguments of kwargs in agruments, e.g., 2 of super call, but method call requires one positional argument.

This commit will fix the above issue by passing a positional argument with kwargs in the super call.

[1]-https://github.com/odoo/enterprise/blob/43621084d0cf95970eb6e45cf67bcb20ec14b8b3/sale_subscription/models/payment_transaction.py#L186

sentry-5606090812

This fix corrects the Belgian profit and loss financial report to properly include accounts 7632/9, which were previously missing from the calculations. This ensures that companies and associations using Odoo's Belgian accounting module now have accurate and complete profit and loss reporting that complies with local requirements.

Currently, accounts `7632/9` are not taken into account in the Belgian profit and loss report.

opw-4037481

Forward-Port-Of: odoo/enterprise#66343

This fix corrects the account codes used for deferred expenses and revenues in the French accounting chart template. The deferred expense account is now properly set to 486000 and the deferred revenue account to 487000, ensuring accurate financial reporting for French companies using Odoo's accounting module.

- Deferred expense account: 486000
- Deferred revenue account: 487000

task-3839851

**Community PR:** odoo/odoo#171416