Private business:Service GEMME créancier

Le service GEMME créancier peut être décrit avec le diagramme de séquence ci-dessous :

Un exemple

Nous décrivons un cas d'usage et sa mise en œuvre avec les formats XML et PDF.

Description du cas d'usage

L'entreprise FFFF gère ses virements à l'aide du progiciel XXXX et utilise EBICS pour communiquer avec sa Banque. Le progiciel XXXX est capable de générer des messages structurés pour les échanges automatiques avec d'autres systèmes d'information et notamment il est capable de générer des flux XML et des fichiers PDF. FFFF sait faire développer des états personnalisés pour ses besoins. Elle décide donc de faire développer un canal SEPAmail pour transmettre automatiquement à ses clients ses ses demandes de règlements de factures.

Dans un premier temps, elle ne souhaite pas recevoir la confirmation de l'acceptation de chaque demande de règlement de factures si ce n'est grâce à un fichier global de réconciliation des acceptations et des refus qu'elle reçoit déjà de sa banque à fréquence fixe. FFFF souhaite donc seulement automatiser et simplifier l'envoi de la demande d'acceptation du virement automatique via SEPAmail depuis son progiciel XXXX.

Nous décrivons ci-dessous la mise en œuvre de cette demande pour les deux formats XML et PDF via la plate-forme EBICS mise en place entre l'entreprise et sa banque (ou ses banques).

Exemple avec le format XML

Le progiciel XXXX doit générer un message SEPAMail MandateInitiationRequest dont le schéma XML est accessible sur l'espace dédié : www.sepamail.eu/xsd.

Ce message comprend un entête et le corps du message décrit ci-dessous succinctement :

• entête :
  • identifiant unique du message (MsgHdr.MsgId)
  • type du message MsgHdr.MsgTyp, ici mandat@direct.debit
  • une ou plusieurs références (facultatives) du message
• corps :
  • un mandat au format pain.009.001.01 (ISO 20022)
  • des informations supplémentaires utile pour la gestion connexe du mandat
  • une date/heure de péremption de la demande de mandat (facultative)
  • un code du statut du mandat (obligatoire)
  • le type de signature du mandat (manuel ou sepamail)
  • un code retour de règlement (facultatif)
  • les références d'un ou plusieurs documents (titre, langue, type obligatoires, date et type facultatifs) avec un contenu facultatif (binaire) attaché
  • la signature du débiteur (obligatoire)
  • la signature du créancier (facultatif)
  • un logo (facultatif)
  • le prénom, nom et civilité du débiteur (facultatif)

Le flux XML SEPAmail est :

1. généré
2. vérifié (xml conforme et valide selon le schéma sepamail message direct.debit MandateInitiationRequest)
3. encodé en base64, afin d'être compatible avec la norme EBICS (base64Binary pour le type OrderDataType, balise OrderData au sein de la balise DataTransfer)
4. intégré dans un flux de transfert après avoir initié une requête FUL sur un nom de fichier de type pain.xxx.sepamail_mes_dd_mir

Lors du dépôt du fichier, on ne demande pas le contrôle des montants et des comptes car ces contrôles n'ont pas forcément de sens dans ce cas d'usage.

Exemple avec le format PDF

Le progiciel XXXX doit générer un fichier PDF/A-1 incluant obligatoirement la métadonnée suivante :

• xmp:sepamail_missive contenant le message SEPAmail tel que décrit dans le paragraphe précédent

et facultativement les métadonnées suivantes :

• xmp:sepamail_document.signed si le document PDF est signé et qu'il est demandé à SEPAmail de prendre en compte cette signature (par défaut, SEPAmail considère cette variable à False si elle est non présente)
• xmp:sepamail_document.generator avec le nom et la version du progiciel FFFF (ce qui permet de recenser les bogues liés à un progiciel en particulier)

Le fichier doit bien être au format PDF/A-1, ce qui signifie que :

• les polices doivent être incluses dans le fichier,
• les couleurs doivent être incluses dans le fichier,
• les images doivent être incluses dans le fichier,
• il ne doit pas y avoir de liens externes dynamiques (lien direct vers un site web) car cela peut mettre en danger la pérennité du fichier
• les protections spécifiques au fichier (impression, copies interdites) ne peuvent pas être appliquées
• il doit y avoir une métadonnée précisant le format PDF/A-1

Le flux XML SEPAmail est :

1. généré,
2. vérifié (xml conforme et valide selon le schéma sepamail missive intégrant un message direct.debit MandateInitiationRequest).

Puis le fichier PDF/A-1 est

1. généré en insérant le flux xml,
2. vérifié,
3. encodé en base64, afin d'être compatible avec la norme EBICS (base64Binary pour le type OrderDataType, balise OrderData au sein de la balise DataTransfer),
4. intégré dans un flux de transfert après avoir initié une requête FUL sur un nom de fichier de type pain.xxx.sepamail_message_DirectDebit_MandateInitiationRequest,

Lors du dépôt du fichier, on ne demande pas le contrôle des montants et des comptes car ces contrôles n'ont pas forcément de sens dans ce cas d'usage.

Les fichiers PDF sont transportés par la plateforme d'EBICS au sein d'un format variable permettant d'isoler chacun des fichiers PDF du fichier final. C'est, là encore le format xml, qui lève cette difficulté. SEPAmail sait reconnaître au sein d'un fichier/flux pain.xxx.sepamail_mes_dd_mir un fichier PDF s'il est intégré à un fichier xml minimal tel quel spécifié par le schéma sepamail_missive_file.xsd.