Private business talk:Guide Entreprises et Éditeurs RUBIS

Question de nommage

Page 5, concernant les Request Type de SEPAMAIL (que ce soit pour EBICS ou SWIFTNet), nous ne comprenons pas bien la construction retenue :

pain.xxx.sepamail_mes_dd_mir pour une requête de mandat GEMME pain xxx.sepamail_mes_pa_ar pour une demande de règlement RUBIS

A quoi sert le ‘mes’ ? cela veut dire message, je suppose. Est-ce utile ? ‘pa_ar’ veut dire payment activation request ? Comment nomme t on le payment activation report ?

Est-ce que pain.xxx.sepamail_009_001_01.miq et pain.xxx.sepamail_013_001_01.piq par exemple ne seraient pas mieux , à condition de fixer que ‘miq’ est mandateinitiationrequest et ‘piq’ paymentinitiationrequest et même si ces natures ne sont effectivement pas définies par le CFONB? Dans tous les cas, merci de préciser le Request Type pour chaque type de fichier.

Lise.mahaut 27 février 2012 à 11:25 (CET)

La question est posée, à mon avis, elle est à traiter en GT études et fonctionnel

Je mets en lien une page d'annexe sur le sujet et met un code en trois lettres pour distinguer le report du request

Manfred S. OLM, cabinet deciBI 6 mars 2012 à 15:32 (CET)

caractères latins

page 63 (Missive : Implementation Guideline).

La limitation au jeu de caractères latin est source de soucis. Nous serons confrontés au fait que des clients particuliers vont accentuer leur texte, que des clients créanciers transmettront un contenu avec des caractères nationaux. Les IG de l’EPC disent que les caractères nationaux doivent être autorisés (« bank and their customers must be allowed to use ») .

Lise.mahaut 27 février 2012 à 11:28 (CET)

D'un autre côté, si la banque à qui nous écrivons refuse le message parce qu'il n'est pas conforme aux règles de l'EPC, nous avons un souci aussi ... Je suis en cours de réflexion sur ce sujet, sans doute pour imposer le jeu "Latin" sauf dans certains champs (nom, prénom, adresse, titre ...). Et encore, peut-être avec un transcodage quelque part ?

Olivier.jousselin 5 mars 2012 à 12:01 (CET)

Après discussion, je préfère maintenir la contrainte "officielle SEPA" pour l'instant : seul le jeu de caractères Latin est accepté. Par la suite, on pourra envisager de relâcher la contrainte sur certains champs, mais il faudra définir clairement ce qu'il en advient dans les différents cas (affichage sur un GAB, reprise de la valeur vers un message standard ISO 20022 ...)

Olivier.jousselin 5 mars 2012 à 16:34 (CET)

Back again to connexion Ebics

Pour faire suite aux remarques de Lise du tout début : je fais l’hypothèse que

- « mes » est utile pour bien montrer qu’on n’est pas en transaction financière (« it does not move money » comme dirait l’autre)

- dd et pa identifient l’écosystème (ou famille), -Gemme et rubis pour faire simple

- la suite est le message (exemple, dans la famille pa, => ar étant l’un ou l’autre de request ou report) ; si je me souviens, certains ne le distinguent pas sauf le sens, à vérifier ! Un autre code identifierait la problématique enrôlement

SIEMONS Thea (Thea.SIEMONS@credit-agricole-sa.fr)

les renvois

Certains liens ne fonctionnent pas : [6] et [8] depuis mon poste ; SIEMONS Thea (Thea.SIEMONS@credit-agricole-sa.fr)

Le lien 6 est en cours de développement

Le lien 8 a été corrigé

Manfred S. OLM, cabinet deciBI 1 mars 2012 à 09:41 (CET)

§ Format XML p6

"Chacun des messages doit être inclus dans une missive unique". J'ai un doute, est-ce bien tout ce que l'on veut dire ou il faut un petit cran de plus (bijection missive / message ?)

SIEMONS Thea (Thea.SIEMONS@credit-agricole-sa.fr)

je pense que la rédaction actuelle est correcte -- on pourrait éventuellement s'interroger sur l'utilité du mot "unique". Un message est forcément inclus dans une missive. Aujourd'hui, on a effectivement une bijection, une missive ne contenant qu'un message. Ceci pourrait toutefois changer un de ces jours, donc je préfère qu'on sépare bien la nécessité d'encapsulation d'un message pour son transport dans SEPAmail, qui est protocolaire et ne changera pas, du nombre de messages contenus dans une missive.

Olivier.jousselin 5 mars 2012 à 12:01 (CET)

Changement effectué, j'enlève le mot "unique"

Manfred S. OLM, cabinet deciBI 6 mars 2012 à 15:29 (CET)

Deux documents distinct ?

Il serait peut-être plus pertinent de faire deux documents distincts, l'un pour GEMME, l'autre pour RUBIS. Le mélange est source de troubles et d’interrogations inutiles de la part des créanciers pour lesquels le seul service SEPAMail est le service RUBIS.

pas de souci à séparer le document en deux dans le wiki et dans sa version pdf, décision à valider en GT

titre à trouver pour chacun des deux documents

Manfred S. OLM, cabinet deciBI 6 mars 2012 à 15:45 (CET)

____ Des inconvénients, des avantages aussi. Je ne trouve pas la réponse si évidente SIEMONS Thea (Thea.SIEMONS@credit-agricole-sa.fr)

demande de paiement, expression à proscrire

L'expression 'Demande de paiement' est employée alors que nous avions convenu de parler de 'Demande de règlement' ou bien dans d autres documents il est fait état de DRE (Demande de règlement électronique). Est-ce que l'on peut convenir d’un terme de façon définitive.

changement effectué, plus de mention au mot paiement

Manfred S. OLM, cabinet deciBI 6 mars 2012 à 15:23 (CET)

les cas d'erreur

Aucun information concernant les cas d'erreur, les cas limites, les cas où ça ne se passe pas comme prévu (le créancier posera ces questions): missives mal formatées, formats des fichiers non respectés, fichiers corrompus, données non autorisées/inconnues de la norme, défaillance technique créancier, défaillance technique banque, missives nominales et d'acquittement ne se réconcilient pas, etc. Comment ces cas "d'erreur" sont techniquement gérés?

deux types de cas d'erreur

* ceux partageables par tous

* ceux différant selon l'implémentation de chacun des adhérents SEPAmail

pour le premier cas :

* missive mal formatée : acquittement SEPAmail selon la norme et le même format que celui paramétré en retour (pdf ou xml)

* données non autorisées/non reconnues dans la norme : acquittement SEPAmail comme premier point

pour le second cas :

* format des fichiers non respecté, selon la norme EBICS ou SwiftNet, pas de connecteur fichier SEPAmail prévu pour le moment

* gestion du workflow missive nominale et acquittement, la SMIRK missive donne les règles, on peut préciser ces règles mais cela fera double emploi. Peut-on réagir sur le SMIRK pour les règles qui ne sont pas claires ?

donc pas de nom de fichier sur cette prise

* fichiers corrompus, selon la norme EBICS ou SwiftNet

* défaillance technique créancier, à préciser

* défaillance technique banque, à préciser selon un protocole d'escalade qui ne regarde que l'espace compétitif ?

on peut compléter les exemples avec d'autres flux ou un flux questions/réponses complets (même si la réponse n'est pas forcément utile pour tous les créanciers) et analyser deux trois cas d'erreur courant.

Qui s'en charge ?

Manfred S. OLM, cabinet deciBI 6 mars 2012 à 15:55 (CET)

règles de gestion

Le créancier un peu pointilleux pourra également demander les règles de gestion sur chacune des données (en fait, c'est qu'on aimerait avoir aussi pour la recette), au-delà des critères obligatoires, facultatifs, que contrôle-t-on (sur les dates, les comptes, les noms, les doublons, contrôles de cohérence, etc...)

la référence au fichier XML donne les formats avec les motifs/types à vérifier sur chacun des champs

quand une règle s'applique à plusieurs champs, alors la règle se trouve dans les IG si elle fait partie des règles actuellement pointée par l'interbancaire

concernant les doublons, le sujet est vaste et non véritablement ouvert à la discussion pour le moment. C'est peut-être l'occasion de l'ouvrir pour le traiter.

une missive reçue en double (identique au numéro d'ordre prêt) fait l'objet à la deuxième réception d'un acquittement spécifique. Dans le cas d'un numéro d'ordre différent, la règle qui peut-être vérifiée est celle-ci la missive est renvoyée avec un ordre incrémenté de 1 ; l'émetteur s'interdit de changer le contenu de la missive renvoyée, à l'exception du numéro d'ordre (référence SMIRK MIS1101) et toute missive nominale reçue (quelque soit son ordre) doit être acquittée. parce que L'acquittement vise à informer l'émetteur de la bonne réception de la missive émise et d'un horodatage de cette réception. (référence SMIRK MIS1101)

un message reçu en double dans deux missives nominale différentes (identifiant différent) a forcément un identifiant de message différent donc ce n'est pas un doublon. Il doit être traité comme tel deux fois. Il n'y a pas de message d'annulation ou de suppression ou de modification et il faut donc travailler ce sujet.

Manfred S. OLM, cabinet deciBI 6 mars 2012 à 16:16 (CET)

Retour Consolidé BNPP sur le document en lui-même

Page 3 : Comment se connecter à SepaMail (Remarque de forme) : L’emploi de tournures comme « Vos interlocuteurs », « Votre Banque » ne semble pas approprié, il conviendrait de les remplacer par « les interlocuteurs du créancier », « la banque du créancier ».

l'entreprise peut être aussi du coté débiteur

on peut donc imaginer les interlocuteurs de l'entreprise et la banque de l'entreprise ???

Manfred S. OLM, cabinet deciBI 6 mars 2012 à 16:26 (CET)

Page 7 : Les services : Est-ce que cette description est utile ici ? Déjà abordée Page 2 Pour cette première partie en général trop de termes non définis avant leur utilisation (Création d un lexique ??)

pour le Lexique, voyez-vous une annexe reprenant cette page Glossaire et/ou celle-là Catégorie:Lexique. Je vous rappelle que c'est le wiki qui fera référence en dernier lieu également pour les entreprises et leurs éditeurs

Manfred S. OLM, cabinet deciBI 6 mars 2012 à 16:29 (CET)

Page 9 : Globalement on ne comprend pas bien le but de l’entreprise à implémenter SEPAMail (peut être définir de façon plus précise la situation initiale et la situation cible) Pourquoi commencer par un exemple sans avoir introduit les services globalement La définition de l’enrôlement n est pas précisée par exemple Les différences de couleur sur les flèches ne sont pas expliquées. Il faudrait peut être commencer par un exemple plus simple et ensuite un exemple avec fichier PDF. Pourquoi parler de document au lieu de facture ou quittance ?? (Cela gène la compréhension), si c’est un exemple autant être précis. Remplacer créancier FFFF et société éditrice XXXXX par des pseudos « L’entreprise FFFF désire conserver….. » Quelles sont les conséquences pour la mise en place de la solution ?

Page 10 : DDPP ?? Terme non défini Définir Payment activation Request (au moins souligner que cela correspond à la flèche 3 du diagramme précédent)

« des informations supplémentaires utiles pour la gestion… » Lesquelles, exemple ?

« Le flux XML SepaMail est 1. Généré 2. Vérifié 3. envoyé»

A quoi cela sert d’écrire ça ? Qui réalise ces opérations ? Donner des détails.

Merci de proposer une formulation qui vous convient pour cet exemple.

Manfred S. OLM, cabinet deciBI 6 mars 2012 à 16:34 (CET)

Cela fait la grosse différence avec le format pdf...

Théa Siémons

Page 11 : Point 2. Message direct.debit Mandate initiation request ????? (Erreur ?) Les fichiers sont transportés via EBIC cela aurait du faire partie de l'introduction de l'exemple.

Page 11 : Private business : Service RUBIS Débiteur A quoi cela sert de mettre ce paragraphe ? Celui-ci n est pas explicité ? Il n est pas équivalent à celui donné en Page 9 Source de confusion. Page 16 : Le terme écosystème n est pas défini Le message de demande de paiement : PaymentActivation Request

Proposition de reformulation : Ce message est envoyé par le créancier (émetteur) pour faire une demande de règlement au débiteur. Celui ci est véhiculé de façon sécurisée jusqu’au débiteur par le système SEPAMAIL. Le débiteur a ensuite la possibilité de répondre ou non la demande du créancier. Dans le cas ou le débiteur décide de répondre, un message est renvoyé au débiteur (PaymentActivationReport, décrit après).

Si la demande de règlement est acceptée par le débiteur, le système SEPAMail génère automatiquement un message pain.001 de demande d’exécution du virement correspondant à la demande du créancier.

Le message de réponse à demande de paiement : PaymentActivation Report

On ne comprend pas bien le rubrique EnrollReply : il faut faudrait peut être le remettre en perspectives dans l'ensemble du protocole d’enrôlement.

Bruno.joanides 5 mars 2012 à 18:51 (CET)

Glossaire

Un consensus sur la nécessité d'un (petit) glossaire, me semble-t-il Toutefois, écosystème est défini page 3. Mais ça fera pas de mal d ele retrouver en glossaire. J'ai cherché également DDPP.. SIEMONS Thea (Thea.SIEMONS@credit-agricole-sa.fr)

Contenu des fichiers

les fichiers EBICS (resp.SWIFTNET) dans leur contenu doivent-ils :

• Respecter le format fichier séquencé décrit dans l'IG http://documentation.sepamail.eu/wiki/Standards:IG_file.sequence ?
• contenir des paymentActivationRequest (resp. paymentActivationReport) au format message (sans missive) ce que semble évoquer la page "service RUBIS créancier" (cf. http://documentation.sepamail.eu/wiki/Private_business:Service_RUBIS_cr%C3%A9ancier)
• contenir des paymentActivationRequest (resp. paymentActivationReport) au format messages encapsulés dans des missives à l'équivalent des échanges unitaires interbancaires ?

Lionel.chemla (discussion) 17 juillet 2012 à 15:29 (CEST)

Tout est possible. Dans la mesure où EBICS et autres ne sont que des canaux d'échange (voire des pré-canaux), ils sont indépendants du contenu. Si les deux correspondants "parlent" SEPAmail, le fichier EBICS devra contenir une enveloppe S/MIME, contenant une missive, contenant un message. Sinon (hors interbancaire bien sûr), ils peuvent retenir l'une ou l'autre de ces solutions, ou encore une autre de leur choix. La solution 2 est sans doute la plus simple à mettre en oeuvre, d'où sa présence dans la page en question.

Précisons que le format "fichier séquencé" n'est actuellement utilisé nulle part, et ne le sera peut-être jamais. Je viens d'ailleurs de passer cette page en état "discussion", pour éviter toute ambiguïté.

Olivier.jousselin (discussion) 18 juillet 2012 à 15:34 (CEST)