[DavidZed]

Assez étrange en effet, dans la continuité des points a vérifier:

• Essayer sur un autre écran, toujours dans la priorité onvisible, essayer dans une nouvelle appli. Si ça fonctionne, alors le but est au niveau de l’App
• Supprimer la source de données et la réimporter
• Vérifier qu’aucun contrôle, objet, écran ou variable n’a le même nom que la source de données (qui aurait été créé avant l’import de la source)
• Essayer de dupliquer l’écran et tester
• Faire une session avec l’inspecteur du navigateur ou une session monitorée et voir si tu peux en apprendre plus sur l’erreur
• Vérifier que la variable n’est pas définie avec une autre structure de données dans cet écran (ou passée a cet écran via un navigate)

• Cette réponse a été modifiée Il y a 9 mois par  DavidZed.

[DavidZed]

Hello,

Il me semble que le déclencheur ne récupère pas le contenu des pièces jointes, il est nécessaire d’ajouter une action “Obtenir la pièce jointe” dans la boucle avant l’action “Ajouter à la variable de Tableau” :

Syntaxe pour le Json :

{
  "name":@{outputs('Obtenir_la_pièce_jointe_(V2)')?['body/name']},
  "Content": {
    "$content-type":@{outputs('Obtenir_la_pièce_jointe_(V2)')?['body/contentType']},
    "$content":@{outputs('Obtenir_la_pièce_jointe_(V2)')?['body/contentBytes']} 
  }
}

Le résultat avec 5 fichiers PNG :

[DavidZed]

Hello,

Il me semble que le déclencheur ne récupère pas le contenu des pièces jointes, il est nécessaire d’ajouter une action “Obtenir la pièce jointe” dans la boucle avant l’action “Ajouter à la variable de Tableau” :

Syntaxe pour le Json :

{
 "Name": @{outputs('Obtenir_la_pièce_jointe_(V2)')?['body/name']},
 "Content": "@{outputs('Obtenir_la_pièce_jointe_(V2)')?['body/contentBytes']}"
}

[DavidZed]

Hello,

Si les tables ont la même structure de données, tu peux essayer la fonction UnGroup()

Ungroup( Table, GroupColumnName )

[DavidZed]

Bonjour,

A ma connaissance, il y a deux possibilités :

Mettre l’action d’approbation dans une boucle “exécuter jusqu’à”, mettre un timeout court, équivalent a la période souhaitée entre chaque relance. Il suffit ensuite d’indiquer que la condition de sortie de la boucle est que l’approbation doit avoir reçu une réponse.

Une autre approche est de créer un flux planifié qui va lister tous les éléments en cours d’approbation et envoyer des notifications de relances. Cela nécessitera, si l’approbation est en plusieurs étapes, d’avoir un champ qui contient l’information de l’étape en cours afin de notifier les personnes concernées .

[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é

[DavidZed]

Hello Mick,

Le Json de sortie de ta colonne Destinataire est entre [], ça signifie que c’est une colonne qui attend une donnée de type table ( Tu as du cocher l’option multiple values sur ta colonne SP ) et tu lui donnes un record (enregistrement).

Si c’est une erreur et que ta colonne n’est censé contenir qu’un destinataire, tu peux :

• Soit modifier les propriétés de ta colonne dans SP
• Soit récupérer le 1er élément de la table avec l’index [0] ou la fonction first() , exemple : item(‘Appliquer_à_chacun_2’)?[‘Destinataire’][0]?[‘Value’]

Si ton champ peut effectivement contenir plusieurs destinataires, tu peux concatainer les valeurs de ta table :

• Soit en utilisant l’action de données Joindre
• Soit en utilisant la fonction join( TABLE , ‘Séparateur Texte’ ) dans une expression

[DavidZed]

Hello Jean,

Si ces données sont textuelles, il faudra passer par AI Builder et entrainer un modèle de reconnaissance de champs.

Voici le learnpath pour apprendre à créer un modèle et l’intégrer à Power Apps : Traiter des documents personnalisés avec AI Builder – Training | Microsoft Learn

Attention, AI builder consomme des crédits à chaque utilisation, les licences premium Power apps et Power Automate fournissent un quota mensuel de crédit AI Builder

[DavidZed]

Hello,

J’ai buggé sur le 1er point : si CustomID présent dans les 2 tableaux : conserver la ligne dans le tableau 1

Car si dans cette situation on conserve cette ligne seulement dans le tableau 1, cela va enchainer avec la 2eme condition et la ligne dans le tableau 1 va être supprimée également.

Pour le flux, pour chaque tableau, il faudra faire :

Un action “Sélectionner” sur la colonne CustomID, appelons les Sélectionner ID Tableau 1 et Sélectionner ID Tableau 2

Ensuite, pour le tableau 1 :

Une action filtrer les lignes avec comme fonction : le body de l’action “Sélectionner ID Tableau2 “ ne contient pas le CustomID de la ligne

Pour chaque ligne du tableau filtrer : supprimer une ligne du tableau 1

Pour le tableau 2 :

Une action filtrer les lignes avec comme fonction : le body de l’action “Sélectionner ID Tableau1 “ ne contient pas le CustomID de la ligne

Pour chaque ligne du tableau filtrer : Ajouter une ligne au tableau 1

Si tu as une action à faire sur les lignes présentes dans les deux tableaux, il faudra utiliser la fonction intersection()

[DavidZed]

Hello Marielle,

La solution qui me parait la plus simple, est d’ajouter une colonne de type choix à ta liste, qui va représenter l’étape de process du traitement de la facture, avec pour options les différents états possibles, par exemple :

1. Attente d’affectation à un département
2. Attente d’affectation à un agent
3. Chèque ou ODR en cours d’émission
4. Attente de transmission au bénéficiaire
5. Traitement terminé
6. Traitement annulé

L’idée ensuite, est d’avoir un flux automatisé, qui va se déclencher sur la modification d’un élément de la liste (mettre un filtre odata pour écarter les items qui ont le statut Traitement terminé ou annulé dès le déclencheur).

Ensuite, mettre un switch sur la valeur de la colonne statut avec une branche pour chacune des 4 premières étapes, plus 0 : quand l’item vient d’être créé et que le statut est vide (il faut lui créer sa propre branche et non utiliser celle par défaut comme dans mon screenshot ci-après).

L’idée est ensuite, pour chaque branche, de vérifier si l’action précédente a été réalisée, et si tel est le cas, envoyer un message à la personne en charge de l’étape suivante, celà devrait ressembler à ceci :

Il faudra prévoir une colonne “chèque/virement émis le:” et “chèque/virement envoyé le:” qui serviront de vérification de l’exécution de ces tâches

Il est possible d’optimiser ce flux car celui-ci va se redéclencher inutilement à la dernière étape. Dans ce cas, il faut prévoir dans la condition de déclenchement du flux, les seuls cas où il est censé être lancé.

Enfin, ce n’est qu’une approche, il en existe bien d’autres qui sont tout aussi valides, par exemple un flux qui va durer tout le temps du process en accompagnant chaque élément de la liste du début à la fin du traitement (Solution valable si le traitement des factures doit être fait en moins de 48h, sinon c’est vite la pagaille d’avoir XXX flux en cours en même temps).

Pour les relances, le plus simple est d’avoir un second flux, plannifié, qui liste tous les items de la liste qui ne sont pas terminés et dont la date de modification est supérieure à X jours, et envoi d’un message au destinataire concerné en fonction de l’étape de l’item.

[DavidZed]

Hello Clémence, d’après ton screenshot, le formulaire n’est pas un custom form Power Apps, mais un formulaire Sharepoint de base

Si la donnée est bien présente, et que le formulaire Power Apps a bien été créé :

Vérifier que cette option est bien sélectionnée dans les paramètres de la liste > paramètres du formulaire

[DavidZed]

Bonjour,

L’idéal est de faire un flux power automate,

A la base, il faudra créer une liste “Archive” avec la même structure que la liste source : Mêmes noms de colonnes (idéalement même nom technique et même nom d’affichage)

Généralement je préfère partir sur un déclencheur manuel, pour déclencher moi même l’archivage, mais il est tout à fait possible d’utiliser un déclencheur planifié.

Liste des éléments à transférer :
Ajouter une action Sharepoint : “Obtenir les éléments” (il est possible de filtrer sur la date en Odata)

Copie des éléments
Mettre à la suite une action Sharepoint : “Créer un élément” et reporter les valeurs correspondantes de l’action précédente dans chaque champ, cela va créer une boucle “Appliquer à chacun”

Suppression des éléments de la liste principale:
Dans cette boucle, à la suite de l’action “créer un élément”, mettre une action SP : “Supprimer un élément” renseigner la liste principale et l’ID récupéré dans “Obtenir les éléments”

[DavidZed]

C’est surprenant

A tester : Mettre un ID en dur d’une ligne qui existe dans le tableau et voir si le problème est le même, exemple :

<code class="language-diff">
Patch(
Tableau1_1;
{Iddmd: "34"};
{
emailreparateur: TextInput5.Text; .......

• Cette réponse a été modifiée Il y a 9 mois, 1 semaine par  DavidZed.

[DavidZed]

Tout dépend de ce que tu as stocké dans ta variable varItem,

Si tu as stocké uniquement l’ID de la ligne, ça devrait fonctionner

Si tu as stocké l’enregistrement entier, tu peux appeler la valeur de l’ID avec vartItem.Iddmd

Pour la fonction Patch, il y a une erreur sur le 2nd argument: celui où tu es censée renseigner l’enregistrement à patcher, tu as trois possibilités :

• Mettre les valeurs par défaut
  Patch(Tableau1_1; Defaults(‘Ta source de données’) ; {emailreparateur: TextInput5.Text; …….} )
  , ce qui va créer une nouvelle ligne
• Renseigner l’ID:
  Patch(Tableau1_1; {Iddmd : 54} ; {emailreparateur: TextInput5.Text; …….} )
  Où 54 est l’ID de la ligne que tu souhaites patcher
• Fournir l’enregistrement complet avec un LookUp :
  Patch(Tableau1_1; LookUp(Tableau1_1; emailreparateur = “polo@moumoute.com” ) ; {emailreparateur: TextInput5.Text; …….} )