> Amélioration continue des processus > Order to Cash Facturation > `Microsoft Dynamics 365` > Modèle de données

Votre Template de Données Order to Cash - Facturation

Microsoft Dynamics 365

Attributs Order to Cash - Facturation (18) Activités Order to Cash - Facturation (12) Guides d'extraction (2)

Votre Template de Données Order to Cash - Facturation

Ce template fournit une feuille de route claire pour la collecte des points de données essentiels nécessaires à l'analyse de votre processus Order to Cash - Facturation. Vous y trouverez les attributs recommandés à inclure dans votre journal d'événements, les activités clés à suivre et des conseils pratiques pour extraire ces informations. Il est conçu pour vous aider à préparer rapidement vos données pour un Process Mining pertinent.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction pour 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

Attributs Order to Cash - Facturation

Ce sont les champs de données recommandés à inclure dans votre journal d'événements pour une analyse complète de l'Order to Cash - Facturation.

3 Obligatoire 6 Recommandé 9 Facultatif

	Nom	Description
	Numéro de facture InvoiceNumber	L'identifiant unique pour chaque facture client, servant d'identifiant de cas principal pour le processus de facturation.
Description Le numéro de facture est la clé centrale qui regroupe toutes les activités liées à un seul document de facturation. Il permet une analyse complète, de bout en bout, du cycle de vie de la facture, de la génération et de l'approbation au paiement client et à la clôture finale. En l'utilisant comme identifiant de cas (Case ID), chaque entrée du journal d'événements correspond à une facture spécifique, permettant une analyse détaillée des variantes, le calcul des temps de cycle et le suivi des performances pour chaque transaction de facturation. Pourquoi c'est important Cet attribut est essentiel pour suivre le cycle de vie complet d'une facture, permettant l'analyse de l'efficacité des processus, des goulots d'étranglement et des écarts pour chaque document de facturation individuel. Où obtenir Ceci se trouve généralement dans le module Ventes et marketing, au sein de tables comme CustInvoiceJour (champ InvoiceId) ou exposé via des entités de données comme SalesInvoiceHeaderV2. Exemples CIV-001254INV-2023-9876US-004321
	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'Heure de l'événement, également appelée horodatage, enregistre la date et l'heure exactes pour chaque activité du processus. Ces données sont essentielles pour toutes les analyses de Process Mining basées sur le temps. Elles sont utilisées pour calculer les temps de cycle entre les activités, mesurer la durée totale d'un cas et comprendre la performance du processus au fil du temps. Des horodatages précis et fiables sont le fondement des KPI tels que le délai moyen de recouvrement et le temps de génération des factures. Pourquoi c'est important Ceci est l'attribut fondamental pour toutes les analyses de performance et de temps, permettant le calcul des temps de cycle, des durées et du débit pour mesurer l'efficacité du processus. Où obtenir Les horodatages proviennent de divers champs de date et d'heure dans différentes tables de Dynamics 365, tels que CreatedDateTime sur la table CustInvoiceJour pour la génération de factures, ou des horodatages spécifiques de l'historique de workflow. Exemples 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Nom de l'activité ActivityName	Le nom de l'activité commerciale ou de l'événement qui s'est produit à un point spécifique du cycle de vie de la facture.
Description Cet attribut décrit une étape ou un jalon spécifique au sein du processus de facturation, tel que 'Facture Générée', 'Facture Approuvée' ou 'Paiement Client Reçu'. La séquence de ces activités forme le flux de processus. L'analyse des activités est fondamentale pour le Process Mining, car elle permet la découverte de modèles de processus, l'identification des variantes et la mesure des performances entre les différentes étapes. Pourquoi c'est important Il définit les étapes du processus, permettant la visualisation des cartographies de processus, l'analyse des variantes de processus et l'identification des goulots d'étranglement ou des écarts par rapport à la procédure standard. Où obtenir Cet attribut est généralement dérivé de plusieurs sources, telles que les champs de changement de statut (par exemple, DocumentState), les champs de date spécifiques renseignés ou les journaux d'historique de workflow au sein de Microsoft Dynamics 365. Exemples Facture généréeFacture approuvéePaiement client reçuAvoir Émis
	Date d'échéance du paiement PaymentDueDate	La date à laquelle le client est censé payer la facture.
Description La date d'échéance de paiement (Payment Due Date) est un champ de date critique calculé en fonction de la date de facture et des conditions de paiement du client. Elle sert de référence pour mesurer la ponctualité des paiements. Cet attribut est essentiel pour le dashboard 'Analyse de l'Adhérence aux Conditions de Paiement' et pour le calcul de KPIs tels que le 'Taux de Paiement à Temps' et le 'Days Sales Outstanding'. La comparaison de cette date avec la date de paiement réelle révèle le comportement de paiement des clients et l'efficacité du processus de recouvrement. Pourquoi c'est important Ceci est le point de référence pour mesurer la performance des paiements. C'est essentiel pour calculer les taux de paiement à temps et analyser l'adhérence aux conditions de paiement des clients. Où obtenir Ceci se trouve généralement dans la table CustInvoiceJour dans un champ comme DueDate. Exemples 2023-05-152023-06-302023-07-01
	Département Department	Le service commercial associé à l'utilisateur ou à l'activité.
Description Cet attribut assigne une activité ou un utilisateur à un département organisationnel spécifique, tel que 'Comptes Clients' ou 'Ventes'. Il permet une vue de la performance des processus à un niveau supérieur à celui de l'utilisateur individuel. L'analyse par département aide à comprendre les transferts interfonctionnels, à comparer l'efficacité entre les équipes et à identifier les goulots d'étranglement au niveau du département, comme requis par le dashboard 'Charge d'Activité du Département de Facturation'. Pourquoi c'est important Permet une analyse des performances au niveau organisationnel, en comparant l'efficacité entre différentes équipes et en comprenant comment les transferts interdépartementaux impactent le processus. Où obtenir Ceci n'est généralement pas un champ direct sur la transaction de facture. Il est dérivé en joignant l'ID UserResponsible avec le répertoire des employés ou des utilisateurs qui contient les informations de département. Exemples Créances ClientsFinanceOpérations de Facturation
	Montant de la facture InvoiceAmount	La valeur monétaire totale de la facture.
Description Cet attribut représente le montant total dû sur la facture. C'est une métrique critique pour l'analyse financière, permettant la segmentation des factures par valeur. Par exemple, les analystes peuvent se concentrer sur les factures de grande valeur pour comprendre leurs comportements de paiement ou identifier si les factures plus importantes nécessitent des temps d'approbation plus longs. Il est également fondamental pour calculer la valeur totale des factures en souffrance et pour les calculs de DSO. Pourquoi c'est important Il permet une analyse d'impact financier, vous permettant de filtrer et de segmenter les processus par valeur monétaire afin de prioriser les factures de grande valeur et de comprendre leurs comportements de processus spécifiques. Où obtenir Trouvé dans la table CustInvoiceJour, généralement dans un champ comme InvoiceAmount. Également disponible dans les tables de transactions associées. Exemples 5430.5012500.00750.25
	Nom du client CustomerName	Le nom du client à qui la facture a été émise.
Description Le nom du client fournit un identifiant lisible pour l'entreprise ou l'individu facturé. Dans l'analyse de Process Mining, cela permet de segmenter le processus de facturation par client. Cela peut révéler quels clients paient constamment à temps, lesquels sont fréquemment en retard, ou si certains groupes de clients rencontrent des variations de processus ou des retards uniques. C'est essentiel pour les dashboards liés au comportement de paiement des clients et à l'analyse du Days Sales Outstanding. Pourquoi c'est important Cela permet de segmenter l'analyse des processus par client, aidant à identifier les comportements spécifiques aux clients, les schémas de paiement ou les problèmes de processus. Où obtenir Ces informations sont récupérées en joignant les données de facture avec la table de données maître client, typiquement CustTable, basée sur le numéro de compte client. Exemples Contoso Ltée.Fabrikam, Inc.Northwind Traders
	Statut de la facture InvoiceStatus	Le statut actuel de la facture dans son cycle de vie (par exemple, Ouverte, Payée, Annulée).
Description Cet attribut fournit un aperçu de l'état actuel de la facture. Il indique si une facture est toujours en attente de paiement, a été entièrement payée, est en souffrance ou a été annulée via une note de crédit. Ceci est utile pour filtrer les cas afin d'analyser uniquement les factures ouvertes ou de confirmer le résultat final d'une facture clôturée. Cela aide à comprendre la charge de travail actuelle et la situation financière des créances. Pourquoi c'est important Fournit un aperçu rapide de l'état actuel de la facture, utile pour filtrer les cas et comprendre les résultats des différentes variantes de processus. Où obtenir Ceci peut être dérivé du statut de paiement de la facture, souvent en vérifiant si le solde du registre CustTrans associé est nul. Il n'y a pas toujours un seul champ de 'statut'. Exemples OuvertPayéEn retardAnnulé
	Utilisateur Responsable UserResponsible	L'utilisateur ou l'employé responsable de l'exécution d'une activité spécifique.
Description Cet attribut identifie l'individu qui a effectué une tâche particulière dans le processus de facturation, comme l'approbation d'une facture ou l'affectation des espèces. Il est crucial pour l'analyse de la charge de travail, la comparaison des performances et l'identification des besoins en formation. Par exemple, le dashboard 'Charge d'Activité du Département de Facturation' s'appuie sur cet attribut pour voir si le travail est réparti équitablement ou si certains utilisateurs sont des goulots d'étranglement. Il aide également à comprendre l'allocation des ressources et l'efficacité. Pourquoi c'est important Il permet une analyse au niveau des ressources, aidant à identifier les goulots d'étranglement, à mesurer la performance individuelle ou d'équipe et à analyser la répartition de la charge de travail au sein du service de facturation. Où obtenir Ceci peut être obtenu à partir des journaux d'historique de workflow (par exemple, WorkflowTrackingStatusTable) ou des champs de propriété comme Owner ou ModifiedBy sur les tables pertinentes. Exemples John SmithAlicia BakerAdministrateur système
	Conditions de paiement PaymentTerms	Les conditions de paiement convenues pour une facture (par exemple, Net 30, Net 60).
Description Les conditions de paiement définissent les règles relatives au moment où un client est censé payer une facture. Cet attribut est utilisé pour calculer la date d'échéance de paiement et constitue une dimension clé pour l'analyse du comportement de paiement. Le dashboard 'Analyse de l'Adhérence aux Conditions de Paiement' utilise cet attribut pour regrouper les clients et les factures afin de déterminer si certaines conditions de paiement sont plus ou moins efficaces ou sont associées à des taux plus élevés de paiements en retard. Pourquoi c'est important Il fournit le contexte expliquant pourquoi une facture est due à une certaine date et permet de segmenter l'analyse pour voir si certaines conditions de paiement sont corrélées à des retards de paiement. Où obtenir Ceci est généralement stocké sur l'enregistrement maître client mais copié dans l'en-tête de la facture. Recherchez un champ Payment ou PaymTermId sur la table CustInvoiceJour. Exemples Net 30Net 60Dû à réception
	Délai moyen de recouvrement DaysSalesOutstanding	Le nombre de jours entre la génération de la facture et la réception du paiement client.
Description Le délai moyen de recouvrement (DSO) est un indicateur financier clé qui mesure le nombre moyen de jours nécessaires à une entreprise pour encaisser un paiement après une vente. Cet attribut calculé détermine cette durée pour chaque facture individuelle. C'est la métrique principale pour le tableau de bord « Analyse des tendances du délai moyen de recouvrement » et l'indicateur clé de performance « DSO ». L'analyse du DSO aide à gérer la trésorerie et à évaluer l'efficacité de la fonction de crédit et de recouvrement. Pourquoi c'est important Ceci est un KPI critique pour mesurer la santé du flux de trésorerie d'une entreprise et l'efficacité de son processus de recouvrement. Il quantifie la rapidité avec laquelle les revenus sont convertis en espèces. Où obtenir Cet attribut n'est pas dans le système source. Il est calculé comme la durée entre l'activité 'Facture Générée' et l'activité 'Paiement Client Reçu'. Exemples 284592
	Dernière mise à jour des données LastDataUpdate	L'horodatage indiquant la dernière fois que les données de cet événement ont été actualisées à partir du système source.
Description Cet attribut enregistre la dernière extraction ou mise à jour des données de Microsoft Dynamics 365. C'est un champ de métadonnées crucial pour comprendre la fraîcheur des données analysées. Il aide les analystes et les utilisateurs métier à savoir s'ils consultent les informations les plus récentes et est essentiel pour gérer les plannings d'actualisation des données et garantir la fiabilité de l'analyse. Pourquoi c'est important Il garantit que les utilisateurs comprennent la fraîcheur des données, ce qui est essentiel pour la gouvernance des données, la gestion de l'actualisation des dashboards et la fiabilité des insights. Où obtenir Cet attribut est généré et horodaté sur l'ensemble de données pendant le processus d'extraction, de transformation et de chargement (ETL) des données. Exemples 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	Devise Currency	Le code de la devise du montant de la facture (par exemple, USD, EUR).
Description Cet attribut spécifie la devise dans laquelle le montant de la facture est libellé. Il est essentiel pour les organisations multinationales qui traitent différentes devises. Sans ce contexte, l'agrégation ou la comparaison des montants de factures serait dénuée de sens. Il permet une conversion de devises appropriée et des rapports financiers et analyses précis dans différentes régions. Pourquoi c'est important Il fournit un contexte essentiel pour toute métrique financière comme le montant de la facture, prévenant les agrégations incorrectes et permettant une analyse précise dans des environnements multi-devises. Où obtenir Trouvé dans la table CustInvoiceJour, généralement dans un champ comme CurrencyCode. Exemples USDEURGBP
	Est un retravail IsRework	Un indicateur signalant si le processus de facturation a impliqué des activités de retravail, telles que des approbations multiples.
Description Ceci est un attribut booléen calculé qui signale les factures ayant subi un retravail. Le retravail peut être défini comme ayant plusieurs événements 'Facture Approuvée' ou des annulations de paiements. Cet attribut est spécifiquement conçu pour soutenir le dashboard 'Analyse du Retravail des Factures' et le KPI 'Taux de Retravail des Factures'. En isolant ces cas, les analystes peuvent investiguer les causes profondes du retravail, qui souvent indiquent des inefficacités de processus, des problèmes de qualité des données ou des lacunes de formation. Pourquoi c'est important Cet indicateur quantifie directement l'inefficacité des processus en identifiant les cas avec des actions répétitives ou correctives, aidant à cibler les causes profondes du gaspillage et des retards. Où obtenir Cet attribut n'est pas disponible dans le système source. Il est calculé dans la couche de transformation des données en recherchant les activités répétées ou les modèles de retravail spécifiques au sein d'un cas. Exemples truefaux
	Nécessite une Intervention Manuelle RequiresManualIntervention	Un indicateur signalant si un paiement a nécessité un ajustement manuel lors de l'application des paiements.
Description Cet attribut booléen signale les paiements qui ont nécessité une intervention ou une correction manuelle pendant le processus d'affectation des paiements. Ceci est essentiel pour le KPI 'Taux d'Écart d'Affectation des Paiements', car il aide à quantifier la précision et le niveau d'automatisation de la validation des paiements. L'identification des raisons de l'intervention manuelle, telles que des informations de virement manquantes ou des écarts de paiement, peut conduire à des améliorations de processus qui augmentent les taux de traitement direct. Pourquoi c'est important Cet attribut aide à identifier les frictions de processus et les inexactitudes dans l'étape d'affectation des paiements, ce qui est crucial pour améliorer l'automatisation et réduire l'effort manuel. Où obtenir Ces informations peuvent être déduites de l'utilisateur qui a validé le paiement (si ce n'est pas un utilisateur système) ou de codes de motif spécifiques utilisés lors du rapprochement des paiements. Consultez la documentation de Microsoft Dynamics 365. Exemples truefaux
	Numéro de commande de vente SalesOrderNumber	L'identifiant de la commande client qui a généré la facture.
Description Le numéro de commande client relie le processus de facturation au processus de vente précédent. Cette connexion est inestimable pour une analyse Order-to-Cash plus large et de bout en bout. Elle permet aux analystes d'étudier comment les problèmes dans le processus de vente et d'exécution, tels que les modifications de commande ou les retards d'expédition, pourraient impacter le cycle de facturation. Par exemple, elle peut aider à répondre à des questions comme 'Les factures issues de commandes client complexes mettent-elles plus de temps à être payées ?'. Pourquoi c'est important Cet attribut relie le processus de facturation au processus de vente en amont, permettant une analyse Order-to-Cash de bout en bout plus complète pour identifier les causes profondes des problèmes de facturation. Où obtenir Trouvé sur l'en-tête ou les détails de la ligne de facture, renvoyant à la commande client. Recherchez un champ comme SalesId sur la table CustInvoiceJour. Exemples SO-009876SO-010234US-SO-00543
	Paiement à Temps IsOnTimePayment	Un indicateur signalant si le paiement client a été reçu à la date d'échéance ou avant.
Description Cet attribut booléen calculé compare l'horodatage 'Paiement Client Reçu' avec la 'Date d'Échéance de Paiement'. Il signale chaque facture comme étant payée à temps ou en retard. C'est le composant principal pour le calcul du KPI 'Taux de Paiement à Temps' et il est largement utilisé dans le dashboard 'Analyse de l'Adhérence aux Conditions de Paiement'. Il fournit un résultat binaire clair pour la performance de paiement, simplifiant l'analyse et le reporting. Pourquoi c'est important Mesure directement le respect des conditions de paiement par le client et sert de base à l'indicateur clé de performance (KPI) du taux de paiement à temps, simplifiant l'analyse de l'efficacité du recouvrement. Où obtenir Cet attribut n'est pas dans le système source. Il est calculé lors de la transformation des données en comparant la date de paiement à la PaymentDueDate. Exemples truefaux
	Système source SourceSystem	Le système d'où les données ont été extraites.
Description Cet attribut identifie l'origine des données du processus. Dans ce contexte, il spécifie que les données proviennent de Microsoft Dynamics 365. Ceci est important dans les environnements multi-systèmes pour différencier les sources de données et garantir une traçabilité claire des données, ce qui facilite la validation des données et le dépannage. Pourquoi c'est important Il fournit un contexte crucial sur l'origine des données, ce qui est essentiel pour la gouvernance des données, la validation et lors de la fusion de données provenant de plusieurs systèmes d'entreprise. Où obtenir C'est une valeur statique ajoutée pendant le processus d'extraction et de transformation des données pour étiqueter l'origine de l'ensemble de données. Exemples Microsoft Dynamics 365 FinanceD365 F&O

Obligatoire Recommandé Facultatif

Activités Order to Cash - Facturation

Ce sont les `étapes clés` du `processus` et les `jalons` à capturer dans votre `Event Log` pour une `découverte` et une `analyse` précises des `processus`.

7 Recommandé 5 Facultatif

	Activité	Description
	Date d'Échéance de Paiement Atteinte	Un événement calculé qui se produit lorsque la date d'échéance de la facture est atteinte sans que le paiement ne soit entièrement appliqué. Cette activité ne correspond pas à une transaction dans le système, mais est dérivée de données existantes.
Pourquoi c'est important Cet événement est crucial pour analyser les taux de paiement à temps et identifier les factures qui deviennent en souffrance. Il agit comme un point de déclenchement pour les activités de recouvrement et de relance. Où obtenir Ceci n'est pas enregistré comme un événement. Il est calculé en utilisant le champ DueDate de la table CustInvoiceJour. L'horodatage de l'événement est la date d'échéance elle-même. Capture Créer un événement où l'horodatage est la valeur du champ CustInvoiceJour.DueDate. Type d'événement calculated
	Encaissement appliqué à la facture	Représente le règlement d'un paiement client sur une facture spécifique, réduisant le solde impayé de la facture. Il s'agit d'une étape distincte dans Dynamics 365 qui lie la transaction de paiement à la transaction de facture.
Pourquoi c'est important Ceci est un jalon critique pour calculer précisément le DSO et comprendre l'efficacité de l'équipe d'affectation des paiements. Il marque le point où le paiement est entièrement rapproché de ce qui a été facturé. Où obtenir Enregistré dans la table CustSettlement. Le champ de date de règlement de cette table fournit l'horodatage du moment où un paiement spécifique a été appliqué à une transaction de facture spécifique. Capture Utilisez TransDate ou CreatedDateTime de la table CustSettlement. Type d'événement explicit
	Facture approuvée	Marque l'achèvement du processus de révision interne, où la facture est formellement approuvée. Cet événement est enregistré par le système de workflow de Dynamics 365 et signifie que la facture est prête à être envoyée au client.
Pourquoi c'est important Ceci est un jalon clé pour mesurer le temps de cycle d'approbation. Les retards à ce stade peuvent directement augmenter le temps total pour recevoir le paiement du client. Où obtenir Enregistré dans les tables d'historique de workflow, telles que WorkflowTrackingStatusTable, comme une étape d'achèvement ou d'approbation pour l'instance de workflow de facture spécifique. Capture Extraire les journaux d'événements de workflow où le statut est 'Approuvé' ou 'Terminé'. Type d'événement explicit
	Facture clôturée	Cette activité marque l'état final d'une facture, où son solde est nul car elle a été entièrement payée ou réglée avec des notes de crédit. Il ne s'agit pas d'une transaction directe mais d'un état déduit basé sur le statut financier de la facture.
Pourquoi c'est important Cet événement signifie l'achèvement réussi du cycle Order to Cash pour une seule facture. Le temps nécessaire pour atteindre cet état est une mesure principale de l'efficacité globale du processus. Où obtenir Déduit en vérifiant si la transaction de facture dans la table CustTrans a un solde restant de zéro. Cela est déterminé en comparant le montant de la facture au montant total réglé. Capture Dériver des enregistrements CustTrans où AmountCur est égal à SettleAmountCur. L'horodatage est la date du dernier règlement. Type d'événement inferred
	Facture Envoyée au Client	Cette activité représente le moment où la facture a été transmise au client, soit électroniquement, soit physiquement. Dans Dynamics 365, cela peut être un événement explicite si envoyé par e-mail système, ou déduit comme se produisant au moment de la validation si aucun suivi spécifique n'est activé.
Pourquoi c'est important Mesure l'efficacité du processus de livraison des factures. Un délai entre l'approbation et l'envoi de la facture prolonge inutilement le cycle de paiement. Où obtenir Peut être explicitement capturé à partir des journaux d'e-mails comme SysOutgoingEmailTable si les capacités d'e-mail de D365 sont utilisées. Sinon, il est souvent déduit comme étant le même que l'heure d'enregistrement de la facture à partir de CustInvoiceJour. Capture Utilisez l'horodatage du journal d'e-mail si disponible ; sinon, utilisez l'horodatage de validation de la facture. Type d'événement inferred
	Facture générée	Représente la création et la validation du document de facture de vente dans le système. Il s'agit d'une transaction explicite dans Dynamics 365 qui crée un document légal et des écritures financières dans le sous-grand livre des comptes clients.
Pourquoi c'est important Ceci est le début officiel du cycle de vie de la facturation pour une facture. C'est un événement critique pour le suivi du Days Sales Outstanding (DSO) et de la durée globale du processus. Où obtenir Capturé à partir de l'horodatage de création de l'enregistrement de facture de vente comptabilisée dans la table CustInvoiceJour. Les transactions financières correspondantes sont créées dans les tables GeneralJournalEntry et LedgerEntry lors de l'enregistrement. Capture Utilisez le champ CreatedDateTime de la table CustInvoiceJour pour la facture validée. Type d'événement explicit
	Paiement client reçu	Cette activité marque la création d'une écriture de journal pour enregistrer un paiement reçu d'un client. Elle signifie que les espèces ont été reçues, mais qu'elles n'ont pas encore été appliquées à une facture spécifique.
Pourquoi c'est important Ceci est le point de départ pour mesurer le délai d'affectation des espèces. Il différencie la réception de l'argent de son rapprochement effectif avec les factures en souffrance. Où obtenir Capturé à partir de la création ou de l'enregistrement d'un journal de paiement client. Ceci est enregistré dans des tables comme LedgerJournalTrans, qui crée ensuite une transaction client dans CustTrans lors de l'enregistrement. Capture Utilisez l'horodatage de validation du journal de paiement client de LedgerJournalTable. Type d'événement explicit
	Avoir Émis	Représente la création d'une note de crédit ou d'un avoir, généralement pour corriger une erreur de facturation, accorder un ajustement de prix ou comptabiliser des marchandises retournées. Une note de crédit est essentiellement une facture négative.
Pourquoi c'est important Des notes de crédit fréquentes peuvent indiquer des problèmes systémiques dans le processus d'exécution des commandes ou de facturation. Analyser pourquoi les notes de crédit sont émises est essentiel pour l'amélioration des processus et la réduction des fuites de revenus. Où obtenir Ceci est une transaction explicite, enregistrée comme une nouvelle facture validée avec un montant négatif dans la table CustInvoiceJour. Elle est souvent liée à la facture originale via un champ de référence. Capture Identifiez les enregistrements dans CustInvoiceJour avec un montant total négatif et liez-les à la facture originale. Type d'événement explicit
	Commande Client Exécutée	Cette activité marque le point où les marchandises ont été expédiées ou les services rendus pour une commande client, déclenchant le processus de facturation. Elle est généralement déduite de la validation d'un bon de livraison ou d'une note de livraison dans Microsoft Dynamics 365, ce qui modifie le statut des lignes de commande client associées.
Pourquoi c'est important Cet événement sert de point de départ pour mesurer le temps de cycle de génération des factures. Comprendre le délai entre l'exécution et la facturation aide à identifier les goulots d'étranglement administratifs qui peuvent impacter le flux de trésorerie. Où obtenir Déduit de la date de création d'une écriture de journal de bon de livraison liée à la commande client. Cela implique des tables telles que CustPackingSlipJour et CustPackingSlipTrans, qui sont liées à la commande client sur laquelle la facture est basée. Capture Identifiez la date de validation la plus récente du bon de livraison pour la commande client associée à la facture. Type d'événement inferred
	Facture soumise pour approbation	Cette activité indique qu'une facture générée a été soumise à un workflow d'approbation formel. Ceci est courant dans les organisations avec des contrôles exigeant un examen par la direction avant qu'une facture ne soit envoyée à un client. Ceci est enregistré comme une étape spécifique dans le moteur de workflow de D365.
Pourquoi c'est important Le suivi de la soumission pour approbation aide à séparer le temps de création de la facture du temps d'attente d'approbation. C'est la première étape de l'analyse de l'efficacité des processus de révision et de contrôle internes. Où obtenir Capturé à partir des tables d'historique du workflow, telles que WorkflowTrackingStatusTable, en filtrant l'événement de soumission lié au document de facture. Capture Extraire les journaux d'événements de workflow où le statut est 'Soumis'. Type d'événement explicit
	Paiement Annulé	Cette activité signifie l'annulation d'un paiement client précédemment validé. Cela se produit en raison d'erreurs telles qu'une validation incorrecte, des fonds insuffisants ou d'autres échecs de paiement.
Pourquoi c'est important Les annulations de paiement mettent en évidence des erreurs opérationnelles ou des problèmes liés aux paiements clients. L'analyse de leur fréquence aide à identifier les causes profondes et à améliorer la précision du processus d'affectation des paiements. Où obtenir Capturé comme une annulation de transaction dans le grand livre. Un journal annulé peut être identifié dans GeneralJournalEntry, souvent avec un indicateur spécifique ou par sa relation avec la transaction originale. Capture Identifier les écritures de journal avec un indicateur d'annulation ou une référence à une transaction annulée. Type d'événement explicit
	Rappel de Paiement Émis	Représente l'envoi d'une lettre de relance ou d'un avis de recouvrement à un client concernant une facture en souffrance. Dynamics 365 dispose d'un processus de relance formel qui génère et enregistre ces communications.
Pourquoi c'est important Le suivi des rappels aide à évaluer l'efficacité du processus de relance. Il permet d'analyser le nombre de rappels nécessaires avant la réception d'un paiement. Où obtenir Ceci est un événement explicite capturé à partir de la date de création du journal des lettres de relance dans la table CustCollectionLetterJour, qui est liée à la transaction de facture en souffrance. Capture Utilisez l'horodatage de création de la table CustCollectionLetterJour. 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 and Operations. Utilisez la barre de recherche pour trouver et naviguer vers l'espace de travail Gestion des données. C'est le point central pour toutes les opérations d'importation et d'exportation de données.
Créer un nouveau projet d'exportation : Dans l'espace de travail Gestion des données, cliquez sur la tuile Exporter pour créer un nouveau projet d'exportation de données. Donnez au projet un nom significatif, tel que ProcessMind_O2C_Billing_Export, et une description.
Sélectionner le format de données cible : Dans la configuration du projet, spécifiez le Format de données cible. Pour une compatibilité avec la plupart des outils de transformation de données, sélectionnez CSV. Configurez les options de format si nécessaire, en vous assurant d'utiliser un délimiteur et un qualificatif de texte communs.
Ajouter les entités de données requises : C'est l'étape la plus critique. Vous ajouterez plusieurs entités de données standard à votre projet pour capturer toutes les activités requises. Pour chaque entité, cliquez sur Ajouter une entité et recherchez le nom de l'entité listé dans la section Requête/Script. Ajoutez chacune des entités suivantes à votre projet : Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement et Dunning history letters.
Appliquer les filtres d'entité : Pour limiter les données à une portée pertinente, appliquez des filtres à vos entités. Au minimum, filtrez Sales invoice headers V2 par InvoiceDate pour une période spécifique, par exemple les 6 derniers mois. Filtrez également par les entités juridiques (sociétés) spécifiques que vous souhaitez analyser.
Exécuter la tâche d'exportation : Une fois toutes les entités ajoutées et les filtres appliqués, cliquez sur le bouton Exporter dans le volet d'action. Le système créera un paquet de tâche et commencera le traitement de l'extraction des données en arrière-plan.
Surveiller et télécharger les données : Vous pouvez suivre la progression de la tâche dans la section Historique des tâches. Une fois la tâche terminée avec succès, vous pouvez télécharger le paquet de données exporté. Le paquet sera un fichier ZIP contenant des fichiers CSV distincts pour chaque entité de données.
Décompresser le paquet : Extrayez le contenu du fichier ZIP téléchargé dans un dossier local. Vous disposerez alors de plusieurs fichiers CSV, un pour chaque entité.
Transformer et combiner les données : Les fichiers bruts doivent être transformés en un journal d'événements unique. Utilisez un outil de préparation de données comme Power Query, Python ou une zone de staging de base de données. Pour chaque fichier source, créez les colonnes requises : InvoiceNumber (ID de cas), ActivityName (une valeur codée en dur représentant l'événement, comme 'Facture Générée'), et EventTime (le champ de date pertinent du fichier source). Mappez d'autres attributs comme InvoiceAmount et CustomerName.
Union de toutes les données transformées : Combinez les données transformées de tous les fichiers sources en une seule table à l'aide d'une opération d'union ou d'ajout. Cela crée le journal d'événements final et unifié où chaque ligne représente une activité dans le cycle de vie de la facture.
Formatage final pour le téléchargement : Assurez-vous que le fichier CSV final a les en-têtes de colonne corrects (InvoiceNumber, ActivityName, EventTime, etc.) et que la colonne EventTime est dans un format d'horodatage cohérent (par ex., AAAA-MM-JJ HH:MI:SS). Ce fichier est maintenant prêt à être téléchargé dans ProcessMind.

Configuration

Entités de données : L'extraction s'appuie sur un ensemble d'entités de données D365 standard. Les entités clés incluent Sales invoice headers V2 (pour les factures et les notes de crédit), Sales packing slip headers (pour l'exécution des commandes), CustPaymentJournalLineEntity (pour les paiements), Customer settlement (pour l'application des paiements) et Workflow tracking status table (pour les approbations).
Format d'exportation : Le format de données cible recommandé est le CSV pour sa large compatibilité avec les outils de transformation de données.
Filtrage par période : Il est crucial d'appliquer un filtre de période aux entités primaires, en particulier à Sales invoice headers V2 sur le champ InvoiceDate. Une plage de 3 à 6 mois est recommandée pour maintenir l'exportation gérable tout en fournissant suffisamment de données pour l'analyse.
Filtrage par société : L'exportation doit être filtrée par l'entité juridique ou le code d'entreprise spécifique que vous analysez afin de garantir la pertinence des données et de réduire la taille de l'exportation.
Préparation et transformation des données : Une étape de post-traitement en dehors de Dynamics 365 est nécessaire. Les fichiers exportés doivent être combinés et restructurés dans un format de journal d'événements unique. Cela implique généralement l'utilisation d'outils tels que Power BI (Power Query), Python ou SQL.
Prérequis : L'utilisateur effectuant l'exportation doit disposer des rôles de sécurité appropriés dans Dynamics 365, incluant généralement un rôle avec des autorisations pour l'espace de travail Data management et l'accès aux entités de données requises.

a Exemple de requête config

The following configuration outlines the data entities and field mappings required for the export project within the Dynamics 365 Data Management Framework. A post-processing script or tool is required to union these outputs into a single event log.

**1. Activity: Sales Order Fulfilled**
*   **Entity Name:** `Sales packing slip headers`
*   **Mapping:**
    *   `InvoiceNumber`: Use `SalesOrderNumber` as a key to later join to the invoice data and find the corresponding `InvoiceNumber`.
    *   `ActivityName`: 'Sales Order Fulfilled' (Hardcoded Value)
    *   `EventTime`: `DeliveryDate`
    *   `UserResponsible`: `CreatedBy`

**2. Activity: Invoice Generated**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is not 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Generated' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate` and `CreatedTime`
    *   `InvoiceAmount`: `TotalInvoiceAmount`
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`
    *   `PaymentDueDate`: `DueDate`
    *   `InvoiceStatus`: `DocumentState`

**3. Activities: Invoice Submitted for Approval & Invoice Approved**
*   **Entity Name:** `Workflow tracking status table`
*   **Filter:** `ContextTableName` is 'CustInvoiceJour'.
*   **Mapping:**
    *   `InvoiceNumber`: Join `ContextRecId` to `RecId` from `Sales invoice headers V2` to get the `InvoiceNumber`.
    *   `ActivityName`: Use a conditional rule, if `TrackingStatus` is 'Submitted', set to 'Invoice Submitted for Approval'; if 'Approved', set to 'Invoice Approved'.
    *   `EventTime`: `CreatedDateTime`
    *   `UserResponsible`: `User`

**4. Activity: Invoice Sent to Customer**
*   **Note:** This is an inferred event. The posting date is used as a proxy.
*   **Entity Name:** `Sales invoice headers V2`
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Invoice Sent to Customer' (Hardcoded Value)
    *   `EventTime`: `PostedDateTime` (or equivalent posting timestamp)

**5. Activity: Payment Due Date Reached**
*   **Note:** This is a calculated event generated during post-processing.
*   **Source Entity:** `Sales invoice headers V2`
*   **Logic:** For each invoice where the `DueDate` has passed and the invoice is not fully settled.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Payment Due Date Reached' (Hardcoded Value)
    *   `EventTime`: `DueDate`

**6. Activity: Payment Reminder Issued**
*   **Entity Name:** `Dunning history letters`
*   **Mapping:**
    *   `InvoiceNumber`: Join from the dunning history to the customer transactions to find the related `InvoiceNumber`.
    *   `ActivityName`: 'Payment Reminder Issued' (Hardcoded Value)
    *   `EventTime`: `DunningLetterDate`
    *   `UserResponsible`: `CreatedBy`

**7. Activity: Customer Payment Received**
*   **Entity Name:** `CustPaymentJournalLineEntity`
*   **Mapping:**
    *   `InvoiceNumber`: The `Invoice` field may be populated, but often settlements are needed to link payments to invoices. This might require staging the payment data first.
    *   `ActivityName`: 'Customer Payment Received' (Hardcoded Value)
    *   `EventTime`: `ReceivedDate` or `DocumentDate`
    *   `UserResponsible`: `CreatedBy`

**8. Activity: Cash Applied to Invoice**
*   **Entity Name:** `Customer settlement`
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Cash Applied to Invoice' (Hardcoded Value)
    *   `EventTime`: `TransDate`
    *   `UserResponsible`: `CreatedBy`

**9. Activity: Payment Reversed**
*   **Source Entity:** `Customer settlement`
*   **Logic:** Filter for transactions where a settlement was later reversed. This may require looking for cancellation markers.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Payment Reversed' (Hardcoded Value)
    *   `EventTime`: Reversal transaction timestamp.

**10. Activity: Credit Note Issued**
*   **Entity Name:** `Sales invoice headers V2`
*   **Filter:** `InvoiceType` is 'CreditNote'.
*   **Mapping:**
    *   `InvoiceNumber`: `InvoiceNumber`
    *   `ActivityName`: 'Credit Note Issued' (Hardcoded Value)
    *   `EventTime`: `InvoiceDate`
    *   `InvoiceAmount`: `TotalInvoiceAmount` (will be negative)
    *   `CustomerName`: `InvoiceCustomerName`
    *   `UserResponsible`: `CreatedBy`

**11. Activity: Invoice Closed**
*   **Note:** This is an inferred event based on settlement data.
*   **Source Entity:** `Customer settlement`
*   **Logic:** Use the latest `TransDate` for an invoice from the settlement data where the invoice balance becomes zero.
*   **Mapping:**
    *   `InvoiceNumber`: `OffsetInvoice`
    *   `ActivityName`: 'Invoice Closed' (Hardcoded Value)
    *   `EventTime`: The latest `TransDate` that resulted in the invoice being fully settled.

Étapes

Prérequis : Assurez-vous d'avoir Python 3.6+ installé avec les bibliothèques requests et pandas. Vous aurez également besoin d'identifiants pour un principal de service (enregistrement d'application) dans Azure Active Directory qui a reçu un accès à l'environnement Dynamics 365 Finance & Operations.
Enregistrement de l'application : Dans Azure AD, enregistrez une nouvelle application. Créez un secret client et notez l'ID de l'application (client), l'ID du répertoire (locataire) et le secret client. Dans Dynamics 365, ajoutez cet ID d'application sous Administration système > Configuration > Applications Azure Active Directory et attribuez-lui les droits d'utilisateur appropriés pour lire les entités de données requises.
Configurer le script : Ouvrez le script Python fourni. Remplissez les variables de configuration en haut du script, y compris d365_url, tenant_id, client_id, client_secret, company, start_date et end_date. Le d365_url doit être l'URL de base de votre environnement Dynamics 365, par exemple, https://your-d365-instance.operations.dynamics.com.
Authentification : Le script contient une fonction get_access_token qui utilise automatiquement vos identifiants pour demander un jeton d'accès OAuth2 à la plateforme d'identité de Microsoft. Ce jeton est nécessaire pour autoriser les appels d'API ultérieurs.
Extraction des données : Exécutez le script depuis votre terminal en utilisant python your_script_name.py. Le script commencera par récupérer toutes les factures de vente enregistrées (CustInvoiceJour) dans la plage de dates spécifiée. Pour chaque facture, il effectuera ensuite des appels d'API supplémentaires pour récupérer les données associées pour des activités telles que les paiements, les règlements, les notes de crédit et l'historique du workflow.
Génération d'activités : Le script traite les données brutes provenant de plusieurs points de terminaison d'API. Il génère explicitement une ligne pour chacune des 12 activités requises. Par exemple, il utilise l'entité CustInvoiceJour pour l'événement 'Facture Générée' et interroge l'entité CustSettlement pour créer les événements 'Encaissement Appliqué à la Facture'.
Événements calculés : Notez que des événements comme 'Date d'échéance de paiement atteinte' et 'Facture clôturée' ne sont pas des transactions directes dans Dynamics 365. Le script dérive ces événements en fonction de la date d'échéance, du statut et de l'historique de règlement d'une facture, créant des entrées correspondantes dans le journal d'événements.
Gestion de la pagination : La fonction d'assistance fetch_all_data est conçue pour gérer automatiquement la pagination. Les API OData de Dynamics 365 renvoient un nombre limité d'enregistrements par page, cette fonction suit donc le @odata.nextLink fourni dans la réponse de l'API pour récupérer l'ensemble complet des données.
Transformation et sortie des données : Après avoir collecté tous les événements, le script les compile en une seule liste, les convertit en un DataFrame pandas et standardise les noms de colonnes en InvoiceNumber, ActivityName, EventTime et d'autres attributs requis.
Exporter au format CSV : Enfin, le script enregistre le DataFrame résultant dans un fichier CSV nommé d365_billing_event_log.csv. Ce fichier est formaté et prêt à être téléchargé dans ProcessMind ou un autre outil de Process Mining.

Configuration

URL D365 : L'URL de base de votre instance Dynamics 365 Finance & Operations. C'est le point d'accès principal pour tous les appels d'API.
Identifiants Azure AD : Un client_id, un client_secret et un tenant_id sont nécessaires pour l'authentification. Ceux-ci doivent correspondre à une application disposant d'un accès en lecture aux entités D365 pertinentes.
Société : Spécifiez le DataAreaId, qui correspond à l'entité juridique dans Dynamics 365 à partir de laquelle vous souhaitez extraire des données (par ex., 'USMF').
Période : Définissez une start_date et une end_date pour limiter la portée de l'extraction. Pour une analyse initiale, une période de 3 à 6 mois est recommandée afin d'assurer une taille de jeu de données gérable tout en capturant suffisamment de variations de processus.
Entités OData Clés : Le script interroge principalement les entités suivantes : CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours et WorkflowTrackingStatusTables. Assurez-vous que l'utilisateur configuré dispose des autorisations de lecture pour toutes ces entités.
Performance : L'extraction de données sur une longue période ou pour une très grande entreprise peut être lente en raison de la nature des appels d'API séquentiels multiples. Il est conseillé d'exécuter le script pendant les heures creuses et de commencer par une période plus courte pour estimer le temps d'exécution total.

a Exemple de requête python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
d365_url = class="hl-string">"https://[your-d365-instance].operations.dynamics.com" class=class="hl-string">"hl-comment"># Your D365 F&O URL
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 = class="hl-string">"[Your Company DataAreaId, e.g., USMF]"
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- Authentication ---
def get_access_token():
    url = fclass="hl-string">"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': client_id,
        class="hl-string">'client_secret': client_secret,
        class="hl-string">'scope': fclass="hl-string">"{d365_url}/.default"
    }
    response = requests.post(url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

class=class="hl-string">"hl-comment"># --- OData Helper ---
def fetch_all_data(access_token, resource_path):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    full_url = fclass="hl-string">"{d365_url}/data/{resource_path}"
    results = []
    while full_url:
        response = requests.get(full_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        results.extend(data[class="hl-string">'value'])
        full_url = data.get(class="hl-string">'@odata.nextLink')
    return results

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---
def main():
    print(class="hl-string">"Acquiring access token...")
    token = get_access_token()
    event_log = []
    today = datetime.now(timezone.utc).date()

    print(class="hl-string">"Fetching Invoices and Credit Notes...")
    invoice_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    invoice_fields = class="hl-string">"$select=InvoiceNumber,InvoiceDate,SalesOrderNumber,InvoiceAmount,CustomerAccount,Due_Date,WorkerSalespersonName,createdDateTime,RecId,SalesInvoiceHeader_SalesStatus"
    invoices = fetch_all_data(token, fclass="hl-string">"CustInvoiceJours?cross-company=true&{invoice_filter}&{invoice_fields}")

    class=class="hl-string">"hl-comment"># Create a lookup for invoice RecIds for workflow queries
    invoice_recid_map = {inv[class="hl-string">'RecId']: inv[class="hl-string">'InvoiceNumber'] for inv in invoices}

    for inv in invoices:
        case_id = inv[class="hl-string">'InvoiceNumber']
        invoice_amount = inv[class="hl-string">'InvoiceAmount']
        customer_name = inv.get(class="hl-string">'CustomerAccount', class="hl-string">'') class=class="hl-string">"hl-comment"># Placeholder, join to CustTable for name
        user_responsible = inv.get(class="hl-string">'WorkerSalespersonName', class="hl-string">'System')
        due_date = inv.get(class="hl-string">'Due_Date')
        invoice_status = inv.get(class="hl-string">'SalesInvoiceHeader_SalesStatus', class="hl-string">'Open')

        class=class="hl-string">"hl-comment"># Activity: Invoice Generated / Credit Note Issued
        activity_name = class="hl-string">'Credit Note Issued' if invoice_amount < 0 else class="hl-string">'Invoice Generated'
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': activity_name,
            class="hl-string">'EventTime': inv[class="hl-string">'createdDateTime'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Invoice Sent to Customer (proxy)
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Sent to Customer',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'],
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })
        
        class=class="hl-string">"hl-comment"># Activity: Sales Order Fulfilled (proxy via invoice date, complex to get actual packing slip date)
        class=class="hl-string">"hl-comment"># A more accurate query would trace SalesInvoiceLinesV2 -> SalesOrderLines -> CustPackingSlipJour
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Fulfilled',
            class="hl-string">'EventTime': inv[class="hl-string">'InvoiceDate'], class=class="hl-string">"hl-comment"># Using InvoiceDate as a proxy
            class="hl-string">'InvoiceAmount': invoice_amount,
            class="hl-string">'CustomerName': customer_name,
            class="hl-string">'UserResponsible': user_responsible,
            class="hl-string">'Department': class="hl-string">'[Configure based on your system]',
            class="hl-string">'PaymentDueDate': due_date,
            class="hl-string">'InvoiceStatus': invoice_status
        })

        class=class="hl-string">"hl-comment"># Activity: Payment Due Date Reached (calculated)
        if due_date and pd.to_datetime(due_date).date() < today and invoice_status != class="hl-string">'Paid':
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Payment Due Date Reached',
                class="hl-string">'EventTime': due_date,
                class="hl-string">'InvoiceAmount': invoice_amount,
                class="hl-string">'CustomerName': customer_name,
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class="hl-string">'Department': class="hl-string">'Finance',
                class="hl-string">'PaymentDueDate': due_date,
                class="hl-string">'InvoiceStatus': invoice_status
            })

    print(class="hl-string">"Fetching Settlements for Cash Applied and Invoice Closed events...")
    settlement_filter = fclass="hl-string">"$filter=InvoiceDate ge {start_date} and InvoiceDate le {end_date}"
    settlement_fields = class="hl-string">"$select=InvoiceNumber,SettlementDate,OffsetTransactionVoucher,OffsetRecId,CanBeReversed"
    settlements = fetch_all_data(token, fclass="hl-string">"CustSettlements?cross-company=true&{settlement_filter}&{settlement_fields}")

    class=class="hl-string">"hl-comment"># Group settlements by invoice
    settlements_by_invoice = pd.DataFrame(settlements).groupby(class="hl-string">'InvoiceNumber')

    for case_id, group in settlements_by_invoice:
        last_settlement = group.sort_values(class="hl-string">'SettlementDate').iloc[-1]

        for _, settlement in group.iterrows():
            class=class="hl-string">"hl-comment"># Activity: Cash Applied to Invoice
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Cash Applied to Invoice',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'],
                class="hl-string">'UserResponsible': class="hl-string">'System',
                class=class="hl-string">"hl-comment"># Add other attributes from original invoice if needed
            })

            class=class="hl-string">"hl-comment"># Activity: Customer Payment Received (date of original payment)
            class=class="hl-string">"hl-comment"># This requires a second hop to CustTrans using OffsetRecId
            class=class="hl-string">"hl-comment"># For simplicity, we use settlement date as a proxy. A full implementation would query CustTrans.
            event_log.append({
                class="hl-string">'InvoiceNumber': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Customer Payment Received',
                class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Proxy timestamp
                class="hl-string">'UserResponsible': class="hl-string">'System',
            })

            class=class="hl-string">"hl-comment"># Activity: Payment Reversed (if applicable)
            if settlement[class="hl-string">'CanBeReversed']: class=class="hl-string">"hl-comment"># A simplistic check, real logic is more complex
                 event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': class="hl-string">'Payment Reversed',
                    class="hl-string">'EventTime': settlement[class="hl-string">'SettlementDate'], class=class="hl-string">"hl-comment"># Reversal date would be different in reality
                    class="hl-string">'UserResponsible': class="hl-string">'System',
                 })
        
        class=class="hl-string">"hl-comment"># Activity: Invoice Closed (inferred from last settlement)
        class=class="hl-string">"hl-comment"># This logic assumes the invoice is fully paid by the last settlement. A robust check would sum amounts.
        event_log.append({
            class="hl-string">'InvoiceNumber': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Invoice Closed',
            class="hl-string">'EventTime': last_settlement[class="hl-string">'SettlementDate'],
            class="hl-string">'UserResponsible': class="hl-string">'System',
        })

    print(class="hl-string">"Fetching Payment Reminders...")
    reminder_filter = fclass="hl-string">"$filter=CollectionLetterDate ge {start_date} and CollectionLetterDate le {end_date}"
    reminders = fetch_all_data(token, fclass="hl-string">"CustCollectionLetterJours?cross-company=true&{reminder_filter}")
    for rem in reminders:
        class=class="hl-string">"hl-comment"># Linking reminders to invoices can be complex. This is a simplified approach.
        if rem.get(class="hl-string">'InvoiceNum'):
            event_log.append({
                class="hl-string">'InvoiceNumber': rem[class="hl-string">'InvoiceNum'],
                class="hl-string">'ActivityName': class="hl-string">'Payment Reminder Issued',
                class="hl-string">'EventTime': rem[class="hl-string">'CollectionLetterDate'],
                class="hl-string">'UserResponsible': rem.get(class="hl-string">'UserId', class="hl-string">'System'),
            })

    print(class="hl-string">"Fetching Workflow History...")
    class=class="hl-string">"hl-comment"># This is a complex query. It requires knowing the TableId for CustInvoiceJour (e.g., 523)
    class=class="hl-string">"hl-comment"># The filter below is illustrative and needs to be adapted for your specific workflow setup.
    workflow_filter = fclass="hl-string">"$filter=createdDateTime ge {start_date}T00:00:00Z"
    wf_history = fetch_all_data(token, fclass="hl-string">"WorkflowTrackingStatusTables?cross-company=true&{workflow_filter}")
    for item in wf_history:
        if item.get(class="hl-string">'ContextRecId') in invoice_recid_map:
            case_id = invoice_recid_map[item[class="hl-string">'ContextRecId']]
            activity_name = None
            if item[class="hl-string">'TrackingStatus'] == class="hl-string">'Submitted':
                activity_name = class="hl-string">'Invoice Submitted for Approval'
            elif item[class="hl-string">'TrackingStatus'] == class="hl-string">'Approved':
                activity_name = class="hl-string">'Invoice Approved'
            
            if activity_name:
                event_log.append({
                    class="hl-string">'InvoiceNumber': case_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTime': item[class="hl-string">'createdDateTime'],
                    class="hl-string">'UserResponsible': item.get(class="hl-string">'User', class="hl-string">'System'),
                })

    print(fclass="hl-string">"Total events extracted: {len(event_log)}")
    if not event_log:
        print(class="hl-string">"No events found for the given criteria.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'])
    df.to_csv(class="hl-string">'d365_billing_event_log.csv', index=False)
    print(class="hl-string">"Event log saved to d365_billing_event_log.csv")

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

Votre Template de Données Order to Cash - Facturation

Votre Template de Données Order to Cash - Facturation

Attributs Order to Cash - Facturation

Activités Order to Cash - Facturation

Guides d'extraction

Exportation d'entité de données Microsoft Dynamics 365

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API Web OData de Dynamics 365

Étapes

Configuration

a Exemple de requête python

Prêt(e) à démarrer ?

Mettez fin aux retards de facturation : Optimisez votre Commande au Paiement et Facturation dès aujourd'hui

Votre Template de Données Order to Cash - Facturation

Votre Template de Données Order to Cash - Facturation

Attributs Order to Cash - Facturation

Activités Order to Cash - Facturation

Guides d'extraction

Exportation d'entité de données Microsoft Dynamics 365

Étapes

Configuration

a Exemple de requête config

Script Python utilisant l'API Web OData de Dynamics 365

Étapes

Configuration

a Exemple de requête python

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Mettez fin aux retards de facturation : Optimisez votre Commande au Paiement et Facturation dès aujourd'hui