[R3dKap]

Salut Guillaume,

Navré mais je ne peux pas t’aider avec les éléments fournis. Il faut bien te dire que je ne sais absolument pas ce que tu es en train de créer comme application, ni quel est ton modèle de données (listes et colonnes), ni quelle mécanisme doit être mis en place. Il faut vraiment être très précis, clair et détaillé dans les questions pour que l’on passe le moins de temps (perso) possible à répondre. Je sais que ça prend un peu de temps de ton côté mais c’est le seul moyen pour être efficaces ensemble. C’est une critique constructive hein 😉…

Pour ta question, je soupçonne que le cœur de ton problème se situe sur ce que tu appelles le “copier coller des champs précédents”. Il faut que tu me détailles ça.

1. Est-ce qu’il s’agit d’un pb de construction des formulaires où il y a de nombreux champs ?
2. Est-ce qu’il s’agit d’un pb lié à la manipulation des données des différentes listes ?

Essaie de me donner le plus d’éléments possible…

[guillaume]

Bonjour R3dKap,

déjà un grand merci pour ta réponse et ta remarque sur mon post.

Alors pour je dois faire un Apps pourque mes collègues fassent la saisie des compteurs d’eau, d’électricité et de gaz.

Le souci est j’ai environ 460 compteurs différents.

Les compteurs sont sur des listes SharePoint ayant la même structure.

Un enregistrement pour l’ensemble des compteurs.

L’idée est d’utiliser des formulaires pour saisir la valeur des compteurs, d’y afficher la valeur précédent et de faire la différence entre les deux.

j’ai commencé à le faire mais cela va me prendre un temps de ouf, je me dis qu’il doit y avoir une solution.

j’espère que je suis plus claire 🙁

[R3dKap]

Merci pour les éléments complémentaires Guillaume. Mais je manque encore d’informations.

1. Que représentent les colonnes E172, E173, E174 ? Les compteurs ? Si c’est le cas et que tu as 460 compteurs tu comptais faire une liste avec 460 colonnes ?
2. Pour quelle raison tu parles de 6 listes dans ton post d’origine ?
3. Est-ce que la différence entre 2 relevés doit être enregistrées ou elle doit être stockée pour historisation ? Comment est-elle utilisée ? Vous en faites quoi ? Vous produisez un document, une facture ?

Pense à bien noter les numéros de mes questions dans ta réponse pour que je puisse bien faire le lien… 😉

Merci.

[guillaume]

Bonjour R3dKap,

Déjà je te souhaite une bonne année et un maximum de réussite professionnelle et personnelle.

Je récupéré seulement mon PC, cest la fin des vacances.

1. Que représentent les colonnes E172, E173, E174 ? Les compteurs ? Si c’est le cas et que tu as 460 compteurs tu comptais faire une liste avec 460 colonnes ?
   1. Non, je vais faire des listes en fonction des différents services , 1 liste pour l’administration, & liste pour la mécanique, 1 liste pour le production etc….
2. Pour quelle raison tu parles de 6 listes dans ton post d’origine ?
   1. Car j’ai six services différents pour une facilité de gestion pour la compta.
3. Est-ce que la différence entre 2 relevés doit être enregistrées ou elle doit être stockée pour historisation ? Comment est-elle utilisée ? Vous en faites quoi ? Vous produisez un document, une facture ?
   1. Le process, un salarié va relevé les compteurs de son service via l’application, sur celle-ci. Il peut voir par compteur la dernière valeur relevé ainsi que les différences des derniers mois. En indiquant la valeur du compteur il peut lire la consommation par rapport au mois précédent.
   2. Les valeurs des compteurs et des différences sont enregistrées sur un liste SharePoint via un SubmitForm.
   3. Ensuite, les valeurs sont copiées manuellement vers un fichier Excel pour la compta. (pour le moment, je ne veux pas de copie directe).

Voilà, j’espère que mes indications de 2024 seront plus claires que l’année précédente.

Guillaume

[R3dKap]

Très belle année à toi également.

Merci pour les explications complémentaires.

Du coup, qu’as-tu prévu pour l’instant dans tes listes ? Comment sont-elles structurées ? Quelles colonnes contiennent-elles ?

[guillaume]

Alors dans mon idée mais ce n’est pas forcément la meilleur.

Les listes auront toutes la même apparence à savoir

1. la date de saisie
2. La valeur du compteur “E172”
3. La valeur du compteur “E173”
4. Etc…

L’opérateur fera sa saisie via un formulaire

1. Le nom du compteur
2. Le type de fluide “information prise via une autre liste SharePoint “
3. Sa localisation “information prise via une autre liste SharePoint “
4. La zone à renseigner
5. La valeur précédente
6. La différence (valeur calculée, je ne sais pas encore si la valeur sera intégrer directement dans la liste SharePoint. Si oui, il va falloir que je trouve un moyen pourque le SubmitForm prenne en compte cette valeur )

Comme tu peux voir cela est vraiment basique mais vu le nombre d’opération par compteur risque de générer des erreurs.

J’ai vu ta vidéo (Construire un formulaire dynamique avec Power Apps et SharePoint) sur l’enregistrement de nombreuse valeurs via une gallery mais cela fait un enregistrement par valeur et moi je dois faire un ligne pour l’ensemble des compteurs.

Au passage ta vidéo est vraiment sympa, j’ai appris pas mal de petit truc. merci

<div data-oembed-url=”https://www.youtube.com/watch?v=d7YNZFUeaZY&list=PLCcLLr7RiGSoDmRakYzP8YGh1548WdC-Y&index=2&t=1072s”><div style=”position: relative; padding-bottom: 100%; height: 0; padding-bottom: 56.2493%;”><iframe src=”https://www.youtube.com/embed/d7YNZFUeaZY” style=”position: absolute; width: 100%; height: 100%; top: 0; left: 0;” frameborder=”0″ allow=”autoplay; encrypted-media” allowfullscreen=””></iframe></div></div>

[R3dKap]

Aaaaah… Voilà une belle explication 😅 Merci.

La manière dont tu structure tes données est hyper importante pour faciliter et clarifier le développement de ton application.

Perso, je suis pas fan de créer des objets hyper similaires comme ça. Je préfèrerais avoir une seule liste, voire je construirai mon modèle de données ainsi :

• Une liste Compteurs qui référence tous les compteurs (qui du coup pourra porter d’autres colonnes détaillant éventuellement les caractéristiques de chaque compteur)
• Une liste Services avec les 6 services concernés par les relevés (également avec des données complémentaires si nécessaire)
• Une liste Relevés où seront stockés les relevés mensuels

Cette dernière liste Relevés, je lui donnerais la structure suivante :

• Service (qui pointe vers la liste Services)
• Compteur (qui pointe vers la liste Compteurs)
• Date (la date du relevé)
• Année (qui va contenir l’année de la date du relevé)
• Mois (qui va contenir le mois de la date du relevé)
• Valeur (qui va contenir la valeur relevée pour le compteur du service à la date précisée)

Ce modèle de données représente vraiment la réalité : c’est l’idéal. Toutes les problématiques d’accès aux données ou de volumétrie peuvent être résolus dans le code. Je vais l’expliquer…

Effectivement, le volume de la liste Relevés va être très important. C’est la raison pour laquelle il te faut alors concevoir ton application pour t’assurer que toute requête sur ta liste te ramène moins de 2000 éléments et éviter tout problème de délégation (en as-tu entendu parler ?).

C’est pour cette raison que j’ai rajouté les colonnes Année et Mois dans la liste : elles vont permettre de cibler les enregistrements à afficher dans ton application, en plus de Service (et éventuellement Compteur). En effet, dans une requête, si on avait utilisé les fonctions Year(Date) ou Month(Date) on aurait eu des problèmes de délégation. A toi de remplir ces 2 colonnes Année et Mois au moment de la création du relevé.

Concrètement, l’idée va consister à obliger l’utilisateur à choisir un service (éventuellement un compteur, mais c’est pas obligé), une année (éventuellement un mois, mais c’est pas obligé non plus). Sauf erreur de ma part, étant donné que tu as 460 compteurs (donc, en moyenne 460/6=76 compteurs par service) et que tu vas avoir un relevé par mois par compteur et par service, cela va te donner 76 x 12 = 900 relevés/compteur/service/an. Il est donc capital que ton application oblige à choisir à minima un service et une année avant d’accéder à ta liste. Toute opération de récupération de données sur ta liste devra donc à minima avoir un :

<code class="language-plaintext">Filter(Relevés; Service = … & Année = …)

C’est comme ça que l’on monte une solution propre et bien structurée (selon moi 😉).

Maintenant, ce sera à toi de faire en sorte qu’après que l’utilisateur ait choisi le service et l’année, tu récupères l’ensemble des relevés concernés pour les mettre en collection et ne travailler ensuite qu’avec la collection pour optimiser les accès à la source de données. A toi aussi de faire en sorte de récupérer en plus les relevés JUSTE sur le mois m-1 pour pouvoir calculer le delta.

Et les listes Services et Compteurs tu les charges aussi en entier dans des collections une seule fois au lancement de l’application.

Est-ce que cette approche pourrait répondre à ton besoin ?

[DavidZed]

Hello,

A ta place je partirais sur un modèle simple : Date du relevé, Bâtiment, Type de compteur, n° de compteur, relevé. Si tu t’obstines à faire une colonne par compteur, tu risques de rallonger ton temps de développement et de maintenance à chaque fois que tu auras à ajouter / supprimer / modifier un compteur.

Si tu souhaites avoir cette disposition par la suite, on pourra s’en approcher avec une vue de liste groupée ou, au pire, un peu de Power Query dans un fichier Excel.

Il faudra une seconde liste qui sert de référence pour les compteurs (avec N° compteur, type de compteur, bâtiment…), c’est dans celle-ci que tu vas gérer tes compteurs, bâtiments etc…

Dans l’application de relevés, l’idée serait de générer une liste de relevés à effectuer pour le jour J (soit via un bouton l’appli, soit avec un flux power automate planifié). Par exemple avec un :

<code class="language-plaintext">Patch( ‘Liste relevés compteurs’ ; ForAll( ‘Liste REF Compteurs’ As ThisCompteur; {
	'Date du relevé': Today()
	'N° Compteur' : ThisCompteur.'N° Compteur';
	Bat : ThisCompteur.Bat;
	'Type Compteur': ThisCompteur.TypeCompteur
} )

On ne mettra rien dans la colonne relevé, car cette valeur sera saisie durant la tournée d’inspection => On génère une liste de compteurs à relever qui permettra de voir instantanément lesquels ont été vérifiés ou non.

Dans le patch que je t’ai donné plus haut, tu as également la possibilité de créer des listes de relevés pour une tournée précise en filtrant ta ‘Liste REF Compteurs’ par bâtiment ou par type de compteur

[DavidZed]

Pour la vue de saisie des relevés : on filtre sur la date du jour et éventuellement la tournée (bâtiment / localisation / type de compteur)

Pour obtenir le relevé précédent :

<code class="language-plaintext">Last( Sort( Filter( ‘Liste relevés compteurs’; ‘Date du relevé’ < Today() ; ‘Date de relevé’ ; SortOrder.Descending ))).Relevé

[guillaume]

Bonjour DavidZed,

Alors tes réponses mon laissé avec beaucoup d’interrogations mais elles m’ont permis d’avancer sur le projet.

Une gallery permet à l’utilisateur de remplir les valeurs et d’enregistrer sur une liste SharePoint.

Un fichier Excel récupère les données pour alimenter les différents tableaux de la compta.

Je tiens à vous remercier pour l’ensemble de vos réponses et votre patience.

Guillaume