Réintégration de documents générés #653
Comments
|
Le problème de Prevarisc est qu'en tant qu'application web, la modification d'une pièce jointe se fait forcément par:
Pour résoudre ce problème il faudrait que Prevarisc intègre un moteur de ged. Ce n'est pas prévu à ma connaissance. Cela est un changement d'habitude pour les utilisateurs de ERPv2 qui avaient l'habitude de modifier et enregistrer directement les PV dans Word. Avantage de prevarisc : la technologie utilisée permet de consulter le logiciel via internet (hors du sdis). Inconvénient: un peu moins de souplesse dans la gestion des documents. Cela vient sans doute du fait que, sauf erreur de ma part, le SDIS62, créateur du logiciel, utilise quasi exclusivement les champs du logiciel pour faire leur étude/pv et qu'ils génèrent la pièce jointe finalisée seulement à la fin? |
|
merci pour cette réponse, dont je me doutais. |
|
Notre service prévention s'est plaint de la même problématique... Selon moi, la philosophie de l'outil est :
La mise en forme doit être définie une fois pour toutes dans le document type. |
|
Le problème en utilisant quasi exclusivement les champs de Prevarisc pour faire les études est que ces champs ne sont pas forcément adaptés aux façons de fonctionner des différents SDIS. En ce qui nous concerne, nous trouvons que les champs de descriptif technique sont inutiles. A titre d'exemple, à quoi bon parler de desserte en termes de nombre de voies engins ou de façades accessibles si on ne précise pas quelles sont ces voies ou ces façades (données fondamentales quand on va en visite par exemple). Même problème avec la stabilité au feu. Stabilité au feu = 0 veut-il dire:
Le logiciel ne permet pas de le préciser. Idem concernant l'isolement par rapport aux tiers, les locaux à risques, le désenfumage... Par conséquent, à part à des fins de statistiques (et encore pourquoi avoir besoin de requeter sur les établissements suivants les critères cités plus haut?) le descriptif technique ne nous est pas utile pour générer l'étude/pv. Donc si l'on souhaite utiliser Prevarisc pour générer automatique le descriptif de l'ERP dans l'étude/pv, il faudrait remplir le champ libre "Descriptif". Mais comme ce champ n'est pas formaté (texte brut), et que les descriptifs comportent souvent des listes à tiret, il faut retravailler la mise en page au niveau du secrétariat dans tous les cas. Si l'on rajoute le fait que prevarisc ne génère pas les tableaux d'effectifs et de dégagements, il est plus simple pour nous de continuer un peu comme avant (ERPv2) où le document word (ou OpenDocument au choix) est notre support de travail. Prevarisc n'étant utilisé que comme container d'établissement et de dossier. Pour autant, les autres fonctionnalités de Prevarisc sont fort utiles (gestion des calendrier des com ou des visites, gestion des avis, accès facile aux différents ERP d'un site [contrairement à ERPv2], ajout des plans au niveau de la page d'accueil de l'ERP, possibilité de mettre des pièces jointes...). |
|
Je comprends tout à fait ce point de vue qui semble se rapprocher de celui de notre service prévention.
|
|
A mon avis, faire évoluer l'interface utilisateur de Prevarisc pour ajouter des champs de texte libre formaté permettrait de résoudre en partie le problème. Il faudrait idéalement que ces champs libres formatés puissent intégrer des tableaux (effectifs par niveau, dégagements par niveau...) mais cela semblait problématique techniquement (développement informatique) |
|
En tant que développeur, je confirme : ajouter des champs de texte libre formaté pouvant intégrer des tableaux, le tout retranscrit dans un fichier Writer me parait compliqué, je n'ai encore jamais vu ça... Cette problématique me semble insoluble. |
|
Bonjour,
En terme de développement, nous nous orientons sur l’ajout d’un bouton de « réintégration » dont la fonction, via une IHM spécifique est de reprendre un rapport existant dans PREVARISC et de demander à l’utilisateur de sélectionner le nouveau fichier mis en page . Celui écrase le précédent, sans création d’un nouveau fichier (comme c’est le cas actuellement).
Là où le bas blesse pour le moement, c’est notre capacité de développement Zendo limitée. Mais ……j’ai bonne espoir.
De : CFX-SDIS33 [mailto:[email protected]]
Envoyé : jeudi 2 mars 2017 10:32
À : SDIS62/prevarisc
Cc : Regnault Olivier; Author
Objet : Re: [SDIS62/prevarisc] Réintégration de documents générés (#653)
En tant que développeur, je confirme : ajouter des champs de texte libre formaté pouvant intégrer des tableaux, le tout retranscrit dans un fichier Writer me parait compliqué, je n'ai encore jamais vu ça...
Cette problématique me semble insoluble.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#653 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/APptMO42K816FduXfYkmxaQr8c-A92Rhks5rhoyRgaJpZM4MOJPl>.
|
|
Je confirme : La transformation d'un champ texte libre formaté est difficilement réinterprétable par le writer .odt que l'on utilise. Même si l'on pourrait passer par un standard (Markdown par exemple) on déplace le problème : si on a besoin d'un texte libre c'est qu'on est passé à côté de quelque chose dans Prevarisc. Le but de l'application est de pouvoir rentrer toutes les informations dans des cases spécifiques afin de bénéficier de statistiques et de compréhension globale. Les manques du tableau d'effectif, et d'observations générales sont connus. La version en développement prend une toute nouvelle approche pour gérer ces cas de figure. En attendant, une solution pour éviter le téléchargement, la modification, et la réintégration dans Prevarisc des documents générés serait de placer le repertoire |
Je ne partage pas votre point de vue. Le descriptif d'un ERP ne peut pas être enregistré sous forme de données fortement structurées. Les dispositions constructives, les installations techniques et les remarques liées à l'exploitation que l'on détaille dans nos descriptifs ne sont pas (toujours) compatibles avec des champs "figés" ou des cases à cocher. Même le plus basique des champs pour lequel on pourrait se dire qu'il est facile à mettre en oeuvre sous forme structurée c'est le nombre de niveaux dans un ERP. Et pourtant quand on pousse un peu la réflexion, c'est nettement plus compliqué que ça:
A cela s'ajoutent toutes les petites choses que l'on vient rajouter dans le PV pour aider nos collègues qui passeront à la prochaine visite tel que par exemple une phrase expliquant une disposition qui n'est pas conforme avec la réglementation actuelle mais qui l'est avec la réglementation applicable à l'ERP ou encore un élément admis par la commission de sécurité (pas forcément sous forme de dérogation formelle mais sous forme d'avis simple ou encore une non conformité admise plus ou moins implicitement lors d'une précédente visite). A mon avis, on peut donc faire de la donnée structurée pour plein de choses dans Prevarisc (avis, présence de locaux à sommeil, type, catégorie, effectif total, effectif hébergé, prescriptions...) mais difficilement pour le descriptif technique de l'établissement (et difficilement aussi pour les effectifs détaillés par niveau ou les dégagements par niveaux). Même la notion de textes applicables est une notion complexe dans la mesure où bien souvent, certaines partie d'un ERP répondent à une réglementation quand d'autres répondent à une autres (GN10)... Après c'est la vision d'une façon de faire de la prévention. Certainement pas la seule ni forcément la meilleure... |
|
@CO16 D'un point de vue technique, certains modules se présentant actuellement sous la forme de texte libre gagneraient à être cadrés via des standards / aides de saisies. Après, oui, le besoin de textes libres dans le fonctionnement métier de l'application n'est pas remis en cause. Il faut juste que ça se fasse intelligemment. C'est une des pistes que la v3 suit actuellement. |
Bonjour,
Comment peux t on réintégrer un document généré dans prevarisc puis soumis à mise en page et taches de secrétariat sans générer un nouveau fichier (problème de référence de document basé sur le numéro de fichier)?
Le développement d'une fonctionnalité de réintégration est elle en projet ?
merci
The text was updated successfully, but these errors were encountered: