Dans le cadre d’un accord client, il doit être possible de prendre en compte l’accord central pour l’opération métier concernée, indépendamment de la version EBICS. La compatibilité et l’interopérabilité entre les versions précédentes sont spécifiées pour EBICS. Si deux signatures électroniques sont convenues pour un virement SEPA, il n’est pas pertinent, par exemple, que les remises relatives soient effectuées par BTF ou par type d’ordre ou paramètres FileFormat. Cette condition exige une mise en correspondance interne des anciennes et des nouvelles opérations métier dans le serveur bancaire et, le cas échéant, dans les systèmes clients. Jusqu’à présent, ces mises en correspondance sont officiellement spécifiées pour les opérations métier standard.
Les traitements préalables et ultérieures d’EBICS auprès des institutions financières et des entreprises clientes reposent en règle générale encore sur les anciens ID EBICS, comme les types d’ordres à trois caractères, et en France sur les paramètres de FileFormat pouvant comporter jusqu’à 40 caractères. Tant qu’une mise en correspondance existe, il n’est pas nécessaire de modifier ce procédé. Mais que se passerait-t-il si aucun type d’ordre/paramètre FileFormat n’est plus spécifié pour une opération métier et que les opérations métier sont valables uniquement avec BTF ? Si on ne souhaite pas adapter ses processus de traitement annexes à la BTF, on peut bien sûr garder une mise en correspondance. Pour les mises en correspondance non spécifiées, il convient toutefois de définir des ID individuels appropriés.
Dans les relations externes entre le client et l’institution financière, il faut tenir en compte que les spécifications du serveur bancaire concernant les opérations métier et les mises en correspondance sont communiquées au client ou au système Client par différents moyens. Les différentes représentations du point de vue du client, du participant et du moment jouent également un rôle. Un participant utilise toujours une version EBICS concrète, alors que l’accord client doit représenter toutes les versions valables. En outre, le moment de l’information a une incidence. Ainsi, avant l’initialisation du participant, l’institution financière ne sait généralement pas quelle version EBICS ce dernier utilise.
Le formulaire des paramètres bancaires, créé sur le serveur bancaire lors de la configuration du participant, doit donc représenter les options de toutes les versions EBICS prises en charge, y compris les éventuelles spécifications de mise en correspondance BTF. Il en va de même au moins pour le type d’ordre HKD permettant de télécharger les accords au niveau du client par le Client technique. Si aucune mise en correspondance n’est plus proposée pour certaines opérations métier dans la relation entre le client et l’institution financière, indépendamment de l’utilisation interne, les informations respectives devraient en conséquence représenter la mise en correspondance exclusivement par BTF. Pour l’administration et la gestion internes, il serait utile que les ID individuels utilisés uniquement en interne soient visibles dans le cas d’une mise en correspondance interne, (par exemple, les types d’ordre individuels avec leur propre mise en correspondance BTF), mais qu’ils soient différents des ID externes.
En résumé, le défi consiste à rendre la migration vers EBICS 3.0 aussi facile que possible pour toutes les parties concernées, compte tenu de la nouvelle diversité des informations. Cependant, avec une configuration adéquate et en respectant quelques consignes d’utilisation, la transition vers la nouvelle version EBICS n’est pas si difficile. Si vous avez besoin de soutien pour passer à EBICS 3.0 ou si vous avez des questions à ce sujet, n’hésitez pas à nous contacter.
Auteur : Michael Lembcke
