openARIA 1.4 documentation

Note

Cette création est mise à disposition selon le Contrat Paternité-Partage des Conditions Initiales à l’Identique 2.0 France disponible en ligne http://creativecommons.org/licenses/by-sa/2.0/fr/ ou par courrier postal à Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.

openARIA est un logiciel libre permettant l’Analyse du Risque Incendie et de l’Accessibilité pour les Établissements Recevant du Public. Il gère le Référentiel des ERP, les visites, les analyses de plan, les décisions, les commissions, les autorités de police et bien plus encore.

Ce document a pour but de guider les utilisateurs et les développeurs dans la prise en main du projet.

Bonne lecture et n’hésitez pas à nous faire part de vos remarques à l’adresse suivante : contact@openmairie.org !

Manuel de l’utilisateur

Manuel de l’utilisateur

Ergonomie

Tableau de bord

Le tableau de bord est composé de plusieurs blocs d’informations appelés widget qui permettent à l’utilisateur de visualiser rapidement des informations transverses.

La disposition des widgets est propre à chaque profil et peut être modifiée très facilement par l’administrateur. Il est donc possible pour les services de modifier la disposition (suppression de widget / déplacement de widget) pour le profil technicien de son service.

Pour conserver une cohérence dans la navigation et un comportement identique dans tous les cas de figure, tous les liens du tableau de bord qui pointent vers un élément pointent vers la fiche de visualisation du dossier d’instruction qui est le cœur de travail du technicien. Les liens qui pointent vers un listing pointent vers un listing accessible également depuis le menu.

Widgets

Widget « Activité du service »

L’objet de ce widget est de présenter les statistiques du service de l’utilisateur.

Widget « Analyses à acter »

L’objet de ce widget est de permettre au rôle « secrétaire » de visualiser les analyses validées et donc à acter (pour lesquelles il faut générer le Procès Verbal). Si le dossier d’instruction lié à l’analyse est clôturé l’analyse n’apparaît pas. Le widget n’apparaît pas si aucune analyse n’est dans ce cas.

Widget « Analyses à valider »

L’objet de ce widget est de permettre au rôle « cadre » de visualiser les analyses terminées et donc à valider. Si le dossier d’instruction lié à l’analyse est clôturé l’analyse n’apparaît pas. Le widget n’apparaît pas si aucune analyse n’est dans ce cas.

Widget « Autorités de police qui n’ont pas été notifiées ou exécutées »

L’objet de ce widget est de permettre de visualiser les autorités de police non notifiées ou exécutées. Le widget n’apparaît pas si aucune autorité de police n’est dans ce cas.

Widget « Convocations exploitants à envoyer »

Ce widget liste les programmations pour lesquelles les envois de convocations aux exploitants sont à effectuer. Le widget n’apparaît pas si aucune programmation n’est dans ce cas.

Widget « Convocations membres à envoyer »

Ce widget liste les programmations arrivant dans moins de 2 semaines et pour lesquelles les envois de convocations aux membres sont à effectuer. Le widget n’apparaît pas si aucune programmation n’est dans ce cas.

Widget « Documents entrants à valider »

Ce widget permet au cadre de savoir combien il a de documents entrants à vérifier et de visualiser la liste des cinq derniers. Un lien permet d’accéder à la liste complète.

Widget « Documents entrants suivis »

Ce widget permet de lister tous les documents entrants pour lesquels le suivi est activé. Les documents entrants sont triés par date butoir.

Widget « Dossiers de coordination à qualifier »

Ce widget affiche les 5 plus anciens dossiers à qualifier, avec un lien permettant d’afficher tous les dossiers à qualifier. (Voir le paragraphe Dossiers à qualifier pour plus d’informations)

Widget « Dossiers de coordination à clôturer »

Ce widget affiche les 5 plus anciens dossiers dont les dossiers d’instruction sont clôturés, avec un lien permettant d’afficher tous les dossiers à clôturer.

Widget « Établissements NPAI »

L’objet de ce widget est de permettre de lister les établissements dont l’adresse de contact est incorrecte afin d’effectuer des recherches hors logiciel. Le widget n’apparaît pas si aucun établissement n’est dans ce cas.

Widget « Mes documents entrants non lus »

Ce widget liste les documents entrants associés à un dossier dont l’utilisateur est identifié comme instructeur et qui est noté comme « non lu » avec un lien vers le dossier en question ainsi qu’un lien qui permet d’accéder au listing de tous les documents entrants non lus de l’utilisateur.

Widget « Mes dossiers en réunion »

Ce widget liste tous les dossiers dont l’utilisateur connecté est l’instructeur et qui passent en réunion dans les 30 jours suivant la date du jour avec un lien vers le dossier en question. Le listing contient une rupture par réunion (la date et le libellé du type de réunion sont affichés), puis par catégorie de passage de la réunion en question (le libellé de la catégorie est affiché).

Widget « Mes dossiers plans »

Ce widget liste les 5 plus récents dossiers plans dont l’utilisateur connecté est identifié comme instructeur avec un lien vers le dossier en question ainsi qu’un lien qui permet d’accéder au listing de tous les dossiers plans de l’utilisateur.

Widget « Mes dossiers visites »

Ce widget liste les 5 plus anciens dossiers visites dont l’utilisateur connecté est identifié comme instructeur avec un lien vers le dossier en question ainsi qu’un lien qui permet d’accéder au listing de tous les dossiers visites de l’utilisateur.

Widget « Mes infos »

Ce widget a été créé spécifiquement pour des besoins de test de l’application. Il permet d’afficher les informations de l’utilisateur actuellement connecté. En effet, pour faciliter les tests avec différents utilisateurs, différents profils et différents services, il est plus facile d’avoir un widget qui rassemble ces informations sur le tableau de bord.

Widget « Mes messages »

Ce widget indique le nombre de messages non lus pour l’utilisateur connecté. Une liste présente les cinq derniers messages non lus arrivés. Un lien permet d’accéder à une liste complète des messages non lus de l’utilisateur (voir Mes non lus). Un clic sur le message permet d’accéder à la fiche de visualisation du message dans le contexte du dossier d’instruction si l’utilisateur est TECHNICIEN et dans le contexte du dossier de coordination si l’utilisateur est CADRE.

Widget « Mes visites à réaliser »

Ce widget liste les 5 prochaines visites à réaliser par l’utilisateur avec un lien vers le dossier en question ainsi qu’un lien qui permet d’accéder au listing de toutes les prochaines visites de l’utilisateur. L’état de la visite permet au technicien de savoir qu’une visite qui lui avait été programmée a été annulée.

Widget « Mon activité »

Ce widget représente les chiffres statistiques définis dans la section Pilotage concernant l’utilisateur connecté.

Widget « Profil non configuré »

Ce widget permet d’informer l’utilisateur que son profil n’est pas encore configuré correctement et qu’il doit prévenir son administrateur pour que ce soit le cas.

Widget « Programmations à valider »

Principalement destiné au cadre, ce widget permet d’afficher toutes les programmations qui ont été finalisées et qui sont donc à valider. Le widget n’apparaît pas si aucune programmation n’est dans ce cas.

Widget « Programmations urgentes »

Ce widget liste les programmations arrivant dans moins de 3 semaines pour lesquelles les envois de convocations ne sont pas terminés. Le widget n’apparaît pas si aucune programmation n’est dans ce cas.

Widget « Documents générés à éditer »

Ce widget permet au cadre et à la secretaire de savoir combien il a de documents générés à éditer, c’est-à-dire finalisés et dont les dates de suivi (date d’envoi et de retour pour signature et AR) ne sont pas renseignées. Un lien permet d’accéder à la liste complète (voir Depuis le menu « À Éditer »). Le widget n’apparaît pas si aucun document généré n’est dans ce cas.

Widget « Documents générés en attente de signature »

Ce widget permet au cadre et à la secretaire de savoir combien il a de documents générés en attente de signature, c’est-à-dire finalisés, dont la date d’envoi en signature est saisie et dont les dates d’envoi AR et de retour signature et AR ne sont pas renseignées. Un lien permet d’accéder à la liste complète (voir Depuis le menu « Attente Signature »). Le widget n’apparaît pas si aucun document généré n’est dans ce cas.

Widget « Documents générés en attente de retour AR »

Ce widget permet au cadre et à la secretaire de savoir combien il a de documents générés en attente de retour AR, c’est-à-dire finalisés, dont la date de retour signature ou la date d’envoi AR sont saisies et dont la date de retour AR n’est pas renseignée. Un lien permet d’accéder à la liste complète (voir Depuis le menu « Attente Retour AR »). Le widget n’apparaît pas si aucun document généré n’est dans ce cas.

Rubrique « Établissements »

La rubrique « Établissements » contient les accès aux établissements et unités d’accessibilité.

Les établissements

Les listings des établissements

Chacun des deux listings permet une recherche avancée complète sur plusieurs critères.

Lorsqu’un Système d’Information Géographique est paramétré, chaque ligne des listings d’établissements contient un icône en forme de Terre. Celui-ci permet d’être redirigé sur le SIG avec la vue centrée sur l’établissement correspondant à cette ligne.

Depuis le menu « Référentiel ERP »

Liste tous les établissements qui constituent le référentiel officiel des ERP.

Lorsqu’un Système d’Information Géographique est paramétré, un icône en forme de Terre au-dessus du listing permet d’être redirigé vers le SIG et de consulter la sélection actuelle d’établissements. S’il n’y a pas eu de recherche avancée, le bouton redirige vers la couche des établissements sur le SIG.

Depuis le menu « Tous les établissements »

Liste tous les établissements ERP, les référentiels et les autres.

Lorsqu’un Système d’Information Géographique est paramétré, un icône en forme de Terre au-dessus du listing permet d’être redirigé vers le SIG et de consulter la sélection actuelle d’établissements. S’il n’y a pas eu de recherche avancée, le bouton redirige vers la couche des établissements sur le SIG.

Ajouter un établissement

Il est possible d’ajouter un établissement depuis les deux listings, soit depuis le formulaire d’ajout ou de modification d’un dossier de coordination. Dans chaque cas le formulaire est identique.

Géolocalisation automatique

Lorsqu’un Système d’Information Géographique est paramétré, openARIA va tenter de géolocaliser automatiquement l’établissement lors de sa création. Cette géolocalisation se fait sur la base de l’adresse, des parcelles et du numéro de dossier ADS qui ont été renseignés.

Si l’établissement a été géolocalisé automatiquement sur le SIG grâce aux informations renseignées, le message suivant apparaît, en indiquant la précision de la géolocalisation.

Si l’établissement n’a pas pû être géolocalisé automatiquement, un message est affiché, qui contient un lien permettant à l’utilisateur de dessiner manuellement l’établissement sur le SIG.

Une fois ce dessin manuel effectué sur le SIG, il faut faut lancer l’action de géolocalisation depuis la fiche de l’établissement créé pour valider le dessin manuel. En cas de succès, un message de validation apparaît, en indiquant la précision de la géolocalisation.

Si l’établissement existe déjà sur le SIG, un message indique à l’utilisateur que celui-ci a déjà été géolocalisé.

La fiche d’un établissement

Lorsqu’un Système d’Information Géographique est paramétré, les icônes en forme de Terre présents dans la fiche permettent d’être redirigé sur le SIG avec la vue centrée sur l’élément choisi :

• si l’établissement a été géolocalisé, l’icône dans le champ « Géolocalisé » permet de visualiser l’établissement sur le SIG
• si des références cadastrales ont été renseignées, l’icône dans le champ références cadastrales permet de visualiser ces parcelles sur le SIG.

Les ERP référentiels

Les ERP référentiel officiel font l’objet de visites périodiques obligatoire suivant leur type et catégorie (les ERP de type Plein Air n’ont pas de visite périodique).

La mise à jour des données des ERP référentiels se fait uniquement par une décision de procès-verbal.

Les ERP autres que référentiels

Les données des ERP autres que référentiel peuvent être mises à jour sans que cela se passe par une décision.

Ouverture / Fermeture d’un ERP

L’ouverture et la fermeture d’un ERP référentiel se fait depuis un arrêté. Pour les autres ERP il est possible de passer par le formulaire.

En cas d’extrême urgence, l’administrateur peut également modifier le statut d’ouverture d’un ERP référentiel.

Gestion de l’exploitant et des mandataires

L’exploitant est le responsable unique de l’établissement, de ce fait il peut être ajouté seulement depuis la fiche de l’établissement. La fiche de l’exploitant est visible depuis l’onglet « Contacts » de l’établissement, il est possible de le modifier de cet endroit. Une synchronisation se fera entre les données des deux enregistrements.

Il possible d’ajouter d’autres contacts, de type autre qu’exploitant. Ceux-ci seront visible au moyen de l’onglet des contacts de l’établissement.

Géolocaliser un établissement

Si un SIG a été paramétré et que l’établissement n’a pas déjà été géolocalisé, une action dans le portail d’actions contextuelles permet de le géolocaliser sur le SIG.

Si l’établissement a été géolocalisé automatiquement sur le SIG grâce aux informations renseignées, le message suivant apparaîtra, en indiquant la précision de la géolocalisation.

Si ces informations ne permettent pas de géolocaliser automatiquement l’établissement, un message sera affiché, qui contiendra un lien permettant à l’utilisateur de dessiner manuellement l’établissement sur le SIG.

Une fois ce dessin manuel effectué sur le SIG, il faut une nouvelle fois lancer l’action de géolocalisation du portail d’actions contextuelles pour valider le dessin manuel. En cas de succès, un message de validation apparaît.

Si l’établissement existe déjà sur le SIG, un message indique à l’utilisateur que celui-ci a déjà été géolocalisé.

Récupérer les propriétaires de parcelles

Si un SIG a été paramétré et que les références cadastrales sont renseignées, une action sur le champ des références cadastrales permet de récupérer la liste des propriétaires par parcelles.

L’action ouvre un overlay nommé « Liste des propriétaires ».

Si les parcelles renseignées ont un ou plusieurs propriétaires, une liste est présentée à l’utilisateur.

Il se peut que le SIG ne récupère aucun propriétaires.

En cas d’erreur de la part du SIG, une erreur est affichée à l’utilisateur.

Dans le cas du retour d’aucun ou de plusieurs propriétaires, il est possible d’ajouter un contact sur l’établissement directement depuis cette interface en cliquant sur le bouton d’ajout d’un contact.

Le formulaire d’ajout d’un contact apparaît à coté de la liste des propriétaires pour faciliter les copier-coller.

Les boutons de retour permettent de fermer le formulaire d’ajout d’un contact tout en gardant la liste des propriétaires.

Le bouton de fermeture situé en dessous de la liste des propriétaires permet de fermer la fenêtre entière même si le formulaire d’ajout d’un contact est toujours ouvert.

Archiver un établissement

Les établissements peuvent être archivés. Ils n’apparaitront plus dans le listing par défaut.

Un établissement archivé à la possiblité d’être désarchivé.

Lien avec le référentiel des voies

Les voies sont récupérées automatiquement depuis le référentiel officiel grâce à un processus quotidien qui récupérera le fichier de voies actualisées du référentiel et mettra à jour la table des voies dans OpenARIA. Un champ de complétion automatique, avec un affichage des voies au fur et à mesure de la frappe, est utilisé pour la sélection de la voie. Les arrondissements seront alors filtrés par rapport à ces voies.

Les voies sont utilisées lors de la saisie des adresses, afin d’éviter toute erreur de saisie. Le changement de libellé de voie sera répercuté automatiquement sur les établissements. Les voies qui viennent du référentiel et n’existent plus seront désactivées et ne seront plus disponibles pour les nouvelles saisies.

Lien avec le référentiel patrimoine

La référence patrimoine ne sera affichée que si le statut juridique de l’établissement est « ville » et que l’option est activée. Les références patrimoines sont obtenu à partir des références de parcelles.

Le fonctionnement est le suivant :

• suite à la saisie des références cadastrales, l’utilisateur disposera d’une action permettant de rechercher la référence patrimoine,
• cette action déclenchera un web service vers le référentiel patrimoine,
• le web service répondra avec une liste d’éléments de patrimoine,
• l’utilisateur sélectionnera les éléments qui sont pertinent,
• les références patrimoines seront stockées au sein de la fiche de l’établissement.

Onglet Contraintes

Liste

Les contraintes affichées dans le tableau sont classées par groupe et sous-groupe, et éventuellement par le numéro d’ordre d’affichage si elles en possèdent un. Chacune dispose de boutons permettant de la consulter, modifier et supprimer. En sus du tableau deux liens permettent d’ajouter et récupérer des contraintes.

Formulaire

Seul le texte complété est affiché et modifiable. Si la contrainte a été récupérée depuis le référentiel alors une action permet de la démarquer.

Ajout

On peut ajouter des contraintes du paramétrage d’openARIA. Seules les actives sont proposées (c’est à dire les archivées sont masquées). Ajouter une contrainte synchronisée avec le référentiel SIG aura le même comportement qu’ajouter une contrainte créée manuellement : elle ne sera pas marquée comme récupérée.

Récupération

L’option SIG doit être activée pour bénéficier de cette fonctionnalité. Selon les références cadastrales de l’établissement, openARIA interroge le référentiel SIG pour récupérer les contraintes applicables à ces parcelles. Si le logiciel ne dispose pas des dites contraintes, il proposera de les synchroniser. Sinon, il ajoutera automatiquement ces contraintes à l’établissement (ou les mettra à jour si elles étaient déjà appliquées). Le texte complété d’une contrainte récupérée est celui du référentiel SIG éventuellement concaténé au texte surchargé si ce dernier est défini dans le paramétrage. Ce texte sera toujours écrasé lors d’une récupération : vous devez démarquer la contrainte si vous ne souhaitez pas que cela soit le cas.

Éditions

Lors de la rédaction des lettres-types vous pouvez afficher les contraintes de l’établissement en appelant la variable de substitution &contraintes_etab. Cette dernière est remplacée par une liste à puces de toutes les contraintes, classées par groupe et sous-groupe.

• Pour un affichage à plat, sans puce ni groupe ni sous-groupe, appelez &contraintes_etab(affichage_sans_arborescence=t).
• Pour filtrer par groupe(s) appelez &contraintes_etab(liste_groupe=g1). Si plusieurs séparez par une virgule sans espace.
• Pour filtrer par sous-groupe(s) appelez &contraintes_etab(liste_ssgroupe=sg1,sg2). Si plusieurs séparez par une virgule sans espace.

Note

• Les trois paramètres sont optionnels et cumulables : séparez les par un point-virgule sans espace. Ex. : &contraintes_etab(liste_groupe=g1;affichage_sans_arborescence=t).
• La même fonctionnalité est disponible pour les dossiers de coordination : la variable est &contraintes_dc.
• S’il n’y a pas de contrainte et ce quelle que soit la raison (aucun établissement rattaché au dossier de coordination, aucune contrainte appliquée) la variable de substitution est tout de même supprimée lors de l’édition.

Onglet UA

Cet onglet présente un écran permettant d’accéder à trois listings :

• un listing des UA validées
• un listing des UA en projet
• un listing des UA archivées

Au clic sur l’onglet UA, on accède par défaut au listing des UA validées.

Listing des UA validées

Une action d’ajout d’une UA est disponible depuis ce listing. Un lien représenté par un plus vert permet d’accéder au formulaire d’ajout d’une UA.

Un clic sur chaque ligne du listing permet d’accéder à la fiche de visualisation d’une UA.

Le tableau comporte les colonnes suivantes :

• « libellé » : c’est le libellé de l’UA qui permet de l’identifier parmi les autres UA de l’établissement.
• « acc. auditif » : information sur l’accessibilité au handicap auditif de l’UA. Les valeurs possibles sont : « Oui » / « Non » / « » (vide).
• « acc. mental » : information sur l’accessibilité au handicap mental de l’UA. Les valeurs possibles sont : « Oui » / « Non » / « » (vide).
• « acc. physique » : information sur l’accessibilité au handicap physique de l’UA. Les valeurs possibles sont : « Oui » / « Non » / « » (vide).
• « acc. visuel » : information sur l’accessibilité au handicap visuel de l’UA. Les valeurs possibles sont : « Oui » / « Non » / « » (vide).
• « dérogation » : information indiquant si l’UA possède une dérogation ou non. Les deux valeurs possibles sont : « Oui » et « » (vide).

Listing des UA en projet

Aucune action d’ajout d’une UA n’est possible depuis ce listing.

Un clic sur chaque ligne du listing permet d’accéder à la fiche de visualisation d’une UA.

Le tableau comporte les colonnes suivantes :

• « libellé » : c’est le libellé de l’UA qui permet de l’identifier parmi les autres UA de l’établissement.
• « acc. auditif » : information sur l’accessibilité au handicap auditif de l’UA. Les valeurs possibles sont : « Oui » / « Non » / « » (vide).
• « acc. mental » : information sur l’accessibilité au handicap mental de l’UA. Les valeurs possibles sont : « Oui » / « Non » / « » (vide).
• « acc. physique » : information sur l’accessibilité au handicap physique de l’UA. Les valeurs possibles sont : « Oui » / « Non » / « » (vide).
• « acc. visuel » : information sur l’accessibilité au handicap visuel de l’UA. Les valeurs possibles sont : « Oui » / « Non » / « » (vide).
• « dérogation » : information indiquant si l’UA possède une dérogation ou non. Les deux valeurs possibles sont : « Oui » et « » (vide).

Listing des UA archivés

Aucune action d’ajout d’une UA n’est possible depuis ce listing.

Un clic sur chaque ligne du listing permet d’accéder à la fiche de visualisation d’une UA.

Le tableau comporte les colonnes suivantes :

• « libellé » : c’est le libellé de l’UA qui permet de l’identifier parmi les autres UA de l’établissement.
• « acc. auditif » : information sur l’accessibilité au handicap auditif de l’UA. Les valeurs possibles sont : « Oui » / « Non » / « » (vide).
• « acc. mental » : information sur l’accessibilité au handicap mental de l’UA. Les valeurs possibles sont : « Oui » / « Non » / « » (vide).
• « acc. physique » : information sur l’accessibilité au handicap physique de l’UA. Les valeurs possibles sont : « Oui » / « Non » / « » (vide).
• « acc. visuel » : information sur l’accessibilité au handicap visuel de l’UA. Les valeurs possibles sont : « Oui » / « Non » / « » (vide).
• « dérogation » : information indiquant si l’UA possède une dérogation ou non. Les deux valeurs possibles sont : « Oui » et « » (vide).
• « état » : c’est l’état de l’UA. Les deux valeurs possibles sont : « en projet » et « validé ».

Onglet Documents Entrants

L’onglet « Document Entrants » sur la fiche d’un établissement affiche tous ses documents entrants liés (ainsi que ceux éventuellement liés aux dossiers d’instruction et aux dossiers d’instruction rattachés à l’établissement). Les informations présentées sont :

• le nom du document,
• le type du document (acte, courrier de l’explotant, …),
• la date de création du document,
• la date de réception du document,
• la date d’émission du document,
• la date butoir du document,
• le statut du document (en cours, qualifié, …).

Les unités d’accessibilité (UA)

Les unités d’accessibilité (UA) permettent de découper les établissements en plus petites unités au sens de l’accessibilité. Ces unités ont vocation à stocker les données techniques particulières à cette unité au sein de l’établissement.

Le listing des UA

Ce listing est un tableau qui fait apparaître toutes les UA qui ne sont pas archivées. Une recherche avancée permet de filtrer les UA qui apparaissent dans le listing.

Aucune action d’ajout d’une UA n’est possible depuis ce listing.

Un clic sur chaque ligne du listing permet d’accéder à la fiche de visualisation d’une UA.

Le tableau comporte les colonnes suivantes :

• « libellé » : c’est le libellé de l’UA qui permet de l’identifier parmi les autres UA de l’établissement
• « établissement » : même chose que pour le reste des listings
• « adresse » : même chose que pour le reste des listings
• « accessible » : les quatre informations sur l’accessibilité de l’UA sont concaténées dans la même cellule du tableau (auditif : « Oui » / « Non » / « » (vide), mental : « Oui » / « Non » / « » (vide), physique : « Oui » / « Non » / « » (vide), visuel : « Oui » / « Non » / « » (vide))
• « état » : c’est l’état de l’UA. Les deux valeurs possibles sont : « en projet » et « validé »

Lorsqu’un Système d’Information Géographique est paramétré, les icônes en forme de Terre de chaque ligne du tableau permettent d’être redirigé sur le SIG avec la vue centrée sur l’établissement lié à cette UA.

La recherche avancée des UA

La recherche avancée permet de filtrer les UA qui apparaissent dans le listing sur les critères suivants :

• « Libellé » : texte libre sur le libellé de l’UA.
• « Établissement » : texte libre sur le code et le libellé de l’établissement. Identique au critère de recherche du même nom dans les recherches avancées des écrans de listing de dossiers.
• « Numéro » : texte libre. Identique au critère de recherche du même nom dans les recherches avancées des écrans de listing de dossiers.
• « Voie » : texte libre. Identique au critère de recherche du même nom dans les recherches avancées des écrans de listing de dossiers.
• « Arrondissement » : liste à choix sur l’arrondissement de l’établissement (valeurs : « 1er », « 2ème », … Ce sont les valeurs disponibles dans le paramétrage des arrondissements ). Identique au critère de recherche du même nom dans les recherches avancées des écrans de listing de dossiers. Si aucune sélection « Choisir », ce critère n’applique aucun filtre sur le listing.
• « État » : liste à choix sur l’état de l’UA (valeurs : « en projet », « validé »). Si aucune sélection « Choisir », ce critère n’applique aucun filtre sur le listing.
• « Accessible auditif » : liste à choix sur l’information sur l’accessibilité au handicap auditif de l’UA (valeurs : « Oui », « Non »). Si aucune sélection « Choisir », ce critère n’applique aucun filtre sur le listing.
• « Accessible mental » : liste à choix sur l’information sur l’accessibilité au handicap mental de l’UA (valeurs : « Oui », « Non »). Si aucune sélection « Choisir », ce critère n’applique aucun filtre sur le listing.
• « Accessible physique » : liste à choix sur l’information sur l’accessibilité au handicap physique de l’UA (valeurs : « Oui », « Non »). Si aucune sélection « Choisir », ce critère n’applique aucun filtre sur le listing.
• « Accessible visuel » : liste à choix sur l’information sur l’accessibilité au handicap visuel de l’UA (valeurs : « Oui », « Non »). Si aucune sélection « Choisir », ce critère n’applique aucun filtre sur le listing.

La recherche avancée affiche les champs de recherche les uns à la suite des autres sans possibilité de regroupement.

La fiche d’une UA

Lorsqu’un Système d’Information Géographique est paramétré et que l’établissement lié à cette UA a été géolocalisé, l’icône en forme de Terre permet d’être redirigé sur le SIG avec la vue centrée sur l’établissement lié.

Rubrique « Dossiers »

La rubrique « Dossiers » est divisée en catégories :

• DC (Coordination) : il est possible pour un technicien depuis le DI ou l’établissement d’accéder à des écrans de DC, il a donc été nécessaire d’ajouter une entrée de menu à cet effet, pour qu’elle soit disponible et sélectionnée sur cet écran afin de conserver une navigation cohérente.
• DI (Instruction) : catégorie principale dont les entrées sont sélectionnées lors d’accès aux écran de DI.
• Visites : catégorie nécessaire au listing du widget « mes visites à réaliser »
• Documents entrants : catégorie nécessaire au listing du widget « mes documents entrants non lus »
• Autorité de police : catégorie nécessaire au listing du widget « Autorités de police qui n’ont pas été notifiées ou exécutées »

DC (Dossiers de Coordination)

Les listings de DC

Lorsqu’un Système d’Information Géographique est paramétré, chaque ligne des listings de dossiers de coordination contient un icône en forme de Terre. Celui-ci permet d’être redirigé sur le SIG avec la vue centrée sur le dossier de coordination correspondant à cette ligne.

Dossiers à qualifier

(Dossiers ‣ DC (Coordination) ‣ Dossiers à qualifier)

Ce listing présente les dossiers de coordination à qualifier par ordre alphabétique du libellé du dc.

Dans ce listing (comme dans le listing du widget Widget « Dossiers de coordination à qualifier »), trois couleurs permettent de distinguer les éléments suivants :

• blanc ou gris : un dc dont la date de demande est de moins de 15 jours et sur lequel le marqueur dépôt de pièce n’est pas activé
• vert : un dc dont la date de demande est de moins de 15 jours et sur lequel le marqueur dépôt de pièce est activé
• rouge : un dc dont la date de demande est de plus de 15 jours

Le marqueur dépôt de pièce est activé en cas de réception d’un message du référentiel ADS sur le dossier de coordination en question ([113](Échange ADS → ERP) Ajout d’une nouvelle pièce numérisée).

L’administrateur peut modifier la limite de 15 jours via l’option dc_a_qualifier_redlimit dans Paramètres.

Tous les dossiers

(Dossiers ‣ DC (Coordination) ‣ Tous les dossiers)

Ce listing présente tous les dossiers de coordination.

Lorsqu’un Système d’Information Géographique est paramétré, un icône en forme de Terre au-dessus du listing permet d’être redirigé vers le SIG et de consulter la sélection actuelle de dossiers de coordination. S’il n’y a pas eu de recherche avancée, le bouton redirige vers la couche des dossiers de coordination sur le SIG.

Ajouter un nouveau DC

(Dossiers ‣ DC (Coordination) ‣ Nouveau dossier)

Cette entrée de menu permet d’accéder directement au formulaire d’ajout d’un dossier de coordination.

Les types de dossier de coordination ont un paramétrage qui permet de remplir automatiquement certains champs du formulaire :

• la case à cocher de la qualification,
• la case à cocher du dossier d’instruction sécurité,
• la case à cocher du dossier d’instruction accessibilité.

La case à cocher « À qualifier » définit si un dossier doit être qualifié ou non.

Lorsqu’un Système d’Information Géographique est paramétré, openARIA va tenter de géolocaliser automatiquement le dossier de coordination lors de sa création. Cette géolocalisation se fait sur la base de l’adresse, des parcelles et du numéro de dossier ADS qui ont été renseignés.

Si le dossier a été géolocalisé automatiquement sur le SIG grâce aux informations renseignées, le message suivant apparaîtra, en indiquant la précision de la géolocalisation.

Si le dossier n’a pas pû être géolocalisé automatiquement, le message de validation contient un lien, qui permet à l’utilisateur de dessiner manuellement le dossier de coordination sur le SIG.

Une fois ce dessin manuel effectué sur le SIG, il faut faut lancer l’action de géolocalisation depuis la fiche du dossier créé pour valider le dessin manuel. En cas de succès, un message de validation apparaîtra, en indiquant la précision de la géolocalisation.

Si le dossier existe déjà sur le SIG, un message indique à l’utilisateur que ce dossier a déjà été géolocalisé.

Certains types de dossiers de coordination peuvent ne pas être géolocalisables. Dans ce cas, le message de validation lors de la création du dossier précise que le dossier n’est pas géolocalisable.

La fiche du dossier de coordination (DC)

Lorsqu’un Système d’Information Géographique est paramétré, les icônes en forme de Terre présents dans la fiche permettent d’être redirigé sur le SIG avec la vue centrée sur l’élément choisi :

• si le dossier de coordination a été géolocalisé, l’icône dans le champ « Géolocalisé » permet de visualiser le dossier sur le SIG.
• si un établissement est lié au dossier, on peut le visualiser sur le SIG en cliquant sur l’icône à côté du nom de l’établissement.
• si des références cadastrales ont été renseignées, l’icône dans le champ références cadastrales permet de visualiser ces parcelles sur le SIG.

Activer/Désactiver l’enjeu ERP

Cette action permet d’activer/ de désactiver le caractère “à enjeu ERP” d’un dossier de coordination c’est-à-dire qu’une attention particulière doit y être apportée.

Si l’option est activée et que les critères du déclencheur sont remplis, un message de notification transmet l’information au référentiel ADS ([207](Échange ERP → ADS) Dossier PC/ERP Notification de dossier à enjeux ERP).

L’information est visible sur la fiche de visualisation du DC :

L’information est visible également sur la fiche de visualisation du DI dans le bloc d’informations du dossier de coordination :

L’information est visible uniquement si le dossier est marqué comme à enjeu ERP sinon l’information n’est pas affichée du tout.

Connexion avec le référentiel ADS

Dans le contexte de l’interface avec le référentiel ADS, il est nécessaire d’identifier les dossiers qui sont connectés avec ce référentiel afin d’éviter de transmettre des messages de réponse à des dossiers non initialisés en ce sens. Lorsqu’un dossier de coordination est créé dans openARIA suite à la réception d’une notification du référentiel ADS, il est noté comme connecté avec le référentiel ADS. Aucune action ne permet à l’utilisateur de modifier ce marqueur.

L’information est visible sur la fiche de visualisation du DC :

L’information est visible également sur la fiche de visualisation du DI dans le bloc d’informations urbanisme :

L’information est visible uniquement si le dossier est connecté au référentiel ADS sinon l’information n’est pas affichée du tout.

Les champs « dossier d’autorisation ADS » et « dossier d’instruction ADS »

Dans le contexte de l’interface avec le référentiel ADS, le dossier de coordination porte les champs « dossier d’autorisation ADS » et « dossier d’instruction ADS ». Ces deux champs ont des comportements différents en fonction du contexte.

Cas d’un DC non connecté au référentiel ADS

Ces deux champs sont modifiables par l’utilisateur qui a le droit de modifier le DC. Lors de la validation du formulaire, si l’option “référentiel ADS” est activée alors on vérifie si les valeurs saisies existent dans le référentiel ADS. Si elles n’existent pas on indique à l’utilisateur que les dossiers n’existent pas. La valeur saisie doit être la référence ADS sans espace.

Cas d’un DC connecté au référentiel ADS

Ces deux champs sont remplis par le référentiel ADS et non modifiables.

Lien vers openADS sur le champ « dossier d’autorisation ADS »

Si l’option “référentiel ADS” est activée et qu’une valeur est présente dans le champ « dossier d’autorisation ADS » alors un lien apparaît à côté de la valeur et permet lors du clic sur ce lien d’ouvrir une nouvelle fenêtre vers la fiche du dossier d’autorisation directement dans openADS.

Le lien est disponible sur la fiche de visualisation du DC :

Le lien est disponible également sur la fiche de visualisation du DI :

Géolocaliser un dossier de coordination

Si un SIG a été paramétré et que le type du dossier en question est géolocalisable, et si le dossier de coordination n’a pas déjà été géolocalisé, alors une action dans le portail d’actions contextuelles permet de le géolocaliser sur le SIG.

Si l’établissement a été géolocalisé automatiquement sur le SIG grâce aux informations renseignées, le message suivant apparaît, en indiquant la précision de la géolocalisation.

Si le dossier de coordination n’a pas pû être géolocalisé automatiquement, un message est affiché, qui contient un lien permettant à l’utilisateur de dessiner manuellement le dossier sur le SIG.

Une fois ce dessin manuel effectué sur le SIG, il faut lancer l’action de géolocalisation depuis la fiche du dossier de coordination créé pour valider le dessin manuel. En cas de succès, un message de validation apparaît, en indiquant la précision de la géolocalisation.

Si le dossier de coordination existe déjà sur le SIG, un message indique à l’utilisateur que celui-ci a déjà été géolocalisé.

Récupérer les propriétaires de parcelles

Si un SIG a été paramétré et que les références cadastrales sont renseignées, une action sur le champ des références cadastrales permet de récupérer la liste des propriétaires par parcelles.

L’action ouvre un overlay nommé « Liste des propriétaires ».

Si les parcelles renseignées ont un ou plusieurs propriétaires, une liste est présentée à l’utilisateur.

Il se peut que le SIG ne récupère aucun propriétaires.

En cas d’erreur de la part du SIG, une erreur est affichée à l’utilisateur.

Dans le cas du retour d’aucun ou de plusieurs propriétaires, il est possible d’ajouter un contact sur le dossier de coordination directement depuis cette interface en cliquant sur le bouton d’ajout d’un contact.

Le formulaire d’ajout d’un contact apparaît à coté de la liste des propriétaires pour faciliter les copier-coller.

Les boutons de retour permettent de fermer le formulaire d’ajout d’un contact tout en gardant la liste des propriétaires.

Le bouton de fermeture situé en dessous de la liste des propriétaires permet de fermer la fenêtre entière même si le formulaire d’ajout d’un contact est toujours ouvert.

Onglet Contraintes

La fonctionnalité est identique à l”application des contraintes aux établissements.

Onglet Contacts

Onglet DC Fils

Cet onglet permet d’afficher tous les dossiers de coordination sur lesquels le dossier de coordination sur lequel on se trouve a été sélectionné comme dossier de coordination parent.

Onglet Documents Entrants

Listing standard (ou interne)

L’onglet « Document Entrants » sur la fiche d’un dossier de coordination affiche tous ses documents entrants liés (ainsi que ceux éventuellement liés aux dossiers d’instruction). Les informations présentées sont :

• le nom du document,
• le type du document (acte, courrier de l’explotant, …),
• la date de création du document,
• la date de réception du document,
• la date d’émission du document,
• la date butoir du document,
• le statut du document (en cours, qualifié, …).

Listing guichet unique

Dans le cas où le module “swrod” (Documents du guichet unique en lecture seule) est activé, l’onglet peut posséder un affichage différent si le DC contient une référence vers un dossier ADS. Dans ce cas, l’onglet “Interne” présente les mêmes informations et actions que l’onglet “Documents Entrants” standard et l’onglet “Guichet Unique” présente une vue en lecture seule des documents concernant le dossier ADS du DC.

Onglet Documents générés

Onglet AP

L’autorité de police c’est l’autorité du maire, elle n’est pas rattachée directement à un service ou à une Commission. Cependant, le Maire (ou un délégué) se base sur l’avis de la Commission pour prendre une décision d’autorité de Police et pour ce faire il profite des réunions de Commission pour discuter des dossiers en autorité de police.

L’autorité de Police, c’est le pouvoir du Maire qui, en fonction de l’avis d’une commission, demande la mise en règle d’un établissement. Il peut y avoir zéro, une ou plusieurs décisions d’autorité de Police qui sont prises lors d’un passage en commission. Une décision d’autorité de Police est composée principalement de trois informations : une décision, un délai, un motif. Ces décisions d’autorité de police sont liées à un courrier ou à plusieurs courriers permettant de notifier ces décisions. L’autorité de Police se trouve sur le dossier de coordination.

Onglet Messages

Voir le paragraphe Onglet Messages.

Qualification d’un dossier de coordination

La qualification d’un dossier de coordination peut se faire depuis deux écrans, depuis le formulaire d’ajout d’un dossier de coordination ou depuis son formulaire de modification.

Lorsqu’un Système d’Information Géographique est paramétré et que les références cadastrales sont renseignées, il est possible de récupérer la liste des établissements proches géographiquement depuis le champ de liaison avec un établissement.

Pour une sélection plus aisée des champs permettent de filtrer la liste des établissements proches :

• le champ Limite permet de limiter le total de résultats à 10, 20, 30, 40 ou 50 établissements ;
• le champ Nature permet d’afficher seulement les établissements de la nature sélectionnée.

En cliquant sur l’un des établissements celui-ci sera sélectionné pour la liaison avec le dossier de coordination.

Si les références cadastrales du dossier de coordination ne sont pas renseignées, un message d’erreur informe l’utilisateur que celles-ci sont obligatoires pour utiliser cette fonctionnalité.

S’il n’y a aucun établissement proche, alors les champs filtrants sont désactivés et un message indique à l’utilisateur qu’aucun résultat n’est disponible.

DI (Dossiers d’Instruction)

Les listing de DI

Lorsqu’un Système d’Information Géographique est paramétré, chaque ligne des listings de dossiers d’instruction contient un icône en forme de Terre. Celui-ci permet d’être redirigé sur le SIG avec la vue centrée sur le dossier d’instruction correspondant à cette ligne.

Dossiers à qualifier

(Dossiers ‣ DI (Instruction) ‣ Dossiers à qualifier)

Dossiers à affecter

(Dossiers ‣ DI (Instruction) ‣ Dossiers à affecter)

Mes plans

(Dossiers ‣ DI (Instruction) ‣ Mes plans)

Ce listing présente les dossiers d’instruction dont l’utilisateur connecté est noté comme instructeur et dont le type du dossier de coordination est de type PLAN.

Tous les plans

(Dossiers ‣ DI (Instruction) ‣ Tous les plans)

Ce listing présente les dossiers d’instruction rattachés au service dont l’utilisateur connecté fait partie et dont le type du dossier de coordination est de type PLAN.

Mes visites

(Dossiers ‣ DI (Instruction) ‣ Mes visites)

Ce listing présente les dossiers d’instruction dont l’utilisateur connecté est noté comme instructeur et dont le type du dossier de coordination est de type VISIT.

Toutes les visites

(Dossiers ‣ DI (Instruction) ‣ Toutes les visites)

Ce listing présente les dossiers d’instruction rattachés au service dont l’utilisateur connecté fait partie et dont le type du dossier de coordination est de type VISIT.

Tous les dossiers

(Dossiers ‣ DI (Instruction) ‣ Tous les dossiers)

La fiche du dossier d’instruction (DI)

Lorsqu’un Système d’Information Géographique est paramétré et que le dossier de coordination lié à ce dossier d’instruction a été géolocalisé, l’icône en forme de Terre permet d’être redirigé sur le SIG avec la vue centrée sur le dossier de coordination lié.

Actions

• Modifier

  • Disponible si le DI n’est pas clôturé.
  • Ouvre le formulaire de modification du dossier d’instruction.

• Clôturer

  • Disponible si le DI n’est pas clôturé, n’est pas à qualifier et, dans le cas d’un dossier de coordination périodique, s’il possède une visite.
  • Clôture le dossier d’instruction.

• Rouvrir

  • Disponible si le DI est clôturé, n’est pas à qualifier et, dans le cas d’un dossier de coordination périodique, si ce dernier n’est pas clôturé.
  • Rouvre le dossier d’instruction.

• À poursuivre

  • Disponible si le DI n’est pas clôturé, si son statut est « à programmer » ou « programmé » et s’il y a au moins une visite planifiée.
  • Change le statut du dossier d’instruction en « à poursuivre ».

• À programmer

  • Disponible si le DI n’est pas clôturé, si son statut est « programmé » et s’il n’y a aucune visite ou qu’elles sont toutes annulées.
  • Change le statut du dossier d’instruction en « à programmer ».

• Programmer

  • Disponible si le DI n’est pas clôturé, si son statut est « à programmer » ou « à poursuivre » et s’il y a au moins une visite planifiée.
  • Change le statut du dossier d’instruction en « programmé ».

Onglet Analyse

Dans le coin haut gauche de la fiche d’analyse figure son état : en cours de rédaction, terminée, validée ou actée.

Dans le coin haut droit sont disponibles les actions que l’on peut effectuer dessus : changer son état et éditer un document (rapport, compte-rendu et prévisualisation de procès-verbal).

Le corps de l’analyse est composé de plusieurs blocs de données qui ont chacun un titre et éventuellement un bouton modifier (cela dépend de vos droits et de l’état de l’analyse) :

• Type de l’analyse
• Objet
• Descriptif de l’établissement
• Classification de l’établissement
• Données techniques
• Réglementation applicable
• Prescriptions
• Documents présentés lors des visites et ceux fournis après ces dernières
• Essais réalisés
• Compte-rendu d’analyse
• Observation
• Avis proposé
• Proposition de décision autorité de police

Onglet PV

Cet onglet permet de gérer les procès verbaux du dossier d’instruction.

Listing

Les différentes actions possibles sont : de lister les procès verbaux existants, d’accéder aux différents procès verbaux existants, de générer un nouveau procès verbal, de regénérer le dernier procès verbal, d’ajouter un nouveau procès verbal tiers.

Générer un nouveau PV

L’analyse du DI doit être validée pour que l’action soit disponible. Le numéro est défini automatiquement selon l’année de la date de rédaction et récupère un numéro en fonction du service. Exemple : 2014/00012). L’état de l’analyse devient « actée ». On peut par la suite ajouter au PV généré sa version signée.

Fiche d’un PV généré

On ne peut pas modifier ce PV. Il est possible de le ré-générer si c’est le dernier procès-verbal (en conservant le même numéro de PV). Cette modification nécessite au préalable l’action « ré-ouvrir » sur l’analyse, la modification des éléments à corriger, puis l’action « terminer » sur l’analyse, et enfin l’action « valider » sur l’analyse.

L’unique action disponible sur cet élément est l’ajout du PV signé numérisé.

Regénérer le dernier PV

Si l’analyse est rouverte puis revalidée, et qu’au moins un PV a déjà été généré, alors il devient possible de regénérer le dernier. Pour le reste le comportement est semblable à un PV généré.

Ajouter un PV

Permet d’ajouter directement un PV tiers (supposé signé). Aucun numéro de PV n’est défini.

Fiche d’un PV ajouté

On peut modifier ce procès-verbal.

Mise à jour des informations de l’établissement

Dans tous les cas s’il s’agit d’un dossier d’instruction du service Sécurité Incendie et que l’on ajoute un PV signé, tiers ou relatif au PV (re)généré, cela met à jour les données techniques de l’établissement selon celles définies dans l’analyse.

Mise à jour des propositions d’avis de l’analyse

De plus et ce quelque soit le service, toute action sur un PV (création, modification) met à jour le couple de champs « proposition d’avis » et « proposition de complément d’avis » de la demande de passage liée grâce au couple de champs « proposition d’avis » et « proposition de complément d’avis » de l’analyse du dossier d’instruction sur lequel on se trouve.

Pour le bon fonctionnement de la proposition d’avis dans les réunions de commission aussi bien pour les dossiers de visites que de plans, le mécanisme suivant est nécessaire : la création ou modification de ce procès-verbal déclenche la mise à jour du couple de champs « proposition d’avis » et « proposition de complément d’avis » de la demande de passage liée grâce au couple de champs « proposition d’avis » et « proposition de complément d’avis » de l’analyse du dossier d’instruction sur lequel on se trouve. Si lors de l’impression de l’ordre du jour de la réunion de commission, il s’avère que le champ « proposition d’avis » n’est pas rempli dans la demande de passage, alors c’est la valeur de ce même champ dans l’analyse qui sera affiché dans l’ordre du jour.

Onglet Documents Entrants

Listing standard (ou interne)

L’onglet « Document Entrants » sur la fiche d’un dossier d’instruction affiche tous ses documents entrants liés. Les informations présentées sont :

• le nom du document,
• l’établissement,
• le dossier de coordination,
• le dossier d’instruction,
• la date butoir du document,
• le statut du document (en cours, qualifié, …).

Listing guichet unique

Dans le cas où le module “swrod” (Documents du guichet unique en lecture seule) est activé, l’onglet peut posséder un affichage différent si le DC contient une référence vers un dossier ADS. Dans ce cas, l’onglet “Interne” présente les mêmes informations et actions que l’onglet “Documents Entrants” standard et l’onglet “Guichet Unique” présente une vue en lecture seule des documents concernant le dossier ADS du DC.

Onglet Documents générés

Onglet Réunions

Onglet Visites

Onglet Messages

Voir le paragraphe Onglet Messages.

Messages

La notion de messages correspond à une notification entrante dans openARIA, sortante d’openARIA ou interne d’openARIA qui permet de tracer des informations, de notifier certains utilisateurs sur des événements qui ont eu lieu sur un dossier de coordination en particulier.

Les listings de messages

Mes non lus

(Dossiers ‣ Messages ‣ Mes non lus)

Listing accessible depuis le widget Widget « Mes messages ».

Cet écran est destiné aux profils CADRE et TECHNICIEN.

Le listing est filtré sur les messages considérés comme non lus de l’utilisateur.

Si l’utilisateur est CADRE sont considérés comme non lus :

• tous les messages dont le marqueur CADRE de son service est à non lu,
• tous les messages dont le marqueur TECHNICIEN de son service est à non lu sur les messages rattachés à un dossier sur lequel il est référencé comme technicien.

Si l’utilisateur est TECHNICIEN sont considérés comme non lus :

• tous les messages dont le marqueur TECHNICIEN de son service est à non lu sur les messages rattachés à un dossier sur lequel il est référencé comme technicien.

Les colonnes du listing sont fixes :

• date
• type
• catégorie
• émetteur
• dc
• établissement

Aucun message en gras sur ce listing puisque tous les messages de ce listing sont non lus.

Par défaut le listing est trié par date décroissante.

Note

Du fait du format de la colonne date (DD/MM/YYYY HH:MM:SS), le tri manuel sur cette colonne est alphanumérique et non chronologique. Cependant le tri par défaut est lui bien chronologique.

L’ajout, la modification et la suppression de message sont impossibles via l’interface.

Un lien sur le message permet d’accéder à la fiche de visualisation du message dans le contexte du dossier d’instruction si l’utilisateur est TECHNICIEN et dans le contexte du dossier de coordination si l’utilisateur est CADRE.

Onglet Messages

Cet écran est destiné aux profils CADRE et TECHNICIEN.

Ce listing est identique sur l’onglet message du DC et sur l’onglet message du DI. Il présente tous les messages liés au DC (ou au DC lié au DI) sur lequel on se trouve.

Les colonnes fixes du listing sont :

• date
• type
• catégorie
• émetteur

Si l’utilisateur possède un service, deux colonnes supplémentaires apparaissent :

• cadre <service> : marqueur de lecture du message pour un utilisateur cadre <service>
• tech <service> : marqueur de lecture du message pour un utilisateur tech <service>

Si un des messages répond aux critères “non lu” pour l’utilisateur connecté (voir Mes non lus) alors la ligne s’affiche en gras.

Par défaut le listing est trié par date décroissante.

Note

Du fait du format de la colonne date (DD/MM/YYYY HH:MM:SS), le tri manuel sur cette colonne est alphanumérique et non chronologique. Cependant le tri par défaut est lui bien chronologique.

L’ajout, la modification et la suppression de message sont impossibles via l’interface.

Un lien sur le message permet d’accéder à la fiche de visualisation du message dans le contexte du dossier d’instruction si l’utilisateur est TECHNICIEN et dans le contexte du dossier de coordination si l’utilisateur est CADRE.

Tous les messages

(Dossiers ‣ Messages ‣ Tous les messages)

Cet écran est destiné au profil CADRE.

Le listing présentetous les messages existants dans openARIA.

Une recherche avancée permet de filtrer le listing sur les critères suivant :

• type
• émetteur
• catégorie

Les colonnes du listing ont fixes :

• date
• type
• catégorie
• émetteur
• dc
• établissement
• cadre si : marqueur de lecture du message pour un utilisateur cadre si
• tech si : marqueur de lecture du message pour un utilisateur tech si
• cadre acc : marqueur de lecture du message pour un utilisateur cadre acc
• tech acc : marqueur de lecture du message pour un utilisateur tech acc

Par défaut le listing est trié par date décroissante.

Note

Du fait du format de la colonne date (DD/MM/YYYY HH:MM:SS), le tri manuel sur cette colonne est alphanumérique et non chronologique. Cependant le tri par défaut est lui bien chronologique.

L’ajout, la modification et la suppression de message sont impossibles via l’interface.

Un lien permet d’accéder à la fiche de visualisation du message dans son contexte propre.

La fiche de visualisation du message

Les informations du message :

• catégorie : entrant (message reçu depuis un autre applicatif), sortant (message envoyé à une autre applicatif) ou interne (notification interne à openARIA)
• dossier de coordination : le dossier lié au message
• le type de message : un identifiant texte permettant de savoir de quel message il s’agit (exemple : ADS_ERP__AT__DEPOT_DE_PIECE_PAR_LE_PETITIONNAIRE, c’est un message des services ADS vers les services ERP concernant une AT notifiant le dépôt de pièce par le pétitionnaire au guichet unique)
• l’émetteur
• la date d’émission : la date à laquelle le message a été envoyé
• le contenu du message : texte libre
• les modes et marqueurs de lecture (voir le paragraphe suivant)

Modes de lecture et marqueurs de lecture

Les marqueurs de lecture sont disponibles sur un message par service en fonction du mode de lecture déterminé. Un message possède donc un mode de lecture par service qui détermine les marqueurs de lecture disponibles sur ce message.

• mode 0 : Aucun marqueur
• mode 1 : Uniquement le marqueur de lecture “cadre”
• mode 2 : Uniquement le marqueur de lecture “tech”
• mode 3 : Les deux marqueurs

Action “Marquer comme lu”

Marquer comme lu (cadre <service>)

Cette action est disponible uniquement si :

• le marqueur indiqué entre parenthèses est à non lu
• ET le mode de lecture indique que ce marqueur est activé (mode 1 ou 3)
• ET l’utilisateur a la permission (profil CADRE)

Marquer comme lu (tech <service>)

Cette action est disponible uniquement si :

• le marqueur indiqué entre parenthèses est à non lu
• ET le mode de lecture indique que ce marqueur est activé (mode 1 ou 3)
• ET l’utilisateur a la permission (profil CADRE)

Action “Marquer comme non lu”

Marquer comme non lu (cadre <service>)

Cette action est disponible uniquement si :

• le marqueur indiqué entre parenthèses est à lu
• ET le mode de lecture indique que ce marqueur est activé (mode 2 ou 3)
• ET l’utilisateur est référencé comme technicien du dossier
• ET l’utilisateur a la permission (profil CADRE et TECHNICIEN)

Marquer comme non lu (tech <service>)

Cette action est disponible uniquement si :

• le marqueur indiqué entre parenthèses est à lu
• ET le mode de lecture indique que ce marqueur est activé (mode 2 ou 3)
• ET l’utilisateur est référencé comme technicien du dossier
• ET l’utilisateur a la permission (profil CADRE et TECHNICIEN)

Rubrique « Suivi »

La rubrique « Suivi » est divisée en catégories :

• Documents entrants
• Documents générés
• Programmations
• Réunions
• Pilotage

Documents entrants

(Suivi ‣ documents entrants)

Les listings des documents entrants

Il existe plusieurs listings des documents entrants.

Depuis le menu « Bannette »

La bannette affiche tous les documents entrants qui ne sont pas encore liés à un établissement et/ou dossier de coordination et/ou dossier d’instruction. Les informations présentées sont :

• le nom du document,
• le type du document (acte, courrier de l’explotant, …),
• la date de création du document,
• la date de réception du document,
• la date d’émission du document,
• la date butoir du document,
• le statut du document (en cours, qualifié, …).

Depuis l’onglet « Documents Entrants » d’un établissement

Onglet « Documents Entrants » sur l’établissement

Depuis l’onglet « Documents Entrants » d’un dossier de coordination

Onglet « Documents Entrants » sur le dossier de coordination

Depuis l’onglet « Documents Entrants » d’un dossier d’instruction

Onglet « Documents Entrants » sur le dossier d’instruction

Depuis le menu « Suivi »

Ce menu affiche les documents entrants suivis qui n’ont pas de date butoir ou dont leur date butoir <= à la date du jour. Les informations présentées sont :

• le nom du document,
• le type du document (acte, courrier de l’explotant, …),
• la date de création du document,
• la date de réception du document,
• la date d’émission du document,
• la date butoir du document,
• le statut du document (en cours, qualifié, …)

Depuis le menu « À Valider »

Les documents entrants qui demandent une validation sont affichés dans ce listing. Les informations présentées sont :

• le nom du document,
• le type du document (acte, courrier de l’explotant, …),
• la date de création du document,
• la date de réception du document,
• la date d’émission du document,
• la date butoir du document.

Depuis le menu « Mes Non Lus »

(Dossiers ‣ documents entrants ‣ mes non lus)

Liste les documents entrants non lu d’un dossier d’instruction pour son technicien. Les informations présentées sont :

• le dossier d’instruction,
• l’établissement,
• l’adresse de l’établissement,
• le nom du document,
• la date de création du document,
• la date butoir du document.

Ajouter un document entrant

Un document entrant peut être ajouté depuis plusieurs endroits de l’application, depuis la bannette, depuis un établissement, depuis un dossier de coordination ou depuis un dossier d’instruction.

Si la liaison est faite depuis un dossier d’instruction alors le document sera lié automatiquement au dossier de coordination et à l’établissement. Même traitement depuis le dossier de coordination, le document sera lié automatiquement à l’établissement.

Depuis la banette

Ajouter un document entrant depuis la bannette permet de ne pas le lier à un établissement, un dossier de coordination ou un dossier d’instruction, dans ce cas il sera « En cours ».

Si dans le cas inverse, un établissement, un dossier de coordination ou un dossier d’instruction est renseigné alors celui-ci est « Qualifié ». Une permission speciale permet de qualifier et valider directement le document entrant.

Depuis un établissement/dossier de coordination/dossier d’instruction

Ajouter un document entrant depuis un établissement, un dossier de coordination ou un dossier d’instruction est identique à l’ajout depuis la bannette mais le lien sera automatiquement fait avec l’enregistrement en question.

La fiche d’un document entrant

Les documents présents au format PDF, PNG et JPG peuvent être visualisés directement dans le navigateur à condition qu’il dispose des composants nécessaires (lecteur PDF Acrobat avec plugin navigateur par exemple). Les autres types de document devront être téléchargés pour être visualisés au moyen du logiciel adapté.

Marquer comme lu un document entrant

Lorsqu’un document entrant est lié à un dossier d’instruction, le technicien responsable est notifié de son existence depuis le widget « Mes documents entrants non lus » sur son tableau de bord.

Une fois qu’il a pris connaissance des consignes du document, il peut le marquer comme lu.

Un document entrant lu peut être marqué comme non lu.

Suivre un document entrant

Un document entrant peut être suivi et apparaitre dans le widget « Documents entrants suivis » du tableau de bord.

Le suivi peut être désactiv& et ainsi le document n’apparaitra plus dans la liste.

Valider un document entrant

Les documents entrants liés à un établissement/dossier de coordination/dossier d’instruction sans permission speciale doivent être validés.

La dématérialisation

Les documents numérisés et placés dans un dossier spécifique seront récupérés toutes les 15 minutes par openARIA. Tous ces documents seront disponibles depuis la bannette et pourront être traités depuis le menu du même nom.

Documents générés

(Suivi ‣ documents générés)

Les listings des documents générés

Il existe plusieurs listings des documents générés.

Depuis le menu « Gestion »

Le menu « Gestion » permet d’afficher tous les documents générés.

Depuis le menu « À Éditer »

Le menu « À Éditer » permet d’afficher les documents générés finalisés dont les dates de suivi (date d’envoi et de retour pour signature et AR) ne sont pas renseignées.

Depuis le menu « Attente Signature »

Le menu « Attente Signature » permet d’afficher les documents générés finalisés dont la date d’envoi en signature est saisie et dont les dates d’envoi AR et de retour signature et AR ne sont pas renseignées.

Depuis le menu « Attente Retour AR »

Le menu « Attente Retour AR » permet d’afficher les documents générés finalisés dont la date de retour signature ou la date d’envoi AR sont saisies et dont la date de retour AR n’est pas renseignée.

Depuis l’onglet « Documents Générés » d’un dossier d’instruction

L’onglet « Document Générés » sur la fiche d’un établissement affiche tous ses documents générés liés, les documents générés liés à ses dossiers de coordinations ainsi que les documents générés liés à ses dossiers d’instruction.

Depuis l’onglet « Documents Générés » d’un dossier de coordination

L’onglet « Document Générés » sur la fiche d’un établissement affiche tous ses documents générés liés ainsi que les documents générés liés à ses dossiers d’instructions.

Depuis l’onglet « Documents Générés » d’un établissement

L’onglet « Document Générés » sur la fiche d’un établissement affiche tous ses documents générés liés.

Ajouter un document généré

Les documents générés s’ajoutent manuellement depuis les onglets d’un établissement/dossier de coordination/dossier d’instruction, ou automatiquement lors d’actions spécifiques dans l’application comme par exemple la génération d’un PV.

Le choix du ou des destinataires se fait grâce au champ de sélection multiple « Contact liés », la liste est composée des contacts de l’établissement, des pétitionnaires du dossier de coordination et des contacts institutionnels.

Il est possible d’insérer des textes types dans les champs de complément. Ces textes types sont filtrés par le type du courrier.

Les fiches d’un document généré

La fiche d’un document généré « mailing » ou s’il y a un destinataire.

La fiche d’un document généré « enfant », c’est-à-dire créé automatiquement en cas de « mailing » lorsqu’il y a plusieurs destinataires.

Les actions n’apparaissent pas sur cette fiche.

Modifier un document généré

Le formulaire de modification d’un document généré qui n’est pas encore validé.

Le formulaire de modification d’un document généré validé, seules les dates de suivi et le fichier signé sont modifiables.

Dans le cas d’un document généré « mailing » parent, ses données ne peuvent pas être modifiés tant que celui-ci est validé.

Prévisualiser le document PDF

Le rédacteur du document généré peut, tant que le document n’est pas finalisé, contrôler le rendu final du PDF.

Finaliser un document généré

Une fois la rédaction du document généré, il peut être finalisé.

Lors de la finalisation du document généré, si celui-ci à plusieurs destinataires alors un document unique est créé pour chacun d’eux et reste lié au document « mailing ». Dans l’autre situation, si le document généré à un destinataire alors aucun autre enregistrement n’est ajouté. Sur chaque courrier il est possible de sélectionner un autre courrier du même dossier pour l’envoyer en pièce jointe.

Un document généré peut être rouvert en cas de modification. Si c’est un courrier « mailing », alors tous ses « enfants » seront supprimés.

Le formulaire de suivi d’un document généré

(Suivi ‣ documents générés ‣ suivi par code barres)

Lorsque le document généré est finalisé, il fait l’objet d’un circuit de signature avant son envoi. Il est donc nécessaire d’avoir la possibilité de mettre à jour les dates de suivi.

Depuis ce formulaire, il suffit de scanner le code imprimé sur le document généré pour accéder au contexte du document généré et de cliquer sur l’action « Modifier » pour renseigner les dates de suivi.

Le formulaire d’impression des étiquettes RAR

(Suivi ‣ documents générés ‣ édition rar)

Les prés-imprimés de la Poste des lettres recommandées avec accusé de réception (lettres RAR) sont fournis vierges. Le code-barres du document généré doit être imprimé sur le troisième feuillet qui lui revient pour pouvoir saisir dans l’application les dates de suivi.

Le formulaire permet de renseigner une date d’envoi, par défaut la date du jour, et de scanner à la douchette les documents générés concernés. Le bouton de validation génère un fichier PDF contenant l’édition de tous les bordereaux RAR dans l’ordre de scanne. Lors de la génération du fichier des RAR, la date d’envoi RAR est mise à jour sur le suivi des documents générés.

Les contacts institutionnels

(Suivi ‣ documents générés ‣ contact institutionnel)

Le listing des contacts institutionnels

Le menu « Contact Institutionnel » permet d’afficher tous les contacts institutionnels.

Ajouter un contact institutionnel

Les cases à cocher « Réception de la programmation » et « Réception des éditions liées aux commissions » permettent de recevoir, respectivement, les convocations de membres des programmations de visite et les convocations et comptes rendus de réunion du service du contact. Si le contact institutionnel n’a pas de service alors il reçoit les documents de tous les services.

La sélection de la qualité du contact permet de saisir des informations différentes sur le contact.

Qualité “particulier”

Le nom est obligatoire.

Le contact est présenté de la manière suivante dans l’application si toutes les informations sont remplies : « <civilité> <nom> <prénom> » (Par exemple : M. DUPONT Jacques).

Qualité “personne morale”

La dénomination OU la raison sociale est obligatoire (il faut saisir au moins une des deux informations, l’une ou l’autre ou les deux).

La civilité, le nom, le prénom et le titre sont utilisés pour qualifier le représentant de la personne morale.

Le contact est présenté de la manière suivante dans l’application si toutes les informations sont remplies : « <raison sociale> <dénomination> représenté(e) par <civilité> <nom> <prénom> » (Par exemple : RAISON SOCIALE représenté(e) par M. DUPONT Jacques).

La fiche d’un contact institutionnel

Programmations

(Suivi ‣ Programmations ‣ Gestion)

La programmation des visites est gérée par semaine, elle est identifiée par l’année et le numéro de semaine (Ex : 2015/39). Les numéros de semaines sont calculées selon la norme ISO (chaque semaine fait 7 jours et peut être à cheval sur deux années selon l’année il peut y en avoir 52 ou 53).

Le listing des programmations

Ce listing présente les programmations spécifiques au service de l’utilisateur connecté.

Ajouter une programmation

Le listing des programmations présente un bouton « Ajouter » qui permet d’accéder au formulaire d’ajout d’une nouvelle semaine de programmation.

Par défaut, le formulaire d’ajout d’une semaine de programmation est pré-rempli avec le numéro de semaine supérieur à celui de la dernière semaine de programmation existante. Par exemple si la dernière semaine créée est 2015/23 alors la prochaine sera 2015/24.

La fiche de la programmation

Onglet « Visites »

Cet onglet présente la liste de toutes les visites liées à la programmation en cours. Les informations présentées sont :

• la date et l’heure de la visite,
• l’état de la visite,
• le technicien,
• l’état d’envoi des convocations aux exploitants,
• la date d’annulation s’il y en a une,
• les versions de programmation pendant la vie de la visite.

En cliquant sur la ligne on accédera à la visite avec son détail et tous les envois liés. On aura aussi accès aux fonctions d’envoi de convocation ou courrier d’annulation.

La vie de la programmation

Le numéro de version à la création de la programmation est 1. Il est incrémenté chaque fois qu’une nouvelle version de la programmation est créée.

L’état de la programmation est « En préparation » par défaut. Les états sont successivement :

• « En préparation » : c’est uniquement quand la programmation est dans cet état que l’on peut ajouter, modifier et annuler les visites. Depuis cet état l’action finaliser la programmation est disponible et permet de passer dans l’état « Finalisée ».
• « Finalisée » : il est possible de la réouvrir, ce qui la repasse à l’état « En préparation » ou de la valider ce qui la passe à l’état « Validée ».
• « Validée » : il est possible de générer les convocations et/ou de créer une nouvelle version de la programmation, ce qui la répasse à l’état « En préparation » en incrémentant le numéro de version.

Les convocations

Liste des statuts des convocations :

• Vide : la programmation est « En préparation » ou « Finalisée » sur une version 1 ou sur une version > 1 dont le statut de la convocation était vide ou « À envoyer ».
• « À envoyer » : la programmation est « Validée » sur une version 1.
• « À compléter » ou « À renvoyer » : si sur une version > à 1 et le statut de la convocation était « Envoyée ».
• « Envoyée » : si les convocations sont envoyées.

La convocation des exploitants

Les convocatiosn sont des documents générés et apparaissent dans l’onglet « Documents Générés » dans le contexte du dossier d’instruction.

Les convocations des exploitants sont dans l’ordre :

• Non effectuées pour la version courante (tant que la version n’est pas validée on laisse le champ vide)
• A envoyer (la programmation a été validée et aucune convocation n’a été envoyée)
• Envoyées (toutes les convocations ont été envoyées)
• A compléter (si les convocations étaient Envoyées dans une version précédente, il faut compléter les envois)

L’action « Générer les convocations exploitant » génère pour chaque visite dont le statut d’envoi de convocation est « à envoyer » un document généré à chaque contact de l’établissement marqué comme destinataire des courriers (que ce soit pour les courriers de convocation ou pour les courriers d’annulation).

La convocation des membres

Les convocations des membres sont dans l’ordre :

• Non envoyées pour la version courante (tant que la version n’est pas validée on laisse le champ vide)
• « A envoyer » (la programmation a été validée. Si c’est une nouvelle version de la programmation, celle-ci est tout de même A envoyer.)
• « Envoyée » (la programmation a été envoyée)

Une action permet d’envoyer par mail la convocation des membres au format PDF à tous les contacts institutionnels du service de la programmation dont la case « réception de la programmation » est cochée ainsi qu’à tous les techniciens présents dans les visites de la programmation.

Le document comporte les informations suivantes :

• planning de la programmation de la semaine
• historique, comportant pour chaque version de la programmation :

• numéro de version de la programmation
• liste des visites ajoutées
• liste des visites annulées
• date de la finalisation de la version de la programmation

Une action permet de télécharger la convocation une fois que la programmation est validée.

Exemple

Voici donc un scénario pour une semaine « 2014/07 » :

• Version 1: préparation, finalisation, réouverture pour correction, finalisation, validation, envoi des convocations exploitant seulement.
• Version 2: suite aux retours des exploitants, préparation v2, finalisation, validation, envoi des convocations exploitant seulement.
• Version 3: suite aux retours des exploitants, préparation v3, finalisation, validation, envoi des convocations exploitant et membres.
• Version 4: suite aux retours des exploitants, préparation v4, finalisation, validation, envoi des convocations exploitant et membres.

La planification des visites

L’écran de planification des visites est composé de deux blocs principaux : la liste des dossiers d’instruction de type VISIT qui sont en attente de programmation et l’agenda des visites de la semaine.

Lorsqu’un Système d’Information Géographique est paramétré, il est possible de filtrer les dossiers de visite par distance par rapport à un établissement.

Par défaut le bouton Tous est sélectionné : le filtre sur les établissements proches est désactivé.

Pour activer le filtre il faut géolocaliser les dossiers autour d’un établissement :

• cliquer sur le bouton Proche afin d’afficher les champs de recherche ;
• saisir le code d’établissement autour duquel le périmètre s’appliquera ;
• sélectionner le rayon (il s’agit, en mètres, de la distance maximum d’éloignement acceptée) ;
• cliquer sur le bouton Valider.

Note

• Si aucun établissement n’est trouvé dans le rayon, ou si ceux trouvés ne correspondent à aucun dossier de visite, alors le tableau de propositions n’affichera aucun résultat.
• Géolocaliser les dossiers de visite par établissements proches sous-entend que les dossiers n’ayant pas d’établissement rattaché ne seront pas listés.

Bloc de propositions

Les propositions sont classées par défaut selon l’ordre suivant :

• 1 - A poursuive, par code de technicien, croissant,
• 2 - Visites périodiques avec locaux à sommeil,
• 3 - Visites de contrôle avec locaux à sommeil,
• 4 - Visites de réception,
• 5 - Visites périodiques sans locaux à sommeil,
• 6 - Visites de contrôle sans locaux à sommeil,
• les visites sont classées par date de visite croissante.

En plus du tri par défaut, il est possible de filtrer les dossiers selon :

• leur type de visite : une liste à choix propose soit tous les types, soit les périodiques, soit les contrôles, soit les réceptions,
• si la visite est à poursuivre (la visite doit avoir lieu en plusieurs fois),
• si la visite porte sur un établissement avec locaux à sommeil,
• si la visite est en retard (c’est-à-dire si la date butoir du dossier de coordination est dans le passé),
• si la visite porte sur un dossier d’instruction prioritaire.

De plus chaque colonne peut être filtrée grâce à un champ de recherche ainsi que triée grâce à un clic sur l’entête de colonne.

Bloc agenda

Le calendrier comporte les 7 jours de la semaine, du lundi au dimanche.

Par défaut, l’agenda présenté est celui de tous les techniciens confondus (« Tous »), il n’est alors pas possible de planifier les visites, les dates de congés ne sont pas affichés et les périodes préférentielles des agents non plus.

Le calendrier affiche alors toutes les visites planifiées. L’affichage comporte le N° d’établissement et l’acronyme du technicien.

Un clic sur l’affichage permet d’afficher un bloc comportant les informations clés de la visite : - données du tableau de présentation, - ainsi qu’un hyperlien permettant d’ouvrir l’établissement et/ou le dossier de visite, - N° établissement, - acronyme du technicien, - type, cat, sommeil, - type de visite, - commission compétente.

Lorsqu’un technicien est sélectionné, seules ses visites sont affichées. Les fonds du calendrier sont coloriés en rouge pour les périodes de congés du technicien (par jours et heures) et en vert pour les périodes privilégiées (par demi-journée). Il est alors possible de lui affecter des visites en effectuant un tirer-lacher de la liste de propositions vers le calendrier de planification.

Planifier une nouvelle visite

Il faut préalablement sélectionner un technicien. Son agenda est alors affiché. Il est dès lors possible de tirer une proposition de visite du cadre supérieur vers une zone de l’agenda du technicien. Cette action provoque l’ouverture d’un formulaire d’ajout d’une visite : celui-ci contient des informations d’aide à la planification et des champs à renseigner.

Informations d’aide à la programmation :

• Code établissement,
• libellé établissement,
• date de prochaine visite périodique prévue,
• type, catégorie, locaux à sommeil,
• type de la visite,
• objet de la visite (par défaut = type de visite),
• durée prévue de visite,
• liste des autres visites liées à ce dossier de visite (cette liste est disponible depuis l’onglet « Visites » du dossier d’instruction concerné dont le lien est présent au-dessus).

Liste des champs à renseigner :

• date de la visite,
• heure de début de visite,
• heure de fin de visite,
• « à poursuivre »,
• observations (texte libre).

Il est à noter que le technicien peut aussi passer le dossier de visite en planification « à poursuivre » lors de la rédaction de son PV de visite.

La vie de la visite

• Visualiser la visite programmée : ceci ouvre la fiche de visite programmée dans une fenêtre superposée à la vue courante. Cette fenêtre contient les informations présentées et saisies lors de la planification de la visite, ainsi que le statut de la visite. Elle comporte notamment un lien direct vers la fiche de l’établissement et un autre lien vers le dossier de visite.
• Modifier la visite : la modification de la date (dans les dates de la semaine de rpogrammation) et/ou de l’heure et/ou du technicien de la visite peut se faire jusqu’à ce que la version de la programmation soit validée. Après ce moment il faudra annuler la visite puis la reprogrammer.
• À poursuivre : disponible si le dossier d’instruction n’est pas clôturé, si son statut est « à programmer » ou « programmé » et s’il y a au moins une visite planifiée. Change le statut du dossier d’instruction en « à poursuivre ».
• Annuler la visite programmée : il faut alors saisir la date d’annulation (par défaut la date du jour) ainsi que le motif d’annulation. Le motif est choisi au sein de la liste suivante :

• Annulation exceptionnelle
• SPGR
• Indisponibilité d’un membre
• SCDS
• Exploitant indisponible
• Exploitant défaillant
• NPAI

Lorsqu’une visite est annulée pour tout motif autre que NPAI, le dossier de visite repasse en dossier à programmer si c’était la seule date de visite, en dossier à poursuivre s’il y a d’autres visites programmées.

Lorsqu’une visite est annulée pour motif NPAI le dossier de visite est annulé et l’établissement est affiché dans le widget « Établissement NPAI ». Il est alors nécessaire de le traiter hors logiciel afin de mettre à jour les informations de l’établissement et prendre les mesures nécessaires.

Un document généré d’annulation est géré selon le même modèle que le document généré de convocation et le statut de convocation est donc noter comme « à compléter » jusqu’à la génération des convocations exploitants par lot à la validation de la version de la programmation.

Suppression d’une programmation

Il est possible de supprimer une semaine de programmation uniquement si aucune visite n’y a jamais été planifiée.

Réunions

(Suivi ‣ Réunions ‣ Gestion)

Le listing des réunions

Ce listing présente les réunions spécifiques au service de l’utilisateur connecté.

Ajouter une réunion

Le listing des réunions présente un bouton « Ajouter » qui permet d’accéder au formulaire d’ajout d’une nouvelle réunion.

Le code de la réunion est composé automatiquement du code du type de réunion sélectionné concaténé avec la date de la réunion (Exemple : CCS-2014-06-22). Le libellé de la réunion est composé du libellé du type de réunion sélectionné concaténé avec la date de la réunion (Exemple : Réunion Plénière CCS du 24/06/2014). Lors de la création de la réunion, les données présentes dans le paramétrage du type de réunion sont récupérées automatiquement dans le formulaire de création (heure, lieu, …).

La fiche de la réunion

Gérer l’ordre du jour de la réunion

L’ordre du jour est composé de la liste des dossiers dont les instances présentes vont discuter pendant la réunion. Il y a un unique ordre du jour par réunion. Si le type de réunion contient plusieurs catégories, alors cette liste est groupée par catégorie. Depuis l’écran de gestion de la réunion, plusieurs actions sont disponibles pour la composition de l’ordre du jour.

Réunion

Cet écran présente un listing de toutes les demandes de passage qui ont été planifiées à la réunion sur laquelle on se trouve, groupées par catégorie.

Planifier

Cet écran présente un listing des dossiers pressentis, ce sont toutes les demandes de passage qui n’ont été planifiées à aucune réunion mais dont le type correspond au type de la réunion sur laquelle on se trouve. Des cases à cocher permettent de sélectionner les demandes de passage que l’on souhaite planifier/ajouter à l’ordre du jour. En cliquant sur le bouton de validation, le traitement est effectué sauf si la demande de passage n’est plus disponible. Dans les deux cas un message indique à l’utilisateur le résultat du traitement. Cette action est disponible seulement si la réunion n’a pas déjà été clôturée.

Pour aider à la saisie des dossiers à planifier, une action permet de sélectionner tous les éléments du listing (cocher toutes les cases à cocher) en un seul clic et un formulaire de recherche permet de filtrer le listing sur :

• une période pour la date souhaitée (du … au …),
• la catégorie.

Déplanifier

Cet écran présente un listing des demandes de passage qui ont été planifiées pour la réunion sur laquelle on se trouve. Des cases à cocher permettent de sélectionner les demandes de passage que l’on souhaite retirer de l’ordre du jour. En cliquant sur le bouton de validation, le traitement est effectué sauf si un retour d’avis est déjà saisi dans la demande de passage. Dans les deux cas un message indique à l’utilisateur le résultat du traitement. Pour aider à la saisie des dossiers à déplanifier, une action permet de sélectionner tous les éléments du listing (cocher toutes les cases à cocher) en un seul clic. Cette action est disponible seulement si la réunion n’a pas déjà été clôturée.

Planifier nouveau

Cet écran permet de planifier directement un ou des dossiers d’instruction à la réunion sur laquelle on se trouve sans créer manuellement au préalable une demande de passage sur le ou les dossiers d’instruction concernés. Cette action est disponible seulement si la réunion n’a pas déjà été clôturée.

Trois choix de planification directe sont possibles :

• programmation : planifie tous les dossiers d’instruction correspondant aux visites présente dans une programmation. Il suffit de sélectionner : la programmation (parmi la liste des programmations passées qui n’ont pas déjà été planifiées pour une autre réunion) et la catégorie (dans laquelle on souhaite insérer ces demandes de passage).

• réunion : planifie tous les dossiers d’instruction présents dans une réunion. Il suffit de sélectionner : la réunion (parmi la liste des réunions clôturées qui ne sont pas des réunions de commission et qui n’ont pas déjà été planifiées pour une autre réunion) et la catégorie (dans laquelle on souhaite insérer ces demandes de passage).

• dossier : planifie le dossier d’instruction correspondant au code du dossier de coordination ou du dossier d’instruction saisi. Il suffit de saisir le code du dossier de de sélectionner la catégorie (dans laquelle on souhaite insérer cette demande de passage).

Numéroter

Cette action permet de déclencher la numérotation de l’ordre du jour, c’est-à-dire numéroter la liste des demandes de passage planifiées à partir de 1. Une fois que la numérotation a été déclenchée, tout nouveau dossier prendra le numéro suivant. Un dossier retiré de l’ordre du jour laissera un vide dans la numérotation. La numérotation initiale se fait par catégorie selon l’ordre défini dans le paramétrage du type de réunion. Cette action est disponible que si la numérotation n’a pas déjà été effectuée.

Imprimer l’ordre du jour

À tout moment une action permet d’accéder à l’ordre du jour au format PDF en cliquant sur l’action « Ordre du jour » dans l’écran de gestion de la réunion.

Un modèle de document paramétrable dans le type de réunion sert de base pour l’ordre du jour de la réunion. Il sera composé de champs de fusion et rempli avec les informations de la réunion au moment de sa génération. Un champ de fusion particulier « avis proposé » provient de la demande de passage ou de l’analyse selon le cas.

L’ordre du jour est stocké pour mémoire lors de la clôture de la réunion.

Gérer les membres de la réunion

Convoquer

À tout moment une action permet de convoquer les instances de la réunion en cliquant sur l’action « Convoquer les membres » dans l’écran de gestion de la réunion. Cette action permet d’envoyer un mail aux différentes adresses paramétrées dans les instances, ainsi qu’aux adresses présentes dans le champ « liste de diffusion » de la réunion. Un écran permet de confirmer l’envoi du mail avec une case à cocher permettant d’indiquer si l’ordre du jour doit être envoyé ou non en pièce jointe. La date de dernière convocation est stockée pour mémoire.

Feuille de présence

À tout moment une action permet d’accéder à la feuille de présence au format PDF en cliquant sur l’action « Feuille de présence » dans l’écran de gestion de la réunion.

Un modèle de document paramétrable dans le type de réunion sert de base pour la feuille de présence de la réunion. Il sera composé de champs de fusion et rempli avec les informations de la réunion au moment de sa génération.

Sélectionner les signataires

Un écran permet, pour chaque instance de la réunion :

• de sélectionner le membre qui la représente,
• de saisir un texte libre.

L’unique objectif de ces informations est de remplir la feuille de présence.

Gérer les avis

Rendre l’avis

Depuis l’écran de gestion d’une réunion, le listing des dossiers planifiés (l’ordre du jour) permet d’accéder à chaque formulaire de saisie du retour d’avis. Ce retour est composé des informations suivantes :

• proposition d’avis : lecture seule,
• proposition de complément d’avis (éventuellement second avis) : lecture seule,
• avis : sélection d’un avis dans la liste des avis,
• complément d’avis (éventuellement second avis) : ligne de texte,
• motivation de l’avis : texte.

Il est possible d’imprimer le compte-rendu d’avis depuis cet écran.

Dans cet écran une action permet d’insérer et de saisir des décisions d’autorité de police.

Dans certains cas, il n’y a pas de prise d’avis ou de décision sur un dossier lors d’une réunion. Dans ce cas un avis tel que “A revoir” ou “Différé” est saisi, qui permettra la suite du processus. Il est donc nécessaire de reprogrammer un passage pour le dossier en question. Dans le même écran de saisie, une action permet d’insérer et de saisir des demandes de passage en réunion. Le formulaire est identique au formulaire de demande de passage manuel. Il est ainsi possible d’indiquer la date souhaitée de passage, le type de réunion, la catégorie et éventuellement la proposition d’avis.

Imprimer le compte rendu d’avis

Un modèle de document paramétrable dans le type de réunion servira de base pour le compte-rendu par dossier. Il sera composé de champs de fusion et rempli avec les informations de la réunion au moment de sa génération.

Une action disponible depuis la fiche de visualisation d’une demande de passage permet d’imprimer le « compte-rendu par dossier » de la demande de passage.

Une action disponible sur la fiche de la réunion permet d’imprimer l’ensemble des « compte-rendus par dossier » de toutes les demandes de passage en une seule action.

Gérer le compte-rendu et la clôture de la réunion

Imprimer le compte rendu

Un modèle de document paramétrable dans le type de réunion servira de base pour le compte-rendu global de la réunion. Il sera composé de champs de fusion et rempli avec les informations de la réunion au moment de sa génération.

À tout moment une action permet d’accéder au compte-rendu au format PDF en cliquant sur l’action « Compte-rendu » dans l’écran de gestion de la réunion. Ce compte-rendu global de la réunion est un listing de tous les dossiers avec l’avis résultant de la réunion.

Clôturer

Une action permet de clôturer la réunion.

Restriction(s) :

• Si toutes les demandes de passage n’ont pas un avis, alors la clôture de la réunion n’est pas possible.
• Une fois la réunion clôturée alors il n’est plus possible de modifier les avis.
• Une fois la réunion clôturée alors il n’est plus possible de modifier l’ordre du jour (les actions/écrans permettant de le gérer disparaissent).

Cette action permet d’accéder à un formulaire de confirmation de la clôture de la réunion en donnant le choix à l’utilisateur de diffuser ou non par mail le compte-rendu global. Les actions sont :

• diffuser le compte-rendu par mail aux instances de la réunion (aux différentes adresses paramétrées dans les instances et dans le champ « liste de diffusion »),
• générer et finaliser le compte-rendu (stockage du document),
• générer et finaliser l’ordre du jour (stockage du document),
• noter la réunion comme clôturée.

Charger les fichiers numérisés

Cet écran permet de charger dans la réunion le « compte-rendu global » signé numérisé ainsi que le document rassemblant l’ensemble des « compte-rendus par dossier » signés numérisé. Cette action est disponible seulement une fois que la réunion est clôturée.

Supprimer une réunion

Cet écran permet de supprimer la réunion. Cette action est disponible seulement si aucun dossier planifié à cette réunion n’a d’avis rendu.

Lors de la suppression, toutes les demandes de passages qui lui étaient affectées seront désaffectées et réapparaîtront dans le pool des demandes de passage pour être planifié à une autre réunion.

Pilotage

Statistiques

(Suivi ‣ Pilotage ‣ Statistiques)

Etat des lieux des élements

Réalisés sur l’année courante

• Visites réalisées

Nombre de visites programmées depuis le début de l’année : c’est le nombre total de visites dont la date est dans l’année courante du service de l’utilisateur.

• Visites réalisées

Nombre de visites réalisées depuis le début de l’année : c’est le nombre total de visites dont la date est inférieure à la date du jour et est dans l’année courante moins le nombre de visites annulées dont la date est inférieure à la date du jour et est dans l’année courante pour le service de l’utilisateur.

• Plans étudiés

Nombre de dossiers de plan étudiés depuis le début de l’année : c’est le nombre de dossier d’instruction dont le type est PLAN et dont la date de clôture est dans l’année courante pour les dossiers d’instruction qui concernent le service de l’utilisateur.

• Avis

Nombre d’avis défavorables et favorables émis (avec détail par type de dossier) : nombre de passage en réunion de commission plénière dont l’avis est DEFAVORABLE, et nombre de passage en réunion de commission plénière dont l’avis est DEFAVORABLE dont la date de réunion de commission est dans l’année courante pour les dossiers d’instruction qui concernent le service de l’utilisateur.

En cours

• Visites en retard

Nombre de visites en retard (avec détail par type et catégorie d’établissement) : nombre d’établissements dont la date de la prochaine visite est passée.

• Dossiers en cours

Nombre de dossiers en cours : c’est le nombre de dossiers d’instruction qui ne sont ni clôturés ni à qualifier.

• AP en cours

Nombre de dossiers avec autorité de police en cours : c’est le nombre de dossiers de coordination dont le champ « autorité de police en cours » est à oui et dont une des décisions d’autorité de police concerne le service de l’utilisateur.

• Délai moyen d’instruction

Moyenne de la date de clôture du dossier moins sa date d’ouverture pour ceux clôturés il y a moins de six mois.

• Délai moyen de suivi d’une autorité de police

Moyenne sur les six derniers mois glissants de la date de clôture du dossier moins la date du premier passage en commission pour les dossiers comportant au moins une autorité de police sur les six derniers mois.

• Délai moyen de notification par courrier

Moyenne de la date de première présentation d’un courrier moins la date d’envoi du courrier.

• Dossiers par type et par statut

Nombre de dossiers d’instruction : par type (plan, visite) et statut (à qualifier, …).

Editions

Il est possible de générer une édition de ces données pour une année particulière (actuelle par défaut).

Cela crée un fichier PDF comportant les tableaux suivants :

Visites réalisées

• par type et catégorie d’établissement
• par type de dossier et catégorie d’établissement

Avis rendus

• par avis et type d’établissement
• par avis et catégorie d’établissement

Décisions d’autorité de police

• par décision et catégorie d’établissement

Etudes de plan

• par type et catégorie d’établissement
• par type de réunion et type d’établissement

Requêtes mémorisées

(Suivi ‣ Pilotage ‣ Requêtes mémorisées)

Le module “requêtes mémorisées” permet d’exporter des données de l’application parmi les éléments suivants :

Chaque export peut être paramétré selon les critères ci-après :

• tri (choix d’un champ)
• format de sortie (fichier CSV ou tableau à l’écran)
• si CSV le séparateur de champs (virgule, point-virgule ou pipe)
• si tableau le nombre maximum d’enregistrements

Administration et paramétrage

Etablissements

Type

Typologie d’un établissement représentant son activité.

Catégories

Liste des catégories d’un établissement représentant sa capacité.

Natures

Liste des natures d’un établissement (ERP Référentiel, ERP non référentiel, Bâtiment non ERP, …).

Codes :

États

Liste des états d’un établissement (Ouvert, Fermé, Non suivi, …).

Codes :

Statut juridique

Liste des statuts juridiques d’un établissement (ville, public, privé, …).

Codes :

Tutelle administrative

Liste des tutelles administratives d’un établissement lorsque son statut juridique est “public” ou du code “PUB”.

Périodicité de Visite

Paramétrage de la périodicité des visites obligatoires à réaliser sur les établissements de nature “ERP référentiel”.

La périodicité des visites s’applique sur les établissements dont la nature est “ERP Référentiel” (etablissement_nature_periodique : paramètre correpondant au code de la nature “ERPR”) et dans l’état “Ouvert” (etablissement_etat_periodique : paramètre correpondant au code de l’état “OUVE”).

Un dossier de coordination de type “Visite Périodique de Sécurité” (dossier_coordination_type_periodique : paramètre correpondant au code du type de dossier de coordination “VPS”) est le dossier de coordination rattaché à un établissement pour la gestion de la périodicité des visites.

Adresses

Voies

Liste des voies auxquelles sont rattachées les établissements.

Arrondissements

Liste des arrondissements auxquels sont rattachés les établissements.

Contacts

Types

Typologie d’un contact.

Codes :

• EXPL
• INST

Civilités

Liste des civilités d’un contact.

Contraintes

Listing

Liste des contraintes paramétrées et destinées à être appliquées aux établissements et dossiers de coordination. Elles peuvent provenir d’un référentiel SIG (via une synchronisation) ou être ajoutées manuellement.

Les informations spécifiques et facultatives d’une contrainte paramétrée sont :

• l’ordre d’affichage (permet de classer les contraintes appliquées à un établissement ou un dossier de coordination à l’intérieur des groupes et sous-groupes) ;
• le texte surchargé (permet d’étendre le texte standard de la contrainte à respecter).

Synchronisation

L’option SIG doit être activée pour faire apparaître cette rubrique. Effectuer une synchronisation revient à mettre à jour les contraintes paramétrées selon le référentiel SIG :

• s’il manque des contraintes dans openARIA elles sont ajoutées ;
• si des contraintes d’openARIA ne sont plus dans le référentiel elles sont archivées ;
• si des contraintes d’openARIA sont dans le référentiel elles sont mises à jour.

Seules contraintes paramétrées provenant d’un référentiel sont impactées par la synchronisation : celles ajoutées manuellement ne sont pas concernées. La synchronisation ne se fait que dans le sens SIG → openARIA : les contraintes présentes sur le référentiel ne sont pas modifiées.

Les informations d’une contrainte récupérée du SIG sont :

• identifiant dans le référentiel ;
• nature (POS/PLU/CC/RNU) ;
• groupe ;
• sous-groupe ;
• libellé ;
• texte.

Note

Lorsque l’on récupère des contraintes pour un établissement ou un dossier de coordination, openARIA est susceptible de demander une synchronisation des contraintes dans le cas où les contraintes récupérées depuis le référentiel SIG sont absentes du paramétrage.

Métiers

Services

Liste des services.

Acteurs

Liste des acteurs de l’application représentant les cadres, techniciens et secrétaires affectés à un service. Un acteur peut être rattaché à un utilisateur ou non.

Avis

Liste des avis possibles sur un dossier que ce soit en réunion, suite à une visite ou dans une analyse.

Instances

Paramétrage des instances convoquées lors des réunions ou lors des visites ainsi que de leurs membres.

Autorités compétentes

Liste des autorités compétentes d’un dossier d’instruction.

Dérogations SCDA

Liste des dérogations SCDA disponibles depuis les données techniques des établissements.

Réunions

Types

Typologie et paramétrage de toutes les informations communes à chaque réunion et qui caractérisent un type de réunion.

Catégories

Liste des catégories de dossiers traitées en réunion.

Autorités de police

Types

Typologie et paramétrage d’une décision d’autorité de police notamment les délais.

Motifs

Liste des motifs d’une décision d’autorité de police.

Analyses

Types

Typologie et paramétrage des analyses notamment les modèles d’éditions associés.

Essais réalisés

Textes types disponibles à l’insertion depuis le formulaire de saisie des essais réalisés lors de l’analyse des dossiers d’instruction.

Documents présentés

Textes types disponibles à l’insertion depuis le formulaire de saisie des documents présentés lors de l’analyse des dossiers d’instruction.

Réglementations applicables

Textes types disponibles à l’insertion depuis le formulaire de saisie des réglementation applicables lors de l’analyse des dossiers d’instruction.

Prescriptions

Paramétrage des prescriptions réglementaires et spécifiques utilisées dans les analyses des dossiers d’instruction.

Documents entrants

Types

Typologie d’un document entrant.

Documents générés

Compléments

Textes types disponibles à l’insertion depuis le formulaire de saisie d’un document généré dans les champs compléments.

Qualités de signataire

Liste des qualités d’un signataire.

Signataires

Paramétrage des signataires disponibles depuis un document généré ou un PV.

Visites

Durées

Liste des durées de visite.

Motifs d’annulation

Liste des motifs d’annulation d’une visite.

Dossiers

Types

Typologie des types de dossiers de coordination (Visites, Plans, …).

Types de DC

Typologie et paramétrage des dossiers de coordination (AT, PC, Visite périodque, …).

Éditions

Types

Typologie et paramétrage d’un modèle d’édition qui permet de filtrer les modèles d’édition disponibles en fonction du contexte des interfaces.

Catégories

Paramétrage des catégories de types de modèles d’édition. Cette catégorisation permet de définir le contexte dans lequel les types de modèles d’édtion rattachés à cette catégorie vont être disponibles.

Modèles d’édition

Paramétrage des modèles d’édition par la sélection de leur type et de la lettre type utilisée.

Lettres types

Composition des lettres types.

Logos

Paramétrage des logos disponibles depuis l’écran de composition des lettres types.

Sous-états

Paramétrage des tableaux (appelés sous-états) disponibles à l’insertion depuis l’écran de composition des lettres types.

Requêtes

Paramétrage des configurations de champs de fusion disponibles depuis l’écran de composition des lettres types.

Général

Collectivités

Paramétrage des collectivités.

Paramètres

Divers paramètres de l’application : champs de fusion généraux disponibles pour les éditions pdf, activation/désactivation de modules complémentaires, paramétrages fonctionnels, …

Utilisation des options :

• option_sig : la valeur par défaut est aucun. Les valeurs possibles sont sig_externe, sig_interne ou aucun.
• option_referentiel_patrimoine : Interface avec le référentiel patrimoine
• swrod : Module “swrod”
• option_referentiel_ads : Interface avec le référentiel ADS
• dc_a_qualifier_redlimit : c’est le nombre de jours depuis la date de la demande à partir duquel les enregistrements dans le listing des DC à qualifier et dans le widget des DC à qualifier apparaissent en rouge. Si le paramètre n’est pas positionné alors la valeur par défaut est de 15 jours. Dossiers à qualifier
• template__proces_verbal_numero : Par défaut : [ANNEE]/[CHRONO]. Les variables de remplacement disponibles sont : [ANNEE] (“2017” année du PV sur 4 caractères), [CHRONO] (“00123” séquence du procès verbal pour le service pour l’année du PV).
• template__proces_verbal_numero_complet : Par défaut : [CODE_SERVICE]-[PROCES_VERBAL_NUMERO]. Les variables de remplacement disponibles sont : [CODE_SERVICE] (“SI” ou “ACC” le code du service émetteur en majuscule), [PROCES_VERBAL_NUMERO] (le numéro officiel du procès verbal selon le template ci-dessus).
• template__arrete_numero : Par défaut : [ANNEE]_[CHRONO]_ERP. Les variables de remplacement disponibles sont : [ANNEE] (“2017” année de l’arrêté sur 4 caractères), [CHRONO] (“00123” séquence de l’arrêté pour cette année).

Gestion des utilisateurs

Profils

Paramétrage des profils utilisateurs et de toutes les permissions qui y sont associées.

Utilisateurs

Paramétrage des utilisateurs autorisés à se connecter à l’application.

Tableaux de bord

Widgets

Paramétrage des blocs d’informations affichables sur le tableau de bord.

Composition

Composition des tableaux de bord par profil.

Options avancées

Géolocalisation

Si un SIG externe est paramétré, il est possible de géolocaliser l’ensemble des établissements et des dossiers de coordination, en un seul clic.

Un message de validation fait apparaître le nombre d’éléments qui ont pu être géolocalisés automatiquement par le SIG, ainsi que le nombre d’éléments qui n’ont pas pu être géolocalisés. Pour les éléments qui ne sont pas géolocalisables automatiquement (dont les informations sont inconnues du SIG), il est possible de dessiner manuellement l’élément sur le SIG. Pour cela, il faut se rendre directement sur l’établissement ou le dossier de coordination.

Import

Ce module permet l’intégration de données dans l’application depuis des fichiers CSV.

Import des établissements

Les établissements peuvent être ajoutés depuis un fichier CSV. Un fichier CSV modèle est disponible sur le formulaire d’import.

Note

Il est nécessaire de mettre à jour manuellement la séquence de l’établissement lors de l’utilisation de cet import CSV.

Note

Même lorsqu’un Système d’Information Géographique est paramétré les établissements ne sont pas géolocalisés automatiquement lors de l’import CSV. Les établissements restent géolocalisable depuis l’interface de géolocalisation de tous les établissements et des dossiers de coordination (voir Éditions Géocoder tous).

Générateur

Ce module permet la génération d’éléments à partir du modèle de données.

Guide du développeur

Guide du développeur

Stratégie

openARIA respecte la stratégie de développement SD01.

Sommaire

Tests et Intégration Continue

openARIA possède des tests unitaires et fonctionnels joués intégralement à chaque modification du code source afin d’assurer sa stabilité et sa pérennité. Tous les tests sont présents dans le répertoire tests/. Deux frameworks de test sont utilisés : RobotFramework et PHPUnit. http://openmairie.readthedocs.io/projects/omframework/fr/latest/reference/tests_ci/index.html

Écrire un TestSuite RobotFramework

Créer le fichier exemple.robot dans le répertoire tests/.

Copier/Coller le code suivant dans le fichier créé :

*** Settings ***
Resource  resources/resources.robot
Suite Setup  For Suite Setup
Suite Teardown  For Suite Teardown
Documentation  La programmations des visites...


*** Test Cases ***
Exemple de testcase

    Depuis la page d'accueil  admin  admin
    Log  Je suis authentité en tant qu'utilisateur 'admin'

Exécuter la commande :

./om-tests -c runone -t exemple.robot

Ressources

Les ressources sont des librairies de mots-clés RobotFramework.

Voici la documentation des librairies spécifiques à openARIA :

Librairie de l’application openARIA App.

Librairie du framework openMairie Core.

Voici les documentations des librairies génériques utilisées par openARIA :

• Base - BuiltIn : http://robotframework.org/robotframework/latest/libraries/BuiltIn.html
• Base - String : http://robotframework.org/robotframework/latest/libraries/String.html
• Base - Collections : http://robotframework.org/robotframework/latest/libraries/Collections.html
• Base - OperatingSystem : http://robotframework.org/robotframework/latest/libraries/OperatingSystem.html
• Selenium2 : http://rtomac.github.io/robotframework-selenium2library/doc/Selenium2Library.html
• Requests : http://bulkan.github.io/robotframework-requests/
• Selenium2Screenshots : https://robotframework-selenium2screenshots.readthedocs.org/en/latest/_downloads/keywords.html

Interface avec le référentiel patrimoine

Voir les apports de la fonctionnalité dans l’interface utilisateur :

• Formulaire de l’établissement

Configuration du module

dyn/services.inc.php

<?php
$URL_REFERENTIEL_PATRIMOINE_EQUIPEMENT = "";
?>

Activation de l’option

Pour que l’option soit activée, il est nécessaire de se rendre dans le menu “Administration & Paramétrage > Paramètres” et d’ajouter/de modifier le paramètre option_referentiel_patrimoine pour lui affecter la valeur “true”.

Interface avec le référentiel ADS

Interface avec le logiciel openADS : http://www.openmairie.org/catalogue/openads

Note

Il est nécessaire d’utiliser au minimum la version 3.36.0 d’openADS pour le fonctionnement de cette interface.

Configuration du module

Configuration des URLs des échanges sortants vers le référentiel ADS :

dyn/services.inc.php

$ADS_URL_MESSAGES = 'http://openads/services/rest_entry.php/messages/';
$ADS_URL_DOSSIER_AUTORISATIONS = 'http://openads/services/rest_entry.php/dossier_autorisations/';
$ADS_URL_DOSSIER_INSTRUCTIONS = 'http://openads/services/rest_entry.php/dossier_instructions/';
$ADS_URL_CONSULTATIONS = 'http://openads/services/rest_entry.php/consultations/';
$ADS_URL_VISUALISATION_DA = 'http://openads/app/web_entry.php?obj=dossier_autorisation&value=<ID_DA>';

Configuration des paramètres des déclencheurs :

• ads__liste_services__si : correspond à la liste des codes représentant le service ERP Sécurité Incendie tel qu’ils sont définis dans la colonne “abrégé” du paramétrage des services d’openADS par exemple « Service Pr;ERPSI »
• ads__liste_services__acc : correspond à la liste des codes représentant le service ERP Accessibilité tel qu’ils sont définis dans la colonne “abrégé” du paramétrage des services d’openADS par exemple « Division d;ERPACC »

Types de DC nécessaires au bon fonctionnement du module:

• PC
• AT
• VR
• DAACT

Il faut renseigner la catégorie des avis pour permettre d’établir une correspondance entre les avis d’openARIA et les avis du référentiel ADS:

• Voir le menu “administration & paramétrage > métiers > avis”.

Activation de l’option

Activation de l’option dans l’interface :

om_parametre

• option_referentiel_ads -> true

Les échanges

[101](Échange ADS → ERP) Dossier AT Information de qualification ADS

L’objectif principal de cet échange est de permettre à l’instructeur ADS de transmettre facilement les informations d’autorité compétente et de contraintes PLU (de compétence URBA) du dossier AT aux services ERP.

Identifiant : ADS_ERP__AT__INFORMATION_DE_QUALIFICATION_ADS

Cas d’utilisation :

• Suite à la qualification des informations d’autorité compétente et de contraintes PLU par l’instructeur ADS sur le dossier dans openADS, l’information est transmise à titre d’information sur le dossier dans openARIA.

Déclencheur :

• Web Service exposé

Traitement :

• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 1.

Contenu de l’échange :

• type : Type de message
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction
• contenu :
  • competence : Compétence : texte : Qualification compétence : Mairie/Etat
  • contraintes_plu : Contraintes PLU : texte multilignes reprenant les contraintes PLU du dossier
  • references_cadastrales :

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type" : "ADS_ERP__AT__INFORMATION_DE_QUALIFICATION_ADS",
    "date" : "31/12/2015 14:42",
    "emetteur" : "instr",
    "dossier_instruction" : "PC0130551600001P0",
    "contenu" : {
        "competence" : "",
        "contraintes_plu" : "",
        "references_cadastrales" : ""
    }
}

[102](Échange ADS → ERP) Dossier PC/ERP Pré-demande de complétude ERP

L’objectif principal de cet échange est de permettre à l’instructeur ADS de gagner du temps dans sa vérification de complétude et d’interroger rapidement les services ERP sur la complétude du dossier.

Identifiant : ADS_ERP__PC__PRE_DEMANDE_DE_COMPLETUDE_ERP

Cas d’utilisation :

• Un dossier PC qui concerne un ERP est identifié dans openADS, l’instructeur ADS souhaite obtenir avant la consultation officielle du service une pré-complétude par les services ERP. Une notification permet donc la création d’un dossier PLAN à qualifier dans openARIA.

Déclencheur :

• Web Service exposé

Traitement :

• Création de DC (PC-PLAN) possible : Si le message [103] n’est pas arrivé avant alors un dossier de coordination de type PC PLAN est créé.
• Récupération des informations sur le DI ADS : Via l’échange [212] récupération de la localisation des travaux (adresse, références cadastrales) et récupération du ou des demandeurs.
• Marquage du dossier DC (PC-PLAN) : Le marqueur « connecté avec le référentiel ADS » sur le dossier créé est positionnée à « OUI » afin de pouvoir identifier ce dossier à l’avenir.
• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.

Contenu de l’échange :

• type : Type de message
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type" : "ADS_ERP__PC__PRE_DEMANDE_DE_COMPLETUDE_ERP",
    "date" : "31/12/2015 14:42",
    "emetteur" : "instr",
    "dossier_instruction" : "PC0130551600001P0"
}

[103](Échange ADS → ERP) Dossier PC/ERP Pré-demande de qualification ERP

L’objectif principal de cet échange est de permettre à l’instructeur ADS de gagner du temps dans sa qualification de dossier et d’interroger rapidement les services ERP sur le caractère ERP du dossier.

Identifiant : ADS_ERP__PC__PRE_DEMANDE_DE_QUALIFICATION_ERP

Cas d’utilisation :

• Un dossier PC qui concerne un ERP est identifié dans openADS, l’instructeur ADS souhaite obtenir avant la consultation officielle du service une pré-qualification par les services ERP. Une notification permet donc la création d’un dossier PLAN à qualifier dans openARIA.

Déclencheur :

• Web Service exposé

Traitement :

• Création de DC (PC-PLAN) possible : Si le message [102] n’est pas arrivé avant, alors un dossier de coordination de type PC PLAN est créé.
• Récupération des informations sur le DI ADS : Via l’échange [212] récupération de la localisation des travaux (adresse, références cadastrales) et récupération du ou des demandeurs.
• Marquage du dossier DC (PC-PLAN) : Le marqueur « connecté avec le référentiel ADS » sur le dossier créé est positionnée à « OUI » afin de pouvoir identifier ce dossier à l’avenir.
• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.

Contenu de l’échange :

• type : Type de message
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type" : "ADS_ERP__PC__PRE_DEMANDE_DE_QUALIFICATION_ERP",
    "date" : "31/12/2015 14:42",
    "emetteur" : "instr",
    "dossier_instruction" : "PC0130551600001P0"
}

[104](Échange ADS → ERP) Dossier PC/ERP Consultation officielle pour avis

L’objectif principal de cet échange est de permettre à l’instructeur ADS d’émettre une consultation officielle pour avis des services ERP.

Identifiant : ADS_ERP__PC__CONSULTATION_OFFICIELLE_POUR_AVIS

Cas d’utilisation :

• Un dossier PC qui concerne un ERP est identifié dans openADS, l’instructeur ADS a lancé la consultation officielle du service. Une notification permet donc la création d’un dossier PLAN à qualifier dans openARIA ou le rattachement à un dossier existant si une pré-qualification a été réalisée.

Déclencheur :

• Web Service exposé

Traitement :

• Création de DC (PC-PLAN) possible : Si le message [102] ou le [103] n’est pas arrivé avant, alors un dossier de coordination de type PC PLAN est créé.
• Récupération des informations sur le DI ADS : Via l’échange [212] récupération de la localisation des travaux (adresse, références cadastrales) et récupération du ou des demandeurs.
• Marquage du dossier DC (PC-PLAN) : Le marqueur « connecté avec le référentiel ADS » sur le dossier créé est positionnée à « OUI » afin de pouvoir identifier ce dossier à l’avenir.
• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.

Contenu de l’échange :

• type : Type de message
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction
• contenu :
  • consultation : Identifiant de la consultation
  • service_abrege : Code du service consulté
  • service_libelle : Libellé du service consulté
  • date_envoi : Date d’envoi de la consultation
  • date_limite : Date limite de réponse

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type" : "ADS_ERP__PC__CONSULTATION_OFFICIELLE_POUR_AVIS",
    "date" : "31/12/2015 14:42",
    "emetteur" : "instr",
    "dossier_instruction" : "PC0130551600001P0",
    "contenu" : {
        "consultation" : 2,
        "date_envoi" : "31/12/2015",
        "service_abrege" : "ACC",
        "service_libelle" : "Service Accessibilité",
        "date_limite" : "31/01/2016",
    }
}

[105](Échange ADS → ERP) Dossier PC/ERP Information de décision ADS

L’objectif principal de cet échange est de permettre d’informer les services ERP de certaines étapes importantes de la vie du dossier : arrêté effectué, retrait du dossier par le pétitionnaire, …

Identifiant : ADS_ERP__PC__INFORMATION_DE_DECISION_ADS

Cas d’utilisation :

• Suite à un échange [102] et/ou [103] et/ou [104] (demande d’instruction d’un dossier PC par ADS), une étape importante survient sur le dossier (retrait par le pétitionnaire, arrêté de refus émis, …) et les services ADS souhaitent en informer les services ERP. Lors de cette étape, un message d’information est envoyé aux services ERP.

Déclencheur :

• Web Service exposé

Traitement :

• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 3.

Contenu de l’échange :

• type : Type de message
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction
• contenu :
  • decision : Décision : texte libre (Décision de l’arrêté)

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type" : "ADS_ERP__PC__INFORMATION_DE_DECISION_ADS",
    "date" : "31/12/2015 14:42",
    "emetteur" : "instr",
    "dossier_instruction" : "PC0130551600001P0",
    "contenu" : {
        "decision" : ""
    }
}

[106](Échange ADS → ERP) Dossier PC/ERP Consultation officielle pour conformité

L’objectif principal de cet échange est de permettre à l’instructeur ADS de gagner du temps dans sa consultation officielle pour conformité des services ERP.

Identifiant : ADS_ERP__PC__CONSULTATION_OFFICIELLE_POUR_CONFORMITE

Cas d’utilisation :

• Lorsqu’ADS interroge les services ERP sur la conformité (lors du dépôt d’une DAACT).

Déclencheur :

• Web Service exposé

Traitement :

• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Création de DC (DAACT-PLAN) : Il sera automatiquement qualifié en fonction de la qualification du plan DC (PC-PLAN) auquel il est rattaché.

Contenu de l’échange :

• type : Type de message « Consultation ERP pour conformité »
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction
• contenu :
  • consultation : Identifiant de la consultation
  • service_abrege : Code du service consulté
  • service_libelle : Libellé du service consulté
  • date_envoi : Date d’envoi de la consultation
  • date_limite : Date limite de réponse

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type" : "ADS_ERP__PC__CONSULTATION_OFFICIELLE_POUR_CONFORMITE",
    "date" : "31/12/2015 14:42",
    "emetteur" : "instr",
    "dossier_instruction" : "PC0130551600001P0",
    "contenu" : {
        "consultation" : 2,
        "date_envoi" : "31/12/2015",
        "service_abrege" : "SC",
        "service_libelle" : "Service Conformité",
        "date_limite": "31/01/2016"
    }
}

[107](Échange ADS → ERP) Dossier PC/ERP Demande de visite d’ouverture

Dans le contexte du guichet unique, l’objectif principal de cet échange est d’informer les services ERP qu’une demande de visite d’ouverture a été déposée.

Identifiant : ADS_ERP__PC__DEMANDE_DE_VISITE_D_OUVERTURE_ERP

Cas d’utilisation :

• Dans le cas où les demandes de visite d’ouverture des ERP sont saisies par le guichet unique dans openADS, alors lorsque le pétitionnaire vient déposer une demande de visite d’ouverture sur un PC qui concerne un ERP, une notification est transmise aux services ERP.

Déclencheur :

• Web Service exposé

Traitement :

• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Création de DC (VR-VISIT) possible
• Marquage du dossier DC (VR-VISIT)

Contenu de l’échange :

• type : Type de message
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type" : "ADS_ERP__PC__DEMANDE_DE_VISITE_D_OUVERTURE_ERP",
    "date" : "31/12/2015 14:42",
    "emetteur" : "instr",
    "dossier_instruction" : "PC0130551600001P0"
}

[108](Échange ADS → ERP) Dossier AT Dépôt initial

Dans le contexte du guichet unique, l’objectif principal de cet échange est d’informer les services ERP qu’une demande d’autorisation de travaux a été déposée.

Identifiant : ADS_ERP__AT__DEPOT_INITIAL

Cas d’utilisation :

Un pétitionnaire est venu déposé une demande d’autorisation de travaux au guichet unique et la demande a été saisie dans openADS, un message est donc transmis à openARIA. L’arrivée de ce message entraîne dans openARIA la création d’un dossier de coordination de type AT PLAN dans l’état “à qualifier” pour que le coordinateur ERP le voit apparaître dans son tableau de bord et puisse le prendre en charge.

Déclencheur :

• Web Service exposé

Traitement :

• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.

Traitement asynchrone :

Note

Un traitement asynchrone est nécessaire ici. En effet, nous sommes dans le contexte du guichet unique. L’échange est transmis par le référentiel ADS au référentiel ERP lors de la validation de la demande au guichet unique. Le dossier n’existe pas encore à ce moment là. Le formulaire de valaidation de la demande attend une confirmation de bonne réception de l’échange par le référentiel ERP afin de valider sa transaction et de créer effectivement le dossier rattaché à la demande. Il est donc impossible pour le référentiel ERP d’interroger le référentiel ADS sur un dossier pour obtenir ses informations alors qu’il n’a pas été encore effectivement créé dans celui-ci à ce moment là. L’objet du traitement asynchrone est donc de limiter le traitement synchrone à la création du message et d’avoir une méthode de traitement qui parcourt les messages non traités pour réaliser sur ces derniers les opérations nécessaires. Voir : Web Service Maintenance de déclenchement des traitements de messages asynchrones

• Création de DC (AT-PLAN) : Un dossier de coordination de type AT-PLAN est créé.
• Récupération des informations sur le DI ADS : Via l’échange [212] récupération de la localisation des travaux (adresse, références cadastrales) et récupération du ou des demandeurs.
• Marquage du dossier DC (AT-PLAN) : Le marqueur « connecté avec le référentiel ADS » sur le dossier créé est positionnée à « OUI » afin de pouvoir identifier ce dossier à l’avenir.

Contenu de l’échange :

• type : Type de message
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type" : "ADS_ERP__AT__DEPOT_INITIAL",
    "date" : "31/12/2015 14:42",
    "emetteur" : "guichet",
    "dossier_instruction" : "AT0130551600001P0"
}

[109](Échange ADS → ERP) Dossier AT Retrait du pétitionnaire

Dans le contexte du guichet unique, l’objectif principal de cet échange est d’informer les services ERP qu’une demande de retrait d’autorisation de travaux a été déposée.

Identifiant : ADS_ERP__AT__RETRAIT_DU_PETITIONNAIRE

Cas d’utilisation :

• Le pétitionnaire dépose une demande de retrait au guichet unique sur un dossier connecté au référentiel ERP. Lors de la saisie de cette demande dans openADS, une notification est émise vers openARIA pour que les services ERP soient informés et puissent agir en conséquence.

Déclencheur :

• Web Service exposé

Traitement :

• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 3.

Contenu de l’échange :

• type : Type de message
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type" : "ADS_ERP__AT__RETRAIT_DU_PETITIONNAIRE",
    "date" : "31/12/2015 14:42",
    "emetteur" : "guichet",
    "dossier_instruction" : "AT0130551600001P0"
}

[110](Échange ADS → ERP) Dossier AT Demande de visite d’ouverture

Dans le contexte du guichet unique, l’objectif principal de cet échange est d’informer les services ERP qu’une demande de visite d’ouverture a été déposée.

Identifiant : ADS_ERP__AT__DEMANDE_DE_VISITE_D_OUVERTURE_ERP

Cas d’utilisation :

• Suite à une autorisation de travaux acceptée, le pétitionnaire dépose une demande de visite d’ouverture (de réception de travaux) au guichet unique en fournissant la référence de l’autorisation en question.

Déclencheur :

• Web Service exposé

Traitement :

• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Création de DC (VR-VISIT) possible : Lié (dossier parent) au DC (AT-PLAN) correspondant au dossier AT sur lequel la demande de visite a été déposée. Création automatique d’un DC de visite de réception lié (dossier parent) au DC AT correspondant au dossier AT sur lequel la visite de réception a été déposée. Un seul dossier VISIT peut être connecté au référentiel ADS sur le même dossier AT.
• Marquage du dossier DC (VR-VISIT)

Contenu de l’échange :

• type : Type de message
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type" : "ADS_ERP__AT__DEMANDE_DE_VISITE_D_OUVERTURE_ERP",
    "date" : "31/12/2015 14:42",
    "emetteur" : "guichet",
    "dossier_instruction" : "AT0130551600001P0"
}

[111](Échange ADS → ERP) Dossier PC/ERP Information de décision Conformité

L’objectif principal de cet échange est de permettre d’informer les services ERP de certaines étapes importantes de la vie du dossier : arrêté effectué, retrait du dossier par le pétitionnaire, …

Identifiant : ADS_ERP__PC__DECISION_DE_CONFORMITE_EFFECTUEE

L’échange [105] a été rendu plus générique et permet de réaliser l’objectif de cet échange. Celui-ci a donc été supprimé.

[112](Échange ADS → ERP) Dossier AT Dépôt de pièce par le pétitionnaire

Dans le contexte du guichet unique, l’objectif principal de cet échange est d’informer les services ERP qu’un dépôt de pièces a été fait.

Identifiant : ADS_ERP__AT__DEPOT_DE_PIECE_PAR_LE_PETITIONNAIRE

Cas d’utilisation :

• Le pétitionnaire dépose des pièces complémentaires ou supplémentaires au guichet unique sur un dossier connecté au référentiel ERP. Lors de la saisie de cette demande dans openADS, une notification est émise vers openARIA pour que les services ERP soient informés et puissent agir en conséquence.

Déclencheur :

• Web Service exposé

Traitement :

• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 3.

Contenu du message :

• type : Type de message
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction
• contenu :
  • type_piece : Si le Dossier d’instruction est ouvert, alors les pièces sont acceptées (si le dossier est « incomplet » les pièces sont classées « complémentaires », sinon les pièces sont classées « supplémentaires »). Dans les deux cas, openADS envoie automatiquement un message unique à openARIA signalant l’arrivée d’une pièce sur le dossier et son statut : pièce « complémentaire » ou « supplémentaire ».

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type" : "ADS_ERP__AT__DEPOT_DE_PIECE_PAR_LE_PETITIONNAIRE",
    "date" : "31/12/2015 14:42",
    "emetteur" : "admin",
    "dossier_instruction" : "AT0130551600001P0",
    "contenu": {
        "type_piece" : "complémentaire"
    }
}

[113](Échange ADS → ERP) Ajout d’une nouvelle pièce numérisée

L’objectif principal de cet échange est de permettre aux services ERP d’être informé de la numérisation d’une pièce sur un dossier sur lequel ils sont impliqués.

Identifiant : ADS_ERP__AJOUT_D_UNE_NOUVELLE_PIECE_NUMERISEE

Cas d’utilisation :

• Lorsque des documents numérisés concernant des dossiers qui concernent ERP, une notification permet d’informer les services ERP que les documents sont disponibles en ligne pour leur indiquer que la qualification est possible.

Déclencheur :

• Web Service exposé

Traitement :

• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0. (Cependant la création de ce message entraîne la création/mise à jour d’un autre message de catégorie « interne » qui lui est marqué comme non lu par défaut. L’objectif est de ne pas avoir 14 messages à lire lors de la numérisation de 14 pièces sur le même dossier.)
• Mise à jour du marqueur indiquant le dépôt des pièces

Contenu de l’échange :

• type : Type de message
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction
• contenu :
  • date_creation : Date de création
  • nom_fichier : Nom du fichier : texte
  • type : Type de document : texte
  • categorie : Catégorie du type de document

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type" : "ADS_ERP__AJOUT_D_UNE_NOUVELLE_PIECE_NUMERISEE",
    "date" : "31/12/2015 14:42",
    "emetteur" : "admin",
    "dossier_instruction" : "AT0130551600001P0",
    "contenu": {
        "date_creation" : "31/12/2015",
        "nom_fichier" : "DGIMPC.pdf",
        "type" : "Imprimé de demande de permis de construire",
        "categorie" : "Définition Générale"
    }
}

[114](Échange ADS → ERP) Dossier PC Notification de dossier à enjeux ADS

L’objectif principal de cet échange est de permettre aux services ADS de partager le caractère “à enjeu” du dossier pour en informer le service ERP.

Identifiant : ADS_ERP__PC__ENJEU_ADS

Cas d’utilisation :

• Un instructeur du referentiel ADS peut qualifier le dossier comme Dossier à enjeux. Dans ce cas, un message « Dossier à enjeux ADS » est envoyé vers l’application openARIA afin de mettre à jour le Dossier. La mise à jour est effectuée automatiquement et un message est attaché au dossier.

Déclencheur :

• Web Service exposé

Traitement :

• Création de message : Un message de catégorie « entrant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Mise à jour du champ “enjeu ADS” du DC en fonction de la valeur du message.

Contenu de l’échange :

• type : Type de message
• date : Date/heure d’envoi du message
• emetteur : Émetteur du message (Nom/Prénom/Login de l’utilisateur à l’origine du message)
• dossier_instruction : Identifiant du dossier d’instruction
• contenu :
  • Dossier à enjeux ADS : Oui / Non

Exemple :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type": "ADS_ERP__PC__ENJEU_ADS",
    "date": "10/01/2017 12:52",
    "emetteur": "John Doe",
    "dossier_instruction": "PC0130551600001P0",
    "contenu": {
        "Dossier à enjeu ADS": "oui"
    }
}

[201](Échange ERP → ADS) Mise à jour du numéro de l’établissement dans le référentiel ADS

Identifiant : ERP_ADS__MAJ_NUMERO_ERP_DOSSIER_AUTORISATION

Cas d’utilisation :

• Un arrêté d’ouverture ERP est signé. Le numéro de l’établissement est transmis au logiciel ADS pour mise à jour du référentiel.

Déclencheur :

• L’option ADS est activée
• Le dossier est marqué comme « connecté au référentiel ADS »
• Un document généré signé de type « Arrêté » est ajouté (Validation du formulaire de modification du document généré avec ajout d’un fichier signé alors que le champ était vide au préalable)

Traitement :

• Création de message : Un message de catégorie « sortant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Envoi de la requête à destination de la ressource “dossier_autorisations” d’openADS. Configuration des échanges sortants

Contenu de l’échange :

• numero_erp : c’est le code de l’établissement au format entier (exemple : “3498”).

Exemple :

PUT /openads/services/rest_entry.php/dossier_autorisations/PC0130551601234 HTTP/1.1
Host: localhost

{
    "numero_erp":"12345"
}

[202](Échange ERP → ADS) Mise à jour du statut ouvert de l’établissement dans le référentiel ADS

Identifiant : ERP_ADS__MAJ_STATUT_ERP_DOSSIER_AUTORISATION

Cas d’utilisation :

• Un arrêté d’ouverture ERP est signé. Cette information ainsi que la date sont transmis au logiciel ADS pour mise à jour du référentiel.

Déclencheur :

• L’option ADS est activée
• Mise à jour au moment de la notification de la décision (arrêté) d’ouverture uniquement.

Traitement :

• Création de message : Un message de catégorie « sortant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Envoi de la requête à destination de la ressource “dossier_autorisations” d’openADS. Configuration des échanges sortants

Contenu de l’échange :

• erp_ouvert : Marqueur signifiant l’ouverture de l’établissement (booléen : “oui” / “non”).
• date_arrete : Date de la décision d’ouverture (Format : 12/01/2015).

Exemple :

PUT /openads/services/rest_entry.php/dossier_autorisations/PC0130551601234 HTTP/1.1
Host: localhost

{
    "erp_ouvert":"oui",
    "date_arrete":"12/01/2015"
}

[203](Échange ERP → ADS) Récupération des informations depuis le référentiel ADS

Identifiant : ERP_ADS__RECUPERATION_INFORMATIONS_DOSSIER_AUTORISATION

Cas d’utilisation :

• Lors de la saisie manuelle d’un DA ADS dans le formulaire du DC, on vérifie que ce dossier existe bien dans le référentiel ADS.
• Lors de la réception d’un message qui concerne un DA ADS, on récupère les informations qui le concerne pour éviter une resaisie dans openARIA.

Traitement :

• Envoi de la requête à destination de la ressource “dossier_autorisations” d’openADS. Configuration des échanges sortants

Exemple :

GET /openads/services/rest_entry.php/dossier_autorisations/PC0130551601234 HTTP/1.1
Host: localhost

[204](Échange ERP → ADS) Dossier PC/ERP Information sur la complétude ERP Accessibilité

L’objectif principal de cet échange est de permettre aux services ERP d’apporter une réponse à l’échange [102] et d’informer l’instructeur ADS sur la complétude ERP du dossier.

Identifiant : ERP_ADS__PC__INFORMATION_COMPLETUDE_ERP_ACCESSIBILITE

Cas d’utilisation :

• Cet échange ne concerne que le PC de type PLAN. Le service ERP Accessibilité indique au service ADS si le dossier est complet ou pas. Un délai de 15 jours est prévu, mais n’est pas géré coté ADS : tous les messages provenant du logiciel ERP sont acceptés dans openADS, y compris hors délais. Pour pouvoir effectuer cette réponse le service ERP a accès aux pièces nécessaires du dossier ADS via la GED.

Déclencheur :

• L’option ADS est activée
• Le dossier est marqué comme « connecté au référentiel ADS »
• Le DC est un PC-PLAN
• Le formulaire de complétude/incomplétude est validé sur le DI ACC

Traitement :

• Création de message : Un message de catégorie « sortant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Envoi de la requête à destination de la ressource “messages” d’openADS. Configuration des échanges sortants

Contenu de l’échange :

• contenu :
  • libelle « Complétude ERP ACC » : valeur : « oui/non »
  • libelle « Motivation Complétude ERP ACC » : valeur : texte libre multi-lignes

Exemple :

POST /openads/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type": "ERP_ADS__PC__INFORMATION_COMPLETUDE_ERP_ACCESSIBILITE",
    "date": "16/06/2014 14:12",
    "emetteur": "John Doe",
    "dossier_instruction": "PD12R0001",
    "contenu": {
        "Complétude ERP ACC": "non",
        "Motivation Complétude ERP ACC": "Lorem ipsum dolor sit amet..."
    }
}

[205](Échange ERP → ADS) Dossier PC/ERP Information sur la complétude ERP Sécurité

L’objectif principal de cet échange est de permettre aux services ERP d’apporter une réponse à l’échange [102] et d’informer l’instructeur ADS sur la complétude ERP du dossier.

Identifiant : ERP_ADS__PC__INFORMATION_COMPLETUDE_ERP_SECURITE

Cas d’utilisation :

• Cet échange ne concerne que le PC de type PLAN. Le service ERP Sécurité indique au service ADS si le dossier est complet ou pas. Un délai de 15 jours est prévu, mais n’est pas géré coté ADS : on accepte tous les messages y compris hors délais. Pour pouvoir effectuer cette réponse le service ERP a accès aux pièces nécessaires du dossier ADS via la GED.

Déclencheur :

• L’option ADS est activée
• Le dossier est marqué comme « connecté au référentiel ADS »
• Le DC est un PC-PLAN
• Le formulaire de complétude/incomplétude est validé sur le DI SI

Traitement :

• Création de message : Un message de catégorie « sortant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Envoi de la requête à destination de la ressource “messages” d’openADS. Configuration des échanges sortants

Contenu de l’échange :

• contenu :
  • libelle « Complétude ERP SECU » : valeur : « oui/non »
  • libelle « Motivation Complétude ERP SECU » : valeur : texte libre multi-lignes

Exemple :

POST /openads/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type": "ERP_ADS__PC__INFORMATION_COMPLETUDE_ERP_SECURITE",
    "date": "16/06/2014 14:12",
    "emetteur": "John Doe",
    "dossier_instruction": "PD12R0001",
    "contenu": {
        "Complétude ERP SECU": "oui",
        "Motivation Complétude ERP SECU": "Lorem ipsum dolor sit amet..."
    }
}

[206](Échange ERP → ADS) Dossier PC/ERP Information sur la qualification ERP

L’objectif principal de cet échange est de permettre aux services ERP d’apporter une réponse à l’échange [103] et d’informer l’instructeur ADS sur le caractère ERP du dossier.

Identifiant : ERP_ADS__PC__INFORMATION_QUALIFICATION_ERP

Cas d’utilisation :

• Cet échange ne concerne que le PC de type PLAN.
• Le service ERP répond à une demande de qualification d’un dossier ADS. Il renseigne le type et la catégorie ERP. Ces informations enrichiront le Référentiel Autorisations lorsqu’elles seront actualisées dans le Dossier d’Instruction par l’instructeur.

Déclencheur :

• L’option ADS est activée
• Le dossier est marqué comme « connecté au référentiel ADS »
• Le DC est un PC-PLAN
• Le formulaire de qualification est validé

Traitement :

• Création de message : Un message de catégorie « sortant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Envoi de la requête à destination de la ressource “messages” d’openADS. Configuration des échanges sortants

Contenu de l’échange :

• contenu :
  • Confirmation ERP : oui/non (le Dossier est bien/n’est pas un ERP)
  • Type de dossier ERP : texte libre
  • Catégorie de dossier ERP : texte libre

Exemple :

POST /openads/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type": "ERP_ADS__PC__INFORMATION_QUALIFICATION_ERP",
    "date": "16/06/2014 14:12",
    "emetteur": "John Doe",
    "dossier_instruction": "PD12R0001",
    "contenu": {
        "Confirmation ERP": "oui",
        "Type de dossier ERP": "Lorem ipsum dolor sit amet...",
        "Catégorie de dossier ERP": "Lorem ipsum dolor sit amet..."
    }
}

[207](Échange ERP → ADS) Dossier PC/ERP Notification de dossier à enjeux ERP

L’objectif principal de cet échange est de permettre aux services ERP de partager le caractère “à enjeu” du dossier pour en informer l’instructeur ADS.

Identifiant : ERP_ADS__PC__NOTIFICATION_DOSSIER_A_ENJEUX_ERP

Cas d’utilisation :

• Cet échange ne concerne que le PC de type PLAN.
• Le service ERP peut qualifier le dossier comme Dossier à enjeux. Dans ce cas, un message « Dossier à enjeux ERP » est envoyé vers l’application ADS. Ce message ne met pas directement à jour le référentiel mais il est pris en compte dans les messages présentés à l’instructeur qui est chargé de mettre à jour ses données, et par voie de conséquence le référentiel.

Déclencheur :

• L’option ADS est activée
• Le dossier est marqué comme « connecté au référentiel ADS »
• Le DC est un PC-PLAN
• Le DC est marqué comme à enjeu

Traitement :

• Création de message : Un message de catégorie « sortant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Envoi de la requête à destination de la ressource “messages” d’openADS. Configuration des échanges sortants

Contenu de l’échange :

• contenu :
  • Dossier à enjeux ERP : Oui / Non

Exemple :

POST /openads/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type": "ERP_ADS__PC__NOTIFICATION_DOSSIER_A_ENJEUX_ERP",
    "date": "16/06/2014 14:12",
    "emetteur": "John Doe",
    "dossier_instruction": "PD12R0001",
    "contenu": {
        "Dossier à enjeux ERP" : "oui"
    }
}

[208](Échange ERP → ADS) Dossier AT Mise à jour des informations arrêtées dans le référentiel ADS

Identifiant : ERP_ADS__AT__MAJ_ARRETE_ERP_DOSSIER_AUTORISATION

Cas d’utilisation :

• Cette information est envoyée par ERP à ADS suite à la signature de l’arrêté d’autorisation d’un dossier AT.

Déclencheur :

• L’option ADS est activée
• Le dossier est marqué comme « connecté au référentiel ADS »
• Un document généré signé de type « Arrêté » est ajouté (Validation du formulaire de modification du document généré avec ajout d’un fichier signé alors que le champ était vide au préalable)

Traitement :

• Création de message : Un message de catégorie « sortant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Envoi de la requête à destination de la ressource “dossier_autorisations” d’openADS. Configuration des échanges sortants

Contenu de l’échange :

• « arrete_effectue » : Arrêté effectué. Format : booléen (oui/non)
• « date_arrete » : Date de l’arrêté. Format : date (JJ/MM/YYYY)

Exemple :

PUT /openads/services/rest_entry.php/dossier_autorisations/PC0130551601234 HTTP/1.1
Host: localhost

{
    "arrete_effectue":"some",
    "date_arrete":"04/06/2014"
}

[209](Échange ERP → ADS) Dossier PC/ERP Retour de consultation

L’objectif principal de cet échange est de permettre aux services ERP de répondre à une consultation d’un instructeur ADS directement depuis openARIA (sans nécessité de le faire depuis l’interface dédiée aux services consultés dans openADS).

Identifiant : ERP_ADS__PC__RETOUR_CONSULTATION

Cas d’utilisation :

• Cet échange ne concerne que le DC de type PLAN (PC).
• L’instructeur ADS a consulté officiellement via l’échange [104] le service ACC ou SECU d’openARIA sur un dossier d’instruction ADS de type PC, lorsque le PV est généré sur le DI lié alors on envoi directement le PV avec l’avis à openADS.

Déclencheur :

• L’option ADS est activée
• Le dossier est marqué comme « connecté au référentiel ADS »
• Le DC est un PC-PLAN
• Émission du PV de plan.

Traitement :

• Création de message : Un message de catégorie « sortant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Envoi de la requête à destination de la ressource “consultations” d’openADS. Configuration des échanges sortants

Contenu de l’échange :

• Date de retour d’avis (obligatoire) : {“date_retour”: “jj/mm/aaaa”} ;
• Avis (obligatoire) : {“avis” :”favorable|defavorable|favorable_reserve|…”} ;
• Motivation (facultatif) : {“motivation” :”Texte libre …”} ;
• Nom du fichier de retour d’avis (facultatif) : {“nom_fichier” :”retour d’avis ABF.pdf”} ;
• Fichier encodé en base 64 (facultatif) : {“fichier_base64” :data}.

Exemples :

Retour d’avis d’une consultation sans fichier :

PUT /openads/services/rest_entry.php/consultations/12 HTTP/1.1
Host: localhost

{
    "date_retour": "14/01/2012",
    "avis": "Favorable"
}

Retour d’avis d’une consultation avec fichier :

PUT /openads/services/rest_entry.php/consultations/12 HTTP/1.1
Host: localhost

{
    "date_retour": "14/01/2012",
    "avis": "Favorable",
    "fichier_base64": "JVBERi0xLjQKJcOkw7zDtsOfCjIgM",
    "nom_fichier": "plop.pdf"
}

[210](Échange ERP → ADS) Dossier AT Complétude Incomplétude

Dans le contexte du guichet unique, l’objectif principal de cet échange est de mettre à jour l’information de complétude d’un dossier AT dans openADS suite à sa complétude/incomplétude dans openARIA pour que les agents du guichet unique puisse accomplir leur mission d’enregistrement des demandes correctement.

Identifiant : ERP_ADS__AT__MAJ_COMPLETUDE_INCOMPLETUDE

Cas d’utilisation :

• À sa création dans openADS et dans openARIA, le dossier AT est considéré comme complet
• En cas d’incomplétude constatée par un des services d’openARIA, il va y a voir un message [210] openARIA > openADS, qui indiquera à openADS que le dossier est incomplet : un événement dans openADS devrait passer le dossier dans un état incomplet. État qui ne devrait permettre uniquement de recevoir des pièces complémentaires.
• En complément, la réception de pièces complémentaires sur le dossier dans openADS devrait le repasser de fait de incomplet à complet et ré-engager le processus de complétude mentionné ci-dessus.

Déclencheur :

• L’option ADS est activée
• Le dossier est marqué comme « connecté au référentiel ADS »
• Le formulaire de complétude/incomplétude est validé sur un DI avec la case à cocher « incomplet » cochée

Traitement :

• Création de message : Un message de catégorie « sortant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Envoi de la requête à destination de la ressource “dossier_instructionss” d’openADS. Configuration des échanges sortants

Contenu de l’échange :

• « message » : « complet », cette information ne correspond pas à la qualification de la complétude (complet ou incomplet) mais à un marqueur qui indique à openADS qu’il doit y appliquer un événement de complétude sur le dossier, dans le cas d’openARIA l’information transmet un état incomplet
• « date » : Date de la mise à jour de l’information au format JJ/MM/AAAA

Exemple :

PUT /openads/services/rest_entry.php/dossier_instructions/PC0130551600001P0 HTTP/1.1
Host: localhost

{
    "message":"complet",
    "date":"27/10/2013"
}

[211](Échange ERP → ADS) Dossier AT Clôture

Dans le contexte du guichet unique, l’objectif principal de cet échange est de mettre à jour l’information de clôture d’un dossier AT dans openADS suite à sa clôture dans openARIA pour que les agents du guichet unique puisse accomplir leur mission d’enregistrement des demandes correctement.

Identifiant : ERP_ADS__AT__MAJ_CLOTURE

Cas d’utilisation :

• Ce message a vocation à permettre aux agents du Guichet unique de bien accomplir leur mission d’enregistrement face à l’arrivée d’une nouvelle pièce : si le dossier d’instruction DAT est ouvert, alors les pièces sont acceptées (si le dossier est « incomplet », les pièces sont classées « complémentaires », sinon les pièces sont « supplémentaires ») et si le dossier est clos, les pièces sont refusées.
• Tous les dossiers d’instruction d’AT ne donnent pas lieu à un arrêté, ni même à une instruction. Vus du guichet unique et d’openADS ils peuvent donc toujours paraître « en cours d’instruction ». Dès que le dossier est clos dans openARIA pour ccessibilité et Sécurité, un message doit partir vers openADS.
• Le message de clôture doit mettre à jour automatiquement dans openADS le dossier d’instruction avec un statut « clos » et cela doit se répercuter automatiquement sur le refus des nouvelles pièces arrivant au guichet unique.

Déclencheur :

• L’option ADS est activée
• Le dossier est marqué comme « connecté au référentiel ADS »
• Le dossier est noté comme clôturé

Traitement :

• Création de message : Un message de catégorie « sortant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Envoi de la requête à destination de la ressource “dossier_instructionss” d’openADS. Configuration des échanges sortants

Contenu de l’échange :

• « message » : « clos » ou « ouvert »
• « date » : Date de la mise à jour de l’information au format JJ/MM/AAAA

Exemple :

PUT /openads/services/rest_entry.php/dossier_instructions/PC0130551600001P0 HTTP/1.1
Host: localhost

{
    "message":"clos",
    "date":"27/10/2013"
}

[212](Échange ERP → ADS) Récupération des informations depuis le référentiel ADS

Identifiant : ERP_ADS__RECUPERATION_INFORMATIONS_DOSSIER_INSTRUCTION

Cas d’utilisation :

• Lors de la saisie manuelle d’un DI ADS dans le formulaire du DC, on vérifie que ce dossier existe bien dans le référentiel ADS.
• Lors de la réception d’un message qui concerne un DI ADS, on récupère les informations qui le concerne pour éviter une resaisie dans openARIA.

Traitement :

• Envoi de la requête à destination de la ressource “dossier_instructions” d’openADS. Configuration des échanges sortants

Exemple :

GET /openads/services/rest_entry.php/dossier_instructions/PC0130551601234P0 HTTP/1.1
Host: localhost

[213](Échange ERP → ADS) Dossier PC Accusé de reception de consultation officielle

L’objectif principal de cet échange est de fournir un accusé de réception de consultation par le référentiel ERP au référentiel ADS.

Identifiant : ERP_ADS__PC__AR_CONSULTATION_OFFICIELLE

Cas d’utilisation :

• Cette information est envoyée par le référentiel ERP au référentiel ADS suite à la notification de consultation officielle d’un dossier PC.

Déclencheur :

• Appel d’une méthode de maintenance par cron
• Le dossier est marqué comme « connecté au référentiel ADS »
• Un message de type [104](Échange ADS → ERP) Dossier PC/ERP Consultation officielle pour avis ou [106](Échange ADS → ERP) Dossier PC/ERP Consultation officielle pour conformité a été reçu sur le dossier

Traitement :

• Création de message : Un message de catégorie « sortant » est ajouté dans openARIA afin de consigner l’échange. Il est visible depuis l’onglet « Message(s) » du dossier d’instruction et du dossier de coordination. → Marqueur(s) de lecture du message : mode 0.
• Envoi de la requête à destination de la ressource “message” d’openADS. Configuration des échanges sortants

Contenu de l’échange :

• « consultation » : l’identifiant de la consultation

Exemple :

POST /openads/services/rest_entry.php/messages HTTP/1.1
Host: localhost

{
    "type": "ADS_ERP__PC__AR_CONSULTATION_OFFICIELLE",
    "date": "16/06/2014 14:12",
    "emetteur": "John Doe",
    "dossier_instruction": "PD12R0001",
    "contenu": {
        "consultation" : 2
    }
}

Numérisation automatique

L’emplacement des documents à numériser doit être spécifié dans le fichier dyn/config.inc.php via le paramètre digitalization_folder :

$config['digitalization_folder_path'] = '../var/digitalization/';

Ce répertoire devra obligatoirement contenir deux sous-répertoires ACC et SI. Ces derniers devront également contenir les sous-répertoires Todo et Done. Ils permettent respectivement de stocker/consulter les documents à traiter/traités. L’opérateur qui numérise les documents devra donc déposer les documents dans le répertoire SI/Todo ou ACC/Todo.

Note

La consultation n’est qu’informative étant donné que les documents traités sont créés dans le filestorage. Les fichiers traités sont déplacés dans le répertoire Done à des fins de vérfication du traitement de la reprise. Afin de limiter l’utilisation de l’espace disque ils peuvent être supprimés par un service automatique (cf. Purge des documents numérisés).

Exemple d’arborescence :

var
└── digitalization
    ├── ACC
    │   ├── Done
    │   └── Todo
    └── SI
        ├── Done
        │   └── 20160101AUTPCP.pdf
        └── Todo
            ├── T2ARRETE26-10-2016.pdf
            └── 20160206DGPA01.pdf

Un service automatique (CRON) se chargera de traiter ces documents afin les enregistrer dans le système de stockage prédéfini.

En fonction de sa nomenclature, le fichier pourra être rattaché à un établissement et un type de pièce. Lors du processus de chargement automatique des fichiers, si le nom du fichier respecte la convention de nommage alors les informations qui y sont contenues sont extraites et analysées. Si l’une d’entre-elles est invalide alors la reprise de ce fichier est un échec. Si le nom du fichier ne correspond pas à la nomenclature alors il est placé dans la bannette, destiné à être classifié manuellement par la suite.

La charte de nommage des fichiers est TxxxxxType-de-doc-openARIAJJ-MM-AAAA.ext :

• Txxxxx : caractère T suivi du numéro d’établissement sur 5 chiffres
• Type-de-doc-openARIA : le type de document correspond au champ “Code” des types de fichiers depuis l’interface d’administration d’openARIA, ce type est passé en métadonnée lors du stockage du fichier.
• JJ-MM-AAAA : date au format jour-mois-année
• .ext : extension de fichier, obligatoirement .pdf

Module “filestorage”

Dans l’application openARIA, lorsqu’un document a vocation à être consulté ultérieurement, il doit être stocké de manière pérenne. Par défaut, c’est un système de stockage unique qui est un répertoire présent à la racine de l’application sur le système de fichiers du serveur.

C’est le module “filestorage” qui est en charge de réaliser cette opération. Il est composé d’un abstracteur et d’un ensemble de connecteurs (aussi appelés plugins). Ces derniers respectent l’API de l’abstracteur. Le connecteur par défaut est “filestorage_filesystem” présent dans le framework openMairie.

http://openmairie.readthedocs.io/projects/omframework/fr/latest/reference/filestorage.html

Le stockage du document est composé du fichier en lui-même mais aussi d’un ensemble d’informations permettant éventuellement d’utiliser le fichier en consultation depuis une autre application qu’openARIA (par exemple dans une GED). On appelle ces informations les métadonnées.

Les fichiers stockés

• Logo [om_logo.fichier]
  • Titre : Logo <LIBELLE>
  • Description : logo
  • Origine : téléversé
  • Stockage à l’ajout du fichier
  • Mise à jour à chaque mise à jour du champ fichier
• Document généré finalisé [courrier.om_fichier_finalise_courrier]
  • Titre : Établissement <CODE> - Dossier <CODE DC ou CODE DI> - <MODELE>
  • Description : document généré finalisé
  • Origine : généré
  • Stockage à la finalisation de l’édition
  • Mise à jour à chaque refinalisation de l’édition
  • Mise à jour des métadonnées à chaque modification de l’enregistrement (triggermodifierapres)
• Document généré numérisé signé [courrier.om_fichier_signe_courrier]
  • Titre : Établissement <CODE> - Dossier <CODE DC ou CODE DI> - <MODELE> (signé)
  • Description : document généré numérisé signé
  • Origine : téléversé
  • Stockage à l’ajout du fichier
  • Mise à jour à chaque mise à jour du champ fichier
  • Mise à jour des métadonnées à chaque modification de l’enregistrement (triggermodifierapres)
• Document entrant numérisé [piece.uid]
  • Titre : Établissement <CODE> - Dossier <CODE DC ou CODE DI> - <TYPE>
  • Description : document entrant numérisé
  • Origine : téléversé
  • Stockage à l’ajout du fichier
  • Mise à jour à chaque mise à jour du champ fichier
  • Mise à jour des métadonnées à chaque modification de l’enregistrement (triggermodifierapres)
• Procès verbal numérisé ajouté [proces_verbal.om_fichier_signe]
  • Titre : Établissement <CODE> - Dossier <CODE DC ou CODE DI> - procès verbal
  • Description : procès verbal numérisé ajouté
  • Origine : téléversé
  • Stockage à l’ajout du fichier
  • Mise à jour à chaque mise à jour du champ fichier
• Ordre du jour finalisé [reunion.om_fichier_reunion_odj]
  • Titre : (<CODE>) <TYPE> du <DATE> - ordre du jour
  • Description : ordre du jour de réunion finalisé
  • Origine : généré
  • Stockage à la finalisation de l’édition
  • Mise à jour à chaque refinalisation de l’édition
• Compte rendu global finalisé [reunion.om_fichier_reunion_cr_global]
  • Titre : (<CODE>) <TYPE> du <DATE> - compte rendu global
  • Description : compte rendu global de réunion finalisé
  • Origine : généré
  • Stockage à la finalisation de l’édition
  • Mise à jour à chaque refinalisation de l’édition
• Compte rendu global numérisé signé [reunion.om_fichier_reunion_cr_global_signe]
  • Titre : (<CODE>) <TYPE> du <DATE> - compte rendu global (signé)
  • Description : compte rendu global de réunion numérisé signé
  • Origine : téléversé
  • Stockage à l’ajout du fichier
  • Mise à jour à chaque mise à jour du champ fichier
• Ensemble des comptes rendus individuels numérisés signés [reunion.om_fichier_reunion_cr_par_dossier_signe]
  • Titre : (<CODE>) <TYPE> du <DATE> - compte rendu par dossier (signé)
  • Description : ensemble des comptes rendus de réunion individuels numérisés signés
  • Origine : téléversé
  • Stockage à l’ajout du fichier
  • Mise à jour à chaque mise à jour du champ fichier

Les métadonnées

Clé	Description
filename	Nom du fichier. Exemple : « nomdufichier.pdf » ou « nomdufichier.png ».
size	Taille du fichier en octets. Exemple : « 3254 » ou « 15124 ».
mimetype	Type MIME du fichier. Exemple : « application/pdf » ou « image/png ».
application	Nom de l’application. La valeur est « openARIA ».
titre	Titre permettant d’identifier le document (spécifique à chaque champ fichier). Exemple : « Établissement T1234 - Dossier VPS-VISIT-13211-SI - Courrier simple ».
description	Description générique du document. Exemple : « ordre du jour de réunion finalisé ».
origine	Origine du document. La valeur est « généré » si le document est généré par openARIA et la valeur est « téléversé » si le document est téléversé par l’utilisateur.
code_reunion	Code de la réunion. Exemple : « CCS-PLEN-2016-07-20 ».
date_reunion	Date de la réunion au format AAAA-MM-JJ. Exemple : « 2015-12-31 ».
type_reunion	Libellé du type de réunion. Exemple : « Commisson Communale de Sécurité ».
commission	Marqueur indiquant si la réunion est une commission ou non. La valeur est « true » si c’est le cas et « false » si ce n’est pas le cas.
etablissement_code	Code de l’établissement. Exemple : « T3556 ».
etablissement_libelle	Libellé de l’établissement. Exemple : « MATERNELLE LES CANTARELLES ».
etablissement_siret	Numéro de SIRET de l’établissement au format « sans espace ». Exemple : « 00011122233333 ».
etablissement_referentiel	Marqueur indiquant si l’établissement est référentiel ou non. La valeur est « true » si c’est le cas et « false » si ce n’est pas le cas.
etablissement_exploitant	Prénom et nom de l’exploitant. Exemple : « Paul DURAND ».
etablissement_adresse_numero	Numéro de l’adresse de l’établissement.
etablissement_adresse_mention	Mention de l’adresse de l’établissement.
etablissement_adresse_voie	Libellé de la voie de l’adresse de l’établissement.
etablissement_adresse_cp	Code postal de l’adresse de l’établissement.
etablissement_adresse_ville	Ville de l’adresse de l’établissement.
etablissement_adresse_arrondissement	Arrondissement de l’adresse de l’arrondissement. Exemple : « 6ème ».
etablissement_ref_patrimoine	Références patrimoines de l’établissement. Exemple : « 120;90 ».
dossier_coordination	Libellé du dossier de coordination. Exemple : « VPS-VISIT-13211 ».
dossier_instruction	Libellé du dossier d’instruction. Exemple : « VPS-VISIT-13211-SI ».
signataire	Prénom et nom du signataire. Exemple : « Jacques DURAND ».
signataire_qualite	Qualité du signataire. Exemple : « Adjoint délégué au Maire aux ERP ».
date_signature	Date de signature. Exemple : « 2015-12-31 ».
arrete_numero	Numéro de l’arrêté. Exemple : « 2016_01234_ERP ».
arrete_reglementaire	Marqueur indiquant si l’arrêté est réglementaire ou non. La valeur est « true » si c’est le cas et « false » si ce n’est pas le cas.
arrete_notification	Marqueur indiquant si l’arrêté est soumis à notification individuelle ou non. La valeur est « true » si c’est le cas et « false » si ce n’est pas le cas.
arrete_date_notification	Date de notification de l’arrêté (retour de l’AR du document). Exemple : « 2015-12-31 ».
arrete_publication	Marqueur indiquant si l’arrêté est soumi à publication au recueil des actes administratifs ou non. La valeur est « true » si c’est le cas et « false » si ce n’est pas le cas.
arrete_date_publication	Non renseigné.
arrete_temporaire	Marqueur indiquant si l’arrêté prévoit explicitement une date d’expiration ou non. La valeur est « true » si c’est le cas et « false » si ce n’est pas le cas.
arrete_expiration	Date d’expiration (date de notification + délai de la décision). Exemple : « 2015-12-31 ».
arrete_date_controle_legalite	Date de retour du contrôle de légalité. Exemple : « 2015-12-31 ».
arrete_nature_acte	Nature juridique de l’arrêté. La valeur est soit « Arrêtés Réglementaires » sinon « Arrêtés Individuels ».
arrete_nature_acte_niv1	Code du texte de premier niveau du domaine juridique de l’arrêté. Exemple : « 9 Autres domaines de competences ».
arrete_nature_acte_niv2	Code du texte de second niveau du domaine juridique de l’arrêté. Exemple : « 9.1 Autres domaines de competences des communes ».
pv_erp_numero	Numéro du procès verbal. Exemple : « SI-2016/00001 ».
pv_erp_nature_analyse	Nature de l’analyse. Exemple : « Visite de réception sécurité ».
pv_erp_reference_urbanisme	Code du dossier d’autorisation urbanisme. Exemple : « PC0130551600001 ».
pv_erp_avis_rendu	Avis rendu. Exemple : « FAVORABLE ».

Module “swrod”

Le module “swrod” (Single Window Read Only Documents) permet de d’afficher une liste de documents en lecture seule (à télécharger) provenant d’une source externe (GED, FTP, WS, …) représentant les pièces déposées sur un dossier ADS au Guichet Unique de la collectivité.

Voir les apports de la fonctionnalité dans l’interface utilisateur :

• Onglet « Documents Entrants » sur le dossier de coordination
• Onglet « Documents Entrants » sur le dossier d’instruction

Il est composé d’un abstracteur et d’un ensemble de connecteurs (aussi appelés plugins). Ces derniers respectent l’API de l’abstracteur.

Configuration d’un connecteur

La configuration du connecteur est définie dans dyn/swrod.inc.php.

Exemple :

$swrod = array(
    "type" => "swrodaria_example",
    "path" => "../plugins/swrod/swrodaria_example/swrodaria_example.class.php",
);

Liste des paramètres obligatoires :

• type défini le type de connecteur
• path défini le chemin du connecteur

Dans cet exemple, le script swrodaria_example.class.php sera inclus et la classe swrodaria_example sera instanciée. Il n’exite aucun connecteur de base dans openARIA puisque dépendant de l’environnement.

Cette configuration n’est pas multi base de données. La configuration de ce module sera donc commune aux différentes configurations de base de données présentes dans le script dyn/database.inc.php.

Activation de l’option

Pour que l’option soit activée, il est nécessaire de se rendre dans le menu “Administration & Paramétrage > Paramètres” et d’ajouter/de modifier le paramètre swrod pour lui affecter la valeur “true”.

Description de l’abstracteur et spécifications du connecteur

Le script obj/swrod.class.php permet de définir les classes de base permettant de définir le fonctionnement du module.

Liste des classes définies dans le script :

• swrod
• swrod_base

swrod

La classe “swrod” est une classe d’abstraction, spécifique à openARIA, permettant de gérer les interfaces avec des systèmes de stockage externes et ainsi proposer aux utilisateurs un accès aux documents du guichet unique. Cette classe est instanciée et utilisée par d’autres scripts pour gérer notamment la visualisation de ces documents dans l’onglet “Documents entrants” du DC et du DI. Son objectif est d’instancier les classes spécifiques aux SIG aussi appelées connecteurs correspondant au paramétrage de la collectivité.

swrod_base

Classe parente de tous les connecteurs SWROD.

Important

Les classes des connecteurs SWROD doivent étendre de swrod_base.

• $conf
• get_list()
• get_file()

$conf

$conf : null

Paramètres du connecteur SWROD présent dans `dyn/swrod.inc.php`.

get_list()

get_list(  $dossier)

openARIA fournit la valeur positionnée dans le champ DA ADS ou DI ADS du dossier de coordination afin d’obtenir la liste des documents correspondant dans le stockage externe.

Parameters

(string) $dossier : Identifiant du dossier à rechercher. Ex. : PC1305515J0045P0.

Returns

(array) Tableau de résultats (un sous-tableau par document) qui contient les clés suivants :

• date_creation
• categorie
• nom_fichier
• type_document
• uid
• dossier

//
return array(
    array(
        "date_creation" => "2016-12-01",
        "categorie" => "Arrêté",
        "nom_fichier" => "20161201ARR-01.pdf",
        "type_document" => "arrêté de conformité",
        "uid" => "12345",
        "dossier" => "AT0130551200001P0",
    ),
    array(
        "date_creation" => "2016-12-01",
        "categorie" => "Arrêté",
        "nom_fichier" => "20161201ARR-02.pdf",
        "type_document" => "arrêté de conformité",
        "uid" => "23465",
        "dossier" => "AT0130551200001P0",
    ),
    array(
        "date_creation" => "2013-12-01",
        "categorie" => "Arrêté",
        "nom_fichier" => "20131201ARR.pdf",
        "type_document" => "arrêté de conformité",
        "uid" => "46546",
        "dossier" => "AT0130551200001P0",
    ),
);

Si aucun résultat :

//
return array();

En cas d’erreur :

//
return false;

get_file()

get_file(  $id)

openADS fournit une liste de parcelles et le numéro de dossier correspondant. Le SIG renvoie un statut, spécifiant si le calcul été effectué correctement ou non.

Parameters

(string) $id : Identifiant du document à télécharger dans le stockage externe.

Returns

(array) Tableau contenant le fichier à télécharger.

//
return array(
    'file_content' => "%PDF...%EOF",
    'metadata' => array(
        "filename" => "truc.pdf",
        "mimetype" => "application/pdf",
    ),
);

En cas d’erreur :

//
return false;

Module géolocalisation

Le module de géolocalisation permet d’avoir des intéractions entre openARIA et un Système d’Information Géographique extérieur à l’application.

Ce module ajoute les fonctionnalités suivantes dans l’interface utilisateur :

• La possibilité de géolocaliser un établissement ou dossier de coordination sur le SIG
• Plusieurs liens de redirection vers l’élément sur le SIG, avec la carte centrée sur l’élément lorsqu’il est géolocalisé. Voir les listings
• Onglet « Contraintes » sur le dossier de coordination
• Onglet « Contraintes » sur l’établissement

Le module SIG est composé d’un abstracteur et d’un ensemble de connecteurs (aussi appelés plugins). Ces derniers respectent l’API de l’abstracteur.

Configuration d’un connecteur

La configuration du connecteur est définie dans dyn/sig.inc.php.

Exemple :

$conf["sig-default"] = array (
    "1" => array( // Identifiant de la collectivité
        'connector' => 'example',
        'path' => '../plugins/sig/geoaria_example/',
    ),
);

Liste des paramètres obligatoires :

• option_sig doit être positionnée à la valeur « sig_externe »
• connector défini le type de connecteur (Dans cet exemple, le connecteur geoaria_generic.class.php contenu dans le dossier « obj » sera instancié.)
• path défini le chemin du connecteur

• sig_treatment_mod permet de définir le mode de synchronisation des contraintes :

  • « mono » : permet d’affecter les contraintes d’un SIG à chaque collectivité de l’application via le code insee fourni lors de l’appel au web service. Chaque commune n’accés qu’aux contraintes afféctées lors de la synchronisation.
  • « multi » : permet d’affecter toutes les contraintes du SIG à la collectivité correspondant à la communauté de commune. Ces contraintes seront disponible pour toutes les communes de la communauté.

Dans openARIA, le paramètre du menu Administration option_sig doit être positionné à la valeur « sig_externe ».

Dans cet exemple, le script geoaria_example.class.php sera inclus et la classe geoaria_example sera instanciée. Il n’existe aucun connecteur de base dans openARIA puisque dépendant de l’environnement.

Il est possible d’avoir un paramétrage SIG par configuration de base de données. Pour cela, il faut ajouter dans le fichier de configuration dyn/database.inc.php, après les autres paramètres, un tableau nommé “extras” :

"extras" => array (
    'sig' => 'sig-default', // Paramétrage de la configuration SIG à utiliser
)

Description du script geoaria.class.php

Le script obj/geoaria.class.php contient les classes de base qui définissent le fonctionnement du module.

Liste des classes définies dans le script :

• geoaria
• geoaria_base
• geoaria_exception
• geoaria_om_parameter_exception
• geoaria_argument_exception
• geoaria_bdd_exception
• geoaria_configuration_exception
• geoaria_connector_4XX_exception
• geoaria_connector_5XX_exception
• geoaria_connector_exception
• geoaria_connector_method_not_implemented_exception

geoaria

La classe “geoaria” est une classe d’abstraction, spécifique à openARIA, permettant de gérer les interfaces avec des SIG externes et ainsi proposer aux utilisateurs de géolocaliser un élément sur le SIG, d’accéder directement au SIG avec la carte centrée sur l’élément, ou encore de récupérer en un clic les contraintes d’un élément. Cette classe est instanciée et utilisée par toutes les classes métier qui ont un besoin de géolocalisation, comme les dossiers, les établissements ou les contraintes. L’objectif de l’abstracteur est d’instancier les classes spécifiques aux SIG aussi appelées connecteurs correspondant au paramétrage de la collectivité. Ces connecteurs héritent de la classe “geoaria_base” qui leur sert de modèle. Enfin la classe “geoaria_exception” permet de gérer les erreurs. Plusieurs classes en héritent afin de spécifier le type d’exception.

geoaria_base

Classe parente de tous les connecteurs geoaria.

Important

Les classes des connecteurs geoaria doivent étendre de geoaria_base.

geoaria_exception

Classe gérant les erreurs (une exception est levée pour chacune).

geoaria_om_parameter_exception

Classe d’exceptions utilisée lors de la vérification des paramètres de l’application utilisés par les méthodes de l’abstracteur.

geoaria_argument_exception

Classe d’exceptions utilisée lors de la vérification des arguments passés aux méthodes de l’abstracteur.

geoaria_bdd_exception

Classe d’exceptions utilisée lors d’une erreur de base de données.

geoaria_configuration_exception

Classe d’exceptions utilisée lors d’une erreur dans le paramétrage du connecteur.

geoaria_connector_4XX_exception

Classe de gestion des exceptions retournée lors d’un code http 4XX.

Important

Cette exception correspond à un problème inhérent à openARIA.

geoaria_connector_5XX_exception

Classe de gestion des exceptions retournée lors d’un code http 5XX.

Important

Cette exception correspond à un problème inhérent au SIG.

geoaria_connector_exception

Classe de gestion des exceptions génériques remontées par le connecteur.

geoaria_connector_method_not_implemented_exception

Classe de gestion des exceptions sur les methodes du connecteur qui ne sont pas implémentées.

Description de l’abstracteur

Attributs

• $sig : Cet attribut permet de stocker l’instance du connecteur SIG utilisé.
• $collectivite : Paramètres de la collectivité fournie à l’abstracteur.

$sig

$sig : null

Cet attribut permet de stocker l’instance du connecteur SIG utilisé.

$collectivite

$collectivite : array

Paramètres de la collectivité fournie à l’abstracteur.

Méthodes implémentées

• __construct()
• geocoder_objet()
• synchro_contraintes()
• recup_contraintes()
• redirection_web()
• redirection_web_emprise()
• lister_etablissements_proches()
• lister_proprietaires_parcelles()

__construct()

__construct(array $collectivite)

Le constructeur instancie le connecteur SIG selon la configuration

Parameters

• (array) $collectivite : Configuration du connecteur.

geocoder_objet()

geocoder_objet(string $obj, string $idx, array $params)

openARIA fournit le type d’objet, ainsi que toutes les informations utiles qui ont été renseignées qui peuvent permettre de géolocaliser l’établissement ou le dossier de coordination.

Parameters

• (string) $obj : Le type d’élément openARIA, « etablissement » ou « dossier ».
• (string) $idx : Identifiant de l’objet.
• (array) $params Un tableau contenant un ou plusieurs des éléments suivants :

array (
    'parcelles' => array (
        array(
            'quartier' => string,
            'section' => string,
            'parcelle' => string
        ),
        array(
            'quartier' => string,
            'section' => string,
            'parcelle' => string,
        ),
    )
    'adresse' => string,
    'voie' => string,
    'dossier_ads' => string,
).

Returns

(string) La précision de la géolocalisation en mètres.

En cas d’erreur :

//
return false;

synchro_contraintes()

synchro_contraintes(string $insee = null)

openARIA fournit au SIG externe le code INSEE d’une commune. Le SIG renvoie l’ensemble des contraintes applicables à cette commune. Ces contraintes sont ensuite enregistrées dans la base de données d’openARIA, afin d’être réutilisées lors de la récupération des contraintes applicables à un dossier de coordination ou un établissement.

Parameters

(string) $insee : Code INSEE de la commune.

Returns

(array) Tableau de contraintes

//
return array(
    array(
        array(
         "contrainte" => "22",
           "groupe_contrainte" => "Servitudes",
           "sous_groupe_contrainte" => "",
           "libelle" => "Exemple de servitude",
       ),
        array(
            "contrainte" => "27",
            "groupe_contrainte" => "ZONES DU PLU",
            "sous_groupe_contrainte" => "protection",
            "libelle" => "Une contrainte du PLU",
       ),
    ),
);

S’il n’y a aucune parcelle :

//
return array();

recup_contraintes()

recup_contraintes(array $parcelle)

openARIA appelle le web service contrainte en lui fournissant la liste des parcelles dont on souhaite récupérer les contraintes. Le SIG renvoie une collection de contraintes qui s’y appliquent.

Parameters

(array) $parcelles : Un tableau contenant une ou plusieurs parcelles.

Returns

(array) Tableau de contraintes

//
return array(
        array(
            "contrainte" => "27",
            "groupe_contrainte" => "ZONES DU PLU",
            "sous_groupe_contrainte" => "protection",
            "libelle" => "Une contrainte du PLU",
       ),
    ),
);

S’il n’y a aucune parcelle :

//
return array();

redirection_web()

redirection_web(string $obj = null, array $data = null)

openARIA fournit le type d’objet et le ou les identifiant(s) de l’élement que l’utilisateur souhaite consulter sur le SIG. Le connecteur renvoie un URL, qui permettra à l’utilisateur d’accéder au SIG avec la vue centrée sur l’élément choisi.

Parameters

(string) $obj Le type d’objet à visualiser : parcelle/etablissement/dossier_coordination. (array) $data Tableau contenant un ou plusieurs identifiants de l’objet, ex: une ou plusieurs parcelles, un ou plusieurs numéros d’établissements, un ou plusieurs numéros de dossiers de coordination.

Format du tableau $data pour un objet établissement :

array(
    0 => 'T5',
    1 => 'T10',
    2 => 'T1111',
)

Format du tableau $data pour un objet dossier_coordination :

array(
    0 => array(
        'id' => 'VPS-VISIT-000010',
        'type' => 'VPS',
        )
    1 => array(
        'id' => 'PC-PLAN-000001',
        'type' => 'PC',
        )
    )

Format du tableau $data pour un objet parcelle :

array (
    0 => array (
        'prefixe' => '201',
        'quartier' => '806',
        'section' => 'AB',
        'parcelle' => '0025',
        ),
    1 => array(
        'prefixe' => '208',
        'quartier' => 806,
        'section' => ' A',
        'parcelle' => '0050',
        ),
    )

Returns

(String) L’URL du SIG centré sur le ou les éléments si l’objet a été précisé, sinon l’URL vers la vue par défaut du SIG.

redirection_web_emprise()

redirection_web_emprise(string $obj, array $data)

openARIA fournit le type d’objet et l’identifiant(s) de l’élement que l’utilisateur souhaite dessiner manuellement sur le SIG. Le connecteur renvoie un URL, qui permettra à l’utilisateur d’accéder au SIG en mode création d’établissement ou dossier de coordination.

Parameters

(string) $obj Le type d’objet à visualiser : parcelle/etablissement/dossier_coordination. (array) $data L’identifiant de l’objet, son code ou numéro et l’identifiant de la voie.

Returns

(String) L’url du SIG pour la création manuelle.

lister_etablissements_proches()

lister_etablissements_proches(array $params)

Récupération d’une liste d’établissements proches de l’objet passé en paramètre.

Parameters

• (array) $params Un tableau associatif contenant un ou plusieurs des paramètres suivant :

array(
    "idcentre" => array (
        "id" => string,
        "type" => string (etablissement/dossier_ads)
    )
    "listeparcelles" => array
    "limite" => string
    "distance" => string
)

Returns

(array) Tableau d’établissement(s), avec la distance en mètres de l’établissement par rapport à l’objet qui a été passé en paramètre.

lister_proprietaires_parcelles()

lister_proprietaires_parcelles(array $parcelles)

Récupération des informations nominatives des propriétaires des parcelles passées en paramètres. openARIA appelle le SIG en lui fournissant une ou plusieurs parcelles dont on souhaite obtenir les détails sur leur(s) propriétaire(s). Le résultat est un ensemble de propriétaires confondus (non identifiés par leur parcelle).

Parameters

• (array) $parcelles Tableau de parcelles.

Returns

(array) Un tableau contenant les informations d’un ou plusieurs propriétaires d’une ou plusieurs parcelles. Le retour est par exemple :

array(
    "ident1" => "DUPONT",
    "ident2" => "CLAUDE",
    "adr1" => "4EME ETAGE DROITE",
    "adr2" => "42 AV ROGER SALENGRO",
    "adr3" => "QUARTIER EUROMED",
    "cp_ville_pays" => "13003 MARSEILLE",
    "code_pays" => ""
    )

Si la récupération a échoué, on retourne false

Redirection vers openARIA

OpenARIA permet la redirection depuis une application externe vers la fiche ou une sélection d’objet. Pour cela il est nécessaire de passer par le script d’entrée à l’application app/entry.php.

Accéder à la fiche d’un objet

L’url doit être composée des paramètres suivants :

• obj objet de l’élément que l’on souhaite visualiser (etablissement ou dc) ;
• action type de redirection (view pour accéder à une fiche) ;
• by champ de l’objet sur lequel chercher les valeurs (code pour les établissements et libelle pour les dossiers de coordination) ;
• id valeur à chercher ;

Exemples d’url à composer :

• <lien_openaria>/app/entry.php?obj=etablissement&action=view&by=code&id=T3468
• <lien_openaria>/app/entry.php?obj=dc&action=view&by=libelle&id=VPS-VISIT-005018

Accéder au listing d’une sélection

L’url doit être composée des paramètres suivants :

• obj objet de l’élément que l’on souhaite visualiser (etablissement ou dc) ;
• action type de redirection (list pour accéder à une sélection d’objet) ;
• by champ de l’objet sur lequel chercher les valeurs (code pour les établissements et libelle pour les dossiers de coordination) ;
• ids valeurs à chercher séparées par des , ;

Exemples d’url à composer :

• <lien_openaria>/app/entry.php?obj=etablissement&action=list&by=code&ids=T3468,T3789,T4985
• <lien_openaria>/app/entry.php?obj=dc&action=list&by=libelle&id=VPS-VISIT-005018,AT-PLAN-009022,VPS-VISIT-005019

Web Services

Les web services d’openARIA sont RESTful. Les retours sont au format JSON, encodés en UTF-8.

Ressource « maintenance »

Synchronisation des utilisateurs via un annuaire

POST /openaria/services/rest_entry.php/maintenance

Exemple de requête :

POST /openaria/services/rest_entry.php/maintenance HTTP/1.1
Host: localhost

{
  "module": "user"
}

Exemple de réponse :

HTTP/1.1 500 Internal Server Error
Content-Type: text/javascript

{
  "http_code": 500,
  "http_code_message": "500 Internal Server Error",
  "message": "Erreur interne"
}

Status Codes:

• 200 OK – Tout s’est déroulé correctement.
• 500 Internal Server Error – Erreur interne.

Synchronisation des voies

POST /openaria/services/rest_entry.php/maintenance

Exemple de requête :

POST /openaria/services/rest_entry.php/maintenance HTTP/1.1
Host: localhost

{
  "module": "voies",
  "data" : {
      "file_name" : "/tmp/synchronsization_voies.csv"
  }
}

Numérisation automatique

POST /openaria/services/rest_entry.php/maintenance

Exemple de requête :

POST /openaria/services/rest_entry.php/maintenance HTTP/1.1
Host: localhost

{
  "module": "import",
  "data": {
    "service": "ACC"
    // Ces deux paramètres sont facultatifs
    "Todo" : "chemin_dossier_source", // ou "" pour utiliser le chemin dans la configuration
    "Done" : "chemin_dossier_destination" // ou "" pour utiliser le chemin dans la configuration
  }
}

Synchronisation des contraintes

POST /openaria/services/rest_entry.php/maintenance

Exemple de requête :

POST /openaria/services/rest_entry.php/maintenance HTTP/1.1
Host: localhost

{
  "module": "contraintes"
}

Gestion des messages asynchrones

POST /openaria/services/rest_entry.php/maintenance

Exemple de requête :

POST /openaria/services/rest_entry.php/maintenance HTTP/1.1
Host: localhost

{
  "module": "messagesasync"
}

Gestion des consultations

POST /openaria/services/rest_entry.php/maintenance

Exemple de requête :

POST /openaria/services/rest_entry.php/maintenance HTTP/1.1
Host: localhost

{
  "module": "ar_consultation"
}

Ressource « messages »

Cette ressource permet d’interfacer un message.

POST /openaria/services/rest_entry.php/messages

Cas d’utilisation :

• [101](Échange ADS → ERP) Dossier AT Information de qualification ADS
• [102](Échange ADS → ERP) Dossier PC/ERP Pré-demande de complétude ERP
• [103](Échange ADS → ERP) Dossier PC/ERP Pré-demande de qualification ERP
• [104](Échange ADS → ERP) Dossier PC/ERP Consultation officielle pour avis
• [105](Échange ADS → ERP) Dossier PC/ERP Information de décision ADS
• [106](Échange ADS → ERP) Dossier PC/ERP Consultation officielle pour conformité
• [107](Échange ADS → ERP) Dossier PC/ERP Demande de visite d’ouverture
• [108](Échange ADS → ERP) Dossier AT Dépôt initial
• [109](Échange ADS → ERP) Dossier AT Retrait du pétitionnaire
• [110](Échange ADS → ERP) Dossier AT Demande de visite d’ouverture
• [111](Échange ADS → ERP) Dossier PC/ERP Information de décision Conformité
• [112](Échange ADS → ERP) Dossier AT Dépôt de pièce par le pétitionnaire
• [113](Échange ADS → ERP) Ajout d’une nouvelle pièce numérisée
• [114](Échange ADS → ERP) Dossier PC Notification de dossier à enjeux ADS

Exemple de requête :

POST /openaria/services/rest_entry.php/messages HTTP/1.1
Host: localhost

  {
      "type": "Mise à jour de complétude ERP ACC",
      "date": "16/06/2014 14:12",
      "emetteur": "John Doe",
      "dossier_instruction": "PD12R0001",
      "contenu": {
          "Complétude ERP ACC": "non",
          "Motivation Complétude ERP ACC": "Lorem ipsum dolor sit amet..."
      }
  }

Gestion des fichiers journaux

Les fichiers journaux permettent d’avoir un historique des événements du fonctionnement d’openARIA. Plusieurs fichiers de logs sont présents dans l’application, chacun ayant un usage différent.

Fichier journal des erreurs de l’application

Le fichier var/log/error.log contient les erreurs importantes liées à l’utilisation d’openARIA, telles que les erreurs de base de données, les erreurs lors de l’enregistrement d’un fichier sur le disque, les erreurs lors d’une synchronisation des contraintes avec un SIG, etc.

Fichier journal des web services

Le fichier var/log/services.log contient une trace de toutes les requêtes entrantes et sortantes des web services openARIA. Pour chaque requête est détaillé le nom de la fonction utilisée, les paramètres en entrée et le retour de la requête.

Fichier journal des plugins

Les connecteurs externes à openARIA gèrent eux-même leur propre fichier de log.

Contributeurs

(par ordre alphabétique)

• atReal