Context:
The Belgian localisation has two Intrastat report handlers:

- Goods: `l10n_be_intrastat.models.account_intrastat_report`
- Services: `l10n_be_intrastat_services.models.account_intrastat_services_report`

`account_intrastat_report.be_intrastat_export_to_xml()` is the single export entry-point for both. It always calls an internal helper named `_be_intrastat_get_xml_file_content(options, results, company)` and then serialises the returned string.

Why it failed:
1. Signature drift The services override expected a fourth positional argument (`date`), so the shared entry-point raised a `TypeError`.

2. Wrong template prefix The helper tried to render `l10n_be_intrastat.intrastat_services_report_export_xml`, but the template is stored under `l10n_be_intrastat_services`, leading to a `ValueError`.

This commit drop the unused `date` parameter and compute the period from options the same way we do in the other function.

opw-4834279

Forward-Port-Of: odoo/enterprise#86759

[FIX] account_online_synchronization: currencies symbol missing

Before this commit when doing a bank synchronization with a currency that wasn't
enabled, the currency was not reloaded in the session and so the getCurrency
function was not working properly. The symbol was not displayed.

task-4749335

This commit will change a bit the display of statement line with multi currency.
A popover has been added when clicking on the amount to have extra line info
like the exchange difference and when we have a partial reconcile.

- Correcting a bug where the amount currency of the suspense was wrong when
dealing with currencies (delete or adding lines). For example when dealing with
JPY currency (that have a rounding of 1). Making an invoice for 100 yen and a
statement line of 50 yen. When adding the line and removing it, we could have
rounding issue since we calculate the amount currency by multiplying the balance
and the currency rate. In this example we achieve a suspense line of 49 when it
should be 50.

- Correcting another bug with exchange diff. In the same case, we had an
exchange
difference value of 0.01 in _lines_get_account_balance_exchange_diff which
shouldn't be there. In prior version of 18.3 we checked that the origin_balance
minus move_line.balance was zero in the currency of the move line as well as
the one from the company and if that was the case no exchange move line were
created. And since there were no exchange move line the exchange move was not created.
In this commit, I reintroduce the logic of checking the move line currency to
return 0.0 but that was not enough since the reconcile_plan function would still
create the exchange move since we were not using the context key anymore. So
now if the exchange value is 0 then we pass the context key to avoid having an
exchange move.

- Also doing some formatting because the linter was not correctly applied.

- Correcting also a case where the reconciled_lines_ids has multiple line in
case of exchange diff, which cased a traceback since is_invoice needs a
singleton.

- When having a foreign currency, the suspense amount is displayed in the
foreign currency but when adding move line with the same currency, due to the
computation on the amount_currency we could have situation where the amounts
don't add up. We decided that if there is a foreign currency and that all the
lines are in the foreign currency we do an addition of the amount currency
otherwise we display the suspense in journal currency. For this we had to use
the self.amount_currency because the liquidity line is not modified when
modifying the amount currency of the statement line itself. (Tried to synchro
the move and more in particular the liquidity line but had a constraint failing)

- When doing an apply amount of a line that has multiple value in the
reconcilied_lines_ids, it gives a traceback because we want to get the
current_ids of a dict of multiple values

task-4749335

Forward-Port-Of: odoo/enterprise#86519

The certification reports for Colombian withholdings (Fuente, ReteIVA, ReteICA) incorrectly referenced the current year (i.e., the year when the report is generated) as the "año gravable" in the certificate body:

"Durante el año gravable de 2025..."

This caused a mismatch when generating certificates for the previous fiscal period (e.g., 2024), especially when the user filtered movements from a prior year.

This change ensures that the "año gravable" corresponds to the selected period year, taken from the date_from filter in the report wizard, which reflects the actual accounting or fiscal period being certified.

Justification
According to Colombian tax practices and DIAN guidelines, the "año gravable" mentioned in retention certificates must match the period in which the income or payment was made and the tax was withheld. Using the current date instead of the actual reporting period could lead to confusion or even legal inconsistencies during audits.

Reference:

Estatuto Tributario Art. 378: Certificates must include the fiscal year in which the withholding was applied.

Common practice requires companies to issue certificates reflecting the year of the transactions, not the year of report generation.

Forward-Port-Of: odoo/enterprise#86838

When a signed document is moved to trash in the documents app, when the cron tries to delete the said document it should raise a foreign key violation error in the terminal not in UI.

**Steps to reproduce:**
* Install document and sign
* Document App> all> click `Employment contract.pdf`.
* Select sign>drag and drop Signature>Sign now
* Sign the document>validate and send completed document
* Documents>certificate of completion or the signed document>actions>trash
* The error will be produced when cron deletes the document.
* You can delete the document from trash to see what error will be displayed by cron.
  
 `ERROR: update or delete on table "ir_attachment" violates foreign key constraint "sign_request_completed_document_rel_ir_attachment_id_fkey" on table "sign_request_completed_document_rel"`
 
**Solution:**
* Modifying the domain for `_gc_clear_bin` via a new function called overridden `_gc_documents_domain` in `documents_sign` this will allow for cron to skip over signed required document during unlink process.
* This will still throw an `Validation Error` when the user tries to delete it from the GUI letting them know it cannot be deleted.

Sentry-6225030131

Forward-Port-Of: odoo/enterprise#86382
Forward-Port-Of: odoo/enterprise#83765

### Steps to reproduce:
- Have an overdue invoice
- Go to Accounting > Customers > Follow-up Reports and click the partner
- Change the state of the report to something different than the first state
- Click "Follow-up", select "By post" and send
- Settings > technical > Email > Snailmail Letters find the letter corresponding to the report
- Check the PDF, it is using the mail template of the first followup level

### Cause:
When sending a followup report, the followup level of the report is recomputed for it to have the correct value.
Then the report is generated.
But the option to send a letter uses methods from the module `snailmail` for example `` which don't have options. The options are then recomputed to generate the report, reading [`partner.followup_line_id`](https://github.com/odoo/enterprise/blob/c8dac822cf3df23922488f33c07a114bbea05198/account_followup/models/account_followup_report.py#L42) so getting the wrong value.

### Solution:
Add a context key to pass the value of `followup_line` to the report generation after snailmail.

opw-4766804

Forward-Port-Of: odoo/enterprise#86706
Forward-Port-Of: odoo/enterprise#85717

The system will crash with an error when we `fetch transactions` and then click on the total amount in the top right corner, because the method `action_open_bank_balance_in_gl` expects `exactly one journal record` (self.ensure_one()), but receives an empty recordset.

**Steps to Produce:-**

1. Install the `Accounting` module.
2. Navigate to `Invoicing > Bank`, then click on "Search Banks" and connect with the `Odoo Bank Sync Demo`.
3. Click on `Fetch Transactions` and wait for the process to complete.
4. In the new view, click on the `total amount` located in the `top right corner`.

**Error:-**
`ValueError: Expected singleton: account.journal()`

**Solution:-**
- At [1], in `default_context` we can see that `active_id` is not given.

 [1] https://github.com/odoo/enterprise/blob/4b8edc19dbece15f7843ec3647c464307e165906/account_online_synchronization/models/account_online.py#L878-L882

- So, in this commit now active_id is added in default_context to prevent the error

**Sentry - 6644825437**

Forward-Port-Of: odoo/enterprise#86896

The system crashed because it expected the information from the card to be in `dictionary` format, but it came in the `list of dictionaries`. Usually, when there is only one contact on the card, the system retrieves the details as a `Dictionary`. But if the card has details of more than one person, it receives a `list of dictionaries`.

When the `extracted_data` comes as list of dictionaries, then at [1], it raises the `TypeError`.

[1]
https://github.com/odoo/enterprise/blob/e5b21d77b6dfff2b1371909c3c1e17cecee43a19/crm_enterprise/tools/business_card_scanner.py#L85

**Steps to produce:-**
1. Install `CRM` and make sure you have iap tokens for `Lead generation`.
2. Go to CRM and click on gear icon and click on Import Business Cards.
3. Then upload this [image](https://drive.google.com/file/d/1wKONdUEAMQptNU8cUeZsUY1xVJBpD8Dk/view?usp=sharing).

**Traceback:-**
```py
Traceback (most recent call last):
  File "/home/odoo/odoo18/community/odoo/http.py", line 2467, in __call__
    response = request._serve_db()
  File "/home/odoo/odoo18/community/odoo/http.py", line 1970, in _serve_db
    return self._transactioning(
  File "/home/odoo/odoo18/community/odoo/http.py", line 2034, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "/home/odoo/odoo18/community/odoo/service/model.py", line 164, in retrying
    result = func()
  File "/home/odoo/odoo18/community/odoo/http.py", line 2001, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "/home/odoo/odoo18/community/odoo/http.py", line 2263, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "/home/odoo/odoo18/community/odoo/addons/base/models/ir_http.py", line 349, in _dispatch
    result = endpoint(**request.params)
  File "/home/odoo/odoo18/community/odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "/home/odoo/odoo18/community/addons/web/controllers/dataset.py", line 32, in call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "/home/odoo/odoo18/community/odoo/service/model.py", line 84, in call_kw
    result = method(recs, *args, **kwargs)
  File "/home/odoo/odoo18/enterprise/crm_enterprise/models/crm_lead.py", line 34, in action_ocr_business_cards
    leads = card_scanner.business_cards_to_leads(attachments)
  File "/home/odoo/odoo18/enterprise/crm_enterprise/tools/business_card_scanner.py", line 82, in business_cards_to_leads
    lead_values = {
  File "/home/odoo/odoo18/enterprise/crm_enterprise/tools/business_card_scanner.py", line 85, in <dictcomp>
    if extracted_data.get(field)
AttributeError: 'list' object has no attribute 'get'
```

**Solution:-**
- We first checked whether the data returned from the OCR was a dictionary or a list of dictionaries (multiple contacts).
    - If it was just a dictionary, **we wrapped it in a list** so that we could handle everything the same way.
    - Then, we looped through each dictionary, picked out the allowed fields, and **created a lead for each one**.

**Sentry - 6658829547**

Forward-Port-Of: odoo/enterprise#87159