> Amélioration continue des processus > Demande d’achat au paiement > Microsoft Dynamics 365 > Modèle de données

Votre modèle de données Purchase-to-Pay pour les demandes d’achat

Microsoft Dynamics 365

Attributs des demandes d’achat Purchase-to-Pay(17) Activités des demandes d’achat Purchase-to-Pay(12) Guides d’extraction(3)

Votre modèle de données Purchase-to-Pay pour les demandes d’achat

Ce modèle présente les principaux attributs à recueillir et les activités essentielles à suivre pour examiner en détail votre processus de demande d’achat. Il fournit également des conseils pratiques pour extraire ces données et préparer efficacement votre journal d’événements en vue d’une analyse approfondie.

Attributs recommandés à recueillir
Activités clés à suivre
Conseils d’extraction

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs des demandes d’achat Purchase-to-Pay

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail votre processus Purchase-to-Pay de demande d’achat.

5 Obligatoire 6 Recommandé 6 Facultatif

	Nom	Description
	Heure de l’événement EventTime	Horodatage précis auquel une activité ou un événement s’est produit.
Description L’heure de l’événement, ou horodatage, indique la date et l’heure auxquelles un événement métier a été enregistré dans le système. Elle constitue la base temporelle de toute analyse des processus. Cet attribut est essentiel pour calculer les temps de cycle, les durées et les temps d’attente entre les activités. Il permet d’analyser les performances du processus, de repérer les goulots d’étranglement et de suivre le respect des SLA. Des horodatages exacts sont indispensables à la fiabilité de l’analyse Process Mining. Pourquoi est-ce important ? Il indique l’ordre chronologique des événements, nécessaire pour calculer la durée des processus, repérer les goulots d’étranglement et analyser les performances dans le temps. Où trouver ces données Cet horodatage figure dans l’historique des flux de travail ou les tables de journaux de documents, souvent dans un champ ’CreatedDateTime’ ou ’ModifiedDateTime’ associé à chaque changement de statut ou enregistrement d’événement. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
	Identifiant de la demande d’achat PurchaseRequisitionId	Identifiant unique d’une demande d’achat, utilisé comme identifiant principal du cas.
Description L’identifiant de la demande d’achat est la clé centrale qui relie toutes les activités associées à une demande de biens ou de services. Chaque demande est suivie sous cet identifiant unique, de sa création à son approbation finale et à sa clôture. En Process Mining, cet attribut est indispensable pour reconstituer le parcours complet de chaque demande. Il permet d’analyser les variantes du processus, les temps de cycle et la conformité de chaque cas, et donne une vue complète du cycle de vie des demandes. Pourquoi est-ce important ? Il est indispensable pour regrouper tous les événements associés dans une seule instance de processus et analyser le cycle de vie complet de chaque demande. Où trouver ces données Il s’agit généralement de la clé primaire de la table principale des en-têtes de demandes d’achat, comme PurchReqTable dans Microsoft Dynamics 365. Exemples PR-001254PR-001255PR-001256
	Nom de l’activité ActivityName	Nom de l’événement métier ou de l’étape qui s’est produit dans le processus de demande d’achat.
Description Cet attribut indique le nom de chaque activité réalisée au cours du cycle de vie d’une demande d’achat. Il peut s’agir, par exemple, de « Demande d’achat créée », « Étape d’approbation approuvée » ou « Commande d’achat créée ». Ces activités constituent les nœuds de la carte de processus générée. L’analyse de leur séquence, de leur fréquence et du temps écoulé entre elles est au cœur du Process Mining. Elle permet de repérer les goulots d’étranglement, les boucles de reprise et les écarts par rapport au flux de processus standard, et de mettre en évidence les inefficacités opérationnelles. Pourquoi est-ce important ? Cet attribut définit les étapes de la carte de processus et permet de visualiser, d’analyser et de comprendre le flux de travail des demandes d’achat. Où trouver ces données Cet attribut est généralement obtenu à partir des journaux de changements de statut, des tables d’historique des flux de travail ou des tables d’événements de Microsoft Dynamics 365, comme WorkflowTrackingStatusTable. Exemples Demande d’achat soumise pour approbationÉtape d’approbation approuvéeDemande d’achat modifiée
	Dernière mise à jour des données LastDataIngestionTimestamp	Horodatage de la dernière extraction des données et de leur chargement dans l’outil de Process Mining.
Description Cet attribut indique si les données analysées sont à jour. Il précise la date et l’heure de leur actualisation la plus récente depuis le système source. Il ne s’agit pas d’un champ de Dynamics 365, mais de métadonnées ajoutées lors de l’importation des données. Cet horodatage permet aux utilisateurs de savoir si les analyses sont à jour. Ils peuvent ainsi déterminer s’ils consultent des données en temps réel ou un instantané pris à un moment précis, ce qui influe sur la pertinence de leurs conclusions. Pourquoi est-ce important ? Il indique si les données sont à jour, afin que les utilisateurs connaissent la période couverte par l’analyse et puissent évaluer la pertinence des résultats. Où trouver ces données Cette valeur est générée et ajoutée au jeu de données lors de son importation ou du processus ETL. Exemples 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Système source SourceSystemId	Système de référence à partir duquel les données ont été extraites.
Description Cet attribut identifie le système source des données d’événements. Dans ce contexte, il s’agit de « Microsoft Dynamics 365 ». Dans les environnements où plusieurs systèmes sont intégrés, ce champ est essentiel pour retracer l’origine des données et les replacer dans leur contexte. Lors de l’analyse, il permet de distinguer les processus qui couvrent plusieurs systèmes ou de confirmer que les données proviennent d’une source unique faisant autorité. Il contribue ainsi à valider les données et à vérifier que l’analyse repose sur le bon jeu de données. Pourquoi est-ce important ? Il précise l’origine des données, une information essentielle pour leur gouvernance et leur validation, notamment lorsque plusieurs systèmes sont intégrés. Où trouver ces données Cette valeur statique, « Microsoft Dynamics 365 », est ajoutée lors de l’extraction et de la transformation des données. Exemples Microsoft Dynamics 365 F&OD365MSD365
	Étape d’approbation ApprovalStep	Nom ou étape d’une étape d’approbation précise du flux de travail.
Description Cet attribut désigne une étape précise du flux de travail d’approbation, par exemple « Approbation du responsable » ou « Approbation des finances ». Il fournit un niveau de détail supérieur au nom général de l’activité. Cet attribut est essentiel pour l’« Analyse des goulots d’étranglement des étapes d’approbation ». En suivant le temps passé à chaque étape d’approbation, vous pouvez déterminer précisément lesquelles retardent le processus global. Vous pouvez alors intervenir de manière ciblée pour améliorer l’efficacité du flux de travail. Pourquoi est-ce important ? Il permet d’analyser en détail le flux de travail d’approbation et de repérer les étapes précises à l’origine des goulots d’étranglement. Où trouver ces données Ces informations figurent dans les tables d’historique du flux de travail, telles que WorkflowTrackingStatusTable, qui détaillent chaque étape du flux de travail configuré. Exemples Approbation du responsableApprobation du responsable de serviceExamen par les finances
	Montant total de la demande d’achat RequisitionTotalAmount	Valeur monétaire totale de la demande d’achat.
Description Cet attribut correspond à la valeur totale de toutes les lignes d’une demande d’achat. Le montant influe souvent sur la complexité du flux de travail d’approbation : les demandes de montant élevé nécessitent généralement davantage d’étapes d’approbation. Dans l’analyse des processus, cet attribut est essentiel pour filtrer et analyser les demandes selon leur valeur. Il permet de répondre à des questions telles que « Les demandes de montant élevé prennent-elles plus de temps à être approuvées ? » ou « Quelle est la valeur des demandes actuellement bloquées dans le processus ? ». Il apporte ainsi un éclairage financier sur la performance du processus. Pourquoi est-ce important ? Il ajoute une dimension financière à l’analyse, ce qui permet de prioriser les cas de montant élevé et de comprendre l’incidence de la valeur monétaire sur le déroulement du processus. Où trouver ces données Cette valeur figure généralement dans la table d’en-tête des demandes d’achat ou est calculée en additionnant les montants des lignes de la table des lignes de demande d’achat (PurchReqLine). Exemples 1500.0025000.50500.75
	Niveau d’urgence UrgencyLevel	Classement du degré d’urgence de la demande, par exemple « Élevé », « Moyen » ou « Faible ».
Description Le niveau d’urgence, ou la priorité, indique dans quel délai les biens ou services demandés sont nécessaires. Cet attribut sert souvent à déterminer le circuit d’approbation ou à prioriser le travail des approbateurs. Son analyse permet de vérifier si le système de priorités est efficace. Vous pouvez, par exemple, comparer les temps de cycle des demandes à urgence « Élevée » et « Faible ». Si l’écart est négligeable, cela peut indiquer que le champ de priorité est ignoré ou mal utilisé. C’est un élément important à examiner dans le Dashboard « Analyse de l’incidence du niveau d’urgence ». Pourquoi est-ce important ? Il permet de vérifier si les paramètres de priorité accélèrent effectivement le traitement des demandes urgentes et de repérer les éventuels usages inappropriés de la classification par niveau d’urgence. Où trouver ces données Il peut s’agir d’un champ standard ou personnalisé de PurchReqTable. Sa présence et son nom peuvent varier selon la configuration du système. Exemples ÉlevéMoyenFaible
	Service Department	Service du demandeur ou centre de coûts associé à la demande d’achat.
Description Cet attribut indique le service ou le centre de coûts à l’origine de la demande d’achat, par exemple « Marketing », « Informatique » ou « Opérations ». Cette information figure généralement dans l’en-tête de la demande. La segmentation du processus par service est essentielle pour comparer les résultats. Elle permet de repérer les services où les temps de cycle sont les plus longs, les taux de rejet les plus élevés ou les modifications les plus fréquentes. Ces analyses aident à adapter les améliorations aux besoins de chaque service. Pourquoi est-ce important ? Il permet de filtrer et de comparer les performances des processus entre différentes unités opérationnelles, afin de repérer les tendances, les goulots d’étranglement et les inefficacités propres à chaque service. Où trouver ces données Ces informations sont souvent stockées dans l’en-tête de la demande d’achat (PurchReqTable) et liées à la configuration des dimensions financières dans Dynamics 365. Exemples Service informatiqueFinanceOpérations
	Statut de la demande d’achat RequisitionStatus	Statut actuel ou final de la demande d’achat.
Description Cet attribut indique le statut global de la demande d’achat à un moment donné, par exemple « En cours d’examen », « Approuvé », « Rejeté » ou « Clôturé ». Il s’agit souvent d’un attribut au niveau du cas qui représente le résultat final. L’analyse du statut final permet de comprendre les résultats globaux du processus. Par exemple, un nombre élevé de demandes « Rejeté » ou « Retiré » peut révéler des problèmes lors de la phase de demande initiale ou un processus d’approbation laborieux. Cet attribut est essentiel pour mesurer les taux de réussite et l’efficacité du processus. Pourquoi est-ce important ? Il indique clairement le résultat de chaque cas et permet d’analyser les taux d’approbation, de rejet et de retrait, qui sont des indicateurs clés de performance. Où trouver ces données Le champ de statut se trouve généralement dans la table d’en-tête des demandes d’achat, PurchReqTable, sous le nom « Status » ou « PurchReqStatus ». Exemples ApprouvéEn cours d’examenRejetéBrouillon
	Utilisateur User	Identifiant ou nom de l’utilisateur qui a réalisé l’activité.
Description Cet attribut identifie l’employé ou l’utilisateur système responsable d’une étape précise du processus, comme la soumission d’une demande d’achat ou l’approbation d’une demande. Il peut s’agir d’un identifiant utilisateur, d’un nom complet ou d’une adresse e-mail. L’analyse des activités par utilisateur permet de repérer les besoins de formation, les personnes ou les équipes les plus performantes et la répartition de la charge de travail. Elle est également essentielle à l’analyse de la conformité, notamment à la séparation des tâches, et à la compréhension des interactions entre les différents rôles et le processus. Pourquoi est-ce important ? Il permet d’analyser les comportements, la charge de travail et les performances propres à chaque utilisateur, ce qui est essentiel à la gestion des ressources et au repérage des besoins de formation. Où trouver ces données Cet attribut figure généralement dans les tables d’historique des flux de travail, comme WorkflowTrackingStatusTable, ou dans les tables de transactions, comme PurchReqTable, reliées à une table d’utilisateurs, comme UserInfo. Exemples j.smitha.joness.patel
	Approuvée dès la première soumission IsFirstPass	Indicateur précisant si une demande a été approuvée sans modification ni rejet préalable.
Description Cet attribut booléen calculé vaut « true » si le parcours d’approbation d’une demande ne comprend aucune activité « Demande d’achat modifiée » ni « Étape d’approbation rejetée ». Dans le cas contraire, il vaut « false ». Cet attribut contribue directement à l’indicateur clé de performance « Taux d’approbation des demandes dès la première soumission ». Il simplifie l’analyse de l’efficacité du processus en fournissant un indicateur clair des reprises pour chaque cas. Un faible taux d’approbation dès la première soumission révèle des problèmes de qualité des données initiales ou des exigences peu claires, et signale une possibilité d’amélioration du processus. Pourquoi est-ce important ? Il mesure directement la qualité et l’efficacité du processus en repérant les cas qui ont nécessité des reprises, et contribue aux indicateurs clés de performance portant sur les demandes correctement traitées dès la première fois. Où trouver ces données Cet attribut est calculé lors de la transformation des données. Il faut analyser la séquence complète des activités de chaque cas pour vérifier qu’aucune activité de reprise n’a eu lieu avant l’approbation. Exemples truefalse
	Devise Currency	Code de devise du montant de la demande.
Description Cet attribut précise la devise, par exemple USD, EUR ou GBP, dans laquelle est exprimé le montant total de la demande. Il est essentiel pour l’analyse financière, en particulier dans les organisations multinationales qui utilisent plusieurs devises. L’attribut de devise permet de traiter et d’agréger correctement les données financières. Il garantit une interprétation juste des montants et permet de les convertir dans une devise commune afin d’établir des rapports et des comparaisons fiables entre différentes régions ou unités opérationnelles. Pourquoi est-ce important ? Il apporte le contexte nécessaire aux attributs financiers et garantit une interprétation et une agrégation exactes des montants dans les environnements multidevises. Où trouver ces données Ce champ se trouve généralement dans la table d’en-tête des demandes d’achat, PurchReqTable, à côté des champs de montant. Exemples USDEURGBP
	Groupe d’approbateurs ApproverGroup	Groupe d’utilisateurs ou rôle chargé d’une étape d’approbation.
Description Cet attribut désigne le groupe, le rôle ou la file d’attente chargé de traiter une tâche d’approbation précise, par exemple « Approbateurs des finances » ou « Responsables informatiques ». L’analyse de la performance des processus par groupe d’approbateurs permet de comprendre la répartition de la charge de travail et de repérer les groupes qui manquent de ressources ou ont besoin d’une formation complémentaire. Elle complète directement le Dashboard « Analyse des goulots d’étranglement des étapes d’approbation », qui permet de ventiler les résultats par équipe responsable des approbations. Pourquoi est-ce important ? Il permet de comparer la performance des équipes d’approbation et de repérer les éventuelles contraintes de ressources ou les besoins de formation au sein de certains groupes. Où trouver ces données Ces informations figurent dans l’historique du flux de travail (par exemple, WorkflowTrackingStatusTable), qui consigne l’utilisateur ou le groupe d’utilisateurs affecté à chaque tâche. Exemples Approbateurs des financesResponsables informatiquesDirection générale
	Nombre de modifications AmendmentCount	Nombre total de modifications apportées à une demande.
Description Cet attribut numérique calculé compte les occurrences de l’activité « Demande d’achat modifiée » pour chaque cas de demande d’achat. Cet attribut est essentiel pour le Dashboard « Fréquence de modification des demandes d’achat » et l’indicateur clé de performance « Taux de modification des demandes d’achat ». Il quantifie les reprises pour chaque cas et facilite le repérage des demandes, services ou utilisateurs associés à de nombreuses modifications et à une faible efficacité. Ces informations permettent de cibler les efforts visant à améliorer la qualité des demandes initiales. Pourquoi est-ce important ? Il quantifie les reprises dans un cas et facilite la mesure et l’analyse de la fréquence des modifications ainsi que de leur incidence sur l’efficacité du processus. Où trouver ces données Cet attribut est calculé lors de la transformation des données en comptant les activités « Demande d’achat modifiée » pour chaque PurchaseRequisitionId unique. Exemples 013
	Numéro de commande d’achat PurchaseOrderNumber	Identifiant de la commande d’achat créée à partir de la demande.
Description Cet attribut stocke l’identifiant unique de la commande d’achat générée à partir d’une demande d’achat approuvée. Il relie le processus de demande au processus d’approvisionnement qui suit. Le suivi de ce numéro est essentiel pour analyser le « Délai de conversion d’une demande en commande d’achat ». Il confirme qu’une demande est passée à l’étape suivante du cycle Purchase-to-Pay et permet d’analyser le processus de bout en bout, des demandes aux commandes d’achat. Pourquoi est-ce important ? Il relie la demande à la commande d’achat qui en découle, ce qui permet d’analyser la conversion de la demande en commande et de relier les différentes étapes du processus P2P. Où trouver ces données Après la création d’une commande d’achat, ces informations se trouvent généralement dans la table des lignes de demande d’achat (PurchReqLine), qui renvoie à PurchTable. Exemples PO-000987PO-000988PO-000989
	Parcours du flux de travail d’approbation ApprovalWorkflowPath	Représentation de la séquence des étapes d’approbation suivies.
Description Cet attribut calculé regroupe, dans l’ordre, les étapes d’approbation suivies pour une demande donnée, par exemple « Approbation du responsable -> Approbation du responsable de service -> Approbation des finances ». Il résume ainsi la variante du sous-processus d’approbation. Cet attribut est essentiel pour le Dashboard « Suivi des écarts de conformité ». En comparant le parcours réel du flux de travail à un parcours standard ou attendu, vous pouvez facilement repérer les flux inhabituels ou non conformes, susceptibles de signaler une violation des règles ou un risque opérationnel. Pourquoi est-ce important ? Il simplifie l’analyse de la conformité en représentant clairement la variante du processus sous forme de texte, ce qui facilite le repérage des écarts par rapport aux procédures standard. Où trouver ces données Cet attribut ne correspond pas à un champ standard. Il doit être calculé lors de la transformation des données en regroupant, dans l’ordre chronologique, les valeurs de « ApprovalStep » pour chaque cas. Exemples Responsable -> DirecteurResponsable -> Directeur -> Vice-président des financesResponsable -> Approbation automatique

Obligatoire Recommandé Facultatif

Activités des demandes d’achat Purchase-to-Pay

Voici les étapes et jalons essentiels à consigner dans votre journal d’événements pour découvrir et analyser avec précision le flux de travail de vos demandes d’achat.

7 Recommandé 5 Facultatif

	Activité	Description
	Commande d’achat créée	Une ligne approuvée de la demande d’achat est convertie en ligne de commande d’achat, ce qui marque le transfert à l’équipe chargée des achats. L’événement est repéré en reliant la ligne de demande à la ligne de commande correspondante.
Pourquoi est-ce important ? Cette étape importante relie la demande au processus d’achat en aval. Elle est indispensable pour mesurer le KPI « délai de conversion d’une demande d’achat en commande ». Où trouver ces données L’événement est déduit de la présence, dans la table ’PurchLine’, d’un enregistrement faisant référence à l’identifiant d’une ’PurchReqLine’ associée au cas de la demande. Données à recueillir Reliez PurchReqLine à PurchLine à l’aide du champ de référence, par exemple PurchReqLineRefId. Type d’événement inferred
	Demande d’achat approuvée	La demande a franchi avec succès toutes les étapes d’approbation requises dans le flux de travail. Cette activité est enregistrée lorsque l’instance du flux de travail se termine avec le statut final approuvé.
Pourquoi est-ce important ? Cette étape importante marque la fin du cycle d’approbation et le début du processus d’achat. Elle correspond à l’événement de fin du KPI « délai d’approbation des demandes d’achat ». Où trouver ces données L’événement est consigné explicitement dans ’WorkflowTrackingStatusTable’ à la fin du flux de travail. Le champ ’Status’ de ’PurchReqTable’ est alors mis à jour avec la valeur ’Approved’. Données à recueillir Filtrez les événements de fin du flux de travail dont le statut est ’Approved’, ou suivez les changements de statut dans PurchReqTable. Type d’événement explicit
	Demande d’achat clôturée	La demande d’achat est considérée comme terminée lorsque toutes ses lignes ont été converties en commandes d’achat ou annulées. Il s’agit de l’état final de réussite.
Pourquoi est-ce important ? Cette activité marque la fin du cycle de vie de la demande. Elle constitue le point final pour mesurer la durée totale du processus, de bout en bout. Où trouver ces données Ce statut est généralement calculé ou déduit. Il est atteint lorsque toutes les lignes ’PurchReqLine’ associées ont un statut final, par exemple ’Closed’ ou ’Cancelled’. Données à recueillir Déduisez cet événement en vérifiant que toutes les lignes PurchReqLine associées à un enregistrement PurchReqTable ont un statut final. Type d’événement calculated
	Demande d’achat créée	Cet événement correspond à la création initiale de la demande d’achat, qui est alors à l’état de brouillon. Il est repéré à partir de l’horodatage de création de l’en-tête de la demande.
Pourquoi est-ce important ? En tant que point de départ du processus, cette activité est essentielle pour mesurer la durée totale du cycle de vie des demandes et analyser leur volume quotidien. Où trouver ces données Cette activité est déduite du champ ’createdDateTime’ de la table ’PurchReqTable’ pour chaque nouvel identifiant de demande d’achat. Données à recueillir Utilisez l’horodatage de création de l’enregistrement dans PurchReqTable. Type d’événement inferred
	Demande d’achat rejetée	La demande a été rejetée pendant le processus d’approbation et ne sera pas traitée davantage. Elle se trouve alors dans un état d’échec définitif.
Pourquoi est-ce important ? Cet événement de fin est essentiel pour analyser le taux global de rejet et comprendre les conséquences financières ou opérationnelles des demandes refusées. Où trouver ces données L’événement est consigné explicitement dans ’WorkflowTrackingStatusTable’ à la fin du flux de travail, avec le statut ’Rejected’. Le champ de statut de ’PurchReqTable’ est alors mis à jour. Données à recueillir Filtrez les événements de fin du flux de travail dont le statut est ’Rejected’, ou suivez les changements de statut dans PurchReqTable. Type d’événement explicit
	Demande d’achat soumise pour approbation	L’utilisateur soumet la demande remplie, ce qui lance le processus formel d’approbation. Le moteur de flux de travail du système consigne explicitement cette action.
Pourquoi est-ce important ? Cette activité marque une étape importante : elle lance le cycle d’approbation. Elle sert de point de départ au calcul du « délai d’approbation des demandes d’achat » et du « taux d’approbation dès la première soumission ». Où trouver ces données L’événement est enregistré dans la table ’WorkflowTrackingStatusTable’ ou dans une table similaire d’historique des flux de travail, où une soumission est consignée pour la demande d’achat. Données à recueillir Dans les journaux d’historique des flux de travail, filtrez les événements de type ’Submission’ ou ’Start’ associés à la demande. Type d’événement explicit
	Étape d’approbation approuvée	L’approbateur termine la tâche qui lui a été attribuée et approuve la demande à cette étape du processus. La demande passe alors à l’étape suivante ou à l’approbation finale.
Pourquoi est-ce important ? Cette activité mesure le temps de traitement de chaque étape d’approbation et aide à repérer les étapes du flux de travail qui se déroulent efficacement. Elle joue un rôle important dans l’analyse des variantes. Où trouver ces données L’événement est consigné explicitement dans ’WorkflowTrackingStatusTable’ lorsqu’un utilisateur termine un élément de travail avec le résultat ’Approve’. Données à recueillir Dans les journaux d’historique des flux de travail, repérez les événements ’WorkItemCompleted’ dont le résultat est ’Approve’. Type d’événement explicit
	Demande d’achat modifiée	Cet événement se produit lorsqu’un utilisateur retire une demande soumise du flux de travail pour la modifier. Il est généralement repéré par une action de retrait suivie d’une nouvelle soumission.
Pourquoi est-ce important ? Le suivi des modifications est essentiel pour repérer les reprises, les demandes initiales imprécises et les inefficacités du processus. Il alimente directement le Dashboard « Fréquence des modifications des demandes d’achat ». Où trouver ces données L’événement peut être déduit de l’historique des flux de travail (’WorkflowTrackingStatusTable’) en repérant une action ’Recall’ ou ’RequestChange’. Il peut également être déduit des modifications du champ ’modifiedDateTime’ dans ’PurchReqTable’ après la soumission. Données à recueillir Repérez les événements de retrait du flux de travail ou les changements de version de l’enregistrement entre les soumissions. Type d’événement inferred
	Demande d’achat retirée	Après la soumission de la demande, son créateur ou un utilisateur autorisé l’annule. Cette action met fin au flux de travail et à la demande.
Pourquoi est-ce important ? Le suivi des retraits aide à repérer les problèmes de planification des besoins ou les processus trop complexes. Il alimente le Dashboard « Analyse des retraits de demandes d’achat ». Où trouver ces données L’événement est déduit d’un changement du statut de ’PurchReqTable’ à ’Cancelled’ ou d’un événement ’Cancel’ dans ’WorkflowTrackingStatusTable’. Données à recueillir Repérez le passage du statut de PurchReqTable à ’Cancelled’ ou un événement d’annulation du flux de travail. Type d’événement inferred
	Étape d’approbation commencée	Dans le cadre du flux de travail, une tâche d’approbation est attribuée à un utilisateur ou à un groupe. Cette étape marque le début du temps d’attente ou de traitement pour un approbateur donné.
Pourquoi est-ce important ? Cette activité est essentielle à l’« Analyse des goulots d’étranglement des étapes d’approbation », qui permet de mesurer les temps d’attente à chaque étape. Où trouver ces données L’événement est enregistré dans ’WorkflowTrackingStatusTable’ lorsqu’un nouvel élément de travail est créé et attribué dans le cadre du flux de travail de la demande. Données à recueillir Dans les journaux d’historique des flux de travail, repérez les événements ’WorkItemCreated’ ou similaires associés à la demande concernée. Type d’événement explicit
	Étape d’approbation rejetée	L’approbateur rejette la tâche qui lui a été attribuée, ce qui renvoie généralement la demande à son auteur pour correction. Le moteur de flux de travail consigne explicitement cette action.
Pourquoi est-ce important ? Cette activité est indispensable pour calculer le « taux de rejet des demandes d’achat » et repérer les étapes où les rejets sont les plus fréquents, afin de cibler les améliorations du processus. Où trouver ces données L’événement est consigné explicitement dans ’WorkflowTrackingStatusTable’ lorsqu’un utilisateur termine un élément de travail avec le résultat ’Reject’. Données à recueillir Dans les journaux d’historique des flux de travail, repérez les événements ’WorkItemCompleted’ dont le résultat est ’Reject’. Type d’événement explicit
	Ligne de demande d’achat clôturée	Une ligne de la demande d’achat est considérée comme entièrement traitée. C’est généralement le cas lorsqu’elle a été entièrement convertie en commande d’achat.
Pourquoi est-ce important ? Cette activité fournit des informations détaillées sur le traitement des demandes et permet de déterminer si elles ont été converties en commandes d’achat en partie ou en totalité. Où trouver ces données L’événement est déduit du champ de statut de la table ’PurchReqLine’. Un statut indiquant que la ligne a été commandée ou reçue signifie qu’elle est clôturée. Données à recueillir Surveillez le champ de statut de la table PurchReqLine pour repérer une valeur finale comme ’Invoiced’ ou ’Closed’. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Microsoft Dynamics 365

Étapes

Ouvrez l’espace de travail de gestion des données : Connectez-vous à Microsoft Dynamics 365, puis ouvrez le menu Workspaces. Sélectionnez Data management pour accéder au centre de gestion des importations et des exportations de données.
Créez un projet d’exportation : Dans l’espace de travail de gestion des données, cliquez sur la vignette Export. Saisissez un Group name unique, une Description explicite et définissez la Project category sur Project. Vous pourrez ainsi organiser vos tâches d’extraction de données.
Ajoutez les entités de données : Ajoutez à votre projet les entités de données standard nécessaires. Cliquez sur Add entity, recherchez chacune des entités suivantes, puis ajoutez-les une par une :
- Purchase requisition headers
- Purchase requisition lines
- Workflow tracking status table
- Workflow work items
- Purchase order lines V2
Définissez le format d’exportation : Pour chaque entité ajoutée, sélectionnez un Target data format, par exemple CSV ou Excel. Le format CSV est généralement recommandé pour ses performances et sa compatibilité avec les outils de transformation des données.
Appliquez des filtres aux données : Sélectionnez une entité, puis cliquez sur Filter. Dans l’onglet Range, indiquez l’entité juridique (code société) afin d’extraire les données de la bonne unité opérationnelle. Il est également essentiel de filtrer le champ Created date and time de l’entité Purchase requisition headers pour limiter le volume de données. Nous recommandons de commencer par une période de 3 à 6 mois.
Lancez l’exportation : Une fois les entités et les filtres configurés, cliquez sur Export dans le volet Actions. Le système crée un package de traitement et lance l’opération. Vous pouvez suivre sa progression dans la section Job history.
Téléchargez le package de données : Une fois l’exportation terminée, ouvrez les détails de Job history, puis cliquez sur Download package. Vous téléchargerez un fichier ZIP contenant les fichiers de données distincts pour chaque entité.
Transformez les données brutes en journal d’événements : Les fichiers exportés correspondent aux tables brutes du système, et non à un journal d’événements prêt à l’emploi. Vous devez utiliser un outil externe, comme Python, Power Query ou une plateforme ETL, pour combiner et restructurer les données. Il faut notamment :
- Joindre les fichiers d’en-tête et de lignes.
- Relier les données de flux de travail aux demandes d’achat à l’aide de CorrelationId et du RecId de l’en-tête de demande d’achat.
- Transformer les changements de statut et les événements de flux de travail des tables concernées en lignes d’activité distinctes (Requisition Submitted, Approval Step Approved, etc.).
- Créer une ligne pour chaque activité, avec les valeurs appropriées pour ActivityName, EventTime et PurchaseRequisitionId.
Calculez et associez les attributs : Pendant la transformation, associez les colonnes sources aux attributs requis, comme User et Department. Calculez les attributs dérivés, par exemple RequisitionTotalAmount, en additionnant les montants des lignes. Attribuez une valeur fixe à SourceSystemId (par exemple, D365_F&O) et utilisez l’heure d’exécution de votre script pour LastDataIngestionTimestamp.
Finalisez et formatez le résultat : Vérifiez que le fichier final est un seul fichier CSV, dans lequel chaque ligne représente un événement du processus. Les colonnes doivent respecter la structure requise du journal d’événements, notamment PurchaseRequisitionId, ActivityName et EventTime.

Configuration

Autorisations requises : Les utilisateurs doivent disposer d’un rôle de sécurité leur donnant accès à l’espace de travail Data management et aux entités de données exportées, par exemple Data management administrator ou un rôle personnalisé équivalent.
Principales entités de données :
- Purchase requisition headers : fournit l’identifiant principal du cas, l’horodatage de création et le statut général.
- Purchase requisition lines : contient le détail des articles demandés, notamment les montants et les liens vers les commandes d’achat.
- Workflow tracking status table : principale source des événements de flux de travail, comme la soumission, l’approbation, le rejet et le rappel.
- Workflow work items : détaille les tâches attribuées aux utilisateurs pendant le processus d’approbation.
- Purchase order lines V2 : permet de retrouver l’horodatage de création de la commande d’achat associée à une ligne de demande.
Filtrage par période : Il est essentiel d’appliquer un filtre de dates au champ Created date and time de l’entité Purchase requisition headers. Pour une première analyse, une période de 3 à 6 mois est recommandée afin de trouver un équilibre entre le volume de données et la qualité de l’analyse.
Filtrage par code société : Appliquez toujours un filtre sur l’entité juridique (Legal entity) afin d’éviter d’extraire des données de sociétés non concernées ou de test. Cette mesure réduit considérablement le volume de données et améliore les performances du traitement.
Transformation des données : Cette méthode nécessite une étape importante de post-traitement en dehors de Dynamics 365 pour convertir les exportations brutes des entités en un journal d’événements structuré. Prévoyez d’utiliser un script ou un outil ETL.

Exemple de requête sql

/*
This is not a single executable query. Instead, it is a configuration manifest for a Dynamics 365 Data Management Framework Export Project.
You must add each entity listed below to the project and select the specified fields for export.
The transformation logic to create the final event log must be applied after exporting these files.
*/

-- Entity 1: Purchase requisition headers
-- Purpose: Captures requisition creation, overall status, and header-level attributes.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    REQUISITIONSTATUS AS RequisitionStatus,
    CREATEDDATETIME AS EventTime_RequisitionCreated,
    MODIFIEDDATETIME AS EventTime_RequisitionClosed, -- Used if status is Closed
    PREPARERPERSONNELNUMBER AS User_Preparer,
    REQUESTERPERSONNELNUMBER AS User_Requester,
    DEFAULTLEDGERDIMENSIONDISPLAYVALUE AS Department, -- Or similar dimension field
    REQUISITIONTOTAL AS RequisitionTotalAmount
FROM PurchaseRequisitionHeaderEntity;

-- Entity 2: Purchase requisition lines
-- Purpose: Provides line-level details, amounts, and links to Purchase Orders.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    LINENUMBER,
    REQUISITIONINGSTATUS AS LineStatus,
    MODIFIEDDATETIME AS EventTime_LineClosed, -- Used if status is Closed
    PURCHASEORDERNUMBER,
    PURCHASEORDERLINENUMBER
FROM PurchaseRequisitionLineEntity;

-- Entity 3: Workflow tracking status table
-- Purpose: The primary source for all workflow-driven activities.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CONTEXT, -- Contains information like step name
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_WorkflowStep,
    TRACKINGSTATUS AS ActivityName, -- (e.g., Submitted, Approved, Rejected, Canceled)
    USERID AS User
FROM WorkflowTrackingStatusTableEntity;

-- Entity 4: Workflow work items
-- Purpose: Captures the start of an approval task assigned to a user.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_ApprovalStepStarted,
    USERID AS User, -- The user assigned the task
    DESCRIPTION AS ApprovalStep
FROM WorkflowWorkItemTableEntity;

-- Entity 5: Purchase order lines V2
-- Purpose: Used to find the creation date of the resulting Purchase Order.
-- Note: Requires joining to PurchaseRequisitionLineEntity on PO/Line number post-export.
SELECT
    PURCHASEORDERNUMBER,
    LINENUMBER,
    CREATEDDATETIME AS EventTime_PurchaseOrderCreated
FROM PurchaseOrderLinesV2Entity;

Étapes

Enregistrez une application Azure Active Directory : Ouvrez le portail Azure et enregistrez une nouvelle application. Celle-ci servira à l’authentification auprès de l’API Dynamics 365. Notez l’ID d’application (client) et l’ID de répertoire (locataire).
Générez un secret client : Dans l’application que vous venez d’enregistrer dans Azure, créez un secret client dans « Certificates & secrets ». Copiez la valeur du secret et conservez-la en lieu sûr, car elle ne sera plus affichée.
Accordez les autorisations d’API : Dans la section « API permissions » de l’application, ajoutez une autorisation pour « Dynamics ERP ». Sélectionnez « Delegated permissions » et accordez Financials.ReadWrite.All ou une autorisation équivalente, plus restrictive et en lecture seule. Accordez le consentement administrateur pour ces autorisations.
Installez les bibliothèques Python : Vérifiez que Python est installé, puis installez les bibliothèques nécessaires avec pip : pip install requests pandas.
Configurez le script Python : Copiez le script Python fourni dans un fichier, par exemple extract_d365_requisitions.py. Renseignez les variables de substitution en haut du script : URL Dynamics 365, ID du locataire, ID client, secret client, période souhaitée et ID de la société.
Repérez les entités OData : Le script interroge trois entités de données principales : PurchaseRequisitionHeaders pour les détails de la demande, PurchaseRequisitionLines pour les lignes, notamment leur conversion en commandes d’achat, et WorkflowTrackingStatusTable pour les événements de flux de travail, comme les soumissions et les approbations.
Exécutez le script : Lancez le script depuis la ligne de commande : python extract_d365_requisitions.py. Le script s’authentifie, récupère les données de chaque activité et gère automatiquement la pagination de l’API.
Transformez les données : Le script traite les données JSON brutes renvoyées par les appels à l’API. Il les restructure en parcourant les enregistrements et en créant une ligne distincte pour chacune des 12 activités métier. Il associe les champs sources aux colonnes standard du journal d’événements, comme PurchaseRequisitionId, ActivityName et EventTime.
Regroupez et normalisez les événements : Tous les événements générés sont rassemblés dans une même liste, puis convertis en DataFrame pandas. Le script ajoute des colonnes fixes, comme SourceSystemId et LastDataIngestionTimestamp.
Exportez au format CSV : Le DataFrame final est exporté dans un fichier CSV nommé d365_purchase_requisition_log.csv. Ce fichier est prêt à être importé directement dans un outil de Process Mining. Vérifiez qu’il est encodé en UTF-8.

Configuration

Prérequis : Vous devez avoir accès à un abonnement Azure pour enregistrer une application, ainsi qu’à un ID d’application (client), un secret client et un ID de locataire fournis par Azure Active Directory. L’utilisateur qui exécute le script doit disposer d’identifiants lui donnant accès aux points de terminaison de l’API OData de Dynamics 365 Finance and Operations.
Configuration du point de terminaison de l’API : Le script nécessite l’URL de base de votre environnement Dynamics 365, généralement au format https://[your-environment-name].operations.dynamics.com.
Période : Définissez les variables START_DATE et END_DATE dans le script pour délimiter la période d’extraction. Pour une première analyse, une période de 3 à 6 mois est recommandée afin de concilier volume de données et qualité de l’analyse.
Filtre par société : Le script est configuré pour filtrer une entité juridique précise à l’aide de la variable COMPANY_ID. Pour extraire les données de toutes les sociétés, vous devrez peut-être modifier le filtre OData et inclure cross-company=true dans les en-têtes de la requête.
Performances : Le script ne récupère que les colonnes nécessaires au journal d’événements grâce à $select dans les requêtes OData, ce qui améliore les performances. Il gère également la pagination pour traiter les grands volumes de données sans surcharger l’API. Pour les extractions historiques très volumineuses, envisagez d’exécuter le script par lots, sur des périodes plus courtes.

Exemple de requête python

import requests
import pandas as pd
from datetime import datetime, timezone
import os

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Dynamics 365 environment details
D365_URL = class="hl-string">"https://[your-d365-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[your-tenant-id]"
CLIENT_ID = class="hl-string">"[your-client-id]"
CLIENT_SECRET = class="hl-string">"[your-client-secret]"

class=class="hl-string">"hl-comment"># --- Parameters ---
class=class="hl-string">"hl-comment"># Set the data extraction window
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"
COMPANY_ID = class="hl-string">"[YourCompanyLegalEntity]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">"USMF"
OUTPUT_FILENAME = class="hl-string">"d365_purchase_requisition_log.csv"


def get_access_token():
    class="hl-string">"""Authenticates with Azure AD to get an access token."""
    auth_url = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}/oauth2/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET,
        class="hl-string">'resource': D365_URL
    }
    response = requests.post(auth_url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

def fetch_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_records = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Accept': class="hl-string">'application/json'
    }
    while entity_url:
        response = requests.get(entity_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        all_records.extend(data[class="hl-string">'value'])
        entity_url = data.get(class="hl-string">'@odata.nextLink')
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    print(class="hl-string">"Acquiring access token...")
    access_token = get_access_token()
    events = []
    last_ingestion_ts = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Purchase Requisition Headers for class="hl-string">'Created' and class="hl-string">'Closed' events
    print(class="hl-string">"Fetching Purchase Requisition Headers...")
    pr_headers_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionHeaders?" 
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}" 
        fclass="hl-string">"&$select=RequisitionNumber,RequisitionStatus,CreatedDateTime,CreatedBy,RequestingDepartmentName,RequisitionTotalAmount,RequisitionUrgencyLevel"
    )
    pr_headers = fetch_data(access_token, pr_headers_url)

    for prh in pr_headers:
        case_id = prh.get(class="hl-string">'RequisitionNumber')
        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        events.append({
            class="hl-string">'PurchaseRequisitionId': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Requisition Created',
            class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'),
            class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
            class="hl-string">'RequisitionStatus': prh.get(class="hl-string">'RequisitionStatus'),
            class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
            class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
            class="hl-string">'ApprovalStep': None,
            class="hl-string">'ProcessingTime': None
        })
        class=class="hl-string">"hl-comment"># Activity: Requisition Closed
        if prh.get(class="hl-string">'RequisitionStatus') == class="hl-string">'Closed':
            class=class="hl-string">"hl-comment"># Note: We need a reliable timestamp for closure. Using CreatedDateTime as a placeholder.
            class=class="hl-string">"hl-comment"># A better source might be the last workflow approval or line closure date.
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Closed',
                class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'), class=class="hl-string">"hl-comment"># Placeholder timestamp
                class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'), class=class="hl-string">"hl-comment"># Placeholder user
                class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
                class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 2. Fetch Workflow History for workflow-related events
    print(class="hl-string">"Fetching Workflow Tracking Status Table...")
    workflow_url = (
        fclass="hl-string">"{D365_URL}/data/WorkflowTrackingStatusTable?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE} and startswith(Context,'PurchReq')"
        fclass="hl-string">"&$select=Context,CreatedDateTime,TrackingType,User,WorkItemSubject"
    )
    workflow_items = fetch_data(access_token, workflow_url)

    for item in workflow_items:
        context_parts = item.get(class="hl-string">'Context', class="hl-string">'').split(class="hl-string">':')
        if len(context_parts) < 2:
            continue
        case_id = context_parts[1].strip()
        tracking_type = item.get(class="hl-string">'TrackingType')
        activity_map = {
            class="hl-string">'Submission': class="hl-string">'Requisition Submitted for Approval',
            class="hl-string">'Started': class="hl-string">'Approval Step Started',
            class="hl-string">'Completion': class="hl-string">'Approval Step Approved',
            class="hl-string">'Rejection': class="hl-string">'Approval Step Rejected',
            class="hl-string">'Cancellation': class="hl-string">'Requisition Withdrawn',
            class="hl-string">'Recall': class="hl-string">'Requisition Amended',
            class="hl-string">'Approved': class="hl-string">'Requisition Approved',
            class="hl-string">'Fault': class="hl-string">'Requisition Rejected'
        }
        activity_name = activity_map.get(tracking_type)
        if activity_name:
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
                class="hl-string">'User': item.get(class="hl-string">'User'),
                class="hl-string">'Department': None, class=class="hl-string">"hl-comment"># Department info is not in this entity
                class="hl-string">'RequisitionStatus': None, class=class="hl-string">"hl-comment"># Status info is not in this entity
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': item.get(class="hl-string">'WorkItemSubject'),
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 3. Fetch Purchase Requisition Lines for PO Creation and Line Closure
    print(class="hl-string">"Fetching Purchase Requisition Lines...")
    pr_lines_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionLines?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}"
        fclass="hl-string">"&$select=RequisitionNumber,PurchaseOrderNumber,IsPrepaymentRequired,LineStatus,ModifiedDateTime,ModifiedBy"
    )
    pr_lines = fetch_data(access_token, pr_lines_url)

    for prl in pr_lines:
        case_id = prl.get(class="hl-string">'RequisitionNumber')
        po_number = prl.get(class="hl-string">'PurchaseOrderNumber')
        line_status = prl.get(class="hl-string">'LineStatus')
        
        class=class="hl-string">"hl-comment"># Activity: Purchase Order Created
        if po_number:
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': None,
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': fclass="hl-string">"PO: {po_number}",
                class="hl-string">'ProcessingTime': None
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Line Closed
        if line_status == class="hl-string">'Closed':
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Line Closed',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

    if not events:
        print(class="hl-string">"No events found for the specified criteria.")
        return

    class=class="hl-string">"hl-comment"># 4. Create and format the DataFrame
    print(class="hl-string">"Formatting data...")
    df = pd.DataFrame(events)
    df[class="hl-string">'SourceSystemId'] = class="hl-string">'Microsoft Dynamics 365'
    df[class="hl-string">'LastDataIngestionTimestamp'] = last_ingestion_ts

    class=class="hl-string">"hl-comment"># Fill forward missing data within each case
    df = df.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTime'])
    df[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']] = \
        df.groupby(class="hl-string">'PurchaseRequisitionId')[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']].ffill().bfill()

    class=class="hl-string">"hl-comment"># Ensure required columns exist and are in order
    final_columns = [
        class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'SourceSystemId',
        class="hl-string">'LastDataIngestionTimestamp',
        class="hl-string">'User',
        class="hl-string">'Department',
        class="hl-string">'RequisitionStatus',
        class="hl-string">'RequisitionTotalAmount',
        class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalStep',
        class="hl-string">'ProcessingTime'
    ]
    for col in final_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[final_columns]

    class=class="hl-string">"hl-comment"># 5. Save to CSV
    df.to_csv(OUTPUT_FILENAME, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Successfully extracted {len(df)} events to {OUTPUT_FILENAME}")

if __name__ == class="hl-string">"__main__":
    main()

Étapes

Vérifiez que le connecteur natif Microsoft Dynamics 365 Finance est disponible dans Power BI Desktop et que l’utilisateur est autorisé à accéder aux entités de données requises, à l’historique des flux de travail, aux données des demandes d’achat et aux données associées des commandes d’achat.
Dans Power BI Desktop, sélectionnez « Obtenir les données », choisissez le connecteur Microsoft Dynamics 365 Finance et indiquez l’URL de l’instance Dynamics 365 Finance. Authentifiez-vous avec un compte autorisé à lire les entités requises. Remplacez [Your Dynamics 365 Finance instance URL] par l’URL de l’instance de votre environnement.
Dans le navigateur, sélectionnez les entités d’en-tête et de lignes des demandes d’achat, celles de l’historique ou du suivi des flux de travail, les entités utilisateur et organisationnelles, ainsi que les entités de commandes d’achat requises par votre configuration. Les noms des entités et les champs disponibles varient selon l’environnement. Consultez les métadonnées des entités et remplacez chaque élément générique de la requête par l’entité et le champ correspondants exposés par votre système.
Chargez les entités sélectionnées dans Power Query. Filtrez les données selon l’entité juridique ou la société, le type de document et la période d’extraction requis. Utilisez les paramètres [Start date] et [End date], puis conservez les enregistrements dont l’horodatage de l’événement se situe dans la période choisie. Incluez les en-têtes créés avant le début de cette période s’ils comportent des événements de flux de travail ou de clôture survenus pendant celle-ci, afin de conserver l’historique complet des cas.
Normalisez les identifiants et les horodatages. Convertissez l’identifiant de la demande d’achat en texte, harmonisez le fuseau horaire de tous les horodatages en utilisant l’UTC ou le fuseau horaire métier, et préservez la précision des horodatages sources. Vérifiez que l’identifiant de l’en-tête de demande d’achat figure sur chaque ligne d’événement. Si les enregistrements de flux de travail ne contiennent qu’un identifiant de corrélation, reliez-les à l’en-tête de demande d’achat selon la relation documentée et configurée dans votre environnement.
Créez une requête d’événements pour chaque activité requise. Ces requêtes doivent renvoyer explicitement des lignes pour les activités suivantes : Requisition Created, Requisition Submitted for Approval, Requisition Amended, Approval Step Started, Approval Step Approved, Approval Step Rejected, Requisition Approved, Requisition Rejected, Requisition Withdrawn, Purchase Order Created, Requisition Line Closed et Requisition Closed. Ne comptez pas sur ProcessMind pour déduire une activité à partir des changements de statut ou de l’ordre des événements.
Pour Requisition Amended, appliquez la logique documentée de rappel et de nouvelle soumission à partir de l’historique des flux de travail. Un rappel suivi d’une soumission ultérieure doit générer un événement de modification à l’horodatage du rappel ou à celui de la modification indiqué par l’entité source. Ne créez pas de ligne de modification à partir d’un simple changement de statut, sauf si le système source consigne explicitement ce changement comme une modification.
Pour les événements de ligne et de commande d’achat, reliez les lignes de demande d’achat aux lignes de commande selon la relation source documentée. Si le journal d’événements est organisé par cas selon PurchaseRequisitionId, regroupez les événements de ligne ou conservez-les dans des lignes distinctes avec le même identifiant de cas. Lorsque disponibles, conservez les identifiants de ligne dans des colonnes supplémentaires, même s’ils ne font pas partie des attributs requis.
Ajoutez les colonnes de sortie requises : PurchaseRequisitionId, ActivityName, EventTime, SourceSystemId et LastDataIngestionTimestamp. Ajoutez les colonnes recommandées : User, Department, RequisitionStatus, RequisitionTotalAmount, UrgencyLevel et ApprovalStep. Pour les valeurs indisponibles, utilisez null plutôt que des valeurs inventées. Utilisez une valeur source cohérente, telle que Dynamics 365 Finance, pour SourceSystemId.
Ajoutez toutes les requêtes d’activité avec UNION ALL, supprimez les lignes sans identifiant de cas ou horodatage d’événement, puis triez par PurchaseRequisitionId et EventTime. Conservez les événements en double lorsqu’ils correspondent à des tâches de flux de travail ou à des lignes de demande distinctes. Ne supprimez les doublons que si les enregistrements sources sont manifestement des extractions en double.
Validez le journal d’événements à l’aide des contrôles décrits ci-dessous. Vérifiez que chaque activité requise apparaît sous forme de lignes explicites, que les horodatages se situent dans la période sélectionnée et que les jointures ne multiplient pas les événements de manière inattendue.
Chargez ou exportez la table finale au format CSV ou dans un autre format de journal d’événements pris en charge par ProcessMind. Associez PurchaseRequisitionId à l’identifiant du cas, ActivityName à l’activité et EventTime à l’horodatage de l’événement. Conservez SourceSystemId et LastDataIngestionTimestamp comme attributs d’événement, ainsi que tous les attributs recommandés disponibles.

Configuration

Connecteur et source : Utilisez le connecteur natif Microsoft Dynamics 365 Finance dans Power BI Desktop. Remplacez [Your Dynamics 365 Finance instance URL] par l’URL de l’environnement. Vérifiez les noms des entités et des champs dans les métadonnées du navigateur pour l’implémentation concernée.
Entités requises : Sélectionnez les entités d’en-tête et de lignes des demandes d’achat, celles de suivi ou d’historique des flux de travail, celles d’en-tête et de lignes des commandes d’achat, ainsi que les entités utilisateur ou organisationnelles nécessaires à l’enrichissement. Utilisez les éléments génériques [Your entity name] jusqu’à confirmation des entités exactes.
Période : Commencez par trois à six mois de données. Incluez les en-têtes historiques des demandes d’achat correspondant à des cas ayant des événements de flux de travail, de commande d’achat, de clôture de ligne ou de clôture de demande pendant la période sélectionnée.
Filtres sur la société et le document : Appliquez les filtres [Your company or legal entity filter] et [Your document type filter], le cas échéant. Vérifiez si l’identifiant de la demande d’achat est unique à l’échelle globale ou uniquement au sein d’une société.
Périmètre des flux de travail : Incluez les actions de soumission, de rappel, de nouvelle soumission, d’attribution de tâche, d’approbation, de rejet, de retrait, de fin et d’annulation. Configurez les correspondances entre actions et statuts des flux de travail à partir des valeurs utilisées dans l’environnement.
Sémantique des événements : Chaque activité doit être produite sous la forme d’une ligne d’événement explicite. ProcessMind ne déduit pas les événements d’approbation, de modification, de clôture ou de conversion à partir d’autres lignes.
Gestion des horodatages : Harmonisez tous les horodatages selon un même fuseau horaire. Précisez si les horodatages sources sont enregistrés en UTC ou selon l’heure locale de l’entreprise. Utilisez l’horodatage source offrant la meilleure précision.
Actualisation incrémentielle : Pour les extractions récurrentes, utilisez un point de reprise fondé sur le dernier horodatage de modification ou d’événement disponible dans la source, avec une période de chevauchement afin de récupérer les événements de flux de travail tardifs. Réconciliez les données de cette période avant de charger le journal d’événements final.
Performances : Filtrez les entités sources avant les jointures, sélectionnez uniquement les colonnes requises, évitez de charger inutilement l’historique des flux de travail et utilisez le pliage des requêtes lorsqu’il est pris en charge. Extrayez séparément les en-têtes, les lignes, les événements de flux de travail et les relations avec les commandes d’achat avant de les combiner.
Autorisations et prérequis : Le compte doit disposer d’un accès en lecture aux entités de données et aux données des flux de travail sélectionnées dans Dynamics 365 Finance. Vérifiez que les fonctionnalités d’approvisionnement et de flux de travail concernées sont activées et que Power BI Desktop, le connecteur, la configuration de la passerelle le cas échéant et les règles de sécurité de l’organisation autorisent l’extraction.
Devises et montants : Vérifiez la devise utilisée pour RequisitionTotalAmount. Si les demandes d’achat peuvent être libellées dans plusieurs devises, ajoutez la devise source comme attribut et ne convertissez pas les montants sans le signaler.
Gestion des valeurs nulles : Les attributs recommandés peuvent être nuls si la source ne stocke pas de valeur, si les règles de sécurité en limitent l’accès ou si la relation ne peut pas être établie. Avant l’exportation, vérifiez que les valeurs requises pour le cas, l’activité et l’horodatage de l’événement sont présentes.

Exemple de requête sql

WITH
RequisitionHeader AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [CreatedDateTimeField] AS CreatedDateTime,
        [RequisitionStatusField] AS RequisitionStatus,
        [RequisitionTotalAmountField] AS RequisitionTotalAmount,
        [UrgencyLevelField] AS UrgencyLevel,
        [RequesterUserField] AS RequesterUser,
        [DepartmentField] AS Department
    FROM [Your requisition header entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [DocumentTypeField] = '[Your document type filter]'
),
WorkflowEvents AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [WorkflowEventTimestampField] AS EventTime,
        [WorkflowActionField] AS WorkflowAction,
        [WorkflowStatusField] AS WorkflowStatus,
        [ApprovalStepField] AS ApprovalStep,
        [WorkflowUserField] AS EventUser,
        [WorkflowCorrelationField] AS WorkflowCorrelation
    FROM [Your workflow history or workflow tracking entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [WorkflowEventTimestampField] >= CAST('[Start date]' AS datetime2)
      AND [WorkflowEventTimestampField] < CAST('[End date]' AS datetime2)
),
PurchaseOrderLinks AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [PurchaseRequisitionLineIdField] AS PurchaseRequisitionLineId,
        [PurchaseOrderIdField] AS PurchaseOrderId,
        [PurchaseOrderLineIdField] AS PurchaseOrderLineId,
        [PurchaseOrderCreatedDateTimeField] AS PurchaseOrderCreatedDateTime,
        [RequisitionLineClosedDateTimeField] AS RequisitionLineClosedDateTime
    FROM [Your requisition to purchase order relationship entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
RequisitionClosure AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [RequisitionClosedDateTimeField] AS RequisitionClosedDateTime
    FROM [Your requisition closure entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
Events AS (
    SELECT
        h.PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        h.CreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionHeader h
    WHERE h.CreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Submitted for Approval' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your submission action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your recall action value]')
      AND EXISTS (
          SELECT 1
          FROM WorkflowEvents w2
          WHERE w2.PurchaseRequisitionId = w.PurchaseRequisitionId
            AND w2.WorkflowAction IN ('[Your resubmission action value]')
            AND w2.EventTime > w.EventTime
      )

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval task assigned action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval action value]')
      AND w.WorkflowStatus IN ('[Your approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]')
      AND w.WorkflowStatus IN ('[Your final approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]', '[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your final rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your withdrawal or cancellation action value]')

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        p.PurchaseOrderCreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.PurchaseOrderCreatedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.PurchaseOrderCreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Requisition Line Closed' AS ActivityName,
        p.RequisitionLineClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.RequisitionLineClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.RequisitionLineClosedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        c.PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        c.RequisitionClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionClosure c
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = c.PurchaseRequisitionId
    WHERE c.RequisitionClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND c.RequisitionClosedDateTime < CAST('[End date]' AS datetime2)
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    SourceSystemId,
    LastDataIngestionTimestamp,
    [User],
    Department,
    RequisitionStatus,
    RequisitionTotalAmount,
    UrgencyLevel,
    ApprovalStep
FROM Events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

Prêt à commencer ?

Ce modèle vous fournit tout le nécessaire pour commencer à optimiser votre processus Purchase-to-Pay de demande d’achat. Commencez dès aujourd’hui à mettre au jour des analyses utiles.

Retour au guide d’amélioration

Télécharger le modèle

Optimisez le processus Purchase to Pay, de la demande d’achat à l’approbation, dès maintenant

Éliminez les retards et réduisez de 30 % les temps de cycle dans Dynamics 365.

Démarrez votre essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

Votre modèle de données Purchase-to-Pay pour les demandes d’achat

Votre modèle de données Purchase-to-Pay pour les demandes d’achat

Attributs des demandes d’achat Purchase-to-Pay

Activités des demandes d’achat Purchase-to-Pay

Guides d’extraction

Exportation avec le framework de gestion des données de Dynamics 365

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API REST OData de Dynamics 365

Étapes

Configuration

Exemple de requête python

Extraction avec le connecteur natif Microsoft Power BI

Étapes

Configuration

Exemple de requête sql

Prêt à commencer ?

Optimisez le processus Purchase to Pay, de la demande d’achat à l’approbation, dès maintenant

Votre modèle de données Purchase-to-Pay pour les demandes d’achat

Votre modèle de données Purchase-to-Pay pour les demandes d’achat

Attributs des demandes d’achat Purchase-to-Pay

Activités des demandes d’achat Purchase-to-Pay

Guides d’extraction

Exportation avec le framework de gestion des données de Dynamics 365

Étapes

Configuration

Exemple de requête sql

Script Python utilisant l’API REST OData de Dynamics 365

Étapes

Configuration

Exemple de requête python

Extraction avec le connecteur natif Microsoft Power BI

Étapes

Configuration

Exemple de requête sql

Prêt à commencer ?

Optimisez le processus Purchase to Pay, de la demande d’achat à l’approbation, dès maintenant

Prêt à commencer ?