Standards:IG AigueMarine RecurrentOperationReport

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