Contrat d'interface API DataAsso - associations · Web viewCe document a pour objet de décrire le contrat d’interface de l’API Association. Il fournit les informations nécessaires

MINISTÈRE DE L’EDUCATION NATIONALE

DIRECTION DE LA JEUNESSE,

DE L’EDUCATION POPULAIRE

ET DE LA VIE ASSOCIATIVE

SYSTÈMES D’INFORMATION DE LA VIE ASSOCIATIVE

CONTRAT D’INTERFACE DE L’API ASSOCIATION

Version Date Modifications1.4 17/12/2018 Corrections du schéma .xsd1.3 27/11/2017 Modifications importantes au niveau des DACS (section 7)1.2 15/06/2017 Modifications mineures1.1 23/12/2016 Mise à jour des DACS et des documents_dacs

Remplacement du tableau de la section 5 par un fichier xls1.0 09/11/2016 Intégration des éléments de production0.3 18/10/2016 Modalités d’utilisation des DAC0.2 09/09/2016 Description des méthodes DAC0.1 13/07/2016

95, avenue de France - 75650 Paris CEDEX 13 - Tél. : 01 40 45 90 00

www.jeunes.gouv.fr www.associations.gouv.fr

1

http://www.associations.gouv.fr/

http://www.jeunes.gouv.fr/


1 OBJET DU DOCUMENT...............................................................................................................4

2 PRÉSENTATION DE L’API ASSOCIATION......................................................................................42.1 Finalités.........................................................................................................................................................................4

2.2 Nature des informations véhiculées...........................................................................................................................5

2.3 Méthodes.......................................................................................................................................................................6

3 ACCÈS ET FORMAT.....................................................................................................................73.1 Authentification...........................................................................................................................................................7

3.2 Chiffrement et signature des données........................................................................................................................7

3.3 La méthode GET-structure........................................................................................................................................83.3.1 Appel......................................................................................................................................................................93.3.2 Réponse................................................................................................................................................................10

3.4 La méthode GET-document : téléchargement des documents..............................................................................10

3.5 Les méthodes de mises à jour des données administratives complémentaires (DAC)........................................113.5.1 Modalités de mise à jour des DAC......................................................................................................................123.5.2 Cas particulier des documents.............................................................................................................................13

4 EXPLOITATION DU WEB SERVICE..............................................................................................144.1 Niveaux de service......................................................................................................................................................14

4.2 Gestion des incidents.................................................................................................................................................15

5 LISTE DES DONNÉES.................................................................................................................16

6 JEUX DE TEST...........................................................................................................................16

7 MODALITÉS D’UTILISATION DES MÉTHODES POST, DELETE ET PATCH......................................167.1 Modification des informations complémentaires d’une association.....................................................................18

7.2 Modification des informations complémentaires d’un établissement...................................................................20

7.3 Ajout, suppression et modification d’une relation d’affiliation............................................................................217.3.1 Ajout d’une relation d’affiliation.........................................................................................................................217.3.2 Suppression d’une relation d’affiliation..............................................................................................................227.3.3 Modification d’une relation d’affiliation.............................................................................................................22

7.4 Ajout et suppression d’un adhérent personne morale...........................................................................................227.4.1 Ajout d’un adhérent personne morale..................................................................................................................227.4.2 Suppression d’un adhérent personne morale.......................................................................................................23

7.5 Ajout, suppression et modification d’une personne physique...............................................................................237.5.1 Ajout d’un représentant légal...............................................................................................................................237.5.2 Suppression d’un représentant légal....................................................................................................................247.5.3 Modification d’un représentant légal...................................................................................................................24

7.6 Ajout, suppression et modification d’un agrément administratif.........................................................................257.6.1 Ajout d’un agrément administratif.......................................................................................................................257.6.2 Suppression d’un agrément administratif............................................................................................................257.6.3 Modification d’un agrément administratif...........................................................................................................26



2



MINISTÈRE DE L’EDUCATION NATIONALE7.7 Ajout et modification de ressources humaines........................................................................................................26

7.7.1 Ajout d’une année de données de ressources humaines......................................................................................277.7.2 Modification des données de ressources humaines.............................................................................................27

7.8 Ajout et modification des comptes de résultat et financements perçus................................................................287.8.1 Ajout d’une année de comptes de résultat et financements perçus.....................................................................287.8.2 Modification des données de comptes de résultat et financements perçus..........................................................29

7.9 Ajout, suppression et modification de coordonnées bancaires..............................................................................307.9.1 Ajout d’un RIB (coordonnées bancaires)............................................................................................................307.9.2 Suppression d’un RIB (coordonnées bancaires)..................................................................................................307.9.3 Modification d’un RIB (coordonnées bancaires)................................................................................................30

7.10 Ajout, suppression et modification d’un document administratif........................................................................317.10.1 Ajout de l’iD d’un document administratif.........................................................................................................317.10.2 Suppression de l’ID d’un document administratif...............................................................................................327.10.3 Modification de l’ID d’un document administratif.............................................................................................32



3




1 OBJET DU DOCUMENT

Ce document a pour objet de décrire le contrat d’interface de l’API Association. Il fournit les informations nécessaires permettant d’utiliser le service : formats d’échange et conditions d’utilisation.

2 PRÉSENTATION DE L’API ASSOCIATION

2.1 FINALITÉS

Développée dans le cadre de la gouvernance des Systèmes d’Information de la Vie Associative (SIVA) pilotée par la DJEPVA et ses partenaires, l’API Association a pour objectif de simplifier les démarches administratives des associations. Intégrée également dans la stratégie Etat plateforme du SGMAP, elle doit permettre :

- Le « dites-le nous une fois » pour les associations, qui ne devraient plus avoir à déclarer une nouvelle fois les informations administratives déjà déclarées une fois à l’administration ;

- De disposer d’informations complètes (exhaustives et à jour) pour les administrations ;

L’API Association a pour finalité d’être intégrée dans tout portail, front-office et back-office de gestion des associations, quelles que soient les démarches administratives et les autorités administratives (Etat ou collectivités territoriales) concernées. Elle concerne potentiellement toutes les associations françaises, relevant ou non de la loi 1901.

L’utilisation de l’API Association est prévue pour :

- Toute association souhaitant connaitre les informations dont l’administration dispose sur elle. Elle pourra l’interroger via les portails administratifs qui gèrent des démarches administratives pour les associations ;

- Tout agent public ou tout utilisateur habilité dans le cadre de sa mission à traiter des démarches administratives des associations : soit directement via une URL, soit via un back-office de gestion.

L’API Association est une API unitaire, dont la fonction principale est de retourner au demandeur les informations administratives (données structurées et documents) d’une association. Elle est appelée à partir des identifiants fonctionnels d’une association (n° RNA ou n° SIREN/SIRET) :

- L’appel par le n° RNA ou par le n° SIREN retourne les informations administratives de l’association, caractérisée par son siège, ainsi que l’ensemble des établissements actifs déclarés dans Sirene et leurs coordonnées ;

- L’appel par un n° Siret retourne les informations administratives de l’association, caractérisée par son siège, ainsi que les coordonnées de l’établissement correspondant au n° Siret appelé.

En outre, l’API Association est semi-ouverte, dans le sens où une partie des informations qu’elle véhicule peut être mise à jour directement via les front offices et les télé-services qui la consomment.

Ainsi, l’API Association dispose de plusieurs méthodes : GET pour obtenir les données et documents administratifs d’une association et les méthodes POST, DELETE et PATCH pour permettre à une association de mettre ses informations administratives complémentaires.



4




2.2 NATURE DES INFORMATIONS VÉHICULÉES

Le schéma ci-dessous décrit les différentes informations de présentation d’une association. Ces informations sont classées par nature selon les modalités de déclaration et de validation et les bases de données sources dans laquelle on les trouve. Ce schéma est valable pour les associations relevant de la loi 1901 et qui sont immatriculées à l’INSEE (répertoire Sirene). Cependant :

- L’immatriculation à l’INSEE (n° Siret) n’est obligatoire que sous certaines conditions (emploi de salariés, redevance de taxes, demandes de subventions). Elle ne concerne donc pas toutes les associations ;

- Les associations relevant du régime du Concordat (Alsace-Moselle) ne sont pas immatriculées dans le RNA, mais dans les tribunaux d’instance locaux. Ces informations ne sont pas accessibles à l’heure actuelle par l’API Association ;

- Les informations administratives complémentaires ne doivent être déclarées seulement pour les demandes de subvention.

L’API Association permet de retourner trois types d’information, selon leur nature :

- Les informations juridiques déclarées au greffe des associations pour les associations relevant de la loi 1901, dont la source est la base du RNA (Répertoire National des Associations). Ces informations ne peuvent être déclarées que via les procédures du greffe des associations, au moment de la création juridique (e-Creation pour la version dématérialisée) et au moment de la déclaration d’une modification du nom, du siège, de l’objet, des dirigeants, etc. (e-Modification pour la version dématérialisée) ;

- Les informations « Entreprise » (caractéristiques de l’association et de tous ses établissements), déclarées par l’association au Centres de Formalités des Entreprises (CFE) ou à l’INSEE pour disposer d’un n° Siren et d’un n° Siret pour chaque établissement, pour les conditions exposées ci-dessus. Ces informations sont dans le



5




répertoire Sirene, et sont mises suite à la déclaration par l’association d’une modification du nom, du siège, des activités, de la création, suppression, modification d’un établissement ;

- Les informations administratives complémentaires, nécessaires aux demandes de subvention, aujourd’hui déclarées dans les front-office de demande de subvention des portails de l’Etat et des collectivités territoriales.

L’API Association doit retourner ces trois types d’information, qui correspondent aux dernières informations déclarées par l’association, par l’intermédiaire des mécanismes décrits ci-dessous. On entend par « information » :

- Des champs structurés issus des bases sources telles que le RNA, Sirene et un portail administratif pour les données dites « DAC » ;

- Des documents issus de la base du RNA (statuts, récépissés, liste des dirigeants) ou d’un portail administratif dans lequel les associations ont chargé leur budget annuel, leur compte, leur rapport d’activité, etc.

Si les informations juridiques loi 1901 et les informations « Entreprises » ne peuvent être modifiées par les associations uniquement par les canaux appropriées (utilisation de formulaires et de télé-services spécifiques), les informations administratives complémentaires peuvent être modifiées par l’association en retour : elles seront alors chargées dans une nouvelle base « DBAsso », qui stocke aussi la jointure n° SIREN/n° RNA des associations.

Enfin dans une version ultérieure, il est envisageable que l’API Association véhicule également des informations non administratives d’une association, comme par exemple les activités ou événements qu’elle organise et qu’elle aurait saisie dans un site de crowdsourcing.

2.3 MÉTHODES



6




L’API Association s’appuie sur un format public normalisé des informations de référence d’une association. L’API Association est un service web de type REST, qui s’appuie donc uniquement sur les protocoles et standards utilisés sur le web. Elle se consomme en GET et est également semi-ouverte, une partie des données pouvant être mises à jour (par l’intermédiaire de requête POST DELETE ou PATCH) suite aux modifications effectuées par les associations sur les portails administratifs.

Son accès est sécurisé et elle dispose de plusieurs méthodes :

· GET-structure : appelé à partir d’un n° RNA, n° SIREN ou n° SIRET d’une association, retourne les informations administratives de présentation d’une association,

· GET-document : appelé à partir des id techniques transmis par GET-structure, permet le téléchargement d’un document issu du RNA ou du porte-document administratif d’un portail administratif.

· Les méthodes POST, DELETE et PATCH permettent aux associations de mettre à jour les données administratives complémentaires (DAC) directement à partir d’un portail administratif : ces méthodes s’utilisent sur une dizaine d’objets (représentant légal, agréments administratifs, ressources humaines, etc.) dont les id des documents chargés par l’association dans DBAsso, permettant à un consommateur de l’API Association d’obtenir le contenu du document en retour de la méthode GET-document.

Diagramme de séquence de l’API Association – méthodes GET

Le détail des méthodes est présenté dans la section 3. Les informations administratives de présentation d’une association (données structurées et documents) sont détaillées dans la section 5.

3 ACCÈS ET FORMAT

3.1 AUTHENTIFICATION



7




L’accès à l’API Association est protégé et restreint aux utilisateurs authentifiés. L’authentification, de type « basique » s’effectue par l’intermédiaire d’un username/mot de passe qui devra être transmis pour chaque requête dans l'entête Https, quel que soit le verbe utilisé (GET, POST, PATCH, DELETE).

La consommation en GET est limitée à 1000 requête par heure par username.

Le username/mot de passe des environnements d’intégration et de production seront communiqués après instruction de la demande à effectuer par courriel à [email protected].

3.2 CHIFFREMENT ET SIGNATURE DES DONNÉES

Il s’effectue en https, dans l’environnement de production uniquement.

Aucun certificat ne devra être installé pour l’environnement d’intégration, auquel on accède via http exclusivement.

3.3 LA MÉTHODE GET-STRUCTURE

La récupération des informations de l’association via l’API Association s’effectue via une requête unitaire ( la méthode GET-structure) vers le système d’échange « ESB SIVA », où est hébergé l’API Association. L’ESB SIVA s’appuie sur :

- L’éventuelle jointure entre n° RNA et n° SIREN (base DBAsso), qui permet d’identifier les bases sources à interroger pour collecter les données ;

- L’appel de données au RNA (flux 5) ;- L’appel de données à Sirene (flux 6) ;- L’accès à DBAsso pour les « données administratives complémentaires » (DAC) saisies par les associations

dans les portails et télé-services des administrations (flux 2) ;

La méthode GET-structure doit être appelée avec un des identifiants suivants :

- Le n° RNA- Le n° SIREN- Le n° Siret

Elle retourne des informations structurées détaillées en annexe, ainsi que les id et les modalités d’accès aux documents dont l’administration dispose sur l’association interrogée (ces éléments seront nécessaires pour la consommation ultérieure de la méthode GET-document).

Les informations collectées via les flux 5 et 6 au moment de l’appel de l’API Association sont doublées par des « flux événements », envoyés quotidiennement pour chaque événement de création et de modification d’association par les bases sources RNA (flux 4) et Sirene (flux 9).



8

mailto:[email protected]




Diagramme de séquence de l’API Association – méthode GET-structure

La légende du diagramme de séquence fait apparaitre la disponibilité des différents flux, classés par version de l’API Association (voir la roadmap section Error: Reference source not found).

La relation entre l’identifiant appelé et les informations retournées peut être résumée ainsi :

Identifiant de l’appel Informations del’association (siège)

Etablissements

N° RNA OUI Tous1

N° SIREN OUI Tous

N° SIRET OUIEtablissement correspondant

au n° Siret appelé

Si l’association relève de la loi 1901 (et qu’elle dispose donc d’un n° RNA) mais qu’elle n’est pas immatriculée à l’INSEE (si elle ne dispose pas de n° SIREN) ou que la jointure avec le n° RNA n’est pas connue dans la base DBAsso, l’API retourne les informations issues de la base RNA (et DAC le cas échéant).

Si l’association est immatriculée à l’INSEE (et dispose donc d’un n° SIREN), mais qu’elle ne relève pas de la loi 1901 (elle n’est donc pas immatriculée au greffe des associations et ne dispose pas de n° RNA) ou que la jointure avec le n° RNA n’est pas connue dans la base DBAsso, l’API retourne les informations issues de la base Sirene (et DAC le cas échéant).

3.3.1 APPEL

L’API peut être appelée selon différentes méthodes, qui retournent les informations issues de la base du RNA et/ou de la base Sirene, ajoutée aux informations « DAC ».

1 Seulement si l’association dispose d’un n° Siren et que la jointure avec le n° RNA est connue dans la base DBAsso.



9




Méthode URL id

GET api/structure/{id}api/rna/{idRna}api/siren/{idSiren}

id = idRna, idSiren, idSiret

Les url ci-dessous sont tronquées. Les url complètes seront communiquées après instruction de la demande à effectuer par courriel à [email protected].

URL pour l’intégration :

http://xxx/api/ (voir WADL ci-dessous)

http://xxx/api/structure/id <id = n° RNA ou n° SIREN ou n° Siret>

http://xxx/api/rna/idRna <idRna = n° RNA> --> appel au RNA

http://xxx/api/siren/idSiren <idSiren = n° SIREN> --> appel à Sirene

URL pour la production :

https://xxx/api/structure/ (mêmes modalités que l’intégration)



10

https://xxx/cxf/api/structure/

http://xxx/services/api/siren/idSiren

http://xxx/services/api/rna/idRna

http://xxx/services/api/structure/id

http://xxx/services/api/





3.3.2 RÉPONSE

Sur la base d’une requête unitaire, l’API interroge les différents fournisseurs d’informations et transmet l’information complétée au demandeur :

- Données validées du RNA et/ou du répertoire SIRENE.- Données administratives complémentaires issues de DBAsso (origine : flux DAC) ;- L’index des documents.

Après l’authentification, les contrôles sont effectués dans l’ordre chronologique suivant :

Id Code Réponse

Id conforme 200 La réponse contient un tableau détaillant les caractéristiques de l’association. L’objet en réponse respecte la structure suivante.{ "nom": xxxxxxxxxxx, "sigle": xxxxxxxxxxx, "id_rna": xxxxxxxxxxx, "id_siren": xxxxxxxxxxx, "id_siret_siege": xxxxxxxxxxx, "date_pub_jo": xx/xx/xxxx[…]}

Id format non conforme {"error":"id n'est pas reconnu comme un code acceptable"}

Id non existant {"error":"id not found in dbasso"}

Méthode non conforme {"error":" Method Not Allowed"}

500 Internal Server Error

503 Service Unavailable

3.4 LA MÉTHODE GET-DOCUMENT : TÉLÉCHARGEMENT DES DOCUMENTS

L’API Association permet aussi de télécharger des documents issus du RNA ou du porte-document administratif d’un portail à partir duquel ils ont été déposés. Leur accès nécessite au préalable d’avoir obtenu leur id, via la méthode Get-structure. L’ESB SIVA se charge d’effectuer le routage vers le portail administratif où est stocké le document.

Voici la liste des documents accessibles potentiellement :

Type de document Base source du document

Origine du document

Fréquence / Quantité

Délibération de l’organe délibérant (procès-verbal de RNA Association 1 courant



11



MINISTÈRE DE L’EDUCATION NATIONALEType de document Base source du

documentOrigine du document

Fréquence / Quantité

l'assemblée consultative)Statuts RNA Association 1 courant

Liste des personnes chargées de l’administration de l’association régulièrement déclarée (composition du conseil, du bureau, …)

RNA Association 1 courant

Récépissé de création ou de modification RNA RNA N potentiellementBudget annuel DBAsso Association/

établissementAnnuel

Relevé d’identité bancaire DBAsso Association/ établissement

N potentiellement

Comptes approuvés du dernier exercice clos DBAssoJOAFE

Association/ établissement

Annuel

Rapport du commissaire aux comptes DBAssoJOAFE

Association/ établissement

Annuel

Rapport d’activité approuvé DBAsso Association Le plus récentArrêté de l’agrément administratif DBAsso Association Le plus récent

1 par agrémentAttestation d’affiliation DBAsso Association Le plus récent

1 par affiliationProjet sportif (cas des associations exerçant dans le domaine du Sport)

DBAsso Association Le plus récent

Le diagramme de séquence de la requête GET-document peut être résumé ainsi :

L’utilisateur qui souhaite télécharger un document utilise la méthode GET-document (id-doc, url-doc) vers l’ESB SIVA, qui enregistre l’émetteur de la requête et la forwarde, selon le type de document, vers le RNA ou vers DBAsso.

La base RNA-doc ou DBAsso-doc répond à la méthode GET-document de l’ESB SIVA en transmettant le contenu du document accompagné de l’id-doc. L’ESB-SIVA forwarde le contenu du document et d’id-doc vers l’utilisateur.

Diagramme de séquence de l’API Association – méthode GET-document



12




3.5 LES MÉTHODES DE MISES À JOUR DES DONNÉES ADMINISTRATIVES COMPLÉMENTAIRES (DAC)

L’API Association est semi-ouverte : les associations ont la possibilité de mettre à jour les données administratives complémentaires (DAC) à partir d’un portail administratif connecté à l’API Association. Les autres données (sources RNA et Sirene) doivent être exclusivement modifiées via les formulaires administratifs adéquats (papiers ou dématérialisés).

La mise des informations à jour via l’API Association s’effectue sur les différents objets (affiliations, agréments, ressources humaines…) des données administratives complémentaires (DAC) par l’intermédiaire des verbes PATCH, POST et DELETE.

Les données sont stockées directement dans la base DBAsso : DBAsso devient donc la base de référence nationale pour les données administratives complémentaires, le RNA et Sirene restants les référentiels pour les autres données d’identité des associations. Par ce mécanisme, une association retrouvera dans tout portail administratif les données qu’elle a mises à jour à partir d’un autre portail, et les administrations en bénéficieront en temps-réel. Mais DBAsso ne conserve pas d’historique, sauf pour les données annualisées (ressources humaines, comptes et les documents annualisés)

3.5.1 MODALITÉS DE MISE À JOUR DES DAC

Les données administratives complémentaires (DAC) se caractérisent par les éléments suivants :

- Des informations complémentaires de présentation d’une association ou d’un établissement : le champ d’action territorial de l’association, certaines dates (date de publication de la création au registre des associations pour les associations d’Alsace-Moselle, date de publication au journal officiel de la reconnaissance d’utilité publique) et certaines coordonnées (téléphone, email, site internet de l’association).

- Les relations d’affiliation : identification des fédérations, unions, réseaux auxquels l’association est affiliée. Pour en faciliter la déclaration (qui doit renvoyer un identifiant de l’association), il est conseillé d’exploiter le web service permettant d’obtenir les identifiants (n° RNA et n° Siren) d’une association à partir d’une recherche sur son nom.

- Les adhérents personnes morales : identification des adhérents personne morale autres que des associations- Les personnes physiques : déclaration du représentant légal de l’association pour une demande de

subvention notamment, ou de toute personne physique dont l’identité peut être utile pour l’administration. La saisie de ces informations est nécessaire car la liste des personnes chargées de l’administration de l’association n’est pas disponible à ce jour en tant que champs structurés à ce jour, mais en tant que document. L’id de la structure doit être le n° Siret (et non le n° rna ou n° siren), car pour une demande de subvention formulée par un établissement secondaire, le représentant légal doit être lié à cet établissement (et non nécessairement au siège).

- Les agréments administratifs : il s’agit de la liste des agréments administratifs en cours de validité dont bénéficie l’association.

- Les ressources humaines : il s’agit des différentes ressources humaines (salariés, adhérents, volontaires, bénévoles, licenciés…) dont bénéficie l’association ou ses établissements au 31/12 des trois dernières années.

- Les comptes de résultat et financements perçus : il s’agit du compte de résultat et des financements perçus par l’association ou ses établissements au 31/12 des trois dernières années.



13




- Les coordonnées bancaires : il s’agit du ou des RIB de l’association ou de ses établissements.- Les documents : il s’agit essentiellement des documents qui ne figurent pas dans le RNA et qui sont

demandés dans le cadre d’une demande de subvention (le budget annuel, les comptes annuels, le rapport d’activité le plus récent, etc). Chaque document est caractérisé par un type et une année. Le contenu de ces documents et leurs caractéristiques peuvent être transmis à DBAsso, qui les rend accessibles via les méthodes GET-Structure (pour obtenir leur id, leurs caractéristiques et l’url permettant de les télécharger) et GET-Document pour les télécharger sur son propre poste. Certains documents sont spécifiques à l’association, d’autres peuvent être propres à un établissement (budget ou compte de résultat notamment).

Pour chaque objet, une ou plusieurs méthodes peuvent être utilisées. Celles-ci doivent être utilisées intégralement, en précisant l’id de la structure (n° RNA ou n° Siren, voire n° Siret pour un établissement) ainsi que, le cas échéant, la clé permettant d’identifier l’objet à créer, supprimer ou modifier.


URL pour l’intégration :

http://xxx/api/dacs

URL pour la production :

https://xxx/api/dacs

Exemples :

· Déclaration des coordonnées complémentaires d’une association ({id_structure} correspond au n° RNA, n° SIREN ou n° Siret de l’association ou établissement) :

PATCH http://xxx/api/dacs/id_structure[{“key”:”telephone”,“value”:“0123456789”},{“key”:”site_internet”,“value”:“www.toto.fr”}]

· Ajout d’un représentant légal :

POST http://xxx/api/dacs/representant_legal/id_siret

{Civilite : "M. ", Nom : "R",Prenom : "Bob",



14

https://xxx/cxf/api/dacs

http://xxx/services/api/dacs





Fonction: "Président",…}

Tous les éléments permettant d’utiliser l’API Association semi-ouverte sont détaillés dans les sections 5 et 7.

3.5.2 CAS PARTICULIER DES DOCUMENTS

Un portail administratif doit permettre à une association disposant d’un compte sur ce portail de charger un document d’un des types détaillés ci-dessous :

Type de document Type API et DBAsso Quantité et fréquenceBudget prévisionnel annuel BPA 1 max par anRIB RIB 1 à N, pas annuelComptes annuels CPA 1 max par anRapport du commissaire au compte annuel RCA 1 max par anRapport d'activité (le plus récent) RAR 1 à N, pas annuelRapport financier annuel RFA 1 max par anArrêté de l’agrément administratif AGR Le plus récent

1 par agrémentAttestation d’affiliation AFF Le plus récent

1 par affiliationProjet sportif PRP Le plus récent

Chaque chargement d’un de ces documents doit se concrétiser par l’appel de l’API Association par une de ses méthodes (flux DAC) et la transmission du contenu du document et de ses caractéristiques, à l’instar de la mise à jour d’un champ dans l’écran « Informations administratives et légales » :

- POST-document en cas de chargement d’un nouveau document au sein du portail- PATCH-document si remplacement d’un document existant au sein du portail- DELETE-document : suppression d’un document existant dans le portail sans remplacement

Le portail doit être en mesure de gérer par des règles de gestion la quantité max de document en fonction du type et de l’exercice.

Pour chaque document, les informations transmises par le flux DAC sont détaillées dans la section 7.

4 EXPLOITATION DU WEB SERVICE

L’API Association, ainsi que l’ESB SIVA sur lequel elle repose, sont hébergés par la Direction des Systèmes d’Information des ministères sociaux.

4.1 NIVEAUX DE SERVICE

La plage d’ouverture de l’API Association est permanente : 24h/24 et 7j/7.



15




Son exploitation est assurée par la Direction des Systèmes d’information des ministères sociaux (DSI-MS) qui garantit un niveau de qualité de service en deux temps :

- Un niveau de service actuel jusqu’à courant 2017 ;

- Un niveau de service cible à partir de courant 2017, incluant un service haute disponibilité

Les caractéristiques du niveau de service sont les suivantes :

Service Niveau de service actuel Niveau de service cibleTaux de disponibilité Sans objet 99,8% de disponibilité annuelle, hors

indisponibilités planifiées

Continuité de Service Sans objet Un maximum trimestriel de quatre heures de coupure de service

Délais de rétablissement

Garantie de temps de rétablissement du service : 8 heures

Garantie de temps de rétablissement du service : 4 heures

Performances Temps de réponse :< 2 secondes dans 90 % des cas

Temps de réponse :< 2 secondes dans 90 % des cas

La DJEPVA, en tant que responsable fonctionnel du service, s’engage à informer les partenaires utilisateurs de l’API Association au moins 72 heures à l’avance du planning prévisionnel des arrêts planifiés sur les environnements de production et de qualification.

L’information est systématiquement transmise par messagerie au responsable fonctionnel de l’application du partenaire et à la gestion applicative. Le service ou les correspondants destinataires de l’information doivent accuser réception à l’émetteur de la prise en compte du message.

4.2 GESTION DES INCIDENTS

La DSI des ministères sociaux s’engage à intervenir aux heures de charge définies par la plage 08h00-18h00 5 jours/7.

Les incidents sont à declarer à l’adresse de messagerie suivante : [email protected]

En complément, les personnes suivantes peuvent être contactées :

Interlocuteurs de la DJEPVA :

Division des Systèmes d’information : M. Jean-François MORITZ 01 40 45 91 02

Mail : [email protected]

M. Guillaume GOGO 01 40 45 95 70


M. Frédéric CONSAVELA 01 40 45 94 93


Interlocuteurs de la DSI des ministères sociaux :



16








Bureau des applications de politiques publiques :

M. Vincent CARCEL 01 44 38 27 86 / 01 40 45 91 71




17




5 LISTE DES DONNÉES

Le tableau ci-joint dresse la liste des champs retournés par l’API Association, ainsi que les modalités d’utilisation de l’API DAC :

6 JEUX DE TEST

Cette section décrit quelques jeux de test à utiliser pour implémenter l’API Association dans son propre environnement :

Identifiant association Type de données Commentaires/ 421359381 Association active,

Données RNA et SireneDocuments RNA

/ 775675598 Association active,Données RNA, Sirene et DACEtablissements

W952002436 / 529339475 Association dissoute/ 775719792 Association reconnue d’utilité publique (ARUP)Ultérieurement Dirigeants

PatrimoineCoordonnées bancairesDocuments complémentaires

7 MODALITÉS D’UTILISATION DES MÉTHODES POST, DELETE ET PATCH

Les modifications des informations administratives complémentaires s’effectuent en appelant l’API à partir des url suivantes :

- Environnement d’intégration : http://xxx/api/dacs- Environnement de production : https://xxx/api/dacs

auxquelles il convient d’ajouter /dacs, puis l’objet de la modification, l’id de la structure et le cas échéant, l’id de l’objet à modifier ou à supprimer en fonction de l’action souhaitée (POST, PATCH ou DELETE).


Exemple : DELETE http://xxx/api/dacs/agrement/id_structure/id_agrement permet de supprimer l’agrément identifié par {id_agrement} (obtenu par la méthode GET) de l’association identifiée par {id_structure}

Le tableau ci-dessous résume les objets modifiables par quelle(s) action(s) :



18



http://xxx/services/api/dacs/agrement/id_structure/id_agrement


https://xxx/cxf/api/dacs

http://xxx/services/api/dacs

Objet Nom url id POST DELETE PATCHDAC2 association /dacs id_structure OUIDAC établissement /etablissements id_siret OUIRelation d’affiliation à une Fédération, union, réseau

/reseaux_affiliation id_structure OUI OUI OUI

Adhérent personne morale /adherents_personnes_morales id_structure OUI OUIReprésentant légal /representants_legaux id_siret OUI OUI OUIAgrément administratif /agrements id_structure OUI OUI OUIRessources humaines /rhs/<annee> id_siret OUI OUIComptes de résultat et financements

/comptes/<annee> id_siret OUI OUI

Coordonnées bancaires /ribs id_siret OUI OUI OUIDocument administratif /dac_documents id_siret OUI OUI OUI

Chacun de ces objets représente un micro-service qui peut aussi être appelé en GET.

Modalités pour les tests :

Des tests peuvent être effectués facilement en utilisant par exemple l’application POSTMAN : elle est accessible depuis le navigateur Chrome (chrome://apps/).

1) Configurer les environnements :

En haut à droite de « No environnement », cliquer sur l’icône œil : et éditer l’environnement, à paramétrer comme suit :

Environnement d’intégration : Environnement de production :

Les url (host) sont masquées. Elles seront communiquées après instruction de la demande à effectuer par courriel à [email protected].

2) Importer le fichier ci-dessous (bouton « Import » en haut à gauche »).

Ce fichier contient l’ensemble des méthodes et paramètres dont les catégories d’objets apparaissent dans la colonne de gauche.

POSTMAN est alors utilisable pour effectuer des tests en GET, POST, PATCH et DELETE pour les objets identifiés.

7.1 MODIFICATION DES INFORMATIONS COMPLÉMENTAIRES D’UNE ASSOCIATION

2 DAC = données administratives complémentaires



19




Cette méthode permet de modifier la valeur des champs suivants pour une association :

- Le régime de l’association (loi 1901, Alsace-Moselle, autre) : permet de gérer plus facilement les spécificités d’affichage de champs si l’association relève notamment du régime Alsace-Moselle (l’association n’étant dans ce cas pas immatriculée au RNA, mais au greffe local)

- pour les associations d’Alsace-Moselle :o le volume et le folio qui figure au registre local des associations o la date de publication de la création au registre des associationso le tribunal d’instance où est enregistrée l’association

- la date de publication au journal officiel de la reconnaissance d’utilité publique- le domaine d’activité : permet de déclarer un domaine d’activité particulier (exemple : Sport), duquel peuvent

découler des règles de gestion spécifiques dans le front ou le back office- spécialement pour les associations dont le domaine = Sport, le type de structure sportive (comité, ligue ou club)- le champ d’action territorial- l’adresse de gestion- le n° de téléphone - l’email - le site internet- l’accord de publier sur internet les coordonnées de son association (téléphone, adresse de messagerie)- une note

Formats particuliers :

- {id_structure} doit être au choix le n° RNA ou le n° SIREN de l’association à modifier- les dates doivent être saisies au format AAAA-MM-JJ- les valeurs possibles de « identite.regime » sont :

o loi1901o alsaceMoselleo autre

- les valeurs possibles de « identite.type_structure_sportive » sont :o comitéo ligueo club

- les valeurs possibles de « activites.champ_action_territorial » sont :o internationalo nationalo régionalo départementalo local

- Le format de l’adresse de gestion est particulier : il comporte une série de champ :o Complément : \"cplt_3\"o Voie (n°, type et nom de la voie : \"voie\"o Boite postale : \"bp\"o Cedex : \"cedex\"o Code postal : \"cp\"o Commune : \"commune\"o Code Insee : \"code_insee\"o Pays : \"pays\"

- coordonnees.publication_internet est booléen : la valeur « true » indique que l’utilisateur donne son accord pour publier les coordonnées de son association (téléphone, adresse de messagerie)

- Remarque : dans l’url au complet on aura donc deux fois « /dacs » de suite : …/api/dacs/dacs/id_structure



20



- utiliser les méthodes POST et DELETE pour ces données n’a pas de sens, seule la méthode PATCH pourra être exploitée

L’API n’effectuant aucun contrôle, les contrôles sur le caractère obligatoire d’un champ et le format des champs doivent être effectués au moment de la saisie par l’utilisateur.

PATCH /dacs/id_structure[{

"key": "identite.regime","value": "asso1901",

},

{"key": "identite.volume","value": "023",

},

{"key": "identite.folio","value": "412",

},

{"key": "identite.date_pub_registre","value": "2003-10-10"

},

{"key": "identite.tribunal_instance","value": "Tribunal d’instance de Strasbourg",

},

{"key": "identite.date_publication_util_publique","value": "2006-10-10"

},

{"key": "activites.domaine","value": "",

},

{"key": "identite.type_structure_sportive","value": "club",

},

{"key": "activites.champ_action_territorial",



21



"value": "régional"},

{"key": "coordonnees.adresse_gestion","value": "{ \"cplt_3\": \"chez les voisins\", \"voie\": \"26, rue de l’Eglise\", \"bp\": \"BP 3612 \", \"cedex\": \"cedex 304\", \"cp\": \"94300\", \"commune\": \"Vincennes\", \"code_insee\": \"\", \"pays\": \"FRANCE\"}",

},

{"key": "coordonnees.telephone","value": "0123456789"

},

{"key": "coordonnees.courriel","value": "[email protected]"

},

{"key": "coordonnees.site_web","value": "dataasso.fr"

} ,

{"key": "coordonnees.publication_internet","value": "1"

},

{"key": "commentaire.note","value": "blablablo"

}]

7.2 MODIFICATION DES INFORMATIONS COMPLÉMENTAIRES D’UN ÉTABLISSEMENT

Cette méthode permet de modifier la valeur des champs suivants pour tout établissement (siège ou secondaire) :

- le nom (enseigne) de l’établissement- le n° de téléphone de l’établissement- l’email de l’établissement- une note de l’établissement


- l’id de la structure {id_siret} doit être le n° Siret de l’établissement à modifier- le champ « telephone » doit respecter le format d’un n° de téléphone- le champ « courriel » doit respecter le format d’une adresse de messagerie



22



- utiliser les méthodes POST et DELETE pour ces données n’a pas de sens, seul la méthode PATCH pourra être exploitée


PATCH /établissements/id_siret[{

"key":"nom","value": "ALLIANCE DU COEUR – établissement Leblouis"

},

{"key": "telephone","value": "0123456789"

},

{"key": "courriel","value": "[email protected]"

},

{"key": "note","value": "blablablu"

}]

7.3 AJOUT, SUPPRESSION ET MODIFICATION D’UNE RELATION D’AFFILIATION

Ces méthodes permettent à l’association de déclarer les fédérations, unions, réseaux auxquels elle est affiliée.


- L’id de la structure {id_structure} doit être le n° RNA ou n° SIREN de l’association affiliée (celle pour laquelle on déclare une relation d’affiliation).

- L’id de la structure d’affiliation (la structure parente) {id_structure_parente} doit aussi se déclarer via son n° RNA ou son n° SIREN.

- Les données sont le nombre de licenciés sportifs, pour les associations sportives.

7.3.1 AJOUT D’UNE RELATION D’AFFILIATION

Pour en faciliter la déclaration (qui doit renvoyer un identifiant de l’association d’affiliation), il est conseillé d’exploiter le web service permettant d’obtenir les identifiants (n° RNA et n° SIREN) d’une association à partir d’une recherche sur son nom.

POST /reseaux_affiliation/id_structure/id_structure_parente{

"nb_licencies": "42","nb_licencies_h": "12",



23



"nb_licencies_f": "30",}

7.3.2 SUPPRESSION D’UNE RELATION D’AFFILIATION

La suppression de la relation d’affiliation implique de transmettre l’id_rna ou l’id_siren de l’association d’affiliation :

DELETE /reseaux_affiliation/id_structure/id_structure_parente

7.3.3 MODIFICATION D’UNE RELATION D’AFFILIATION

La modification de la relation d’affiliation a pour objet, dans le cas des associations sportives, de modifier le nombre de licenciés. A l’instar du DELETE, le PATCH implique de transmettre l’id_rna ou l’id_siren de l’association d’affiliation :

PATCH /reseaux_affiliation/id_structure/id_structure_parente[{

"key":"nb_licencies","value": "40"

},

{"key":"nb_licencies_h","value": "32"

},

{"key":"nb_licencies_f","value": "8"

}]

7.4 AJOUT ET SUPPRESSION D’UN ADHÉRENT PERSONNE MORALE

Ces méthodes permettent à l’association de déclarer les adhérents personne morale d’une association (autres que des associations). Il n’est possible que d’ajouter ou supprimer un adhérent personne morale.


- Dans les deux cas (POST et DELETE), l’id de la structure {id_structure} doit être le n° RNA ou n° SIREN de l’association affiliée.

- Pour la suppression, il est nécessaire de transmettre l’id de l’adhérent personne moral obtenu par la méthode GET-structure.

7.4.1 AJOUT D’UN ADHÉRENT PERSONNE MORALE

La création s’effectue en déclarant le nom de l’adhérent personne morale :

POST /adherents_personnes_morales/id_structure



24



{"nom": "COMMUNAUTE DE COMMUNES PAYS DU VERMANDOIS","siret": "24020049300031"

}

7.4.2 SUPPRESSION D’UN ADHÉRENT PERSONNE MORALE

La suppression s’effectue en déclarant l’id de l’adhérent personne morale {id_adherentpm} obtenu par la méthode GET-structure (à ne pas confondre avec l’ {id_structure} de l’association à déclarer dans l’url) :

DELETE /adherents_personnes_morales/id_structure/id_adherentpm

7.5 AJOUT, SUPPRESSION ET MODIFICATION D’UNE PERSONNE PHYSIQUE

Ces méthodes permettent à l’association de déclarer, supprimer ou modifier une personne physique de l’association pour une demande de subvention notamment. La saisie de ces informations est nécessaire car la liste des personnes chargées de l’administration de l’association n’est pas disponible à ce jour en tant que champs structurés à ce jour, mais en tant que document.

En plus des coordonnées propres à la personne physique (téléphone et adresse de messagerie), il est possible de décrire par l’intermédiaire de trois booléens :

- Si la personne physique est un représentant légal (dirigeant) de l’association ;- Si la personne physique dispose des droits pour valider les demandes du Compte Engagement Citoyen ;- Si la personne physique souhaite ou non que les informations la concernant soit accessibles sur internet.


- L’id de la structure doit être le n° SIRET, le représentant légal pouvant être celui d’une association (établissement siège) ou d’un établissement secondaire, car pour une demande de subvention formulée par un établissement secondaire, le représentant légal doit être lié à cet établissement.

- Pour la création, il est cependant nécessaire de transmettre à minima les 4 champs obligatoires, figurant en gras ci-dessous.

- Pour la suppression et la modification, il est nécessaire de transmettre l’id du représentant légal {id_representant_legal} obtenu par la méthode GET-structure.

L’API n’effectuant pas de contrôle à ce niveau, les contrôles sur le caractère obligatoire d’un champ et le format des champs doivent être effectués au moment de la saisie par l’utilisateur.

7.5.1 AJOUT D’UN REPRÉSENTANT LÉGAL

La création s’effectue en déclarant entre 4 à 6 champs caractéristiques d’un représentant légal. Les champs notés en gras sont obligatoires dans la transmission des informations :

POST /representants_legaux/id_siret

{"civilite": "M. ", "nom": "R","prenom": "Bob","fonction": "Président","telephone": "0123456789",



25



"courriel": "[email protected]","est_representant_legal": "1","valideur_cec": "1","publication_internet": "1"}

7.5.2 SUPPRESSION D’UN REPRÉSENTANT LÉGAL

La suppression s’effectue en déclarant l’id du représentant légal {id_representant_legal} obtenu par la méthode GET-structure (à ne pas confondre avec le siret de l’établissement à déclarer dans l’url) :

DELETE /representants_legaux/id_siret/id_representant_legal

7.5.3 MODIFICATION D’UN REPRÉSENTANT LÉGAL

La modification d’un représentant légal s’effectue via la méthode PATCH en déclarant l’id du représentant légal {id_representant_legal} obtenu par la méthode GET-structure (à ne pas confondre avec le siret de l’établissement à déclarer dans l’url) et en envoyant les champs modifiés :

PATCH /representants_legaux/id_siret/id_representant_legal[{

"key":"civilite","value": "Mme"

},

{"key":"nom","value": "Momo"

},

{"key":"prenom","value": " Patrick "

},

{"key":"fonction","value": " cheffe"

},

{"key":"telephone","value": "0102111213"

},

{"key":"courriel","value": "[email protected]" ,

}

{"key":"valideur_cec","value": "0"



26



},

{"key":"est_representant_legal","value": "0"

},

{"key":"publication_internet","value": "0"

}]

7.6 AJOUT, SUPPRESSION ET MODIFICATION D’UN AGRÉMENT ADMINISTRATIF

Ces méthodes permettent à l’association de déclarer, supprimer ou modifier un de ses agréments administratifs.


- L’id de la structure doit être le n° RNA ou le n° SIREN.- Le champ « niveau » ne doit avoir que les valeurs suivantes :

o Nationalo Local

- la « date_attribution » doit être transmise au format AAAA-MM-JJ


7.6.1 AJOUT D’UN AGRÉMENT ADMINISTRATIF

La création s’effectue en déclarant entre 1 à 5 champs caractéristiques d’un agrément. Les champs notés en gras sont obligatoires dans la transmission des informations :

POST /agrement/id_structure

{"type": "JEP","numero": "JEP-3256","niveau": "national","attributeur": "DJEPVA","date_attribution": "1998-08-15"}

7.6.2 SUPPRESSION D’UN AGRÉMENT ADMINISTRATIF

La suppression s’effectue en déclarant dans la méthode l’id de l’agrément {id_agrement} à supprimer, obtenu par la méthode GET-structure :

DELETE /agrement/id_structure/id_agrement

7.6.3 MODIFICATION D’UN AGRÉMENT ADMINISTRATIF



27



La modification d’un agrément s’effectue via la méthode PATCH en déclarant la méthode l’id de l’agrément à modifier, obtenu par la méthode GET-structure, et en envoyant les champs modifiés :

PATCH /agrement/id_structure/id_agrement[{

"key":"type","value": "Ecologie"

},

{"key":"numero","value": "BY-099"

},

{"key":"niveau","value": "international"

},

{"key":"attributeur","value": "MEE"

},

{"key":"date_attribution","value": "2014-09-24"

},]

7.7 AJOUT ET MODIFICATION DE RESSOURCES HUMAINES

Ces méthodes permettent à l’association de déclarer ou modifier ses ressources humaines (salariés, adhérents, volontaires, bénévoles…) pour une année : en général on considère qu’ils sont arrêtés au 31/12 d’une année en particulier, sauf pour l’année courante. Les licenciés sportifs, initialement inclus dans les ressources humaines, sont désormais dans les relations d’affiliations (voir section 7.3).

La méthode POST doit être utilisée seulement s’il n’existe aucune donnée pour l’année souhaitée.

La méthode PATCH doit être utilisée pour modifier des données de l’année souhaitée (celle-ci disposant déjà de données propres)

La méthode DELETE n’a pas de sens.


- L’id de la structure doit être le n° Siret. On peut ainsi déclarer des ressources humaines par établissement.- L’annee à laquelle s’appliquent les données de ressources humaines est à déclarer dans l’url de la méthode utilisée.

Elle constitue une partie de la clé.

7.7.1 AJOUT D’UNE ANNÉE DE DONNÉES DE RESSOURCES HUMAINES



28



La « création » d’une année par la méthode POST doit se faire seulement si la méthode GET n’a pas retourné de donnée pour l’année en question. En cas d’absence de données pour une année, les données doivent être déclarées de la manière suivante :

POST /rhs/id_siret/annee

{"nb_adherents": "15","nb_adherents_h": "7","nb_adherents_f": “8”,"nb_benevoles": "366","nb_volontaires": "12","nb_emplois_aides": "2","nb_personnels_detaches": "0","nb_salaries": “3”,"nb_salaries_etpt": “5.5”,"cumul_top_5_salaires": “550 345”}

7.7.2 MODIFICATION DES DONNÉES DE RESSOURCES HUMAINES

Dans le cas où l’API Association retourne des données pour l’année dont l’association souhaite effectuer une modification, la modification s’effectue via la méthode PATCH en déclarant dans l’url l’annee à modifier, obtenue par la méthode GET-structure, et en envoyant les champs modifiés :

PATCH /rhs/id_siret/annee[{

"key":"nb_adherents","value": "150"

},

{"key":"nb_adherents_h","value": "78"

},

{"key":"nb_adherents_f","value": "72"

},

{"key":"nb_benevoles","value": "15420"

},

{"key":"nb_volontaires","value": "3660"

},

{"key":"nb_emplois_aides",



29



"value": "1"},

{"key":"nb_personnels_detaches","value": "1"

},

{"key":"nb_salaries","value": "42"

},

{"key":"nb_salaries_etpt","value": "3"

},

{"key":"cumul_top_5_salaires","value": "5123568"

}]

7.8 AJOUT ET MODIFICATION DES COMPTES DE RÉSULTAT ET FINANCEMENTS PERÇUS

Ces méthodes permettent à un établissement de déclarer ou modifier ses comptes et les financements perçus pour une année en particulier et ce, pour les trois dernières années. Cet objet a été modifié pour être étendu aux établissements dans le cas où un établissement secondaire aurait une comptabilité propre.

La méthode POST doit être utilisée seulement s’il n’existe aucune donnée pour l’année souhaitée.

La méthode PATCH doit être utilisée pour modifier des données pour l’année souhaitée (celle-ci disposant déjà de données propres).

La méthode DELETE n’a pas de sens.


- L’id de la structure doit être le n° Siret.- Il est nécessaire d’indiquer systématiquement dans l’url « annee » qui constitue la clé.

7.8.1 AJOUT D’UNE ANNÉE DE COMPTES DE RÉSULTAT ET FINANCEMENTS PERÇUS

La « création » d’une année par la méthode POST doit se faire seulement si la méthode GET n’a pas retourné de donnée pour l’année en question. En cas d’absence de données pour une année, les données doivent être déclarées de la manière suivante :

POST /comptes/id_siret/annee

{"a_commissaire_aux_comptes": "non","dons": "455000","subv": "103000",



30



"subv_cause": "blablabla","aides_3ans": "1555000","charges": "238500","produits": "138000","resultat": "100500"}

7.8.2 MODIFICATION DES DONNÉES DE COMPTES DE RÉSULTAT ET FINANCEMENTS PERÇUS

Dans le cas où l’API Association retourne des données pour l’année dont l’association souhaite effectuer une modification, la modification s’effectue via la méthode PATCH en déclarant dans l’url l’annee à modifier, obtenue par la méthode GET-structure, et en envoyant les champs modifiés :

PATCH /comptes/id_siret/annee[{

"key":"a_commissaire_aux_comptes","value": "oui"

},

{"key":"dons","value": "5000"

},

{"key":"subv","value": "55000"

},

{"key":"subv_cause","value": "xxx"

},

{"key":"aides_3ans","value": "30000000"

},

{"key":"charges","value": "55200"

},

{"key":"produits","value": "54100"

},

{"key":"resultat","value": "-1100"

}]



31



7.9 AJOUT, SUPPRESSION ET MODIFICATION DE COORDONNÉES BANCAIRES

Ces méthodes permettent à l’association de déclarer, modifier ou supprimer ses coordonnées bancaires. Une association peut disposer de plusieurs coordonnées bancaires. Les coordonnées bancaires sont même spécifiques à un établissement, et un même établissement (même secondaire) peut disposer de plusieurs coordonnées bancaires.


- L’id de la structure doit être le n° Siret- L’iban doit respecter le format attendu.- Le bic doit respecter le format attendu. Le bic doit toujours comporter 11 caractères. S’il n’est formaté que sur 8

caractères, rajouter « XXX » à la fin.


7.9.1 AJOUT D’UN RIB (COORDONNÉES BANCAIRES)

La création s’effectue en déclarant les 5 champs obligatoires qui caractérisent une coordonnée bancaire :

POST /ribs/id_siret

{ "titulaire": "M. POLO", "banque": "LCL", "domiciliation": "chez moi", "iban": "4309 4456 5675 2426", "bic": "CMCCC377XXX"}

7.9.2 SUPPRESSION D’UN RIB (COORDONNÉES BANCAIRES)

La suppression s’effectue en déclarant l’id de la coordonnée bancaire {id_rib} obtenu par la méthode GET-structure :

DELETE /ribs/id_siret/id_rib

7.9.3 MODIFICATION D’UN RIB (COORDONNÉES BANCAIRES)

La modification d’un représentant légal s’effectue via la méthode PATCH en déclarant l’id de la coordonnée bancaire {id_rib} obtenu par la méthode GET-structure et en envoyant les champs modifiés :

PATCH /ribs/id_siret/id_rib[{

"key":"titulaire","value": "JMO"

},

{"key":"banque","value": "Compte populaire"



32



},

{"key":"domiciliation","value": "international"

},

{"key":"iban","value": "FR76 1091 7000 3002 0211 2781 328"

},

{"key":"bic","value": "CPPCM888XXX"

},]

7.10 AJOUT, SUPPRESSION ET MODIFICATION D’UN DOCUMENT ADMINISTRATIF

Ces méthodes permettent au portail dans lequel l’association intègre ses documents d’envoyer leur contenu et leurs caractéristiques. Ces documents sont typés.


- L’id de la structure doit être le n° Siret, de sorte qu’il soit possible de transmettre un document spécifique à un établissement

- Le type doit respecter le format attendu (plusieurs types différents, codés sur 3 caractères).- L’annee ne doit être transmise que pour les documents annuels.- Le contenu du document au format BLOB


7.10.1 AJOUT DE L’ID D’UN DOCUMENT ADMINISTRATIF

La création s’effectue en déclarant les champs (en gras les champs obligatoires) qui caractérisent un document chargé sur le portail (ce dernier étant identifié par « id » attribué par DBAsso) :

POST /dac_documents/id_structure{ "id": "55", "nom": "un sacré document", "commentaire": "ouvrez-le", "type": "BPA", "url": "xxxxx", "time_depot": "20151125", "annee": "2015", "contenu": "UEsDBBQAAAAIAAOAyUoFPFFSXVoaAAwpH…",}

7.10.2 SUPPRESSION DE L’ID D’UN DOCUMENT ADMINISTRATIF



33



La suppression s’effectue en déclarant l’id du document {id_document_dacs} obtenu par la méthode GET-structure :

DELETE /dac_documents/id_structure/id_document_dacs

7.10.3 MODIFICATION DE L’ID D’UN DOCUMENT ADMINISTRATIF

La modification d’un document s’effectue via la méthode PATCH en déclarant l’id du document {id} obtenu par la méthode GET-structure et en envoyant les champs modifiés :

PATCH /dac_documents/id_structure/id [{

"key":"id","value": "56"

},

{"key":"nom","value": "padoque"

},

{"key":"commentaire","value": "rien"

},

{"key":"type","value": "RAR"

},

{"key":"url","value": "Rul/url"

},

{"key":"time_depot","value": "20151126"

},

{"key":"annee","value": "2016"

},

{"key":"contenu","value": "y0wNDA4IEFTUEFNLnBkZgoAIAAAAAAAAQAYAF6DZLMo4dIBXoN…"

}



34



]



35

