> Amélioration continue des processus > Achats au Paiement – Traitement des factures > `Microsoft Dynamics 365` > Modèle de données

Votre modèle de données Achats à la Payer - Traitement des Factures

Microsoft Dynamics 365

← Retour au Guide d'amélioration

Achats au Paiement – Attributs de traitement des factures (23) Achats au Paiement – Activités de traitement des factures (14) Guides d'extraction (4)

Votre modèle de données Achats à la Payer - Traitement des Factures

Ce modèle fournit un guide clair pour extraire les données essentielles nécessaires à l'analyse de votre processus Achats au Paiement – Traitement des factures dans Microsoft Dynamics 365. Il décrit les attributs cruciaux à collecter, les activités clés à suivre et des conseils pratiques pour l'extraction des données. Utilisez cette ressource pour vous assurer de recueillir toutes les informations nécessaires à une analyse et une optimisation complètes des processus.

Attributs recommandés à collecter pour une analyse approfondie
Activités clés à suivre tout au long du cycle de traitement des factures
Guide d'extraction de données de Microsoft Dynamics 365

Nouveau dans 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 traitement des factures

Ce sont les champs de données recommandés à inclure dans votre Event Log pour une analyse complète de votre processus Achats au Paiement – Traitement des factures.

5 Obligatoire 7 Recommandé 11 Facultatif

	Nom	Description
	Heure de l'événement EventTime	L'horodatage précis indiquant quand une activité ou un événement spécifique s'est produit.
Description L'Event Time, ou horodatage, enregistre la date et l'heure exactes d'une activité. C'est un composant essentiel de l'Event Log, fournissant la séquence temporelle nécessaire pour ordonner correctement les activités et calculer les durées. En analyse, cet horodatage est la base de toutes les métriques liées au temps. Il est utilisé pour calculer la durée des activités, le temps de cycle entre différentes étapes (par exemple, le temps d'approbation), et le temps total de traitement de bout en bout pour chaque facture. Il permet également l'analyse des tendances dans le temps. Pourquoi c'est important Cet horodatage est essentiel pour ordonner les événements, calculer tous les temps de cycle et les durées, et identifier les goulots d'étranglement du processus. Où obtenir Ceci est extrait de divers champs de date/heure à travers plusieurs tables, tels que les champs createdDateTime ou modifiedDateTime dans des tables comme VendInvoiceInfoTable, VendTrans, ou les tables d'historique de workflow. Exemples 2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
	Nom de l'activité ActivityName	Le nom de l'événement commercial ou de la tâche spécifique qui s'est produit à un moment donné du cycle de vie du traitement des factures.
Description Le nom de l'activité (Activity Name) décrit une étape spécifique ou un changement de statut dans le processus de facturation, tel que « Facture enregistrée », « Facture envoyée pour approbation » ou « Paiement exécuté ». Ces données sont cruciales pour construire la cartographie des processus et comprendre la séquence des événements. L'analyse de cet attribut révèle le flux de processus, identifie les parcours courants et met en évidence les déviations ou les goulots d'étranglement. Il est utilisé pour calculer les temps de cycle entre les activités, comme la durée de l'approbation à la comptabilisation, et pour mesurer la fréquence d'événements spécifiques comme les rejets ou les blocages de paiement. Pourquoi c'est important Il définit les étapes de la cartographie des processus, permettant la visualisation du flux de processus et l'analyse des transitions entre les différentes activités. Où obtenir Cet attribut est généralement dérivé d'une combinaison de champs de statut, de types de transactions ou d'entrées de journal de modifications au sein de diverses tables Dynamics 365 liées au traitement des factures. Exemples Facture envoyée pour approbationDivergence de rapprochement trouvéePaiement effectué
	Numéro de facture InvoiceNumber	L'identifiant unique de chaque facture fournisseur, servant d'ID de cas principal pour le suivi de son cycle de vie.
Description Le numéro de facture (Invoice Number) est la clé unique qui lie toutes les activités associées à une seule facture fournisseur. Il permet le traçage de bout en bout du parcours de la facture, de la réception et de l'enregistrement jusqu'au rapprochement, à l'approbation et au paiement final. Dans l'analyse Process Mining, cet attribut est fondamental. Il définit le 'case', permettant la reconstruction du flux de processus de chaque facture. Cela permet le calcul des temps de cycle totaux, l'identification des variantes de processus et l'analyse des caractéristiques et résultats spécifiques aux factures. Pourquoi c'est important C'est l'ID de cas (Case ID) essentiel qui connecte tous les événements liés, rendant possible l'analyse du cycle de vie complet de chaque facture individuelle. Où obtenir Ceci se trouve typiquement dans la table principale des factures fournisseurs, telle que VendInvoiceInfoTable, champ Num. Exemples INV-10056773245-AUS-001-98432
	Dernière mise à jour des données LastDataUpdate	L'horodatage indiquant la dernière fois que les données de ce processus ont été actualisées à partir du système source.
Description Cet attribut enregistre la date de la dernière extraction et mise à jour du dataset à partir de Microsoft Dynamics 365. Il est généralement le même pour tous les enregistrements au sein d'un même chargement de données. Cette information est vitale pour que les utilisateurs comprennent l'actualité des données qu'ils analysent. Elle fournit un contexte sur la pertinence des insights de processus et est essentielle pour gérer les calendriers d'actualisation des données et valider les pipelines de données. Pourquoi c'est important Informe les utilisateurs sur l'actualité des données, s'assurant qu'ils connaissent la date de l'analyse la plus récente et la date prévue de la prochaine mise à jour des données. Où obtenir Cet horodatage est généré et apposé sur le dataset par le processus d'extraction de données ou ETL au moment de l'exécution. Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Système source SourceSystem	Le système d'origine à partir duquel les données d'événement ont été extraites.
Description Cet attribut identifie l'application source d'où proviennent les données d'activité. Pour ce processus, il s'agira typiquement de « Microsoft Dynamics 365 ». Dans les environnements avec plusieurs systèmes, comme une solution OCR ou de capture externe, ce champ aide à différencier où chaque étape du processus se produit. Il assure la clarté de la lignée des données et aide au dépannage des problèmes d'extraction de données. Pourquoi c'est important Il fournit un contexte crucial sur l'origine des données, ce qui est important pour la validation des données et la compréhension du paysage système du processus. Où obtenir C'est une valeur statique, « Microsoft Dynamics 365 », ajoutée lors de la transformation des données pour étiqueter l'origine du dataset. Exemples `Microsoft Dynamics 365`
	Date d'échéance du paiement PaymentDueDate	La date à laquelle la facture devrait être payée selon les conditions de paiement convenues.
Description La date d'échéance du paiement (Payment Due Date) est calculée en fonction de la date de la facture et des conditions de paiement du fournisseur. Elle représente la date limite contractuelle pour le paiement. Cette date est essentielle pour mesurer la performance financière et la gestion des relations avec les fournisseurs. Elle sert de base pour calculer l'ICP (KPI) du « Taux de paiement à temps » en la comparant à la date réelle de « Paiement exécuté ». L'analyse de cette donnée aide à identifier les problèmes systémiques qui causent les retards de paiement, ce qui peut entraîner des relations fournisseurs endommagées ou des escomptes pour paiement anticipé manqués. Pourquoi c'est important C'est le repère pour mesurer la performance des paiements à temps, un ICP (KPI) clé pour la santé financière et les relations avec les fournisseurs. Où obtenir Cette date est souvent calculée par le système et stockée dans la table des transactions fournisseurs, comme VendTrans, en fonction de la date de la facture et des conditions de paiement. Exemples 2023-05-152023-06-302023-07-20
	Heure de fin EndTime	L'horodatage précis indiquant quand une activité ou un événement spécifique a été achevé.
Description L'heure de fin (End Time) enregistre la fin d'une activité. Combinée à l'heure de début (Start Time - EventTime), elle permet le calcul précis de la durée de chaque étape individuelle. Cet attribut est essentiel pour calculer le 'ProcessingTime' pour chaque activité, une métrique clé pour l'analyse des performances. Il aide à identifier précisément quelles étapes du processus consomment le plus de temps, permettant des efforts d'amélioration ciblés. Par exemple, il peut mesurer la durée exacte d'une étape de codage manuel ou d'approbation. Pourquoi c'est important Permet le calcul direct des temps de traitement des activités, ce qui est fondamental pour identifier les étapes les plus chronophages du processus. Où obtenir Comme l'heure de début (StartTime), cette donnée provient de divers champs de date/heure. Pour certaines activités, il peut s'agir de l'heure de début de l'activité suivante. Dans d'autres cas, il peut s'agir d'un horodatage spécifique de « complétion ». Exemples 2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
	Montant de la facture InvoiceAmount	La valeur monétaire totale de la facture.
Description Cet attribut représente le montant total dû tel qu'indiqué sur la facture fournisseur. C'est un point de donnée financier fondamental pour chaque cas. Le montant de la facture (Invoice Amount) est largement utilisé pour la segmentation et l'analyse. Il peut révéler si les factures de grande valeur suivent un processus d'approbation différent et plus strict ou si elles prennent plus de temps à être traitées. Il est également utilisé dans les Dashboards pour analyser les volumes de factures par valeur et peut être agrégé pour comprendre la dépense totale sous analyse. Pourquoi c'est important Permet une analyse basée sur la valeur financière, aidant à prioriser les efforts d'amélioration des processus sur les factures de grande valeur et à comprendre les facteurs de coût. Où obtenir Se trouve dans la table d'en-tête de facture, par exemple, VendInvoiceInfoTable, dans un champ comme InvoiceAmount ou Amount. Exemples 1500.00250.7512500.50
	Numéro de commande d'achat PurchaseOrderNumber	L'identifiant du bon de commande (PO) auquel la facture est liée.
Description Le numéro de bon de commande (Purchase Order Number) lie une facture au document d'approvisionnement original. C'est essentiel pour les processus qui impliquent un rapprochement à 2 ou 3 voies entre la facture, le PO et la réception des marchandises. Cet attribut permet l'analyse des factures avec et sans PO, qui suivent souvent des chemins de processus différents. Il est essentiel pour comprendre l'efficacité du processus de rapprochement, enquêter sur les divergences de rapprochement et mesurer le taux de traitement direct pour les factures adossées à un PO. Pourquoi c'est important Il distingue les factures adossées à un bon de commande (PO) des factures sans bon de commande, ce qui est un facteur principal de variation des processus et crucial pour l'analyse des rapprochements. Où obtenir Situé dans la table d'en-tête de facture, comme VendInvoiceInfoTable, souvent dans un champ tel que PurchId. Exemples PO-001234PO-005678PO-009101
	Numéro de fournisseur VendorNumber	L'identifiant unique du fournisseur ou du prestataire qui a soumis la facture.
Description Le numéro de fournisseur (Vendor Number) est le code qui identifie de manière unique un fournisseur dans les données de base. Il lie la transaction de facture à un fournisseur spécifique, permettant une analyse centrée sur le fournisseur. Cet attribut est essentiel pour segmenter les données de processus par fournisseur. Il aide à répondre à des questions telles que « Quels fournisseurs ont les délais d'approbation les plus longs ? » ou « Les divergences de rapprochement sont-elles plus fréquentes avec certains fournisseurs ? ». L'analyse des performances par fournisseur peut révéler des opportunités de collaboration avec les fournisseurs et d'amélioration des processus. Pourquoi c'est important Permet le filtrage et l'analyse des causes profondes par fournisseur, aidant à identifier les problèmes de performance ou les schémas liés à des fournisseurs spécifiques. Où obtenir Ceci se trouve typiquement dans l'en-tête de la table des factures fournisseurs, telle que VendInvoiceInfoTable, liée aux données de base des fournisseurs principales dans VendTable. Exemples V-1001V-2050V-8342
	Statut de la facture InvoiceStatus	Le statut actuel de la facture au moment de l'extraction des données.
Description Le statut de la facture (Invoice Status) indique l'état actuel d'une facture au cours de son cycle de vie, tel que « En attente d'approbation », « Approuvée », « Comptabilisée » ou « Payée ». Cela fournit un aperçu de la progression de la facture. Cet attribut est principalement utilisé pour créer des Dashboards opérationnels qui montrent la charge de travail actuelle et le backlog. Il aide les managers à comprendre combien de factures se trouvent à chaque étape du processus, soutenant l'allocation des ressources et le suivi opérationnel. Il est clé pour le Dashboard « Débit et statut du traitement des factures ». Pourquoi c'est important Fournit une vue de l'état actuel de toutes les factures, essentielle pour le suivi opérationnel, la gestion de la charge de travail et l'identification des goulots d'étranglement actuels. Où obtenir Ceci est typiquement dérivé des champs de statut sur la table principale des factures, comme VendInvoiceInfoTable. Exemples En attente d'approbationComptabiliséPayé
	Utilisateur User	L'identifiant ou le nom de l'utilisateur qui a effectué l'activité.
Description Cet attribut identifie l'employé ou l'utilisateur système responsable de l'exécution d'une étape spécifique du processus. Pour les étapes automatisées, il peut s'agir d'un compte système ou de service. L'analyse du processus par utilisateur aide à comprendre la répartition de la charge de travail, à identifier les besoins en formation et à comparer les performances entre individus ou équipes. Elle est cruciale pour analyser les boucles de retravail, où le travail est transmis d'un utilisateur à l'autre, et pour comprendre les variations dans la manière dont différents utilisateurs accomplissent la même tâche. Pourquoi c'est important Il permet d'analyser les performances et la charge de travail par utilisateur ou par équipe, et aide à identifier les niveaux d'automatisation et les sources de retravail. Où obtenir Provient des champs d'identifiant utilisateur dans les tables d'historique de transactions ou de workflow, tels que les champs createdby ou modifiedby. Ces informations peuvent se trouver dans les tables de suivi des workflows. Exemples j.doea.smithAX_Admin
	Code société CompanyCode	L'identifiant de l'entité juridique ou de l'entreprise au sein de l'organisation qui traite la facture.
Description Le code d'entreprise (Company Code) représente l'entité juridique spécifique financièrement responsable de la facture. Dans une organisation multi-entreprises, il s'agit d'un point de données critique pour la segmentation financière. Cet attribut permet de filtrer ou de comparer l'analyse de processus entre différentes entités juridiques. Il peut révéler si les performances, les politiques ou les goulots d'étranglement du processus sont spécifiques à certaines entreprises du groupe, soutenant ainsi des initiatives d'amélioration de processus localisées. Pourquoi c'est important Permet de segmenter l'analyse des processus par entité juridique, ce qui est crucial pour les grandes organisations multi-sociétés. Où obtenir C'est un champ standard dans la plupart des tables financières de Dynamics 365, souvent appelé DataAreaId. Exemples USMFDEMFGBSI
	Conditions de paiement PaymentTerms	L'accord sur les conditions de paiement avec le fournisseur, tel que « Net 30 » ou « 2% 10, Net 30 ».
Description Les conditions de paiement définissent les modalités convenues pour le paiement du fournisseur, y compris le délai et les remises potentielles. Ces informations proviennent généralement des données de base des fournisseurs ou du bon de commande. Cet attribut fournit un contexte crucial pour la date d'échéance du paiement et l'ICP (KPI) du taux de paiement à temps. L'analyse de la corrélation entre certaines conditions de paiement et les retards de paiement peut révéler des défis opérationnels. Elle aide également à la planification financière et à la gestion efficace du fonds de roulement. Pourquoi c'est important Fournit un contexte pour les dates d'échéance de paiement et aide à analyser l'impact financier du calendrier de paiement et des taux de capture des escomptes. Où obtenir Ces informations sont stockées dans les données de base des fournisseurs (VendTable) et copiées dans les tables de transactions comme VendInvoiceInfoTable. Exemples Net 30Net 602% 10, Net 30
	Département Department	Le centre de coûts ou le département auquel les coûts de la facture sont alloués.
Description Le Département identifie l'unité commerciale ou le centre de coûts responsable de la dépense sur la facture. Cela est généralement déterminé lors de l'activité de codage de la facture. L'analyse du processus par département est essentielle pour comprendre les différences départementales en matière de dépenses, de temps d'approbation et de conformité. Elle aide à identifier quels départements ont le plus d'exceptions de factures ou les cycles d'approbation les plus longs, fournissant une base pour une communication et une formation ciblées. Pourquoi c'est important Permet l'analyse des coûts et des processus par département, mettant en évidence les variations de performance et de conformité au sein de l'organisation. Où obtenir Provient des dimensions financières liées aux lignes ou à l'en-tête de la facture. Cela nécessite l'interrogation des structures de données liées aux dimensions. Exemples VentesMarketingOpérations IT
	Devise de la facture InvoiceCurrency	Le code de la devise du montant de la facture (par exemple, USD, EUR).
Description La devise de la facture (Invoice Currency) spécifie la devise dans laquelle le montant de la facture est libellé. C'est important pour les organisations multinationales traitant avec des fournisseurs de différents pays. Cet attribut fournit le contexte nécessaire pour le montant de la facture (Invoice Amount) et est utilisé pour le filtrage et les rapports, en particulier dans les opérations globales. Il garantit que les valeurs financières sont interprétées correctement et permet une analyse spécifique à la devise ou une conversion vers une devise de rapport standard. Pourquoi c'est important Fournit un contexte essentiel pour les montants financiers, permettant une interprétation et une analyse précises des valeurs des factures dans différentes régions. Où obtenir Situé dans la table d'en-tête de facture, à côté du montant de la facture, par exemple, le champ CurrencyCode de la table VendInvoiceInfoTable. Exemples USDEURGBP
	Est Automatisé IsAutomated	Un indicateur spécifiant si une activité a été réalisée automatiquement par le système ou par un utilisateur humain.
Description Cet attribut booléen (vrai/faux) distingue les événements exécutés par le système des tâches utilisateur manuelles. Par exemple, une étape de rapprochement de facture peut être automatisée, tandis que le traitement des divergences est manuel. L'analyse de cet attribut est essentielle pour comprendre le niveau d'automatisation dans le processus. Elle aide à mesurer le succès des initiatives d'automatisation, identifie les goulots d'étranglement manuels restants et met en évidence les opportunités d'automatisation supplémentaire pour améliorer l'efficacité et réduire les erreurs. Pourquoi c'est important Aide à mesurer le niveau d'automatisation du processus, en identifiant les goulots d'étranglement manuels et les opportunités de gain d'efficacité. Où obtenir Ceci est typiquement dérivé en fonction de l'attribut « Utilisateur ». Si l'utilisateur est un compte système ou de service connu, ce drapeau est défini sur vrai. Exemples truefaux
	Motif de blocage de paiement PaymentBlockReason	Le code motif expliquant pourquoi un blocage de paiement a été appliqué à une facture.
Description Un blocage de paiement empêche le règlement d'une facture. Cet attribut capture la raison du blocage, qui est généralement un code standardisé sélectionné par un utilisateur, tel que 'Charges contestées' ou 'En attente de réception des marchandises'. Cet attribut est essentiel pour le dashboard 'Fréquence et durée des blocages de paiement'. L'analyse des raisons les plus courantes de blocage de paiement aide à identifier les problèmes sous-jacents du processus P2P. La résolution de ces causes profondes peut réduire considérablement les retards de paiement et améliorer les relations avec les fournisseurs. Pourquoi c'est important Explique pourquoi les paiements sont intentionnellement retardés, aidant à identifier et à résoudre les problèmes en amont qui causent les blocages de paiement. Où obtenir C'est typiquement un champ sur l'enregistrement de la transaction fournisseur ou de la facture, souvent lié au statut de blocage de paiement. Cherchez dans des tables comme VendTrans. Exemples Litige de qualitéEn attente d'avoirBlocage manuel
	Motif de refus RejectionReason	Le motif fourni par un approbateur pour le rejet d'une facture.
Description Lorsqu'une facture est rejetée pendant le workflow d'approbation, l'approbateur indique généralement un motif. Cet attribut saisit cette explication, qui peut être un code prédéfini ou un texte libre. Il s'agit d'un attribut essentiel pour le dashboard d'« Analyse des rejets de factures ». Il offre les insights qualitatifs nécessaires pour comprendre les causes profondes des rejets, telles que « Numéro de commande incorrect », « Facture en double » ou « Écart de prix ». L'analyse de ces motifs permet de prioriser les actions visant à réduire le taux de rejet. Pourquoi c'est important Fournit un aperçu direct des raisons pour lesquelles les factures sont rejetées, permettant des actions ciblées pour réduire le retravail et améliorer les taux de « bon du premier coup ». Où obtenir Typiquement trouvé dans les commentaires ou les journaux d'historique des tables de traitement des workflows. Exemples Quantité incorrecteFacture en doubleLimite d'approbation dépassée
	Paiement à Temps IsOnTimePayment	Un indicateur calculé qui indique si une facture a été payée à ou avant sa date d'échéance.
Description Cet attribut booléen est dérivé en comparant l'horodatage de l'activité « Paiement exécuté » avec la « Date d'échéance du paiement ». Si la date de paiement est inférieure ou égale à la date d'échéance, la valeur est vraie, sinon elle est fausse. Cet attribut prend directement en charge l'ICP (KPI) du « Taux de paiement à temps » et le Dashboard de « Conformité des conditions de paiement ». Il simplifie l'analyse en fournissant un résultat binaire clair pour chaque facture, facilitant le filtrage des retards de paiement et l'investigation de leurs causes profondes par fournisseur, département ou pays. Pourquoi c'est important Mesure directement la conformité aux conditions de paiement, simplifiant le calcul du KPI du Taux de paiement à temps et les analyses connexes. Où obtenir Cet attribut est calculé dans la couche de transformation des données. La logique est : (Horodatage de l'activité « Paiement exécuté ») <= (Date d'échéance du paiement). Exemples truefaux
	Temps de cycle total TotalCycleTime	La durée totale de bout en bout pour le traitement d'une seule facture, de la réception au paiement.
Description Le temps de cycle total (Total Cycle Time) mesure la durée complète qu'une facture passe dans le processus. Il est calculé comme la différence de temps entre la toute première activité (par exemple, « Facture enregistrée ») et la toute dernière activité (par exemple, « Paiement exécuté ») pour un numéro de facture donné. C'est un ICP (KPI) principal pour mesurer l'efficacité globale du processus. Il offre une vue d'ensemble des performances et est utilisé dans le Dashboard « Temps de cycle de bout en bout des factures ». L'analyse des tendances de cette métrique et sa segmentation par des attributs comme le fournisseur ou le montant aide à identifier de vastes opportunités d'amélioration. Pourquoi c'est important Représente l'ICP (KPI) clé de haut niveau pour la vitesse et l'efficacité globales du processus, résumant la performance de chaque facture. Où obtenir Ceci est calculé au niveau du 'case' au sein de l'outil de Process Mining ou lors de la préparation des données. C'est la différence de temps entre le premier et le dernier horodatage d'événement pour chaque CaseId. Exemples P15DP22DT5H30MP7D
	Temps de traitement ProcessingTime	La durée d'une seule activité, calculée comme la différence entre son heure de fin et son heure de début.
Description Le temps de traitement mesure le temps actif passé sur une tâche spécifique. Il est calculé en soustrayant l'heure de début (StartTime) d'un événement de son heure de fin (EndTime). Ceci est également appelé durée d'activité. Cette métrique est fondamentale pour l'analyse des performances. Elle aide à identifier les activités spécifiques qui prennent le plus de temps, par opposition aux temps d'attente entre les activités. Cela permet des améliorations ciblées, comme une meilleure formation pour accélérer le codage manuel ou l'optimisation d'une étape système qui s'exécute lentement. Pourquoi c'est important Mesure la durée de travail réelle des activités, aidant à identifier les tâches inefficaces propices à l'optimisation ou à l'automatisation. Où obtenir Ce n'est pas un champ dans le système source. Il est calculé lors de la transformation des données à l'aide de la formule : EndTime - StartTime. Exemples PT1H30MP2DT4HPT5M15S
	Type d'écart MatchingDiscrepancyType	Catégorise le type d'écart constaté lors du processus de rapprochement entre la facture et le bon de commande.
Description Lorsqu'une divergence survient lors du rapprochement à 2 ou 3 voies, cet attribut spécifie la nature du problème, par exemple, « Écart de prix », « Écart de quantité » ou « Manque de réception de marchandises ». Ces données sont centrales pour le Dashboard « Temps de résolution des divergences de rapprochement ». En analysant la fréquence des différents types de divergences, l'entreprise peut identifier les causes profondes des échecs de rapprochement. Par exemple, des écarts de prix fréquents peuvent indiquer des problèmes de données de base obsolètes, tandis que des écarts de quantité pourraient signaler des problèmes d'expédition. Pourquoi c'est important Il catégorise les échecs de rapprochement, permettant une analyse des causes profondes afin de réduire le taux de divergences et d'améliorer le traitement direct. Où obtenir Ceci peut être stocké dans une table de journal de rapprochement ou d'exceptions dédiée, ou il peut être nécessaire de le dériver à partir des messages de statut ou des commentaires de workflow. Exemples Écart de prixDivergence de quantitéRéception de marchandises manquante

Obligatoire Recommandé Facultatif

Achats au Paiement – Activités de traitement des factures

Voici les étapes clés du processus et les jalons essentiels à capturer dans votre journal d'événements pour une découverte et une analyse précises de votre workflow de traitement des factures.

6 Recommandé 8 Facultatif

	Activité	Description
	Facture approuvée	Représente l'approbation finale et réussie de la facture au sein du workflow, l'autorisant à être comptabilisée et payée. C'est un événement explicite enregistré par le moteur de workflow dès son achèvement.
Pourquoi c'est important C'est une étape cruciale qui conclut le processus d'approbation. Le temps écoulé entre « Facture envoyée pour approbation » et cet événement est une mesure clé de l'efficacité de l'approbation et aide à identifier les goulots d'étranglement. Où obtenir C'est un événement explicite enregistré dans les tables d'historique de workflow (par exemple, WorkflowTrackingStatusTable) lorsque le statut du workflow passe à « Approuvé ». Capture Horodatage de l'entrée de statut « Approuvé » dans l'historique du workflow. Type d'événement explicit
	Facture comptabilisée	C'est l'événement comptable formel où la facture approuvée est enregistrée dans le Grand Livre, créant une dette. C'est un événement transactionnel explicite dans le système.
Pourquoi c'est important La comptabilisation est l'étape finale avant le paiement et un point de contrôle financier clé. Le temps entre « Facture approuvée » et « Facture comptabilisée » mesure l'efficacité des dernières étapes comptables. Où obtenir C'est un événement explicite capturé lors de la création de la transaction fournisseur comptabilisée dans des tables comme VendTrans et les enregistrements associés GeneralJournalEntry et LedgerEntry. Capture Horodatage de création de l'enregistrement dans la table des transactions fournisseurs (VendTrans). Type d'événement explicit
	Facture enregistrée	C'est la saisie initiale d'une facture dans le système, créant un enregistrement de substitution avant que tous les détails ne soient traités. Cette activité est capturée lorsqu'un nouvel enregistrement est créé dans le journal du registre des factures fournisseurs.
Pourquoi c'est important Cette activité marque le début officiel du cycle de vie du traitement des factures. L'analyse du temps à partir de ce point aide à mesurer la durée totale du traitement et identifie les retards en phase précoce. Où obtenir C'est un événement explicite capturé lors de la création d'un enregistrement dans le registre des factures fournisseurs, typiquement dans la table VendInvoiceRegisterJournalTable ou une table similaire de factures en attente. Capture Horodatage de création de l'enregistrement dans le journal du registre des factures fournisseurs. Type d'événement explicit
	Facture envoyée pour approbation	Cette activité marque la soumission formelle d'une facture dans un workflow pour examen et approbation. Le moteur de workflow de Dynamics 365 enregistre explicitement cet événement de soumission.
Pourquoi c'est important C'est le point de départ pour mesurer l'ensemble du cycle d'approbation. Il aide à identifier combien de temps les factures attendent avant même le début du processus d'approbation et constitue le déclencheur des ICP (KPI) liés à l'approbation. Où obtenir C'est un événement explicite enregistré dans les tables d'historique de workflow (par exemple, WorkflowTrackingStatusTable) lorsqu'une facture est soumise à un workflow. Capture Horodatage de création de l'enregistrement de soumission du workflow dans l'historique du workflow. Type d'événement explicit
	Facture rapprochée au bon de commande	Représente l'achèvement réussi du processus de rapprochement, où les détails de la facture s'alignent avec le bon de commande et les informations de réception des marchandises. Cet événement est déduit lorsque le statut de rapprochement de la facture est mis à jour à « Réussi ».
Pourquoi c'est important Le rapprochement réussi est une étape clé pour les factures adossées à un bon de commande, confirmant la validité de la charge avant le paiement. C'est essentiel pour suivre l'efficacité du rapprochement et les taux d'automatisation. Où obtenir Déduit de la mise à jour du champ de statut de rapprochement sur l'en-tête ou les lignes de la facture fournisseur (par exemple, VendInvoiceInfoTable) à une valeur 'Réussi' ou 'Rapproché avec succès'. Capture Horodatage du changement de statut à « Réussi » dans les détails de validation du rapprochement de facture. Type d'événement inferred
	Paiement effectué	C'est l'activité finale, représentant la comptabilisation du journal de paiement qui crée le paiement et règle la facture. C'est un événement transactionnel explicite qui clôture le cycle de vie de la facture.
Pourquoi c'est important Cette activité marque la fin réussie du processus de la facture au paiement. Elle constitue la base pour mesurer le « Taux de paiement à temps » et le temps de cycle total de bout en bout. Où obtenir C'est un événement explicite capturé lors de la comptabilisation du journal de paiement. Les informations de règlement sont enregistrées dans des tables comme VendSettlement, liant le paiement à la facture. Capture Horodatage de la comptabilisation du journal de paiement qui règle la transaction fournisseur. Type d'événement explicit
	Blocage de paiement activé	Cette activité se produit lorsqu'une retenue est placée sur une facture, l'empêchant d'être payée. Ceci est capturé par un changement dans le champ de blocage de paiement ou de statut de retenue sur l'enregistrement de la facture comptabilisée.
Pourquoi c'est important Les blocages de paiement sont une cause principale des retards de paiement. Analyser quand et pourquoi ils sont appliqués est crucial pour améliorer la performance des paiements à temps et les relations avec les fournisseurs. Où obtenir Déduit d'un changement du champ de suspension ou de blocage de paiement sur la transaction fournisseur publiée (VendTrans). Le journal des modifications peut être utilisé pour capturer l'horodatage. Capture Horodatage de la mise à jour qui définit le champ de blocage de paiement sur la transaction fournisseur. Type d'événement inferred
	Blocage de paiement levé	Représente la levée d'une retenue de paiement, permettant à la facture de passer à la planification du paiement. Ceci est capturé lorsque le champ de blocage de paiement est effacé ou modifié vers un état débloqué.
Pourquoi c'est important Mesure le temps nécessaire pour résoudre les problèmes entraînant des retenues de paiement. Des durées prolongées entre l'application et la levée d'un blocage indiquent des processus de résolution de problèmes inefficaces. Où obtenir Déduit d'un changement qui efface le champ de blocage ou de suspension de paiement sur la transaction fournisseur publiée (VendTrans). Le journal des modifications peut fournir l'horodatage. Capture Horodatage de la mise à jour qui efface le champ de blocage de paiement sur la transaction fournisseur. Type d'événement inferred
	Divergence de rapprochement traitée	Marque la résolution d'une divergence de rapprochement précédemment identifiée, permettant à la facture de poursuivre son traitement. Cela est déduit lorsqu'une facture avec un statut de rapprochement « Échec » est correctement rapprochée à nouveau ou annulée manuellement.
Pourquoi c'est important Cette activité conclut le sous-processus de résolution des divergences. Le temps entre « Divergence de rapprochement trouvée » et cet événement est un ICP (KPI) clé pour mesurer l'efficacité de la résolution. Où obtenir Déduit d'un événement de rapprochement réussi ('Facture Rapprochée au Bon de Commande') qui se produit après un événement de 'Discrépance de Rapprochement Trouvée' pour la même facture. Capture Identifier un horodatage de statut de rapprochement 'Réussi' qui suit un horodatage de statut 'Échoué'. Type d'événement inferred
	Divergence de rapprochement trouvée	Cette activité se produit lorsque le processus de rapprochement des factures échoue en raison de désalignements entre la facture, le bon de commande ou la réception des marchandises. Elle est capturée lorsque le statut de rapprochement de la facture est défini sur « Échec » ou « Divergence ».
Pourquoi c'est important Identifier quand et pourquoi les écarts se produisent est crucial pour le KPI 'Taux d'écarts de rapprochement'. Cette activité marque le début du processus de résolution, qui est souvent une source de retards significatifs. Où obtenir Déduit de la mise à jour du champ de statut de rapprochement sur la facture fournisseur (par exemple, VendInvoiceInfoTable) à une valeur 'Échoué'. La raison de l'échec est souvent également enregistrée. Capture Horodatage du changement de statut à « Échec » ou « Divergence » pendant le rapprochement. Type d'événement inferred
	Données de facture saisies	Représente l'achèvement de la saisie des données de la facture, y compris les détails de l'en-tête et des lignes, avant qu'elle ne soit soumise pour rapprochement ou approbation. Ceci est souvent déduit lorsque l'enregistrement de la facture passe d'un statut « nouveau » ou « enregistré » à un état « prêt pour le traitement ».
Pourquoi c'est important Le suivi de cette activité aide à mesurer l'efficacité du processus de saisie des données, qu'il soit manuel ou automatisé (OCR). Les retards ici peuvent avoir un effet en cascade sur l'ensemble du processus. Où obtenir Déduit des changements de statut sur l'enregistrement de la facture fournisseur en attente (par exemple, VendInvoiceInfoTable). L'événement se produit lorsque tous les champs requis sont remplis et que la facture est prête pour l'étape suivante. Capture Détecte un changement de statut sur la table des factures en attente indiquant la fin de la saisie des données. Type d'événement inferred
	Facture codée	Cette activité signifie que les distributions de comptes du grand livre général ont été attribuées aux lignes de facture. Elle est généralement inférée par la création ou la finalisation des distributions de comptes de grand livre liées à la facture.
Pourquoi c'est important Le codage est une étape critique pour la précision financière. Mesurer le temps nécessaire pour coder les factures aide à identifier les goulots d'étranglement dans le processus de révision comptable et soutient le KPI 'Temps moyen de la capture de données au codage'. Où obtenir Déduit de la création et de la validation des enregistrements dans les tables de distribution comptable (par exemple, AccountingDistribution) associées à la facture fournisseur en attente. Capture Horodatage lorsque les distributions comptables de la facture sont enregistrées et validées. Type d'événement inferred
	Facture rejetée	Indique qu'un approbateur a rejeté la facture, arrêtant le processus et la renvoyant généralement pour correction. Le moteur de workflow enregistre explicitement cet événement de rejet.
Pourquoi c'est important Le suivi des rejets aide à quantifier le retravail et à identifier les raisons courantes des échecs, telles qu'un codage incorrect ou des violations de politique. Cela soutient directement l'ICP (KPI) du « Taux de rejet des factures ». Où obtenir C'est un événement explicite enregistré dans les tables d'historique de workflow (par exemple, WorkflowTrackingStatusTable) lorsque le statut du workflow passe à « Rejeté » ou « Annulé ». Capture Horodatage de l'entrée de statut « Rejeté » dans l'historique du workflow. Type d'événement explicit
	Paiement planifié	Cette activité se produit lorsqu'une facture comptabilisée est incluse dans une proposition de paiement ou un journal de paiement, mais avant l'exécution du paiement. C'est une action explicite créant une ligne de journal de paiement.
Pourquoi c'est important Ceci marque la transition des opérations de la comptabilité fournisseurs aux opérations de trésorerie. L'analyse de cette étape peut révéler des retards entre la comptabilisation des factures et l'initiation des paiements. Où obtenir C'est un événement explicite capturé lors de la création d'une ligne dans un journal de paiement (LedgerJournalTrans) qui règle la transaction fournisseur comptabilisée. Capture Horodatage de création de la ligne de journal de paiement référençant la facture. Type d'événement explicit

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de Microsoft Dynamics 365

Étapes

Naviguer vers l'espace de travail Gestion des données: Connectez-vous à Microsoft Dynamics 365 Finance. Utilisez la barre de recherche pour trouver et naviguer vers l'espace de travail Gestion des données.
Créer un nouveau projet d'exportation: Dans l'espace de travail, sélectionnez la tuile Exporter pour créer un nouveau projet d'exportation de données. Donnez un nom significatif au projet, par exemple, ProcessMind_Invoice_Processing_Export.
Définir le projet de données: Dans l'onglet Général du nouveau projet, spécifiez le Format des données. CSV est un format couramment utilisé et recommandé. Définissez les autres paramètres selon vos besoins.
Ajouter les entités de données requises: Allez dans la section Entités sélectionnées et cliquez sur Ajouter une entité. Recherchez et ajoutez les entités principales suivantes une par une. Vous devrez spécifier le format de données cible pour chacune.
- VendInvoiceInfoTableEntity (En-tête de facture fournisseur)
- VendInvoiceTransEntity (Lignes de facture fournisseur)
- VendInvoiceRegisterHeaderEntity (En-tête de journal de registre des factures)
- WorkflowTrackingStatusTableEntity (Historique de workflow)
- AccountingDistributionEntity (Distributions GL)
- VendInvoiceJour (Factures fournisseurs publiées)
- VendTrans (Transactions fournisseurs, pour les blocages de paiement)
- LedgerJournalTransVendPaymEntity (Lignes de journal de paiement fournisseur)
- VendSettlement (Transactions de règlement fournisseur)
Appliquer des filtres: Pour chaque entité, il est essentiel d'appliquer des filtres pour limiter la portée des données. Sélectionnez une entité et cliquez sur Filtrer. Au minimum, filtrez par Société (Entité juridique) et une plage de dates spécifique sur un champ de date pertinent comme CREATEDDATETIME ou INVOICEDATE. Une plage typique pour l'analyse initiale est les 3 à 6 derniers mois.
Configurer les mappages d'entités: Pour chaque entité, révisez le mappage source-cible. Assurez-vous que tous les champs requis pour l'Event Log final sont inclus dans l'exportation. Aucune modification de mappage complexe n'est généralement nécessaire à ce stade.
Exécuter la tâche d'exportation: Une fois toutes les entités ajoutées et filtrées, cliquez sur Exporter dans le volet d'action pour démarrer la tâche. Vous pouvez l'exécuter immédiatement ou la planifier pendant les heures creuses pour minimiser la charge système.
Télécharger les données exportées: Une fois la tâche d'exportation terminée avec succès, accédez à l'historique des tâches. De là, vous pouvez télécharger le package de données exporté, qui contiendra des fichiers distincts pour chaque entité de données.
Transformer les données en Event Log: Les fichiers exportés sont des instantanés d'entités, et non un Event Log consolidé. Vous devez utiliser un outil externe comme une base de données, un script Python ou Power Query pour traiter et combiner ces fichiers. La requête conceptuelle dans la section query fournit la logique complète de cette transformation.
Exécuter la logique de transformation: Chargez les fichiers CSV exportés dans votre environnement de transformation choisi. Exécutez la requête de transformation fournie, qui unit les données de tous les fichiers source pour créer une seule table Event Log avec une ligne par activité métier.
Finaliser et télécharger: Exportez les données transformées finales dans un seul fichier CSV. Assurez-vous que les en-têtes de colonnes correspondent aux exigences, par exemple, InvoiceNumber, ActivityName, EventTime. Ce fichier est maintenant prêt à être téléchargé dans ProcessMind.

Configuration

Entités de données: Le cœur de la configuration consiste à sélectionner l'ensemble d'entités approprié pour couvrir le cycle de vie des factures. Les entités clés incluent VendInvoiceInfoTableEntity, VendInvoiceJour et WorkflowTrackingStatusTableEntity.
Format d'exportation des données: Sélectionnez CSV comme format de données cible pour faciliter le traitement lors des étapes de transformation ultérieures.
Filtrage par société: Il est crucial de filtrer chaque entité de données par l'entité juridique (Société) spécifique que vous analysez afin d'éviter d'extraire des données non pertinentes.
Filtrage par plage de dates: Appliquez un filtre de plage de dates cohérent à toutes les entités pertinentes, telles que VendInvoiceInfoTableEntity et VendInvoiceJour, basé sur les dates de création ou de publication. Commencez par une période récente, par exemple les 6 derniers mois, pour gérer le volume de données.
Exportation complète vs. Incrémentielle: Pour l'extraction initiale, effectuez une exportation complète. Pour les actualisations ultérieures, vous pouvez configurer une exportation incrémentielle pour récupérer uniquement les données qui ont changé depuis la dernière exécution, ce qui réduit le temps de traitement.
Prérequis: L'utilisateur qui exécute l'exportation doit disposer des rôles de sécurité appropriés dans Dynamics 365, généralement incluant Data management administrator ou un rôle similaire avec les permissions d'accès aux entités de données requises.

a Exemple de requête config

/*
-- This is a conceptual query to be executed in a database or data transformation tool.
-- The tables referenced (e.g., 'VendInvoiceInfoTableEntity') are the CSV files exported from Dynamics 365.
-- Replace '[Your_Source_System_Name]' with the actual source system identifier.
*/

-- 1. Invoice Registered
SELECT
    h.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Registered' AS "ActivityName",
    h.CREATEDDATETIME AS "EventTime",
    h.CREATEDBY AS "User",
    h.INVOICEACCOUNT AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    h.INVOICEAMOUNT AS "InvoiceAmount",
    NULL AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    h.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceRegisterHeaderEntity h

UNION ALL

-- 2. Invoice Data Captured
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Data Captured' AS "ActivityName",
    i.CREATEDDATETIME AS "EventTime",
    i.CREATEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i

UNION ALL

-- 3. Invoice Coded
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Coded' AS "ActivityName",
    MIN(a.CREATEDDATETIME) AS "EventTime",
    MIN(a.CREATEDBY) AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    MIN(a.CREATEDDATETIME) AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
JOIN AccountingDistributionEntity a ON i.INVOICENUMBER = a.SOURCEDOCUMENTLINE_INVOICENUMBER
GROUP BY i.INVOICENUMBER, i.VENDORACCOUNT, i.PURCHASEORDERNUMBER, i.INVOICEAMOUNT

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Matched To Purchase Order' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed'

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Found' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Discrepancy' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Failed'

UNION ALL

-- 6. Matching Discrepancy Handled (Approximation)
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Handled' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed' AND i.MODIFIEDDATETIME > i.CREATEDDATETIME

UNION ALL

-- 7. Invoice Sent For Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    w.CONTEXT_INVOICENUMBER AS "InvoiceNumber",
    CASE w.TRACKINGSTATUS
        WHEN 'Submitted' THEN 'Invoice Sent For Approval'
        WHEN 'Completed' THEN 'Invoice Approved'
        WHEN 'Canceled' THEN 'Invoice Rejected'
        ELSE CONCAT('Workflow: ', w.TRACKINGSTATUS)
    END AS "ActivityName",
    w.CREATEDDATETIME AS "EventTime",
    w.USERID AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    w.TRACKINGSTATUS AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    w.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM WorkflowTrackingStatusTableEntity w
JOIN VendInvoiceInfoTableEntity i ON w.CONTEXT_RECID = i.RECID AND w.CONTEXT_TABLEID = i.TABLEID
WHERE w.TRACKINGTYPE = 'Approval'

UNION ALL

-- 10. Payment Block Set
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Set' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Blocked' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'Yes'

UNION ALL

-- 11. Payment Block Released
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Released' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Open' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'No' AND v.MODIFIEDDATETIME > v.CREATEDDATETIME

UNION ALL

-- 12. Invoice Posted
SELECT
    vj.INVOICENUM AS "InvoiceNumber",
    'Invoice Posted' AS "ActivityName",
    vj.POSTINGDATE AS "EventTime",
    vj.CREATEDBY AS "User",
    vj.INVOICEACCOUNT AS "VendorNumber",
    vj.PURCHID AS "PurchaseOrderNumber",
    vj.INVOICEAMOUNT AS "InvoiceAmount",
    'Posted' AS "InvoiceStatus",
    vj.DUEDATE AS "PaymentDueDate",
    vj.POSTINGDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceJour vj

UNION ALL

-- 13. Payment Scheduled
SELECT
    l.INVOICENUMBER AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    l.CREATEDDATETIME AS "EventTime",
    l.CREATEDBY AS "User",
    l.ACCOUNTDISPLAYVALUE AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    l.DEBITAMOUNT + l.CREDITAMOUNT AS "InvoiceAmount",
    'Scheduled for Payment' AS "InvoiceStatus",
    l.DUEDATE AS "PaymentDueDate",
    l.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM LedgerJournalTransVendPaymEntity l

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICENUMBER AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    vs.TRANSDATE AS "EventTime",
    vs.CREATEDBY AS "User",
    vs.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    vs.SETTLEMENTAMOUNT AS "InvoiceAmount",
    'Paid' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    vs.TRANSDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendSettlement vs;

Étapes

Prérequis: Configurer le BYOD: Assurez-vous que la fonctionnalité Bring Your Own Database (BYOD) est configurée pour votre environnement Microsoft Dynamics 365 Finance and Operations. Cela implique la mise en place d'une base de données Azure SQL et la configuration de D365 pour y exporter les données.
Identifier les entités de données: Dans D365, naviguez vers l'espace de travail Gestion des données. Le cœur de cette extraction repose sur l'exportation d'entités de données spécifiques. Assurez-vous que les entités suivantes sont incluses dans une tâche d'exportation ciblant votre base de données BYOD: Vendor invoice journal, Vendor invoice lines, Vendor invoice document register, Workflow tracking status table, Vendor payment journal lines, Vendor settlements et Accounting distributions.
Créer et planifier une tâche d'exportation: Dans l'espace de travail Gestion des données, créez un nouveau projet d'exportation. Ajoutez les entités listées ci-dessus au projet. Configurez le format de données cible pour qu'il soit votre base de données BYOD. Mettez en place une planification récurrente pour la tâche d'exportation, par exemple, quotidienne ou horaire, pour maintenir les données de votre BYOD à jour.
Vérifier les données dans Azure SQL: Connectez-vous à votre base de données Azure SQL à l'aide d'un outil comme SQL Server Management Studio (SSMS) ou Azure Data Studio. Vérifiez que les tables correspondant aux entités D365 ont été créées et sont remplies de données.
Préparer la requête SQL: Copiez la requête SQL fournie. Cette requête est conçue pour s'exécuter directement sur les tables créées par le processus d'exportation BYOD dans votre base de données Azure SQL.
Connecter et exécuter: Ouvrez une nouvelle fenêtre de requête dans votre client SQL connecté au BYOD. Collez la requête SQL copiée dans la fenêtre.
Définir les paramètres de requête: Repérez les variables d'espace réservé en haut du script. Remplacez {StartDate}, {EndDate} et {CompanyCode} par la date de début, la date de fin et l'identifiant de l'entité juridique souhaités, respectivement. Par exemple, SET @StartDate = '2023-01-01';, SET @EndDate = '2023-12-31';, SET @CompanyCode = 'USMF';.
Exécuter la requête: Exécutez le script SQL complet. La requête collectera et unira les données de plusieurs tables pour construire un Event Log chronologique pour chaque facture.
Examiner les résultats: Le résultat sera une seule table contenant l'Event Log avec des colonnes pour InvoiceNumber, ActivityName, EventTime et d'autres attributs spécifiés. Examinez les résultats pour vous assurer qu'ils sont corrects et complets.
Exporter l'Event Log: Exportez les résultats de la requête vers un fichier CSV. La plupart des clients SQL ont une fonction intégrée pour enregistrer les résultats dans un fichier. Assurez-vous que le fichier est enregistré avec un encodage UTF-8.
Préparer le téléchargement: Avant de télécharger vers un outil de Process Mining, confirmez que le fichier CSV a les en-têtes exacts spécifiés dans la requête (InvoiceNumber, ActivityName, etc.). Aucune transformation supplémentaire de la structure du fichier n'est nécessaire.

Configuration

Entités de données clés: L'extraction s'appuie sur l'exportation de plusieurs entités de données D365 vers le BYOD. Les entités critiques incluent: VendInvoiceJour, VendInvoiceInfoTable, WorkflowTrackingStatusTable, VendSettlement, VendInvoiceRegisterHeader, LedgerJournalTrans, AccountingDistribution et VendTrans.
Filtrage par plage de dates: La requête fournie inclut les paramètres @StartDate et @EndDate. Il est recommandé de commencer par une plage de dates limitée, telle que 3 à 6 mois de données, pour garantir la performance. Le filtre est appliqué à la date de publication ou de création de la facture.
Filtrage par code de société: Le paramètre @DataAreaId est crucial pour les environnements multi-sociétés. Filtrez toujours pour une entité juridique spécifique (Code de société) afin d'assurer que le contexte des données est correct.
Fréquence d'actualisation BYOD: L'actualité des données dépend entièrement du calendrier de la tâche d'exportation D365. Pour une analyse quasi-en temps réel, une fréquence élevée (par exemple, horaire) est requise, ce qui peut avoir des implications sur les performances et les coûts de D365 et d'Azure.
Prérequis: Cette méthode nécessite un abonnement Azure actif, une base de données Azure SQL provisionnée et un accès de niveau administrateur dans D365 pour configurer l'espace de travail Gestion des données.

a Exemple de requête sql

DECLARE @StartDate DATETIME = '{StartDate}';
DECLARE @EndDate DATETIME = '{EndDate}';
DECLARE @CompanyCode NVARCHAR(4) = '{CompanyCode}';

WITH BaseInvoices AS (
    SELECT
        h.INVOICEID AS InvoiceNumber,
        h.VENDORACCOUNT AS VendorNumber,
        h.PURCHID AS PurchaseOrderNumber,
        h.INVOICEAMOUNT AS InvoiceAmount,
        p.DUEDATE AS PaymentDueDate,
        h.DOCUMENTSTATUS AS InvoiceStatus,
        h.CREATEDBY AS CreatedByUser,
        h.CREATEDDATETIME AS CreatedDateTime,
        h.MODIFIEDBY AS ModifiedByUser,
        h.MODIFIEDDATETIME AS ModifiedDateTime,
        h.BLOCKED AS IsBlocked,
        h.POSTINGDATE AS PostingDate
    FROM VendInvoiceJour h
    LEFT JOIN VendTrans p ON h.INVOICEID = p.INVOICE AND h.DATAAREAID = p.DATAAREAID AND h.VENDORACCOUNT = p.ACCOUNTNUM
    WHERE h.DATAAREAID = @CompanyCode
      AND h.POSTINGDATE BETWEEN @StartDate AND @EndDate
)
-- 1. Invoice Registered
SELECT
    vpr.JOURNALID AS InvoiceNumber,
    'Invoice Registered' AS ActivityName,
    vpr.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vpr.VENDORACCOUNT AS VendorNumber,
    NULL AS PurchaseOrderNumber,
    vpr.INVOICEAMOUNT AS InvoiceAmount,
    vpr.CREATEDBY AS User,
    'Registered' AS InvoiceStatus,
    vpr.DUEDATE AS PaymentDueDate,
    vpr.CREATEDDATETIME AS EndTime
FROM VendInvoiceRegisterHeader vpr
WHERE vpr.DATAAREAID = @CompanyCode AND vpr.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 2. Invoice Data Captured
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Data Captured' AS ActivityName,
    viit.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.CREATEDBY AS User,
    'Pending' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.CREATEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 3. Invoice Coded
SELECT
    vil.INVOICEID AS InvoiceNumber,
    'Invoice Coded' AS ActivityName,
    MAX(ad.CREATEDDATETIME) AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    MAX(ad.CREATEDBY) AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    MAX(ad.CREATEDDATETIME) AS EndTime
FROM AccountingDistribution ad
JOIN VendInvoiceInfoLine vil ON ad.SOURCEDOCUMENTLINE = vil.RECID
JOIN BaseInvoices bij ON vil.INVOICEID = bij.InvoiceNumber
WHERE ad.DATAAREAID = @CompanyCode
GROUP BY vil.INVOICEID, bij.VendorNumber, bij.PurchaseOrderNumber, bij.InvoiceAmount, bij.InvoiceStatus, bij.PaymentDueDate

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    viit.NUM AS InvoiceNumber,
    'Invoice Matched To Purchase Order' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Found' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matching Failed' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 2 -- Enum for Failed
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 6. Matching Discrepancy Handled (Inferred by successful match after a failure)
-- This is an approximation. A true 'handled' event is difficult to capture without change tracking.
-- This query assumes the modification time of the 'Passed' status represents the handling time.
SELECT
    viit.NUM AS InvoiceNumber,
    'Matching Discrepancy Handled' AS ActivityName,
    viit.MODIFIEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    viit.VENDORACCOUNT AS VendorNumber,
    viit.PURCHID AS PurchaseOrderNumber,
    viit.INVOICEAMOUNT AS InvoiceAmount,
    viit.MODIFIEDBY AS User,
    'Matched' AS InvoiceStatus,
    NULL AS PaymentDueDate,
    viit.MODIFIEDDATETIME AS EndTime
FROM VendInvoiceInfoTable viit
WHERE viit.DATAAREAID = @CompanyCode AND viit.PURCHMATCHINGPOLICY > 0 AND viit.LASTMATCHINGSTATUS = 1 -- Enum for Passed
  AND viit.DISCREPANCYSTATE > 0 -- Indicates there was a discrepancy at some point
  AND viit.MODIFIEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 7, 8, 9. Workflow Events (Submitted, Approved, Rejected)
SELECT
    bij.InvoiceNumber,
    CASE wts.TRACKINGTYPE
        WHEN 1 THEN 'Invoice Sent For Approval' -- Submitted
        WHEN 5 THEN 'Invoice Approved' -- Completed/Approved
        WHEN 4 THEN 'Invoice Rejected' -- Rejection
    END AS ActivityName,
    wts.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    wts.USERID AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    wts.CREATEDDATETIME AS EndTime
FROM WorkflowTrackingStatusTable wts
JOIN VendInvoiceInfoTable viit ON wts.CONTEXTRECID = viit.RECID
JOIN BaseInvoices bij ON viit.NUM = bij.InvoiceNumber
WHERE wts.DATAAREAID = @CompanyCode AND wts.TRACKINGTYPE IN (1, 4, 5)

UNION ALL

-- 10. Payment Block Set
SELECT
    bij.InvoiceNumber,
    'Payment Block Set' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    'Blocked' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
WHERE bij.IsBlocked = 1 -- Enum for Yes

UNION ALL

-- 11. Payment Block Released (Inferred by modification of a previously blocked invoice)
SELECT
    bij.InvoiceNumber,
    'Payment Block Released' AS ActivityName,
    bij.ModifiedDateTime AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.ModifiedByUser AS User,
    bij.InvoiceStatus,
    bij.PaymentDueDate,
    bij.ModifiedDateTime AS EndTime
FROM BaseInvoices bij
-- This logic assumes modification date reflects the unblocking action.
-- It requires a more sophisticated change log for true accuracy.
WHERE bij.IsBlocked = 0 AND bij.ModifiedDateTime > bij.CreatedDateTime

UNION ALL

-- 12. Invoice Posted
SELECT
    bij.InvoiceNumber,
    'Invoice Posted' AS ActivityName,
    bij.PostingDate AS EventTime, -- Or CreatedDateTime depending on business process
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    bij.CreatedByUser AS User,
    'Posted' AS InvoiceStatus,
    bij.PaymentDueDate,
    bij.PostingDate AS EndTime
FROM BaseInvoices bij

UNION ALL

-- 13. Payment Scheduled
SELECT
    ljt.INVOICE AS InvoiceNumber,
    'Payment Scheduled' AS ActivityName,
    ljt.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    bij.VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    ljt.CREATEDBY AS User,
    'Payment Scheduled' AS InvoiceStatus,
    bij.PaymentDueDate,
    ljt.CREATEDDATETIME AS EndTime
FROM LedgerJournalTrans ljt
JOIN BaseInvoices bij ON ljt.INVOICE = bij.InvoiceNumber
WHERE ljt.DATAAREAID = @CompanyCode AND ljt.ACCOUNTPLUSTYPE = 2 -- Vendor type
  AND ljt.CREATEDDATETIME BETWEEN @StartDate AND @EndDate

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICEID AS InvoiceNumber,
    'Payment Executed' AS ActivityName,
    vs.CREATEDDATETIME AS EventTime,
    'D365 F&O' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    vs.VENDORACCOUNT AS VendorNumber,
    bij.PurchaseOrderNumber,
    bij.InvoiceAmount,
    vs.CREATEDBY AS User,
    'Paid' AS InvoiceStatus,
    bij.PaymentDueDate,
    vs.CREATEDDATETIME AS EndTime
FROM VendSettlement vs
JOIN BaseInvoices bij ON vs.INVOICEID = bij.InvoiceNumber
WHERE vs.DATAAREAID = @CompanyCode AND vs.CREATEDDATETIME BETWEEN @StartDate AND @EndDate;

Étapes

Configuration des prérequis: Assurez-vous d'avoir Python 3.6 ou plus récent installé sur votre système. Installez les bibliothèques nécessaires à l'aide de pip: pip install pandas requests msal. Ces bibliothèques sont destinées à la manipulation des données, à l'envoi de requêtes HTTP à l'API et à la gestion de l'authentification de la plateforme d'identité Microsoft.
Enregistrer une application dans Azure Active Directory: Pour vous authentifier auprès de l'API Dynamics 365, vous devez enregistrer une application dans le tenant Azure AD de votre organisation. Créez une nouvelle inscription d'application, générez une clé secrète client et notez l'ID de l'application (client), l'ID du répertoire (tenant) et la valeur de la clé secrète client.
Accorder les permissions API: Dans l'inscription d'application nouvellement créée dans Azure AD, naviguez vers les permissions API. Ajoutez une permission pour 'Dynamics ERP' ou 'Dynamics 365 Business Central' (selon votre licence), et accordez la permission déléguée user_impersonation. Un administrateur doit donner son consentement administratif pour ces permissions.
Créer un utilisateur d'application dans Dynamics 365: Dans votre environnement Dynamics 365, naviguez vers Administration système > Utilisateurs > Utilisateurs. Créez un nouvel utilisateur et entrez l'ID de l'application (client) de l'inscription d'application Azure dans le champ ID de l'application. Attribuez les rôles de sécurité appropriés à cet utilisateur, tels que 'Administrateur système' ou un rôle plus restreint ayant un accès en lecture à toutes les entités de données requises.
Configurer le script Python: Copiez le script Python fourni dans un fichier, par exemple extract_invoices.py. Ouvrez le fichier et mettez à jour les variables d'espace réservé en haut avec l'URL de votre environnement Dynamics 365 spécifique, l'ID du tenant, l'ID du client, la clé secrète client et le code de société (dataAreaId) à partir duquel vous souhaitez extraire les données.
Définir la plage de dates: Ajustez les variables START_DATE et END_DATE dans le script pour définir la fenêtre temporelle d'extraction des données. Il est recommandé de commencer par une plage plus petite, comme un mois, pour tester le script et vérifier les résultats.
Exécuter le script: Exécutez le script depuis votre ligne de commande ou terminal en utilisant la commande: python extract_invoices.py. Le script s'authentifiera, interrogera les différents points de terminaison OData pour chaque activité et traitera les données.
Surveiller l'exécution: Le script affichera des messages de progression dans la console au fur et à mesure qu'il récupère les données pour chaque activité. Cela peut prendre un temps considérable en fonction de la plage de dates et du volume de données. Recherchez les messages d'erreur qui pourraient indiquer des problèmes d'authentification ou d'accès à l'API.
Examiner le fichier de sortie: Une fois le script terminé avec succès, il générera un fichier CSV nommé d365_invoice_event_log.csv dans le même répertoire. Ce fichier contient l'Event Log consolidé.
Préparer le téléchargement: Ouvrez le fichier CSV pour vous assurer qu'il est correctement formaté. Vérifiez que toutes les colonnes requises (InvoiceNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate) sont présentes et remplies. Le fichier est maintenant prêt à être téléchargé dans ProcessMind.

Configuration

Authentification: Le script utilise le flux d'informations d'identification client OAuth 2.0. Vous devez configurer une inscription d'application Azure AD et lui accorder les permissions d'API pour Dynamics 365. Un utilisateur d'application avec des rôles de sécurité appropriés doit être créé dans Dynamics 365 lui-même.
Point de terminaison API: L'URL de base pour l'API OData de Dynamics 365 Finance and Operations. Le format est généralement https://[your-d365-environment-name].operations.dynamics.com.
Plage de dates: Le script inclut les variables START_DATE et END_DATE. Celles-ci sont utilisées pour filtrer les enregistrements en fonction de leurs dates de création ou de modification afin de gérer le volume de données. Pour les extractions initiales, une période de 3 à 6 mois est recommandée.
Filtre de société: Les données doivent être filtrées par une entité juridique ou une société spécifique. Cela se fait en spécifiant le dataAreaId dans le filtre de requête API, ce qui est une configuration obligatoire dans le script.
Entités de données clés: Le script interroge plusieurs entités OData standard de Dynamics 365, notamment VendorInvoiceRegisterJournalsV2, VendorInvoiceHeaders, VendorPostedInvoices, VendorPaymentJournalLines et VendSettlements. Des entités personnalisées peuvent être requises si le processus standard est fortement modifié.
Pagination: Le script gère automatiquement les réponses paginées de l'API en utilisant la propriété @odata.nextLink pour garantir que tous les enregistrements pour la période spécifiée sont récupérés.

a Exemple de requête python

import os
import pandas as pd
import requests
import msal
import datetime
import time

class=class="hl-string">"hl-comment"># --- Configuration: Update these values --- #
D365_URL = class="hl-string">"https://[your-d365-environment].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]"
COMPANY_ID = class="hl-string">"[your-company-id]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">'USMF'
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"

class=class="hl-string">"hl-comment"># --- End Configuration --- #

RESOURCE = fclass="hl-string">"{D365_URL}/"
AUTHORITY = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
API_BASE_URL = fclass="hl-string">"{D365_URL}/data"

LAST_DATA_UPDATE = datetime.datetime.now(datetime.timezone.utc).isoformat()
SOURCE_SYSTEM = class="hl-string">"Microsoft Dynamics 365"

def get_access_token():
    class="hl-string">"""Acquires an access token from Azure AD."""
    app = msal.ConfidentialClientApplication(
        CLIENT_ID,
        authority=AUTHORITY,
        client_credential=CLIENT_SECRET
    )
    result = app.acquire_token_for_client(scopes=[fclass="hl-string">"{RESOURCE}/.default"])
    if class="hl-string">"access_token" in result:
        return result[class="hl-string">'access_token']
    else:
        print(class="hl-string">"Error acquiring token:", result.get(class="hl-string">"error_description"))
        return None

def fetch_all_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_data = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Prefer': class="hl-string">'odata.include-annotations="*"'
    }
    
    next_link = entity_url
    while next_link:
        try:
            response = requests.get(next_link, headers=headers)
            response.raise_for_status()
            data = response.json()
            all_data.extend(data[class="hl-string">'value'])
            next_link = data.get(class="hl-string">'@odata.nextLink')
            time.sleep(0.1) class=class="hl-string">"hl-comment"># Small delay to respect API limits
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"An error occurred: {e}")
            print(fclass="hl-string">"Response body: {response.text}")
            next_link = None
    return all_data

def main():
    token = get_access_token()
    if not token:
        return

    all_events = []
    cross_company_filter = fclass="hl-string">"cross-company=true&$filter=dataAreaId eq '{COMPANY_ID}'"

    print(class="hl-string">"Fetching 'Invoice Registered' events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceRegisterJournalsV2?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=JournalNumber,CreatedDateTime,InvoiceNumber,VendorAccount,CreatedBy,JournalTotalCredit"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Invoice Registered',
            class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'),
            class="hl-string">'InvoiceAmount': item.get(class="hl-string">'JournalTotalCredit'),
            class="hl-string">'PurchaseOrderNumber': None, class="hl-string">'InvoiceStatus': None, class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching invoice header events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorInvoiceHeaders?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,ModifiedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,InvoiceMatchingStatus,LastMatchingValidationDate,InvoiceLastActionDate,Worker,InvoiceLastAction,DueDate,VendorInvoiceHeaderStatus"
    data = fetch_all_data(token, entity_url)
    for item in data:
        class=class="hl-string">"hl-comment"># Invoice Data Captured (approximated by creation of the header)
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Data Captured', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        class=class="hl-string">"hl-comment"># Invoice Coded (inferred by modification after creation)
        if item.get(class="hl-string">'ModifiedDateTime') != item.get(class="hl-string">'CreatedDateTime'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Coded', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Matching activities
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Passed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Matched To Purchase Order', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        if item.get(class="hl-string">'InvoiceMatchingStatus') == class="hl-string">'Failed' and item.get(class="hl-string">'LastMatchingValidationDate'):
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Found', class="hl-string">'EventTime': item.get(class="hl-string">'LastMatchingValidationDate'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
            class=class="hl-string">"hl-comment"># Matching Discrepancy Handled (inferred if invoice is now matched or posted after a discrepancy)
            if item.get(class="hl-string">'VendorInvoiceHeaderStatus') in [class="hl-string">'Matched', class="hl-string">'Posted'] and item.get(class="hl-string">'ModifiedDateTime') > item.get(class="hl-string">'LastMatchingValidationDate'):
                all_events.append({
                    class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Matching Discrepancy Handled', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'Worker'),
                    class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                    class="hl-string">'InvoiceStatus': item.get(class="hl-string">'VendorInvoiceHeaderStatus'), class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
                })

    print(class="hl-string">"Fetching workflow events...")
    class=class="hl-string">"hl-comment"># This is a simplified workflow extraction. A real scenario might need to query WorkflowTrackingWorkItem and join.
    entity_url = fclass="hl-string">"{API_BASE_URL}/WorkflowTrackingStatusTables?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$filter=contains(Context,'VendInvoice')&$select=ContextRecId,CreatedDateTime,TrackingStatus,User,Context"
    class=class="hl-string">"hl-comment"># Note: Linking ContextRecId back to an InvoiceNumber requires another lookup, which is complex. 
    class=class="hl-string">"hl-comment"># A placeholder is used here. For a real implementation, you must resolve this link.
    class=class="hl-string">"hl-comment"># For this script, we will not generate workflow events to avoid complexity.

    print(class="hl-string">"Fetching posted invoice events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPostedInvoices?{cross_company_filter} and PostedDateTime ge {START_DATE} and PostedDateTime le {END_DATE}&$select=InvoiceNumber,PostedDateTime,VendorAccount,PurchaseOrderNumber,InvoiceAmount,DueDate,Block,ModifiedDateTime,ModifiedBy"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Posted', class="hl-string">'EventTime': item.get(class="hl-string">'PostedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'InvoiceStatus': class="hl-string">'Posted', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
        })
        if item.get(class="hl-string">'Block') not in [None, class="hl-string">'No', class="hl-string">'Free']:
            all_events.append({
                class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Block Set', class="hl-string">'EventTime': item.get(class="hl-string">'ModifiedDateTime'), class="hl-string">'User': item.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccount'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'InvoiceAmount'), class="hl-string">'PurchaseOrderNumber': item.get(class="hl-string">'PurchaseOrderNumber'),
                class="hl-string">'InvoiceStatus': class="hl-string">'Posted (Blocked)', class="hl-string">'PaymentDueDate': item.get(class="hl-string">'DueDate')
            })
        class=class="hl-string">"hl-comment"># Payment Block Released is difficult to capture without audit logs. This is an approximation.

    print(class="hl-string">"Fetching payment schedule events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendorPaymentJournalLines?{cross_company_filter} and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}&$select=InvoiceNumber,CreatedDateTime,CreatedBy,JournalBatchNumber,VendorAccountNumber,Amount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Scheduled', class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'), class="hl-string">'User': item.get(class="hl-string">'CreatedBy'),
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'Amount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Payment Scheduled', class="hl-string">'PaymentDueDate': None
        })

    print(class="hl-string">"Fetching payment execution events...")
    entity_url = fclass="hl-string">"{API_BASE_URL}/VendSettlements?{cross_company_filter} and SettlementDate ge {START_DATE} and SettlementDate le {END_DATE}&$select=InvoiceNumber,SettlementDate,VendorAccountNumber,SettlementAmount"
    data = fetch_all_data(token, entity_url)
    for item in data:
        all_events.append({
            class="hl-string">'InvoiceNumber': item.get(class="hl-string">'InvoiceNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Executed', class="hl-string">'EventTime': item.get(class="hl-string">'SettlementDate'), class="hl-string">'User': None, class=class="hl-string">"hl-comment"># User not available in this entity
            class="hl-string">'VendorNumber': item.get(class="hl-string">'VendorAccountNumber'), class="hl-string">'InvoiceAmount': item.get(class="hl-string">'SettlementAmount'), class="hl-string">'PurchaseOrderNumber': None,
            class="hl-string">'InvoiceStatus': class="hl-string">'Paid', class="hl-string">'PaymentDueDate': None
        })

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

    print(class="hl-string">"Processing and saving data...")
    df = pd.DataFrame(all_events)
    df[class="hl-string">'SourceSystem'] = SOURCE_SYSTEM
    df[class="hl-string">'LastDataUpdate'] = LAST_DATA_UPDATE
    df[class="hl-string">'EndTime'] = df[class="hl-string">'EventTime']
    df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)

    output_filename = class="hl-string">'d365_invoice_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")

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

Étapes

Naviguer vers l'espace de travail Gestion des données: Connectez-vous à Microsoft Dynamics 365 Finance. Utilisez la barre de recherche pour trouver et naviguer vers l'espace de travail Gestion des données.
Créer un nouveau projet d'exportation: Dans l'espace de travail, sélectionnez la tuile Exporter pour créer un nouveau projet d'exportation de données. Donnez un nom significatif au projet, par exemple, ProcessMind_Invoice_Processing_Export.
Définir le projet de données: Dans l'onglet Général du nouveau projet, spécifiez le Format des données. CSV est un format couramment utilisé et recommandé. Définissez les autres paramètres selon vos besoins.
Ajouter les entités de données requises: Allez dans la section Entités sélectionnées et cliquez sur Ajouter une entité. Recherchez et ajoutez les entités principales suivantes une par une. Vous devrez spécifier le format de données cible pour chacune.
- VendInvoiceInfoTableEntity (En-tête de facture fournisseur)
- VendInvoiceTransEntity (Lignes de facture fournisseur)
- VendInvoiceRegisterHeaderEntity (En-tête de journal de registre des factures)
- WorkflowTrackingStatusTableEntity (Historique de workflow)
- AccountingDistributionEntity (Distributions GL)
- VendInvoiceJour (Factures fournisseurs publiées)
- VendTrans (Transactions fournisseurs, pour les blocages de paiement)
- LedgerJournalTransVendPaymEntity (Lignes de journal de paiement fournisseur)
- VendSettlement (Transactions de règlement fournisseur)
Appliquer des filtres: Pour chaque entité, il est essentiel d'appliquer des filtres pour limiter la portée des données. Sélectionnez une entité et cliquez sur Filtrer. Au minimum, filtrez par Société (Entité juridique) et une plage de dates spécifique sur un champ de date pertinent comme CREATEDDATETIME ou INVOICEDATE. Une plage typique pour l'analyse initiale est les 3 à 6 derniers mois.
Configurer les mappages d'entités: Pour chaque entité, révisez le mappage source-cible. Assurez-vous que tous les champs requis pour l'Event Log final sont inclus dans l'exportation. Aucune modification de mappage complexe n'est généralement nécessaire à ce stade.
Exécuter la tâche d'exportation: Une fois toutes les entités ajoutées et filtrées, cliquez sur Exporter dans le volet d'action pour démarrer la tâche. Vous pouvez l'exécuter immédiatement ou la planifier pendant les heures creuses pour minimiser la charge système.
Télécharger les données exportées: Une fois la tâche d'exportation terminée avec succès, accédez à l'historique des tâches. De là, vous pouvez télécharger le package de données exporté, qui contiendra des fichiers distincts pour chaque entité de données.
Transformer les données en Event Log: Les fichiers exportés sont des instantanés d'entités, et non un Event Log consolidé. Vous devez utiliser un outil externe comme une base de données, un script Python ou Power Query pour traiter et combiner ces fichiers. La requête conceptuelle dans la section query fournit la logique complète de cette transformation.
Exécuter la logique de transformation: Chargez les fichiers CSV exportés dans votre environnement de transformation choisi. Exécutez la requête de transformation fournie, qui unit les données de tous les fichiers source pour créer une seule table Event Log avec une ligne par activité métier.
Finaliser et télécharger: Exportez les données transformées finales dans un seul fichier CSV. Assurez-vous que les en-têtes de colonnes correspondent aux exigences, par exemple, InvoiceNumber, ActivityName, EventTime. Ce fichier est maintenant prêt à être téléchargé dans ProcessMind.

Configuration

Entités de données: Le cœur de la configuration consiste à sélectionner l'ensemble d'entités approprié pour couvrir le cycle de vie des factures. Les entités clés incluent VendInvoiceInfoTableEntity, VendInvoiceJour et WorkflowTrackingStatusTableEntity.
Format d'exportation des données: Sélectionnez CSV comme format de données cible pour faciliter le traitement lors des étapes de transformation ultérieures.
Filtrage par société: Il est crucial de filtrer chaque entité de données par l'entité juridique (Société) spécifique que vous analysez afin d'éviter d'extraire des données non pertinentes.
Filtrage par plage de dates: Appliquez un filtre de plage de dates cohérent à toutes les entités pertinentes, telles que VendInvoiceInfoTableEntity et VendInvoiceJour, basé sur les dates de création ou de publication. Commencez par une période récente, par exemple les 6 derniers mois, pour gérer le volume de données.
Exportation complète vs. Incrémentielle: Pour l'extraction initiale, effectuez une exportation complète. Pour les actualisations ultérieures, vous pouvez configurer une exportation incrémentielle pour récupérer uniquement les données qui ont changé depuis la dernière exécution, ce qui réduit le temps de traitement.
Prérequis: L'utilisateur qui exécute l'exportation doit disposer des rôles de sécurité appropriés dans Dynamics 365, généralement incluant Data management administrator ou un rôle similaire avec les permissions d'accès aux entités de données requises.

a Exemple de requête config

/*
-- This is a conceptual query to be executed in a database or data transformation tool.
-- The tables referenced (e.g., 'VendInvoiceInfoTableEntity') are the CSV files exported from Dynamics 365.
-- Replace '[Your_Source_System_Name]' with the actual source system identifier.
*/

-- 1. Invoice Registered
SELECT
    h.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Registered' AS "ActivityName",
    h.CREATEDDATETIME AS "EventTime",
    h.CREATEDBY AS "User",
    h.INVOICEACCOUNT AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    h.INVOICEAMOUNT AS "InvoiceAmount",
    NULL AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    h.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceRegisterHeaderEntity h

UNION ALL

-- 2. Invoice Data Captured
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Data Captured' AS "ActivityName",
    i.CREATEDDATETIME AS "EventTime",
    i.CREATEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i

UNION ALL

-- 3. Invoice Coded
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Coded' AS "ActivityName",
    MIN(a.CREATEDDATETIME) AS "EventTime",
    MIN(a.CREATEDBY) AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Pending' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    MIN(a.CREATEDDATETIME) AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
JOIN AccountingDistributionEntity a ON i.INVOICENUMBER = a.SOURCEDOCUMENTLINE_INVOICENUMBER
GROUP BY i.INVOICENUMBER, i.VENDORACCOUNT, i.PURCHASEORDERNUMBER, i.INVOICEAMOUNT

UNION ALL

-- 4. Invoice Matched To Purchase Order
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Invoice Matched To Purchase Order' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed'

UNION ALL

-- 5. Matching Discrepancy Found
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Found' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Discrepancy' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Failed'

UNION ALL

-- 6. Matching Discrepancy Handled (Approximation)
SELECT
    i.INVOICENUMBER AS "InvoiceNumber",
    'Matching Discrepancy Handled' AS "ActivityName",
    i.MODIFIEDDATETIME AS "EventTime",
    i.MODIFIEDBY AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    'Matched' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    i.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceInfoTableEntity i
WHERE i.LASTMATCHSTATUS = 'Passed' AND i.MODIFIEDDATETIME > i.CREATEDDATETIME

UNION ALL

-- 7. Invoice Sent For Approval, 8. Invoice Approved, 9. Invoice Rejected
SELECT
    w.CONTEXT_INVOICENUMBER AS "InvoiceNumber",
    CASE w.TRACKINGSTATUS
        WHEN 'Submitted' THEN 'Invoice Sent For Approval'
        WHEN 'Completed' THEN 'Invoice Approved'
        WHEN 'Canceled' THEN 'Invoice Rejected'
        ELSE CONCAT('Workflow: ', w.TRACKINGSTATUS)
    END AS "ActivityName",
    w.CREATEDDATETIME AS "EventTime",
    w.USERID AS "User",
    i.VENDORACCOUNT AS "VendorNumber",
    i.PURCHASEORDERNUMBER AS "PurchaseOrderNumber",
    i.INVOICEAMOUNT AS "InvoiceAmount",
    w.TRACKINGSTATUS AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    w.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM WorkflowTrackingStatusTableEntity w
JOIN VendInvoiceInfoTableEntity i ON w.CONTEXT_RECID = i.RECID AND w.CONTEXT_TABLEID = i.TABLEID
WHERE w.TRACKINGTYPE = 'Approval'

UNION ALL

-- 10. Payment Block Set
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Set' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Blocked' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'Yes'

UNION ALL

-- 11. Payment Block Released
SELECT
    v.INVOICENUMBER AS "InvoiceNumber",
    'Payment Block Released' AS "ActivityName",
    v.MODIFIEDDATETIME AS "EventTime",
    v.MODIFIEDBY AS "User",
    v.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    v.AMOUNT AS "InvoiceAmount",
    'Open' AS "InvoiceStatus",
    v.DUEDATE AS "PaymentDueDate",
    v.MODIFIEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendTrans v
WHERE v.BLOCKED = 'No' AND v.MODIFIEDDATETIME > v.CREATEDDATETIME

UNION ALL

-- 12. Invoice Posted
SELECT
    vj.INVOICENUM AS "InvoiceNumber",
    'Invoice Posted' AS "ActivityName",
    vj.POSTINGDATE AS "EventTime",
    vj.CREATEDBY AS "User",
    vj.INVOICEACCOUNT AS "VendorNumber",
    vj.PURCHID AS "PurchaseOrderNumber",
    vj.INVOICEAMOUNT AS "InvoiceAmount",
    'Posted' AS "InvoiceStatus",
    vj.DUEDATE AS "PaymentDueDate",
    vj.POSTINGDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendInvoiceJour vj

UNION ALL

-- 13. Payment Scheduled
SELECT
    l.INVOICENUMBER AS "InvoiceNumber",
    'Payment Scheduled' AS "ActivityName",
    l.CREATEDDATETIME AS "EventTime",
    l.CREATEDBY AS "User",
    l.ACCOUNTDISPLAYVALUE AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    l.DEBITAMOUNT + l.CREDITAMOUNT AS "InvoiceAmount",
    'Scheduled for Payment' AS "InvoiceStatus",
    l.DUEDATE AS "PaymentDueDate",
    l.CREATEDDATETIME AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM LedgerJournalTransVendPaymEntity l

UNION ALL

-- 14. Payment Executed
SELECT
    vs.INVOICENUMBER AS "InvoiceNumber",
    'Payment Executed' AS "ActivityName",
    vs.TRANSDATE AS "EventTime",
    vs.CREATEDBY AS "User",
    vs.ACCOUNTNUM AS "VendorNumber",
    NULL AS "PurchaseOrderNumber",
    vs.SETTLEMENTAMOUNT AS "InvoiceAmount",
    'Paid' AS "InvoiceStatus",
    NULL AS "PaymentDueDate",
    vs.TRANSDATE AS "EndTime",
    '[Your_Source_System_Name]' AS "SourceSystem",
    GETUTCDATE() AS "LastDataUpdate"
FROM VendSettlement vs;

Votre modèle de données Achats à la Payer - Traitement des Factures

Votre modèle de données Achats à la Payer - Traitement des Factures

Achats au Paiement – Attributs de traitement des factures

Achats au Paiement – Activités de traitement des factures

Guides d'extraction

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

Étapes

Configuration

a Exemple de requête config

Requête SQL directe via Bring Your Own Database (BYOD)

É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 de flux de données Microsoft Power Platform

Étapes

Configuration

a Exemple de requête config

Prêt(e) à démarrer ?

Commencez dès aujourd'hui à optimiser votre processus Achats au Paiement – Traitement des factures

Votre modèle de données Achats à la Payer - Traitement des Factures

Votre modèle de données Achats à la Payer - Traitement des Factures

Achats au Paiement – Attributs de traitement des factures

Achats au Paiement – Activités de traitement des factures

Guides d'extraction

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

Étapes

Configuration

a Exemple de requête config

Requête SQL directe via Bring Your Own Database (BYOD)

É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 de flux de données Microsoft Power Platform

Étapes

Configuration

a Exemple de requête config

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Commencez dès aujourd'hui à optimiser votre processus Achats au Paiement – Traitement des factures