Private business:Service RUBIS créancier

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

un exemple de mise en œuvre

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

Description du cas d'usage

Un créancier FFFF a besoin d'émettre des demandes de règlements en direction de ses clients à fréquence régulière en insérant un document « humainement » lisible (actuellement envoyé par courrier postal) reprenant la nature et l'explication de la demande de règlement, les conditions générales de la transaction.

Il utilise :

• un logiciel bureautique relié à sa base de donnée,
• la fonction publipostage avec un modèle du document imprimé
• une mise sous enveloppe manuelle avec la poste pour la distribution du courrier
• une gestion des règlements selon les canaux de réception (chèque par voie postale ou sur site, espèces sur site, virement avec rapprochement sur relevé bancaire)

La fonction de publipostage a été réalisée par la société éditrice du logiciel métier XXXX.

Cette société est prête à faire évoluer cette fonction pour automatiser l'envoi d'un flux SEPAmail.

L'entreprise FFFF désire conserver la possibilité de faire évoluer le document lisible par ses clients dans son logiciel bureautique.

La société éditrice propose de réaliser un développement personnalisé DDPP pour son client en dehors de son progiciel en développant une fonction de publipostage SEPAmail.

Cette fonction récupère en entrée :

• les données variables depuis la base de données de son progiciel,
• le gabarit du document modifié par l'entreprise FFFF, avec des clés décrivant quelles variables sont fusionnées
• un gabarit de missive SEPAmail incluant un message Payment Activation Request avec, là aussi, des clés décrivant quelles variables sont fusionnées. Ce gabarit est réalisé par XXXX et n'est pas touché par FFFF

Elle réalise ensuite la fusion des deux gabarits avec les données source et assure l'envoi a la banque de FFFF.

Exemple avec le format XML

Le programme DDPP doit générer un message SEPAMail PaymentActivationRequest 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 activation.request@payment.activation
  • une ou plusieurs références (facultatives) du message
• corps :
  • une demande de règlement au format pain.013.001.01 (ISO 20022)
  • des informations supplémentaires utile pour la gestion connexe de la demande de règlement

Le flux XML SEPAmail est :

1. généré
2. vérifié
3. envoyé

Exemple avec le format PDF

Le programme DDPP 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 programme DDPP (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_PaymentActivation_ActivationRequest,

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[3].