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

Dans, ce cas, le plus simple est de créer une colonne lookup / recherche dans ta table membre, qui pointe vers la table genre.

La relation sera créé automatiquement, c’est beaucoup plus simple et pratique pour nommer la colonne en question.

Il n’est obligatoire de passer par la création de relations que pour les relations N:N

• Cette réponse a été modifiée Il y a 1 année par  DavidZed.

[DavidZed]

Si tu as la même source de données (même ,collection ou source de données SP, DV etc…), supprimer un enregistrement le fera disparaître des deux galeries.

Si tu as deux sources de données différentes, il faudra faire deux Remove (ou RemoveIf ) :

RemoveIf(
Tableau_Debrief_2J;
Type_Entretien = ThisItem.Type_Entretien) ;;

RemoveIf( Tableau_Debrief_1J; Type_Entretien =ThisItem.Type_Entretien)

Si le bouton de suppression est hors de la Gallery2 il faudra mettre Gallery2.Selected à la place de ThisItem

Un conseil: mieux vaut se baser sur l’ID ou une colonne dont on est sûr qu’elle contient des valeurs uniques dans ce genre d’usage

[DavidZed]

Bonjour,

Le plus simple, je pense, est de trier les données affichées dans la table par date de création, exemple :

Dans la propriété Items de ton contrôle table :

Sort(‘Nom de la source Dataverse’ ; ‘Créé le’ ; SortOrder.Ascending)

[DavidZed]

Hello,

C’est effectivement apparu quand les named formulas ont été annoncées et déployées en fonction experimentale, quasi dans la foulée. Il y a eu quelques exemples donnés pour créer des fonctions personnalisées.

Entre temps, les équipes power apps ont vraisemblablement décidé de nous livrer la fonctionnalité complète en deux fois : named formulas dans un premier temps et user defined functions ensuite.

Le paramètre App.Formulas ayant été développé pour accueillir les user defined functions, il ne génère pas d’erreurs si la syntaxe est respectée.

Le fait que les descriptions et mentions des user defined functions ont disparu des annonces, ne laisse malheureusement pas présager d’une date de sortie proche, même en fonctionnalité expérimentale. Il est même possible que ce soit abandonné.

En attendant, il est possible de créer des fonctions personnalisées grâce aux propriétés avancées des composants, qui devaient arriver en GA avant les user defined functions. C’est d’ailleurs le sujet de la session que nous avions présenté au ppfs avec R3dkap il y a peu : https://www.youtube.com/live/_PmxgslTI30?si=rVUMQHmeDau3AV5e&t=20906

[DavidZed]

Bonjour, c’est le 2eme argument du lookup, donc un test logique qui va déterminer quel enregistrement obtenir grâce à la fonction lookup :

Il indique que le “Title” de ta liste doit être égal au texte affiché dans la “DataCardValue11”, qui doit certainement être un contrôle textinput dans un formulaire.

Si tu as récupéré ce code ailleurs, il te faudra modifier cette partie pour qu’elle fasse référence à des valeurs définies dans ton appli.

[DavidZed]

Hello Charles,

Pour moi il y a deux aspects assez différents à prendre en compte dans ta question :

La dimension partage “d’accès”

Dans le contexte que tu décris, le partage des solutions et des flux sera suffisant dans la majeure partie des situations.

Il n’est pas nécessaire de partager les références de connexion et les variables d’environnement, ces dimensions sont accessibles sans rôle de sécurité particulier.

Le seul point bloquant que tu vas certainement rencontrer, c’est que tu ne pourras pas développer de solutions avec Dataverse, si tu ne peux pas créer ou modifier les rôles de sécurité.

Tu risques également d’être limité dans le déploiement de solutions avec le rôle system customizer, l’idéal est d’avoir un rôle d’admin système (idéalement sur un compte de service dédié, voir ci-après).

La dimension de propriété des éléments de la solution :

Pour que ton client sécurise la propriété de ces développements, il est indispensable que le déploiement des solution, qu’elles soient managées ou non, soit faite à l’aide d’un compte technique / de service / non nominatif (plusieurs dénominations possibles).
Car c’est le compte qui déploie qui sera propriétaire des éléments déployés dans la solution, il est donc important que ce compte ne soit dépendant d’une personne ou de sa présence dans les effectifs de l’entreprise.

Pour moi le déploiement avec un compte nominatif ne doit se faire que pour des projets citizen-dev et dans un environnement qui leur est dédié.

[DavidZed]

Hello,

C’est assez étrange comme bug, tu n’as rien dans la partie configure layout ? Et les colonnes sont bien cochées dans la partie Edit columns ?

Autre paramètre à vérifier dans les paramètres du site > propriétés de la liste > propriétés du formulaire :

[DavidZed]

C’est assez logique pourtant, mais cela souligne l’importance du nommage des tables, colonnes etc…

Ici, si tu retrouves ta valeur avec ThisItem.type.type, c’est parce que dans ta table Membre, tu as une colonne lookup qui se nome “type” et qui a la table “Genre” comme source, et que dans la table Genre, tu as une colonne (très certainement de type option/choice) qui se nomme également “type”

Généralement, je nomme les colonnes lookup avec le nom de la table ciblée quand c’est pertinent et que c’est le seul lookup vers cette table, s’il y en a plusieurs, je fais en sorte que le nom de la table figure dans celui de la colonne. Par exemple une colonne lookup vers la table langue :

Si c’est la seule colonne : Langue

S’il y en a plusieurs : Langue maternelle, Langue secondaire, Langue tertiaire etc…

Avec cette règle de nommage, tu aurais ThisItem.Genre.Type pour afficher ta valeur

[DavidZed]

Non, pour les dates, ascending va du plus petit au plus grand, donc du plaus ancien au plus récent

[DavidZed]

Il est clair que le jour où les user defined functions verront le jour, ce sera sensiblement moins lourd en ressources que de passer via les composants, même si, pour avoir pas mal fait de tests, les performances des requêtes sont tout à fait honorables. Mais il y a toujours cette étape de passer par un contrôle (le composant en lui-même) alors qu’une UDF irait directement interroger la source de données.

Pour ce qui est des named formulas à l’heure actuelle, j’y vois tout de même un intérêt, sur deux aspects particulièrement :

• Le fait qu’il s’agisse de constantes toujours à jour, celà simplifie pas mal la remontée d’indicateurs sans avoir besoin de faire des Refresh() ou de mettre à jour une collection, très pratique quand plusieurs utilisateurs d’une appli doivent voir remonter les modifs et ajouts des uns et des autres en temps réél (ou presque)
• J’y mets généralement tout ce que je mettais en variables “fixes” dans le OnStart : Thème couleurs, Tables de menus, Icones SVG… et je trouve que cela se ressent au lancement de l’appli (mais c’est peut-être subjectif 😀 )