> Amélioration Continue des Processusus > Achats au paiement : demande d'achat > Microsoft Dynamics 365 > Template de données

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Microsoft Dynamics 365

← Retour au Guide d'amélioration

Achats au paiement : attributs de demande d'achat (17) Achats au paiement – Activités de demande d'achat (12) Guides d'extraction (3)

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Ce template décrit les attributs clés à collecter et les activités essentielles à suivre, permettant d'explorer en détail de votre processus de demande d'achat. Il fournit également des conseils pratiques sur l'extraction de ces données, vous aidant à préparer efficacement votre journal d'événements (journal d'événements) pour 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 ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Achats au paiement : attributs de demande d'achat

Ce sont les champs de données recommandés à inclure dans votre journal d'événements (journal d'événements) pour une analyse complète de votre processus Achats au paiement (P2P) - Requisition.

5 Obligatoire 6 Recommandé 6 Facultatif

	Nom	Descriptionn
	Heure de l'événement EventTime	L'horodatage précis du moment où une activité ou un événement spécifique s'est produit.
Descriptionn L'heure de l'événement, ou l'horodatage, enregistre la date et l'heure auxquelles un événement métier a été enregistré dans le système. C'est le socle temporel pour toute analyse de processus basée sur le temps. Cet attribut est indispensable pour le calcul des temps de cycle, des durées et des temps d'attente entre les activités. Il permet l'analyse des performances du processus, l'identification des points de blocage et le suivi de la conformité aux SLA. Des horodatages précis sont essentiels pour une analyse de processus mining fiable. Pourquoi est-ce important ? : Elle fournit l'ordre chronologique des événements, ce qui est nécessaire pour calculer les durées de processus, identifier les points de blocage et analyser les performances au fil du temps. Source des données : Trouvé dans l'historique de workflow ou les tables de journaux de documents, souvent comme 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
	ID de la demande d'achat PurchaseRequisitionId	L'identifiant unique d'une demande d'achat, servant d'identifiant principal du cas.
Descriptionn L'ID de demande d'achat (Purchase Requisition ID) est la clé centrale qui relie toutes les activités liées à une seule demande de biens ou de services. Chaque processus de demande, de la création à l'approbation finale et à la clôture, est suivi sous cet ID unique. En Process Mining, cet attribut est indispensable pour reconstituer le parcours complet de chaque demande. Il permet l'analyse des variantes de processus, des temps de cycle et de la conformité pour les cas individuels, offrant une vision globale du cycle de vie de la demande. Pourquoi est-ce important ? : Il est indispensable pour regrouper tous les événements liés en une seule instance de processus, pour une analyse complète, complet, du cycle de vie de chaque demande. Source des données : C'est généralement la clé primaire de la table d'en-tête principale des demandes d'achat, telle que PurchReqTable dans Microsoft Dynamics 365. Exemples PR-001254PR-001255PR-001256
	Nom de l'activité ActivityName	Le nom de l'événement ou de l'étape métier spécifique qui s'est produit dans le processus de demande d'achat.
Descriptionn Cet attribut enregistre le nom de chaque activité effectuée dans le cycle de vie de la demande d'achat. Par exemple : "Demande Créée", "Étape d'Approbation Approuvée" et "Bon de Commande Créé". Ces activités forment 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 l'essence du Process Mining. Elle aide à identifier les points de blocage, les boucles de reprise et les écarts par rapport au flux de processus standard, révélant les inefficacités opérationnelles. Pourquoi est-ce important ? : Cet attribut définit les étapes de la carte de processus, permettant de visualiser et d'analyser le flux de travail de demande d'achat. Source des données : Ceci est généralement dérivé des journaux de changement de statut, des tables d'historique de workflow ou des tables d'événements spécifiques dans Microsoft Dynamics 365, telles que WorkflowTrackingStatusTable. Exemples Demande d'achat soumise pour approbationÉtape d'approbation approuvéeDemande modifiée
	Dernière mise à jour des données LastDataIngestionTimestamp	L'horodatage (horodatage) de la dernière extraction et du dernier chargement des données dans l'outil de Process Mining.
Descriptionn Cet attribut indique la la réactualisation des données analysées. Il affiche la date et l'heure de la dernière actualisation des données du système source. Il ne s'agit pas d'un champ de Dynamics 365 lui-même, mais de métadonnées ajoutées lors de l'ingestion des données. Cet horodatage (horodatage) est indispensable pour que les utilisateurs comprennent la pertinence des analyses. Il les aide à savoir s'ils consultent des données en temps réel ou un instantané d'un moment précis, ce qui affecte la pertinence de leurs conclusions. Pourquoi est-ce important ? : Il informe les utilisateurs sur la la réactualisation des données, en s'assurant qu'ils comprennent le cadre temporel de l'analyse et la pertinence des résultats. Source des données : Cette valeur est générée et ajoutée à l'ensemble de données pendant le processus d'ingestion de données ou ETL. Exemples 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Système source SourceSystemId	Le système d'enregistrement à partir duquel les données ont été extraites.
Descriptionn Cet attribut identifie le système source d'où proviennent les données d'événement. Dans ce contexte, il s'agirait de "Microsoft Dynamics 365". Dans les environnements avec plusieurs systèmes intégrés, ce champ est impératif pour la traçabilité des données et le contexte. Dans l'analyse, il aide à différencier les processus qui peuvent s'étendre sur plusieurs systèmes ou confirme que les données proviennent d'une source unique et faisant autorité. Ceci est important pour la validation des données et pour s'assurer que l'analyse est basée sur le bon ensemble de données. Pourquoi est-ce important ? : Il fournit un contexte sur l'origine des données, ce qui est impératif pour la gouvernance des données, la validation et dans les environnements où plusieurs systèmes sont intégrés. Source des données : Il s'agit d'une valeur statique, "Microsoft Dynamics 365", ajoutée pendant le processus d'extraction et de transformation des données. Exemples Microsoft Dynamics 365 F&OD365MSD365
	Département Department	Le service du demandeur ou le centre de coûts associé à la demande d'achat.
Descriptionn Cet attribut spécifie le service commercial ou le centre de coûts qui a initié la demande d'achat, comme "Marketing", "IT" ou "Opérations". Cette information fait généralement partie de l'en-tête de la demande. Segmenter le processus par service est impératif pour l'analyse comparative. Cela vous permet de voir quels services ont les temps de cycle les plus longs, les taux de rejet les plus élevés ou les amendements les plus fréquents. Ces informationsns (insights) aident à adapter les améliorations de processus aux besoins spécifiques des départements. Pourquoi est-ce important ? : Il permet de filtrer et de comparer les performances des processus entre différentes unités commerciales, révélant des modèles, des points de blocage ou des inefficacités spécifiques à chaque service. Source des données : Cette information est souvent stockée sur l'en-tête de la demande d'achat (PurchReqTable) et liée à la configuration des dimensions financières dans Dynamics 365. Exemples Service informatiqueFinanceOpérations
	Étape d'approbation ApprovalStep	Le nom ou l'étape d'une étape d'approbation spécifique dans le workflow.
Descriptionn Cet attribut identifie l'étape particulière du workflow d'approbation, telle que "Approbation du Responsable" ou "Approbation Financière". Il fournit des détails plus précisres que le nom général de l'activité. Cet attribut est indispensable pour l'"Analyse des points de blocage par étape d'approbation". En suivant le temps passé à chaque étape d'approbation distincte, il devient possible de localiser précisément les étapes qui causent des retards dans le processus global. Cela permet des interventions ciblées pour améliorer l'efficacité du workflow. Pourquoi est-ce important ? : Il permet une analyse granulaire du workflow d'approbation, rendant possible l'identification des étapes spécifiques qui créent des points de blocage. Source des données : Cette information est contenue dans les tables d'historique de workflow, telles que WorkflowTrackingStatusTable, qui détaillent chaque étape du workflow configuré. Exemples Approbation du responsableApprobation du chef de serviceExamen financier
	Montant total de la demande d'achat RequisitionTotalAmount	La valeur monétaire totale de la demande d'achat.
Descriptionn Cet attribut capture la valeur totale de toutes les lignes d'articles d'une demande d'achat. Le montant influence souvent la complexité du workflow d'approbation, les demandes de valeur plus élevée nécessitant plus d'étapes d'approbation. Dans l'analyse des processus, cet attribut est indispensable pour le filtrage et l'analyse basés sur la valeur. Il aide à répondre à des questions telles que : "Les demandes de grande valeur prennent-elles plus de temps à être approuvées ?" ou "Quelle est la valeur des demandes actuellement bloquées dans le processus ?". Cela fournit un contexte financier à la performance du processus. Pourquoi est-ce important ? : Il ajoute une dimension financière à l'analyse, permettant la priorisation des dossiers à forte valeur et la compréhension de l'impact de la valeur monétaire sur le comportement du processus. Source des données : Cette valeur se trouve généralement sur la table d'en-tête de la demande d'achat ou est calculée comme la somme des montants des lignes d'articles de la table de ligne de la demande d'achat (PurchReqLine). Exemples 1500.0025000.50500.75
	Niveau d'urgence UrgencyLevel	Une classification de l'urgence de la demande, telle que 'Élevée', 'Moyenne' ou 'Faible'.
Descriptionn Le niveau d'urgence, ou priorité, indique la rapidité avec laquelle les biens ou services demandés sont nécessaires. Cet attribut est souvent utilisé pour influencer le chemin d'approbation ou pour prioriser le travail des approbateurs. L'analyse de cet attribut permet de déterminer si le système de priorité est efficace. Par exemple, vous pouvez comparer les temps de cycle des demandes d'urgence "Élevée" à ceux des demandes d'urgence "Faible". S'il n'y a pas de différence significative, cela peut indiquer que le champ de priorité est ignoré ou mal utilisé, ce qui constitue une information clé pour le tableau de bord "Analyse de l'impact du niveau d'urgence". Pourquoi est-ce important ? : Il aide à évaluer si les paramètres de priorité accélèrent efficacement les demandes critiques et met en évidence une éventuelle utilisation abusive de la classification d'urgence. Source des données : Il peut s'agir d'un champ standard ou personnalisé sur la table PurchReqTable. Son existence et son nom peuvent varier en fonction de la configuration du système. Exemples ÉlevéMoyenFaible
	Statut de la demande RequisitionStatus	Le statut actuel ou final de la demande d'achat.
Descriptionn Cet attribut indique le statut global de la demande d'achat à un moment donné, tel que "En cours d'examen", "Approuvée", "Rejetée" ou "Clôturée". Il s'agit souvent d'un attribut au niveau du cas (case-level) 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 "Rejetées" ou "Retirées" peut indiquer des problèmes dans la phase de demande initiale ou un processus d'approbation lourd. Il est indispensable pour mesurer les taux de réussite et l'efficacité du processus. Pourquoi est-ce important ? : Il fournit un résultat clair pour chaque cas, permettant l'analyse des taux d'approbation, de rejet et de retrait, qui sont des indicateurs de performance clés. Source des données : Le champ de statut se trouve généralement sur la table d'en-tête de la demande d'achat, PurchReqTable, souvent nommé 'Status' ou 'PurchReqStatus'. Exemples ApprouvéEn révisionRejetéBrouillon
	Utilisateur User	L'identifiant ou le nom de l'utilisateur qui a effectué l'activité.
Descriptionn Cet attribut identifie l'employé ou l'utilisateur du système responsable de l'exécution d'une étape de processus spécifique, comme la soumission d'une demande d'achat ou l'approbation d'une requête. Il peut s'agir d'un ID utilisateur, d'un nom complet ou d'une adresse e-mail. L'analyse des activités par utilisateur aide à identifier les besoins en formation, les individus ou équipes performants, et la répartition de la charge de travail. Elle est également essentielle pour l'analyse de conformité, telle que la séparation des tâches, et pour comprendre comment les différents rôles d'utilisateur interagissent avec le processus. Pourquoi est-ce important ? : Il permet l'analyse du comportement, de la charge de travail et des performances spécifiques à l'utilisateur, ce qui est indispensable pour la gestion des ressources et l'identification des opportunités de formation. Source des données : Généralement disponible dans les tables d'historique de workflow (par exemple, WorkflowTrackingStatusTable) ou les tables de transactions (par exemple, PurchReqTable) liées à une table utilisateur (par exemple, UserInfo). Exemples j.smitha.joness.patel
	Chemin du workflow d'approbation ApprovalWorkflowPath	Une représentation de la séquence des étapes d'approbation effectuées.
Descriptionn Cet attribut est un champ dérivé qui concatène la séquence des étapes d'approbation pour une demande donnée, telles que "Approbation du Responsable -> Approbation du Chef de Département -> Approbation Financière". Il résume efficacement la variante du processus pour le sous-processus d'approbation. Ceci est impératif pour le tableau de bord "Moniteur d'Écarts de Conformité". En comparant le chemin réel du workflow avec un chemin standard ou attendu prédéfini, il devient facile de signaler les flux de processus non conformes ou inhabituels qui peuvent représenter des violations de politique ou des risques opérationnels. Pourquoi est-ce important ? : Il simplifie l'analyse de la conformité en fournissant une représentation textuelle claire de la variante de processus, facilitant la détection des écarts par rapport aux procédures standard. Source des données : Cet attribut n'est pas un champ standard. Il doit être obtenu en concaténant les valeurs d'« ApprovalStep » dans l'ordre chronologique pour chaque cas lors de la transformation des données. Exemples Manager -> DirecteurManager -> Directeur -> VP FinancesManager -> Auto-approuvé
	Devise Currency	Le code de devise pour le montant de la demande d'achat.
Descriptionn Cet attribut spécifie la devise, par exemple, USD, EUR, GBP, dans laquelle le montant total de la demande est libellé. Il est impératif pour l'analyse financière, en particulier dans les organisations multinationales traitant plusieurs devises. L'utilisation de l'attribut de devise permet un traitement et une agrégation appropriés des données financières. Il garantit que les valeurs monétaires sont interprétées correctement et permet des conversions vers une devise commune pour des rapports et des comparaisons précis entre les différentes régions ou unités commerciales. Pourquoi est-ce important ? : Il fournit le contexte nécessaire aux attributs financiers, garantissant une interprétation et une agrégation précises des valeurs monétaires dans les environnements multidevises. Source des données : Ce champ se trouve généralement sur la table d'en-tête de la demande d'achat, PurchReqTable, à côté des champs de montant. Exemples USDEURGBP
	Est approuvé au premier passage IsFirstPass	Un indicateur signalant si une demande a été approuvée sans modifications ou rejets préalables.
Descriptionn Il s'agit d'un attribut booléen calculé qui est "vrai" si le chemin d'approbation d'une demande d'achat n'a pas inclus d'activités "Demande d'achat amendée" ou "Étape d'approbation rejetée". Sinon, il est "faux". Cet attribut prend directement en charge le KPI (KPI) "Taux d'approbation en première passe des demandes d'achat". Il simplifie l'analyse de l'efficacité du processus en fournissant un indicateur clair, au niveau du cas, du reprises. Un faible taux d'approbations en première passe met en évidence des problèmes de qualité des données initiales ou d'exigences peu claires, signalant une opportunité d'amélioration du processus. Pourquoi est-ce important ? : Il mesure directement la qualité et l'efficacité du processus en identifiant les cas qui ont nécessité un reprises, soutenant les KPI axés sur les taux de réussite du premier coup. Source des données : Ceci est un attribut calculé. Il nécessite l'analyse de la séquence complète des activités pour chaque cas lors de la transformation des données afin de vérifier l'absence d'activités de reprises avant l'approbation. Exemples truefaux
	Groupe d'approbateurs ApproverGroup	Le groupe d'utilisateurs ou le rôle responsable d'une étape d'approbation.
Descriptionn Cet attribut identifie le groupe, le rôle ou la file d'attente assigné pour gérer une tâche d'approbation spécifique, par exemple, "Approbateurs Financiers" ou "Responsables Informatiques". L'analyse de la performance du processus par groupe d'approbateurs est indispensablele pour comprendre la répartition de la charge de travail et identifier les groupes qui pourraient être sous-dotés ou nécessiter une formation supplémentaire. Elle contribue directement au le tableau de bord "Analyse des points de blocage par étape d'approbation" en permettant de segmenter la performance par les équipes responsables des approbations. Pourquoi est-ce important ? : Il aide à identifier les différences de performance entre les équipes d'approbation, mettant en évidence les contraintes potentielles de ressources ou les besoins de formation dans groupes spécifiques. Source des données : Cette information fait partie de l'historique du workflow (par exemple, WorkflowTrackingStatusTable), qui enregistre l'utilisateur ou le groupe d'utilisateurs assigné pour chaque tâche. Exemples Approbateurs financiersResponsables informatiquesDirection générale
	Nombre de modifications AmendmentCount	Le nombre total de fois qu'une demande d'achat a été amendée.
Descriptionn Il s'agit d'un attribut numérique calculé qui compte les occurrences de l'activité "Demande d'achat amendée" pour chaque cas de demande d'achat. Cet attribut est indispensable pour le tableau de bord "Fréquence des amendements de demandes" et le KPI (KPI) "Ratio d'amendements de demandes". Il quantifie le volume de reprises par cas, facilitant l'identification des demandes, départements ou utilisateurs associés à des niveaux élevés de changements et d'inefficacité. Cela aide à cibler les efforts pour améliorer la qualité de la demande initiale. Pourquoi est-ce important ? : Il quantifie les reprises au sein d'un dossier, facilitant la mesure et l'analyse de la fréquence des modifications et de son impact sur l'efficacité du processus. Source des données : Ceci est un attribut calculé. Il est dérivé lors de la transformation des données en comptant les activités "Demande d'achat amendée" pour chaque identifiant unique de demande d'achat (PurchaseRequisitionId). Exemples 013
	Numéro de commande d'achat PurchaseOrderNumber	L'identifiant du bon de commande créé à partir de la demande d'achat.
Descriptionn Cet attribut stocke l'ID unique du bon de commande qui a été généré à partir d'une demande d'achat approuvée. Il sert de lien entre le processus de demande et le processus d'approvisionnement en aval. Le suivi de ce numéro est indispensable pour analyser le "temps de conversion de la demande d'achat en bon de commande". Il confirme qu'une demande a réussi à passer à l'étape suivante du cycle Purchase-to-Pay et permet une analyse de processus complet qui englobe à la fois les demandes et les bons de commande. Pourquoi est-ce important ? : Il connecte la demande au bon de commande ultérieur, permettant l'analyse de la conversion Demande-Bon de commande et liant les différentes étapes du processus P2P. Source des données : Cette information se trouve généralement sur la table de ligne de la demande d'achat (PurchReqLine) après la création d'un bon de commande, faisant le lien avec la table PurchTable. Exemples PO-000987PO-000988PO-000989

Obligatoire Recommandé Facultatif

Achats au paiement – Activités de demande d'achat

Ce sont les étapes de processus et les jalons essentiels à capturer dans votre journal d'événements (journal d'événements) pour une découverte et une analyse précises de votre workflow de demande d'achat.

7 Recommandé 5 Facultatif

	Activité	Descriptionn
	Commande d'achat créée	Une ligne de demande d'achat approuvée est convertie en une ligne de bon de commande, signalant le transfert à l'équipe d'approvisionnement. Ceci est capturé en liant la ligne de demande à une ligne de bon de commande.
Pourquoi est-ce important ? : Il s'agit d'un jalon critique reliant la demande d'achat au processus d'approvisionnement en aval. Il est indispensable pour mesurer le KPI (KPI) "Délai de conversion de la demande en bon de commande". Source des données : Inférez en trouvant un enregistrement dans la table `PurchLine` qui référence l'ID d'une `PurchReqLine` associé au dossier de demande. Capture Joindre `PurchReqLine` avec `PurchLine` sur le champ de référence de liaison (par exemple, `PurchReqLineRefId`). Type d'événement inferred
	Demande approuvée	La demande d'achat a franchi avec succès toutes les étapes d'approbation requises dans le workflow. Cette activité est capturée lorsque l'instance du workflow se termine avec un statut final approuvé.
Pourquoi est-ce important ? : Il s'agit d'un jalon majeur, marquant la fin du cycle d'approbation et le début de la phase d'approvisionnement. C'est l'événement de fin pour le KPI (KPI) "Temps de cycle d'approbation des demandes". Source des données : Capturé explicitement depuis le `WorkflowTrackingStatusTable` lorsque le workflow est terminé. Cela met également à jour le champ 'Statut' sur `PurchReqTable` à 'Approuvé'. Capture Filtrer les événements de 'Achèvement' de workflow avec un statut 'Approuvé' ou suivre le changement de statut sur `PurchReqTable`. Type d'événement explicit
	Demande clôturée	L'intégralité de la demande d'achat est considérée comme complète, ce qui signifie que toutes ses lignes ont été traitées en bons de commande ou annulées. Il s'agit d'un état final et réussi.
Pourquoi est-ce important ? : Cette activité marque l'achèvement réussi du cycle de vie de la demande d'achat. C'est le point final pour mesurer la durée totale du processus complet. Source des données : Ce statut est généralement calculé ou inféré. Il se produit lorsque tous les enregistrements 'PurchReqLine' associés ont atteint un statut terminal (par exemple, 'Clôturé', 'Annulé'). Capture Déduisez cet événement en vérifiant si tous les enregistrements enfants `PurchReqLine` pour un `PurchReqTable` ont 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 de brouillon. Il est capturé en identifiant l'horodatage (horodatage) de création de l'en-tête de la demande d'achat.
Pourquoi est-ce important ? : En tant que début du processus, cette activité est indispensablele pour mesurer le temps de cycle global de la demande et analyser les volumes de traitement quotidiens des demandes. Source des données : Cette activité est inférée du champ 'createdDateTime' sur la table 'PurchReqTable' pour chaque nouvel ID de demande d'achat (Purchase Requisition ID). Capture Utilisez l'horodatage (horodatage) de création de l'enregistrement dans la PurchReqTable. Type d'événement inferred
	Demande d'achat soumise pour approbation	L'utilisateur soumet la demande d'achat terminée, ce qui lance le workflow d'approbation formel. Il s'agit d'une action explicite enregistrée par le moteur de workflow du système.
Pourquoi est-ce important ? : Cette activité est une étape critique qui marque le début du cycle d'approbation. Elle constitue le point de départ pour mesurer le "temps de cycle d'approbation des demandes" et le "taux d'approbation en première passe". Source des données : Capturé depuis le `WorkflowTrackingStatusTable` ou un tableau d'historique de workflow similaire, où un événement 'Soumission' est enregistré pour la demande d'achat. Capture Filtrer les journaux d'historique de workflow pour le type d'événement 'Soumission' ou 'Démarrage' lié à la demande. Type d'événement explicit
	Demande rejetée	La demande d'achat a été rejetée pendant le workflow d'approbation et ne sera pas traitée davantage. Cela représente un état d'échec terminal pour la demande.
Pourquoi est-ce important ? : Cet événement de fin est indispensable pour analyser les taux de rejet globaux et comprendre l'impact financier ou opérationnel des requêtes échouées. Source des données : Capturé explicitement depuis le `WorkflowTrackingStatusTable` à la fin du workflow avec un statut 'Rejeté', ce qui met à jour le champ de statut de `PurchReqTable`. Capture Filtrer les événements de 'Achèvement' de workflow avec le statut 'Rejeté' ou suivre le changement de statut sur `PurchReqTable`. Type d'événement explicit
	Étape d'approbation approuvée	Un approbateur termine sa tâche assignée, approuvant la demande pour son étape du processus. Cela déplace la demande à l'étape suivante ou à l'approbation finale.
Pourquoi est-ce important ? : Mesure le temps de traitement pour chaque étape d'approbation et aide à cibler les parties efficaces du workflow. C'est un composant clé de l'analyse des variantes. Source des données : Comptabilisé explicitement dans le `WorkflowTrackingStatusTable` lorsqu'un utilisateur termine un élément de travail avec un résultat 'Approuver'. Capture Identifier les événements 'WorkItemCompleted' avec un résultat 'Approuver' dans les journaux d'historique du workflow. Type d'événement explicit
	Demande modifiée	Cet événement se produit lorsqu'un utilisateur rappelle une demande d'achat soumise du workflow pour y apporter des modifications. L'activité est généralement capturée en identifiant une action de rappel suivie d'une resoumission ultérieure.
Pourquoi est-ce important ? : Le suivi des amendements est indispensable pour identifier les reprises, les demandes initiales peu claires et les inefficacités de processus. Il contribue directement au le tableau de bord "Fréquence des amendements de demandes". Source des données : Peut être inféré de l'historique de workflow (`WorkflowTrackingStatusTable`) en détectant une action 'Rappel' ou 'Demande de modification'. Il peut également être inféré des modifications du champ `modifiedDateTime` sur `PurchReqTable` après soumission. Capture Détecter les événements de rappel de workflow ou les changements de version d'enregistrement entre les événements de soumission. Type d'événement inferred
	Demande retirée	Le créateur ou un utilisateur autorisé annule la demande d'achat après sa soumission. Cette action met fin au workflow et à la requête.
Pourquoi est-ce important ? : Le suivi des retraits aide à identifier les problèmes de planification de la demande ou les processus trop complexes. Il soutient le tableau de bord "Informations sur les retraits de demandes". Source des données : Ceci est inféré d'un changement de statut sur la 'PurchReqTable' à 'Annulé' ou d'un événement 'Annuler' dans la 'WorkflowTrackingStatusTable'. Capture Détecter le changement de statut en 'Annulé' sur `PurchReqTable` ou un événement d'annulation de workflow. 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 workflow. Cela représente le début d'un temps d'attente ou de traitement pour un approbateur spécifique.
Pourquoi est-ce important ? : Cette activité est indispensablele pour l'"Analyse des points de blocage par étape d'approbation", permettant de mesurer les temps d'attente pour des étapes d'approbation spécifiques. Source des données : Capturé depuis le `WorkflowTrackingStatusTable` lorsqu'un nouvel élément de travail est créé et assigné pour l'instance de workflow de la demande. Capture Identifier les événements 'WorkItemCreated' ou similaires dans les journaux d'historique du workflow pour la demande spécifique. Type d'événement explicit
	Étape d'approbation rejetée	Un approbateur rejette sa tâche assignée, renvoyant généralement la demande à l'initiateur pour correction. C'est une action explicite enregistrée par le moteur de workflow.
Pourquoi est-ce important ? : Cette activité est clée pour calculer le "taux de rejet des demandes" et identifier les étapes où les rejets se produisent le plus souvent, mettant en évidence les domaines d'amélioration du processus. Source des données : Comptabilisé explicitement dans le `WorkflowTrackingStatusTable` lorsqu'un utilisateur termine un élément de travail avec un résultat 'Rejeter'. Capture Identifier les événements 'WorkItemCompleted' avec un résultat 'Rejeter' dans les journaux d'historique du workflow. Type d'événement explicit
	Ligne de demande d'achat clôturée	Une ligne d'article individuelle sur la demande d'achat est considérée comme entièrement traitée. Cela se produit généralement après que la ligne a été complètement convertie en bon de commande.
Pourquoi est-ce important ? : Fournit des détails granulaires sur l'exécution des demandes, aidant à identifier si les demandes sont partiellement ou entièrement converties en bons de commande. Source des données : Inférez du champ de statut sur la table individuelle `PurchReqLine`. Un statut indiquant qu'il est commandé ou reçu signifierait la clôture. Capture Surveiller le champ de statut sur la table `PurchReqLine` pour une valeur finale comme 'Facturé' ou 'Clôturé'. Type d'événement inferred

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de Microsoft Dynamics 365

Étapes

Accéder à l'espace de travail Gestion des données : Connectez-vous à Microsoft Dynamics 365 et naviguez vers le menu Espaces de travail. Sélectionnez Gestion des données pour ouvrir le hub central des opérations d'importation et d'exportation de données.
Créer un nouveau projet d'exportation : Dans l'espace de travail Gestion des données, cliquez sur la tuile Exporter. Fournissez un Nom du groupe unique, une Descriptionn descriptive et définissez la Catégorie de projet sur Projet. Cela organise vos tâches d'extraction de données.
Ajouter des entités de données : Ajoutez les entités de données standard nécessaires à votre projet. Cliquez sur Ajouter une entité et recherchez chacune des entités suivantes, en les ajoutant une par une :
- En-têtes de demande d'achat
- Lignes de demande d'achat
- Tableau de statut de suivi de workflow
- Éléments de travail de workflow
- Lignes de bon de commande V2
Définir le format d'exportation : Pour chaque entité ajoutée, sélectionnez un Format de données cible tel que CSV ou Excel. Le format CSV est généralement recommandé pour les performances et la compatibilité avec les outils de transformation de données.
Appliquer les filtres de données : Sélectionnez une entité, puis cliquez sur le bouton Filtrer. Sur l'onglet Plage, spécifiez l'entité juridique (code d'entreprise) pour vous assurer que vous extrayez les données de l'unité commerciale correcte. Il est également essentiel d'ajouter un filtre de date sur le champ Date et heure de création de l'entité En-têtes de demande d'achat pour limiter le volume de données. Nous recommandons de commencer par une période de 3 à 6 mois.
Exécuter le travail d'exportation : Une fois toutes les entités et tous les filtres configurés, cliquez sur Exporter dans le volet d'actions. Le système créera un package de travail et commencera le traitement. Vous pouvez surveiller la progression du travail dans la section Historique des travaux.
Télécharger le package de données : Une fois le travail d'exportation terminé avec succès, naviguez vers les détails de l'Historique des travaux et cliquez sur Télécharger le package. Cela téléchargera un fichier ZIP contenant les fichiers de données séparés pour chaque entité.
Transformer les données brutes en journal d'événements : Les fichiers exportés représentent des tables système brutes, et non un journal d'événements final. Vous devez utiliser un outil externe comme Python, Power Query ou une plateforme ETL pour combiner et remodeler les données. Cela implique :
- La jointure des fichiers d'en-tête et de ligne.
- La jointure des données de workflow aux demandes d'achat à l'aide de l'CorrelationId et de l'RecId de l'en-tête de la demande d'achat.
- Le pivotement des changements de statut et des événements de workflow des tables de workflow en lignes d'activité distinctes (Demande soumise, Étape d'approbation approuvée, etc.).
- La création d'une nouvelle ligne pour chaque activité avec l'(ActivityName), l'(EventTime) et le PurchaseRequisitionId corrects.
Calculer et mapper les attributs : Pendant la transformation, mappez les colonnes sources aux attributs requis comme Utilisateur et Service. Calculez les attributs dérivés comme Montant total de la demande 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 LastDataIngestionHorodatage.
Finaliser et formater la sortie : Assurez-vous que le fichier de sortie final est un fichier CSV unique où chaque ligne représente un événement du processus. Les colonnes doivent correspondre à la structure de journal d'événements requise, y compris PurchaseRequisitionId, (ActivityName) et (EventTime).

Configuration

Autorisations requises : Les utilisateurs doivent disposer d'un rôle de sécurité avec des autorisations pour l'espace de travail Gestion des données et un accès aux entités de données spécifiques exportées, telles que Administrateur de la gestion des données ou un rôle personnalisé similaire.
Entités de données clés :
- En-têtes de demande d'achat : Fournit l'identifiant principal du dossier, l'horodatage de création et le statut global.
- Lignes de demande d'achat : Contient les détails de chaque article demandé, y compris les montants et les liens vers les bons de commande.
- Tableau de statut de suivi de workflow : La source principale pour les événements de workflow tels que la soumission, l'approbation, le rejet et le rappel.
- Éléments de travail de workflow : Détaille les tâches spécifiques assignées aux utilisateurs pendant le processus d'approbation.
- Lignes de bon de commande V2 : Utilisé pour trouver l'horodatage de création du bon de commande lié à une ligne de demande.
Filtrage par plage de dates : Il est impératif d'appliquer un filtre de plage de dates au champ Date et heure de création sur l'entité En-têtes de demande d'achat. Une plage de 3 à 6 mois est recommandée pour l'analyse initiale afin d'équilibrer le volume de données et les informations sur le processus.
Filtrage par code d'entreprise : Appliquez toujours un filtre pour l'entité juridique afin d'éviter d'extraire des données d'entreprises non visées ou de test. Cela réduit considérablement la taille des données et améliore les performances du travail.
Transformation des données : Cette méthode nécessite une étape de post-traitement significative en dehors de Dynamics 365 pour transformer les exportations d'entités brutes en un journal d'événements structuré. Préparez-vous à utiliser un outil de script ou ETL.

a Exemple de requête config

/*
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 : Naviguez vers le portail Azure et enregistrez une nouvelle application. Cette application sera utilisée pour s'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 nouveau secret client sous 'Certificats et secrets'. Copiez la valeur secrète en toute sécurité, car elle ne sera plus visible.
Accorder les autorisations API : Dans la section 'Autorisations API' de l'application, ajoutez une autorisation pour 'Dynamics ERP'. Sélectionnez 'Autorisations déléguées' et accordez Financials.ReadWrite.All ou un équivalent en lecture seule plus restrictif. Accordez le consentement administrateur pour les autorisations.
Installer les bibliothèques Python : Assurez-vous que Python est installé. Ensuite, installez les bibliothèques nécessaires à l'aide de 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é en haut du script : votre URL Dynamics 365, ID de locataire, ID client, secret client, la plage de dates souhaitée et l'ID d'entreprise.
Comprendre les entités OData : Le script interroge trois entités de données principales : PurchaseRequisitionHeaders pour les détails principaux de la demande, PurchaseRequisitionLines pour les spécificités des articles, y compris la conversion en bons de commande, et WorkflowTrackingStatusTable pour tous les événements liés au workflow comme les soumissions et les approbations.
Exécuter le script : Exécutez le script depuis votre ligne de commande : python extract_d365_requisitions.py. Le script s'authentifiera, récupérera les données pour chaque activité et gérera automatiquement la pagination de l'API.
Transformation des données : Le script traite les données JSON brutes des appels API. Il remodèle les données en itérant à travers les enregistrements et en créant une ligne distincte pour chacune des 12 activités commerciales, mappant les champs source aux colonnes standard du journal d'événements comme PurchaseRequisitionId, (ActivityName) et (EventTime).
Combiner et standardiser les événements : Tous les événements générés sont collectés dans une liste unique, puis convertis en un DataFrame pandas. Le script ajoute des colonnes statiques comme (SourceSystemId) et le LastDataIngestionHorodatage.
Exporter au format CSV : Le DataFrame final est exporté vers un fichier CSV nommé d365_purchase_requisition_log.csv. Ce fichier est formaté pour un téléchargement direct dans un outil de process mining. Vérifiez que le fichier est encodé en UTF-8.

Configuration

Prérequis : Accès à un abonnement Azure pour enregistrer une application. Un ID d'application (client), un secret client et un ID de locataire d'Azure Active Directory. L'utilisateur exécutant le script a besoin d'identifiants qui accordent l'accès aux points de terminaison de l'API OData de Dynamics 365 Finance and Operations.
Configuration du point de terminaison API : Le script nécessite l'URL de base de votre environnement Dynamics 365, généralement au format https://[votre-nom-d'environnement].operations.dynamics.com.
Plage de dates : Définissez les variables START_DATE et END_DATE dans le script pour définir la fenêtre d'extraction. Pour l'analyse initiale, une période de 3 à 6 mois est recommandée pour équilibrer le volume de données et les enseignements.
Filtre d'entreprise : Le script est configuré pour filtrer une entité juridique spécifique à l'aide de la variable COMPANY_ID. Pour extraire les données de toutes les entreprises, vous devrez peut-être modifier le filtre OData et inclure cross-company=true dans les en-têtes de requête.
Considérations relatives aux performances : Le script ne récupère que les colonnes nécessaires pour le journal d'événements en utilisant $select dans les requêtes OData, ce qui améliore les performances. Il gère également la pagination pour gérer de grands ensembles de données sans surcharger l'API. Pour les très grandes charges historiques, envisagez d'exécuter le script par lots avec des plages de dates plus petites.

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

Accéder à l'espace de travail Gestion des données : Connectez-vous à Microsoft Dynamics 365 et naviguez vers le menu Espaces de travail. Sélectionnez Gestion des données pour ouvrir le hub central des opérations d'importation et d'exportation de données.
Créer un nouveau projet d'exportation : Dans l'espace de travail Gestion des données, cliquez sur la tuile Exporter. Fournissez un Nom du groupe unique, une Descriptionn descriptive et définissez la Catégorie de projet sur Projet. Cela organise vos tâches d'extraction de données.
Ajouter des entités de données : Ajoutez les entités de données standard nécessaires à votre projet. Cliquez sur Ajouter une entité et recherchez chacune des entités suivantes, en les ajoutant une par une :
- En-têtes de demande d'achat
- Lignes de demande d'achat
- Tableau de statut de suivi de workflow
- Éléments de travail de workflow
- Lignes de bon de commande V2
Définir le format d'exportation : Pour chaque entité ajoutée, sélectionnez un Format de données cible tel que CSV ou Excel. Le format CSV est généralement recommandé pour les performances et la compatibilité avec les outils de transformation de données.
Appliquer les filtres de données : Sélectionnez une entité, puis cliquez sur le bouton Filtrer. Sur l'onglet Plage, spécifiez l'entité juridique (code d'entreprise) pour vous assurer que vous extrayez les données de l'unité commerciale correcte. Il est également essentiel d'ajouter un filtre de date sur le champ Date et heure de création de l'entité En-têtes de demande d'achat pour limiter le volume de données. Nous recommandons de commencer par une période de 3 à 6 mois.
Exécuter le travail d'exportation : Une fois toutes les entités et tous les filtres configurés, cliquez sur Exporter dans le volet d'actions. Le système créera un package de travail et commencera le traitement. Vous pouvez surveiller la progression du travail dans la section Historique des travaux.
Télécharger le package de données : Une fois le travail d'exportation terminé avec succès, naviguez vers les détails de l'Historique des travaux et cliquez sur Télécharger le package. Cela téléchargera un fichier ZIP contenant les fichiers de données séparés pour chaque entité.
Transformer les données brutes en journal d'événements : Les fichiers exportés représentent des tables système brutes, et non un journal d'événements final. Vous devez utiliser un outil externe comme Python, Power Query ou une plateforme ETL pour combiner et remodeler les données. Cela implique :
- La jointure des fichiers d'en-tête et de ligne.
- La jointure des données de workflow aux demandes d'achat à l'aide de l'CorrelationId et de l'RecId de l'en-tête de la demande d'achat.
- Le pivotement des changements de statut et des événements de workflow des tables de workflow en lignes d'activité distinctes (Demande soumise, Étape d'approbation approuvée, etc.).
- La création d'une nouvelle ligne pour chaque activité avec l'(ActivityName), l'(EventTime) et le PurchaseRequisitionId corrects.
Calculer et mapper les attributs : Pendant la transformation, mappez les colonnes sources aux attributs requis comme Utilisateur et Service. Calculez les attributs dérivés comme Montant total de la demande 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 LastDataIngestionHorodatage.
Finaliser et formater la sortie : Assurez-vous que le fichier de sortie final est un fichier CSV unique où chaque ligne représente un événement du processus. Les colonnes doivent correspondre à la structure de journal d'événements requise, y compris PurchaseRequisitionId, (ActivityName) et (EventTime).

Configuration

Autorisations requises : Les utilisateurs doivent disposer d'un rôle de sécurité avec des autorisations pour l'espace de travail Gestion des données et un accès aux entités de données spécifiques exportées, telles que Administrateur de la gestion des données ou un rôle personnalisé similaire.
Entités de données clés :
- En-têtes de demande d'achat : Fournit l'identifiant principal du dossier, l'horodatage de création et le statut global.
- Lignes de demande d'achat : Contient les détails de chaque article demandé, y compris les montants et les liens vers les bons de commande.
- Tableau de statut de suivi de workflow : La source principale pour les événements de workflow tels que la soumission, l'approbation, le rejet et le rappel.
- Éléments de travail de workflow : Détaille les tâches spécifiques assignées aux utilisateurs pendant le processus d'approbation.
- Lignes de bon de commande V2 : Utilisé pour trouver l'horodatage de création du bon de commande lié à une ligne de demande.
Filtrage par plage de dates : Il est impératif d'appliquer un filtre de plage de dates au champ Date et heure de création sur l'entité En-têtes de demande d'achat. Une plage de 3 à 6 mois est recommandée pour l'analyse initiale afin d'équilibrer le volume de données et les informations sur le processus.
Filtrage par code d'entreprise : Appliquez toujours un filtre pour l'entité juridique afin d'éviter d'extraire des données d'entreprises non visées ou de test. Cela réduit considérablement la taille des données et améliore les performances du travail.
Transformation des données : Cette méthode nécessite une étape de post-traitement significative en dehors de Dynamics 365 pour transformer les exportations d'entités brutes en un journal d'événements structuré. Préparez-vous à utiliser un outil de script ou ETL.

a Exemple de requête config

/*
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;

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Achats au paiement : attributs de demande d'achat

Achats au paiement – Activités de demande d'achat

Guides d'extraction

Exportation du Cadre de gestion des données de Dynamics 365

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API REST OData de Dynamics 365

Étapes

Configuration

a Exemple de requête python

Extraction via le connecteur natif Microsoft Power BI

Étapes

Configuration

a Exemple de requête config

Prêt(e) à démarrer ?

Optimisez Achats et Comptabilité fournisseurs - Demande d'achat pour des approbations plus rapides dès maintenant

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Votre Modèle de Données de Demandes d'Achat – Du Bon de De la commande au paiement

Achats au paiement : attributs de demande d'achat

Achats au paiement – Activités de demande d'achat

Guides d'extraction

Exportation du Cadre de gestion des données de Dynamics 365

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API REST OData de Dynamics 365

Étapes

Configuration

a Exemple de requête python

Extraction via le connecteur natif Microsoft Power BI

Étapes

Configuration

a Exemple de requête config

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Optimisez Achats et Comptabilité fournisseurs - Demande d'achat pour des approbations plus rapides dès maintenant