Direction des ressources humaines, methodes et système D’information




Скачать 118.15 Kb.
НазваниеDirection des ressources humaines, methodes et système D’information
Дата11.10.2012
Размер118.15 Kb.
ТипДокументы





direction deS RESSOURCES HUMAINES, METHODES ET système D’INFORMATION




service INFORMATIQUE :

REPORTING ET GRANDS PROJETS


JL/TR








Paris, le 2 décembre 2011




NOTE TECHNIQUE n° 2010 – 03


Version du 2/12/2011




Objet : Reporting selon le format XML ~ XBRL


La présente note décrit les caractéristiques techniques que les fichiers relatifs aux déclarations réglementaires, télétransmis au SGACP et à la Banque de France devront respecter.


Pour tout renseignement complémentaire, vous pouvez adresser vos questions au Service Informatique : Reporting et Grands Projets – SIRGP à l’adresse électronique suivante : sirgp.gi@acp.banque-france.fr



  1. Présentation et Réception des fichiers


À compter de l’échéance du 30 juin 2010, l’ensemble du reporting dû par les établissements assujettis au titre des réglementations SURFI et au titre des réglementations COREP et FINREP quelle que soit l’échéance, est télétransmis au format XML/XBRL et alimente le nouveau système d’information du Secrétariat général de l'Autorité de contrôle prudentiel.


À cette fin, les fichiers doivent obligatoirement être remis sur le guichet OneGate. Les modalités de connexion et d’attribution de code d’accès à ce portail sont précisées dans une documentation spécifique fournie par la Banque de France et disponible sur le site e-surfi à l’adresse suivante : http://www.banque-france.fr/e-surfi/index.htm


Les canaux de télétransmission via le guichet GFIN restent utilisés :

  • sous le dossier SIGNECB / BAFI_Déclarations :

    • pour les envois relatifs aux documents de type BAFI (corrections sur les arrêtés antérieurs à 06.2010) ;

    • pour les envois relatifs aux documents 8019i et 8597i concernant les arrêtés jusqu’à 09.2010 inclus ;

  • sous le dossier SIGNECB / Droits à signer :

    • pour les envois relatifs aux éventuelles mises à jour dans le cadre des Droits à signer pour les documents BAFI.


S’agissant des envois par les lignes Transpac – protocole PESIT :

  • le profil « CB21 » dédié aux remises BAFI est maintenu selon les mêmes conditions que celles décrites ci-dessus pour le guichet GFIN ;

  • le profil « CB18 » dédié aux remises COREP/FINREP est supprimé à la date de mise en place d’un nouveau profil créé pour les reporting au format XML/XBRL. Les informations liées à ce nouveau profil et plus généralement au canal Transpac sont reprises dans une note technique Banque de France-SDESS ;

  • le profil « CB20 » dédié aux Déclarations de Droits A Signer – DDAS électroniques est maintenu aux mêmes conditions que celles décrites ci-dessus pour le guichet GFIN.


Conformément à l’instruction n° 2007-01 relative à la signature électronique, les fichiers devront être signés et ne comporter qu’une seule signature par fichier.


Le formalisme à respecter en la matière est repris dans une note technique ad-hoc, y compris les modalités de télétransmission via les nouveaux et anciens canaux.



  1. Standard du fichier XML


Les reporting doivent respecter les recommandations XML / XBRL référencées ci-dessous.


À des fins d’identification, un « en-tête » listant des informations sur l’agent financier est obligatoire.

    1. Structure de fichier


Tout fichier transmis doit respecter la recommandation XML 1.0


Un fichier peut contenir 1 à n instances XBRL enveloppées par un en-tête, toutefois les instances incluses dans un même fichier doivent obligatoirement être associées à un type de remise UNIQUE (cf. § 3).


Dans l’hypothèse où un fichier comporte plusieurs instances, celles-ci doivent avoir un identifiant distinct (CIB / arrêté / taxonomie / monnaie).


La structure du fichier et la description de l’en-tête sont décrites dans la note technique OneGate – format fichier. Cette structure est synthétisée dans le schéma suivant :

















La première balise d’un fichier est et est unique pour respecter la norme XML.



  • Norme XML 1.0 avec prologue pour tout fichier signé ou non

  • Un fichier doit avoir comme première balise

  • Un seul type de remise est autorisé au sein d’un fichier

    1. Structure d’en-tête


Chaque instance devra être identifiée par un en-tête dont les informations sont décrites dans la note technique OneGate – format fichier et intégrée dans un élément .



    1. Structure de l’instance




Informations

Descriptif

Valeur

Caractéristiques



Instance XBRL comprenant les références XBRL, y compris celle de la taxonomie, le contexte c'est-à-dire le CIB, l’unité monétaire, la date d’arrêté et les faits valorisés

Instance XBRL

Obligatoire et unique


Chaque instance XBRL devra être conforme aux principes repris dans le cadre ci-dessous.

- Instance mono arrêté, mono CIB, mono taxonomie, mono monnaie d’expression des montants.

- Recommandations XBRL 2.1 et Dimension 1.0 : http://www.xbrl.org/SpecRecommendations/


Les seules valeurs d’unité acceptées pour l'expression des montants sont l'euro ou le franc CFP, définie par la norme ISO 4217 : EUR et XPF. Une instance ne pourra contenir qu’une seule unité monétaire d’expression des montants.


Dans les contextes, les définitions d'entité (élément "identifier") doivent utiliser le code CIB, l'URI correspondant (attribut "scheme") doit être "http://www.banque-france.fr/fr/supervi/supervi_banc/reporting/cib".


En application de ces principes :

  • l’ensemble des tableaux issus d’une seule taxonomie sont donc repris dans une même instance (exemples : FINREP, SURFI_Principale).

Toutefois, un fait présent dans plusieurs tableaux d’une même taxonomie ne doit apparaître qu’une seule fois dans une instance ;

  • les tableaux issus de taxonomies différentes tel que COREP doivent être déclarés dans des instances distinctes. Par contre, les tableaux détaillant le calcul d’une exigence de fonds propres aux titres du risque de crédit et de marché selon les approches retenues (CR_SA CR_IRB MKR_SA…) et se déclinant en différentes classes d’exposition devront être remis dans une seule instance.




  1. Organisation des remises

3.1 Domaines


Pour des besoins de gestion, les déclarations sont regroupées sous 4 types de remises ou domaines différents. La table de correspondance ci-dessous précise pour chaque type de remise le ou les taxonomies référencées :



Domaine – libellé court

Domaine –
libellé long


Taxonomie(s) de référence

SUR

SURFI

« SURFI Principale »,
« Cartographie »,
« SURFI Grands Risques »,
« SURFI Ratio de Couverture Sociétés Crédit Foncier et de Financement à l’habitat »,

« SURFI Engagements Internationaux » (Activité Bancaire Internationale),
« SURFI Devi-Situ » ( Emplois Ressources par Devises et Pays )

BLC

BLANCHIMENT

(SURFI) « Blanchiment » et « Blanchiment EP »

COR

COREP

(COREP) – CA, CRSA….

FIN

FINREP

FINREP



Comme il est précisé au point 2.1, un fichier peut contenir plusieurs instances dès lors que celles-ci relèvent du même domaine. À titre d’exemple, un fichier peut inclure dans une première instance des faits relatifs au tableau SITUATION de la taxonomie « SURFI_Principale » et dans une seconde des faits relatifs au tableau IMPLANTAT de la taxonomie « Cartographie », en revanche il n’est pas possible d’y ajouter une instance comportant des faits relatifs à la taxonomie « Blanchiment ».

3.2 Identification des tableaux


Afin d’identifier les déclarations transmises par les établissements et de les rapprocher des obligations réglementaires de chaque assujetti, il a été créé une notion de « gabarit de remise » pour les informations référencées dans les taxonomies des domaines SURFI et Blanchiment (cf. 3.1).

Cette notion est traduite dans la taxonomie par le concept « indicateur de remise » et chaque élément correspond à un tableau parfois décliné selon certaines valeurs de dimension dite majeure, comme la zone d’activité par exemple.

Chaque télétransmission de données relatives au reporting SURFI, devra donc mentionner le ou les gabarits de remise concernés par l’envoi. Ce principe ne concerne pas les taxonomies COREP et FINREP.

Toute instance relative à l’une des taxonomies :

  • SURFI Principale,

  • SURFI Cartographie,

  • SURFI Grands Risques,

  • SURFI Ratio de Couverture Sociétés Crédit Foncier et de Financement à l’habitat,

  • SURFI Engagements Internationaux - Activité Bancaire Internationale,

  • SURFI Devi-Situ - Emplois Ressources par Devises et Pays,

  • SURFI Blanchiment

  • SURFI Blanchiment_EP

devra comporter au moins un concept « indicateur de remise ».


La liste exhaustive de ces indicateurs de remise est disponible sur le site e-surfi (http://www.banque-france.fr/e-surfi/index.htm) à la rubrique taxonomie SURFI sous le lien « tableaux colorisés et dimensions pour conception taxonomie » (fichier « Liste_gabarits_de_remise»).

3.3 Remises partielles


En raison de la structure des taxonomies et des délais de remise variables selon les tableaux, le type d’établissement ou encore l’arrêté, les remises partielles sont autorisées. Cette modalité s’applique à tout type de remise visé au point 3.1.


Pour une même remise (CIB, arrêté, taxonomie et monnaie identiques), les différentes instances reçues, dès lors qu’elles ont satisfait les contrôles de validité (cf. point 5), sont agrégées.


Lors de l'agrégation d'une nouvelle instance, un nouveau fait remplace un fait déjà reçu (même CIB, arrêté, taxonomie, monnaie, élément et valeurs de dimension).


Le principe d’agrégation s’applique également au concept « indicateur de remise », ce qui permet de s’assurer de la complétude des remises au fil des télétransmissions.


Si un fait est associé à une dimension typée, deux faits (un ancien et un nouveau) ne seront considérés comme identiques que si cette dimension prend exactement la même valeur lexicographique :


Exemple des risques par bénéficiaire sur le tableau GRAN_RISK, utilisant la dimension "Numéro de liste" :

Déclaration initiale :

numéro de liste 00001 : total des risques pondérés sur société A d’un montant de 1 000 €

numéro de liste 00002 : total des risques pondérés sur société B d’un montant de 2 000 €

numéro de liste 00003 : total des risques pondérés sur société C d’un montant de 3 000 €


Déclaration rectificative : l’établissement doit déclarer un encours de 2 500 € au lieu de 2 000 € sur la société B

numéro de liste 00002 : total des risques pondérés sur société B d’un montant de 2 500 €

Attention : un numéro de liste à "2" ajouterait un nouveau fait ("2" est différent de "00002").


3.4 Annulation de Tableaux ou de Faits


Pour réinitialiser ou annuler une donnée, le principe retenu est le suivant :

  • si l’établissement souhaite annuler un montant valorisé transmis précédemment, il doit retransmettre le Fait correspondant à « nil» ;

  • si l’établissement souhaite annuler l’ensemble des données d’un tableau des domaines « SUR » ou « BLC », il doit retransmettre le concept « indicateur de remise » du tableau concerné à « nil » ET l’ensemble des faits de ce tableau à « nil », à l’exception des faits communs avec d’autres tableaux remis.


Un nouveau fait à « nil » annule un fait déjà reçu.


Note - rappel du mécanisme du "nil" :


Un élément à « nil » ne possède pas de valeur mais un attribut particulier défini par la recommandation XML Schema (xsi :nil) avec la valeur booléenne « true » (ou « 1 »). Pour un élément numérique, l’attribut XBRL « decimals » ne doit pas être présent.


3.5 Déclaration sans valorisation de Faits


Dans l’hypothèse où un établissement est assujetti à la remise d’un tableau défini dans les taxonomies SURFI_Principale, SURFI_Grands Risques, SURFI Ratio de Couverture Sociétés Crédit Foncier et de Financement à l’habitat, SURFI Emplois Ressources par Devises et Pays, mais pour lequel il ne porte pas d’encours, il doit déclarer le concept « Indicateur de remise » associé avec la valeur « OUI » sans aucun autre concept spécifique de ce tableau.

Pour la remise COREP, seuls les tableaux valorisés sont à transmettre au SGACP. Toutefois, si le système de reporting utilisé génère l’ensemble des tableaux, il convient alors de préciser au moins un « context » et un « unit » avec une « measure » de type « monetary » pour chacune des instances à néant.



  1. Règles de gestion

4.1 Expression des données


Les pourcentages doivent respecter les spécifications XBRL 2.1 et seront par défaut exprimés en ratio avec une précision d’au moins quatre décimales après la virgule (attribut "decimals" avec la valeur "4") (exemple 9,80 % sera exprimé 0.0980). Néanmoins, certains ratios définis dans la note DSMF n° 2009-01 (tableau M_INTNOUA par exemple), seront exprimés avec la précision d’au moins six décimales (attribut "decimals" valant "6") (exemple 10,0754 % sera déclaré 0.100754, 10,0700 % sera déclaré 0.1007avec attribut "decimal" valant "6").


Les spécifications XBRL 2.1 font référence à la norme ISO 4217 pour la définition des unités monétaires ce qui conduit à exprimer les montants en unités d’Euros ou de Francs CFP. Les montants monétaires devront être exprimés en unités monétaires (attribut "decimals" avec la valeur "0").


Toutes les données monétaires d'une instance doivent être exprimées en Euros ou en Francs CFP (QName = "{http://www.xbrl.org/2003/iso4217}EUR" ou "{http://www.xbrl.org/2003/iso4217}XPF".


Toutes les données numériques non monétaires doivent être exprimées en "unités pures" (QName = {http://www.w3.org/2001/XMLSchema-instance}pure)


4.2 Expression des codes activités


Les codes activités « code APE/NAF » utilisés pour certains tableaux tels que IMPLANTAT ou GRAN_RISK devraient être exprimés avec deux chiffres, un point, deux chiffres et une lettre majuscule sans accent (exemple l’activité « télécommunications filaires » sera déclarée 61.10Z).


4.3 Identification des personnes physiques


Dans le cadre des déclarations qui référencent des personnes physiques (exemple tableau GRAN_RISK), ces dernières sont identifiées par les éléments suivants :

  • leur qualité : « Madame », « Monsieur », « Mademoiselle » ;

  • leur nom patronymique selon une chaine d’au plus 30 caractères ;

  • leur date de naissance  au format AAAA-MM-JJ (exemple 2010-05-03) ;

  • la référence interne complète cette identification et est exprimée avec 16 caractères (chiffres ou lettres, minuscules ou majuscules, non accentuées).


4.4 Précision sur les éléments de type « Duration »


Les différents éléments dans Surfi correspondent à un solde ou à un flux financier relevé au cours d’une période. Les comptes de bilan appartiennent à la première catégorie, les comptes de charges et de produits à la seconde catégorie. Dans la taxonomie Surfi, cela correspond pour chaque élément à la propriété « période » avec les valeurs respectives « instant » et « duration».


Les tableaux Surfi qui possèdent des éléments de type « duration » sont les suivants :

  • RESU_INFI     Résultats des opérations sur instruments financiers à terme (T)

  • CPTE_RESU   Compte de résultat (S)

  • RESU_IFT      Résultats des Opérations sur instruments fin. à terme (S)

  • RESU_CONS  Compte de résultat consolidé (S)

  • CLIEN_CB     Opérations de crédit-bail et op assim (S)

  • RESU_PUBL  Compte de résultat publiable (A)

  • SYS_GAR03   Système de garantie de place 3 (A)

  • SYS_GAR09   Système de garantie de place 9 (A)



Les tableaux COREP qui possèdent des éléments de type « duration » sont les suivants :

  • OPR Loss Detail Information détaillée sur les principales pertes

  • OPR Detail Pertes brutes par ligne de métier et type d'évènement sur l'année passée


Les tableaux FINREP, qui possèdent des éléments de type « duration » sont les suivants :

  • FINREP 2 Compte de résultat consolidé

  • FINREP 9    Immobilisations corporelles

  • FINREP 10      Immeubles de placement (IP)  

  • FINREP 11      Goodwill et autres immobilisations incorporelles

  • FINREP 18     Provisions

  • FINREP 20      Produits et charges d'honoraires et de commissions

  • FINREP 23      Profit net ou perte nette résultant de la comptabilité de couverture

  • FINREP 25      Autres produits et charges opérationnels

  • FINREP 30      Informations sur le risque de crédit et les dépréciations  

  • FINREP 32      Locations : informations complémentaires

  • FINREP 34      Information relative aux parties liées



Les valeurs de la duration à retenir pour les éléments appartenant à ces tableaux sont les suivantes (exemples) :


Arrêté

Les valeurs

Arrêté du 31 mars 2012

startDate 2012-01-01 endDate : 2012-03-31
(période du 01 01 2012 au 31 03 2012)

Arrêté du 30 juin 2012

startDate 2012-01-01 endDate : 2012-06-30
(période du 01 01 2012 au 30 06 2012)

Arrêté du 30 septembre 2012 

startDate 2012-01-01 endDate : 2012-09-30
(période du 01 01 2012 au 30 09 2012)

Arrêté du 31 décembre 2012 

startDate 2012-01-01 endDate : 2012-12-31
(période du 01 01 2012 au 31 12 2012)



Par exception, cette règle ne s’applique pas au tableau trimestriel monétaire M_FLUDINT  Flux d’intérêts trimestriels dont les périodes sont les suivantes :  


Arrêté

Les valeurs pour M_FLUDINT (trimestriel)

Arrêté du 31 mars 2012

startDate 2012-01-01 endDate : 2012-03-31
(période du 01 01 2012 au 31 03 2012)

Arrêté du 30 juin 2012

startDate 2012-04-01 endDate : 2012-06-30
(période du 01 01 2012 au 30 06 2012)

Arrêté du 30 septembre 2012 

startDate 2012-07-01 endDate : 2012-09-30
(période du 01 01 2012 au 30 09 2012)

Arrêté du 31 décembre 2012 

startDate 2012-10-01 endDate : 2012-12-31
(période du 01 01 2012 au 31 12 2012)




  1. Les contrôles


Plusieurs types de contrôles sont mis en place au sein des applications OneGate et SURFI :

5.1 Contrôles de structure visant à s’assurer de la validité des instances


#

Contrôle

Type

OneGate

SURFI







Vérifier la conformité de l’en-tête

Bloquant

X




Cf. note technique OneGate




Unicité de la clé de l’instance

Bloquant

X

X

Cf. point 2.3




Vérification CIB en-tête et instance

Bloquant

X

X







Vérifier le Domaine par rapport à la taxonomie référencée

Bloquant



X







XBRL 2.1

Bloquant

X










Agrégation et dimensions

Bloquant

X










Version de taxonomie et arrêté

Bloquant




X







Présence de l’option de remise pour les taxonomies COREP

Bloquant

X

X







Présence d’au moins un tableau déclaratif pour les taxonomies concernées

Bloquant




X

Cf. point 3.2




Arrêté existant

Bloquant




X







Existence du CIB

Bloquant suite à analyse SGACP

X

X







Vérifications diverses par rapport au profil de l’établissement (ex : assujetti FINREP…)

Soumis à analyse
SGACP




X







Vérifications sur l’approche des risques…)

Soumis à analyse
SGACP




X




5.2 Des contrôles sur les données visant à s’assurer de la bonne qualité des instances.


Les contrôles publiés sur le site du SGACP et de la DSMF, ainsi que ceux publiés au travers des tableaux COREP et FINREP annexés aux instructions ont été définis, selon le cas, dans l’un des types ci-dessous :

  • contrôles standards XBRL Formula : ces contrôles sont intégrés dans les taxonomies respectives sous la forme d'assertions ;

  • contrôles paramétrés XBRL Formula (cf. point 5.3) : contrôles basés sur le « profil » de l’établissement, portés par les taxonomies ;

  • contrôles spécifiques : contrôles non portés par les taxonomies y compris inter-instances COREP ;

  • contrôles en lien avec d’autres bases de données : ces contrôles visent à vérifier l’existence de SIREN notamment.



Les différents types de contrôles ci-dessus sont effectués sur les instances agrégées.


Pour les déclarations relatives aux taxonomies des domaines SURFI et BLANCHIMENT (cf. partie 3.1) le déclenchement de ces contrôles est associé à un ou plusieurs indicateurs de remise (cf. point 3.2) ; ils ne s’effectuent que si l’ensemble de ces indicateurs de remise sont à « OUI » dans l’instance agrégée.

5.3 Contrôles paramétrés


Dans la taxonomie SURFI Principale, certains contrôles ne doivent être appliqués que si l'assujetti présente des particularités. Ces contrôles dépendent donc de paramètres extérieurs à la taxonomie et à l'instance XBRL ; ils sont appelés "Contrôles paramétrés".


Les contrôles paramétrés de la taxonomie SURFI Principale dépendent de l'activité de l'assujetti et ne sont à effectuer que si elle est limitée à la France et / ou aux départements d'outre-mer.


Les modalités du paramétrage sont décrites dans la notice descriptive de la taxonomie.



  1. Précisions sur les Dimensions des tableaux COREP


État MKR SA EQU (risques de marché en approche standard relatifs aux positions sur titres de propriété) cité au point 3.2 de l’instruction détaille les exigences de fonds propres pour les principaux marchés nationaux. Les marchés nationaux seront exprimés par leur code ISO à la norme w:en:ISO 3166-1 alpha-2.


D’autre part, afin de rapprocher l’exigence de fonds propres déclarée sur l’état CA rubrique 2.3.1.2, à la somme des exigences de l’ensemble des marchés nationaux de l’état MKR SA EQU (cf. annexe 11) , le contrôle inter-instance reposera sur la dimension « National Market » exprimée avec sa valeur « Total ».


État MKR SA COM (risques de marché en approche standard relatifs aux positions sur produits de base) sera décliné sur chacune des quatre dimensions qui seront exprimées :

  • pétrole, gaz

  • métaux

  • céréales

  • café, cacao, sucre




  1. Exigences minimales des éditeurs de taxonomie et tests


Il est nécessaire de sélectionner un éditeur de taxonomie qui certifie respecter les spécifications XBRL 2.1 ainsi que la spécification XBRL Dimensions 1.0.


Certaines règles techniques applicables aux reporting visés par cette note, sont reprises en annexe.


Il vous est également possible d’effectuer des tests en envoyant des instances sur un environnement dédié dit d’homologation à l’URL suivante : https://onegate-test.banque-france.fr/onegate


Ces tests permettront de valider l’intégralité du processus de réception et de traitement, ainsi que de vous adresser un compte rendu sur la validation de tous les processus de contrôle.


Dans cette hypothèse vous devrez au préalable contacter les services concernés pour obtenir les autorisations nécessaires.

Nota bene : les Sociétés de Services peuvent obtenir auprès du service informatique du SGACP un code interbancaire fictif pour effectuer ces tests.



  1. Procédure TESS : obtention de numéro fictif pour les entités sans SIREN


L’ensemble des entités non établissements assujettis, déclarées dans certains tableaux SURFI tels que IMPLANTAT, GRAN_RISK, SYS_GAR07…, doivent obligatoirement être identifiées avec un numéro SIREN.


Pour le cas particulier des entités non résidentes, des Fonds Communs de Créances et Fonds Communs de Placements non référencés avec ce type de codification, le Service Central des Risques de la Banque de France leur attribue un numéro SIREN fictif. Ce dernier doit donc être reporté dans les déclarations réglementaires SURFI. Dans l’hypothèse où le déclarant n’aurait pas connaissance de ce SIREN fictif pour compléter ses déclarations réglementaires, il doit en faire la demande via l’outil TESS (Traitement des Entités Sans Siren).


Tout renseignement complémentaire sur cette procédure peut être obtenu en contactant l’adresse suivante : 4072-tess-ut@banque-france.fr



  1. Restitutions : compte-rendu de collecte


Les Comptes Rendus de Collecte générés à l’issue des traitements effectués dans l’application du SGACP ainsi que les relances retards déterminées en cas d’absence de déclaration après les dates limites de remise, sont déposés sur le portail OneGate (cf. guide utilisateur OneGate).


Ces dépôts feront l’objet de notification par mail auprès des utilisateurs accrédités au portail OneGate.



  1. Fiche déclarative


La fiche déclarative est un document qui permet au SGACP de collecter diverses informations concernant les établissements. Ces informations portent sur les zones d’activité, la consolidation, les normes comptables, les approches de risques ou encore les prestataires informatiques et sont utilisées notamment pour déterminer la remise ou non de certains tableaux SURFI, COREP ou FINREP par les agents assujettis.


La fiche déclarative doit être complétée par chaque établissement assujetti via le domaine « FDE » du portail OneGate (cf. guide utilisateur OneGate).


Deux cas peuvent se présenter :

  • l’établissement remettait un reporting BAFI avant le 30/06/2010.

Le SGACP dispose alors des éléments issus de ses applications antérieures et aucune mise à jour n’est requise pour initialiser sa nouvelle application.

L’établissement ne renseigne cette fiche que lorsque l’une au moins de ses caractéristiques évolue.

Lors de la première mise à jour, la fiche n’étant pas initialisée, il convient d’effectuer une saisie complète de celle-ci en valorisant l’ensemble des rubriques à la date d’effet du 30.06.2010 et à la date effective pour la(es) rubrique(s) à l’origine de la modification.

Lors des mises à jour suivantes, la fiche sera pré-alimentée avec les données antérieures et seule la donnée à modifier sera saisie à la date souhaitée.

  • l’établissement ne remettait pas de reporting BAFI avant le 30/06/2010.

Tout nouvel établissement doit préalablement à l’envoi de déclarations réglementaires, compléter intégralement cette fiche. Elle est ensuite actualisée à chaque évolution d’une caractéristique de l’établissement.



  1. Annexe




Règles techniques XML XBRL








61 RUE TAITBOUT - 75009 PARIS – Code courrier : 090-2716

Похожие:

Direction des ressources humaines, methodes et système D’information iconLe système d’information sanitaire du service de Chirurgie «A» : états des lieux et propositions d’amélioration
«A» du Centre Hospitalier Universitaire du Point G, nous avons suivi une démarche rigoureuse afin de définir un outil réellement...
Direction des ressources humaines, methodes et système D’information iconResearch Methods in Population Health / Méthodes de recherche en santé des populations

Direction des ressources humaines, methodes et système D’information iconCoordination de la nuit des musées : Direction des musées de France / Mission de la communication 6, rue des Pyramides f-75041 Paris cedex 01
Министерства культуры и коммуникации Франции, прошедшая с большим успехом, главной целью которой является привлечение новых посетителей,...
Direction des ressources humaines, methodes et système D’information iconInformation is about direction of preparation

Direction des ressources humaines, methodes et système D’information icon1 Préfecture de la Charente-Maritime Direction de la Réglementation et des Libertés Publiques 145

Direction des ressources humaines, methodes et système D’information iconSommaire avant propos p 3 introduction … p 4
«un examen qui se base sur des techniques permettant d’analyser et d’évaluer les méthodes de l’entreprise»
Direction des ressources humaines, methodes et système D’information iconDirection de Genève place des frères Zanarelli, à Coupy. Rte du camping – aire perm En Bord de rivière, Eau vidanges Edf

Direction des ressources humaines, methodes et système D’information iconErp, gestion de projet, pilotage de projet, changement organisationnel, analyse processuelle, système d’information

Direction des ressources humaines, methodes et système D’information iconPaix : Edward Teller, père de la bombe à hydrogène et premier fan du système d'armes «guerre des étoiles», pour avoir consacré sa vie à changer la signification du mot «paix». Physique
«guerre des étoiles», pour avoir consacré sa vie à changer la signification du mot «paix»
Direction des ressources humaines, methodes et système D’information iconGestion de projet e-business, moa-moe, urbanisme des systèmes d’information, gouvernance, entreprise étendue, communautés de pratique

Разместите кнопку на своём сайте:
Библиотека


База данных защищена авторским правом ©lib.znate.ru 2014
обратиться к администрации
Библиотека
Главная страница