### Issue before this commit:
The XML generation for the Luxembourg annual VAT declaration included several fields with a value of 0,00 even when these fields were not mandatory according to the official eCDF specification. As a result, the generated XML contained unnecessary elements that should only appear when the related fields are filled or when specific dependency conditions are met. This behavior produced XML declarations that did not strictly follow the expected rules of the Luxembourg tax authority specification.

### Steps to reproduce the issue:
1. Download Accounting and l10n_lu apps
2. Switch to LU company
3. Go to Accounting > Reporting > Tax Report
4. Set Report parameter as "Annual VAT Declaration (LU)"
5. Wheel button next to title "Tax Report" > XML
6. Fields 129, 137, 145, 163, 175 should not be there if setted to zero

### Cause of the issue:
The issue was caused by the logic used during XML generation, which kept certain fields in the declaration even when their value was zero. These fields were included because they were listed among mandatory fields or because the filtering logic did not fully reflect the conditional requirements defined in the eCDF rules. Consequently, fields that should only appear when related fields are filled or when dependency conditions are satisfied were still exported with a zero value.

### Reason to introduce the fix:
This fix ensures that only the fields required by the eCDF specification are included in the generated XML declaration. Non-mandatory fields with a zero value are now properly excluded unless they are explicitly required by dependency rules. This improves compliance with the Luxembourg tax declaration format and prevents the generation of unnecessary or invalid fields in the XML output. 

### Fix details:
While addressing this issue, several elements previously introduced by PR
https://github.com/odoo/enterprise/pull/105143 and https://github.com/odoo/enterprise/pull/91938 had to be modified still maintaining their fixes.
The implementation follows the rules described in the official documentation: https://ecdf-developer.b2g.etat.lu/ecdf/forms/popup/TVA_DECA_TYPE/2020/en/1/rules

The main purpose of this change is to first compute (if that is possible) and then validate the logic of the VAT declaration fields in a structured and maintainable way. To achieve this, a large dictionary (YEARLY_VAT_RULES) was introduced to describe the relationships and validation rules between all fields appearing in the declaration. Each entry of the dictionary corresponds to a field of the declaration (identified by its numeric ID) and defines how its value should be validated or computed. For each field, the structure specifies:
- relation_type: indicates if the field belongs to a circular dependency group or to a parent-child relation
- group: lists the fields that are part of the same dependency group.
- rules: describes how the field value should be derived or validated.

opw-5925322

Concurrent processing of emails with the same `Message-Id` can create duplicate records.

### Steps to reproduce

1. Configure multiple mail aliases (e.g., two helpdesk teams).
2. Send one email with both aliases as recipient.

The Mail Transfer Agent may invoke `odoo-mailgate.py` once per recipient, resulting in concurrent processing of the same email in separate transactions.

We expect one record per alias/team, but duplicates may be created.

### Cause

This is a race condition in the `Message-Id` deduplication logic, caused by concurrent transactions and PostgreSQL snapshot isolation.

Odoo uses the `REPEATABLE READ` isolation level. This means that each transaction takes a snapshot of the database at its first query and cannot see changes committed by other concurrent transactions.

When two concurrent transactions process the same email:

1. Both enter `message_process` and take their snapshot.
2. Both search for the `Message-Id`. Because their snapshots don't include each other's work, both find nothing.
3. Both create records.

Even if one transaction commits before the other performs the check, the second transaction still uses its original stale snapshot and create duplicates.

### Fix

After the initial duplicate check, attempt to acquire a transactional advisory lock on a hash of the `Message-Id` using `pg_try_advisory_xact_lock`. If another transaction is already processing the same email and holds the lock, the call returns false and the email is treated as a duplicate. If the lock is acquired, processing continues as normal.

opw-5116492

[FIX] project_timesheet_holidays: Exclude archived employees from time-off 

# Description of the issue/feature this PR addresses:
## Steps to Reproduce:
1. Create a time off for Employee A (it should affect the timesheets).
2. Create a new public holiday (global time off) that overlaps with Employee A’s time off.
3. Archive Employee A.
4. Delete the public holiday created in step 2.
5. An error related to timesheet generation appears.

## Expected Behavior:
- The public holiday / global time off should be deleted without any error.

# Desired behavior after PR is merged:
## Fix (Implemented):
When regenerating timesheets due to changes in holidays or time off, leaves related to archived employees should not be taken into account. A check was added inside the `_generate_timesheets` function in `project_timesheet_holidays/models/hr_holidays.py` to exclude leaves belonging to archived employees.

## Alternative Fix (Not Implemented):
Instead of filtering out leaves linked to archived employees, we could delete those leaves when an employee is archived. However, this approach is not ideal, as archived employees may be reactivated later and would still need their previously requested time off to be preserved.

 ## Version:
 This bug appears in both version 17.0 and 19.0. I assumed that it also appears in 18.0  but didn't directly test

## Task:

[5474038](https://www.odoo.com/odoo/project/4105/tasks/5474038)

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

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

This error only exists in the 17.0 version
- In the 16.0 version, it doesn’t select other companies in the navigation bar and doesn’t give an access error as well
- In the 17.4 and 18.0 versions, it selects other companies in the navigation bar and doesn’t give an access error as well

I backported the fix from the below-attached PRs:
- https://github.com/odoo/odoo/pull/157399/files#diff-706c5300f0b758ed43a362c85fa84a655c8bae12339bd882e98dc419623facc2R207
- https://github.com/odoo/odoo/pull/160730/files#diff-c28b3e2d6bbe6f94bf95e9cbbe228f61664ca6e1d9a4048f951d8769e2d22752L124

### Steps to reproduce the bug:
1) Create 2 companies: Company A and Company B
2) Assign Company A to the company_id field on the contact form for Company A. 
3) Assign Company B to the company_id field on the contact form for Company B. 
4) Create a user and add both companies to the allowed companies in the user record. 
5) In the navigation bar, select only one company (e.g., Company A). 
6) Attempt to open the user record from the user form, it will give an access error.

### Current Behavior before PR:
An AccessError is raised when attempting to open the user record after selecting only one company in the navigation bar.

### Desired behavior after PR is merged:
When navigating to a user record after selecting only one company in the navigation bar, the system should:
1) Automatically select the other company [similar to the behavior in version 18] 
2) Reload the page before redirecting to the specific user record 
3) Open the user record page without giving any access error.

opw-4449964



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