Standards:IG AigueMarine AccountSwitchingInformationServiceNotify

Cette page est à l'état de validation.
Elle est en cours de révision par les instances officielles, et devrait devenir une norme définitive prochainement.

Le message AIGUE-MARINE SwitchingNotify

Généralités

Ce message est envoyé par l'Établissement d'Émetteur (ÉÉ) à l'Établissement d'Arrivée (ÉA).

Il intervient obligatoirement en réponse à un message SwitchingForward envoyé par l'ÉA.

Besoin fonctionnel

Même s'il n'est pas prévu dans le schéma de la Profession, ce flux retour est indispensable dans le cadre d'une messagerie correctement structurée. En effet, le destinataire d'un message doit au minimum disposer d'un moyen d'indiquer que le contenu d'un message n'est pas correct.

Nous ne parlons pas ici de réponse protocolaire ou technique, qui est assurée par la missive d'acquittement, mais bien d'une réponse métier.

Voici par exemple un cas dans lequel ce message est indispensable :

• si l'établissement d'émetteur reçoit un message pour un émetteur qui n'est plus parmi ses clients, alors qu'elle est responsable de l'acheminement de l'information vers cet émetteur, elle doit pouvoir informer l'ÉA, pour que celui-ci puisse éventuellement faire parvenir cette information au Client concerné.

Pour des raisons de responsabilité des uns et des autres, il est donc nécessaire d'avoir un flux retour.

Cas d'usage

Dans le cadre actuel, pour simplifier la mise en place du flux 4R, seuls les messages à l'initiative de l'ÉÉ sont prévus.

Voici les deux cas d'usage concernés :

• positif : message transmis à l'émetteur
• négatif : message non transmis, pour une raison à préciser, par exemple
  • émetteur inconnu
  • émetteur non joignable

Fonctionnement du message

L'ÉÉ doit envoyer un et un seul message SwitchingNotify par message SwitchingForward reçu.

Il doit être envoyé aussitôt que possible, c'est-à-dire dès que les éléments internes à l'ÉÉ permettent de déterminer si le message a été transmis ou non à l'émetteur — voire simplement si le message pourra lui être transmis. En effet, le message ne comporte pas, dans son état actuel, de notion d'accusé de réception, par l'émetteur lui-même, du message transmis.

Le délai opérationnel d'envoi du flux retour sera donc de deux jours ouvrables.

Contenu du message

Le contenu du message est extrêmement simple :

• le rappel des éléments de la demande, selon les principes de SEPAmail (messages auto-portés)
• une réponse, positive ou négative
• si elle est négative, éventuellement une précision sur son statut (pourquoi est-elle négative ?)

Rappelons que les éléments de nature commerciale, du genre "plus de relation entre l'émetteur et son client", doivent rester strictement dans la sphère des relations entre l'Émetteur et le Client.

Le message a été conçu selon les mêmes lignes que ceux du CFONB, en ajoutant simplement un bloc 2 au message SwitchingForward que l'ÉÉ reçoit. Ce bloc 2 peut donc avoir deux contenus, selon que le message est positif ou négatif.

Dans le cas positif, le contenu est fixe (code de retour positif TS01), l'ÉÉ conservant la possibilité d'ajouter des précisions dans le champ AdditionalInformation.

Dans le cas négatif, le code de retour peut prendre l'une des 3 valeurs suivantes :

• BE01 (InconsistentWithEndCustomer, émetteur inconnu ou message incorrect)
• BE06 (UnknownEndCustomer, émetteur ne pouvant être joint)
• MS03 (NotSpecifiedReasonAgentGenerated, autres cas)

Voici le contenu de ce message :

• dans le cas positif
• dans le cas négatif

Extensions futures

Dans des versions ultérieures, explicitement exclues du périmètre actuel de SEPAmail, il pourrait être possible de prendre en compte d'autres cas d'usage de ce message, notamment à l'initiative de l'émetteur :

• le cas négatif
  • Client inconnu (ou plus de contrat en cours)
  • Modification déjà réalisée
• le cas positif
  • client identifié, modification réalisée