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

Votre modèle de données Order to Cash - Billing & Invoicing

Microsoft Dynamics 365

← Retour au guide d’amélioration

Attributs du processus Order to Cash - Facturation et émission des factures (18) Activités du processus Order to Cash - Facturation et émission des factures (12) Guides d'extraction (2)

Votre modèle de données Order to Cash - Billing & Invoicing

Ce modèle fournit une feuille de route claire pour recueillir les données essentielles à l’analyse de votre processus Order to Cash - Billing & Invoicing. Vous y trouverez les attributs recommandés pour votre journal d’événements, les activités clés à suivre et des indications pratiques pour extraire ces informations. Il est conçu pour vous aider à préparer rapidement vos données en vue d’un Process Mining pertinent.

Attributs recommandés à recueillir
Principales activités à suivre
Conseils d'extraction pour Microsoft Dynamics 365

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

Télécharger le modèle

Attributs du processus Order to Cash - Facturation et émission des factures

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser de manière complète le processus Order to Cash de facturation et d’émission des factures.

3 Obligatoire 6 Recommandé 9 Facultatif

	Nom	Description
	Numéro de facture InvoiceNumber	Identifiant unique de chaque facture client, servant d’identifiant de dossier principal pour le processus de facturation.
Description L’Invoice Number est la clé centrale qui regroupe toutes les activités associées à un même document de facturation. Il permet d’analyser de bout en bout le cycle de vie de la facture, de sa génération et de son approbation jusqu’au paiement client et à sa clôture définitive. En l’utilisant comme Case ID, chaque entrée du journal d’événements correspond à une facture précise, ce qui permet d’analyser les variantes, de calculer les délais de cycle et de suivre la performance de chaque transaction de facturation. Pourquoi c’est important Cet attribut est essentiel pour suivre l’ensemble du cycle de vie d’une facture et analyser l’efficacité du processus, les goulots d’étranglement et les écarts pour chaque document de facturation. Où les obtenir Il se trouve généralement dans le module Sales and marketing, dans des tables telles que CustInvoiceJour, champ InvoiceId, ou est exposé par des entités de données telles que SalesInvoiceHeaderV2. Exemples CIV-001254INV-2023-9876US-004321
	Heure de l’événement EventTime	Horodatage précis indiquant le moment où une activité ou un événement donné s’est produit.
Description L’Event Time, également appelé horodatage, enregistre la date et l’heure exactes de chaque activité du processus. Ces données sont essentielles à toutes les analyses temporelles de process mining. Elles servent à calculer les délais entre les activités, à mesurer la durée totale d’un dossier et à comprendre la performance du processus au fil du temps. Des horodatages exacts et fiables constituent le fondement d’indicateurs tels que le délai moyen de recouvrement et le délai de génération des factures. Pourquoi c’est important Il s’agit de l’attribut fondamental de toutes les analyses de performance et de durée. Il permet de calculer les délais de cycle, les durées et le débit afin de mesurer l’efficacité du processus. Où les obtenir Les horodatages proviennent de différents champs de date et d’heure répartis dans plusieurs tables de Dynamics 365, comme CreatedDateTime dans la table CustInvoiceJour pour la génération des factures, ou de champs d’horodatage propres à l’historique du flux de travail. Exemples 2023-04-15T10:22:15Z2023-05-01T14:05:00Z2023-05-10T09:00:30Z
	Nom de l’activité ActivityName	Nom de l’activité métier ou de l’événement survenu à un moment précis du cycle de vie de la facture.
Description Cet attribut décrit une étape ou un jalon précis du processus de facturation, comme « Invoice Generated », « Invoice Approved » ou « Customer Payment Received ». La séquence de ces activités forme le flux du processus. L’analyse des activités est fondamentale en process mining, car elle permet de découvrir les modèles de processus, d’identifier les variantes et de mesurer la performance entre les différentes étapes. Pourquoi c’est important Il définit les étapes du processus, ce qui permet de visualiser les cartes de processus, d’analyser les variantes et d’identifier les goulots d’étranglement ou les écarts par rapport à la procédure standard. Où les obtenir Cet attribut est généralement dérivé de plusieurs sources, telles que les champs de changement de statut, par exemple DocumentState, certains champs de date renseignés ou les journaux d’historique du flux de travail dans 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é régler la facture.
Description La date d'échéance du paiement est un champ de date essentiel, calculé à partir de la date de facturation et des conditions de paiement du client. Elle sert de référence pour mesurer la ponctualité des paiements. Cet attribut est indispensable au Dashboard « Payment Terms Adherence Analysis » et au calcul d'indicateurs tels que « On-Time Payment Rate » et « Days Sales Outstanding ». La comparaison de cette date avec la date réelle de paiement permet d'évaluer le comportement de paiement des clients et l'efficacité du processus de recouvrement. Pourquoi c’est important Cette date sert de référence pour mesurer la performance des paiements. Elle est essentielle au calcul du taux de paiements à temps et à l'analyse du respect des conditions de paiement accordées aux clients. Où les obtenir Cette information se trouve généralement dans la table CustInvoiceJour, dans un champ tel que DueDate. Exemples 2023-05-152023-06-302023-07-01
	Montant de la facture InvoiceAmount	Valeur monétaire totale de la facture.
Description Cet attribut représente le montant total dû au titre de la facture. Il s’agit d’un indicateur essentiel pour l’analyse financière, qui permet de segmenter les factures selon leur valeur. Les analystes peuvent par exemple se concentrer sur les factures de montant élevé pour comprendre leurs comportements de paiement ou déterminer si elles nécessitent davantage de temps pour être approuvées. Cet attribut est également indispensable au calcul de la valeur totale des factures impayées et du DSO. Pourquoi c’est important Il permet d’analyser l’impact financier en filtrant et en segmentant les processus selon leur valeur monétaire, afin de donner la priorité aux factures de montant élevé et de comprendre leurs comportements spécifiques. Où les obtenir Se trouve dans la table CustInvoiceJour, généralement dans un champ tel que InvoiceAmount. Également disponible dans les tables de transactions associées. Exemples 5430.5012500.00750.25
	Nom du client CustomerName	Nom du client auquel la facture a été émise.
Description Le nom du client fournit un identifiant lisible par un humain pour l'entreprise ou le particulier facturé. Dans l'analyse de Process Mining, il permet de segmenter le processus de facturation par client. Vous pouvez ainsi déterminer quels clients paient systématiquement à temps, lesquels sont souvent en retard et si certains groupes de clients rencontrent des variations ou des retards particuliers dans le processus. Cet attribut est essentiel pour les Dashboards consacrés au comportement de paiement des clients et à l'analyse du délai moyen de recouvrement des créances clients (Days Sales Outstanding). Pourquoi c’est important Il permet de segmenter l'analyse du processus par client afin d'identifier les comportements propres à chaque client, les habitudes de paiement ou les problèmes liés au processus. Où les obtenir Ces informations sont obtenues en reliant les données de facturation à la table des données de référence clients, généralement CustTable, à partir du numéro de compte client. Exemples Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Service Department	Le service de l'entreprise associé à l'utilisateur ou à l'activité.
Description Cet attribut associe une activité ou un utilisateur à un service précis de l'organisation, tel que « Accounts Receivable » ou « Sales ». Il offre une vision plus globale des performances du processus que l'analyse au niveau individuel. L'analyse par service aide à comprendre les transferts entre fonctions, à comparer l'efficacité des équipes et à identifier les goulots d'étranglement à l'échelle d'un service, comme l'exige le Dashboard « Billing Department Activity Load ». Pourquoi c’est important Il permet d'analyser les performances à l'échelle de l'organisation, de comparer l'efficacité des différentes équipes et de comprendre l'incidence des transferts entre services sur le processus. Où les obtenir Il ne s'agit généralement pas d'un champ direct de la transaction de facturation. Cet attribut est obtenu en reliant l'identifiant UserResponsible à l'annuaire des collaborateurs ou des utilisateurs, qui contient les informations relatives au service. Exemples Comptes clientsFinanceOpérations de facturation
	Statut de la facture InvoiceStatus	Le statut actuel de la facture dans son cycle de vie, par exemple Open, Paid ou Canceled.
Description Cet attribut fournit un état des lieux de la facture. Il indique si celle-ci est toujours en attente de paiement, a été intégralement réglée, est échue ou a été annulée par une note de crédit. Il 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. Il aide à comprendre la charge de travail actuelle et la situation financière des créances clients. Pourquoi c’est important Il fournit rapidement une vue d'ensemble de l'état actuel de la facture, ce qui est utile pour filtrer les cas et comprendre les résultats des différentes variantes du processus. Où les obtenir Cet attribut peut être déduit du statut de paiement de la facture, notamment en vérifiant si le solde de l'enregistrement CustTrans associé est nul. Il n'existe pas toujours de champ unique « status ». Exemples OuvertePayéeÉchueAnnulée
	Utilisateur responsable UserResponsible	L'utilisateur ou le collaborateur responsable de l'exécution d'une activité donnée.
Description Cet attribut identifie la personne qui a exécuté une tâche donnée dans le processus de facturation, par exemple l'approbation d'une facture ou l'affectation d'un paiement. Il est essentiel pour analyser la charge de travail, comparer les performances et identifier les besoins de formation. Par exemple, le Dashboard « Billing Department Activity Load » s'appuie sur cet attribut pour vérifier si le travail est réparti équitablement ou si certains utilisateurs constituent des goulots d'étranglement. Il contribue également à comprendre l'affectation des ressources et l'efficacité du processus. Pourquoi c’est important Il permet d'analyser le processus au niveau des ressources, d'identifier les goulots d'étranglement, de mesurer les performances individuelles ou collectives et d'étudier la répartition de la charge de travail au sein du service de facturation. Où les obtenir Ces informations peuvent provenir des journaux d’historique du flux de travail, par exemple WorkflowTrackingStatusTable, ou de champs de propriété tels que Owner ou ModifiedBy dans les tables concernées. Exemples John SmithAlicia BakerAdministrateur système
	Conditions de paiement PaymentTerms	Les conditions convenues pour le règlement d'une facture, par exemple Net 30 ou Net 60.
Description Les conditions de paiement définissent le délai dans lequel le client est censé régler une facture. Cet attribut sert à calculer la date d'échéance du paiement et constitue une dimension importante pour analyser les comportements de paiement. Le Dashboard « Payment Terms Adherence Analysis » l'utilise pour regrouper les clients et les factures, afin de déterminer si certaines conditions de paiement sont plus ou moins efficaces ou associées à un taux plus élevé de retards de paiement. Pourquoi c’est important Il explique pourquoi une facture arrive à échéance à une date donnée et permet de segmenter l'analyse afin de déterminer si certaines conditions de paiement sont corrélées aux retards de paiement. Où les obtenir Cette information est généralement enregistrée dans la fiche de référence du client, puis copiée dans l'en-tête de la facture. Recherchez un champ Payment ou PaymTermId dans la table CustInvoiceJour. Exemples Échéance à 30 joursÉchéance à 60 joursPayable à réception
	Délai moyen de recouvrement des créances clients DaysSalesOutstanding	Le nombre de jours entre l'émission de la facture et la réception du paiement du client.
Description Le Days Sales Outstanding (DSO) est un indicateur financier important qui mesure le nombre moyen de jours nécessaires à une entreprise pour recouvrer un paiement après une vente. Cet attribut calculé détermine cette durée pour chaque facture. Il constitue l'indicateur principal du Dashboard « Days Sales Outstanding Trend Analysis » et du KPI « DSO ». L'analyse du DSO aide à gérer la trésorerie et à évaluer l'efficacité des fonctions de crédit et de recouvrement. Pourquoi c’est important Il s'agit d'un KPI important pour mesurer la santé de la trésorerie d'une entreprise et l'efficacité de son processus de recouvrement. Il quantifie la rapidité avec laquelle le chiffre d'affaires est converti en liquidités. Où les obtenir Cet attribut n'est pas présent dans le système source. Il est calculé comme la durée entre l'activité « Invoice Generated » et l'activité « Customer Payment Received ». Exemples 284592
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation des données associées à cet événement depuis le système source.
Description Cet attribut enregistre la date de la dernière extraction ou mise à jour des données depuis Microsoft Dynamics 365. Il s’agit d’un champ de métadonnées essentiel pour connaître l’actualité des données analysées. Il aide les analystes et les utilisateurs métier à vérifier qu’ils consultent les informations les plus récentes, et il est indispensable à la gestion des calendriers d’actualisation ainsi qu’à la fiabilité de l’analyse. Pourquoi c’est important Il permet aux utilisateurs de connaître la récence des données, un élément essentiel pour la gouvernance des données, la gestion de l’actualisation des Dashboards et la confiance accordée à l’actualité des analyses. Où les obtenir Cet attribut est généré et ajouté au jeu de données lors du processus d’extraction, de transformation et de chargement (ETL). Exemples 2023-06-20T05:00:00Z2023-06-21T05:00:00Z
	Devise Currency	Code de devise du montant de la facture, par exemple USD ou EUR.
Description Cet attribut précise la devise dans laquelle le montant de la facture est exprimé. Il est essentiel pour les organisations internationales qui utilisent plusieurs devises. Sans ce contexte, l’agrégation ou la comparaison des montants de factures n’aurait pas de sens. Il permet d’effectuer les conversions appropriées et de produire des rapports et des analyses financières exacts dans les différentes régions. Pourquoi c’est important Il fournit le contexte indispensable à tous les indicateurs financiers tels que le montant de la facture, évite les agrégations incorrectes et permet une analyse fiable dans les environnements multidevises. Où les obtenir Se trouve dans la table CustInvoiceJour, généralement dans un champ tel que CurrencyCode. Exemples USDEURGBP
	Intervention manuelle requise RequiresManualIntervention	Indicateur précisant si un paiement a nécessité un ajustement manuel lors de l'affectation des paiements.
Description Cet attribut booléen signale les paiements ayant nécessité une intervention ou une correction manuelle lors de l'affectation des paiements. Il est essentiel au KPI « Cash Application Discrepancy Rate », car il aide à mesurer la précision et le niveau d'automatisation de l'enregistrement des paiements. L'identification des causes de ces interventions manuelles, telles que l'absence d'informations de remise ou les écarts de paiement, peut contribuer à améliorer le processus et à augmenter le taux de traitement direct. Pourquoi c’est important Cet attribut aide à identifier les points de friction et les erreurs lors de l'affectation des paiements. Il est donc important pour améliorer l'automatisation et réduire les tâches manuelles. Où les obtenir Ces informations peuvent être déduites de l'utilisateur ayant enregistré le paiement, s'il ne s'agit pas d'un utilisateur système, ou de codes motif précis utilisés lors du rapprochement des paiements. Consultez la documentation de Microsoft Dynamics 365. Exemples truefalse
	Numéro de commande client SalesOrderNumber	L'identifiant de la commande client à l'origine de la facture.
Description Le numéro de commande client relie le processus de facturation au processus commercial qui le précède. Cette relation est particulièrement utile pour une analyse Order-to-Cash complète, de bout en bout. Elle permet d'étudier l'incidence de problèmes survenus lors de la vente ou de l'exécution de la commande, tels que des modifications de commande ou des retards d'expédition, sur le cycle de facturation. Vous pouvez par exemple répondre à la question suivante : « Les factures issues de commandes complexes mettent-elles plus de temps à être réglées ? » Pourquoi c’est important Cet attribut relie le processus de facturation au processus commercial en amont. Il permet ainsi de mener une analyse Order-to-Cash complète de bout en bout et d'identifier les causes profondes des problèmes de facturation. Où les obtenir Il se trouve dans l'en-tête de la facture ou dans le détail des lignes et renvoie à la commande client. Recherchez un champ tel que SalesId dans la table CustInvoiceJour. Exemples SO-009876SO-010234US-SO-00543
	Paiement à temps IsOnTimePayment	Indicateur précisant si le paiement du client a été reçu à la date d'échéance ou avant celle-ci.
Description Cet attribut booléen calculé compare l'horodatage « Customer Payment Received » à la « Payment Due Date ». Il indique pour chaque facture si le paiement a été reçu à temps ou en retard. Il constitue la base du calcul de l'indicateur « On-Time Payment Rate » et est largement utilisé dans le Dashboard « Payment Terms Adherence Analysis ». Il fournit un résultat binaire clair sur la performance des paiements, ce qui simplifie l'analyse et le reporting. Pourquoi c’est important Il mesure directement le respect des conditions de paiement par le client et sert de base à l'indicateur « On-Time Payment Rate », ce qui simplifie l'analyse de l'efficacité du recouvrement. Où les obtenir Cet attribut n'est pas présent dans le système source. Il est calculé lors de la transformation des données en comparant la date de paiement à PaymentDueDate. Exemples truefalse
	Reprise nécessaire IsRework	Indicateur précisant si le processus de facturation a comporté des activités de reprise, telles que plusieurs approbations.
Description Cet attribut booléen calculé signale les factures ayant fait l'objet d'une reprise. Celle-ci peut être définie par la présence de plusieurs événements « Invoice Approved » ou par des annulations de paiements. Cet attribut est conçu pour alimenter le Dashboard « Invoice Rework Analysis » et l'indicateur « Invoice Rework Rate ». En isolant ces cas, les analystes peuvent rechercher les causes profondes des reprises, qui révèlent souvent des inefficacités du processus, des problèmes de qualité des données ou des lacunes en matière de formation. Pourquoi c’est important Cet indicateur quantifie directement l'inefficacité du processus en identifiant les cas comportant des actions répétitives ou correctives. Il aide ainsi à déterminer les causes profondes des gaspillages et des retards. Où les 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 des schémas de reprise précis au sein d'un cas. Exemples truefalse
	Système source SourceSystem	Système depuis lequel les données ont été extraites.
Description Cet attribut identifie l’origine des données du processus. Dans ce contexte, il précise que les données proviennent de Microsoft Dynamics 365. Cette information est importante dans les environnements multisystèmes pour différencier les sources de données et garantir la traçabilité, ce qui facilite la validation des données et le dépannage. Pourquoi c’est important Il fournit un contexte essentiel sur l’origine des données, indispensable à la gouvernance et à la validation des données ainsi qu’à la fusion de données provenant de plusieurs systèmes d’entreprise. Où les obtenir Il s’agit d’une valeur statique ajoutée lors de l’extraction et de la transformation des données pour identifier l’origine du jeu de données. Exemples Microsoft Dynamics 365 FinanceD365 F&O

Obligatoire Recommandé Facultatif

Activités du processus Order to Cash - Facturation et émission des factures

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour une découverte et une analyse précises du processus.

7 Recommandé 5 Facultatif

	Activité	Description
	Date d’échéance du paiement atteinte	Événement calculé qui survient lorsque la date d’échéance de la facture est atteinte sans que le paiement ait été entièrement imputé. Cette activité ne correspond pas à une transaction dans le système, mais est déduite des données existantes.
Pourquoi c’est important Cet événement est essentiel pour analyser le taux de paiement dans les délais et identifier les factures qui deviennent échues. Il sert de point de déclenchement aux activités de recouvrement et de relance. Où les obtenir Cet événement n’est pas enregistré. Il est calculé à partir du champ DueDate de la table CustInvoiceJour. L’horodatage de l’événement correspond à la date d’échéance elle-même. Collecte Créer un événement dont l’horodatage correspond à la valeur du champ CustInvoiceJour.DueDate. Type d’événement calculated
	Facture approuvée	Marque la fin du processus de contrôle interne, au cours duquel la facture est officiellement approuvée. Cet événement est enregistré par le système de flux de travail Dynamics 365 et indique que la facture peut être envoyée au client.
Pourquoi c’est important Il s’agit d’une étape clé pour mesurer le délai du cycle d’approbation. Les retards à ce stade peuvent augmenter directement le délai global nécessaire pour recevoir le paiement du client. Où les obtenir Enregistré dans les tables d’historique du flux de travail, telles que WorkflowTrackingStatusTable, comme étape d’achèvement ou d’approbation de l’instance de flux de travail associée à la facture. Collecte Extrayez les journaux d’événements du flux de travail dont le statut est « Approved » ou « Completed ». Type d’événement explicit
	Facture clôturée	Cette activité marque l’état final d’une facture, dont le solde est nul parce qu’elle a été entièrement payée ou réglée au moyen d’avoirs. Il ne s’agit pas d’une transaction directe, mais d’un état déduit du statut financier de la facture.
Pourquoi c’est important Cet événement indique l’achèvement réussi du cycle Order to Cash pour une facture donnée. Le temps nécessaire pour atteindre cet état constitue une mesure essentielle de l’efficacité globale du processus. Où les obtenir Déduit en vérifiant que la transaction de facture dans la table CustTrans présente un solde restant nul. Cette vérification consiste à comparer le montant de la facture au montant total réglé qui lui est associé. Collecte Déduire cet événement des enregistrements CustTrans où AmountCur est égal à SettleAmountCur. L’horodatage correspond à 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, par voie électronique ou physique. Dans Dynamics 365, il peut s’agir d’un événement explicite si l’envoi est effectué par e-mail depuis le système, ou d’un événement déduit au moment de la validation si aucun suivi spécifique n’est activé.
Pourquoi c’est important Mesure l’efficacité du processus d’envoi des factures. Un délai entre l’approbation et l’envoi prolonge inutilement le cycle de paiement. Où les obtenir Peut être capturé explicitement dans les journaux d’e-mails, tels que SysOutgoingEmailTable, si les fonctionnalités de messagerie de D365 sont utilisées. Dans le cas contraire, il est souvent déduit comme correspondant à l’heure de validation de la facture dans CustInvoiceJour. Collecte Utiliser l’horodatage du journal d’e-mails s’il est disponible ; sinon, utiliser 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 client 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 clients.
Pourquoi c’est important Il s’agit du début officiel du cycle de facturation d’une facture. Cet événement est essentiel pour suivre le délai moyen de recouvrement (DSO) et la durée globale du processus. Où les obtenir Capturé à partir de l’horodatage de création de l’enregistrement de facture client validé dans la table CustInvoiceJour. Les transactions financières correspondantes sont créées dans les tables GeneralJournalEntry et LedgerEntry lors de la validation. Collecte Utiliser 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 enregistrant un paiement reçu d’un client. Elle indique que les fonds ont été reçus, mais qu’ils n’ont pas encore été imputés à une facture précise.
Pourquoi c’est important Il s’agit du point de départ pour mesurer le délai d’imputation des paiements. Cette étape distingue la réception des fonds de leur rapprochement effectif avec les factures impayées. Où les obtenir Capturé à partir de la création ou de la validation d’un journal de paiements clients. Cette opération est enregistrée dans des tables telles que LedgerJournalTrans, qui crée ensuite une transaction client dans CustTrans lors de la validation. Collecte Utiliser l’horodatage de validation du journal de paiement client dans LedgerJournalTable. Type d’événement explicit
	Paiement imputé à la facture	Représente le règlement d’un paiement client sur une facture précise, ce qui réduit le solde restant dû. Il s’agit d’une étape distincte dans Dynamics 365, qui relie la transaction de paiement à la transaction de facture.
Pourquoi c’est important Il s’agit d’une étape essentielle pour calculer précisément le DSO et comprendre l’efficacité de l’équipe chargée de l’imputation des paiements. Elle marque le moment où le paiement est entièrement rapproché avec le montant facturé. Où les obtenir Enregistré dans la table CustSettlement. Le champ de date de règlement de cette table fournit l’horodatage du moment où un paiement précis a été imputé à une transaction de facture précise. Collecte Utiliser TransDate ou CreatedDateTime depuis la table CustSettlement. Type d’événement explicit
	Avoir émis	Représente la création d’un avoir, généralement pour corriger une erreur de facturation, accorder un ajustement de prix ou comptabiliser des marchandises retournées. Un avoir est essentiellement une facture négative.
Pourquoi c’est important La fréquence des avoirs peut révéler des problèmes systémiques dans le processus d’exécution des commandes ou de facturation. Analyser les raisons de leur émission est essentiel pour améliorer le processus et réduire les pertes de revenus. Où les obtenir Il s’agit d’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 d’origine par un champ de référence. Collecte Identifier dans CustInvoiceJour les enregistrements dont le montant total est négatif et les relier à la facture d’origine. Type d’événement explicit
	Commande client exécutée	Cette activité indique que les marchandises ont été expédiées ou que les services ont été fournis pour une commande client, ce qui déclenche le processus de facturation. Elle est généralement déduite de la validation d’un bordereau d’expédition ou d’un bon de livraison dans Microsoft Dynamics 365, qui modifie le statut des lignes de commande concernées.
Pourquoi c’est important Cet événement constitue le point de départ pour mesurer le délai de génération de la facture. Comprendre le délai entre l’exécution de la commande et la facturation aide à identifier les goulots d’étranglement administratifs susceptibles d’affecter la trésorerie. Où les obtenir Déduit de la date de création d’une écriture de journal de bordereau d’expédition liée à la commande client. Cela implique notamment les tables CustPackingSlipJour et CustPackingSlipTrans, associées à la commande client sur laquelle repose la facture. Collecte Identifier la date de validation du dernier bordereau d’expédition 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 flux de travail formel d’approbation. Cette situation est courante dans les organisations dont les contrôles exigent une revue par la direction avant l’envoi d’une facture au client. L’événement est enregistré comme une étape précise dans le moteur de flux de travail D365.
Pourquoi c’est important Le suivi de la soumission pour approbation permet de distinguer le temps de création de la facture du temps d’attente avant approbation. Il s’agit de la première étape pour analyser l’efficacité des processus internes de revue et de contrôle. Où les obtenir Extrait des tables d’historique du flux de travail, telles que WorkflowTrackingStatusTable, en filtrant l’événement de soumission associé au document de facture. Collecte Extrayez les journaux d’événements du flux de travail dont le statut est « Submitted ». Type d’événement explicit
	Paiement annulé	Cette activité indique l’annulation d’un paiement client précédemment validé. Elle peut être due à des erreurs telles qu’une validation incorrecte, une insuffisance de provision ou un autre échec de paiement.
Pourquoi c’est important Les annulations de paiements 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’imputation des paiements. Où les obtenir Capturé comme une contrepassation dans le grand livre. Un journal annulé peut être identifié dans GeneralJournalEntry, souvent au moyen d’un indicateur spécifique ou de sa relation avec la transaction d’origine. Collecte Identifier les écritures de journal comportant un indicateur d’annulation ou une référence à une transaction annulée. Type d’événement explicit
	Rappel de paiement envoyé	Représente l’envoi d’une lettre de relance ou d’un avis de recouvrement à un client au sujet d’une facture échue. Dynamics 365 dispose d’un processus formel de relance qui génère et enregistre ces communications.
Pourquoi c’est important Le suivi des rappels permet d’é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ù les obtenir Il s’agit d’un événement explicite capturé à partir de la date de création du journal de lettre de recouvrement dans la table CustCollectionLetterJour, liée à la transaction de facture échue. Collecte Utiliser l’horodatage de création de la table CustCollectionLetterJour. Type d’événement explicit

Recommandé Facultatif

Guides d'extraction

Comment récupérer vos données depuis Microsoft Dynamics 365

Étapes

Accéder à l'espace de travail Data Management : Connectez-vous à Microsoft Dynamics 365 Finance and Operations. Utilisez la barre de recherche pour trouver et ouvrir l'espace de travail Data management. Il s'agit du 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 Data management, cliquez sur la vignette Export pour créer un projet d'exportation de données. Donnez-lui un nom explicite, tel que ProcessMind_O2C_Billing_Export, ainsi qu'une description.
Sélectionner le format de données cible : Dans la configuration du projet, indiquez le Target data format. Pour assurer la compatibilité avec la plupart des outils de transformation des données, sélectionnez CSV. Configurez les options de format selon vos besoins, en veillant à utiliser un délimiteur et un qualificateur de texte communs.
Ajouter les entités de données requises : Il s'agit de l'étape la plus importante. Vous allez ajouter plusieurs entités de données standard à votre projet afin de recueillir toutes les activités nécessaires. Pour chaque entité, cliquez sur Add entity et recherchez le nom indiqué dans la section Query/Script. Ajoutez à votre projet chacune des entités suivantes : Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement et Dunning history letters.
Appliquer des filtres aux entités : Pour limiter les données à un périmètre pertinent, appliquez des filtres à vos entités. Au minimum, filtrez Sales invoice headers V2 sur InvoiceDate pour une période donnée, par exemple les six derniers mois. Filtrez également les entités sur les entités juridiques, ou sociétés, que vous souhaitez analyser.
Exécuter le projet d'exportation : Une fois toutes les entités ajoutées et les filtres appliqués, cliquez sur le bouton Export dans le volet d'action. Le système crée un package de traitement et commence l'extraction des données en arrière-plan.
Suivre et télécharger les données : Vous pouvez suivre l'avancement du projet dans la section Job history. Une fois le projet terminé, vous pouvez télécharger le package de données exporté. Celui-ci est un fichier ZIP contenant un fichier CSV distinct pour chaque entité de données.
Décompresser le package : Extrayez le contenu du fichier ZIP téléchargé dans un dossier local. Vous disposez alors de plusieurs fichiers CSV, un pour chaque entité.
Transformer et regrouper les données : Les fichiers bruts doivent être transformés en un journal d'événements unique. Utilisez un outil de préparation des données tel que Power Query, Python ou une zone de staging de base de données. Pour chaque fichier source, créez les colonnes requises : InvoiceNumber (Case ID), ActivityName (valeur codée en dur représentant l'événement, telle que « Invoice Generated ») et EventTime (champ de date pertinent du fichier source). Mappez les autres attributs, tels que InvoiceAmount et CustomerName.
Effectuer l'union de toutes les données transformées : Regroupez les données transformées de tous les fichiers sources dans une table unique à l'aide d'une opération d'union ou d'ajout. Vous obtenez ainsi le journal d'événements final et unifié, dans lequel chaque ligne représente une activité du cycle de vie de la facture.
Mettre en forme les données avant importation : Vérifiez que le fichier CSV final contient les en-têtes de colonnes corrects (InvoiceNumber, ActivityName, EventTime, etc.) et que la colonne EventTime utilise un format d'horodatage cohérent, par exemple YYYY-MM-DD HH:MI:SS. Le fichier est alors prêt à être importé dans ProcessMind.

Configuration

Entités de données : L'extraction repose sur un ensemble d'entités de données D365 standard. Les principales entités sont 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'affectation des paiements) et Workflow tracking status table (pour les approbations).
Format d'exportation : Le format de données cible recommandé est CSV, en raison de sa large compatibilité avec les outils de transformation des données.
Filtrage par période : Il est essentiel d'appliquer un filtre de période aux entités principales, en particulier à Sales invoice headers V2 sur le champ InvoiceDate. Une période de trois à six mois est recommandée afin de conserver un export gérable tout en disposant de suffisamment de données pour l'analyse.
Filtrage par société : L'exportation doit être filtrée sur l'entité juridique ou le code société analysé, afin de garantir la pertinence des données et de réduire la taille de l'export.
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 regroupés et restructurés dans un format de journal d'événements unique. Cette opération s'effectue généralement avec des outils tels que Power BI (Power Query), Python ou SQL.
Prérequis : L'utilisateur qui exécute l'exportation doit disposer des rôles de sécurité appropriés dans Dynamics 365, notamment d'un rôle autorisant l'accès à l'espace de travail Data management et 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 : Vérifiez que Python 3.6 ou une version ultérieure est installé avec les bibliothèques requests et pandas. Vous aurez également besoin des identifiants d’un principal de service (inscription d’application) dans Azure Active Directory, auquel l’accès à l’environnement Dynamics 365 Finance & Operations a été accordé.
Inscription de l’application : Dans Azure AD, inscrivez une nouvelle application. Créez un secret client et notez l’ID d’application (client), l’ID de répertoire (locataire) et le secret client. Dans Dynamics 365, ajoutez cet ID d’application sous System administration > Setup > Azure Active Directory applications et attribuez-lui les droits utilisateur appropriés pour lire les entités de données requises.
Configurez le script : Ouvrez le script Python fourni. Renseignez les variables de configuration situées en haut du script, notamment d365_url, tenant_id, client_id, client_secret, company, start_date et end_date. d365_url doit correspondre à 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 API suivants.
Extraction des données : Exécutez le script depuis votre terminal avec python your_script_name.py. Le script commence par récupérer toutes les factures client validées (CustInvoiceJour) dans la période indiquée. Pour chaque facture, il effectue ensuite des appels API supplémentaires afin de récupérer les données associées à des activités telles que les paiements, les règlements, les avoirs et l’historique du flux de travail.
Génération des activités : Le script traite les données brutes provenant de plusieurs points de terminaison 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 'Invoice Generated' et interroge l’entité CustSettlement pour créer les événements 'Cash Applied to Invoice'.
Événements calculés : Notez que des événements tels que 'Payment Due Date Reached' et 'Invoice Closed' ne correspondent pas à des transactions directes dans Dynamics 365. Le script déduit ces événements à partir de la date d’échéance, du statut et de l’historique des règlements de la facture, puis crée les entrées correspondantes dans le journal d’événements.
Gestion de la pagination : La fonction auxiliaire fetch_all_data gère automatiquement la pagination. Les API OData de Dynamics 365 renvoient un nombre limité d’enregistrements par page. Cette fonction suit donc le lien @odata.nextLink fourni dans la réponse de l’API afin de récupérer l’ensemble des données.
Transformation et sortie des données : Après avoir recueilli tous les événements, le script les regroupe dans une liste unique, la convertit en DataFrame pandas et standardise les noms de colonnes en InvoiceNumber, ActivityName, EventTime ainsi que les autres attributs requis.
Exportation au format CSV : Enfin, le script enregistre le DataFrame obtenu dans un fichier CSV nommé d365_billing_event_log.csv. Ce fichier est mis en forme et prêt à être importé dans ProcessMind ou dans un autre outil de Process Mining.

Configuration

URL D365 : URL de base de votre instance Dynamics 365 Finance & Operations. Il s’agit du point de terminaison 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. Ils doivent correspondre à une application disposant d’un accès en lecture aux entités D365 concernées.
Société : indiquez le DataAreaId, qui correspond à l’entité juridique de Dynamics 365 depuis laquelle vous souhaitez extraire les données, par exemple « USMF ».
Période : définissez une start_date et une end_date pour limiter le périmètre de l’extraction. Pour une première analyse, il est recommandé de sélectionner une période de 3 à 6 mois afin de conserver un volume de données gérable tout en couvrant suffisamment de variantes du processus.
Principales entités OData : le script interroge principalement les entités suivantes : CustInvoiceJours, CustSettlements, CustTrans, CustCollectionLetterJours et WorkflowTrackingStatusTables. Vérifiez que l’utilisateur configuré dispose des autorisations de lecture sur l’ensemble de ces entités.
Performances : l’extraction de données sur une longue période ou depuis une très grande société peut être lente, car elle repose sur plusieurs appels d’API séquentiels. Il est conseillé d’exécuter le script en dehors des heures de pointe et de commencer par une période plus courte afin d’estimer la durée totale d’exécution.

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()

Prêt à commencer ?

Commencez à optimiser votre facturation et l’émission de vos factures à l’aide de ce modèle. Donnez à votre équipe les analyses nécessaires pour améliorer l’efficacité et la trésorerie.

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

Mettez fin aux retards de facturation : optimisez aujourd'hui votre processus Order-to-Cash et votre facturation

Réduisez de 30 % la durée du cycle de facturation et obtenez plus rapidement une vision claire de votre situation financière.

Démarrer l'essai gratuit

Aucune carte bancaire requise. Essai gratuit de 14 jours.

Votre modèle de données Order to Cash - Billing & Invoicing

Votre modèle de données Order to Cash - Billing & Invoicing

Attributs du processus Order to Cash - Facturation et émission des factures

Activités du processus Order to Cash - Facturation et émission des factures

Guides d'extraction

Export des entités 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 à commencer ?

Mettez fin aux retards de facturation : optimisez aujourd'hui votre processus Order-to-Cash et votre facturation

Votre modèle de données Order to Cash - Billing & Invoicing

Votre modèle de données Order to Cash - Billing & Invoicing

Attributs du processus Order to Cash - Facturation et émission des factures

Activités du processus Order to Cash - Facturation et émission des factures

Guides d'extraction

Export des entités 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 à commencer ?

Mettez fin aux retards de facturation : optimisez aujourd'hui votre processus Order-to-Cash et votre facturation

Nous attachons de l’importance à votre confidentialité