Dans la série «Comment améliorer EBICS», 1re partie – référence d’ordre client

Avec cette nouvelle série, je souhaite lancer une nouvelle rubrique invitant à réfléchir aux extensions d’EBICS envisageables et judicieuses. Ces propositions sont issues d’un cadre spécifique ou technique concret, dont découle la solution proposée. La première édition de cette série est consacrée à la référence d’ordre client.

Certains clients se sont souvent enquis de la possibilité d’associer une référence à un ordre, par exemple sous forme d’un nom de fichier ou d’un identifiant quelconque. Cette référence doit être sans équivoque. Le client serait ainsi en mesure d’obtenir l’état du traitement de l’ordre uniquement en indiquant la référence, que le traitement ait été terminé plusieurs jours auparavant ou qu’il soit encore en cours. Cette même référence permettrait en outre d’effectuer un contrôle pour éviter les doublons.

Il semble évident que l’ID d’ordre existant, formé de 4 caractères, n’est pas en mesure de répondre aux exigences précitées. Cet ID d’ordre est attribué par le serveur EBICS depuis la version 2.5, mais il se révèle équivoque.

Or, les exigences pourraient être satisfaites par l’introduction d’une référence d’ordre client (Customer Order Reference), qui viendrait compléter le standard EBICS. Concrètement, la mise en œuvre pourrait s’effectuer de la manière suivante:

• Introduction d’une référence individuelle d’ordre client, par exemple de 512 caractères. Cette référence peut être librement attribuée par le client. Elle peut par exemple être constituée du nom du fichier, d’un identifiant quelconque ou d’une combinaison des deux. La référence d’ordre client doit être indiquée dans le compte-rendu (PTK/HAC).
• Pour chaque client, l’unicité de la référence est vérifiée par le serveur EBICS de la banque, par exemple dans un délai de 90 jours. Lorsqu’un ordre est soumis avec une référence pour laquelle un envoi a déjà été effectué avec succès, l’ordre est refusé. En revanche, si un deuxième envoi portant la même référence d’ordre client intervient alors que le premier envoi est encore en cours, ce dernier est terminé avec erreur. Il est ainsi possible d’utiliser la référence d’ordre client même lorsqu’un transfert reste bloqué. Le refus est dans tous les cas indiqué dans le PTK/HAC.
• Lorsque les comptes-rendus PTK/HAC du serveur EBICS de la banque sont par exemple complétés par le Clearing, ils devraient également comporter la référence d’ordre client correspondante, dans la mesure où cette dernière se réfère à une remise.

Les ordres suivants seraient envisageables au regard des requêtes :

• Le client peut demander un PTK/HAC de manière ciblée pour une ou plusieurs références d’ordre client. Le PTK/HAC tel qu’il se présente à ce moment est alors transmis au client. L’état de restitution du PTK/HAC reste ici inchangé.
• Toutes les références d’ordre client déjà remis peuvent être recherchées. La période peut alors être limitée de la même manière que pour l’historique de restitution. Il s’agirait d’une fonction de service pour les références d’ordre client.

L’introduction d’une référence d’ordre client, permettant la recherche ciblée de telles références ainsi qu’un contrôle des doublons, serait sans nul doute un outil puissant. Le client pourrait rechercher des ordres individuels et serait en mesure d’instituer un système de contrôle des doublons efficace. La banque quant à elle pourrait étendre les possibilités de recherche mises à la disposition de ses clients, et ainsi réduire le nombre de sollicitations auprès de ses services. Le contrôle de doublons pourrait même être délégué au client. L’introduction d’une telle référence serait donc une situation gagnant-gagnant pour les banques et les clients. Que demander de plus?

Michael Lembcke