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

This update fixes an issue where job positions were not sorting alphabetically when clicking the sort header in the Contracts view. The referral module was interfering with the standard sorting behavior. Now employees can properly sort job positions in alphabetical order when managing contracts.

Necessary modules:
hr_contract, hr_referral

Steps to reproduce:
- Employees > Employees > Contracts
- Click header to sort by job position

What happens:
Job positions are not sorted by alphabetical order

What was done:
Make sure referral does not override the ordering rules of hr_job, so the alphabetical sorting is kept.

opw-4037409

This update fixes an issue with how stock movements are ordered when reporting to Kenya's eTIMS tax system. By making the ordering consistent and predictable, the system now works reliably without random test failures, ensuring accurate and stable tax compliance reporting.

When we search for the stock moves to report to eTIMS, we need to ensure that the ordering is deterministic so that tests don't randomly fail.

runbot-71136

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