Répondre à: Formulaire Plan de prévention

  • R3dKap

    Membre
    16 mai 2022 à 9h53

    @Sylvain je pense qu’il faut commencer par voir s’il est possible de découper ton formulaire Word en plusieurs “morceaux”. L’idée c’est que ces “morceaux” soient répartis sur différents écrans de ton application Power Apps, ceci afin de soulager chacun des écrans. Parce-que si tu mets un contrôle formulaire dans ton application avec l’ensemble des 20 pages de ton Word, ton écran va littéralement crever la gueule ouverte… 😁

    Donc, plus concrètement :

    • identifier les données à saisir à minima pour qu’une occurrence d’un PdP existe -> j’explique plus loin pourquoi

    • saucissonner le contenu du formulaire et répartir les questions dans différents écrans

    Côté application :

    • un écran d’accueil E1 qui liste mes PdP

    • un écran E2 avec un contrôle formulaire pour les données de base du PdP et des onglets qui permettent d’accéder aux différentes sections (saucissonnage précédent) des données à renseigner

    • un écran En pour chacun des onglets avec un contrôle formulaire qui porte les données correspondantes

    • il faut obligatoirement que le PdP existe, et donc à minima l’enregistrer au niveau de l’écran E2, avant de pouvoir accéder aux onglets et aux différentes sections du formulaire

    • chaque écran En a son propre contrôle formulaire branché sur sa propre liste (voir plus bas le modèle de données que je te recommande)

    • changer d’onglet implique que l’on a sauvegardé les données de l’onglet sur lequel on se trouve (sinon on perd sa saisie) -> chaque écran est “indépendant” (plus facile à maintenir aussi) -> mettre en place un système de détection de changement de données dans le formulaire pour afficher une popup de confirmation de changement d’onglet sans sauvegarder (ou plutôt de proposer de sauvegarder les données modifiées avant de naviguer)

    Et comme indiqué par @DavidZed tu peux facilement mettre en place des petites règles de gestion simples pour afficher/masquer des datacards en fonction de certains critères.

    Côté modèle de données, y’a plusieurs options dont celle d’avoir une seule liste avec la totalité des colonnes (mais ça va être monstrueux), et donc je suggèrerais plutôt :

    • 1 liste principale avec les données de base du PdP

    • 1 liste pour chaque section (si elles sont bien indépendantes) avec une colonne de recherche pour pointer sur le PdP de la liste principale et faire le lien avec le PdP en question

    A la rigueur, ce qui peut être intéressant aussi c’est de voir dans quelle mesure lors de la création initiale d’un PdP il est possible de demander à l’utilisateur de quelles sections du formulaire il va avoir besoin : ça te permettrait de n’afficher que les onglets utiles.

    Pour ce qui est du workflow de validation, ça dépend du besoin. Si c’est plutôt basique tu peux utiliser un flux d’approbation Power Automate. Sinon, faut le “coder” entièrement dans ton application avec des boutons de validation à chaque étape et pour chaque acteur.

    Enfin, pour générer le fichier PDF je te recommande vivement de passer par de la génération d’HTML que tu convertis ensuite en PDF avec le convertisseur natif gratuit (attention l’HTML ne doit pas faire plus de 2Mo -> évite les images, ou alors seulement des petits logos). Mon avis strictement perso, d’expérience : passer par de l’HTML est plus simple et plus flexible que de passer par un modèle de document Word.

    NOTE – Attention, à vu de nez comme ça, étant donné que ton formulaire Word de base est déjà plutôt monstrueux, y’a quand même beaucoup de boulot : entre la création des centaines de colonnes, des différentes listes SP, la création des différents écrans de l’appli, des nombreux formulaires à faire fonctionner avec pas mal de datacards avec des règles de gestion, …
    Au bas mot (mais j’ai pas vu la tronche du Word), je dirais qu’il y a bien 20j de boulot tout compris si tu veux faire un truc propre… 😉

    CommentID=EVHNx2DwXzWt4vT, PostID=nqb4ZT1WDagvuhu