Standards:IG AigueMarine RecurrentOperationReport

From documentation SEPAmail
Revision as of 09:50, 19 May 2015 by Olivier.jousselin (talk | contribs) (Changement couleur bandeau)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Cette page est à l'état de discussion.

Elle n'a donc aucune valeur normative, et pourrait même disparaître du périmètre de SEPAmail.

Si vous voulez contribuer, utilisez la page de discussion SVP. Consultez également les autres pages en discussion.
  • These implementation rules shall be applied in accordance with ISO20022 and SEPA own implementation rules. Thus, unless explicitly specified, data contained within a field or XML structure of a SEPAmail message must comply with the constraints related to the equivalent field or XML structure in ISO20022 or SEPA messages.
  • for an explanation of the color coding used in the tables below, see this page
  • for general rules applying to all fields, see this page
  • for business rules directing these IG, see this page
Ces IG sont hors périmètre actuel de validation (mai 2015)

Ils ont été publiés pour que tous les éléments fournis par Isilis soient présents, mais les messages définitifs seront fournis par le CFONB.

Vous pouvez néanmoins les commenter dans la page "Discussion" si vous le souhaitez.
Auteur : Isilis, avec la collaboration de Manfred Olm

Introduction

Ce document décrit les directives d’implémentation du message RecurrentOperationReport de l’application Aigue-Marine de SEPAmail

Fonctionnalités

Portée

Le message SEPAmail RecurrentOperationReport est envoyé par la banque quittée d’un migrant à l’opérateur de mobilité qui lui en a fait la demande.

Usage

Le message SEPAmail RecurrentOperationReport est envoyé en réponse à un message RecurrentOperationRequest.

Ce message peut être échangé entre deux adhérents SEPAmail ou entre un adhérent SEPAmail et son client.

Il contient la demande initiale ainsi que la réponse à chacune des requêtes contenues dans cette demande.

Divers justificatifs peuvent être joints au message.

Contenu

Le message RecurrentOperationReport est composé de deux blocs d’information :

  • A une demande de rapport au format camt.060 de l’ISO, version 002 ou version 003, conforme à la requête ;
  • B une partie non ISO pour insérer la réponse et des justificatifs.

Structure

Racine du message

Mult
Balise XML
Description
[1..1]
RecurrentOperationReport

Niveau d’abstraction interne

Afin de faciliter les évolutions futures du message, un niveau d’abstraction est inséré à la racine de l’élément.


Mult
Balise XML
Description
[1..1]
+ sepamail_message_mobility_recurrent_operation_request_001 Première version de la structure

Parties ISO et Non-ISO

Réf.
Mult
Or
Balise XML
Description
A
[1..1]
++ OperationRequest un élément camt.060, voir ci-dessous
B
[1..1]
++ Complement une partie non ISO, comme décrit plus loin dans le document

Partie ISO : OperationRequest

Cet élément doit contenir l’une des versions courantes du camt.060.


Réf.
Mult
Or
Balise XML
Description
A1
[1..1]
{Or
+ AccountReportingRequestV02 un élément camt.060 en version 002
A2
[1..1]
Or}
+ AccountReportingRequestV03 un élément camt.060 en version 003

Partie Non-ISO : Complement

Cette partie du message ajoute des informations utilisées par l’application SEPAmail/Aigue-Marine afin de fournir aux utilisateurs des fonctionnalités enrichies.


Réf.
Mult
Or
Balise XML
Description
B1
[1..n]
+ ReportResult Une réponse pour chacune des demandes
B1.1
[1..1]
++ RequestIdentification
B1.2
[1..1]
++ Response
B1.3
[0..1]
++ Description
B1.4
[0..1]
++ NumberRecords
B1.5
[0..n]
++ Record
B1.5.1
[1..1]
+++ PaymentArea
B1.5.2
[1..1]
+++ TransactionCode
B1.5.3
[1..1]
+++ InitiatingPartyIdentifiant
B1.5.4
[0..1]
+++ NumberOfTransactions
B1.5.5
[0..1]
+++ DateFrom
B1.5.6
[0..1]
+++ DateTO
B2
[0..n]
+ Document un ou plusieurs documents de l’espace de nom SEPAmail.

Règles

Nous avons les règles suivantes :

  • [R1] Le fragment OperationRequest DOIT être le fragment OperationRequest de la demande d’opérations récurrentes reçue en requête.
  • [R2] Il DOIT y avoir un (et un seul) fragment ReportResult par fragment RptgReq de la demande reçue en requête.
  • [R3] L’élément RequestIdentification DOIT correspondre à un identifiant de fragment RptgReq>Id de la demande.

Exemple métier

Description

Un opérateur de mobilité est mandaté par un migrant pour demander à sa banque quittée les opérations récurrentes de virement sur 2 mois et les opérations récurrentes de prélèvement sur 13 mois. La banque quittée répond positivement, en donnant 3 enregistrements issus de deux systèmes différents (MINOS et SEPA). Elle ne communique aucun justificatif.

Données métier

Balise
Valeur
Nom Migrant M. Paul PECHE
Banque quittée TESTFRBQ
Opérateur de mobilité MOBILITY OPERATOR
BIC opérateur de mobilité TESTFROPMOB
ancien IBAN migrant FR91TESTFRBQUI00000000000000PECHE

Instance XML

Le fichier correspondant est disponible ici : Fichier:ExempleRecOpRep.xml