steps to reproduce:
-------------------
1. Install `l10n_sa_edi` and `l10n_latam_invoice_document`
2. Create and confirm an invoice.
3. Print the invoice PDF

issue:
------
The company logo is not printed on the invoice PDF.

cause of the issue:
-------------------
The `l10n_latam_invoice_document` hides the standard company logo if
`company_header` is set to true:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_latam_invoice_document/views/report_templates.xml#L6-L8

In the case of `l10n_sa`, the custom_header value is set because of this condition:
https://github.com/odoo/odoo/blob/0f6cb037e05db86e808682659a12442464b2cdd2/addons/l10n_sa/views/report_invoice.xml#L23

However, the condition in `l10n_latam_invoice_documnet` expects
a callable record instead of static XML data, which is incorrect:
https://github.com/odoo/odoo/blob/022fcbcf40a28afa56010f6130c26bb0503d5467/addons/l10n_latam_invoice_document/views/report_templates.xml#L9-L14

solution:
---------
Renaming the variable to `custom_header_sa` resolves the issue.

<details>
    <summary>Click here to see:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/f4606a44-10ce-4038-92a3-2c8ec2a69edf"/>

    After:
   <img src="https://github.com/user-attachments/assets/70055155-63f2-4fec-aaf6-3bf5587f5591"/>
</details>


opw-4977422

Forward-Port-Of: odoo/odoo#225476

In **`balance_pymes_line_32300`** (`CURRENT LIABILITIES > Current payables > Other current payables`), amounts are **doubled** because account **551** is included twice.

* **Formula using `account_codes`:**

  ```xml <field name="formula">-1034 - 1044 - 190 - 192 - 194 - 500 - 501 - 505 ...551 - 5566 - 5595 - 5598 - 560 - 561 - 569</field> ```

  → Explicitly includes account **551**.

* **Formula using `domain`:**

  ```xml <field name="formula" eval="['|', ('account_id.code','=like','550%'), '|', ('account_id.code','=like','551%'), '|', ('account_id.code','=like','554%'), ('account_id.code','=like','5525%')]"/> ```

  → Includes **all accounts starting with 551**, so **551** is also counted here.

This overlap causes the balance to be counted twice, inflating the reported value.

**steps to reproduce:**

1. With a Spanish company, go to **Accounting > Dashboard > Bank > Transaction > New**.
2. Select an account, search for **55100**, and add it.
3. Go to **Reporting > Balance Sheet > Other current payables**.
4. Notice that the reported amount is **double** the actual accounting data.

Overlapping formulas: specific account `551` and `5525` are counted in `account_codes`, while the `domain` formula already includes `551%`, leading to duplication.

**Fix**

Remove explicit account codes from `account_codes` if they are already covered by the `domain` prefixes to avoid double-counting. and also made sure to correct the same issue in the whole report.

opw-5075035

*: test_import_export

### Steps to reproduce:

- Go to Sales/Prodcuts/Pricelists
- Create a new pricelist with a rule with a set Valid Period
- Export that record adding the Pricelist Rule/Start Date (item_ids/date_start) as XLSX format
- Delete the record and test the import the XLSX file
#### Uncaught Promise:
> Invalid props for component 'ImportDataColumnError' :'resultNames' is undefined (should be a array)

### Cause of the Issue:

The issue is raised by the error message:
https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1428-L1432
which is not properly handled by the `ImportDataColumnError` component. However, in the present situation, the issue is just that this error message itself should not be raised in the first place.

#### Details:

Since commit 630b2683d3aad203b0bbf7d2d63b88cd4d3bd9d7, date and datetime formatted cells in spreadsheets are no longer Char field. Instead, they are imported as date and datetime objects. This was intended to allow importing columns with mixed encodings (e.g., some values stored as strings, others as dates in the spreadsheet).

However, a side effect of this change is that if a char-type field contains values that a spreadsheet interprets as dates or datetimes, the import fails. For example, an account move name "21/12/2025" may be interpreted as a date. Attempting to perform a join on this string expected value causes a traceback here: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1628-L1632

To address this discrepancy, commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e introduced a check raising an error if the imported field type is not appropriate to carry a `date/datetime` value.

This fix has two major issues:

1) It still does not handle the above use case correctly—it remains impossible to import "21/12/2025" as a record name. 
2) (The present issue) It does not properly check the type of related fields. For example, a field like "company_id/partner_id/membership_start" is not considered as an allowed date field. The current check on allowed date fields being overly simplistic:
https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1416-L1421

### Fix:

We propose reverting commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e. And instead of recursively computing the related model and the appropriate types of related fields (including property-type relational fields), we will simply stringify values when they are written into char-like fields (e.g., char or text).

Note: this may also require an adjustment in master for the html type.

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

Forward-Port-Of: odoo/odoo#226807