> Amélioration continue des processus > Purchase to Pay Requisition > Microsoft Dynamics 365 > Modèle de données

Votre modèle de données Purchase to Pay - Demande d’achat

Microsoft Dynamics 365

Purchase to Pay - Requisition : attributs (17) Purchase to Pay - Requisition : activités (12) Guides d’extraction (3)

Votre modèle de données Purchase to Pay - Demande d’achat

Ce modèle présente les principaux attributs à collecter et les activités importantes à suivre, afin de vous permettre d’examiner en détail votre processus de demande d’achat. Il fournit également des indications pratiques pour extraire ces données et vous aider à préparer efficacement votre journal d’événements en vue d’une analyse détaillée.

Attributs recommandés à collecter
Activités clés à suivre
Guide d’extraction

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Purchase to Pay - Requisition : attributs

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 - Requisition.

5 Obligatoire 6 Recommandé 6 Facultatif

	Nom	Description
	Heure de l’événement EventTime	Horodatage précis auquel une activité ou un événement donné s’est produit.
Description L’heure de l’événement, ou horodatage, enregistre la date et l’heure auxquelles un événement métier a été enregistré dans le système. Elle constitue la base temporelle de toutes les analyses de processus fondées sur le temps. 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 la performance du processus, d’identifier les goulots d’étranglement et de suivre la conformité aux SLA. Des horodatages exacts sont indispensables à une analyse de Process Mining fiable. Pourquoi c’est important Il fournit l’ordre chronologique des événements, nécessaire pour calculer les durées des processus, identifier les goulots d’étranglement et analyser la performance au fil du temps. Où les obtenir Cette information figure dans les tables d’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 Le Purchase Requisition ID est la clé centrale qui relie toutes les activités associées à une même demande de biens ou de services. Chaque processus de demande d’achat, de la création à l’approbation finale et à la clôture, est suivi à l’aide de cet identifiant unique. Dans le Process Mining, cet attribut est fondamental pour reconstituer le parcours de bout en bout de chaque demande d’achat. Il permet d’analyser les variantes de processus, les temps de cycle et la conformité de chaque cas, afin d’obtenir une vision complète du cycle de vie de la demande. Pourquoi c’est important Il est essentiel pour regrouper tous les événements associés au sein d’une même instance de processus et permettre une analyse complète du cycle de vie de chaque demande d’achat, de bout en bout. Où les obtenir Il s’agit généralement de la clé primaire de la table principale d’en-tête des demandes d’achat, telle que 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 précise survenu dans le processus de demande d’achat.
Description Cet attribut enregistre le nom de chaque activité réalisée au cours du cycle de vie d’une demande d’achat. Parmi les exemples figurent « Requisition Created », « Approval Step Approved » et « Purchase Order Created ». Ces activités constituent les nœuds de la carte de processus découverte. L’analyse de la séquence, de la fréquence et de la durée entre ces activités est au cœur du Process Mining. Elle aide à identifier les goulots d’étranglement, les boucles de reprise et les écarts par rapport au flux de processus standard, et met en évidence les inefficacités opérationnelles. Pourquoi c’est important Cet attribut définit les étapes de la cartographie du processus et permet de visualiser, d’analyser et de comprendre le flux de travail de demande d’achat. Où les obtenir Cette information est généralement issue des journaux de changement de statut, des tables d’historique des flux de travail ou de tables d’événements spécifiques 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 auquel les données ont été extraites et chargées pour la dernière fois dans l’outil de Process Mining.
Description Cet attribut indique l’actualité des données analysées. Il affiche la date et l’heure de la dernière actualisation des données depuis le système source. Il ne s’agit pas d’un champ propre à Dynamics 365, mais de métadonnées ajoutées lors de l’ingestion des données. Cet horodatage est essentiel pour permettre aux utilisateurs d’évaluer l’actualité des analyses. Il les aide à déterminer s’ils consultent des données en temps réel ou un instantané correspondant à un moment précis, ce qui influe sur la pertinence de leurs conclusions. Pourquoi c’est important Il informe les utilisateurs de l’actualité des données et leur permet de comprendre la période couverte par l’analyse ainsi que la pertinence des analyses. Où les obtenir Cette valeur est générée et ajoutée au jeu de données lors du processus d’ingestion des données ou d’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 depuis lequel les données ont été extraites.
Description Cet attribut identifie le système source dont proviennent les données d’événements. Dans ce contexte, il s’agit de « Microsoft Dynamics 365 ». Dans les environnements intégrant plusieurs systèmes, ce champ est essentiel pour assurer la traçabilité des données et en comprendre le contexte. Dans l’analyse, il aide à distinguer les processus susceptibles de s’étendre sur plusieurs systèmes ou à confirmer que les données proviennent d’une source unique faisant autorité. Il est important pour valider les données et garantir que l’analyse repose sur le bon jeu de données. Pourquoi c’est important Il fournit le contexte sur l’origine des données, ce qui est essentiel pour la gouvernance et la validation des données, ainsi que dans les environnements où plusieurs systèmes sont intégrés. Où les obtenir Il s’agit d’une valeur statique, « Microsoft Dynamics 365 », ajoutée lors de l’extraction et de la transformation des données. Exemples Microsoft Dynamics 365 F&OD365MSD365
	Étape d’approbation ApprovalStep	Le nom ou l’étape d’une étape d’approbation donnée dans le flux de travail.
Description Cet attribut identifie l’étape précise du flux de travail d’approbation, par exemple `Manager Approval` ou `Finance Approval`. Il fournit un niveau de détail plus fin que le 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é dans chaque étape d’approbation distincte, vous pouvez déterminer précisément quelles étapes provoquent des retards dans l’ensemble du processus. Vous pouvez ainsi mettre en œuvre des mesures ciblées pour améliorer l’efficacité du flux de travail. Pourquoi c’est important Il permet d’analyser le flux de travail d’approbation avec précision et d’identifier les étapes qui provoquent des goulots d’étranglement. Où les obtenir Cette information figure dans les tables d’historique du flux de travail, comme WorkflowTrackingStatusTable, qui détaillent chaque étape du flux de travail configuré. Exemples Approbation du responsableApprobation du responsable de départementExamen financier
	Montant total de la demande d’achat RequisitionTotalAmount	Valeur monétaire totale de la demande d’achat.
Description Cet attribut représente la valeur totale de toutes les lignes d’une demande d’achat. Le montant influence souvent la complexité du flux de travail d’approbation, les demandes d’un montant élevé nécessitant davantage d’étapes d’approbation. Dans l’analyse des processus, cet attribut est essentiel pour filtrer et analyser les demandes selon leur valeur. Il aide à répondre à des questions telles que « Les demandes d’achat d’un montant élevé prennent-elles plus de temps à approuver ? » ou « Quelle est la valeur des demandes d’achat actuellement bloquées dans le processus ? ». Il fournit ainsi un contexte financier pour évaluer la performance du processus. Pourquoi c’est important Il ajoute une dimension financière à l’analyse, permettant de prioriser les cas de montant élevé et de comprendre l’influence de la valeur monétaire sur le comportement du processus. Où les obtenir Cette valeur figure généralement dans la table d’en-tête des demandes d’achat ou est calculée comme la somme des montants des lignes de la table des lignes de demandes d’achat, PurchReqLine. Exemples 1500.0025000.50500.75
	Niveau d’urgence UrgencyLevel	Classification du niveau d’urgence de la demande d’achat, par exemple « Élevé », « Moyen » ou « Faible ».
Description Le niveau d’urgence, ou la priorité, indique la rapidité avec laquelle les biens ou les services demandés sont nécessaires. Cet attribut sert souvent à influencer le circuit d’approbation ou à prioriser le travail des approbateurs. L’analyse de cet attribut permet de déterminer si le système de priorité est efficace. Vous pouvez, par exemple, comparer les temps de cycle des demandes d’achat à urgence `High` et `Low`. Si aucune différence importante n’apparaît, cela peut indiquer que le champ de priorité est ignoré ou mal utilisé, ce qui constitue une information importante pour le Dashboard « Analyse de l’impact du niveau d’urgence ». Pourquoi c’est important Il permet d’évaluer si les paramètres de priorité accélèrent effectivement le traitement des demandes urgentes et de détecter une éventuelle mauvaise utilisation de la classification de l’urgence. Où les obtenir Il peut s’agir d’un champ standard ou personnalisé de PurchReqTable. Son existence 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 précise le service métier ou le centre de coûts à l’origine de la demande d’achat, par exemple « Marketing », « IT » ou « Opérations ». Ces informations figurent généralement dans l’en-tête de la demande d’achat. La segmentation du processus par service est essentielle pour effectuer des comparaisons. Elle permet d’identifier les services dont 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 propres à chaque service. Pourquoi c’est important Il permet de filtrer et de comparer la performance du processus entre différentes unités opérationnelles, afin de révéler les tendances, les goulots d’étranglement ou les inefficacités propres à chaque service. Où les obtenir Ces informations sont souvent stockées dans l’en-tête de la demande d’achat, PurchReqTable, et relié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 « In Review », « Approved », « Rejected » ou « Closed ». Il s’agit souvent d’un attribut au niveau du cas, représentant le résultat final. L’analyse du statut final aide à comprendre les résultats globaux du processus. Par exemple, un nombre élevé de demandes « Rejected » ou « Withdrawn » peut signaler des problèmes lors de la phase de demande initiale ou un processus d’approbation trop complexe. Cet attribut est essentiel pour mesurer les taux de réussite et l’efficacité du processus. Pourquoi c’est important Il fournit un résultat clair pour chaque cas et permet d’analyser les taux d’approbation, de rejet et de retrait, qui constituent des indicateurs clés de performance. Où les obtenir Le champ de statut se trouve généralement dans la table d’en-tête des demandes d’achat, PurchReqTable, souvent sous le nom « Status » ou « PurchReqStatus ». Exemples ApprouvéeEn cours d’examenRejetéeBrouillon
	Utilisateur User	Identifiant ou nom de l’utilisateur ayant réalisé l’activité.
Description Cet attribut identifie le collaborateur ou l’utilisateur système responsable de l’exécution 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 aide à identifier les besoins de formation, les personnes ou équipes les plus performantes et la répartition de la charge de travail. Elle est également essentielle pour analyser la conformité, notamment la séparation des tâches, et comprendre comment les différents rôles interagissent avec le processus. Pourquoi c’est important Il permet d’analyser les comportements, la charge de travail et la performance propres à chaque utilisateur, ce qui est essentiel pour la gestion des ressources et l’identification des besoins de formation. Où les obtenir Cette information se trouve généralement dans les tables d’historique des flux de travail, par exemple WorkflowTrackingStatusTable, ou dans les tables de transactions, par exemple PurchReqTable, associées à une table d’utilisateurs, par exemple UserInfo. Exemples j.smitha.joness.patel
	Approuvée dès la première soumission IsFirstPass	Indicateur précisant si une demande d’achat a été approuvée sans modification ni rejet préalable.
Description Il s’agit d’un attribut booléen calculé, égal à « true » si le parcours d’approbation de la demande d’achat ne comprend aucune activité « Demande d’achat modifiée » ni « Étape d’approbation rejetée ». Dans le cas contraire, sa valeur est « false ». Cet attribut alimente directement le KPI « Taux d’approbation des demandes d’achat dès la première soumission ». Il simplifie l’analyse de l’efficacité du processus en fournissant un indicateur clair, au niveau du cas, des reprises nécessaires. Un faible taux d’approbation dès la première soumission met en évidence des problèmes de qualité des données initiales ou des exigences peu claires, et signale une possibilité d’amélioration du processus. Pourquoi c’est important Il mesure directement la qualité et l’efficacité du processus en identifiant les cas ayant nécessité une reprise, et alimente les KPI consacrés au taux de conformité dès la première soumission. Où les obtenir Il s’agit d’un attribut calculé. Sa détermination nécessite d’analyser la séquence complète des activités de chaque cas lors de la transformation des données, afin de vérifier l’absence d’activités de reprise avant l’approbation. Exemples truefalse
	Circuit du flux de travail d’approbation ApprovalWorkflowPath	Représentation de la séquence des étapes d’approbation suivies.
Description Cet attribut est un champ calculé qui concatène la séquence des étapes d’approbation d’une demande d’achat donnée, par exemple `Manager Approval -> Department Head Approval -> Finance Approval`. Il résume efficacement la variante du processus pour le sous-processus d’approbation. Cet attribut est essentiel pour le Dashboard « Suivi des écarts de conformité ». En comparant le circuit réel du flux de travail à un circuit standard ou attendu prédéfini, vous pouvez facilement signaler les flux non conformes ou inhabituels susceptibles de révéler des violations de politiques ou des risques opérationnels. Pourquoi c’est important Il simplifie l’analyse de la conformité en fournissant une représentation textuelle claire de la variante de processus, ce qui facilite l’identification des écarts par rapport aux procédures standard. Où les obtenir Cet attribut ne fait pas partie des champs standard. Il doit être dérivé en concaténant les valeurs de « ApprovalStep » dans l’ordre chronologique pour chaque cas lors de la transformation des données. Exemples Responsable -> DirecteurResponsable -> Directeur -> Vice-président FinanceResponsable -> Approbation automatique
	Devise Currency	Code devise du montant de la demande d’achat.
Description Cet attribut précise la devise, par exemple USD, EUR ou GBP, dans laquelle le montant total de la demande d’achat est exprimé. Il est essentiel pour l’analyse financière, notamment dans les organisations multinationales qui gèrent plusieurs devises. L’utilisation de l’attribut de devise permet de traiter et d’agréger correctement les données financières. Elle garantit une interprétation correcte des valeurs monétaires et permet de les convertir dans une devise commune afin d’obtenir des rapports fiables et de faciliter les comparaisons entre différentes régions ou unités opérationnelles. Pourquoi c’est important Il fournit le contexte nécessaire aux attributs financiers et garantit une interprétation ainsi qu’une agrégation correctes des valeurs monétaires dans les environnements multidevises. Où les obtenir Ce champ se trouve généralement dans la table d’en-tête des demandes d’achat, PurchReqTable, avec les champs de montant. Exemples USDEURGBP
	Groupe d’approbateurs ApproverGroup	Groupe d’utilisateurs ou rôle responsable d’une étape d’approbation.
Description Cet attribut identifie le groupe, le rôle ou la file d’attente chargé de traiter une tâche d’approbation donnée, par exemple « Approbateurs du service financier » ou « Responsables informatiques ». L’analyse des performances par groupe d’approbateurs est essentielle pour comprendre la répartition de la charge et déterminer quels groupes manquent éventuellement de ressources ou nécessitent une formation complémentaire. Elle alimente directement le Dashboard « Analyse des goulots d’étranglement des étapes d’approbation », en permettant d’analyser les performances selon les équipes responsables des approbations. Pourquoi c’est important Il permet d’identifier les écarts de performance entre les équipes d’approbation et de mettre en évidence d’éventuelles contraintes de ressources ou des besoins de formation au sein de certains groupes. Où les obtenir Cette information fait partie de l’historique du flux de travail, par exemple WorkflowTrackingStatusTable, qui enregistre l’utilisateur ou le groupe d’utilisateurs attribué à chaque tâche. Exemples Approbateurs financiersResponsables informatiquesDirection générale
	Nombre de modifications AmendmentCount	Nombre total de modifications apportées à une demande d’achat.
Description Il s’agit d’un attribut numérique calculé qui 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 des modifications des demandes d’achat » et le KPI « Taux de modification des demandes d’achat ». Il quantifie le volume de reprises par cas et facilite l’identification des demandes d’achat, services ou utilisateurs associés à de nombreux changements et à une faible efficacité. Vous pouvez ainsi cibler les efforts visant à améliorer la qualité des demandes initiales. Pourquoi c’est important Il quantifie les reprises au sein d’un cas et facilite la mesure ainsi que l’analyse de la fréquence des modifications et de leur impact sur l’efficacité du processus. Où les obtenir Il s’agit d’un attribut calculé. Il est obtenu 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 du bon de commande PurchaseOrderNumber	Identifiant du bon de commande créé à partir de la demande d’achat.
Description Cet attribut contient l’identifiant unique du bon de commande généré à partir d’une demande d’achat approuvée. Il établit le lien entre le processus de demande d’achat et le processus d’approvisionnement en aval. Le suivi de ce numéro est essentiel pour analyser le « délai de conversion d’une demande d’achat en bon de commande ». Il confirme qu’une demande d’achat est bien passée à l’étape suivante du cycle Purchase-to-Pay et permet une analyse de bout en bout couvrant à la fois les demandes d’achat et les bons de commande. Pourquoi c’est important Il relie la demande d’achat au bon de commande créé ensuite, ce qui permet d’analyser la conversion d’une demande d’achat en bon de commande et de relier les différentes étapes du processus P2P. Où les obtenir Ces informations se trouvent généralement dans la table des lignes de demande d’achat, PurchReqLine, après la création d’un bon de commande, avec un lien vers PurchTable. Exemples PO-000987PO-000988PO-000989

Obligatoire Recommandé Facultatif

Purchase to Pay - Requisition : activités

Voici les étapes et les jalons essentiels du processus à enregistrer dans votre journal d’événements pour détecter et analyser correctement votre flux de travail de demande d’achat.

7 Recommandé 5 Facultatif

	Activité	Description
	Commande d’achat créée	Une ligne approuvée de demande d’achat est convertie en ligne de commande d’achat, ce qui marque le transfert vers l’équipe chargée des achats. L’événement est identifié en reliant la ligne de demande à une ligne de commande d’achat.
Pourquoi c’est important Il s’agit d’une étape essentielle qui relie la demande d’achat au processus d’achat en aval. Elle est indispensable pour mesurer le KPI « Requisition to PO Conversion Time ». Où les obtenir 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 d’achat. Collecte Reliez PurchReqLine à PurchLine à l’aide du champ de référence de liaison, par exemple PurchReqLineRefId. Type d’événement inferred
	Demande d’achat approuvée	La demande d’achat a franchi avec succès toutes les étapes d’approbation requises du flux de travail. Cette activité est enregistrée lorsque l’instance de flux de travail se termine avec un statut final approuvé.
Pourquoi c’est important Il s’agit d’une étape majeure, qui marque la fin du cycle d’approbation et le début de la phase d’achat. Elle constitue l’événement de fin du KPI « Requisition Approval Cycle Time ». Où les obtenir Cette information est enregistrée explicitement dans `WorkflowTrackingStatusTable` lorsque le flux de travail se termine. Le champ `Status` de `PurchReqTable` est alors également mis à jour avec la valeur `Approved`. Collecte Filtrez les événements de `Completion` du flux de travail associés au statut `Approved`, ou suivez le changement de statut dans PurchReqTable. Type d’événement explicit
	Demande d’achat clôturée	La demande d’achat complète est considérée comme terminée, car toutes ses lignes ont été traitées dans des commandes d’achat ou annulées. Il s’agit d’un état final positif.
Pourquoi c’est important Cette activité marque la fin réussie du cycle de vie de la demande d’achat. Elle constitue le point final pour mesurer la durée totale du processus de bout en bout. Où les obtenir Ce statut est généralement calculé ou déduit. Il est atteint lorsque tous les enregistrements « PurchReqLine » associés ont un statut final, par exemple « Closed » ou « Cancelled ». Collecte Déduisez cet événement en vérifiant que tous les enregistrements enfants PurchReqLine d’un PurchReqTable possèdent un statut final. Type d’événement calculated
	Demande d’achat créée	Cet événement marque la création initiale de l’enregistrement de la demande d’achat à l’état brouillon. Il est identifié à partir de l’horodatage de création de l’en-tête de la demande d’achat.
Pourquoi c’est important En tant que point de départ du processus, cette activité est essentielle pour mesurer la durée globale du cycle de vie des demandes d’achat et analyser les volumes quotidiens traités. Où les obtenir Cette activité est déduite du champ « createdDateTime » de « PurchReqTable » pour chaque nouveau Purchase Requisition ID. Collecte Utilisez l’horodatage de création de l’enregistrement dans PurchReqTable. Type d’événement inferred
	Demande d’achat rejetée	La demande d’achat a été rejetée au cours du flux de travail d’approbation et ne sera pas traitée davantage. Il s’agit d’un état d’échec final pour la demande d’achat.
Pourquoi c’est important Cet événement de fin est essentiel pour analyser le taux global de rejet et comprendre l’impact financier ou opérationnel des demandes échouées. Où les obtenir Cette information est enregistrée explicitement dans `WorkflowTrackingStatusTable` à la fin du flux de travail avec le statut `Rejected`, ce qui met à jour le champ de statut de `PurchReqTable`. Collecte Filtrez les événements de `Completion` du flux de travail associés au statut `Rejected`, ou suivez le changement de statut dans PurchReqTable. Type d’événement explicit
	Demande d’achat soumise pour approbation	L’utilisateur soumet la demande d’achat finalisée, ce qui déclenche le flux de travail d’approbation officiel. Il s’agit d’une action explicite enregistrée par le moteur de flux de travail du système.
Pourquoi c’est important Cette activité constitue une étape importante qui lance le cycle d’approbation. Elle sert de point de départ pour mesurer le « Requisition Approval Cycle Time » et le « First-Pass Approval Rate ». Où les obtenir Cette information provient de la table `WorkflowTrackingStatusTable` ou d’une table similaire d’historique des flux de travail, dans laquelle un événement `Submission` est enregistré pour la demande d’achat. Collecte Filtrez les journaux d’historique du flux de travail sur le type d’événement `Submission` ou `Start` associé à la demande d’achat. 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 d’achat pour son étape du processus. La demande passe alors à l’étape suivante ou à l’approbation finale.
Pourquoi c’est important Mesure le temps de traitement de chaque étape d’approbation et aide à repérer les parties efficaces du flux de travail. Il s’agit d’un élément clé de l’analyse des variantes. Où les obtenir L’événement est enregistré explicitement dans « WorkflowTrackingStatusTable » lorsqu’un utilisateur termine un élément de travail avec le résultat « Approve ». Collecte Identifiez les événements `WorkItemCompleted` associés à un résultat `Approve` dans les journaux d’historique du flux de travail. Type d’événement explicit
	Demande d’achat modifiée	Cet événement survient lorsqu’un utilisateur rappelle une demande d’achat soumise depuis le flux de travail afin d’y apporter des modifications. L’activité est généralement identifiée par une action de rappel suivie d’une nouvelle soumission.
Pourquoi c’est important Le suivi des modifications est essentiel pour identifier les reprises, les demandes initiales imprécises et les inefficacités du processus. Il alimente directement le Dashboard « Requisition Amendment Frequency ». Où les obtenir L’événement peut être déduit de l’historique du flux de travail (`WorkflowTrackingStatusTable`) en détectant une action `Recall` ou `RequestChange`. Il peut également être déduit des modifications apportées au champ `modifiedDateTime` de `PurchReqTable` après la soumission. Collecte Détectez les événements de rappel du flux de travail ou les changements de version de l’enregistrement entre deux événements de soumission. Type d’événement inferred
	Demande d’achat retirée	Le créateur ou un utilisateur autorisé annule la demande d’achat après sa soumission. Cette action met fin au flux de travail et à la demande.
Pourquoi c’est important Le suivi des retraits aide à identifier les problèmes de planification de la demande ou les processus trop complexes. Il alimente le Dashboard « Requisition Withdrawal Insights ». Où les obtenir L’événement est déduit d’un changement de statut de « PurchReqTable » vers « Cancelled » ou d’un événement « Cancel » dans « WorkflowTrackingStatusTable ». Collecte Détectez le changement de statut vers `Cancelled` dans PurchReqTable ou un événement d’annulation du flux de travail. Type d’événement inferred
	Étape d’approbation démarrée	Une tâche d’approbation individuelle est attribuée à un utilisateur ou à un groupe dans le cadre du flux de travail. Elle marque le début d’un temps d’attente ou de traitement pour un approbateur donné.
Pourquoi c’est important Cette activité est essentielle à l’« Approval Step Bottleneck Analysis », qui permet de mesurer les temps d’attente à chaque étape d’approbation. Où les obtenir Cette information provient de `WorkflowTrackingStatusTable` lorsqu’un nouvel élément de travail est créé et attribué pour l’instance de flux de travail de la demande d’achat. Collecte Identifiez les événements `WorkItemCreated` ou similaires dans les journaux d’historique du flux de travail pour la demande d’achat concernée. Type d’événement explicit
	Étape d’approbation rejetée	Un approbateur rejette la tâche qui lui a été attribuée, ce qui renvoie généralement la demande d’achat à son initiateur pour correction. Il s’agit d’une action explicite enregistrée par le moteur de flux de travail.
Pourquoi c’est important Cette activité est fondamentale pour calculer le « Requisition Rejection Rate » et identifier les étapes où les rejets sont les plus fréquents, afin de repérer les domaines à améliorer. Où les obtenir L’événement est enregistré explicitement dans « WorkflowTrackingStatusTable » lorsqu’un utilisateur termine un élément de travail avec le résultat « Reject ». Collecte Identifiez les événements `WorkItemCompleted` associés à un résultat `Reject` dans les journaux d’historique du flux de travail. Type d’événement explicit
	Ligne de demande d’achat clôturée	Une ligne individuelle de la demande d’achat est considérée comme entièrement traitée. Cela se produit généralement après sa conversion complète en commande d’achat.
Pourquoi c’est important Cette activité fournit un niveau de détail précis sur l’exécution des demandes d’achat et aide à déterminer si elles sont converties partiellement ou intégralement en commandes d’achat. Où les obtenir L’événement est déduit du champ de statut de la table individuelle « PurchReqLine ». Un statut indiquant que la ligne est commandée ou reçue signale sa clôture. Collecte Surveillez le champ de statut de la table PurchReqLine afin de détecter une valeur finale telle que « Invoiced » ou « Closed ». Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Microsoft Dynamics 365

Étapes

Accéder à l’espace de travail Gestion des données : Connectez-vous à Microsoft Dynamics 365 et ouvrez le menu Workspaces. Sélectionnez Data management pour accéder au centre dédié aux opérations d’importation et d’exportation des données.
Créer un nouveau projet d’exportation : Dans l’espace de travail 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.
Ajouter 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 et ajoutez-les une par une :
- Purchase requisition headers
- Purchase requisition lines
- Workflow tracking status table
- Workflow work items
- Purchase order lines V2
Définir 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.
Appliquer les filtres de données : Sélectionnez une entité, puis cliquez sur le bouton Filter. Dans l’onglet Range, indiquez la Legal entity (code société) afin de vous assurer que les données proviennent de la bonne unité opérationnelle. Il est également essentiel d’ajouter un filtre de date sur le champ Created date and time de l’entité Purchase requisition headers afin de limiter le volume de données. Nous vous recommandons de commencer par une période de 3 à 6 mois.
Exécuter le projet d’exportation : Une fois toutes les entités et tous les filtres configurés, cliquez sur Export dans le volet Action. Le système crée un package de traitement et commence l’exécution. Vous pouvez suivre sa progression dans la section Job history.
Télécharger le package de données : Une fois l’exportation terminée, ouvrez les détails de Job history et cliquez sur Download package. Un fichier ZIP contenant les fichiers de données distincts de chaque entité sera téléchargé.
Transformer 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 final. Vous devez utiliser un outil externe tel que Python, Power Query ou une plateforme ETL pour regrouper et restructurer les données. Cette opération comprend notamment :
- la jointure des fichiers d’en-tête et de lignes ;
- la jointure des données du Workflow avec les demandes d’achat à l’aide de CorrelationId et du RecId de l’en-tête de la demande d’achat ;
- la transformation des changements de statut et des événements du Workflow issus des tables du Workflow en lignes d’activité distinctes (Requisition Submitted, Approval Step Approved, etc.) ;
- la création d’une nouvelle ligne pour chaque activité avec les valeurs correctes de ActivityName, EventTime et PurchaseRequisitionId.
Calculer et mapper les attributs : Lors de la transformation, mappez les colonnes sources vers les attributs requis, tels que User et Department. Calculez les attributs dérivés, comme RequisitionTotalAmount, en additionnant les montants des lignes. Définissez une valeur statique pour SourceSystemId, par exemple D365_F&O, et utilisez l’heure d’exécution de votre script pour renseigner LastDataIngestionTimestamp.
Finaliser et formater le résultat : Vérifiez que le fichier final est un fichier CSV unique 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é autorisant l’accès à l’espace de travail Data management ainsi qu’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 global ;
- Purchase requisition lines : contient les informations relatives à chaque article demandé, notamment les montants et les liens vers les bons de commande ;
- Workflow tracking status table : constitue la source principale des événements du Workflow, tels que la soumission, l’approbation, le rejet et le rappel ;
- Workflow work items : détaille les tâches spécifiques attribuées aux utilisateurs pendant le processus d’approbation ;
- Purchase order lines V2 : permet de trouver l’horodatage de création du bon de commande associé à une ligne de demande d’achat.
Filtrage de la période : Il est essentiel d’appliquer un filtre de période au champ Created date and time de l’entité Purchase requisition headers. Pour une première analyse, nous recommandons une période de 3 à 6 mois 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 la Legal entity afin d’éviter d’extraire des données provenant de sociétés non concernées ou de sociétés de test. Cette précaution 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 transformer les exports bruts des entités en journal d’événements structuré. Prévoyez l’utilisation d’un outil de script ou d’une plateforme ETL.

a 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

Enregistrer une application Azure Active Directory : accédez au portail Azure et enregistrez une nouvelle application. Cette application servira à vous authentifier auprès de l’API Dynamics 365. Notez l’ID d’application (client) et l’ID de répertoire (locataire).
Générer un secret client : dans l’application nouvellement enregistrée dans Azure, créez un secret client sous « Certificates & secrets ». Copiez sa valeur dans un emplacement sécurisé, car elle ne sera plus visible par la suite.
Accorder 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 en lecture seule et plus restrictive. Accordez le consentement administrateur pour ces autorisations.
Installer les bibliothèques Python : vérifiez que Python est installé. Installez ensuite les bibliothèques nécessaires avec pip : pip install requests pandas.
Configurer le script Python : copiez le script Python fourni dans un fichier, par exemple extract_d365_requisitions.py. Renseignez les variables d’espace réservé au début du script : l’URL Dynamics 365, le Tenant ID, le Client ID, le Client Secret, la période souhaitée et l’identifiant de la société.
Comprendre les entités OData : le script interroge trois entités de données principales : PurchaseRequisitionHeaders pour les informations générales de la demande d’achat, PurchaseRequisitionLines pour le détail des lignes, notamment la conversion en bons de commande, et WorkflowTrackingStatusTable pour tous les événements liés au flux de travail, comme les soumissions et les approbations.
Exécuter le script : lancez le script depuis votre 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.
Transformer les données : le script traite les données JSON brutes issues des appels d’API. Il restructure les données en parcourant les enregistrements et en créant une ligne distincte pour chacune des 12 activités métier, tout en associant les champs sources aux colonnes standard du journal d’événements, comme PurchaseRequisitionId, ActivityName et EventTime.
Regrouper et standardiser les événements : tous les événements générés sont réunis dans une seule liste, puis convertis en DataFrame pandas. Le script ajoute des colonnes statiques comme SourceSystemId et LastDataIngestionTimestamp.
Exporter au format CSV : le DataFrame final est exporté dans un fichier nommé d365_purchase_requisition_log.csv. Ce fichier est formaté pour être importé directement dans un outil de Process Mining. Vérifiez que le fichier est encodé en UTF-8.

Configuration

Prérequis : Vous devez disposer d’un abonnement Azure pour enregistrer une application, ainsi que d’un ID d’application (client), d’un Client Secret et d’un Tenant ID provenant d’Azure Active Directory. L’utilisateur qui exécute le script doit disposer d’identifiants autorisant l’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 préciser la fenêtre d’extraction. Pour une première analyse, nous recommandons une période de 3 à 6 mois afin de trouver un équilibre entre le volume de données et la qualité de l’analyse.
Filtre par société : Le script est configuré pour filtrer une entité juridique donnée à 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 ajouter cross-company=true aux en-têtes de la requête.
Considérations relatives aux 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 afin de traiter les volumes importants sans surcharger l’API. Pour les chargements historiques très volumineux, envisagez d’exécuter le script par lots, avec des périodes plus courtes.

a 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 Get data, choisissez le connecteur Microsoft Dynamics 365 Finance et saisissez 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 Navigator, sélectionnez les entités d’en-tête et de ligne des demandes d’achat, les entités d’historique ou de suivi des flux de travail, les entités utilisateur et organisationnelles, ainsi que les entités de commande d’achat requises par votre implémentation. Les noms des entités et les champs disponibles varient selon l’environnement. Utilisez les métadonnées des entités et remplacez chaque espace réservé 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 sélectionnée. Incluez les enregistrements créés avant la date de début lorsqu’ils comportent des événements de flux de travail ou de clôture dans la période, afin de conserver un historique complet des cas.
Standardisez les identifiants et les horodatages. Convertissez l’identifiant de la demande d’achat en texte, convertissez tous les horodatages des événements dans un fuseau horaire UTC ou métier cohérent et préservez la précision des horodatages sources. Vérifiez que l’identifiant d’en-tête de la demande d’achat est disponible sur chaque ligne d’événement. Lorsque les enregistrements de flux de travail contiennent uniquement un identifiant de corrélation du flux de travail, reliez-les à l’en-tête de la demande d’achat au moyen de la relation documentée configurée dans votre environnement.
Créez une requête d’événements pour chaque activité requise. Les requêtes d’événements doivent renvoyer explicitement des lignes pour 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 demandez pas à ProcessMind de 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 issue de l’historique des flux de travail. Une action de rappel suivie d’une soumission ultérieure doit produire un événement de modification à l’horodatage du rappel, ou à l’horodatage de modification exposé par l’entité source. Ne créez pas de ligne de modification uniquement à partir d’un changement de statut de la demande, sauf si le système source enregistre 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 d’achat au moyen de la relation source documentée. Si le journal d’événements est fondé sur PurchaseRequisitionId, agrégez les événements au niveau des lignes ou conservez-les comme des lignes distinctes portant le même identifiant de cas. Préservez les identifiants de ligne dans des colonnes supplémentaires lorsqu’ils sont disponibles, 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. Renseignez les valeurs indisponibles par null plutôt que par des valeurs inventées et utilisez une valeur source cohérente, telle que Dynamics 365 Finance, pour SourceSystemId.
Regroupez toutes les requêtes d’activité avec UNION ALL, supprimez les lignes dont l’identifiant de cas ou l’horodatage de l’événement est manquant, puis triez par PurchaseRequisitionId et EventTime. Conservez les événements en double lorsqu’ils représentent des tâches de flux de travail distinctes ou des lignes de demande distinctes. Supprimez les doublons uniquement lorsque les enregistrements sources sont manifestement des extractions en double.
Validez le journal d’événements obtenu à l’aide des contrôles décrits ci-dessous. Vérifiez que chaque activité requise est représentée par des 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 et préservez tous les attributs recommandés lorsqu’ils sont 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. Les noms et les champs des entités doivent être confirmés à partir des métadonnées de Navigator pour l’implémentation concernée.
Entités requises : sélectionnez les entités d’en-tête et de ligne des demandes d’achat, les entités de suivi ou d’historique des flux de travail, les entités d’en-tête et de ligne des commandes d’achat, ainsi que les entités utilisateur ou organisationnelles nécessaires à l’enrichissement. Utilisez des espaces réservés tels que [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 correspondant aux cas comportant 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 de société et de document : filtrez selon [Your company or legal entity filter] et [Your document type filter] lorsque cela s’applique. Vérifiez si l’identifiant de la demande 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’affectation de tâche, d’approbation, de rejet, de retrait, d’achèvement et d’annulation. Configurez les associations entre les actions et les statuts des flux de travail à partir des valeurs utilisées dans l’environnement.
Sémantique des événements : chaque activité doit être émise 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 : standardisez tous les horodatages dans un même fuseau horaire. Documentez si les horodatages sources sont stockés en UTC ou dans l’heure locale de l’activité. Utilisez l’horodatage source offrant la précision disponible la plus élevée.
Actualisation incrémentielle : pour les extractions récurrentes, utilisez un watermark fondé sur le plus grand horodatage source de modification ou d’événement, avec une fenêtre de chevauchement pour capturer les enregistrements de flux de travail arrivés tardivement. Réconciliez le chevauchement 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 des enregistrements historiques de flux de travail inutiles 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 de flux de travail Microsoft Dynamics 365 Finance sélectionnées. 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é organisationnelles autorisent l’extraction.
Devise et montants : confirmez la devise représentée par RequisitionTotalAmount. Si les demandes peuvent contenir plusieurs devises, ajoutez la devise source comme attribut supplémentaire et ne convertissez pas les montants sans le signaler.
Gestion des valeurs nulles : les attributs recommandés peuvent être null lorsque la source ne stocke aucune valeur, lorsque la valeur est limitée par la sécurité ou lorsque la relation ne peut pas être résolue. Les valeurs requises du cas, de l’activité et de l’horodatage de l’événement doivent être validées avant l’export.

a 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 ?

Avec ce modèle, vous disposez de tout le nécessaire pour commencer à optimiser votre processus Purchase to Pay - Demande d’achat. Commencez dès aujourd’hui à faire apparaître des analyses utiles.

Retour au guide d’amélioration Télécharger le modèle

Optimisez dès maintenant le processus Purchase to Pay, demandes d’achat, pour accélérer les approbations

Supprimez les délais et réduisez de 30 % les temps de cycle dans Dynamics 365.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

Votre modèle de données Purchase to Pay - Demande d’achat

Votre modèle de données Purchase to Pay - Demande d’achat

Purchase to Pay - Requisition : attributs

Purchase to Pay - Requisition : activités

Guides d’extraction

Export via le Framework de gestion des données de Dynamics 365

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l’API REST OData de Dynamics 365

Étapes

Configuration

a Exemple de requête python

Extraction avec le connecteur natif Microsoft Power BI

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Optimisez dès maintenant le processus Purchase to Pay, demandes d’achat, pour accélérer les approbations

Votre modèle de données Purchase to Pay - Demande d’achat

Votre modèle de données Purchase to Pay - Demande d’achat

Purchase to Pay - Requisition : attributs

Purchase to Pay - Requisition : activités

Guides d’extraction

Export via le Framework de gestion des données de Dynamics 365

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l’API REST OData de Dynamics 365

Étapes

Configuration

a Exemple de requête python

Extraction avec le connecteur natif Microsoft Power BI

Étapes

Configuration

a Exemple de requête sql

Prêt à commencer ?

Optimisez dès maintenant le processus Purchase to Pay, demandes d’achat, pour accélérer les approbations

Nous attachons de l’importance à votre confidentialité

Purchase to Pay - Requisition : attributs

Purchase to Pay - Requisition : activités