What:
Previously, actions like "Create Vendor Bill" were only embedded in the
main "Finance" folder. Now, these actions are also embedded directly into
the specific subfolders for each journal type (e.g., "Purchase", "Sales").
All relevant actions are also kept in the parent "Finance" for general
accessibility. The purchase actions are also added to the "Inbox" folder.

Why:
The previous behavior was inefficient. A user uploading a vendor bill to
the "Purchase" folder would not see the "Create Vendor Bill" action. He
would only see it when he is in the parent "Finance" folder. By embedding
it by default this streamlines the process by ensuring the necessary tools
are available exactly where the user is working.

How:
The logic is implemented within the _documents_configure_sync method of
the account.journal model. This is the ideal location because it
handles the complete setup of a journal for the Documents app. This ensures
that actions are embedded correctly both during module installation and
dynamically whenever a new journal is created by a user.

Notes:
- Tests were rewritten to check these embeddings on install. And were
refactored to be more maintainable and cover bank statements better.
- The test for importing bank statements had to be moved to a separate
testing module, as it needs the `account_bank_statement_extract` module,
which is not in the dependencies of `account_move`.
- The tests for bank statement processing errors was improved to match
the tests in later versions

Task-5410752
Related Task-5075610

Forward-Port-Of: odoo/enterprise#105924
Forward-Port-Of: odoo/enterprise#102039

The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference.

It also modify a docstring of a test because it was lying about what it was really testing. The usecase it says it forbid is actually enforced by `test_matching_algorithm_for_multiple_invoices`.

Before this commit:
- functionally: The obvious matching was denied and the accountant had to manually make the match.

- technically: The `aml.ref` and the `move.payment_reference` were the exact same and thus postgres regrouped the invoice (through aml) with itself as if there were 2 invoices matching the same word.

After this commit:
- functionally: The obvious match is made.

- technically: The initial intend was to avoid having several invoices (proxy by amls) reported for a specific matching word preventing the system to take a difficult and arbitrary functional decision which might be wrong. In order to comply with that and to not block the match of an invoice that would be matched through several matching words, we don't gather twice the same aml for the same word.

task-id: None (The issue arose on odoo.com and was brought by APFA)

Forward-Port-Of: odoo/enterprise#105878
Forward-Port-Of: odoo/enterprise#105648

Currently, On renaming or updating roles in the sign template doesn't get saved due
to which drag-drop 'Signature Item' is reseted back to 'Signer 1'.

**Steps to reproduce:**
1) Install sign app.
2) Open the Sign app and select a template.
3) Case A (Direct Rename): In the sidebar, rename a role from
   'Signer 1' to 'Signer 1-Test'.
4) Case B (Edit Button): Click the '3-dots' button on the role and click `edit`,
   change the name to 'Signer 1-Test', and save.
5) Drag and drop 'Signature Item' to template.

**Observed Behaviour:**
- The Role is not updated as `Signer 1-Test` and reset back to `Signer 1`

**Expected Behaviour:**
- The Role should be updated as `Signer 1-Test`.

## **Root Cause:**
### **Case A:** 
The `updateSignerNames` method(see[1]) checks `if (signer.name.includes(str))`
where `str` is `Signer` This condition evaluates to true for any custom name
containing that substring, causing the code to overwrite the user's custom input
with the default generated name string.

### **Case B:**
1) The method `updateRoleNameAndAvatar` see([2])  updated the local state `this.state.roleName`
   but failed to trigger the `onChangeRoleName` prop. As a result, the
   parent component (`SignTemplateSidebar`) remained unaware of the change
   and overwrote the name with its stale value during the next update cycle
   (triggered by the drag-and-drop action).

2) **when `sign_emsigner` module is installed:**
   The module patches `openSignRoleRecord` to manually set `this.state.roleName = data.name`
   before the role update process completes. However, `onChangeRoleName` relies
   on the condition `name !== this.state.roleName` to decide whether to notify
   the parent component (via `this.props.updateRoleName`). Since the state is
   already updated manually, this check fails (returns false), the parent is
   never notified, and the database is not updated. When `sign_emsigner` subsequently
   triggers a re-render (via `displayAddDocumentButton`), the parent passes down
   the old, state name, reverting the user's changes.

### **Fix:**
1) Remove all `updateSignerNames` logic since it is difficult to distinguish between a
   default-generated name and a user-customized name.

2) Update `updateRoleNameAndAvatar` to call `this.onChangeRoleName` with
   the new name, ensuring the parent component's state is synchronized.

[1]- https://github.com/odoo/enterprise/blob/382dd07b8ef93e9315963825e69066155a534ba0/sign/static/src/backend_components/sign_template/sign_template_sidebar.js#L92-L102

[2]- https://github.com/odoo/enterprise/blob/afc32de0a2757d8f241886ce27736fb7c07ab8c7/sign/static/src/backend_components/sign_template/sign_template_sidebar_role_items.js#L121-L122

**opw-5389063**

Forward-Port-Of: odoo/enterprise#102534

## Issue
In the *Profit and Loss* report for the French localization (`l10n_fr_reports`), the account 649 was mentioned in the *"Reversals of provisions (and depreciation), expense transfers"* section, instead of *"Wages and salaries"* and *"Social security charges"*. This classification is described in the *"Recueil des normes comptables françaises"* (Versions [2025](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/Reglements/Recueils/PCG_Janvier2025/Recueil-NF-Janvier-2025.pdf) and [2026](https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf)).

## Steps to reproduce
1. Install *France - Accounting Reports* (`l10n_fr_reports`)
2. Go to the *Profit and Loss* report
3. In debug mode, click the information buttons on the following rows:
    - *Reversals of provisions (and depreciation), expense tranfers*: **649 is mentioned**
    - *Wages and salaries*: **649 is not mentioned**
    - *Social security charges*: **649 is not mentioned**

## Note
The account 649 was added at the beginning of the formula for the *"Wages and salaries"* section in order to respect a logical order. In the *"Social security charges"* formula, since no logical order appears to be used, the account was added at the end.

opw-5724559

Forward-Port-Of: odoo/enterprise#105856
Forward-Port-Of: odoo/enterprise#105474