Currently to exclude valuation accounts from the reconciliation we modify the domain by adding a second condition on the field account_id of the account_move_line table to exclude these accounts while including them in a first condition in the method we override.

This is not very efficient as it prevents the use of indexes on that second NOT IN condition.
Indeed PostgreSQL prioritizes the use of the index on the IN condition and then applies the NOT IN condition in a filtering step, which is very costly when there are many account_move_line records belonging to the inventory valuation accounts.

Here is an example of the before after on a database with 87 million account_move_line records total and 9.5 million account_move_line records matching the first IN condition via an index while only 1 million remain after applying the filtering of the NOT IN condition.

All measures are performed with a warmed up cache

[Explain Before](https://explain.dalibo.com/plan/d0d14efbe51ch359)

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~9s</td>
			<td>~1.5s</td>
		</tr>
	</tbody>
</table>

[Explain After](https://explain.dalibo.com/plan/e882cf62d1ga6955)

## Potential further improvement:

Add a partial index: 
```SQL
CREATE INDEX CONCURRENTLY idx_aml_company_id_account_id_unreconciled_posted
ON account_move_line (company_id, account_id)
WHERE parent_state = 'posted' 
  AND (reconciled IS NULL OR reconciled = FALSE)
  AND (display_type IS NULL OR display_type NOT IN ('line_section', 'line_note'));
```

### Benchmark:
<table>
	<thead>
		<tr>
			<th># of aml</th>
			<th>Before</th>
			<th>After</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td>87713812</td>
			<td>~1.5s</td>
			<td>~900ms</td>
		</tr>
	</tbody>
</table>

[Explain After + Index](https://explain.dalibo.com/plan/56dfdh554668ed43)

Part of https://github.com/odoo/odoo/pull/261931

Forward-Port-Of: odoo/enterprise#115581

## Issue
When generating a DMFA report with a working schedule with more or less than 5 days a week, the *Days Per Week* value in the report is still appearing as 5.

## Steps to reproduce
1. Install *Belgium - Payroll* (`l10n_be_hr_payroll`)
2. In Payroll's Settings:
    - set *ONSS Registration Number* to `0830123456`
    - set *DMFA Employer Class* to `083`
    - create a *Work Address DMFA code* (any name, any numeral code, but set the *Working Address* to the Belgian company used for the rest of the steps)
3. In Employees' Settings, set the *Company Working Hours* to a new Working Schedule, with 9 hours/day, 4 days/week. E.g from Monday to Thursday included:
    - Work from 8:00 to 12:00
    - Lunch from 12:00 to 13:00
    - Work from 13:00 to 18:00
4. Create an Employee E for the Belgian company:
    - In the *Payroll* tab, set the start date of the contract to 01/01/2026.
    - In the *Personal* tab, set the *NISS Number* to `85073003328`
5. Create the payslip for January 2026 for the Employee E.
6. In Payroll > Reporting > Belgium > DMFA, create a new DMFA for the first quarter of 2026 and generate the PDF report
7. **In the generated PDF report, the _Days per Week_ line is set to 5.**

## Cause
The number of days was calculated by multiplying `5` with the `work_time_rate` of the related calendar. This is inaccurate in the case of a company where employees are only expected to work 4 days a week.

opw-6103934

Forward-Port-Of: odoo/enterprise#116465
Forward-Port-Of: odoo/enterprise#113804

#### Issue:
The budget report displays duplicate analytic lines.

#### Steps to reproduce:
In a new company:
- Create a budget with one budget line (Analytic Account A).
- Create one analytic item (linked to Analytic Account A).
- Open the budget report and remove the default "open budget" filter.
Duplicate amounts appear in the pivot view and duplicate lines appear in the list view.

#### Cause:
In #104299, the query in `_get_aal_query` was refactored for performance to avoid a single query with an OR condition in the LEFT JOIN. It was replaced by two separate queries combined with `UNION ALL`. This caused some lines to be captured by both queries, resulting in duplicates in the final report.

#### Fix:
Use three separate queries, each with specific filter conditions to guarantee unique results:
Q1 - Analytic lines with no matching budget line.
Q2 - Analytic lines matched to a budget line with no company (null-company).
Q3 - Analytic lines matched to a company-specific budget line.

OPW-6051696

Forward-Port-Of: odoo/enterprise#116612