Sepa validation errors

[yaslama]

Bug

When submitting a SEPA file generated by version 15.0.3, the bank (CIC) doesn't accept it because of validation errors. For instance when the address contains the character "&". The documents from https://www.europeanpaymentscouncil.eu/document-library/guidance-documents/sepa-requirements-extended-character-set-unicode-subset-best describe a way to handle this character (and other escaped xml chars) but it's still not implemented everywhere. I any case, the current way to handle special chars as committed in https://github.com/Dolibarr/dolibarr/commit/22c271966d4f409f698746fe311d1180f82709d1 doesn't ensure that all the characters are in the limited set of authorized characters (as opposed to https://github.com/Dolibarr/dolibarr/commit/7c2fbe4923e887763a3a280ebcfcaceb6f87a196). @elWhat do you think?

Environment Version

15.0.3

Environment OS

No response

Environment Web server

No response

Environment PHP

No response

Environment Database

No response

Environment URL(s)

No response

Expected and actual behavior

No response

Steps to reproduce the behavior

No response

Attached files

No response

[hregis]

@yaslama I had a refusal from the same bank (CIC) under a different pretext, the XML file did not contain any special characters! They tell me that the format is not good even though it respects the standards and that the other banks accept this format... the CIC bank must be suffering from the heat wave! We must insist! ;-)

[yaslama]

@yaslama I had a refusal from the same bank (CIC) under a different pretext, the XML file did not contain any special characters! They tell me that the format is not good even though it respects the standards and that the other banks accept this format... the CIC bank must be suffering from the heat wave! We must insist! ;-)

Hi @hregis. Thanks for the info but it's an automatic validation mechanism and:

• the error text is like that:

Erreur Ligne 6547 Colonne 48 --> 'AdrLine' : Cet élément est invalide - La valeur '11 & 13 Rue Du Pere Thomas' est
invalide d'après son type de donnée 'Max70Text' - La vérification de la contrainte de pattern a échoué. (Non conforme
à la norme SEPA et/ou ISO20022)

which seems to be a "valid" error.

• As soon as we remove the "&" character, everything is ok. BTW, this dolibarr user sends xml files with thousand of entries each month and everything works as soon as the errors as described are fixed.

[hregis]

@yaslama and if you replace with "et" instead "&" is ok ?

[yaslama]

@yaslama and if you replace with "et" instead "&" is ok ?

You mean in the code generating the sepa? It works but if they are other invalid character in any address or name fields, it fails. Currently, the following patch works in the staging server (the prod still uses 14.0.5):

diff --git a/htdocs/core/lib/functions2.lib.php b/htdocs/core/lib/functions2.lib.php
index fe6e8e0fa40..a2ac7ab136f 100644
--- a/htdocs/core/lib/functions2.lib.php
+++ b/htdocs/core/lib/functions2.lib.php
@@ -2688,7 +2688,7 @@ if (!function_exists('dolEscapeXML')) {
         */
        function dolEscapeXML($string)
        {
-               return strtr($string, array('\''=>'&apos;', '"'=>'&quot;', '&'=>'&amp;', '<'=>'&lt;', '>'=>'&gt;'));
+               return strtr($string, array('\''=>'&apos;', '"'=>'&quot;', '&'=>'+', '<'=>'&lt;', '>'=>'&gt;'));
        }
 }

But I don't think that it's the right solution because sometimes third party names or address are copy/pasted from other software and can contain invisible or weird characters (like variants of quotes) which are supported by Dolibarr as soon as they are valid utf8 characters. Imho, the right solution is a variation of https://github.com/Dolibarr/dolibarr/commit/7c2fbe4923e887763a3a280ebcfcaceb6f87a196

[github-actions[bot]]

This issue is stale because it has been open 1 year with no activity. If this is a bug, please comment to confirm it is still present on latest stable version. if this is a feature request, please comment to notify the request is still relevant and not yet covered by latest stable version. This issue may be closed automatically by stale bot in 10 days (you should still be able to re-open it if required).