> Amélioration continue des processus > Gestion du crédit et recouvrement > Microsoft Dynamics 365 > Modèle de données

Votre modèle de données pour la gestion du crédit et le recouvrement

Microsoft Dynamics 365

Attributs de gestion du crédit et de recouvrement (19) Activités de gestion du crédit et de recouvrement (12) Guides d’extraction (2)

Votre modèle de données pour la gestion du crédit et le recouvrement

Ce modèle vous guide dans la collecte des données nécessaires à l’analyse de vos processus de gestion du crédit et du recouvrement. Il présente les attributs essentiels, les principales activités à suivre et des conseils pratiques pour extraire les données. Appuyez-vous sur cette ressource pour préparer vos données et commencer plus rapidement votre analyse Process Mining.

Attributs recommandés pour une analyse complète
Activités clés à suivre pour une découverte précise
Conseils pratiques pour extraire les données de votre système

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 de gestion du crédit et de recouvrement

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail vos processus de gestion du crédit et du recouvrement.

3 Obligatoire 8 Recommandé 8 Facultatif

	Nom	Description
	Heure de l’événement EventTime	Horodatage indiquant le moment où une activité ou un événement précis s’est produit.
Description L’heure de l’événement correspond à la date et à l’heure précises auxquelles une activité a été enregistrée dans le système. Elle est indispensable pour établir l’ordre chronologique des événements, reconstituer le déroulement du processus et calculer les indicateurs temporels. Cet attribut est essentiel pour analyser les durées, repérer les goulots d’étranglement et suivre les SLA. Par exemple, l’écart entre les événements « Facture générée » et « Paiement reçu » sert à calculer le délai moyen de paiement client (DSO), un indicateur clé de performance. Sans horodatages exacts, il est impossible d’analyser les performances et de repérer les goulots d’étranglement. Pourquoi est-ce important ? Cet horodatage est indispensable pour ordonner les événements, découvrir la carte du processus et calculer les indicateurs de performance, comme les temps de cycle et les durées. Où trouver ces données Cet attribut provient de différents champs de date et d’heure des tables D365, comme « CreatedDateTime » dans « CustInvoiceJour » ou « TransDate » dans « CustTrans », selon l’activité concernée. Exemples 2023-01-15T09:30:00Z2023-02-28T14:12:55Z2023-03-20T11:05:10Z
	Nom de l’activité ActivityName	Nom de l’événement ou de la tâche qui s’est produit à une étape du cycle de vie de la facture.
Description Le nom de l’activité décrit une étape ou un événement précis du processus de gestion du crédit et du recouvrement, par exemple « Facture générée », « Lettre de relance envoyée » ou « Paiement reçu ». Cet attribut est fondamental en Process Mining, car il définit les nœuds de la carte du processus. L’analyse de l’ordre et de la fréquence de ces activités révèle le déroulement réel du processus et permet de repérer les reprises, les inefficacités et les parcours non conformes. Il sert directement à créer les visualisations du processus et à calculer les temps de cycle entre ses différentes étapes. Pourquoi est-ce important ? Cet attribut définit les étapes de la carte du processus et permet de visualiser et d’analyser le cycle de vie des factures. Où trouver ces données Cet attribut est généralement obtenu en associant des événements système, des changements de statut ou des dates de création d’enregistrements provenant de différentes tables, comme « CustInvoiceJour », « CustTrans », « CustCollectionLetterJour » et « CustPaymPromise », à des noms d’activité normalisés. Exemples Facture comptabilisée et envoyéeLettre de relance généréeLitige enregistréPaiement reçu
	Numéro de facture InvoiceNumber	Identifiant unique de chaque facture client, utilisé comme identifiant principal du cas dans le processus de gestion du crédit.
Description Le numéro de facture est un attribut essentiel qui identifie de manière unique chaque transaction financière avec un client. Il relie toutes les activités associées, de la création et de la comptabilisation de la facture au recouvrement du paiement et au règlement final. En Process Mining, ce numéro sert à reconstituer le parcours complet de chaque facture et à analyser en détail son cycle de vie. En suivant chaque facture comme un cas distinct, les organisations peuvent repérer les parcours récurrents, les goulots d’étranglement et les écarts par rapport à la procédure standard. Il constitue la base du calcul d’indicateurs clés comme le délai moyen de paiement client et de l’analyse des variantes du processus. Pourquoi est-ce important ? Il s’agit de l’ID de cas essentiel qui relie tous les événements du processus et permet de reconstituer et d’analyser l’ensemble du cycle de vie, de la facture à l’encaissement. Où trouver ces données Il s’agit généralement du champ « Invoice » de la table « CustInvoiceJour » dans Microsoft Dynamics 365 Finance. Exemples INV-0012345CIV-2023-8876SI-9510034
	Agent de recouvrement affecté CollectorAssigned	Nom de l’agent de recouvrement ou du membre de l’équipe chargé de gérer la facture en retard.
Description Cet attribut identifie la personne chargée des activités de recouvrement pour une facture donnée. Il est essentiel pour analyser les performances et la charge de travail. En filtrant la carte du processus ou les Dashboards par agent, les responsables peuvent évaluer la productivité individuelle, comparer les stratégies de recouvrement et repérer les besoins d’accompagnement. Cet attribut est une dimension clé des Dashboards « Productivité de l’équipe de recouvrement » et « Temps de cycle de résolution des litiges », car il permet de relier les résultats du processus à des personnes ou à des équipes précises. Pourquoi est-ce important ? Permet d’analyser les performances de l’équipe de recouvrement, d’équilibrer la charge de travail et de repérer les bonnes pratiques en comparant l’efficacité des agents. Où trouver ces données Consultez la documentation de Microsoft Dynamics 365. Cette information peut être liée à un module de gestion du recouvrement ou aux champs de responsabilité des utilisateurs dans les fiches client ou les enregistrements de transaction. Exemples John SmithEmily JonesÉquipe de recouvrement A
	Date d’échéance du paiement PaymentDueDate	Date à laquelle le paiement de la facture doit être effectué selon les conditions contractuelles.
Description La date d’échéance du paiement est un attribut temporel essentiel, défini par les conditions de paiement convenues avec le client. Elle sert de référence pour déterminer si une facture est en retard et déclenche les activités de recouvrement, comme l’envoi de rappels ou le lancement d’une procédure formelle de relance. En Process Mining, elle permet de calculer le nombre de jours de retard et de vérifier le respect des règles de relance, par exemple en contrôlant qu’un rappel a été envoyé dans les X jours suivant l’échéance. Pourquoi est-ce important ? Cette date sert de référence pour mesurer le respect des délais de paiement et déclenche les activités liées aux retards et au recouvrement. Où trouver ces données Généralement disponible dans le champ « DueDate » des tables « CustTrans » ou « CustInvoiceJour ». Exemples 2023-02-142023-03-312023-04-30
	Jours de retard DaysOverdue	Nombre de jours écoulés depuis la date d’échéance du paiement d’une facture.
Description Le nombre de jours de retard est un indicateur calculé qui mesure le temps écoulé depuis la date d’échéance du paiement d’une facture impayée. Il correspond à la date du jour moins la date d’échéance. Cet indicateur clé aide l’équipe de recouvrement à déterminer quelles factures traiter en priorité. Il figure au premier plan du Dashboard « Factures en retard par segment » et permet d’évaluer la situation des comptes clients ainsi que l’efficacité des démarches de recouvrement. Pourquoi est-ce important ? Cet indicateur opérationnel est essentiel pour prioriser les démarches de recouvrement et mesurer l’ampleur des retards de paiement. Où trouver ces données Il s’agit d’un champ calculé. La logique est la suivante : IF Invoice is unpaid THEN (Today() - PaymentDueDate) ELSE 0. Exemples 1532910
	Montant de la facture InvoiceAmount	Montant total de la facture.
Description Le montant de la facture correspond à la valeur totale des biens ou des services facturés. Cet attribut fondamental permet d’analyser les données financières du processus. Il permet de regrouper les cas par montant afin de vérifier si les factures élevées suivent un parcours différent ou connaissent des retards plus longs. Il est essentiel aux Dashboards « Passages en perte de factures irrécouvrables » et « Analyse de la gestion des limites de crédit », qui permettent de quantifier l’impact financier et d’évaluer les risques. Pourquoi est-ce important ? Permet d’analyser l’impact financier, de prioriser les factures de montant élevé et de comprendre comment leur valeur influe sur le déroulement du processus. Où trouver ces données Il s’agit probablement du champ « InvoiceAmount » de la table « CustInvoiceJour ». Exemples 1500.7525000.00549.99
	Niveau de relance DunningLevel	Indique l’étape ou le degré de gravité de la procédure de relance et de recouvrement pour une facture en retard.
Description Le niveau de relance correspond à une étape d’une procédure structurée, par exemple « Niveau 1 : rappel courtois », « Niveau 2 : avis formel » ou « Niveau 3 : dernier avertissement ». Le suivi de cet attribut est essentiel pour évaluer l’efficacité de la stratégie de recouvrement. Le Dashboard « Efficacité de la stratégie de relance » indique, à l’aide de cet attribut, le pourcentage de factures payées après chaque niveau de relance. Les entreprises peuvent ainsi améliorer leurs flux de travail de relance pour obtenir les paiements plus efficacement tout en préservant la relation client. Pourquoi est-ce important ? Cet attribut est essentiel pour mesurer l’efficacité de la stratégie de relance et déterminer à quelle étape les clients sont le plus susceptibles de payer. Où trouver ces données Cette information figure dans les tables liées au recouvrement et aux lettres de relance, comme « CustCollectionLetterJour ». Exemples 123 - Dernier niveauAction en justice
	Nom du client CustomerName	Raison sociale du client auquel la facture a été adressée.
Description Le nom du client identifie le client associé à une facture. Cet attribut est une dimension essentielle pour le filtrage et la segmentation. L’analyse du processus par client permet de repérer ceux qui paient régulièrement en retard, contestent leurs factures ou nécessitent de nombreuses démarches de recouvrement. C’est un attribut clé du Dashboard « Temps de cycle de résolution des litiges » et de toute analyse détaillée de comptes clients particuliers. Pourquoi est-ce important ? Permet d’analyser le processus pour chaque client, de repérer des tendances et de gérer les relations avec les comptes importants ou problématiques. Où trouver ces données Cette information est généralement obtenue en reliant la table « CustTable » au numéro de compte client figurant dans « CustInvoiceJour ». Exemples Contoso Ltd.Adventure WorksFabrikam Inc.
	Segment de clientèle CustomerSegment	Classification des clients selon leur taille, leur secteur d’activité ou leur importance stratégique, par exemple.
Description Le segment de clientèle est un attribut catégoriel qui regroupe les clients en catégories pertinentes, comme « Comptes stratégiques », « PME » ou « Secteur public ». Cette segmentation est essentielle à l’analyse stratégique. Elle permet de répondre à des questions telles que « Le délai moyen de paiement est-il plus court pour les comptes stratégiques ? » ou « Les passages en perte sont-ils plus fréquents dans certains secteurs ? ». Cet attribut est utilisé directement dans les Dashboards « Évolution du délai moyen de paiement client », « Passages en perte de factures irrécouvrables » et « Factures en retard par segment » pour dégager des tendances au-delà des comptes individuels. Pourquoi est-ce important ? Permet d’analyser des groupes de clients pour repérer les tendances stratégiques et adapter les stratégies de recouvrement à chaque segment. Où trouver ces données Il s’agit souvent d’un champ personnalisé ou d’une valeur déduite des attributs de « CustTable », la table principale des clients. Exemples EntrepriseMarché intermédiaireSecteur publicPartenaire
	Statut de la facture InvoiceStatus	Statut actuel de la facture dans son cycle de vie.
Description Le statut de la facture indique où elle en est dans le processus, par exemple « Ouverte », « Payée », « Contestée » ou « Passée en perte ». Le journal des activités fournit un historique détaillé, tandis que le statut actuel est un attribut utile au niveau du cas pour le filtrage et les rapports de synthèse. Les analystes peuvent ainsi segmenter rapidement les données pour se concentrer sur les factures ouvertes en retard ou étudier les caractéristiques des factures passées en perte. C’est un moyen simple de connaître l’état actuel des comptes clients. Pourquoi est-ce important ? Permet de filtrer et d’analyser rapidement les factures selon leur état actuel, par exemple pour se concentrer sur les cas ouverts ou contestés. Où trouver ces données Déduit du statut de règlement des transactions dans la table « CustTrans ». Une transaction ouverte n’est pas payée, tandis qu’une transaction clôturée est réglée. Exemples OuvertePayéePartiellement payéePassée en perte
	Code de devise CurrencyCode	Devise de la facture, par exemple USD ou EUR.
Description Le code de devise indique la devise de transaction du montant de la facture. Cet attribut contextuel est important, notamment pour les organisations multinationales. Il est nécessaire pour interpréter correctement les montants et peut servir à déterminer si les cycles de paiement ou les problèmes rencontrés sont liés à certaines devises, par exemple en raison des opérations de change ou de la complexité des paiements internationaux. Pourquoi est-ce important ? Fournit le contexte nécessaire à l’interprétation des montants et permet d’analyser les processus impliquant plusieurs devises. Où trouver ces données Généralement disponible dans le champ « CurrencyCode » de la table « CustInvoiceJour ». Exemples USDEURGBPCAD
	Dernière mise à jour des données LastDataUpdate	Horodatage du dernier actualisation ou de la dernière mise à jour des données.
Description Cet attribut indique la dernière mise à jour du jeu de données à partir du système source. Ces métadonnées sont essentielles pour les utilisateurs de l’analyse du processus, car elles précisent l’actualité des données. Savoir jusqu’à quelle date les données sont à jour aide les analystes à prendre des décisions éclairées et à comprendre la portée de leurs conclusions. Cet attribut est généralement appliqué à l’ensemble du jeu de données lors de son ingestion. Pourquoi est-ce important ? Indique aux utilisateurs l’actualité des données, afin que les analyses portent sur une période connue et que les décisions ne reposent pas sur des informations obsolètes. Où trouver ces données Cette valeur est générée et ajoutée au jeu de données par le pipeline ETL ou de données lors de son exécution. Exemples 2023-04-01T02:00:00Z2023-04-02T02:00:00Z
	Limite de crédit CreditLimit	Montant maximal de crédit autorisé pour le client.
Description La limite de crédit correspond au montant total de la dette qu’un client est autorisé à contracter. Cet attribut est essentiel à la gestion des risques. Le Dashboard « Analyse de la gestion des limites de crédit » compare cette valeur aux montants des factures des comptes en retard ou passés en perte. Cette analyse permet de déterminer si les limites sont adaptées et respectées, et si les clients défaillants ont récemment bénéficié d’une augmentation de leur limite, ce qui peut révéler des faiblesses dans le processus d’approbation du crédit. Pourquoi est-ce important ? Cet attribut est essentiel à l’évaluation des risques et permet de déterminer si les passages en perte sont liés à des limites de crédit client mal gérées ou insuffisantes. Où trouver ces données Cette valeur est généralement enregistrée dans la fiche principale du client, dans « CustTable ». Exemples 10000.0050000.000.00
	Litige signalé IsDisputed	Indicateur booléen précisant si une facture a déjà fait l’objet d’un litige.
Description Cet indicateur calculé prend la valeur true si le cas d’une facture contient une activité « Litige enregistré ». Il simplifie l’analyse en permettant de filtrer ou de comparer facilement les parcours des factures contestées et non contestées. Par exemple, il est possible de comparer le délai moyen de paiement des factures contestées à celui des factures non contestées afin de mesurer l’incidence des litiges sur la trésorerie. Cet attribut est utile pour les Dashboards de synthèse et les analyses comparatives. Pourquoi est-ce important ? Simplifie l’analyse et le filtrage en facilitant la comparaison des factures contestées et non contestées. Où trouver ces données Il s’agit d’un champ calculé. La logique est la suivante : IF the case contains a 'Dispute Registered' activity THEN true ELSE false. Exemples truefalse
	Motif du litige DisputeReason	Motif invoqué par le client pour contester une facture.
Description Lorsqu’un client conteste une facture, il en indique généralement le motif, par exemple « Erreur de prix », « Marchandise endommagée » ou « Facturation en double ». Cet attribut consigne ce motif. L’analyse des motifs de litige est essentielle pour en rechercher les causes profondes. Elle permet de repérer les problèmes récurrents dans le processus de la commande à l’encaissement, par exemple au sein des équipes commerciales, d’expédition ou de facturation. Réduire les litiges à la source est un objectif important de cette analyse, car cela influe directement sur le délai moyen de paiement client en évitant les retards de paiement. Pourquoi est-ce important ? Fournit des données essentielles pour rechercher les causes profondes des retards de paiement et repérer les problèmes en amont qui entraînent des contestations de factures. Où trouver ces données Consultez la documentation de Microsoft Dynamics 365. Cette information relève des fonctionnalités de gestion des litiges ou des dossiers. Exemples Erreur de prixQuantité insuffisanteProduit non reçuService non conforme à la description
	Pays Country	Pays de l’adresse de facturation du client.
Description Cet attribut indique le pays associé au compte client. Il s’agit d’une dimension courante pour les analyses géographiques. La segmentation par pays d’indicateurs du processus, comme le délai moyen de paiement client ou le taux de passage en perte, peut révéler des différences régionales dans les habitudes de paiement, l’efficacité du recouvrement ou la situation économique. Ces constats peuvent conduire à adapter les stratégies de recouvrement à chaque zone géographique ou à proposer des conditions de paiement différentes selon les régions. Pourquoi est-ce important ? Permet une analyse géographique pour repérer les tendances régionales en matière de paiement et de performance du processus de recouvrement. Où trouver ces données Cette information est obtenue en reliant la fiche principale du client (« CustTable ») à son adresse principale, souvent enregistrée dans « LogisticsPostalAddress ». Exemples USADEUGBRCAN
	Système source SourceSystem	Identifie le système d’origine des données.
Description Cet attribut indique l’application source dans laquelle les données de l’événement ont été enregistrées. Dans ce contexte, il s’agirait de « Microsoft Dynamics 365 ». Même s’il peut sembler fixe dans une analyse portant sur un seul système, il est essentiel à la gouvernance des données, au dépannage et aux futures intégrations. Si des données d’autres systèmes, comme un CRM distinct ou un portail d’agence de recouvrement, étaient ajoutées, ce champ permettrait de les distinguer et de comprendre le processus dans son ensemble, entre plusieurs systèmes. Pourquoi est-ce important ? Assure une traçabilité claire des données et contribue au maintien de leur qualité ainsi qu’à l’analyse de plusieurs systèmes intégrés. Où trouver ces données Il s’agit généralement d’une valeur fixe ajoutée lors de l’extraction des données pour indiquer l’origine des enregistrements. Exemples Microsoft Dynamics 365D365 F&O
	Temps de résolution du litige DisputeResolutionTime	Temps écoulé entre l’enregistrement initial d’un litige client et sa résolution.
Description Le temps de résolution du litige mesure l’efficacité du processus de traitement des litiges. Il correspond à la durée entre les activités « Litige enregistré » et « Litige résolu ». Une résolution tardive peut retarder le paiement et nuire à la satisfaction client. L’analyse de cet indicateur par agent de recouvrement ou par motif de litige permet de repérer les goulots d’étranglement et les améliorations possibles dans le flux de travail de gestion des litiges. Pourquoi est-ce important ? Mesure l’efficacité du traitement des litiges, souvent à l’origine de retards de paiement importants. Où trouver ces données Calculé à partir de la durée entre les horodatages des activités « Litige enregistré » et « Litige résolu ». Exemples 7.215.83.5

Obligatoire Recommandé Facultatif

Activités de gestion du crédit et de recouvrement

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir avec précision votre flux de travail de gestion du crédit et du recouvrement.

9 Recommandé 3 Facultatif

	Activité	Description
	Date d’échéance du paiement dépassée	Cet événement calculé se produit lorsque la date du jour dépasse la date d’échéance de la facture. Il ne correspond pas à une action directe de l’utilisateur, mais est déduit en comparant la date du système au champ de date d’échéance de la facture.
Pourquoi est-ce important ? Cet événement déclenche toutes les activités de recouvrement. Il permet d’analyser le volume de factures échues et la rapidité des relances, et de suivre des indicateurs tels que le respect de la politique de relance. Où trouver ces données L’événement est calculé en comparant l’horodatage actuel au champ « DueDate » de la table des transactions client (CustTrans). L’horodatage de l’événement correspond à la valeur de DueDate. Données à recueillir Créez un événement lorsque « NOW() » est supérieur à la valeur DueDate de la facture. Type d’événement calculated
	Facture comptabilisée et envoyée	Indique l’enregistrement officiel de la facture dans le grand livre, qui la transforme en créance client formelle. Cet événement coïncide généralement avec l’envoi de la facture au client et est enregistré à la fin de la procédure de comptabilisation dans Dynamics 365.
Pourquoi est-ce important ? Cette étape marque officiellement le début du délai de paiement et du calcul de l’ancienneté de la créance. Les retards entre la création et la comptabilisation peuvent révéler des inefficacités dans le processus de facturation. Où trouver ces données L’événement est déduit de la date de comptabilisation dans le journal des factures client (CustInvoiceJour) ou d’un changement de statut à « Comptabilisé ». L’horodatage de comptabilisation est la donnée clé. Données à recueillir Utilisez l’horodatage de comptabilisation du journal des factures client (CustInvoiceJour). Type d’événement inferred
	Facture créée	Indique la création d’un enregistrement de facture de vente dans le système, avant sa comptabilisation officielle. Cette activité correspond généralement à un événement explicite enregistré lorsqu’un utilisateur finalise une commande client et génère la facture correspondante.
Pourquoi est-ce important ? Il s’agit de l’événement de début du cycle de vie de la facture. L’analyse du délai entre cette étape et le paiement est essentielle pour mesurer le délai moyen de paiement client. Où trouver ces données L’événement est enregistré dans la table Sales Invoice Header (SalesInvoiceHeader) ou Sales Table (SalesTable) lors de la création de la facture. L’horodatage de création de l’enregistrement sert d’heure d’événement. Données à recueillir Capturez l’horodatage de création de l’enregistrement de la facture de vente. Type d’événement explicit
	Facture passée en perte	La facture est considérée comme irrécouvrable et passée officiellement en perte au titre des créances douteuses. Cette opération est effectuée explicitement par un utilisateur autorisé ; elle solde la créance et comptabilise la perte.
Pourquoi est-ce important ? C’est le principal point d’aboutissement négatif du processus. Le suivi des passages en perte est essentiel pour comprendre le risque de crédit, les échecs de recouvrement et les pertes financières. Où trouver ces données Enregistré à partir d’une transaction spécifique du journal général, utilisée pour passer une créance douteuse en perte et liée à la facture d’origine. La date de comptabilisation du journal de passage en perte sert d’horodatage. Données à recueillir Repérez les écritures de journal associées à un profil de comptabilisation spécifique pour les passages en perte et faisant référence à la facture. Type d’événement explicit
	Facture réglée	La facture est entièrement payée et son solde est nul, ce qui marque la réussite du processus. Ce statut est déduit lorsque la somme des paiements affectés correspond au montant total de la facture.
Pourquoi est-ce important ? C’est le principal point d’aboutissement positif du processus de la commande à l’encaissement. L’analyse des parcours qui y mènent met en évidence les bonnes pratiques et les variantes les plus efficaces. Où trouver ces données Déduit de la date de règlement dans la table des règlements clients (CustSettlement). Cela se produit lorsque la somme des champs « AmountCur » et « SettleAmountCur » de la facture dans CustTrans est égale à zéro. Données à recueillir Repérez la date de règlement la plus récente associée à la transaction de facture qui ramène son solde à zéro. Type d’événement inferred
	Lettre de relance générée	Indique qu’une lettre officielle de relance ou de recouvrement a été créée pour la facture échue. L’événement est enregistré lors de l’exécution du processus périodique de relance dans Dynamics 365, qui génère des enregistrements de lettres pour les factures concernées.
Pourquoi est-ce important ? Cet événement suit le lancement et la fréquence des actions officielles de recouvrement. Il est essentiel pour mesurer l’efficacité des relances et le respect des politiques de recouvrement internes. Où trouver ces données Un enregistrement explicite est créé dans la table de l’historique des relances (CustCollectionLetterJour). La date de création du journal des lettres de relance sert d’horodatage. Données à recueillir Extrayez les événements de création de la table CustCollectionLetterJour et associez-les à la facture correspondante. Type d’événement explicit
	Litige enregistré	Indique que le client a officiellement contesté la facture et que son statut a été mis à jour en conséquence. En général, cet événement est enregistré lorsqu’un utilisateur attribue le statut « Disputed » à la facture dans le module de gestion du recouvrement.
Pourquoi est-ce important ? C’est le point de départ du processus de résolution des litiges. Le suivi de cet événement permet de mesurer la fréquence des litiges et le temps nécessaire à leur résolution, deux facteurs qui influent sur la satisfaction client et la trésorerie. Où trouver ces données Déduit d’un changement de statut de la transaction client (CustTrans) ou d’une table associée à la gestion des litiges (smmCaseDetail). Un journal horodaté des changements de statut est nécessaire. Données à recueillir Repérez le moment où le champ de statut du litige associé à une transaction de facture est renseigné ou passe à « Disputed ». Type d’événement inferred
	Paiement comptabilisé	Correspond à la comptabilisation officielle du paiement client dans le grand livre et à son affectation au règlement d’une facture. Cet événement est enregistré à partir de la date de comptabilisation du journal de paiement client.
Pourquoi est-ce important ? Cette étape clôt la partie paiement du processus. Le temps écoulé entre la réception et la comptabilisation du paiement, appelé délai d’affectation des paiements, est un indicateur clé de l’efficacité du service financier. Où trouver ces données Enregistré à partir de l’horodatage de comptabilisation du journal des paiements clients (LedgerJournalTrans). Il confirme que le paiement a été entièrement traité dans le grand livre. Données à recueillir Utilisez la date de comptabilisation du journal des paiements clients comptabilisé. Type d’événement explicit
	Paiement reçu	Indique qu’un paiement du client a été reçu et saisi dans le système, généralement dans un journal de paiement. Cet événement précède la comptabilisation définitive et l’affectation du paiement à la facture concernée.
Pourquoi est-ce important ? Cette étape est essentielle au calcul du délai moyen de paiement client et à l’analyse de la trésorerie. Le temps écoulé entre cet événement et la comptabilisation du paiement révèle les goulots d’étranglement dans le processus d’affectation des paiements. Où trouver ces données Événement explicite enregistré à partir de la date de création d’une ligne de journal de paiement client (LedgerJournalTrans), avant sa comptabilisation. Il correspond à la date à laquelle le paiement a été enregistré comme reçu. Données à recueillir Utilisez la date de transaction des lignes du journal des paiements clients. Type d’événement explicit
	Activité de recouvrement enregistrée	Indique une action manuelle de recouvrement, comme un appel téléphonique ou un courriel, enregistrée pour un client ou une facture. L’événement est capturé lorsqu’un agent utilise la fonctionnalité Activités de l’espace de travail du recouvrement pour consigner ses échanges.
Pourquoi est-ce important ? Cet événement donne de la visibilité sur le travail manuel de l’équipe de recouvrement. La comparaison de ces activités avec les paiements reçus permet de mesurer la productivité de l’équipe et l’efficacité des différents moyens de contact. Où trouver ces données L’activité est enregistrée dans les tables Activités (smmActivities) ou dans les tables associées de gestion des dossiers liées au compte client. Si possible, associez-la à une facture précise. Données à recueillir Capturez la création des enregistrements Activity dont le type est « Phone Call » ou « Email » et qui concernent le recouvrement. Type d’événement explicit
	Litige résolu	Marque la fin du processus de traitement du litige, lorsqu’une solution a été trouvée et consignée. Cet événement est enregistré lorsqu’un utilisateur attribue le statut « Resolved » au litige associé à une facture ou clôt le dossier correspondant.
Pourquoi est-ce important ? Cette activité clôt le sous-processus de traitement du litige. La durée entre l’enregistrement et la résolution du litige est un indicateur clé de l’efficacité de l’équipe chargée de sa résolution. Où trouver ces données Déduit d’un changement de statut de la transaction client (CustTrans) ou de la clôture du dossier de litige associé (smmCaseDetail). L’horodatage de ce changement de statut correspond à l’heure de l’événement. Données à recueillir Repérez le moment où le champ de statut du litige associé à une facture est effacé ou passe à « Resolved ». Type d’événement inferred
	Promesse de paiement créée	Le client s’engage à effectuer un paiement à une date ultérieure précise, et cet engagement est consigné dans le système. L’événement est enregistré explicitement lorsqu’un agent de recouvrement saisit une promesse de paiement dans le module de recouvrement.
Pourquoi est-ce important ? Cet événement suit les accords de paiement informels et leur taux de respect. La comparaison des promesses avec les paiements réellement reçus peut aider à prévoir la trésorerie et à évaluer la fiabilité des clients. Où trouver ces données L’enregistrement se trouve probablement dans les tables liées à l’espace de travail du recouvrement ou à la gestion des dossiers, notamment celles qui gèrent les promesses de paiement. La date de création de l’enregistrement de la promesse sert d’heure d’événement. Données à recueillir Relevez les événements de création dans une table détaillée des promesses de paiement ou des dossiers de recouvrement. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Microsoft Dynamics 365

Étapes

Vérifiez les prérequis : Assurez-vous que votre organisation utilise Microsoft Dynamics 365 Finance et que la fonctionnalité Bring Your Own Database (BYOD) est configurée pour exporter activement les entités de données vers une base de données Azure SQL. Vous devez disposer d’identifiants autorisant la lecture de cette base.
Identifiez les entités de données : Vérifiez que les entités de données nécessaires sont exportées de Dynamics 365 vers votre BYOD. Les principales entités pour ce processus sont : CustInvoiceJour, CustTrans, CustTable, CustCollectionLetterJour, CustSettlement, smmActivities, CustPromisedPayment et CustDispute. Si certaines sont absentes, configurez leur export dans l’espace de travail de gestion des données de Dynamics 365.
Connectez-vous à la base BYOD : Utilisez un client SQL, tel que SQL Server Management Studio (SSMS) ou Azure Data Studio, pour vous connecter à la base de données Azure SQL configurée comme destination BYOD.
Préparez la requête SQL : Copiez dans votre client SQL la requête T-SQL complète fournie dans la section query de ce document. Elle rassemble les activités et les attributs requis dans un journal d’événements unique.
Définissez les paramètres de la requête : Repérez les espaces réservés au début de la requête. Remplacez '{CompanyCode}' par l’identifiant de l’entité juridique Dynamics 365 à analyser, par exemple « USMF ». Remplacez '{StartDate}' et '{EndDate}' par la période souhaitée, au format « YYYY-MM-DD ».
Exécutez la requête : Lancez la requête modifiée sur la base BYOD. La durée d’exécution dépend du volume de données pour la période sélectionnée.
Vérifiez les résultats : Une fois la requête terminée, le volet des résultats affiche le journal d’événements. Chaque ligne correspond à une activité du cycle de gestion du crédit et du recouvrement d’une facture. Vérifiez que les données sont complètes et exactes.
Exportez le journal d’événements : Exportez les résultats de la requête dans un fichier CSV. La plupart des clients SQL disposent d’une fonction intégrée d’export des résultats. Faites un clic droit sur la grille des résultats et recherchez une option telle que « Save Results As » ou « Export ».
Préparez l’importation : Vérifiez que le fichier CSV exporté est encodé en UTF-8 et que ses en-têtes de colonnes correspondent aux attributs requis : InvoiceNumber, ActivityName, EventTime, ainsi qu’aux attributs recommandés que vous avez inclus. Le fichier est alors prêt à être importé dans ProcessMind.

Configuration

Prérequis : Accès à une instance Microsoft Dynamics 365 for Finance configurée avec la fonctionnalité Bring Your Own Database (BYOD). Celle-ci doit être opérationnelle. Vous devez disposer d’autorisations de lecture sur la base de données Azure SQL cible.
Entités de données : L’extraction repose sur l’export de plusieurs entités de données standard vers BYOD. Vérifiez que CustInvoiceJour, CustTrans, CustTable et CustSettlement figurent au minimum dans votre tâche d’export BYOD. D’autres entités, comme CustCollectionLetterJour, sont nécessaires pour certaines activités.
Période : Il est essentiel de filtrer la requête sur une période précise pour maîtriser les performances. Pour une première analyse, une période de 3 à 6 mois est recommandée. La requête fournie utilise les espaces réservés '{StartDate}' et '{EndDate}' à cette fin.
Filtre de société : La requête doit porter sur une entité juridique précise (code société) afin de garantir la cohérence des données. Utilisez l’espace réservé '{CompanyCode}' pour indiquer la société à analyser.
Performances : Pour les très grands jeux de données couvrant plusieurs années ou sociétés, l’exécution de la requête peut être longue. Envisagez de la lancer en dehors des heures de pointe ou d’ajouter des filtres pour réduire le périmètre des données. Vérifiez que les tables BYOD disposent d’index adaptés sur les dates et les colonnes clés.

a Exemple de requête sql

WITH BaseInvoices AS (
    SELECT 
        cj.INVOICEID AS InvoiceNumber,
        cj.INVOICEDATE AS InvoiceDate,
        cj.DUEDATE AS PaymentDueDate,
        cj.INVOICEAMOUNTMST AS InvoiceAmount,
        ct.NAME AS CustomerName,
        ct.CUSTGROUP AS CustomerSegment,
        -- The collector assignment can be complex. This is a common approach.
        -- It assumes the collector is assigned at the customer level in CustTable.
        -- Your configuration may differ, for example using collection pools.
        col.NAME AS CollectorAssigned,
        cj.DATAAREAID
    FROM 
        dbo.CustInvoiceJour cj
    JOIN 
        dbo.CustTable ct ON cj.INVOICECUST = ct.ACCOUNTNUM AND cj.DATAAREAID = ct.DATAAREAID
    LEFT JOIN 
        -- Placeholder for how collector might be identified. You may need to join to a different table.
        dbo.CollectionsAgent col ON ct.COLLECTIONAGENT = col.AGENTID
    WHERE 
        cj.DATAAREAID = '{CompanyCode}'
        AND cj.INVOICEDATE BETWEEN '{StartDate}' AND '{EndDate}'
)

-- 1. Invoice Generated
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Generated' AS ActivityName,
    cj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel, 
    'Generated' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi
JOIN
    dbo.CustInvoiceJour cj ON bi.InvoiceNumber = cj.INVOICEID AND bi.DATAAREAID = cj.DATAAREAID

UNION ALL

-- 2. Invoice Posted and Sent
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Invoice Posted and Sent' AS ActivityName,
    bi.InvoiceDate AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Posted' AS InvoiceStatus,
    0 AS DaysOverdue
FROM 
    BaseInvoices bi

UNION ALL

-- 3. Payment Due Date Passed
SELECT
    bi.InvoiceNumber AS InvoiceNumber,
    'Payment Due Date Passed' AS ActivityName,
    bi.PaymentDueDate AS EventTime, -- The event happens on the due date
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    0 AS DunningLevel,
    'Overdue' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, GETUTCDATE()) AS DaysOverdue
FROM
    BaseInvoices bi
JOIN 
    dbo.CustTrans ct ON bi.InvoiceNumber = ct.INVOICE AND bi.DATAAREAID = ct.DATAAREAID
WHERE
    bi.PaymentDueDate < GETUTCDATE()
    AND ct.CLOSED = '1900-01-01 00:00:00.000' -- Logic to find open/unsettled transactions

UNION ALL

-- 4. Dunning Letter Generated
SELECT 
    clj.INVOICEID AS InvoiceNumber,
    'Dunning Letter Generated' AS ActivityName,
    clj.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    clj.COLLECTIONLETTERCODE AS DunningLevel,
    'In Dunning' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, clj.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustCollectionLetterJour clj
JOIN
    BaseInvoices bi ON clj.INVOICEID = bi.InvoiceNumber AND clj.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 5. Collection Activity Logged
-- This assumes smmActivities are used and linked to the customer.
-- Linking directly to an invoice can be difficult.
SELECT 
    bi.InvoiceNumber AS InvoiceNumber,
    'Collection Activity Logged' AS ActivityName,
    sa.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'In Collections' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, sa.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.smmActivities sa
JOIN
    dbo.CustTable ct ON sa.PARTY = ct.PARTY
JOIN
    BaseInvoices bi ON ct.ACCOUNTNUM = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    sa.DATAAREAID = '{CompanyCode}' AND sa.CREATEDDATETIME > bi.InvoiceDate

UNION ALL

-- 6. Payment Promise Created
SELECT 
    bi.InvoiceNumber,
    'Payment Promise Created' AS ActivityName,
    cpp.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Promised' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpp.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustPromisedPayment cpp
JOIN 
    dbo.CustTrans ct ON cpp.TRANSACTIONREFRECID = ct.RECID AND cpp.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID

UNION ALL

-- 7. Dispute Registered
SELECT 
    bi.InvoiceNumber,
    'Dispute Registered' AS ActivityName,
    cd.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Disputed' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cd.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 1 -- Assuming 1 means opened/registered

UNION ALL

-- 8. Dispute Resolved
SELECT 
    bi.InvoiceNumber,
    'Dispute Resolved' AS ActivityName,
    cd.MODIFIEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Posted' AS InvoiceStatus, -- Status returns to normal after resolution
    DATEDIFF(day, bi.PaymentDueDate, cd.MODIFIEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustDispute cd
JOIN 
    dbo.CustTrans ct ON cd.CUSTTRANSRECID = ct.RECID AND cd.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE
    cd.STATUS = 2 -- Assuming 2 means closed/resolved

UNION ALL

-- 9. Payment Received (Journal Created, not yet posted)
-- This can be difficult to capture accurately and link to a specific invoice before settlement.
-- This is an approximation based on journal creation.
SELECT 
    bi.InvoiceNumber,
    'Payment Received' AS ActivityName,
    cpjl.CREATEDDATETIME AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Payment Pending' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cpjl.CREATEDDATETIME) AS DaysOverdue
FROM 
    dbo.CustomerPaymentJournalLineEntity cpjl
JOIN
    BaseInvoices bi ON cpjl.AccountDisplayValue = (SELECT TOP 1 INVOICECUST FROM dbo.CustInvoiceJour WHERE INVOICEID = bi.InvoiceNumber AND DATAAREAID = bi.DATAAREAID) AND cpjl.Company = bi.DATAAREAID
WHERE
    cpjl.CREATEDDATETIME >= bi.InvoiceDate

UNION ALL

-- 10. Payment Posted (Settlement Transaction)
-- Captures each partial or full payment application
SELECT 
    bi.InvoiceNumber,
    'Payment Posted' AS ActivityName,
    cs.TRANSDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Partially Paid' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, cs.TRANSDATE) AS DaysOverdue
FROM 
    dbo.CustSettlement cs
JOIN 
    dbo.CustTrans ct ON cs.TRANSRECID = ct.RECID AND cs.DATAAREAID = ct.DATAAREAID
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    cs.SETTLEAMOUNTCUR > 0

UNION ALL

-- 11. Invoice Settled
SELECT 
    bi.InvoiceNumber,
    'Invoice Settled' AS ActivityName,
    ct.CLOSEDDATE AS EventTime,
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Settled' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.CLOSEDDATE) AS DaysOverdue
FROM 
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.CLOSEDDATE <> '1900-01-01 00:00:00.000'
    AND ct.TRANSTYPE = 11 -- Enum for Sales Invoice

UNION ALL

-- 12. Invoice Written Off
SELECT
    bi.InvoiceNumber,
    'Invoice Written Off' AS ActivityName,
    ct.TRANSDATE AS EventTime, -- The date of the write-off transaction
    bi.CollectorAssigned,
    bi.InvoiceAmount,
    bi.CustomerName,
    bi.CustomerSegment,
    bi.PaymentDueDate,
    NULL AS DunningLevel,
    'Written Off' AS InvoiceStatus,
    DATEDIFF(day, bi.PaymentDueDate, ct.TRANSDATE) AS DaysOverdue
FROM
    dbo.CustTrans ct
JOIN
    BaseInvoices bi ON ct.INVOICE = bi.InvoiceNumber AND ct.DATAAREAID = bi.DATAAREAID
WHERE 
    ct.TRANSTYPE = 19; -- Enum for Write-off. This may vary based on configuration.

Étapes

Vérifiez les prérequis et configurez l’environnement : Assurez-vous que Python 3.8 ou une version ultérieure est installé. Installez les bibliothèques nécessaires avec pip : pip install pandas requests msal. Vous aurez également besoin des identifiants d’un principal de service autorisé à accéder à l’environnement Dynamics 365.
Inscrivez l’application dans Azure AD : Accédez au portail Azure Active Directory et inscrivez une nouvelle application pour obtenir un Client ID et un Tenant ID. Créez un secret client dans la section « Certificates & secrets » de l’application. Conservez en lieu sûr le Client ID, le Tenant ID et le Client Secret.
Accordez les autorisations d’API : Dans les paramètres « API permissions » de l’application inscrite dans Azure AD, ajoutez une autorisation. Sélectionnez « Dynamics ERP » ou une entrée similaire pour Dynamics 365, puis accordez l’autorisation déléguée « user_impersonation ». Accordez le consentement administrateur pour votre organisation.
Créez un utilisateur Dynamics 365 : Créez un utilisateur d’application dédié dans Dynamics 365 Finance and Operations. Associez-le au Client ID de votre application Azure AD. Attribuez-lui un rôle de sécurité autorisant la lecture de toutes les entités de données requises, telles que CustInvoiceJour, CustCollectionLetterJour, CustSettlements et smmActivities.
Configurez le script Python : Copiez le script Python fourni dans un fichier, par exemple extract_d365_collections.py. Renseignez les variables de remplacement au début du script avec l’URL de votre environnement D365, le Tenant ID, le Client ID, le Client Secret et la société par défaut (dataAreaId).
Définissez les paramètres d’extraction : Modifiez les variables start_date et end_date du script pour définir la période d’extraction. Une période de 3 à 6 mois est recommandée pour une première analyse.
Exécutez le script : Lancez le script depuis votre terminal avec la commande python extract_d365_collections.py. Le script s’authentifie, interroge les points de terminaison OData pour chacune des 12 activités et gère automatiquement la pagination de l’API.
Récupérez les données de chaque activité : Le script effectue des appels successifs à l’API pour récupérer les données de création et de comptabilisation des factures, de relance, de paiement et d’autres événements clés. Chaque requête cible une entité de données précise et ne sélectionne que les champs nécessaires afin d’optimiser les performances.
Transformez et regroupez les données : La bibliothèque pandas traite la réponse JSON de chaque appel à l’API. Le script transforme les données en table structurée, uniformise les noms de colonnes, puis regroupe les données de toutes les activités dans un journal d’événements unique.
Calculez les événements dérivés : L’activité « Date d’échéance dépassée » n’est pas enregistrée directement dans le système. Le script parcourt toutes les factures en retard pour la période définie et génère une ligne correspondante pour chacune.
Exportez le journal d’événements : Une fois les données traitées et regroupées, le script enregistre le journal d’événements final dans un fichier CSV nommé d365_collections_event_log.csv, dans le même répertoire. Ce fichier est prêt à être importé dans un outil de Process Mining.

Configuration

URL du point de terminaison de l’API : URL de base de votre environnement Dynamics 365 Finance and Operations, au format https://[your-environment-name].operations.dynamics.com.
Identifiants d’authentification : Le script nécessite un Tenant ID, un Client ID et un Client Secret issus de l’inscription d’une application Azure Active Directory. Cette application doit être autorisée à accéder à l’API Dynamics 365.
Filtre de société (dataAreaId) : Dynamics 365 gère plusieurs sociétés. Le script interroge une société précise à l’aide du filtre dataAreaId. Vérifiez que la variable default_company contient l’entité juridique appropriée, par exemple « USMF ».
Période : Les paramètres start_date et end_date définissent la période d’extraction. Il est recommandé de commencer par une période récente de 3 à 6 mois pour maîtriser le volume de données et obtenir les résultats dans un délai raisonnable. Le filtre porte principalement sur la date de création de la facture.
Performances : L’extraction de très grands jeux de données via l’API OData peut prendre du temps et être soumise à une limitation du nombre de requêtes par Microsoft. En cas de problème de performances, réduisez la période d’extraction ou lancez le traitement en dehors des heures de pointe.
Prérequis : Un environnement Python 3.8 ou ultérieur avec les bibliothèques pandas, requests et msal est nécessaire. L’utilisateur Dynamics 365 associé doit pouvoir lire les modules de gestion financière, commerciale et du recouvrement, en particulier les entités mentionnées dans le script.

a Exemple de requête python

import requests
import pandas as pd
import msal
import json
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration --- 
D365_HOST = class="hl-string">"https://[your-d365-environment-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[Your Tenant ID]"
CLIENT_ID = class="hl-string">"[Your Client ID]"
CLIENT_SECRET = class="hl-string">"[Your Client Secret]"

class=class="hl-string">"hl-comment"># Date range for the extraction
start_date = class="hl-string">"2023-01-01"
end_date = class="hl-string">"2023-06-30"
default_company = class="hl-string">"[Your Company ID, e.g., USMF]"

class=class="hl-string">"hl-comment"># MSAL configuration
authority = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
scope = [fclass="hl-string">"{D365_HOST}/.default"]

class=class="hl-string">"hl-comment"># --- Authentication --- 
app = msal.ConfidentialClientApplication(CLIENT_ID, authority=authority, client_credential=CLIENT_SECRET)
result = app.acquire_token_silent(scope, account=None)

if not result:
    result = app.acquire_token_for_client(scopes=scope)

if class="hl-string">"access_token" not in result:
    raise Exception(class="hl-string">"Could not obtain access token: " + result.get(class="hl-string">"error_description"))

access_token = result[class="hl-string">'access_token']
headers = {
    class="hl-string">'Authorization': class="hl-string">'Bearer ' + access_token,
    class="hl-string">'Content-Type': class="hl-string">'application/json',
    class="hl-string">'Accept': class="hl-string">'application/json'
}

class=class="hl-string">"hl-comment"># --- Data Fetching Function --- 
def get_odata_data(entity_url):
    all_records = []
    url = entity_url
    while url:
        try:
            response = requests.get(url, headers=headers, params={class="hl-string">'cross-company': class="hl-string">'true'})
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            all_records.extend(data.get(class="hl-string">'value', []))
            url = data.get(class="hl-string">'@odata.nextLink')
        except requests.exceptions.HTTPError as err:
            print(fclass="hl-string">"HTTP Error fetching data: {err}")
            print(fclass="hl-string">"Response content: {err.response.text}")
            break
        except json.JSONDecodeError:
            print(fclass="hl-string">"Failed to decode JSON from response: {response.text}")
            break
    return all_records

class=class="hl-string">"hl-comment"># --- Main Extraction Logic --- 
all_events = []

print(class="hl-string">"1. Extracting 'Invoice Generated' and 'Invoice Posted'...")
invoice_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and InvoiceDate ge {start_date}T00:00:00Z and InvoiceDate le {end_date}T23:59:59Z&$select=InvoiceNumber,InvoiceDate,createdDateTime,DueDate,InvoiceAmount,SalesOrderNumber,InvoiceCustomerAccountNumber,CustomerName,dataAreaId"
invoices = get_odata_data(invoice_entity_url)
if invoices:
    df_invoices = pd.DataFrame(invoices)
    df_invoices[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Generated'
    df_invoices[class="hl-string">'EventTime'] = pd.to_datetime(df_invoices[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    df_invoices.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'InvoiceAmount': class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName': class="hl-string">'CustomerName', class="hl-string">'DueDate': class="hl-string">'PaymentDueDate'}, inplace=True)
    all_events.append(df_invoices[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    df_posted = df_invoices.copy()
    df_posted[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Posted and Sent'
    df_posted[class="hl-string">'EventTime'] = pd.to_datetime(df_posted[class="hl-string">'InvoiceDate']).dt.tz_localize(None)
    all_events.append(df_posted[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

    print(class="hl-string">"2. Calculating 'Payment Due Date Passed'...")
    df_due_passed = df_invoices[pd.to_datetime(df_invoices[class="hl-string">'PaymentDueDate']).dt.date < datetime.now().date()].copy()
    df_due_passed[class="hl-string">'ActivityName'] = class="hl-string">'Payment Due Date Passed'
    df_due_passed[class="hl-string">'EventTime'] = pd.to_datetime(df_due_passed[class="hl-string">'PaymentDueDate']) + timedelta(days=1)
    all_events.append(df_due_passed[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate']])

print(class="hl-string">"3. Extracting 'Dunning Letter Generated'...")
dunning_entity_url = fclass="hl-string">"{D365_HOST}/data/CustCollectionLetterJours?$filter=dataAreaId eq '{default_company}' and CollectionLetterDate ge {start_date}T00:00:00Z and CollectionLetterDate le {end_date}T23:59:59Z&$select=InvoiceNumber,CollectionLetterCode,CollectionLetterDate"
dunning_letters = get_odata_data(dunning_entity_url)
if dunning_letters:
    df_dunning = pd.DataFrame(dunning_letters)
    df_dunning[class="hl-string">'ActivityName'] = class="hl-string">'Dunning Letter Generated'
    df_dunning[class="hl-string">'EventTime'] = pd.to_datetime(df_dunning[class="hl-string">'CollectionLetterDate']).dt.tz_localize(None)
    df_dunning.rename(columns={class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber', class="hl-string">'CollectionLetterCode': class="hl-string">'DunningLevel'}, inplace=True)
    all_events.append(df_dunning[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'DunningLevel']])

print(class="hl-string">"4. Extracting 'Payment Received' and 'Payment Posted'...")
settlements_entity_url = f"{D365_HOST}/data/CustSettlements?$filter=dataAreaId eq class="hl-string">'{default_company}' and TransDate ge {start_date}T00:00:00Z and TransDate le {end_date}T23:59:59Z&$select=OffsetRecId,TransDate,createdDateTime,SettlementAmountCur
&expand=CustInvoiceJour($select=InvoiceNumber)"
settlements = get_odata_data(settlements_entity_url)
if settlements:
    class=class="hl-string">"hl-comment"># Flatten the expanded data
    flat_settlements = []
    for s in settlements:
        if s.get(class="hl-string">'CustInvoiceJour'):
            s[class="hl-string">'InvoiceNumber'] = s[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_settlements.append(s)

    df_settlements = pd.DataFrame(flat_settlements)
    df_received = df_settlements.copy()
    df_received[class="hl-string">'ActivityName'] = class="hl-string">'Payment Received'
    df_received[class="hl-string">'EventTime'] = pd.to_datetime(df_received[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_received[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
    df_posted_payment = df_settlements.copy()
    df_posted_payment[class="hl-string">'ActivityName'] = class="hl-string">'Payment Posted'
    df_posted_payment[class="hl-string">'EventTime'] = pd.to_datetime(df_posted_payment[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_posted_payment[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># Note: Other activities like Disputes, Promises, Write-offs often involve custom entities or status fields.
class=class="hl-string">"hl-comment"># The following are conceptual examples assuming certain fields exist.
class=class="hl-string">"hl-comment"># You MUST adapt these to your specific D365 configuration.

print(class="hl-string">"5. Extracting 'Dispute Registered' and 'Dispute Resolved' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Assuming a status field class="hl-string">'CollectionStatus' on the invoice indicates a dispute.
class=class="hl-string">"hl-comment"># This would ideally be sourced from an audit trail if available. This example assumes a snapshot.
dispute_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and (CollectionStatus eq 'Disputed' or CollectionStatus eq 'Resolved') and modifiedDateTime ge {start_date}T00:00:00Z&$select=InvoiceNumber,CollectionStatus,modifiedDateTime"
disputes = get_odata_data(dispute_entity_url)
if disputes:
    df_disputes = pd.DataFrame(disputes)
    df_disputes[class="hl-string">'ActivityName'] = df_disputes[class="hl-string">'CollectionStatus'].apply(lambda x: class="hl-string">'Dispute Registered' if x == class="hl-string">'Disputed' else class="hl-string">'Dispute Resolved')
    df_disputes[class="hl-string">'EventTime'] = pd.to_datetime(df_disputes[class="hl-string">'modifiedDateTime']).dt.tz_localize(None)
    all_events.append(df_disputes[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"6. Extracting 'Payment Promise Created' (Conceptual)... ")
promise_entity_url = fclass="hl-string">"{D365_HOST}/data/CustPromisedPayments?$filter=dataAreaId eq '{default_company}' and createdDateTime ge {start_date}T00:00:00Z&$select=Invoice,createdDateTime,PromisedDate,PromisedAmount&$expand=CustInvoiceJour($select=InvoiceNumber)"
promises = get_odata_data(promise_entity_url)
if promises:
    flat_promises = []
    for p in promises:
        if p.get(class="hl-string">'CustInvoiceJour'):
            p[class="hl-string">'InvoiceNumber'] = p[class="hl-string">'CustInvoiceJour'][class="hl-string">'InvoiceNumber']
            flat_promises.append(p)
    df_promises = pd.DataFrame(flat_promises)
    df_promises[class="hl-string">'ActivityName'] = class="hl-string">'Payment Promise Created'
    df_promises[class="hl-string">'EventTime'] = pd.to_datetime(df_promises[class="hl-string">'createdDateTime']).dt.tz_localize(None)
    all_events.append(df_promises[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])
    
print(class="hl-string">"7. Extracting 'Collection Activity Logged' (Conceptual)... ")
class=class="hl-string">"hl-comment"># Linking activities to invoices can be indirect, often through the customer account.
activity_entity_url = fclass="hl-string">"{D365_HOST}/data/smmActivities?$filter=dataAreaId eq '{default_company}' and StartDateTime ge {start_date}T00:00:00Z and Purpose eq '[Your Collection Activity Purpose]'&$select=ActivityNumber,ParentRecordEntityName,ParentRecordRecId,StartDateTime,ResponsibleWorkerName&$expand=CustTable($select=AccountNumber)"
activities = get_odata_data(activity_entity_url)
class=class="hl-string">"hl-comment"># This section requires custom logic to map customer-level activities to open invoices at that time.
class=class="hl-string">"hl-comment"># A simplified approach is omitted here due to its complexity.

print(class="hl-string">"8. Identifying 'Invoice Settled' (Conceptual)... ")
settled_entity_url = fclass="hl-string">"{D365_HOST}/data/CustInvoiceJours?$filter=dataAreaId eq '{default_company}' and Status eq 'Paid' and LastSettlementDate ge {start_date}T00:00:00Z&$select=InvoiceNumber,LastSettlementDate"
settled_invoices = get_odata_data(settled_entity_url)
if settled_invoices:
    df_settled = pd.DataFrame(settled_invoices)
    df_settled[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Settled'
    df_settled[class="hl-string">'EventTime'] = pd.to_datetime(df_settled[class="hl-string">'LastSettlementDate']).dt.tz_localize(None)
    all_events.append(df_settled[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

print(class="hl-string">"9. Identifying 'Invoice Written Off' (Conceptual)... ")
class=class="hl-string">"hl-comment"># This is identified by a specific type of transaction in CustTrans.
writeoff_entity_url = fclass="hl-string">"{D365_HOST}/data/CustTrans?$filter=dataAreaId eq '{default_company}' and TransType eq 'WriteOff' and TransDate ge {start_date}T00:00:00Z&$select=Invoice,TransDate,Txt"
writeoffs = get_odata_data(writeoff_entity_url)
if writeoffs:
    df_writeoffs = pd.DataFrame(writeoffs)
    df_writeoffs.rename(columns={class="hl-string">'Invoice': class="hl-string">'InvoiceNumber'}, inplace=True)
    df_writeoffs[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Written Off'
    df_writeoffs[class="hl-string">'EventTime'] = pd.to_datetime(df_writeoffs[class="hl-string">'TransDate']).dt.tz_localize(None)
    all_events.append(df_writeoffs[[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime']])

class=class="hl-string">"hl-comment"># --- Final Processing --- 
if all_events:
    print(class="hl-string">"Combining all events...")
    final_df = pd.concat(all_events, ignore_index=True)
    final_df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)
    
    class=class="hl-string">"hl-comment"># Fill forward attributes for a complete log
    attributes_to_fill = [class="hl-string">'InvoiceAmount', class="hl-string">'CustomerName', class="hl-string">'PaymentDueDate', class="hl-string">'DunningLevel']
    for attr in attributes_to_fill:
        if attr not in final_df.columns:
            final_df[attr] = None
    
    final_df[attributes_to_fill] = final_df.groupby(class="hl-string">'InvoiceNumber')[attributes_to_fill].fillna(method=class="hl-string">'ffill').fillna(method=class="hl-string">'bfill')
    
    final_df = final_df.dropna(subset=[class="hl-string">'InvoiceNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime'])
    
    output_filename = class="hl-string">'d365_collections_event_log.csv'
    final_df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"Event log successfully created: {output_filename}")
else:
    print(class="hl-string">"No events were extracted. Please check your configuration and date range.")

Prêt à commencer ?

Utilisez ce modèle pour préparer vos données et mieux comprendre vos opérations de gestion du crédit et du recouvrement. Commencez dès aujourd’hui à optimiser vos processus pour accélérer les encaissements.

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

Optimisez dès aujourd’hui la gestion du crédit et du recouvrement pour accélérer les encaissements

Améliorez votre trésorerie en optimisant le cycle crédit-encaissement et en réduisant le temps de cycle de 30 %.

Démarrez votre essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

Votre modèle de données pour la gestion du crédit et le recouvrement

Votre modèle de données pour la gestion du crédit et le recouvrement

Attributs de gestion du crédit et de recouvrement

Activités de gestion du crédit et de recouvrement

Guides d’extraction

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

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l’API REST OData de Dynamics 365

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd’hui la gestion du crédit et du recouvrement pour accélérer les encaissements

Votre modèle de données pour la gestion du crédit et le recouvrement

Votre modèle de données pour la gestion du crédit et le recouvrement

Attributs de gestion du crédit et de recouvrement

Activités de gestion du crédit et de recouvrement

Guides d’extraction

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

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l’API REST OData de Dynamics 365

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd’hui la gestion du crédit et du recouvrement pour accélérer les encaissements

Nous respectons votre vie privée

Prêt à commencer ?