View source for SMIRK REF1201, le référentiel icqx@scheme

__NOTOC__
<translate>
<!--T:1-->
{{Norme 1206}}
[[Catégorie:SMIRK]]


== Principes généraux == <!--T:2-->

<!--T:3-->
Le référentiel des ICQX (icqx@scheme) contient tous les créanciers personnes morales inscrits auprès de SEPAmail, qu'ils soient «&nbsp;visibles&nbsp;» par les débiteurs ou non.


<!--T:4-->
Comme son nom l'indique, il est maintenu par le Scheme manager, ou par le QXOO (QX Operational Office).


<!--T:5-->
Il est mis à jour à l'initiative de la banque du créancier, sur demande du créancier, que ce soit lors de la création de l'enregistrement (correspondant donc à une demande d'ICQX) ou lors d'un changement de contenu. Dans tous les cas, cette mise à jour passe par l'adhérent SEPAmail dont dépend le créancier, et est faite sous sa responsabilité.


<!--T:6-->
Seuls les créanciers personnes morales peuvent être inscrits dans ce référentiel. Les personnes physiques ne sont inscrites dans aucun référentiel.


<!--T:7-->
L'ICQX sert d'index dans ce référentiel. Il est unique pour un créancier donné, quels que soient les changements de situation qui puissent l'affecter (changement d'adresse, de nom, de banque ...). Le seul changement pouvant intervenir dans cet ICQX concerne le 7ème caractère (position 3 du ''business code''), qui est laissé à la libre disposition du créancier. Dans le référentiel, ce caractère sera systématiquement forcé à 'Z'. En revanche, d'autres valeurs pourront être utilisées pour la recherche.


<!--T:8-->
Lorsqu'un créancier est présent dans le référentiel, il peut «&nbsp;s'inscrire&nbsp;» à un ou plusieurs «&nbsp;services&nbsp;». Ces services correspondent à tout ou partie d'une application SEPAmail, et seront par exemple :

<!--T:9-->
* RUBIS inscription 
* RUBIS émission
* RUBIS réception
* DIAMOND émission
* GEMME émission
* GEMME réception

== Contenu du référentiel == <!--T:10-->

<!--T:11-->
Le référentiel contient tous les éléments relatifs à un créancier&nbsp;: éléments d'identification, éléments bancaires, éléments de communication avec les débiteurs et bien sûr éléments relatifs au référentiel lui-même.

<!--T:12-->
Voici la liste détaillée de ces éléments&nbsp;:

=== 1. Index === <!--T:13-->

<!--T:14-->
* ICQX (avec le 3ème caractère du ''business code'' mis à 'Z')

=== 2. Éléments de désignation === <!--T:15-->

<!--T:16-->
* Nom (PartyName) ''[chaîne de 1 à 140 caractères]''
* Nom courant (DisplayName) ''[chaîne de 1 à 140 caractères]''
* Logo ''[image]''
* Vignette (thumbnail) ''[image]''
* Adresse postale ''[format ISO 20022]''

=== 3. Éléments d'identification <ref>L'adresse internet du créancier n'est pas retenue ici, pour des raisons de reroutage et de mise à jour</ref> === <!--T:17-->
''[pour tous : type = chaîne (1 à 16 car) parmi une énumération ("SIRET", "SIREN" ... "Other"), valeur = chaîne de 1 à 35 caractères pouvant ou non avoir un format figé]''

<!--T:18-->
* SIRET
* SIREN
* TVA intracommunautaire
* autre (pour l'administration)
* forme juridique
* activité

=== 4. Éléments bancaires === <!--T:19-->

<!--T:20-->
* BIC (''correspond au BIC de dernière mise à jour'')

=== 5. Éléments liés au référentiel === <!--T:21-->

<!--T:22-->
* Dates de validité (début – fin, correspondant à la validité de l'ICQX) ''[2 dates format ISO]''
* Date de dernière mise à jour ''[format ISO]''
* Compte de test (booléen) (toujours égal à ''false'' dans l'usage actuel)

=== 6. Éléments liés à un service (0 à N blocs possibles) === <!--T:23-->

<!--T:24-->
* Nom du service («RUBIS &nbsp;inscription » par exemple) ''[valeur dans une énumération]''
* Activité vis-à-vis de ce service (booléen)
* Portée (locale ou globale) ''["local" ou "global"]''
* QXBAN associé(s)
* Communication avec débiteurs (0 à 3 identifiants possibles)
** Nom de l'identifiant du débiteur ''[chaîne de 1 à 70 caractères]''
** Où et comment le trouver (texte et/ou image) ''[chaîne de 1 à 140 caractères + image]''


<!--T:25-->
Tous les éléments des blocs 1, 2, 4 et 5 sont obligatoires. Concernant ceux d'identification (bloc 3), au moins un des quatre premiers éléments doit être fourni, et plusieurs peuvent être présents (sauf SIRET et SIREN, qui sont exclusifs l'un de l'autre).


<!--T:26-->
L'ensemble des éléments des blocs 1 à 5 constituent une structure dénommée '''ICQXCard''', qui est transportée intégralement dans certains messages de gestion du référentiel, décrits plus loin dans ce document. Cette structure n'est utilisée nulle part ailleurs dans SEPAmail.


<!--T:27-->
Les éléments liés à un service (bloc 6) constituent une '''ServiceCard'''. Chaque créancier enregistré dans le référentiel peut disposer de 0, une ou plusieurs ServiceCards.

<!--T:28-->
La portée figurant dans une ServiceCard est à interpréter ainsi :
* ''local'' : le pays du créancier (ou du QXOO local), correspondant au code pays figurant dans l'ICQX
* ''global'' : tous les pays

=== Exemple === <!--T:29-->

<!--T:30-->
Un créancier qui envoie et reçoit des messages RUBIS, et qui accepte les messages d'inscription à ce service, aura un enregistrement comportant :
* les blocs 1, 2, 4 et 5 complets
* suffisamment d'éléments dans le bloc 3 pour que sa banque ait pu valider son identité
* 3 ServiceCards (bloc 6), avec le champ "actif" à true dans les trois, et un ou plusieurs QXBAN dans chaque ServiceCard <ref>le même QXBAN peut être ou non utilisé pour plusieurs services. Par ailleurs, un service peut comporter plusieurs QXBAN &ndash; par exemple, pour le service RUBIS émission, il est possible qu'un créancier remette ses demandes de règlement sur plusieurs banques</ref> :
** une pour le service "RUBIS inscription", comportant au moins 1 et au plus 3 blocs "communication avec le débiteur"
** une pour le service "RUBIS émission", sans blocs "communication avec le débiteur"
** une pour le service "RUBIS réception", sans blocs "communication avec le débiteur"


== Accès du client final aux données du référentiel == <!--T:31-->

<!--T:32-->
Toute banque adhérente à SEPAmail est tenue de donner accès aux données des blocs 1 à 3 à l'ensemble de ses clients SEPAmail.

<!--T:33-->
Pour l'utilisation du service "RUBIS inscription", elles devront être complétées par les éléments "communication avec le débiteur" (contenues dans la ServiceCard, bloc 6) correspondantes.

<!--T:34-->
L'affichage et les modes de recherche ne sont pas spécifiés par SEPAmail.

== Utilisation du référentiel == <!--T:35-->

<!--T:36-->
À partir du moment où un créancier est inscrit dans ce référentiel, il se contente d'envoyer, dans les messages qu'il émet, son ICQX. La banque du débiteur peut alors consulter le référentiel, ou un miroir local qu'elle maintient à jour, pour obtenir toutes les informations nécessaires sur ce créancier et les présenter aux débiteurs.


== Processus et messages autour du référentiel == <!--T:37-->

<!--T:38-->
Tous les messages relatifs à ce réferentiel appartiennent à l'écosystème ''scheme''. Sauf mention contraire, l'adresse destinataire des messages à destination du Scheme sera ICQX@scheme.sepamail.eu ou ICQX@fr.scheme.sepamail.eu.

<!--T:39-->
Les BIC correspondant à cette adresse <ref>Ce sont en fait des pseudo-BIC, aucun enregistrement auprès de SWIFT n'est réalisé pour eux </ref> sont :
* pour le QXOO, '''SKEMQX..XXX''', où '''..''' doivent être remplacés par le code du pays
* pour le Scheme Manager, '''SKEMQXQXXXX'''

=== Création d'un créancier === <!--T:40-->

<!--T:41-->
Le créancier communique les informations de son ICQXCard à sa banque, sauf bien sûr l'ICQX <ref name="ftn1">ceci peut ou non se faire par le biais d'un message CreditorCreationRequest, selon le mode de communication entre la banque et son client.</ref>.


<!--T:42-->
La banque réalise les tests de vérification d'identité du créancier, qui sont de son entière responsabilité.

<!--T:43-->
* S'ils sont négatifs, elle lui répond par un rapport négatif et le processus est terminé.
* S'ils sont positifs, elle envoie cette ICQXCard au Scheme par le biais d'un message CreditorCreationRequest.
* Le Scheme attribue un ICQX au créancier et répond à la banque par un CreditorCreationReport positif<ref name="ftn2">sauf des éventuels cas d'erreur à définir dans une version ultérieure de la norme (créancier existant déjà&nbsp;?)</ref> contenant cet ICQX. Ce créancier n'a aucun service associé lors de sa création.
* La banque envoie alors au créancier un rapport positif, contenant au minimum son ICQX.

<!--T:44-->
Le message CreditorCreationRequest peut donc être acheminé
* par le créancier à sa banque s'ils utilisent les échanges SEPAmail
* par la banque du créancier au Scheme


<!--T:45-->
[[Image:ICQX-obtention.png|Obtention d'un ICQX]]

=== Rapport de création d'un créancier === <!--T:46-->

<!--T:47-->
Ce rapport est acheminé par un message CreditorCreationReport, qui peut être positif ou négatif. S'il est positif, ce message contient une ICQXCard complète.


<!--T:48-->
S'il est négatif, le créancier n'est pas créé dans le référentiel du Scheme, et la procédure doit reprendre au début, après correction des anomalies bien sûr.


<!--T:49-->
Le message CreditorCreationReport peut donc être acheminé
* par le Scheme à la banque du créancier
* par la banque du créancier au créancier, s'ils utilisent les échanges SEPAmail

=== Mise à jour d'un créancier === <!--T:50-->

<!--T:51-->
Le processus de mise à jour d'un créancier est très similaire à celui de création&nbsp;: le créancier transmet les informations de mise à jour à sa banque – en cas de changement, à sa nouvelle banque.


<!--T:52-->
La banque réalise les tests de vérification d'identité du créancier<ref name="ftn3">Ces tests sont les mêmes que lors d'une création, ils ne doivent pas être limités aux éléments mis à jour. La banque engage sa responsabilité sur l'ensemble des éléments fournis.</ref>.

<!--T:53-->
* S'ils sont négatifs, elle lui répond par un rapport négatif et le processus est terminé.
* S'ils sont positifs, elle envoie l'ICQXCard au Scheme par le biais d'un message CreditorUpdateRequest.
* Le Scheme met à jour le référentiel et répond à la banque par un CreditorUpdateReport positif<ref name="ftn4">sauf des éventuels cas d'erreur à définir</ref>.
* La banque répond alors au créancier par un rapport positif, contenant au moins son ICQX.

<!--T:54-->
Le message CreditorUpdateRequest peut donc être acheminé
* par le créancier à sa banque s'ils utilisent des échanges SEPAmail
* par la banque du créancier au Scheme

=== Rapport de mise à jour d'un créancier === <!--T:55-->

<!--T:56-->
Ce rapport est acheminé par un message CreditorUpdateReport, qui peut être positif ou négatif. De même que pour le rapport de création d'un ICQX, s'il est positif, ce message contient une ICQXCard complète.


<!--T:57-->
Si le rapport est négatif, l'enregistrement du créancier dans le référentiel et l'ICQXCard sont inchangés.


<!--T:58-->
Le message CreditorUpdateReport peut donc être acheminé
* par le Scheme à la banque du créancier
* par sa banque au créancier, s'ils utilisent des échanges SEPAmail

=== Diffusion d'information sur un créancier === <!--T:59-->

<!--T:60-->
Lorsqu'un créancier est prêt à émettre ou à recevoir les messages d'un service particulier, il est de la responsabilité de sa banque de transmettre cette information à l'ensemble du réseau SEPAmail.


<!--T:61-->
Elle se fait par le biais d'un message CreditorActivationAdvise, qui contient l'ICQX du créancier et la ServiceCard concernée. Le même message permet aussi de suspendre l'activité d'un créancier sur un service spécifique.


<!--T:62-->
Le message est adressé par la banque du créancier à toutes les autres banques et au Scheme, qui met à jour son référentiel à réception.

=== Demande de consultation du référentiel === <!--T:63-->

<!--T:64-->
Lorsqu'une banque reçoit un message, typiquement de l'écosystème Rubis, contenant un ICQX, elle peut consulter le Scheme pour obtenir les informations relatives au créancier détenteur de cet identifiant.


<!--T:65-->
La consultation du référentiel sert également à la banque du débiteur pour mettre à disposition le service d'inscription RUBIS.


<!--T:66-->
Ceci se fait par un message CreditorInformationRequest, mentionnant l'ICQX du créancier<ref name="ftn5">on pourrait ajouter la date de la dernière mise à jour connue par la banque, afin de limiter le volume du message de retour (un simple «&nbsp;rien de neuf&nbsp;» suffirait alors). Est-ce utile&nbsp;? À définir dans une version ultérieure de la norme, en conjonction avec les processus de synchronisation/miroir entre Scheme et banques</ref>. L'ICQX fourni peut contenir un caractère quelconque en position 7, il sera systématiquement forcé à 'Z' par le Scheme avant consultation du référentiel.


<!--T:67-->
[[Image:ICQXCARD-obtention.png]]

=== Réponse à consultation du référentiel === <!--T:68-->

<!--T:69-->
En réponse à un message CreditorInformationRequest, le Scheme répond par un message CreditorInformationReport, contenant l'ICQXCard complète du créancier, et l'ensemble des ServiceCards relatives à ce créancier.

=== Synchronisation du référentiel entre banques === <!--T:70-->

<!--T:71-->
Pour limiter les messages de consultation, il serait cohérent que chaque banque dispose d'un miroir local de son contenu. Les conditions exactes de constitution et de mise à jour de ce miroir restent à définir.

<!--T:72-->
[[Image:ICQX-service-inscription.png]]

== Récapitulatif des messages créés == <!--T:73-->

=== Messages Scheme === <!--T:74-->
{| class="wikitable" style="width:70%"
|-
! align="center" | Nom du message
! align="center" | Utilisation
! align="center" | acteurs
|-
| align="left" style="width:30%" | CreditorCreationRequest
| align="left" style="width:30%" rowspan="2" | Création d'un créancier
| align="left" style="width:40 %" rowspan="2" | Banque créancier &harr; Scheme<br>Créancier &harr; Banque créancier
|-
| align="left" style="width:30%" | CreditorCreationReport 
|-
| align="left" style="width:30%" | CreditorUpdateRequest
| align="left" style="width:30%" rowspan="2" | Mise à jour d'un créancier
| align="left" style="width:40 %" rowspan="2" | Banque créancier &harr; Scheme<br>Créancier &harr; Banque créancier
|-
| align="left" style="width:30%" | CreditorUpdateReport 
|-
| align="left" style="width:30%" | CreditorInformationRequest
| align="left" style="width:30%" rowspan="2" | Consultation du référentiel
| align="left" style="width:40 %" rowspan="2" | Banques &harr; Scheme
|-
| align="left" style="width:30%" | CreditorInformationReport 
|}

<!--T:75-->
Des messages supplémentaires pourront être créés, notamment ceux gérant la réplication du référentiel dans les banques.

=== Messages interbancaires === <!--T:76-->

<!--T:77-->
{| class="wikitable" style="width:70%"
|-
! align="center" | Nom du message
! align="center" | Utilisation
! align="center" | acteurs
|-
| align="left" style="width:30%" | CreditorActivationAdvise
| align="left" style="width:30%" | Diffusion d'un service associé à un créancier
| align="left" style="width:40 %" | Banque créancier &rarr; autres banques<br>Banque créancier &rarr; Scheme
|-
| align="left" style="width:30%" | PaymentActivationEnroll
| align="left" style="width:30%" | Inscription d'un débiteur (service RUBIS inscription)
| align="left" style="width:40 %" | Banque débiteur &rarr; banque créancier
|}

== Phase transitoire == <!--T:78-->

<!--T:79-->
Pour accélérer la mise en place de ce système, sans la rendre dépendante de l'implémentation effective du référentiel et de l'écosystème correspondant, on peut à court terme travailler ainsi&nbsp;:

<!--T:80-->
* le référentiel est remplacé par une feuille de calcul maintenue par le Scheme
* la feuille est envoyée par mail aux adhérents, une fois par jour, dès lors qu'il existe au moins une mise à jour
* les messages d'inscription et de modification, ainsi que leurs rapports, sont remplacés par des formulaires papier. Ceux-ci seront supprimés au fur et à mesure de la disponibilité des messages SEPAmail correspondants.

<!--T:81-->
----
<references/>
</translate>
<languagues />