lundi 28 avril 2014

Se former à SEPAmail

Je reçois assez souvent des questions autour de "comment se former à SEPAmail ?".

Je propose alors d'intervenir dans les entreprises qui le souhaitent avec une offre variant de 1/2 journée à 3 jours et sur des sujets variés :
J'utilise le logiciel open source scenari (et sa chaine éditoriale Opale) pour produire un livret et une présentation cohérente et évolutive.

Je ne connais pas encore d'autre offre de formation dédiée à SEPAmail, même si quelques formations SEPA parlent de SEPAmail.
Cela est du, il me semble, au nombre de sachants encore peu nombreux.

Mais gageons que 2014/2015 verra de nombreuses offres éclorent, offres que nous pourrions relayer dans ce blog.

En attendant, je vous propose en ligne une mini-formation intitulée "SEPAmail en 20 minutes", inspirée de mon billet de janvier 2013.

jeudi 10 avril 2014

FAQ n°6

Q6.1 : Renvoi, doit-on changer la date ?


La question peut se poser ainsi : si je renvoie une missive comme cela est possible, est-ce que je change la date ?

Une réponse rapide est : NON, on ne change que l'ordre quand on renvoie une missive, en l'incrémentant de un.

Voici une explication détaillée de cette réponse rapide :

On trouve la règle à appliquer dans la directive d'implémentation de la missive :
""If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent. All other missive fields, including MsvId and SndDtTm, must be unchanged."

Quel est le sens de cette règle ?

Pour le comprendre, il faut une petite explication :

  • Le message SEPAmail, c'est le signifiant échangé entre les utilisateurs
  • La missive SEPAmail, c'est l'enveloppe de messagerie du réseau privé SEPAmail
  • L'enveloppe SEPAmail, c'est l'enveloppe de sécurité en cas de transport (mode flash ou canonique) sur un réseau public.
Le protocole SEPAmail, c'est un protocole qui permet :
  • cette double encapsulation,
  • une authentification des parties par les relais,
  • un accusé de réception par l'adhérent pour le compte de son utilisateur, quelque soit le cas d'usage (l'application, le nombre d'acteurs...)
  • une forme de "garantie" pour un utilisateur émetteur que son envoi sera acquittée (renvoi, escalade, acquittement obligatoire 24/24 7/7 par l'adhérent récepteur selon la priorité)
Renvoyer une missive, ce n'est pas obligatoire mais une possibilité, offerte si le système émetteur chez l'adhérent considère que l'acquittement des envois précédent pour la même missive n'est pas arrivé.

Par contre, acquitter une missive, c'est obligatoire.

Quand l'émetteur renvoie une missive, voilà ce qu'il dit à son récepteur de missive : "je vous ai déjà émis une missive pour telle personne à telle heure. Comme mon système n'a pas encore enregistré d'accusé réception et que j'ai besoin de cet accusé de réception, je vous renvoie, comme j'en ai la possibilité, la même missive. Pour vous signifier que c'est un renvoi, j'incrémente de 1 l'ordre de la missive. Merci de m'acquitter, comme vous en êtes obligé en tant qu'adhérent, cette missive et les précédentes, si vous les avez reçues."

Quand on raisonne sur ces sujets, il faut absolument ne pas vouloir connaître le statut précis ou le comportement précis de son interlocuteur; mais appliquer le protocole de son point de vue.

Celui qui spécifie le composant qui envoie et reçoit les missives des parties, doit, bien entendu imaginer tous les cas, dont celui pour lequel la contrepartie essaie de frauder ou pour lequel la contrepartie a un système défaillant. Des systèmes de régulation de ces comportements sont présents dans SEPAmail et dépasse le simple cadre de l'acquittement des missives. Pour mémoire, ce sont l'engagement contractuel des adhérents, le procédé d'escalade, la surveillance du réseau par SEPAmail.eu.

Q6.2 :  Pourquoi y a-t-il Acquittement et Aknowledgement dans les types de missives ?


Les schémas XML autour de SEPAmail sont écrits en anglais, pour pouvoir être lus par tous. Les types de missives étaient écrits en français, ce qui ne posait pas de problème pour Service, Nominal et SMAPI qui sont équivalents en anglais mais ce n'est pas le cas pour Acquittement.

En 2010, le committer a donc accepté ma demande de transformer Acquittement en Aknowledgment, tout en conservant Acquittement à des fins de rétro-comptabilité. Les deux termes sont donc équivalents, comme annoncé dans la directive d'implémentation de la missive.

La règle implicite est donc la suivante :

Tout composant mettant en œuvre le standard SEPAmail DOIT accepter en réception les types Acquittement et Aknowledgment.

Mon conseil est de rajouter :

Tout composant mettant en oeuvre le standard SEPAmail DEVRAIT utiliser en émission le type Aknowledgment.

Q6.3 Où peut-on trouver des exemples de flux ?


Cette question revient souvent; elle est tout à fait licite.

J'ai créé en 2013 un espace communautaire pour partager nos exemples.

Il se trouve sur la plateforme google code et a pour petit nom SMITE : SEPAmail I want TEst !

L'espace pourrait être augmenté de nos exemples.

Le problème de chacun est de savoir si son exemple est bien conforme à:

  •  les schémas XML
  •  les directives d'implémentation
  •  les règles opérationnelles entre les adhérents

Pour le premier point, c'est facile puisque tous les outils existent et les schémas sont publiés et stables.

Pour le deuxième point, les directives d'implémentation sont publiées mais certaines règles semblent être encore porteuses d’ambiguïté. La démarche est donc de demander au comitter SEPAmail via l'espace communautaire son avis, soit en direct, soit par la fonctionnalité discuter du wiki.

Pour le troisième point, c'est plus compliqué car ces règles ne sont pas publiées. Pour les avoir consultées, je peux vous assurer qu'il n'y a peu de règles qui touchent aux flux messages ou missive dedans (la taille maximale des flux acceptée pour le moment) mais plus des règles pour connecter entre elles les infrastructures et piloter la mise en production après expérimentation.

Je propose à tous ceux qui souhaitent partager leurs exemples de les aider dans leur démarche. N'hésitez pas à me contacter.

Ces pages sont également ouvertes pour ceux qui désirent partager un billet sur ces sujets.

Je souhaite que nous ne faisions pas comme d'autres communautés à écrire les règles sans partager des exemples qui facilitent leur compréhension.


Q6.4 SEPAmail et RUBIS, c'est la même chose ?


SEPAmail est une messagerie sécurisée fournie par des adhérents SEPAmail à leurs clients ou leurs agents, ceux que l'on appelle des utilisateurs SEPAmail.

RUBIS, comme GEMME, JADE, DIAMOND, sont des applications de SEPAmail qui répondent à un besoin précis des utilisateurs.

Donc, SEPAmail et RUBIS ne sont pas la même chose. Les utilisateurs ne devraient pas entendre parler de RUBIS puisque les cinq adhérents actuels se sont entendus sur la notion de "règlement (via) SEPAmail" pour parler de RUBIS. RUBIS reste un nom de code interne à la communauté SEPAmail.

Q6.5 Quelle est la limite en taille d'un message, d'une missive, d'une enveloppe ?


C'est l'une des exceptions à ce que j'ai dit plus haut. La limite a été fixée dans les règles opérationnelles et elle est de 200kos pour l'enveloppe SEPAmail, c'est à dire trop peu. En effet, comme un fichier pdf (par exemple une facture) est encapsulé dans un message SEPAmail, puis une missive SEPAmail et enfin une enveloppe SEPAmail.

Q6.6 SEPAmail, c'est une norme, un standard, un protocole ?


SEPAmail est un protocole, puisqu'il précise un ensemble de règles pour des acteurs qui cherchent à organiser entre eux une fonctionnalité.

Les français distinguent la norme du standard : la norme est un texte normalisé par un organisme de normalisation reconnue (ou officiel). Le standard est un texte utilisé par une communauté.

Si on reconnait SEPAmail.eu comme un organisme de normalisation officiel, alors SEPAmail est une norme. Ce n'est à mon avis pas encore le cas.

Il existe aujourd'hui une communauté de fait autour de SEPAmail, c'est donc bien un standard de fait.


Q6.7 Quel est le statut de votre blog et de vos réponses ? Puis-je m'y fier ?


Notre blog (nous sommes pour le moment deux rédacteurs) se veut un point de rassemblement de ceux qui participent à la communauté SEPAmail (les lecteurs) et de ceux qui veulent partager des points de vues et des informations sur SEPAmail (les rédacteurs, les interviewés...).

Le blog n'est pas le blog officiel de SEPAmail.eu.

Les éclairages amenés n'engagent donc pas SEPAmail.eu et n'engagent, d'une manière générale, que leur auteur.

Il n'y a pas de comité de validation des billets rédigés.

Comme le blog est lu et (de temps en temps) commenté, vous pouvez, à mon sens, vous fier à ce qui est écrit et vous forger une opinion sur son contenu.

Les deux auteurs sont :

  • Olivier Jousselin, comitter du standard de 2009 à 2013, rédacteur de la SMIRK Jade en 2013
  • Manfred Olm, co-auteur du premier draft en 2008, de quelques SMIRKs en 2011 et 2012, missionné de 2010 à 2012 pour réaliser le contrôle de cohérence entre le standard et les expérimentations ayant été réalisées.

Nous partageons ainsi avec vous le plaisir que vous avez, nous l'espérons.

mardi 8 avril 2014

FAQ n°5

Q5.1 : RUBIS : Combien de décimales sont autorisées dans le montant à payer ?


Le montant se trouve, dans la requête RUBIS (message ActivationRequest), dans le fragment xml Amt (xpath /sem:ActivationRequest/sem:ReqCompl/sem:Request/pain013:PmtInf/pain013:CdtTrfTx/pain013:Amt/pain013:InstdAmt).
Selon le shema XML du pain013, le montant est un nombre décimal positif qui peut avoir 5 décimales au plus.
Selon la directive d'implémentation RUBIS du message ActivationRequest, le montant ne peut pas être nul.
Le montant minimum est donc 0.00001 et un message avec ce montant valide bien le schéma XML du message.

Ce nombre de décimales permet d'effectuer la conversion entres les différentes devises sans ambigüité sur la deuxième décimale. C'est la règle générale qui a été adoptée en Europe au moment du passage des monnaies nationales à l'euro. Elle parait donc adaptée à l'univers SEPAmail et à la zone SEPA en particulier.

L'EPC a précisé pour le pacs.008 puis le pain.001 une règle plus contraignante qui peut se résumer à "Format rule: The fractional part has a maximum of two digits". On retrouve cette règle par exemple pour l'échange de pain.001 entre une banque et son client (référence IG SCT Bank-Client v7.0, Instructed Amount AT-04).

Certains guides du CFONB reprennent la règle ISO (5 décimales) ou la règle EPC (2 décimales).

La question est donc bien licite pour RUBIS.

Concernant une demande de règlement, quel est le sens de payer un montant avec 5 décimales ?
Dans la plupart des usages proposés par RUBIS, cela n'a aucun sens, donc une règle d'au plus 2 décimales aurait du sens.
D'un autre côté, Rubis ne propose que la demande de règlement et non le règlement lui-même, qui est articulé par la banque de débiteur selon le contrat qu'elle a avec le débiteur. Les cas d'usage qui ont été relevés lors du passage à l'euro, peuvent toujours donc se dérouler avec RUBIS.

Il parait raisonnable donc, pour pouvoir s'articuler avec un règlement par virement et être compatible avec les règles EPC d'implémenter à minima les règles suivantes :
  • un créancier DEVRAIT utiliser des montants avec au plus deux décimales s'il n'a pas besoin de conversion
  • l'adhérent du débiteur DOIT arrondir à deux décimales selon les règles d'usage des arrondis dans le monde bancaire tout montant émanant d'une demande de règlement avec plus de deux décimales avant d'initier un règlement par virement (pacs.008 ou pain.001)



Q5.2 : Comment doit réagir un adhérent si une missive n'est pas adressée à un de ces clients ou l'émetteur n'est pas chez l'adhérent qui envoie la missive ?

Le cas est simple et se présente de temps à autre.
L'adhérent émetteur de la missive envoie à un adhérent une enveloppe SEPAmail correcte contenant une missive dont :
  • l'expéditeur (balise Snd) n'est pas un QXBAN de l'émetteur (mauvais BIC)
  • le destinataire (balise Rcv) n'est pas un QXBAN du récepteur (mauvais BIC)
La missive peut donc être acquittée puisqu'elle est valide et lue correctement.

En version 1206, le relai entre les adhérents n'est pas autorisé.
  • Conséquence 1 : l'adhérent qui reçoit la missive NE DOIT PAS  la relayer.
  • Conséquence 2 : L'adhérent qui a envoyé la missive NE DEVAIT PAS la relayer également.

L'acquittement est donc négatif (NAK).
Le code retour peut être utilisé; c'est 511 pour le premier cas (mauvais Snd) et 512 pour le second (mauvais Rcv)

Q5.3 : peut-on envoyer une missive d'ordre 0 ?

Le schéma XML de la missive (voir ici) décrit une balise MsvOrd comme un entier.
Par contre, la directive d'implémentation de la missive donne explicitement l'usage de cette balise : "Usage Rule : this field must be set to 1 (one) at first sending of a given missive. If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent. All other missive fields, including MsvId and SndDtTm, must be unchanged.
Usage Rule: for an acknowledgement missive, the order number will be the one of the missive it acknowledges."

On commence à un et on incrémente de un à chaque renvoi.
On acquite une missive avec le même ordre que la missive nominale acquittée.

Que faire alors si on reçoit une missive nominale d'ordre 0 ?
On acquitte négativement (NAK) avec un code retour 584 ( Order number error).

Mais que faire pour l'ordre de la missive d'acquittement puisqu'il est dit : "Usage Rule: for an acknowledgement missive, the order number will be the one of the missive it acknowledges." ?

Quitte à être non conforme à la directive, je préconise un ordre à 1 et non 0.


De même, si l'ordre n'est pas un entier positif (par exemple un entier négatif), j'acquitterai négativement (NAK) avec un code retour 581 (XML syntax error, non conforming to schema) et un ordre 1.

Q5.4 est-on obligé de renvoyer une missive ?

L’émetteur d'une missive qui n'a pas reçu à temps un acquittement peut renvoyer une missive, selon la directive d'implémentation de la missive et la SMIRK Missive.
La première dit "If the missive needs to be resent, with the same contents, this number MUST be incremented by one each time it is resent".
La seconde dit "Un système de renvoi d'une missive peut être implémenté.[...] l'émetteur de toute missive nominale dont l'acquittement n'est pas constaté dans un temps supérieur aux minima définis pour la priorité de la missive peut renvoyer la missive avec un numéro d'ordre incrémenté ; il s'interdit de le faire avant ; il n'est pas obligé de le faire"

L’émetteur peut donc renvoyer une missive mais il n'est pas obligé de le faire; il n'est même pas obligé d'implémenter le système donc de proposer le service à son client.