Standards:IG AigueMarine RecurrentOperationRequest
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
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.Introduction
Ce document décrit les directives d’implémentation du message RecurrentOperationRequest de l’application Aigue-Marine de SEPAmail
Fonctionnalités
Portée
Le message SEPAmail RecurrentOperationRequest est envoyé par un opérateur de mobilité à la banque quittée pour obtenir la liste des opérations récurrentes sur une période donnée.
Remarque : ce message peut aussi être utilisé par le bénéficiaire d’une succession auprès de la banque du défunt.
Usage
Le message SEPAmail RecurrentOperationRequest est envoyé sur mandat du migrant pour demander la liste des opérations récurrentes de virement et de prélèvement.
Ce message peut être échangé entre deux adhérents SEPAmail ou entre un adhérent SEPAmail et son client.
Il contient la définition des parties en jeu pour la demande (le migrant, la banque quittée, les éventuels relais de l’information).
Un mandat, une preuve de mandat et divers justificatifs peuvent être joints au message.
Contenu
Le message RecurrentOperationRequest est composé de deux blocs d’information :
- À une demande de rapport au format acmt.060 de l’ISO, version 002 ou version 003.
- B une partie non ISO pour insérer notamment des justificatifs
Structure
Racine du message
| RecurrentOperationRequest |
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.
| + sepamail_message_mobility_recurrent_operation_request_001 | Première version de la structure |
Parties ISO et Non-ISO
| A | ++ OperationRequest | un élément acmt.060, voir ci-dessous | ||
| B | ++ Complement | une partie non ISO, comme décrit plus loin dans le document |
Partie ISO : Modification
Cet élément doit contenir l’une des versions courantes de l’acmt.060.
| A1 | + AccountReportingRequestV02 | un élément acmt.060 en version 002 | ||
| A2 | + AccountReportingRequestV03 | un élément acmt.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.
| B1 | + Document | un ou plusieurs documents de l’espace de nom SEPAmail. |
Règles
Nous avons les règles suivantes :
- [R1] l’élément MsgSndr DOIT être utilisé pour désigner l’opérateur de mobilité
- [R2] L’élément Complement (B) NE DOIT PAS être utilisé s’il est vide.
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.
Données métier
| Nom Migrant | M. Paul PECHE |
| Banque quittée | TESTFRBQUI |
| Opérateur de mobilité | MOBILITY OPERATOR |
| BIC opérateur de mobilité | TESTFROPMOB |
| ancien IBAN migrant | FR91TESTFRBQUI00000000000000PECHE |
Instance XML
Le fichier correspondant est acessible ici : Fichier:ExempleRecOpReq.xml