> Amélioration continue des processus > Créances clients > Microsoft Dynamics 365 > Modèle de données

Votre modèle de données pour les créances clients

Microsoft Dynamics 365

Attributs des créances clients (21) Activités liées aux créances clients (15) Guides d’extraction (2)

Votre modèle de données pour les créances clients

Ce modèle fournit un cadre complet pour cartographier votre processus de facturation et d’encaissement dans Microsoft Dynamics 365. Il répertorie les champs de données et les jalons essentiels à la création d’un journal d’événements de qualité pour le Process Mining. En suivant cette structure, vous pourrez mieux comprendre les retards de paiement et optimiser vos flux de travail de recouvrement.

Champs de données essentiels à l’analyse des écritures comptables
Jalons de processus standard à suivre
Instructions techniques 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 des créances clients

Voici les champs de données qu’il est recommandé d’inclure dans votre journal d’événements pour analyser en détail la performance de vos créances clients.

5 Obligatoire 8 Recommandé 8 Facultatif

	Nom	Description
	Activité Activity	Événement ou tâche précise effectuée sur la facture.
Description Cet attribut décrit l’étape du processus, par exemple la comptabilisation d’une facture, la réception d’un paiement ou l’ouverture d’un litige. Dans Microsoft Dynamics 365, il est souvent déduit du type de transaction (TransType) ou de la table dans laquelle l’enregistrement est consigné, comme CustSettlement pour les paiements. Cet attribut est indispensable à la représentation visuelle du processus. Pourquoi est-ce important ? Il définit les nœuds de la cartographie du processus et permet d’analyser le flux de processus et d’identifier ses variantes. Où trouver ces données Déduit de l’énumération TransType ou du contexte de la table (CustTrans, CustSettlement, etc.) Exemples Facture comptabiliséePaiement reçuLettre de recouvrement envoyéeNote d’intérêts comptabilisée
	Horodatage de l’événement EventTimestamp	Date et heure exactes auxquelles l’activité a eu lieu.
Description Cet attribut indique le moment précis où un événement a été enregistré dans le système. Il sert à calculer les durées entre les activités, à déterminer les délais du processus et à ordonner les événements. Dans D365, il correspond généralement à CreatedDateTime ou TransDate, associé à une heure. Pourquoi est-ce important ? Les horodatages sont indispensables au calcul des indicateurs de performance liés au temps, comme le temps de cycle des factures et le délai d’envoi. Où trouver ces données Champs CreatedDateTime ou TransDate couramment utilisés dans différentes tables Exemples 2023-10-15T08:30:00Z2023-10-15T14:45:22Z2023-11-01T09:00:00Z
	Numéro de facture InvoiceNumber	Identifiant unique du document de facture financière.
Description Le numéro de facture est la clé principale pour suivre le cycle de vie d’une créance dans Microsoft Dynamics 365. Il relie la commande initiale, la facture comptabilisée, les paiements ultérieurs et les activités de recouvrement au sein d’un même cas. Dans l’analyse, cet attribut sert d’identifiant de cas pour reconstituer le flux de processus de bout en bout. Pourquoi est-ce important ? Il constitue l’unité d’analyse fondamentale pour la gestion des créances clients et permet au moteur de Process Mining de regrouper des événements distincts dans un même cas cohérent. Où trouver ces données CustInvoiceJour.InvoiceId ou CustTrans.Invoice Exemples INV-2023-001CIV-88921US-004321DE-99120
	Dernière mise à jour des données LastDataUpdate	Date et heure de l’extraction ou de l’actualisation des données.
Description Cet attribut indique la date de la dernière extraction des données depuis Microsoft Dynamics 365. Il permet d’évaluer leur fraîcheur ainsi que la validité des KPI. Il est généralement généré par l’outil d’extraction au moment de la requête. Pourquoi est-ce important ? Il renseigne sur le délai de mise à disposition des données et permet de vérifier que les Dashboards présentent des informations à jour. Où trouver ces données Généré par le script ETL ou d’extraction Exemples 2023-11-05T00:00:00Z2023-11-05T12:00:00Z
	Système source SourceSystem	Nom du système d’origine des données.
Description Cet attribut indique le système de référence des données, ici Microsoft Dynamics 365. Il est utile lorsque vous regroupez des données provenant de plusieurs instances ERP ou d’outils de collecte externes dans une vue unique. Les analystes peuvent ainsi filtrer les processus ou les segmenter selon leur environnement d’origine. Pourquoi est-ce important ? Il garantit la traçabilité et la provenance des données, en particulier dans les environnements comportant plusieurs systèmes. Où trouver ces données Renseigné lors de l’extraction ou déduit de la chaîne de connexion Exemples D365 F&O ProdD365 FinanceDynamics AX 2012
	Code société CompanyCode	Identifiant de l’entité juridique dans D365.
Description Cet attribut correspond à DataAreaId dans D365, qui désigne l’entité juridique ou la société où la transaction a eu lieu. Il est indispensable pour filtrer les données dans les déploiements multi-sociétés et distinguer les numéros de facture qui peuvent se répéter d’une société à l’autre. Pourquoi est-ce important ? Essentiel pour garantir l’unicité dans les environnements multi-entités et réaliser des analyses régionales. Où trouver ces données Champ DataAreaId présent dans toutes les tables Exemples USMFDEMFGBSI
	Compte client CustomerAccount	Identifiant unique ou numéro de compte du client.
Description Le compte client désigne l’entité à facturer. Dans D365, il correspond au champ AccountNum. Le regroupement par cet attribut permet d’analyser les comportements de paiement, la fréquence des litiges et les délais de règlement pour chaque client. Pourquoi est-ce important ? Indispensable pour repérer les clients à risque élevé et comparer les résultats par client. Où trouver ces données CustInvoiceJour.InvoiceAccount ou CustTrans.AccountNum Exemples US-001DE-550CUST-9921
	Date d’échéance DueDate	Date à laquelle le paiement doit être reçu.
Description La date d’échéance est la date limite de paiement définie par les conditions de paiement. Elle est comparée à la date de paiement effective pour mesurer le respect des délais et calculer le délai moyen de paiement client (DSO). Il s’agit d’un champ standard de l’enregistrement des transactions client. Pourquoi est-ce important ? Indispensable pour calculer le taux de paiement à temps et analyser les factures en retard. Où trouver ces données CustTrans.DueDate Exemples 2023-11-302023-12-15
	Est automatisé IsAutomated	Indique si l’activité a été effectuée par un compte système.
Description Cet attribut indique si une étape a été effectuée par un utilisateur ou par un traitement par lots automatisé. Il est calculé en comparant l’attribut User à une liste de comptes système connus, par exemple « flux de travail » ou « Batch ». Il sert au calcul du KPI du taux de lettrage manuel. Pourquoi est-ce important ? Essentiel pour repérer les possibilités d’automatisation et mesurer le niveau d’automatisation actuel. Où trouver ces données Déduit de la logique appliquée au champ User Exemples truefalse
	Groupe de clients CustomerGroup	Catégorie ou segment auquel appartient le client.
Description Cet attribut répartit les clients en groupes, par exemple vente en gros, vente au détail ou opérations intersociétés. Il permet de comparer les segments et de vérifier, par exemple, si certains connaissent des délais de paiement plus longs ou davantage de litiges. Dans D365, il correspond au champ CustGroup. Pourquoi est-ce important ? Permet de comparer les résultats du processus entre différents segments de marché. Où trouver ces données CustTable.CustGroup Exemples Vente en grosVente au détailOpérations intersociétésExportation
	Montant de la facture InvoiceAmount	Montant total de la facture.
Description Cet attribut correspond au montant financier de la facture. Il sert à calculer l’exposition totale des créances clients et à prioriser le recouvrement des montants élevés. Ce champ se trouve généralement dans la table du journal des factures. Pourquoi est-ce important ? Essentiel pour analyser l’impact financier et repérer les goulots d’étranglement liés aux montants élevés. Où trouver ces données CustInvoiceJour.InvoiceAmount Exemples 1500.00250.5010000.00
	Unité opérationnelle BusinessUnit	Unité ou division responsable de la facture.
Description Cet attribut segmente les données selon la structure interne de l’organisation, par exemple la division Électronique ou la division Services. Dans D365, il s’agit souvent d’une dimension financière associée à la transaction. Il permet de comparer les unités dans le Dashboard du délai d’émission des factures. Pourquoi est-ce important ? Permet de comparer les divisions en interne et de repérer les plus efficaces. Où trouver ces données Dimensions financières (DefaultDimension) dans CustInvoiceJour Exemples BU-001Ventes-NordServices-Monde
	Utilisateur User	Identifiant de l’utilisateur ou du compte système ayant effectué l’activité.
Description Cet attribut indique qui a exécuté l’étape du processus, à partir des champs CreatedBy ou ModifiedBy. Il permet d’analyser l’utilisation des ressources, de repérer les besoins de formation et de distinguer les tâches automatisées des interventions manuelles. Pourquoi est-ce important ? Permet d’analyser la performance des ressources et de calculer le taux d’automatisation. Où trouver ces données Champ CreatedBy des tables de transactions Exemples AdministrateurJSmithWorkflowAgentBSmith
	Conditions de paiement PaymentTerms	Code définissant l’échéancier de paiement convenu.
Description Cet attribut contient le code qui détermine la date d’échéance du paiement, par exemple Net30 ou Net60. Il permet de vérifier si les clients respectent les conditions qui leur sont propres et si la date d’échéance a été calculée correctement. Pourquoi est-ce important ? Il précise le contexte de la date d’échéance et aide à déterminer si les conditions sont trop souples ou trop strictes. Où trouver ces données CustInvoiceJour.Payment ou CustTable.PaymTermId Exemples Net30Net45CODEOM
	Date limite de remise pour paiement comptant CashDiscountDate	Date jusqu’à laquelle une remise pour paiement anticipé est valable.
Description Cet attribut indique la date limite à laquelle le client peut bénéficier d’une remise pour paiement anticipé. La comparaison avec la date de paiement permet de calculer le KPI du taux de remises manquées et d’évaluer l’efficacité des incitations à payer plus tôt. Pourquoi est-ce important ? Indispensable au Dashboard d’optimisation des remises pour paiement anticipé. Où trouver ces données CustTrans.CashDisc ou calculé à partir de CashDiscCode Exemples 2023-11-102023-11-15
	Devise Currency	Code de devise de la transaction de facturation.
Description Cet attribut précise la devise dans laquelle la facture a été émise, par exemple USD ou EUR. Il est important pour normaliser les montants financiers lors d’analyses mondiales couvrant plusieurs régions. Pourquoi est-ce important ? Nécessaire pour comprendre la répartition des montants dans les systèmes multidevises. Où trouver ces données CustInvoiceJour.CurrencyCode Exemples USDEURGBPJPY
	Est soldée IsCleared	Indique si la facture a été entièrement réglée.
Description Cet attribut booléen indique si le solde de la facture est nul à la suite d’un paiement ou d’une radiation. Il permet de filtrer rapidement les dossiers ouverts ou clôturés pour calculer le temps de cycle moyen des factures. Pourquoi est-ce important ? Distingue les dossiers en cours des dossiers historiques. Où trouver ces données Déduit de la présence d’une date dans CustTrans.Closed Exemples truefalse
	Est un avoir IsCreditMemo	Indique si le document est un avoir.
Description Cet attribut booléen indique si la transaction correspond à un avoir émis au client. Il sert à calculer le taux d’émission des avoirs et à exclure les factures standard de l’analyse des reprises. Pourquoi est-ce important ? Alimente directement le Dashboard des avoirs et de la fréquence des reprises. Où trouver ces données Déduit de CustInvoiceJour.InvoiceAmount < 0 ou de TransType Exemples truefalse
	ID de commande client SalesOrderId	Numéro de référence de la commande client associée à la facture.
Description Cet attribut relie la facture à la commande client à l’origine de celle-ci. Si les données du processus de la commande à l’encaissement sont disponibles, il permet d’analyser plusieurs processus et de rechercher les causes en amont des problèmes de facturation. Pourquoi est-ce important ? Relie le processus de facturation au processus commercial. Où trouver ces données CustInvoiceJour.SalesId Exemples SO-10022SO-55912
	Jours de retard DaysOverdue	Nombre de jours de retard du paiement par rapport à la date d’échéance.
Description Cette métrique calcule l’écart entre la date de paiement et la date d’échéance. Une valeur positive indique un paiement en retard, tandis qu’une valeur négative indique un paiement anticipé. Elle donne une mesure détaillée des délais de paiement, au-delà d’un simple indicateur binaire. Pourquoi est-ce important ? Complète l’analyse du KPI du taux de paiement à temps. Où trouver ces données Calcul : PaymentDate - DueDate Exemples 50-230
	Motif du litige DisputeReason	Code du motif attribué à un dossier faisant l’objet d’un litige.
Description Cet attribut indique la catégorie du motif du litige sur une facture, par exemple « Erreur de prix » ou « Marchandise endommagée ». Il est essentiel au Dashboard du cycle de résolution des litiges pour repérer les causes des retards de paiement. Pourquoi est-ce important ? Permet d’analyser les causes du KPI de délai de résolution des litiges. Où trouver ces données CustTrans.ReasonRefRecId ou table associée aux dossiers de recouvrement Exemples Écart de prixMarchandise endommagéeBon de commande manquantQualité du service

Obligatoire Recommandé Facultatif

Activités liées aux créances clients

Voici les principales étapes et les principaux jalons à consigner dans votre journal d’événements pour découvrir avec précision le processus de règlement des paiements.

8 Recommandé 7 Facultatif

	Activité	Description
	Avoir émis	Comptabilisation d’un avoir qui vient déduire le montant de la facture d’origine. Elle fait souvent suite à la résolution d’un litige ou à un retour.
Pourquoi est-ce important ? Une fréquence élevée signale des pertes de revenus et des problèmes de qualité en amont. Contrairement à un paiement, l’avoir correspond à un règlement sans mouvement de trésorerie. Où trouver ces données Table CustTrans avec Type égal à « Credit Note », ou table CustInvoiceJour avec un InvoiceAmount négatif. Données à recueillir Enregistré lors de la comptabilisation de la transaction dans CustTrans Type d’événement explicit
	Facture comptabilisée	Enregistrement initial de la facture dans le grand livre. Cette activité correspond à la création de l’obligation financière dans la table CustInvoiceJour.
Pourquoi est-ce important ? Marque le début officiel du cycle de gestion des créances clients et le lancement du délai de paiement. Cette étape est essentielle au calcul du délai moyen de paiement client (DSO). Où trouver ces données Table CustInvoiceJour. Le champ CreatedDateTime ou InvoiceDate sert d’horodatage. Données à recueillir Enregistré lors de la comptabilisation de la transaction dans CustInvoiceJour Type d’événement explicit
	Facture envoyée	Événement correspondant à l’envoi de la facture au client par courriel, par courrier ou par EDI. Il est souvent déduit de l’incrémentation du compteur « Printed » ou des journaux de gestion de l’impression.
Pourquoi est-ce important ? Un délai entre la comptabilisation et l’envoi réduit directement la période dont dispose le client pour payer, ce qui peut donner l’impression que le paiement est en retard. Où trouver ces données Déduit du passage de CustInvoiceJour.PrintedOriginals de 0 à 1, ou suivi dans la table PrintJobHeader si la journalisation est activée. Données à recueillir Comparer le champ de statut avant et après, ou consulter le journal PrintJobHeader Type d’événement inferred
	Facture lettrée	Dernier changement de statut : le solde de la facture atteint zéro et la transaction est marquée comme « Closed » dans le système.
Pourquoi est-ce important ? Fin définitive de l’instance du processus. Sert au calcul du temps de cycle total. Où trouver ces données Champ CustTrans.Closed (date). Cette date est renseignée lorsque la somme des règlements correspond au montant de la facture. Données à recueillir Déduit du champ de date CustTrans.Closed Type d’événement inferred
	Litige ouvert	Création d’un dossier dans le module de gestion des dossiers, associé à la facture et signalant un désaccord du client. Cette étape bloque les flux de recouvrement standard.
Pourquoi est-ce important ? Les litiges sont une cause majeure de retard de paiement. Leur suivi permet de repérer les problèmes de qualité dans les processus en amont, comme la tarification ou l’exécution des commandes. Où trouver ces données Table CaseDetailBase, où Category correspond à Collections/AR et RefRecId renvoie au contexte de la facture. Données à recueillir Enregistré lors de l’exécution de la transaction X dans Case Management Type d’événement explicit
	Paiement intégral reçu	Comptabilisation d’une transaction de paiement qui couvre le solde restant de la facture. Cet événement correspond à une entrée de trésorerie.
Pourquoi est-ce important ? Il s’agit du principal événement marquant la réussite du processus. Il sert à calculer le taux de paiement à temps et à évaluer l’efficacité des conditions d’escompte. Où trouver ces données Table CustTrans avec Type égal à « Payment », reliée à la facture par CustSettlement et ramenant le solde à zéro. Données à recueillir Enregistré lors de la comptabilisation et du lettrage de la transaction dans CustTrans Type d’événement explicit
	Paiement partiel comptabilisé	Enregistrement d’un paiement qui ne couvre pas la totalité du solde ouvert de la facture. Le solde restant doit souvent faire l’objet de nouvelles démarches de recouvrement.
Pourquoi est-ce important ? Permet de distinguer les paiements échelonnés des règlements intégraux. Cette distinction est importante pour établir des prévisions de trésorerie précises. Où trouver ces données Table CustSettlement reliant un paiement (CustTrans) à une facture (CustTrans), lorsque SettlementAmount < InvoiceAmount. Données à recueillir Enregistré lors de l’exécution de la transaction X dans CustSettlement Type d’événement explicit
	Rappel de paiement envoyé	Enregistrement de l’envoi d’une lettre de recouvrement officielle au client. L’événement est extrait du journal des lettres de recouvrement.
Pourquoi est-ce important ? Marque le début des démarches actives de recouvrement. L’analyse de la fréquence des relances aide à optimiser la stratégie de recouvrement et à réduire les coûts administratifs. Où trouver ces données Table CustCollectionLetterJour. Enregistre la date de comptabilisation du code de lettre pour la transaction de facture concernée. Données à recueillir Enregistré lors de la comptabilisation de la transaction dans CustCollectionLetterJour Type d’événement explicit
	Date d’échéance dépassée	Étape calculée indiquant que la date du jour a dépassé la date d’échéance de la facture, qui reste impayée. La facture est alors considérée comme en retard.
Pourquoi est-ce important ? Cette étape est essentielle à l’analyse de l’ancienneté des créances et au déclenchement des flux de travail de recouvrement. Elle marque le passage de la facturation standard à la gestion du recouvrement. Où trouver ces données Calculé en comparant CustInvoiceJour.DueDate à l’heure actuelle de la simulation ou à l’horodatage du paiement. Données à recueillir Déduire l’événement en comparant le champ DueDate à l’heure actuelle Type d’événement calculated
	Litige en cours d’examen	Indique que le dossier de litige est passé du statut « Opened » à « In Process ». Cette étape correspond au temps de traitement par l’équipe chargée de la résolution.
Pourquoi est-ce important ? Les goulots d’étranglement à cette étape allongent le cycle de conversion de trésorerie. La distinction entre le temps d’attente et le temps de traitement actif permet de les analyser séparément. Où trouver ces données Déduit des changements du champ CaseDetailBase.Status ou des entrées de la table CaseLog correspondant à l’évolution du statut. Données à recueillir Comparer le champ de statut avant et après dans CaseDetailBase Type d’événement inferred
	Litige résolu	Clôture du dossier de litige, qui permet à la facture de passer au paiement ou à l’émission d’un avoir. Marque la fin du sous-processus de traitement des exceptions.
Pourquoi est-ce important ? L’écart entre les horodatages d’ouverture et de résolution constitue un indicateur clé de l’efficacité administrative. Où trouver ces données Table CaseDetailBase, où le statut passe à Closed/Resolved. Données à recueillir Comparer le champ de statut avant et après dans CaseDetailBase Type d’événement inferred
	Note d’intérêts générée	Création d’une note d’intérêts pour des paiements en retard. Elle correspond à une pénalité financière appliquée au compte client.
Pourquoi est-ce important ? Signale un retard de paiement important. L’analyse permet de déterminer si les pénalités accélèrent effectivement les paiements ou nuisent aux relations avec les clients. Où trouver ces données Table CustInterestJour. Cette table enregistre les notes d’intérêts générées pour des transactions client précises. Données à recueillir Enregistré lors de la comptabilisation de la transaction dans CustInterestJour Type d’événement explicit
	Paiement passé en perte	Déclaration de la facture comme irrécouvrable et suppression du solde au moyen d’un journal de passage en perte. Cette opération correspond à une perte financière.
Pourquoi est-ce important ? Étape finale d’un processus de recouvrement infructueux. Elle est essentielle à l’analyse du taux de créances irrécouvrables et de l’efficacité de la politique de crédit. Où trouver ces données Table CustTrans avec Type égal à « WriteOff », ou entrée GeneralJournalEntry portant un code de motif de passage en perte. Données à recueillir Enregistré lors de la comptabilisation d’une transaction de type WriteOff Type d’événement explicit
	Promesse de paiement reçue	Engagement précis, enregistré par un agent de recouvrement, par lequel le client s’engage à payer avant une date donnée. Il est extrait du module de gestion du recouvrement.
Pourquoi est-ce important ? Mesure l’efficacité des appels de recouvrement. La comparaison de cette date avec celle du paiement réel permet d’évaluer la fiabilité des promesses des clients. Où trouver ces données Table CustPromiseToPay. Reliée à la transaction client au moyen de TransRecId. Données à recueillir Enregistré lors de la création d’un enregistrement dans CustPromiseToPay Type d’événement explicit
	Relevé bancaire rapproché	Événement de rapprochement au cours duquel le paiement enregistré dans les créances clients est associé à une ligne du relevé bancaire importé.
Pourquoi est-ce important ? Confirme que les fonds sont bien disponibles sur le compte bancaire. Les retards à cette étape signalent des inefficacités dans les processus de gestion de la trésorerie et des comptes bancaires. Où trouver ces données Statut de rapprochement de BankReconciliationLine ou BankAccountTrans. Nécessite le module Advanced Bank Reconciliation. Données à recueillir Enregistré lors du rapprochement de la transaction dans Bank Reconciliation Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Microsoft Dynamics 365

Étapes

Configurez les ressources Azure : créez une base de données Azure SQL qui servira de cible Bring Your Own Database (BYOD). Vérifiez que la chaîne de connexion contient des identifiants disposant des droits de lecture et d’écriture.
Configurez la gestion des données dans D365 : accédez à Administration système > Espaces de travail > Gestion des données. Cliquez sur la vignette « Configurer l’exportation d’entités vers une base de données ». Saisissez la chaîne de connexion de l’étape précédente pour enregistrer la base de données externe.
Sélectionnez les entités requises : créez un projet d’exportation dans l’espace de travail Gestion des données. Ajoutez-y les entités standard suivantes : CustInvoiceJournalHeaderEntity, CustTransactionEntity, CustSettlementEntity, CustCollectionLetterJournalHeaderEntity, CaseDetailEntity, CaseAssociationEntity, CustInterestJournalEntity, BankAccountTransEntity et CustPromiseToPayEntity.
Associez la source à la cible : vérifiez que tous les champs sont correctement associés, notamment les champs RecId et CreatedDateTime, indispensables à l’ordonnancement des événements.
Lancez l’exportation initiale : exécutez manuellement le travail d’exportation (type de travail : Export) pour charger l’ensemble des données historiques dans la base Azure SQL. Consultez le récapitulatif d’exécution pour vérifier que tous les enregistrements ont été transférés.
Planifiez les mises à jour incrémentielles : configurez un travail de données récurrent pour exécuter régulièrement le projet d’exportation, par exemple toutes les 4 heures ou chaque nuit, en utilisant « Incremental push » afin de ne mettre à jour que les enregistrements modifiés.
Connectez-vous à Azure SQL : utilisez SQL Server Management Studio (SSMS) ou un outil similaire pour vous connecter à la base Azure SQL BYOD.
Exécutez le script de transformation : lancez sur les tables BYOD le script SQL fourni dans la section Query ci-dessous. Il regroupe les différentes tables en une seule structure de journal d’événements.
Vérifiez et extrayez les données : contrôlez la cohérence des résultats (voir les étapes de validation). Exportez le jeu de résultats dans un fichier CSV ou Parquet à importer dans ProcessMind.

Configuration

Méthode d’exportation : Bring Your Own Database (BYOD) ou Azure Data Lake Storage Gen2 (ADLS).
Stratégie d’actualisation : Full push pour le chargement initial, puis Incremental push pour les mises à jour récurrentes afin de limiter l’impact sur les performances.
Entités requises : CustInvoiceJournalHeaderEntity (factures), CustSettlementEntity (paiements/lettrage), CustCollectionLetterJournalHeaderEntity (relances), CaseDetailEntity (litiges), BankAccountTransEntity (rapprochement bancaire).
Filtre sur la société : appliquez des filtres à la colonne « DataAreaId » si l’analyse doit porter sur certaines entités juridiques.
Période : une fenêtre glissante de 12 mois, basée sur « InvoiceDate » ou « TransDate », est recommandée.
Suivi des modifications : cette fonction doit être activée sur les tables SQL de D365 pour que l’exportation incrémentielle soit efficace.

a Exemple de requête sql

/* SQL Transformation Script for D365 BYOD Tables */
/* Target: Azure SQL Database containing exported entities */

WITH InvoiceBasics AS (
    SELECT 
        InvoiceNumber AS InvoiceId,
        InvoiceDate,
        DueDate,
        InvoiceAccount AS CustomerAccount,
        SalesId,
        DataAreaId AS CompanyCode,
        InvoiceAmount,
        Currency
    FROM dbo.CustInvoiceJournalHeaderEntity
    WHERE InvoiceDate >= DATEADD(month, -12, GETDATE())
)

/* 1. Invoice Posted */
SELECT 
    T1.InvoiceId AS InvoiceNumber,
    'Invoice Posted' AS Activity,
    CAST(T1.InvoiceDate AS DATETIME) AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    T1.CustomerAccount,
    NULL AS CustomerGroup,
    T1.InvoiceAmount,
    T1.DueDate,
    NULL AS [User],
    NULL AS BusinessUnit,
    T1.CompanyCode,
    1 AS IsAutomated
FROM InvoiceBasics T1

UNION ALL

/* 2. Invoice Dispatched (Inferred from Document Date as Proxy if Print Log unavailable) */
SELECT 
    T1.InvoiceId,
    'Invoice Dispatched' AS Activity,
    DATEADD(minute, 5, CAST(T1.InvoiceDate AS DATETIME)) AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    T1.CustomerAccount,
    NULL,
    T1.InvoiceAmount,
    T1.DueDate,
    NULL,
    NULL,
    T1.CompanyCode,
    1
FROM InvoiceBasics T1

UNION ALL

/* 3. Due Date Passed (Synthetic Event) */
SELECT 
    T1.InvoiceId,
    'Due Date Passed' AS Activity,
    CAST(T1.DueDate AS DATETIME) AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    T1.CustomerAccount,
    NULL,
    T1.InvoiceAmount,
    T1.DueDate,
    NULL,
    NULL,
    T1.CompanyCode,
    1
FROM InvoiceBasics T1
WHERE GETDATE() > T1.DueDate

UNION ALL

/* 4. Payment Reminder Sent */
SELECT 
    Inv.InvoiceId,
    'Payment Reminder Sent' AS Activity,
    CL.JournalDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    CL.CreatedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CustCollectionLetterJournalHeaderEntity CL
JOIN dbo.CustCollectionLetterLineEntity CLL ON CL.JournalNumber = CLL.JournalNumber AND CL.DataAreaId = CLL.DataAreaId
JOIN InvoiceBasics Inv ON CLL.InvoiceId = Inv.InvoiceId AND CLL.DataAreaId = Inv.CompanyCode

UNION ALL

/* 5. Promise to Pay Received */
SELECT 
    Inv.InvoiceId,
    'Promise to Pay Received' AS Activity,
    PTP.PromiseDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    NULL,
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CustPromiseToPayEntity PTP
JOIN InvoiceBasics Inv ON PTP.Invoice = Inv.InvoiceId AND PTP.DataAreaId = Inv.CompanyCode

UNION ALL

/* 6. Dispute Case Opened */
SELECT 
    Inv.InvoiceId,
    'Dispute Case Opened' AS Activity,
    CD.CreatedDateTime AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    CD.CreatedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CaseDetailEntity CD
JOIN dbo.CaseAssociationEntity CA ON CD.CaseId = CA.CaseId AND CD.DataAreaId = CA.DataAreaId
JOIN InvoiceBasics Inv ON CA.RefRecId = Inv.InvoiceId /* Logic assumes linking via Invoice Number or manual mapping might be needed depending on RefTableId */
WHERE CA.RefEntityName = 'CustInvoiceTable'

UNION ALL

/* 7. Dispute Under Review */
SELECT 
    Inv.InvoiceId,
    'Dispute Under Review' AS Activity,
    CD.ModifiedDateTime AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    CD.ModifiedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CaseDetailEntity CD
JOIN dbo.CaseAssociationEntity CA ON CD.CaseId = CA.CaseId AND CD.DataAreaId = CA.DataAreaId
JOIN InvoiceBasics Inv ON CA.RefRecId = Inv.InvoiceId
WHERE CD.Status = 'InProcess'

UNION ALL

/* 8. Dispute Resolved */
SELECT 
    Inv.InvoiceId,
    'Dispute Resolved' AS Activity,
    CD.ClosedDateTime AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    CD.ModifiedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CaseDetailEntity CD
JOIN dbo.CaseAssociationEntity CA ON CD.CaseId = CA.CaseId AND CD.DataAreaId = CA.DataAreaId
JOIN InvoiceBasics Inv ON CA.RefRecId = Inv.InvoiceId
WHERE CD.Status = 'Closed'

UNION ALL

/* 9. Credit Memo Issued */
SELECT 
    T1.InvoiceId,
    'Credit Memo Issued' AS Activity,
    T1.InvoiceDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    T1.CustomerAccount,
    NULL,
    T1.InvoiceAmount,
    T1.DueDate,
    NULL,
    NULL,
    T1.CompanyCode,
    0
FROM dbo.CustInvoiceJournalHeaderEntity T1
WHERE T1.InvoiceAmount < 0

UNION ALL

/* 10. Interest Note Generated */
SELECT 
    Inv.InvoiceId,
    'Interest Note Generated' AS Activity,
    IJ.InterestDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    IJ.CreatedBy AS [User],
    NULL,
    Inv.CompanyCode,
    1
FROM dbo.CustInterestJournalEntity IJ
JOIN InvoiceBasics Inv ON IJ.AccountDisplayValue = Inv.CustomerAccount AND IJ.DataAreaId = Inv.CompanyCode
/* Note: Direct link to specific Invoice ID is often via CustInterestTrans, requiring an additional join */

UNION ALL

/* 11. Partial Payment Posted */
SELECT 
    Inv.InvoiceId,
    'Partial Payment Posted' AS Activity,
    Sett.TransDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Sett.SettleAmountCur AS InvoiceAmount,
    Inv.DueDate,
    Sett.CreatedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CustSettlementEntity Sett
JOIN dbo.CustTransactionEntity Trans ON Sett.TransRecId = Trans.RecId
JOIN InvoiceBasics Inv ON Trans.Invoice = Inv.InvoiceId AND Trans.DataAreaId = Inv.CompanyCode
WHERE ABS(Sett.SettleAmountCur) < ABS(Trans.AmountCur) AND Sett.SettleAmountCur <> 0

UNION ALL

/* 12. Full Payment Received */
SELECT 
    Inv.InvoiceId,
    'Full Payment Received' AS Activity,
    Sett.TransDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Sett.SettleAmountCur AS InvoiceAmount,
    Inv.DueDate,
    Sett.CreatedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CustSettlementEntity Sett
JOIN dbo.CustTransactionEntity Trans ON Sett.TransRecId = Trans.RecId
JOIN InvoiceBasics Inv ON Trans.Invoice = Inv.InvoiceId AND Trans.DataAreaId = Inv.CompanyCode
WHERE ABS(Sett.SettleAmountCur) >= ABS(Trans.AmountCur)

UNION ALL

/* 13. Bank Statement Matched */
SELECT 
    Inv.InvoiceId,
    'Bank Statement Matched' AS Activity,
    Bank.TransDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Bank.AmountCur AS InvoiceAmount,
    Inv.DueDate,
    NULL,
    NULL,
    Inv.CompanyCode,
    1
FROM dbo.BankAccountTransEntity Bank
JOIN dbo.CustSettlementEntity Sett ON Bank.Voucher = Sett.OffsetTransVoucher AND Bank.DataAreaId = Sett.DataAreaId
JOIN dbo.CustTransactionEntity Trans ON Sett.TransRecId = Trans.RecId
JOIN InvoiceBasics Inv ON Trans.Invoice = Inv.InvoiceId

UNION ALL

/* 14. Payment Written Off */
SELECT 
    Inv.InvoiceId,
    'Payment Written Off' AS Activity,
    Trans.TransDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Trans.AmountCur AS InvoiceAmount,
    Inv.DueDate,
    Trans.CreatedBy AS [User],
    NULL,
    Inv.CompanyCode,
    0
FROM dbo.CustTransactionEntity Trans
JOIN InvoiceBasics Inv ON Trans.Invoice = Inv.InvoiceId AND Trans.DataAreaId = Inv.CompanyCode
WHERE Trans.TransactionType = 'WriteOff'

UNION ALL

/* 15. Invoice Cleared */
SELECT 
    Inv.InvoiceId,
    'Invoice Cleared' AS Activity,
    Trans.ClosedDate AS EventTimestamp,
    'D365 F&O' AS SourceSystem,
    GETDATE() AS LastDataUpdate,
    Inv.CustomerAccount,
    NULL,
    Inv.InvoiceAmount,
    Inv.DueDate,
    NULL,
    NULL,
    Inv.CompanyCode,
    1
FROM dbo.CustTransactionEntity Trans
JOIN InvoiceBasics Inv ON Trans.Invoice = Inv.InvoiceId AND Trans.DataAreaId = Inv.CompanyCode
WHERE Trans.ClosedDate IS NOT NULL AND Trans.ClosedDate <> '1900-01-01'

Étapes

Installez les prérequis : vérifiez que Python 3.x est installé sur la machine d’exécution. Installez les bibliothèques requises avec pip : pandas, requests et msal (si vous utilisez Microsoft Authentication Library, même si ce script fait appel directement à REST pour plus de simplicité).
Enregistrez une application Azure : enregistrez une application dans Azure Active Directory (Entra ID) pour autoriser l’accès à Dynamics 365. Notez l’ID client, le secret client et l’ID d’environnement. Vérifiez que l’application dispose des autorisations d’API pour Dynamics ERP (OData).
Configurez le script : ouvrez le script Python fourni. Modifiez le dictionnaire config en haut du fichier en indiquant l’URL D365, l’ID client, le secret client, l’ID d’environnement et le code société cible (dataAreaId).
Définissez la période : modifiez les variables start_date et end_date du script pour définir la fenêtre d’extraction. Pour les chargements incrémentiels, il est recommandé d’utiliser une fenêtre glissante couvrant les 90 à 180 derniers jours.
Lancez l’extraction : exécutez le script. Il s’authentifie auprès d’Azure AD, récupère un jeton d’accès et parcourt plusieurs entités OData (CustomerInvoices, PaymentJournals, CaseDetails, etc.) pour extraire les données.
Traitez les données : le script transforme automatiquement les données, par exemple en renommant les colonnes pour qu’elles correspondent au schéma ProcessMind, en calculant les événements « Date d’échéance dépassée » à partir de la date système et en distinguant les paiements partiels des paiements complets selon les montants des transactions.
Regroupez et triez les données : le script concatène toutes les trames de données d’activité dans un seul journal d’événements, puis les trie par InvoiceNumber et EventTimestamp.
Exportez les données : la trame de données finale est exportée dans un fichier CSV nommé AR_Event_Log.csv. Vérifiez que ce fichier a bien été créé dans le répertoire du script.
Validez les données : ouvrez le fichier CSV et vérifiez que les dates sont au format ISO (YYYY-MM-DD HH:MM:SS) et que toutes les colonnes requises sont renseignées.
Importez le fichier : importez le fichier CSV généré dans ProcessMind à l’aide de l’assistant standard d’importation de fichiers. Associez les colonnes InvoiceNumber à ID de cas, Activity à Activité et EventTimestamp à Horodatage.

Configuration

Taille des lots : le script utilise une taille de page par défaut, souvent de 1 000 enregistrements, définie par le serveur. Il gère automatiquement la pagination à l’aide de la propriété @odata.nextLink.
Filtres de date : le paramètre OData $filter limite l’extraction aux périodes pertinentes, par exemple InvoiceDate ge 2023-01-01T00:00:00Z. Cela améliore considérablement les performances.
Filtrage par société : D365 stocke les données de plusieurs entités juridiques. Le script filtre par dataAreaId pour n’extraire que les données de l’unité opérationnelle concernée.
Authentification : le script utilise OAuth 2.0 (Client Credentials Flow). Vous devez disposer d’un secret client et d’un enregistrement d’application valides.
Sélection des entités : le script utilise des entités standard telles que CustomerInvoices, CustomerPaymentJournalLines et CaseDetail. Si votre organisation utilise des entités personnalisées, vous devez mettre à jour les points de terminaison du dictionnaire endpoints.
Événements calculés : les événements tels que « Date d’échéance dépassée » sont calculés pendant l’exécution du script, car ils ne génèrent pas de journal de transaction spécifique dans la base de données.

a Exemple de requête python

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

class=class="hl-string">"hl-comment"># === CONFIGURATION ===
config = {
    class="hl-string">"resource": class="hl-string">"https://[YourOrg].operations.dynamics.com",
    class="hl-string">"tenant_id": class="hl-string">"[Your-Tenant-ID]",
    class="hl-string">"client_id": class="hl-string">"[Your-Client-ID]",
    class="hl-string">"client_secret": class="hl-string">"[Your-Client-Secret]",
    class="hl-string">"company_code": class="hl-string">"USMF",  class=class="hl-string">"hl-comment"># Example Company Code
    class="hl-string">"start_date": class="hl-string">"2023-01-01T00:00:00Z"
}

class=class="hl-string">"hl-comment"># === AUTHENTICATION ===
def get_token(config):
    token_url = fclass="hl-string">"https://login.microsoftonline.com/{config['tenant_id']}/oauth2/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': config[class="hl-string">'client_id'],
        class="hl-string">'client_secret': config[class="hl-string">'client_secret'],
        class="hl-string">'resource': config[class="hl-string">'resource']
    }
    response = requests.post(token_url, data=payload)
    if response.status_code == 200:
        return response.json().get(class="hl-string">'access_token')
    else:
        raise Exception(fclass="hl-string">"Auth Failed: {response.text}")

class=class="hl-string">"hl-comment"># === ODATA FETCHER ===
def get_odata_data(token, entity_url, filter_str):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'Accept': class="hl-string">'application/json'}
    results = []
    next_link = fclass="hl-string">"{config['resource']}/data/{entity_url}?$filter={filter_str}&$format=json"
    
    while next_link:
        print(fclass="hl-string">"Fetching: {next_link}")
        try:
            res = requests.get(next_link, headers=headers)
            if res.status_code != 200:
                print(fclass="hl-string">"Error fetching data: {res.text}")
                break
            data = res.json()
            results.extend(data.get(class="hl-string">'value', []))
            next_link = data.get(class="hl-string">'@odata.nextLink', None)
        except Exception as e:
            print(fclass="hl-string">"Exception: {e}")
            break
    return pd.DataFrame(results)

class=class="hl-string">"hl-comment"># === MAIN EXTRACTION ===
def main():
    token = get_token(config)
    all_events = []
    company_filter = fclass="hl-string">"dataAreaId eq '{config['company_code']}'"
    date_filter = fclass="hl-string">"InvoiceDate ge {config['start_date']}"

    class=class="hl-string">"hl-comment"># 1. INVOICE BASIC EVENTS (Posted, Dispatched, Credit Memo, Cleared)
    class=class="hl-string">"hl-comment"># Entity: CustomerInvoices (or SalesInvoiceHeaders)
    print(class="hl-string">"Processing Invoices...")
    df_inv = get_odata_data(token, class="hl-string">"CustomerInvoices", fclass="hl-string">"{company_filter} and {date_filter}")
    
    if not df_inv.empty:
        class=class="hl-string">"hl-comment"># Activity: Invoice Posted
        posted = df_inv.copy()
        posted[class="hl-string">'Activity'] = class="hl-string">'Invoice Posted'
        posted[class="hl-string">'EventTimestamp'] = posted[class="hl-string">'InvoiceDate']
        all_events.append(posted)

        class=class="hl-string">"hl-comment"># Activity: Invoice Dispatched (Assumed same day as posted if not tracked separately)
        dispatched = df_inv.copy()
        dispatched[class="hl-string">'Activity'] = class="hl-string">'Invoice Dispatched'
        dispatched[class="hl-string">'EventTimestamp'] = dispatched[class="hl-string">'InvoiceDate']  class=class="hl-string">"hl-comment"># Often inferred
        all_events.append(dispatched)

        class=class="hl-string">"hl-comment"># Activity: Credit Memo Issued
        credit_memos = df_inv[df_inv[class="hl-string">'InvoiceAmount'] < 0].copy()
        credit_memos[class="hl-string">'Activity'] = class="hl-string">'Credit Memo Issued'
        credit_memos[class="hl-string">'EventTimestamp'] = credit_memos[class="hl-string">'InvoiceDate']
        all_events.append(credit_memos)

        class=class="hl-string">"hl-comment"># Activity: Invoice Cleared (Closed)
        class=class="hl-string">"hl-comment"># Note: ClosedDate might need to be cast to datetime
        cleared = df_inv[df_inv[class="hl-string">'ClosedDate'].notnull()].copy()
        if not cleared.empty:
            cleared[class="hl-string">'Activity'] = class="hl-string">'Invoice Cleared'
            cleared[class="hl-string">'EventTimestamp'] = cleared[class="hl-string">'ClosedDate']
            all_events.append(cleared)

        class=class="hl-string">"hl-comment"># Activity: Due Date Passed (Calculated)
        class=class="hl-string">"hl-comment"># Logic: If not closed, and DueDate < Now
        now = datetime.datetime.now()
        overdue = df_inv[(df_inv[class="hl-string">'ClosedDate'].isnull())].copy()
        class=class="hl-string">"hl-comment"># Convert DueDate to datetime objects for comparison
        overdue[class="hl-string">'DueDate_DT'] = pd.to_datetime(overdue[class="hl-string">'DueDate'])
        overdue = overdue[overdue[class="hl-string">'DueDate_DT'] < now]
        if not overdue.empty:
            overdue[class="hl-string">'Activity'] = class="hl-string">'Due Date Passed'
            class=class="hl-string">"hl-comment"># Timestamp is the day it became overdue
            overdue[class="hl-string">'EventTimestamp'] = overdue[class="hl-string">'DueDate'] 
            all_events.append(overdue)

    class=class="hl-string">"hl-comment"># 2. PAYMENTS (Partial, Full, WriteOff)
    class=class="hl-string">"hl-comment"># Entity: CustomerPaymentJournalLines
    print(class="hl-string">"Processing Payments...")
    class=class="hl-string">"hl-comment"># Note: Filter by TransDate usually
    df_pay = get_odata_data(token, class="hl-string">"CustomerPaymentJournalLines", fclass="hl-string">"{company_filter}")
    
    if not df_pay.empty:
        class=class="hl-string">"hl-comment"># Activity: Partial vs Full Payment
        class=class="hl-string">"hl-comment"># Logic requires comparing payment amount to invoice balance. simplified here based on Amount
        class=class="hl-string">"hl-comment"># Assuming we join with invoices later, strictly classifying based on available fields
        class=class="hl-string">"hl-comment"># Here we assume a field class="hl-string">'PaymentStatus' or we treat all as Partial unless marked Settled
        
        class=class="hl-string">"hl-comment"># Full Payment
        full_pay = df_pay.copy()
        full_pay[class="hl-string">'Activity'] = class="hl-string">'Full Payment Received'
        full_pay[class="hl-string">'EventTimestamp'] = full_pay[class="hl-string">'TransDate']
        all_events.append(full_pay)
        
        class=class="hl-string">"hl-comment"># Partial Payment (In a real scenario, this requires logic checking settlement vs invoice total)
        class=class="hl-string">"hl-comment"># Adding a duplicate row for demonstration of structure
        partial_pay = df_pay[df_pay[class="hl-string">'Amount'] < 1000].copy() class=class="hl-string">"hl-comment"># Placeholder logic
        partial_pay[class="hl-string">'Activity'] = class="hl-string">'Partial Payment Posted'
        partial_pay[class="hl-string">'EventTimestamp'] = partial_pay[class="hl-string">'TransDate']
        all_events.append(partial_pay)

        class=class="hl-string">"hl-comment"># Activity: Payment Written Off
        class=class="hl-string">"hl-comment"># Filter by specific Transaction Type or Journal Name
        write_off = df_pay[df_pay[class="hl-string">'JournalName'].str.contains(class="hl-string">'WriteOff', case=False, na=False)].copy()
        write_off[class="hl-string">'Activity'] = class="hl-string">'Payment Written Off'
        write_off[class="hl-string">'EventTimestamp'] = write_off[class="hl-string">'TransDate']
        all_events.append(write_off)

    class=class="hl-string">"hl-comment"># 3. COLLECTIONS (Reminders, Promise to Pay)
    class=class="hl-string">"hl-comment"># Entity: CollectionLetterJournals
    print(class="hl-string">"Processing Collections...")
    df_col = get_odata_data(token, class="hl-string">"CollectionLetterJournals", fclass="hl-string">"{company_filter}")
    if not df_col.empty:
        reminders = df_col.copy()
        reminders[class="hl-string">'Activity'] = class="hl-string">'Payment Reminder Sent'
        reminders[class="hl-string">'EventTimestamp'] = reminders[class="hl-string">'LetterDate']
        all_events.append(reminders)

    class=class="hl-string">"hl-comment"># Entity: CustomerPromiseToPay
    df_promise = get_odata_data(token, class="hl-string">"CustomerPromiseToPay", fclass="hl-string">"{company_filter}")
    if not df_promise.empty:
        promises = df_promise.copy()
        promises[class="hl-string">'Activity'] = class="hl-string">'Promise to Pay Received'
        promises[class="hl-string">'EventTimestamp'] = promises[class="hl-string">'CreatedDateTime']
        all_events.append(promises)

    class=class="hl-string">"hl-comment"># 4. DISPUTES (Opened, Review, Resolved)
    class=class="hl-string">"hl-comment"># Entity: CaseDetails (requires filtering for Collections/Dispute category)
    print(class="hl-string">"Processing Disputes...")
    df_case = get_odata_data(token, class="hl-string">"CaseDetails", fclass="hl-string">"{company_filter} and Category eq 'Collections'")
    if not df_case.empty:
        class=class="hl-string">"hl-comment"># Opened
        opened = df_case.copy()
        opened[class="hl-string">'Activity'] = class="hl-string">'Dispute Case Opened'
        opened[class="hl-string">'EventTimestamp'] = opened[class="hl-string">'CreatedDateTime']
        all_events.append(opened)

        class=class="hl-string">"hl-comment"># Under Review (In Process)
        in_process = df_case[df_case[class="hl-string">'Status'] == class="hl-string">'InProcess'].copy()
        in_process[class="hl-string">'Activity'] = class="hl-string">'Dispute Under Review'
        in_process[class="hl-string">'EventTimestamp'] = in_process[class="hl-string">'ModifiedDateTime']
        all_events.append(in_process)

        class=class="hl-string">"hl-comment"># Resolved (Closed)
        resolved = df_case[df_case[class="hl-string">'Status'] == class="hl-string">'Closed'].copy()
        resolved[class="hl-string">'Activity'] = class="hl-string">'Dispute Resolved'
        resolved[class="hl-string">'EventTimestamp'] = resolved[class="hl-string">'ClosedDateTime']
        all_events.append(resolved)

    class=class="hl-string">"hl-comment"># 5. INTEREST
    class=class="hl-string">"hl-comment"># Entity: InterestNotes
    print(class="hl-string">"Processing Interest Notes...")
    df_interest = get_odata_data(token, class="hl-string">"InterestNotes", fclass="hl-string">"{company_filter}")
    if not df_interest.empty:
        interest = df_interest.copy()
        interest[class="hl-string">'Activity'] = class="hl-string">'Interest Note Generated'
        interest[class="hl-string">'EventTimestamp'] = interest[class="hl-string">'NoteDate']
        all_events.append(interest)

    class=class="hl-string">"hl-comment"># 6. BANK RECONCILIATION
    class=class="hl-string">"hl-comment"># Entity: BankReconciliationLines (Placeholder for matching)
    print(class="hl-string">"Processing Bank Reconciliation...")
    class=class="hl-string">"hl-comment"># This entity availability varies by version
    df_bank = get_odata_data(token, class="hl-string">"BankReconciliationLines", fclass="hl-string">"{company_filter}")
    if not df_bank.empty:
        matched = df_bank[df_bank[class="hl-string">'Reconciled'] == True].copy()
        matched[class="hl-string">'Activity'] = class="hl-string">'Bank Statement Matched'
        matched[class="hl-string">'EventTimestamp'] = matched[class="hl-string">'TransactionDate']
        class=class="hl-string">"hl-comment"># Need to join with Invoice via Payment Reference ideally
        class=class="hl-string">"hl-comment"># For this script, we assume InvoiceNumber is present or mapped
        all_events.append(matched)

    class=class="hl-string">"hl-comment"># === UNIFICATION & EXPORT ===
    if not all_events:
        print(class="hl-string">"No events extracted.")
        return

    final_df = pd.concat(all_events, ignore_index=True)

    class=class="hl-string">"hl-comment"># Map columns to schema
    class=class="hl-string">"hl-comment"># Note: Column names class="hl-string">'InvoiceNumber', class="hl-string">'InvoiceAccount' etc. depend on exact Entity schema
    class=class="hl-string">"hl-comment"># You may need to rename based on your D365 entity fields, e.g., class="hl-string">'InvoiceNum' -> class="hl-string">'InvoiceNumber'
    schema_map = {
        class="hl-string">'InvoiceNumber': class="hl-string">'InvoiceNumber',
        class="hl-string">'InvoiceId': class="hl-string">'InvoiceNumber', class=class="hl-string">"hl-comment"># Alternative common name
        class="hl-string">'InvoiceAccount': class="hl-string">'CustomerAccount',
        class="hl-string">'CustomerAccount': class="hl-string">'CustomerAccount',
        class="hl-string">'InvoiceAmount': class="hl-string">'InvoiceAmount',
        class="hl-string">'Amount': class="hl-string">'InvoiceAmount', class=class="hl-string">"hl-comment"># Fallback for payments
        class="hl-string">'CurrencyCode': class="hl-string">'Currency',
        class="hl-string">'DueDate': class="hl-string">'DueDate',
        class="hl-string">'CreatedBy': class="hl-string">'User',
        class="hl-string">'BusinessUnit': class="hl-string">'BusinessUnit',
        class="hl-string">'DataAreaId': class="hl-string">'CompanyCode'
    }
    
    class=class="hl-string">"hl-comment"># Normalize columns
    for col in final_df.columns:
        if col in schema_map:
            final_df.rename(columns={col: schema_map[col]}, inplace=True)

    class=class="hl-string">"hl-comment"># Add constant fields
    final_df[class="hl-string">'SourceSystem'] = class="hl-string">'Microsoft D365'
    final_df[class="hl-string">'LastDataUpdate'] = datetime.datetime.now().isoformat()
    
    class=class="hl-string">"hl-comment"># Select final columns (fill missing with None)
    required_cols = [
        class="hl-string">'InvoiceNumber', class="hl-string">'Activity', class="hl-string">'EventTimestamp', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate',
        class="hl-string">'CustomerAccount', class="hl-string">'CustomerGroup', class="hl-string">'InvoiceAmount', class="hl-string">'DueDate', class="hl-string">'User',
        class="hl-string">'BusinessUnit', class="hl-string">'CompanyCode', class="hl-string">'IsAutomated'
    ]
    
    for col in required_cols:
        if col not in final_df.columns:
            final_df[col] = None
            
    output_df = final_df[required_cols]
    
    class=class="hl-string">"hl-comment"># Export
    output_df.to_csv(class="hl-string">"AR_Event_Log.csv", index=False)
    print(class="hl-string">"Extraction complete. Saved to AR_Event_Log.csv")

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

Prêt à commencer ?

Commencez dès aujourd’hui à améliorer vos opérations financières grâce à ce modèle de données. Notre équipe peut vous aider à associer vos données Microsoft Dynamics 365 à ces exigences.

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

Optimisez la gestion de vos créances clients et améliorez votre trésorerie dès maintenant

Rejoignez les équipes qui réduisent leur DSO de 15 à 20 jours dans Microsoft Dynamics 365

Démarrez l’essai gratuit

Aucune carte bancaire requise, configuration en 5 minutes

Votre modèle de données pour les créances clients

Votre modèle de données pour les créances clients

Attributs des créances clients

Activités liées aux créances clients

Guides d’extraction

Export d’entités avec le framework de gestion des données de D365

Étapes

Configuration

a Exemple de requête sql

Extraction des événements de créances clients via l’API OData de Python

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez la gestion de vos créances clients et améliorez votre trésorerie dès maintenant

Votre modèle de données pour les créances clients

Votre modèle de données pour les créances clients

Attributs des créances clients

Activités liées aux créances clients

Guides d’extraction

Export d’entités avec le framework de gestion des données de D365

Étapes

Configuration

a Exemple de requête sql

Extraction des événements de créances clients via l’API OData de Python

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez la gestion de vos créances clients et améliorez votre trésorerie dès maintenant

Nous respectons votre vie privée

Prêt à commencer ?