spécifications - documentation SEPAmail

Transcription

DOCUMENT DE LA SÉRIE
«SPÉCIFICATIONS»
SPÉCIFICATIONS FONCTIONNELLES
IMPRIMANTE SEPAMAIL RUBIS
VERSION
1. VERSION
Date
20120131.003
DU DOCUMENT
Version du document
Intervenant
Action
Validation
23/01/2012
Version initiale, pour relecture
Manfred S. Olm
Rédaction
26/01/2012
Version 20120126.002
Manfred S. Olm
Ajout des remarques
Cyril VIgnet
31/01/2012
Version 20120131.003
Manfred S. Olm
Finalisation structure
avant envoi
Cyril VIgnet
2. DOCUMENTS
Date
RÉFÉRENCÉS
Document
Auteur
Version
Ce document ne peut être diffusé sans l'accord explicite de ses auteurs ou de ses
destinataires.
Série Spécifications
Document SPF1201
1/13
scheme SEPAmail – au service du réseau des adhérents SEPAmail
3. INTRODUCTION
Le logiciel « Imprimante Sepamail Rubis Creancier » de nom de code SMURF (Sepa Mail
Universal Resource Formater) permet pour les clients créanciers des banques
adhérentes du réseau SEPAmail de générer en relation avec leur logiciel ERP des
documents au format SEPAmail.
4. SOMMAIRE
1. Version du document........................................................................................................................1
2. Documents référencés.......................................................................................................................1
3. Introduction......................................................................................................................................2
4. Sommaire..........................................................................................................................................2
5. Le contexte.......................................................................................................................................2
6. Les acteurs........................................................................................................................................4
7. Le principe........................................................................................................................................4
8. Le séquencement détaillé..................................................................................................................5
9. Le modèle de donnée........................................................................................................................6
10. Les fonctionnalités..........................................................................................................................7
10.1. Récupérer les demandes de paiement......................................................................................7
10.2. Sélectionner/ Dé-sélectionner les demandes de paiement.......................................................8
10.3. Génération des demandes de paiement au format pdf/a-1a.....................................................8
10.4. Envoi des demandes de paiement au client de messagerie....................................................10
10.5. Génération d'un récépissé d'envoi.........................................................................................10
11. Les librairies à utiliser...................................................................................................................10
12. Les écrans.....................................................................................................................................10
12.1. l'écran RUBIS.......................................................................................................................11
12.2. l'écran paramétrage...............................................................................................................11
12.3. l'écran aide.............................................................................................................................11
13. Les livrables..................................................................................................................................12
14. la qualification...............................................................................................................................12
15. Évolutions pour versions ultérieures.............................................................................................13
5. LE
CONTEXTE
Un client créancier dispose d'un logiciel ERP1 qui lui permet de disposer des comptes de
ses clients.
Pour disposer du service RUBIS2, il a besoin de pouvoir envoyer ses demandes de
paiement au format RUBIS sur la prise SMILE de sa banque.
Le composant SMURF va lui permettre de générer automatiquement le document pdf
au format SEPAmail à envoyer à la prise bancaire SEPAmail SMILE, soit directement
(canal web service), soit via un client de messagerie S/Mime (canal messagerie).
1 Enterprise Resource Planning ou Progiciel de gestion intégrée en français (PGI)
2 RUBIS est l'acronyme français de "Règlement Universel Bancaire Immédiat & SEPA". L'application permet le
paiement de facture par virement en initiant une demande de paiement.
Document SPF1201
2/13
Ce composant est paramétrable
•
•
en entrée avec :
◦
un gabarit du document à générer (la demande de paiement, par exemple
une quittance de loyer, une facture pro-format etc...) au format
OpenDocument.
◦
un gabarit du flux SEPAmail à générer (la demande de paiement RUBIS) au
format xml SEPAmail
◦
une connexion/requête sur la base de données de l'ERP ou un fichier de
données brutes
en sortie avec :
◦
soit une prise au client de messagerie (protocole mailto://)
◦
soit une prise directe au web-service SMILE
◦
soit un fichier utilisable sur une autre prise avec sa banque (EBICS, dépôt
fichier...)
SMURF avec prise directe à l'ERP
Le SMURF est développé avec les contraintes
suivantes :
SMURF sans prise directe à l'ERP
Document SPF1201
3/13
•
le composant utilise le langage de programmation JAVA,
•
le composant utilise un unique fichier de configuration,
•
le composant pourra être installé indifféremment sur MacOS, windows ou tout
système UN*X dont GNU/Linux,
•
le composant est développé sous licence open source « Creative Commons
Paternité - Partage à l'Identique 3.0 non transposé » pour les composants
développé spécialement pour l'outil et sous n'importe quelle licence libre pour
les composants réutilisés en respectant les termes de chacune d'elles.
6. LES
ACTEURS
Le composant SMURF est utilisé par le service réalisant les demandes de paiement.
L'utilisateur principal du composant est un agent humain qui génère les demandes à
partir d'une requête paramétrée et d'un gabarit vérifié et mis à jour si besoin. C'est
donc un utilisateur habituel de la fonction publi-postage d'un traitement de texte ou
d'un écran de génération de demande de paiement dans un ERP. Cet utilisateur a
besoin d'une interface pour réaliser ces opérations.
On peut envisager qu'une ressource informatique intervienne pour le paramétrage du
composant SMURF si ce paramétrage est durable et ne doit pas changer à chaque
génération de demande de paiement. Pour une bonne visibilité du composant vis à vis
de l'utilisateur premier, ce paramétrage est possible au sein d'une interface, avec la
mention « avancée ».
Les automates acteurs de la cinématique autour du composant sont :
•
SMILE, accessible via une interface web-service
•
le client de messagerie, accessible via une interface protocolaire (mailto://)
•
le moteur de base de données du logiciel ERP, accessible via une connexion de
type odbc depuis un utilisateur externe, sans passer par l'ERP directement
SMILE et le client de messagerie sont utilisés exclusivement l'un de l'autre, selon le
mode de transmission choisi, courriel sécurisé ou web-service.
7. LE
PRINCIPE
Le composant SMURF se connecte, sur demande de l'utilisateur, à la base de données
de l'ERP et réalise la requête paramétrée pour récupérer un jeu de données sur les
demandes de paiements (par exemple le montant, la référence client, l'objet de la
demande de paiement, les dates).
L'utilisateur du composant doit pouvoir :
•
filtrer ce jeu de données et ne choisir que les demandes désirées,
•
tester la génération des demandes de paiement au format SEPAmail PDF 1.5/A1 3,
3 http://fr.wikipedia.org/wiki/ISO_19005-1
Document SPF1201
4/13
•
valider le jeu de données et générer la demande définitive,
•
récupérer un état des demandes validées et générées pour archive de l'action,
•
enregistrer la configuration du composant pour pouvoir réutiliser de façon
automatique cette configuration,
•
accéder au paramétrage du composant,
•
accéder depuis le composant aux deux gabarits utilisés en entrée :
◦
le gabarit de la demande de paiement que reçoit habituellement le client, au
format opendocument 4 via un lecteur de ce format,
◦
le gabarit de la missive SEPAmail qui va permettre l'automatisation du
procédé de transmission de la demande de paiement, au format xml via un
éditeur de ce format 5.
8. LE
SÉQUENCEMENT DÉTAILLÉ
Le séquencement détaillé est résumé sur le diagramme de séquence suivant :
Soit la séquence détaillée :
1. l'utilisateur se connecte au composant (il n'y a pas besoin de gestion de droits)
2. l'utilisateur déclenche la récupération des données
4 http://fr.wikipedia.org/wiki/OpenDocument
5 La missive doit respecter le schéma http://xsd.sepamail.eu/current/sepamail_missive.xsd
et contenir un message de type payment.activation activationRequest
http://xsd.sepamail.eu/current/sepamail_message_payment.activation_ActivationRequest.xsd
Document SPF1201
5/13
3. le composant SMURF se connecte au moteur de base de données (liaison ODBC)
et réalise la requête sur ce moteur. La liaison et la requête sont fournies en
paramétrage du composant
4. le moteur de base de données renvoie un jeu de données
5. le composant SMURF présente le résultat de la requête en mode liste avec la
possibilité de filtrer la liste et sélectionner/dé-sélectionner chacun des éléments
6. l'utilisateur sélectionne/ dé-sélectionne les éléments désirés
7. l'utilisateur déclenche la génération test
8. le composant SMURF récupère le fichier gabarit de la demande de paiement
visuelle (au format opendocument)
9. le composant SMURF récupère le fichier gabarit de la demande de paiement
SEPamail (au format xml)
10.le composant SMURF réalise une fusion contrôlée des gabarits avec la sélection
utilisateur du jeu de données
11.le composant SMURF génère un pdf pour chacune des demandes de paiement
(format PDF 1.5/A6) et présente chacune des demandes de paiement (pdf) au
téléchargement au sein de la liste sélectionnée.
12.l'utilisateur vérifie cette génération
en cas de succès de cette vérification
13.l'utilisateur déclenche la validation de la génération
14.le composant SMURF produit un récépissé de génération dans un format pdf
1.5/A selon un paramétrage défini.
15.Le composant SMURF envoie chacune des demandes pdf au client de messagerie
avec la méthode mailto du client de messagerie, tout en créant sur lesystèmede
fichier local une copie de ces fichiers.
En cas d'échec de cette vérification
16.l'utilisateur revient au point 2 ou 6
9. LE
MODÈLE DE DONNÉE
Le composant SMURF manipule :
•
un fichier de configuration au format Properties 7
•
un fichier gabarit au format OpenDocument ou ODF (Open Document Format for
Office Applications) du groupe normatif OASIS (Organization for the
Advancement of Structured Information Standards) pour la demande de
paiement
•
un fichier gabarit au format OpenDocument pour le récépissé d'envoi
6 http://www.fedisa.eu/fedisa2007/info.php3?page=ARTICLES&id=322 et
http://www.pdfa.org/publication/pdfa-l%e2%80%99essentiel/?lang=fr
7 Par exemple, http://commons.apache.org/configuration/howto_properties.html
Document SPF1201
6/13
•
un fichier gabarit au format xml (une missive SEPAmail avec
•
un fichier de journalisation des actions et des erreurs, au format syslog 8
•
un récépissé de chacun des envois, au format PDF/A-1a
Il n'y a pas de base de données pour SMURF.
SMURF manipule les objets en mémoire et dans le système de fichier, avec une
arborescence paramétrable répondant à la classification suivante :
•
un répertoire pour l'application SMURF (par défaut smurf)
•
un répertoire pour la configuration de SMURF (par défaut conf)
•
un répertoire pour les gabarits de SMURF (par défaut template)
•
un répertoire temporaire pour les besoins de décharge mémoire (par défaut tmp)
•
un répertoire pour les sorties pdf de SMURF (par défaut output)
Le nom des fichiers générés répond à la norme :
[nom gabarit demande paiement]_[yyyymmddhhiiss]_[id demande].pdf
où :
•
[yyyymmddhhiiss] est la date/heure de la génération du document
•
[id demande] est l'identifiant de la demande
•
[nom gabarit demande paiement] est le nom du fichier gabarit privé de son
extension finale
10. LES
FONCTIONNALITÉS
Cette version de SMURF ne développe pas la prise directe web-service entre le SMURF
et le composant SMILE. Elle n'utilise pas non plus de données brutes en entrée mais
une connexion au moteur de base de données de l'ERP.
Les grandes fonctions sont décrites ci-dessous.
10.1. RÉCUPÉRER LES DEMANDES DE PAIEMENT
Le composant implémente une fonction de récupération des demandes de paiement.
Cette récupération se fait au moyen d'une liaison de type jdbc directement au moteur
de base de données de l'ERP.
Cette liaison est variable et paramétrable dans le fichier de configuration avec une
interface (écran paramétrage, zone paramétrage avancé). Il n'est pas grave que le mot
de passe associé à l'utilisateur de cette liaison soit en clair dans le programme.
La requête est également variable et doit permettre de récupérer à chaque demande le
bon jeu de données.
On implémente deux variables de cette requête:
•
la date de début (format date/heure)
8 http://tools.ietf.org/html/rfc5424
Document SPF1201
7/13
•
la date de fin (format date/heure)
Ces deux variables disposent d'une saisie à part dans la zone de paramétrage et
peuvent être mise en variable de la requête si besoin.
SI chacune des dates n'est pas renseignée ou mal formatée alors qu'elle est présente
dans la requête, alors un message avertit l'utilisateur de la nécessité de saisir une date
correcte.
Le nom des variables à insérer dans la requête est :
•
#SMURF#dateTimeRequestBegin#
•
#SMURF#dateTimeRequestEnd#
La fonction « récupération des données » réalise donc la séquence d’instruction
suivante :
1. ouverture de la liaison jdbc, exception en cas d'échec
2. construction de la requête, exception en cas d'échec
3. soumission de la requête, exception en cas d'échec
4. récupération du curseur sur le jeu de données résultat, exception en cas d'échec
5. peuplement de l'objet adhoc SMURF qui reçoit la liste des demandes de
paiement, exception en cas d'échec
10.2. SÉLECTIONNER/ DÉ-SÉLECTIONNER LES DEMANDES DE
PAIEMENT
Le composant implémente une fonction de sélection et désélection des demandes de
paiement proposées et affichées.
Par défaut, toutes les demandes de paiements sont sélectionnées.
Le composant permet la dé-sélection de chacune des demandes de paiement.
Le but de cette fonctionnalité est de pouvoir retirer quelques demandes de paiement
en cas de résultat (de la récupération des données) trop important et éviter ainsi que
ces demandes de paiement soient envoyées au client.
10.3. GÉNÉRATION DES DEMANDES DE PAIEMENT AU FORMAT PDF/A1A
Le composant implémente une fonction de génération des demandes de paiement au
format SEPAMail pdf.
Cette fonction est la fonction centrale du composant.
Le format de sortie impose pour chacune des demandes de paiement la génération
d'un fichier avec les contraintes suivantes :
•
le fichier est au format PDF/A-1a
•
le fichier présente des méta-données SEPAmail telles que définies ci-dessous
Document SPF1201
8/13
(spécification issue du « guide SEPAmail de l'entreprise et de l'éditeur de
logiciel »)9
◦
méta-données au format XMP10 (en dehors de l'objet DocumentInfo)
◦
encodage de ces metadata en UTF-8
◦
générateur de nom de code « smurf »
◦
méta-données à insérer
metadonnées
type
xmp:sepamail_missive
xml valide
xmp:sepamail_document.signed
xmp:sepamail_document.generator
Boolean
String(100)
description
obligatoire
contient le message lié au document
format xml valide (schema xml du message SEPAmail
correspondant) intégré dans une missive (schema xml de
la missive SEPAmail)
OUI
contient false ou true selon que la signature doit être
prise en compte par SEPAmail (remarque, le document
doit alors être signé selon une norme reconnue par
l'entreprise et sa banque)
NON
contient une chaine de caractères liée au logiciel
émetteur du document
NON
les métadonnées XMP SEPAmail du fichier PDF/A
La fonction « génération des demandes de paiement » réalise donc la séquence
d’instruction suivante :
1. récupération du gabarit OpenDocument (voir page 10 le paragraphe « Les
librairies à utiliser »), exception en cas d'échec
2. remplacement des variables #SMURF#nom_variable# par les variables de même
nom récupérées dans la requête, exception en cas d'échec sur l'une des
variables
3. récupération du gabarit xml SEPAmail, exception en cas d'échec
variables
5. génération d'un fichier pdf par demande de paiement au format PDF/A-1a (voir
page 10 le paragraphe « Les librairies à utiliser »), exception en cas d'échec à
partir du gabarit OpenDocument enrichi avec en méta données xml :
1. le gabarit xml enrichi en valeur de la métadonnée XMP clé
xmp:sepamail_missive
2. la métadonnée XMP clé xmp:sepamail_document.generator avec le code du
composant
3. nom du fichier pdf selon la norme proposée dans le paragraphe Le modèle de
donnée page 6.
Il doit être possible :
9 Pour plus de précisions sur la compatibilité de XMP avec le format PDF/A, voir http://www.pdflib.com/knowledgebase/xmp-metadata/xmp-in-pdfa/
10 spécifications des métadonnées http://www.aiim.org/documents/standards/xmpspecification.pdf
Document SPF1201
9/13
•
de visualiser chacune de ces demandes de paiements au format pdf,
•
de les imprimer une à une pour vérifier visuellement
•
de les récupérer pour vérifier la validité du format PDF/A-1a et celle du format
SEPAmail PDF (outils en ligne).
10.4. ENVOI DES DEMANDES DE PAIEMENT AU CLIENT DE
MESSAGERIE
Le composant implémente une fonction d'envoi des demandes de paiement au client
de messagerie.
A finaliser avec Cyril, pb avec mailto et attachment, astuce à trouver si beaucoup de
demande de paiement...envoi direct.
10.5. GÉNÉRATION D'UN RÉCÉPISSÉ D'ENVOI
Le composant implémente une fonction de génération de récépissé d'envoi.
Cette fonction réalise la séquence d'instruction suivante :
1. récupération du gabarit OpenDocument du récépissé (voir page 10 le
paragraphe « Les librairies à utiliser »), exception en cas d'échec
variables. On y trouve notamment ce qui concerne les demande de paiement :
date de génération, date d'envoi, nom du fichier pdf, client, montant.
3. Génération d'un fichier PDF au format pdf/A-1a et écriture dans le répertoire de
journalisation.
11. LES
LIBRAIRIES À UTILISER
La maîtrise d’œuvre utilisera les librairies suivantes :
•
jOpenDocument, pour la manipulation de gabarit OpenDocument 11.
•
iText, avec la conformité PDFA1A12 pour la génération des PDF/A ou
préférentiellement pdflib 13, qui garantit cette compatibilité.
12. LES
ÉCRANS
L'interface SMURF se compose de trois écrans que l'on décrit succinctement ci-dessous.
L'interface est classique, avec un menu imagé à gauche et le résultat de l'action de ce
menu sur la droite, comme le menu « préférences » du navigateur firefox.
11 http://www.jopendocument.org/
12 http://api.itextpdf.com/itext/com/itextpdf/text/pdf/interfaces/PdfXConformance.html
13 http://www.pdflib.com/
Document SPF1201
10/13
12.1. L'ÉCRAN RUBIS
Cet écran permet l'assistant en trois étapes, de la récupération des données jusqu'à
l'envoi.
La colonne de gauche permet la sélection des lignes. Un système de pagination est à
proposer.
Les fichiers pdf doivent être cliquables.
12.2. L'ÉCRAN PARAMÉTRAGE
Cet écran permet le paramétrage de l'application. Le bouton « paramétrage avancé »
active les paramètres non accessibles par défaut.
12.3. L'ÉCRAN AIDE
Cet écran permet l'affichage de l'aide.
Document SPF1201
11/13
13. LES
LIVRABLES
Les livrables confiés à la maîtrise d’œuvre par la maîtrise d'ouvrage sont, en sus de
cette spécification :
•
une base de donnée de test
•
trois gabarits de test : la demande de paiement, la missive SEPAmail RUBIS, le
récépissé d'envoi
•
la spécification des méta-données à inclure dans chacun des fichiers pdf (issue
du guide SEPAmail de l'entreprise et de l'éditeur)
Les livrables attendus de la part de la maîtrise d’œuvre sont :
•
L'application directement installable pour une plate-forme windows, linux et
macOs.
•
Les sources de l'application
•
Le texte de licence avec la mention de toutes les librairies utilisées et leurs
licences respectives.
•
Un fichier readme expliquant rapidement comment installer l'application sur
chacune des plates-formes
14.
LA QUALIFICATION
La qualification des livrables sera réalisée par le maître d'ouvrage désigné dans le
contrat commercial ou toute personne qu'il aura déléguée à cette qualification. Elle
sera réalisée en autant de fois que nécessaire pour permettre un résultat conforme à
ces spécifications.
Le maître d'ouvrage mettra à disposition des parties un outils de suivi des anomalies en
ligne. C'est cet outil qui fera référence entre la maîtrise d'ouvrage et la maîtrise
d’œuvre, cette dernière s'obligeant à utiliser cet outil pour confirmer les anomalies et
commenter leur correction, jusqu'à signature du bon de livraison finale de l'application
Document SPF1201
12/13
pour mise en production.
15. ÉVOLUTIONS
POUR VERSIONS ULTÉRIEURES
Nous listons ci-dessous des évolutions envisagées dans le cadre des spécifications et
repoussées à des versions ultérieures :
•
multi-utilisateurs avec authentification et gestion de profil agent et
administrateur
•
protection du mot de passe de la liaison jdbc
•
implémentation du web-service SEPAmail directement avec le SMILE
•
chargement des données brutes sans liaison à l'ERP
•
sauvegarde/chargement de la sélection d'un jeu de données
Document SPF1201
13/13

spécifications - documentation SEPAmail

Transcription

Documents pareils

Communiqué - Crédit Agricole Payment Services

Lire la suite - InovenAltenor

LIGNE DIRECTE - Caisse d`Epargne

SPÉCIFICATIONS FONCTIONNELLES EXTENSION SEPAMAIL

Ajouter des dispositifs: fiche

Personnaliser votre page d`accueil - Espace client

correction

La fabrication - GIE SESAM

Dj Kefran

Peinture 2K-époxy «antistatique»

VITA PLUS - Proquimia

SEPAmail, la missive, spécifications fonctionnelles