> Amélioration continue des processus > Facturation, de la commande à l’encaissement > Microsoft Dynamics 365 > Modèle de données

Votre modèle de données pour le processus de facturation, de la commande à l’encaissement

Microsoft Dynamics 365

← Retour au guide d’amélioration

Attributs du processus de facturation, de la commande à l’encaissement(18) Activités du processus de facturation, de la commande à l’encaissement(12) Guides d’extraction(2)

Votre modèle de données pour le processus de facturation, de la commande à l’encaissement

Ce modèle vous indique clairement quelles données recueillir pour analyser votre processus de facturation, de la commande à l’encaissement. Vous y trouverez les attributs à inclure dans votre journal d’événements, les principales activités à suivre et des conseils pratiques pour extraire ces informations. Il vous aide à préparer rapidement vos données pour le Process Mining.

Attributs recommandés à recueillir
Activités clés à suivre
Conseils d’extraction pour Microsoft Dynamics 365

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs du processus de facturation, de la commande à l’encaissement

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail le processus de facturation, de la commande à l’encaissement.

3 Obligatoire 6 Recommandé 9 Facultatif

	Nom	Description
	Numéro de facture InvoiceNumber	Identifiant unique de chaque facture client, utilisé comme identifiant principal de cas pour le processus de facturation.
Description Le numéro de facture est la clé centrale qui regroupe toutes les activités liées à un même document de facturation. Il permet d’analyser l’ensemble du cycle de vie de la facture, de sa création et de son approbation au paiement par le client et à sa clôture. Utilisé comme ID de cas, il associe chaque entrée du journal d’événements à une facture précise et permet d’analyser les variantes, de calculer les temps de cycle et de suivre les performances de chaque transaction de facturation. Pourquoi est-ce important ? Cet attribut est essentiel pour suivre tout le cycle de vie d’une facture et analyser l’efficacité du processus, ses goulots d’étranglement et ses écarts pour chaque document de facturation. Où trouver ces données Cette information se trouve généralement dans le module Ventes et marketing, dans des tables comme CustInvoiceJour (champ InvoiceId), ou est accessible par l’intermédiaire d’entités de données comme 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’heure de l’événement, également appelée horodatage, enregistre la date et l’heure exactes de chaque activité du processus. Ces données sont indispensables à toutes les analyses temporelles en process mining. Elles servent à calculer les temps de cycle entre les activités, à mesurer la durée totale d’un cas et à comprendre l’évolution des performances du processus. Des horodatages exacts et fiables sont à la base d’indicateurs comme le délai moyen de paiement client et le temps de création des factures. Pourquoi est-ce important ? Cet attribut est à la base de toutes les analyses de performance et de durée. Il permet de calculer les temps de cycle, les durées et le débit afin de mesurer l’efficacité du processus. Où trouver ces données Les horodatages proviennent de différents champs de date et d’heure répartis dans plusieurs tables de Dynamics 365, par exemple CreatedDateTime dans la table CustInvoiceJour pour la création des factures, ou des horodatages spécifiques de l’historique des 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é ou de l’événement métier 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 « Facture créée », « Facture approuvée » ou « Paiement du client reçu ». L’enchaînement de ces activités forme le flux du processus. Leur analyse est fondamentale pour le process mining : elle permet de découvrir des modèles de processus, de repérer les variantes et de mesurer les performances entre les différentes étapes. Pourquoi est-ce important ? Cet attribut définit les étapes du processus. Il permet de visualiser les cartes de processus, d’analyser les variantes et de repérer les goulots d’étranglement ou les écarts par rapport à la procédure standard. Où trouver ces données Cet attribut est généralement établi à partir de plusieurs sources, comme les champs de changement de statut (par exemple DocumentState), les champs de date renseignés ou l’historique des flux de travail dans Microsoft Dynamics 365. Exemples Facture crééeFacture approuvéePaiement du client reçuAvoir émis
	Date d’échéance du paiement PaymentDueDate	Date à laquelle le client est censé avoir réglé la facture.
Description La date d’échéance du paiement est calculée à partir de la date de facture et des conditions de paiement du client. Elle sert de référence pour mesurer le respect des délais de paiement. Cet attribut est essentiel au Dashboard « Analyse du respect des conditions de paiement » et au calcul d’indicateurs clés de performance tels que le taux de paiement à temps et le délai moyen de paiement client. La comparaison de cette date avec la date réelle de paiement révèle les comportements de paiement des clients et l’efficacité du processus de recouvrement. Pourquoi est-ce important ? Cette date sert de référence pour mesurer les délais de paiement. Elle est indispensable au calcul du taux de paiement à temps et à l’analyse du respect des conditions de paiement des clients. Où trouver ces données 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	Montant total de la facture.
Description Cet attribut correspond au montant total dû au titre de la facture. Cette métrique est essentielle à l’analyse financière, car elle permet de répartir les factures selon leur montant. Les analystes peuvent, par exemple, examiner les factures de montant élevé pour comprendre les comportements de paiement ou déterminer si leur approbation prend plus de temps. Cet attribut sert aussi à calculer le montant total des factures impayées et le délai moyen de paiement client. Pourquoi est-ce important ? Il permet d’analyser l’impact financier en filtrant et en répartissant les processus selon leur montant, afin de donner la priorité aux factures les plus élevées et d’étudier leur déroulement. Où trouver ces données 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é adressée.
Description Le nom du client permet d’identifier clairement l’entreprise ou la personne facturée. Dans une analyse de Process Mining, il est possible de répartir le processus de facturation par client. Vous pouvez ainsi repérer les clients qui paient régulièrement à temps, ceux qui sont souvent en retard, ou les groupes de clients confrontés à des variations ou à des délais particuliers. Cet attribut est essentiel aux Dashboards sur les comportements de paiement des clients et à l’analyse du délai moyen de paiement client. Pourquoi est-ce important ? Il permet de répartir l’analyse du processus par client et de repérer les comportements de paiement, les habitudes ou les problèmes propres à chacun. Où trouver ces données Cette information est obtenue en reliant les données de facturation à la table de référence des clients, généralement CustTable, à partir du numéro de compte client. Exemples Contoso Ltd.Fabrikam, Inc.Northwind Traders
	Service Department	Service de l’entreprise associé à l’utilisateur ou à l’activité.
Description Cet attribut associe une activité ou un utilisateur à un service précis, comme « Comptabilité clients » ou « Ventes ». Il donne une vue des performances du processus à l’échelle du service, plutôt qu’à celle de chaque utilisateur. L’analyse par service aide à comprendre les transferts entre équipes, à comparer leur efficacité et à repérer les goulots d’étranglement, comme le demande le Dashboard « Charge d’activité du service de facturation ». Pourquoi est-ce important ? Il permet d’analyser les performances à l’échelle de l’organisation, de comparer l’efficacité des équipes et de comprendre l’incidence des transferts entre services sur le processus. Où trouver ces données Cette information ne figure généralement pas directement dans la transaction de facture. Elle est obtenue en reliant l’identifiant UserResponsible à l’annuaire des employés ou des utilisateurs, qui contient les informations sur les services. Exemples Comptabilité clientsFinanceOpérations de facturation
	Statut de la facture InvoiceStatus	État actuel de la facture dans son cycle de vie (par exemple, ouverte, payée ou annulée).
Description Cet attribut indique où en est la facture. Il précise si elle attend toujours un paiement, a été réglée intégralement, est en retard ou a été annulée par un avoir. Vous pouvez l’utiliser pour filtrer les dossiers et n’analyser que les factures ouvertes, ou pour vérifier 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. Pourquoi est-ce important ? Il donne rapidement une vue de l’état actuel de la facture, utile pour filtrer les dossiers et comprendre les résultats des différentes variantes du processus. Où trouver ces données Cet attribut peut être déduit du statut de paiement de la facture, par exemple en vérifiant si le solde de l’enregistrement CustTrans associé est nul. Il n’existe pas toujours de champ unique « statut ». Exemples OuvertePayéeEn retardAnnulée
	Utilisateur responsable UserResponsible	Utilisateur ou employé chargé d’exécuter une activité donnée.
Description Cet attribut identifie la personne qui a effectué une tâche du 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 repérer les besoins de formation. Par exemple, le Dashboard « Charge d’activité du service de facturation » 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 aide également à comprendre l’affectation des ressources et l’efficacité du processus. Pourquoi est-ce important ? Il permet d’analyser les ressources, de repérer 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ù trouver ces données Ces données peuvent provenir des journaux d’historique des 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
	Avec reprises IsRework	Indicateur précisant si le processus de facturation a comporté des reprises, par exemple plusieurs approbations.
Description Cet attribut booléen calculé signale les factures ayant fait l’objet de reprises. Celles-ci peuvent être définies par la présence de plusieurs événements « Facture approuvée » ou par des annulations de paiement. Cet attribut est conçu pour alimenter le Dashboard « Analyse des reprises de factures » et l’indicateur de taux de reprises des factures. En isolant ces dossiers, les analystes peuvent rechercher les causes profondes des reprises, souvent liées à des inefficacités du processus, à des problèmes de qualité des données ou à des besoins de formation. Pourquoi est-ce important ? Cet indicateur quantifie directement les inefficacités du processus en repérant les dossiers comportant des actions répétées ou correctives. Il aide ainsi à identifier les causes profondes des pertes de temps et des retards. Où trouver ces données 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 reprises précis dans un dossier. Exemples truefalse
	Conditions de paiement PaymentTerms	Conditions convenues pour le paiement d’une facture (par exemple, net à 30 jours ou net à 60 jours).
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 un axe important pour analyser les comportements de paiement. Le Dashboard « Analyse du respect des conditions de paiement » s’en sert pour regrouper les clients et les factures, et déterminer si certaines conditions sont plus efficaces que d’autres ou sont associées à davantage de retards de paiement. Pourquoi est-ce important ? Il explique pourquoi une facture arrive à échéance à une date donnée et permet de répartir l’analyse pour vérifier si certaines conditions de paiement sont associées à des retards. Où trouver ces données Cette information est généralement enregistrée dans la fiche client, puis copiée dans l’en-tête de la facture. Recherchez un champ Payment ou PaymTermId dans la table CustInvoiceJour. Exemples Net à 30 joursNet à 60 joursÀ réception
	Délai moyen de paiement client DaysSalesOutstanding	Nombre de jours entre la création de la facture et la réception du paiement du client.
Description Le délai moyen de paiement client (DSO) est une métrique financière qui mesure le nombre moyen de jours nécessaires à une entreprise pour recevoir le paiement d’une vente. Cet attribut calculé détermine ce délai pour chaque facture. Il constitue la métrique principale du Dashboard « Analyse des tendances du délai moyen de paiement client » et de l’indicateur DSO. Son analyse aide à gérer la trésorerie et à évaluer l’efficacité des fonctions de crédit et de recouvrement. Pourquoi est-ce important ? Cet indicateur clé de performance permet d’évaluer la santé de la trésorerie d’une entreprise et l’efficacité de son processus de recouvrement. Il mesure la rapidité avec laquelle le chiffre d’affaires est converti en liquidités. Où trouver ces données Cet attribut ne figure pas dans le système source. Il est calculé à partir du délai entre les activités « Facture créée » et « Paiement du client reçu ». Exemples 284592
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation des données de cet événement depuis le système source.
Description Cet attribut indique la date de la dernière extraction ou mise à jour des données depuis Microsoft Dynamics 365. Ce champ de métadonnées est essentiel pour évaluer leur fraîcheur. Les analystes et les utilisateurs métier peuvent ainsi vérifier qu’ils consultent les informations les plus récentes. Il est également utile pour gérer les calendriers d’actualisation et garantir la fiabilité des analyses. Pourquoi est-ce important ? Il permet aux utilisateurs de savoir à quand remontent les données, une information importante pour leur gouvernance, la gestion de l’actualisation des Dashboards et la fiabilité des analyses au fil du temps. Où trouver ces données 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 la devise du montant de la facture (par exemple, USD ou EUR).
Description Cet attribut indique la devise dans laquelle le montant de la facture est exprimé. Il est indispensable aux organisations internationales qui utilisent plusieurs devises. Sans cette information, il serait impossible d’agréger ou de comparer les montants des factures de façon pertinente. Elle permet de convertir correctement les devises et d’établir des rapports et des analyses financières fiables dans les différentes régions. Pourquoi est-ce important ? Il apporte le contexte nécessaire à l’interprétation des métriques financières, comme le montant de la facture, évite les agrégations erronées et permet des analyses fiables dans les environnements multidevises. Où trouver ces données 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 son affectation.
Description Cet attribut booléen signale les paiements qui ont nécessité une intervention ou une correction manuelle lors de leur affectation. Il est essentiel au calcul de l’indicateur de taux d’écarts d’affectation des paiements, car il permet de mesurer la précision et le niveau d’automatisation de l’enregistrement des paiements. L’identification des causes d’intervention manuelle, comme l’absence d’informations de remise ou les écarts de paiement, peut aider à améliorer le processus et à augmenter le taux de traitement sans intervention. Pourquoi est-ce important ? Cet attribut aide à repérer les difficultés et les erreurs lors de l’affectation des paiements, afin d’améliorer l’automatisation et de réduire les interventions manuelles. Où trouver ces données Cette information peut être déduite de l’utilisateur ayant enregistré le paiement, s’il ne s’agit pas d’un compte système, ou des codes de motif utilisés lors du rapprochement des paiements. Consultez la documentation de Microsoft Dynamics 365. Exemples truefalse
	Numéro de commande client SalesOrderNumber	Identifiant de la commande client à l’origine de la facture.
Description Le numéro de commande client relie le processus de facturation au processus de vente qui le précède. Ce lien est précieux pour analyser l’ensemble du processus Order-to-Cash, de bout en bout. Les analystes peuvent ainsi étudier comment des problèmes liés aux ventes ou à l’exécution des commandes, comme des modifications de commande ou des retards d’expédition, influent sur le cycle de facturation. Par exemple, il permet de répondre à la question suivante : « Les factures liées à des commandes complexes sont-elles réglées plus tard ? » Pourquoi est-ce important ? Cet attribut relie le processus de facturation au processus de vente en amont. Il permet d’analyser l’ensemble du processus Order-to-Cash de bout en bout et d’identifier les causes profondes des problèmes de facturation. Où trouver ces données Se trouve dans l’en-tête ou les lignes de la facture et renvoie à la commande client. Recherchez un champ tel que SalesId dans la table CustInvoiceJour. Exemples SO-009876SO-010234US-SO-00543
	Paiement reçu à temps IsOnTimePayment	Indicateur précisant si le paiement du client a été reçu au plus tard à la date d’échéance.
Description Cet attribut booléen calculé compare l’horodatage de l’activité « Paiement du client reçu » à la date d’échéance du paiement. 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 de taux de paiement à temps et est largement utilisé dans le Dashboard « Analyse du respect des conditions de paiement ». Il fournit un résultat binaire clair sur les délais de paiement, ce qui simplifie l’analyse et les rapports. Pourquoi est-ce important ? Il mesure directement le respect des conditions de paiement par les clients et sert de base à l’indicateur de taux de paiement à temps, ce qui simplifie l’analyse de l’efficacité du recouvrement. Où trouver ces données Cet attribut ne figure pas dans le système source. Il est calculé lors de la transformation des données en comparant la date de paiement à PaymentDueDate. Exemples truefalse
	Système source SourceSystem	Le système dont les données ont été extraites.
Description Cet attribut indique l’origine des données de processus. Ici, il précise qu’elles proviennent de Microsoft Dynamics 365. Cette information est importante dans les environnements qui utilisent plusieurs systèmes : elle permet de distinguer les sources et de retracer clairement le parcours des données, ce qui facilite leur validation et la résolution des problèmes. Pourquoi est-ce important ? Il apporte un contexte essentiel sur l’origine des données, notamment pour leur gouvernance et leur validation, ainsi que pour la fusion de données issues de plusieurs systèmes d’entreprise. Où trouver ces données Cette valeur statique est ajoutée au jeu de données lors de l’extraction et de la transformation des données afin d’en indiquer l’origine. Exemples Microsoft Dynamics 365 FinanceD365 F&O

Obligatoire Recommandé Facultatif

Activités du processus de facturation, de la commande à l’encaissement

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir et analyser le processus avec précision.

7 Recommandé 5 Facultatif

	Activité	Description
	Date d’échéance du paiement atteinte	Événement calculé qui survient lorsque la facture arrive à échéance sans que le paiement ait été entièrement affecté. Cette activité ne correspond pas à une transaction dans le système : elle est déduite des données existantes.
Pourquoi est-ce important ? Cet événement permet d’analyser les paiements effectués à temps et de repérer les factures qui commencent à être en retard. Il marque le début des démarches de recouvrement et de relance. Où trouver ces données Cet événement n’est pas enregistré directement. Il est calculé à partir du champ DueDate de la table CustInvoiceJour. L’horodatage de l’événement correspond à la date d’échéance. Données à recueillir Créez un événement dont l’horodatage correspond à la valeur du champ CustInvoiceJour.DueDate. Type d’événement calculated
	Facture approuvée	Marque la fin de la vérification interne et l’approbation formelle de la facture. Le système de flux de travail Dynamics 365 enregistre cet événement, qui indique que la facture peut être envoyée au client.
Pourquoi est-ce important ? Cette étape clé permet de mesurer le temps de cycle d’approbation. Un retard à ce stade peut allonger directement le délai avant le paiement du client. Où trouver ces données L’événement est enregistré dans les tables d’historique des flux de travail, comme WorkflowTrackingStatusTable, comme étape d’approbation ou de fin pour l’instance de flux de travail associée à la facture. Données à recueillir Extrayez les journaux d’événements des 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 de la situation financière de la facture.
Pourquoi est-ce important ? Cet événement marque la fin réussie du cycle de commande à encaissement pour une facture donnée. Le temps nécessaire pour atteindre cet état est un indicateur essentiel de l’efficacité globale du processus. Où trouver ces données Cet état est déduit en vérifiant que le solde restant de la transaction de facture dans la table CustTrans est nul. Pour le déterminer, comparez le montant de la facture au montant total réglé. Données à recueillir Déduisez l’événement des enregistrements CustTrans pour lesquels AmountCur est égal à SettleAmountCur. L’horodatage correspond à la date du dernier règlement. Type d’événement inferred
	Facture créée	Correspond à la création et à la comptabilisation de la facture de vente dans le système. Cette transaction explicite dans Dynamics 365 crée un document légal et des écritures financières dans le sous-grand livre des comptes clients.
Pourquoi est-ce important ? Il s’agit du début officiel du cycle de facturation. Cet événement est essentiel pour suivre le délai moyen de paiement client (DSO) et la durée globale du processus. Où trouver ces données L’événement est enregistré à partir de l’horodatage de création de la facture de vente comptabilisée dans la table CustInvoiceJour. Lors de la comptabilisation, les transactions financières correspondantes sont créées dans les tables GeneralJournalEntry et LedgerEntry. Données à recueillir Utilisez le champ CreatedDateTime de la table CustInvoiceJour pour la facture comptabilisée. Type d’événement explicit
	Facture envoyée au client	Cette activité correspond au moment où la facture est transmise au client, par voie électronique ou physique. Dans Dynamics 365, l’envoi peut être enregistré explicitement s’il est effectué par courriel depuis le système. Si aucun suivi spécifique n’est activé, il peut être déduit de l’heure de comptabilisation.
Pourquoi est-ce important ? Cette mesure évalue l’efficacité de l’envoi des factures. Un délai entre l’approbation et l’envoi prolonge inutilement le cycle de paiement. Où trouver ces données L’envoi peut être enregistré explicitement dans les journaux de courriels, comme SysOutgoingEmailTable, si vous utilisez les fonctionnalités de messagerie de D365. Sinon, il est souvent déduit de l’heure de comptabilisation de la facture dans CustInvoiceJour. Données à recueillir Utilisez l’horodatage du journal de courriels s’il est disponible ; sinon, utilisez celui de la comptabilisation de la facture. Type d’événement inferred
	Paiement affecté à la facture	Correspond au règlement d’une facture précise au moyen d’un paiement client, qui réduit le solde impayé de la facture. Dans Dynamics 365, cette étape distincte relie la transaction de paiement à celle de la facture.
Pourquoi est-ce important ? Cette étape clé permet de calculer précisément le DSO et d’évaluer l’efficacité de l’équipe chargée de l’affectation des paiements. Elle marque le rapprochement complet du paiement avec le montant facturé. Où trouver ces données L’événement est enregistré dans la table CustSettlement. Le champ de date de règlement de cette table fournit l’horodatage auquel un paiement précis a été affecté à une transaction de facture donnée. Données à recueillir Utilisez TransDate ou CreatedDateTime dans la table CustSettlement. Type d’événement explicit
	Paiement du client reçu	Cette activité marque la création d’une écriture de journal qui enregistre un paiement reçu d’un client. Elle indique que les fonds ont été reçus, mais pas encore affectés à une facture précise.
Pourquoi est-ce important ? C’est le point de départ pour mesurer le délai d’affectation des paiements. Il permet de distinguer la réception des fonds de leur rapprochement avec les factures impayées. Où trouver ces données L’événement est enregistré lors de la création ou de la comptabilisation d’un journal de paiement client. Il figure dans des tables comme LedgerJournalTrans, puis crée une transaction client dans CustTrans lors de la comptabilisation. Données à recueillir Utilisez l’horodatage de comptabilisation du journal de paiement client dans LedgerJournalTable. Type d’événement explicit
	Avoir émis	Correspond à la création d’un avoir, généralement pour corriger une erreur de facturation, accorder un ajustement de prix ou comptabiliser un retour de marchandises. Un avoir équivaut à une facture négative.
Pourquoi est-ce important ? Des avoirs fréquents peuvent signaler des problèmes systémiques dans le traitement des commandes ou la facturation. Comprendre pourquoi ils sont émis est essentiel pour améliorer le processus et limiter les pertes de revenus. Où trouver ces données Cette transaction explicite est enregistrée dans la table CustInvoiceJour comme une nouvelle facture comptabilisée d’un montant négatif. Elle est souvent liée à la facture d’origine par un champ de référence. Données à recueillir Repérez dans CustInvoiceJour les enregistrements dont le montant total est négatif et associez-les à la facture d’origine. Type d’événement explicit
	Commande client exécutée	Cette activité marque le moment où les marchandises ont été expédiées ou les services fournis dans le cadre d’une commande client, ce qui déclenche le processus de facturation. Dans Microsoft Dynamics 365, elle est généralement déduite de la comptabilisation d’un journal de bons de livraison, qui modifie le statut des lignes de commande concernées.
Pourquoi est-ce important ? Cet événement marque le début de la mesure du temps de cycle de création des factures. Comprendre le délai entre l’exécution de la commande et la facturation aide à repérer les goulots d’étranglement administratifs susceptibles de peser sur la trésorerie. Où trouver ces données Déduit de la date de création d’une écriture de journal de bon de livraison liée à la commande client. Les tables concernées comprennent notamment CustPackingSlipJour et CustPackingSlipTrans, associées à la commande sur laquelle repose la facture. Données à recueillir Repérez la date de comptabilisation la plus récente d’un 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 créée a été soumise à un flux de travail formel d’approbation. C’est courant dans les entreprises où les contrôles imposent une validation par la direction avant l’envoi de la facture au client. Le moteur de flux de travail de D365 enregistre cette étape.
Pourquoi est-ce important ? Le suivi de la soumission pour approbation permet de distinguer le temps de création de la facture du temps d’attente de l’approbation. C’est la première étape pour analyser l’efficacité des processus internes de contrôle et de vérification. Où trouver ces données L’événement est enregistré dans les tables d’historique des flux de travail, comme WorkflowTrackingStatusTable, en filtrant les événements de soumission associés au document de facture. Données à recueillir Extrayez les journaux d’événements des flux de travail dont le statut est « Submitted ». Type d’événement explicit
	Paiement contrepassé	Cette activité indique la contrepassation d’un paiement client précédemment comptabilisé. Elle peut être due à une erreur de comptabilisation, à une provision insuffisante ou à un autre échec de paiement.
Pourquoi est-ce important ? Les contrepassations de paiement révèlent des erreurs opérationnelles ou des problèmes liés aux paiements des clients. L’analyse de leur fréquence aide à en déterminer les causes profondes et à améliorer la précision de l’affectation des paiements. Où trouver ces données L’événement est enregistré comme une contrepassation dans le grand livre. Une écriture de journal contrepassée peut être repérée dans GeneralJournalEntry, souvent grâce à un indicateur spécifique ou à son lien avec la transaction d’origine. Données à recueillir Repérez les écritures de journal comportant un indicateur de contrepassation ou une référence à une transaction contrepassée. Type d’événement explicit
	Rappel de paiement envoyé	Correspond à l’envoi au client d’une lettre de relance ou d’un avis de recouvrement concernant une facture en retard. Dynamics 365 dispose d’un processus formel de relance qui génère et enregistre ces communications.
Pourquoi est-ce important ? Le suivi des rappels permet d’évaluer l’efficacité des relances et d’analyser le nombre de rappels nécessaires avant la réception d’un paiement. Où trouver ces données Cet événement explicite est enregistré à partir de la date de création du journal de lettres de recouvrement dans la table CustCollectionLetterJour, liée à la transaction de facture en retard. Données à recueillir Utilisez l’horodatage de création de la table CustCollectionLetterJour. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Microsoft Dynamics 365

Étapes

Ouvrez l’espace de travail Gestion des données : Connectez-vous à Microsoft Dynamics 365 Finance and Operations. Recherchez l’espace de travail Data management dans la barre de recherche, puis ouvrez-le. Il centralise les opérations d’import et d’export de données.
Créez un projet d’export : Dans l’espace de travail Data management, cliquez sur la tuile Export pour créer un projet d’export de données. Donnez-lui un nom explicite, par exemple ProcessMind_O2C_Billing_Export, et ajoutez une description.
Choisissez le format des données : Dans la configuration du projet, indiquez le Target data format. Pour assurer la compatibilité avec la plupart des outils de transformation de données, sélectionnez CSV. Configurez les options de format, notamment le séparateur et le caractère de délimitation du texte.
Ajoutez les entités de données requises : Cette étape est essentielle. Ajoutez plusieurs entités de données standard au projet afin de recueillir toutes les activités nécessaires. Pour chaque entité, cliquez sur Add entity, puis recherchez le nom indiqué dans la section Query/Script. Ajoutez les entités suivantes : Sales invoice headers V2, Sales packing slip headers, Workflow tracking status table, CustPaymentJournalLineEntity, Customer settlement et Dunning history letters.
Appliquez des filtres aux entités : Limitez les données à la période pertinente en appliquant des filtres. Au minimum, filtrez Sales invoice headers V2 sur le champ InvoiceDate pour une période définie, par exemple les six derniers mois. Filtrez également les entités juridiques (sociétés) que vous souhaitez analyser.
Lancez l’export : Une fois 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 lance l’extraction des données en arrière-plan.
Suivez l’opération et téléchargez les données : Consultez l’avancement dans la section Job history. Une fois l’opération terminée, téléchargez le package de données exportées. Il s’agit d’un fichier ZIP contenant un fichier CSV distinct pour chaque entité.
Décompressez le package : Extrayez le contenu du fichier ZIP téléchargé dans un dossier local. Vous disposerez alors de plusieurs fichiers CSV, un par entité.
Transformez et rassemblez 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 comme Power Query, Python ou une zone de préparation dans une base de données. Pour chaque fichier source, créez les colonnes requises : InvoiceNumber (ID de cas), ActivityName (valeur fixe représentant l’événement, par exemple « Facture générée ») et EventTime (champ de date pertinent du fichier source). Associez les autres attributs, comme InvoiceAmount et CustomerName.
Réunissez toutes les données transformées : Combinez les données transformées de tous les fichiers sources dans une seule table à l’aide d’une opération d’union ou d’ajout. Vous obtiendrez ainsi le journal d’événements final, dans lequel chaque ligne correspond à une activité du cycle de vie d’une facture.
Préparez le fichier pour l’importation : Vérifiez que le fichier CSV final comporte les en-têtes de colonne appropriés (InvoiceNumber, ActivityName, EventTime, etc.) et que la colonne EventTime utilise un format d’horodatage cohérent (par exemple, AAAA-MM-JJ HH:MI:SS). Le fichier est alors prêt à être importé dans ProcessMind.

Configuration

Entités de données : L’extraction s’appuie sur des entités de données standard de D365. Parmi les principales figurent Sales invoice headers V2 (factures et avoirs), Sales packing slip headers (exécution des commandes), CustPaymentJournalLineEntity (paiements), Customer settlement (affectation des paiements reçus) et Workflow tracking status table (approbations).
Format d’export : Le format de données cible recommandé est CSV, compatible avec de nombreux outils de transformation de données.
Filtrage par période : Il est essentiel d’appliquer un filtre de dates aux principales entités, en particulier à Sales invoice headers V2 sur le champ InvoiceDate. Une période de 3 à 6 mois est recommandée pour limiter la taille de l’export tout en disposant de suffisamment de données pour l’analyse.
Filtrage par société : Filtrez l’export sur l’entité juridique ou le code société que vous analysez afin de garantir la pertinence des données et d’en réduire le volume.
Préparation et transformation des données : Une étape de traitement après l’export, en dehors de Dynamics 365, est nécessaire. Les fichiers exportés doivent être réunis et restructurés pour former un journal d’événements unique. Cette opération s’effectue généralement avec Power BI (Power Query), Python ou SQL.
Prérequis : La personne qui lance l’export doit disposer des rôles de sécurité appropriés dans Dynamics 365, notamment des autorisations d’accès à l’espace de travail Data management et aux entités de données requises.

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é, ainsi que 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 (environnement) et le secret client. Dans Dynamics 365, ajoutez l’ID de cette application sous System administration > Setup > Azure Active Directory applications et attribuez-lui les droits nécessaires pour lire les entités de données requises.
Configurez le script : Ouvrez le script Python fourni. Renseignez les variables de configuration 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 dans votre terminal avec la commande python your_script_name.py. Le script commence par récupérer toutes les factures clients comptabilisées (CustInvoiceJour) dans la période définie. Pour chaque facture, il effectue ensuite des appels API supplémentaires afin de récupérer les données associées aux paiements, aux règlements, aux avoirs et à l’historique des 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 « Facture générée » et interroge l’entité CustSettlement pour créer les événements « Paiement affecté à la facture ».
Événements calculés : Certains événements, comme « Échéance de paiement atteinte » et « Facture clôturée », ne correspondent pas à des transactions directes dans Dynamics 365. Le script les déduit 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 pour récupérer l’ensemble des données.
Transformation et sortie des données : Une fois tous les événements recueillis, le script les rassemble dans une liste, la convertit en DataFrame pandas et uniformise les noms des colonnes : InvoiceNumber, ActivityName, EventTime et les autres attributs requis.
Export au format CSV : Enfin, le script enregistre le DataFrame obtenu dans un fichier CSV nommé d365_billing_event_log.csv. Ce fichier est prêt à être importé dans ProcessMind ou 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 API.
Identifiants Azure AD : Les variables client_id, client_secret et tenant_id sont nécessaires à l’authentification. Elles doivent correspondre à une application autorisée à lire les entités D365 concernées.
Société : Indiquez le DataAreaId correspondant à l’entité juridique Dynamics 365 dont vous souhaitez extraire les données, par exemple « USMF ».
Période : Définissez start_date et end_date pour limiter l’extraction. Pour une première analyse, une période de 3 à 6 mois est recommandée afin de conserver un volume de données gérable tout en couvrant suffisamment de variations 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é est autorisé à lire ces entités.
Performances : L’extraction d’une longue période ou des données d’une très grande société peut prendre du temps, car elle nécessite plusieurs appels API successifs. Il est conseillé d’exécuter le script en dehors des heures de pointe et de commencer par une période plus courte pour estimer la durée totale.

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 ?

Utilisez ce modèle pour commencer à optimiser votre processus de facturation. Donnez à votre équipe les éléments nécessaires pour gagner en efficacité et améliorer la trésorerie.

Retour au guide d’amélioration

Télécharger le modèle

Mettez fin aux retards de facturation : optimisez dès aujourd’hui votre processus, de la commande à l’encaissement

Réduisez de 30 % le temps de cycle de facturation et obtenez plus rapidement une vision claire de votre situation financière.

Démarrez votre essai gratuit

Aucune carte bancaire requise. Essai gratuit de 14 jours.

Votre modèle de données pour le processus de facturation, de la commande à l’encaissement

Votre modèle de données pour le processus de facturation, de la commande à l’encaissement

Attributs du processus de facturation, de la commande à l’encaissement

Activités du processus de facturation, de la commande à l’encaissement

Guides d’extraction

Export des entités de données de Microsoft Dynamics 365

Étapes

Configuration

Exemple de requête config

Script Python utilisant l’API web OData de Dynamics 365

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Mettez fin aux retards de facturation : optimisez dès aujourd’hui votre processus, de la commande à l’encaissement

Votre modèle de données pour le processus de facturation, de la commande à l’encaissement

Votre modèle de données pour le processus de facturation, de la commande à l’encaissement

Attributs du processus de facturation, de la commande à l’encaissement

Activités du processus de facturation, de la commande à l’encaissement

Guides d’extraction

Export des entités de données de Microsoft Dynamics 365

Étapes

Configuration

Exemple de requête config

Script Python utilisant l’API web OData de Dynamics 365

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Mettez fin aux retards de facturation : optimisez dès aujourd’hui votre processus, de la commande à l’encaissement

Prêt à commencer ?

Mettez fin aux retards de facturation : optimisez dès aujourd’hui votre processus, de la commande à l’encaissement