EBICS 3.0 – un ensemble de paramètres au lieu du type d'ordre Que faut-il prendre en compte lors de l'identification des opérations métier ?

Avec EBICS 3.0 les différentes opérations métier ne sont plus effectuées via les types d’ordres, mais via les nouveaux paramètres BTF.

Afin de permettre l'utilisation de contrats client avec des clients EBICS de différentes versions d'EBICS combinées avec EBICS 3.0, des règles de mapping ont été spécifiquement développées par les organismes nationaux de spécification. Ces règles suivent généralement les cinq paramètres BTF Service Name, Service Scope, Service Option, Service Message Name et Service Container. Il est important que la combinaison de ces paramètres BTF dans le serveur bancaire EBICS soit unique. Cela permet de s'assurer qu'un type d'ordre peut être attribué à l'opération métier via BTF et vice versa.

Dans la pratique, des ordres identiques d'un format donné peuvent être créés dans différentes versions de format et soumis au serveur bancaire. Bien que des ajustements de format soient effectués régulièrement par les organismes de spécification, la version de format utilisée par le système client dépend également de la version du logiciel client. Comme la version de format doit être transparente dans les logiciels clients, leurs utilisateurs n'ont aucune influence sur les envois dans une version de format spécifique lors de la compilation de leurs remises. En outre, les institutions financières acceptent en règle générale différentes versions de format d'une opération métier. En fin de compte, pour le traitement côté banque, la version de format correspondante peut également être lue à partir du namespace du fichier XML, au moins pour les formats XML. Jusqu’à présent, les serveurs bancaires sont conçus de manière flexible pour différentes versions de format.

Les autres paramètres BTF applicables pour EBICS 3.0 sont Service Message Name Format, Service Message Name Variant et Service Message Name Version. Si une institution financière inclut également ces autres paramètres dans les mappings des types d’ordre et les détails des contrats client, il convient de prendre en considération certains aspects. S’ils n’ont pas déjà été utilisés plus intensivement via le paramètre FileFormat ou s’ils ne sont pas nécessaires pour des raisons inhérentes au traitement, ces paramètres supplémentaires devraient être pris en compte de manière plus mesurée du côté des banques pour les tests EBICS.

Finalement, ces informations supplémentaires sur les paramètres font déjà partie du fichier d’ordre lui-même et, de toute façon, elles peuvent être lues à partir de ce dernier. Que faut-il faire en cas d’indications contradictoires ? Un surplus de gestion dans le serveur bancaire implique plus de temps et davantage d'efforts pour la gestion des référentiels. Il devrait y avoir un accord client propre à chaque version de format d'une opération métier. En plus, ces détails de format sont visibles par le client dans le logiciel client et certains d’entre eux ne peuvent pas être contrôlés.

Que se passerait-il si, par exemple, le serveur bancaire prenait en charge les versions 03 et 04 d'un format XML lors de la remise, mais que le client remettait la version 04 dans le BTF au lieu d’utiliser la version 03 du format ? L’ordre serait rejeté lors de la prise en compte de la version, bien que le système bancaire puisse traiter la version de format. La version réelle est reconnaissable au moyen du namespace.

La mise à disposition de fichiers pour download est encore plus compliquée. Celle-ci devrait être générée de manière synchrone dans la version demandée à la date/heure de téléchargement et être publiée en tant que fichier. Il en va de même pour les téléchargements historiques.

Conclusion : les institutions financières ne devraient pas être trop restrictives dans leurs définitions des accords BTF avec leurs clients. Cela leur permettrait ainsi d’être plus flexibles et d’économiser du temps et des efforts supplémentaires dans la gestion des contrats et des référentiels.


Auteur: Michael Lembcke

Réactions :

0 commentaires:

Enregistrer un commentaire