> Amélioration continue des processus > Clôture comptable et saisie des écritures > Microsoft Dynamics 365 > Modèle de données

Votre modèle de données pour le processus de clôture comptable et les écritures comptables

Microsoft Dynamics 365

← Retour au guide d’amélioration

Attributs du processus de comptabilisation des écritures, de l’enregistrement au reporting(20) Activités du processus de comptabilisation des écritures, de l’enregistrement au reporting(12) Guides d’extraction(4)

Votre modèle de données pour le processus de clôture comptable et les écritures comptables

Ce modèle présente les principales données nécessaires à l’analyse de votre processus de comptabilisation des écritures, de l’enregistrement au reporting. Il indique les attributs à recueillir et les activités à suivre pour disposer des informations utiles à une démarche efficace de Process Mining. Vous y trouverez également des conseils pratiques pour extraire ces données de votre système source.

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

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

Télécharger le modèle

Attributs du processus de comptabilisation des écritures, de l’enregistrement au reporting

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail le processus de comptabilisation des écritures, de l’enregistrement au reporting.

3 Obligatoire 7 Recommandé 10 Facultatif

	Nom	Description
	Heure de l’événement EventTime	Horodatage précis indiquant le moment où une activité ou un événement s’est produit.
Description L’heure de l’événement indique la date et l’heure auxquelles une activité précise du processus de saisie des écritures comptables a eu lieu. Ces données chronologiques sont indispensables pour ordonner les événements et calculer le délai qui les sépare. Lors de l’analyse, cet horodatage sert à établir la chronologie de chaque cas. Il est essentiel au calcul des indicateurs temporels, comme les temps de cycle, les durées de traitement et les temps d’attente. Il permet de repérer les retards entre les étapes et alimente les Dashboards consacrés aux goulots d’étranglement et au respect des SLA. Pourquoi est-ce important ? Cet horodatage est indispensable pour ordonner correctement les événements et calculer les KPI liés aux durées, comme le temps de cycle et les retards de traitement. Où trouver ces données Les horodatages des événements se trouvent généralement dans les journaux d’historique du flux de travail, les tables de pistes d’audit (par exemple SysDatabaseLog) ou les champs de création et de modification des enregistrements associés, comme LedgerJournalTable et LedgerJournalTrans. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:10Z
	Identifiant de l’écriture comptable JournalEntryId	Identifiant unique d’une écriture comptable, qui sert d’identifiant principal du cas.
Description L’identifiant de l’écriture comptable relie de manière unique toutes les activités et données associées à une même transaction. Il permet de suivre l’ensemble du cycle de vie de l’écriture, de sa création et sa vérification jusqu’à sa comptabilisation dans le grand livre. Dans l’analyse de process mining, cet attribut est indispensable pour reconstituer le flux du processus. Chaque identifiant unique correspond à une instance du processus et permet d’examiner en détail les variantes, les temps de cycle et la conformité de chaque transaction financière. Pourquoi est-ce important ? Cet identifiant est la clé qui permet de suivre une écriture comptable du début à la fin et d’analyser l’ensemble du processus pour chaque cas. Où trouver ces données Cet identifiant se trouve généralement dans la table d’en-tête des écritures, par exemple LedgerJournalTable, souvent dans un champ nommé JournalNum. Exemples JRN-0012345JV-2023-08-156GENJ0000891
	Nom de l’activité ActivityName	Nom de l’étape ou de l’événement précis du processus métier qui s’est produit.
Description Cet attribut décrit un événement ou une tâche du cycle de vie d’une écriture comptable, par exemple « Écriture comptable créée », « Écriture soumise pour approbation » ou « Écriture comptable comptabilisée ». Ces activités constituent les nœuds de la carte du processus découverte. L’analyse de leur séquence et de leur fréquence est au cœur du process mining. Elle révèle le déroulement réel du processus, aide à repérer les écarts par rapport à la procédure standard et met en évidence les goulots d’étranglement, lorsque des activités prennent plus de temps que prévu ou sont répétées. Pourquoi est-ce important ? Cet attribut définit les étapes du processus. Il forme la structure de la carte du processus et permet d’analyser son déroulement et ses variantes. Où trouver ces données Il s’agit d’un attribut conceptuel déduit des événements système, des changements de statut ou des journaux du flux de travail dans Microsoft Dynamics 365. Exemples Écriture comptable crééeÉcriture soumise pour approbationÉcriture approuvéeÉcriture comptable comptabilisée
	Entité juridique LegalEntity	Entité juridique ou code société auquel l’écriture comptable est imputée.
Description L’entité juridique désigne la société ou l’unité opérationnelle précise au sein d’une organisation à laquelle la transaction financière est imputée. Il s’agit d’une dimension organisationnelle fondamentale des systèmes financiers. En Process Mining, cet attribut permet de comparer le processus de traitement des écritures comptables entre différentes entités de l’organisation. Il peut révéler que certaines entités juridiques ont des processus plus efficaces, des taux de rejet plus élevés ou des temps de cycle plus longs, et ainsi aider à repérer et à partager les bonnes pratiques. Pourquoi est-ce important ? Permet de comparer les performances des processus entre sociétés ou unités opérationnelles, afin de repérer les écarts et les possibilités d’amélioration. Où trouver ces données Il s’agit d’un champ essentiel dans Dynamics 365, souvent disponible dans des tables de transactions comme LedgerJournalTable et généralement associé à DataAreaId. Exemples USMFDEMFGBSI
	Heure de fin de l’événement EventEndTime	Horodatage indiquant le moment où une activité ou un événement s’est terminé.
Description L’heure de fin de l’événement indique le moment où une activité précise s’achève. StartTime indique le début de l’événement, tandis que EndTime en marque l’autre limite et permet de calculer précisément la durée de chaque tâche. En process mining, disposer des heures de début et de fin permet de calculer la durée de traitement d’une activité, distincte du temps d’attente. Cette information est essentielle aux Dashboards qui analysent les performances des utilisateurs et repèrent les tâches précises, et non seulement les intervalles entre elles, qui prennent le plus de temps. Pourquoi est-ce important ? Permet de calculer précisément la durée de chaque activité, ce qui est essentiel pour analyser les performances des utilisateurs et repérer les tâches qui mobilisent le plus de ressources. Où trouver ces données Ces données peuvent être enregistrées explicitement dans les journaux du flux de travail ou calculées à partir du StartTime de l’activité suivante dans la séquence. Exemples 2023-10-26T10:05:15Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
	Montant total du journal JournalTotalAmount	Valeur monétaire totale de l’écriture comptable, généralement égale à la somme des débits.
Description Cet attribut correspond à la valeur financière totale de l’écriture comptable. Il permet de classer les écritures par tranche de valeur, par exemple faible, moyenne ou élevée. L’analyse du processus selon la valeur financière peut faire ressortir des tendances importantes. Les écritures de montant élevé, par exemple, peuvent suivre un processus d’approbation plus strict, comportant davantage d’étapes et des temps de cycle plus longs. Cet attribut est essentiel à l’analyse de l’importance relative des montants et à l’évaluation de l’incidence financière des inefficacités du processus. Pourquoi est-ce important ? Permet de segmenter le processus selon la valeur financière, souvent liée à sa complexité, aux risques et aux circuits d’approbation. Où trouver ces données Il peut être nécessaire de calculer cette valeur en additionnant, pour chaque écriture comptable, les montants au débit de la table des lignes de journal LedgerJournalTrans. Exemples 1500.75125000.0050.25
	Motif du rejet RejectionReason	Motif indiqué lorsqu’une écriture comptable est rejetée au cours du processus d’approbation.
Description Lorsqu’une écriture comptable est rejetée, la personne chargée de l’approbation en indique souvent le motif. Cet attribut consigne cette information, essentielle à l’analyse des causes profondes. Cet attribut est au cœur du Dashboard « Analyse du taux de rejet des écritures comptables ». En classant et en analysant les motifs de rejet, les organisations peuvent repérer les problèmes récurrents, comme une documentation incorrecte, le non-respect des règles ou des erreurs de saisie, puis mettre en place des formations ciblées ou améliorer les processus. Pourquoi est-ce important ? Explique les causes des reprises et fournit les informations nécessaires pour réduire les rejets et augmenter le taux d’approbation correcte dès la première soumission. Où trouver ces données Cette information figure généralement dans l’historique du flux de travail ou dans les commentaires associés à l’étape de rejet. Exemples Justificatifs insuffisantsCompte incorrectDépasse le seuil d’approbationÉcriture en double
	Nom de l’utilisateur UserName	Nom de l’utilisateur qui a effectué l’activité.
Description Cet attribut identifie l’employé ou l’utilisateur système responsable d’une activité précise, comme la création, l’approbation ou la comptabilisation d’une écriture. Il relie les étapes du processus aux personnes qui les réalisent. L’analyse des performances par utilisateur est une fonctionnalité clé du process mining. Elle permet de créer le Dashboard « Performances des utilisateurs pour la saisie des écritures comptables » et de comparer la durée des activités et le débit de traitement entre utilisateurs ou équipes. Elle peut mettre en évidence les meilleures performances, les besoins de formation et les possibilités de mieux répartir la charge de travail. Pourquoi est-ce important ? Relie les activités du processus à des personnes précises et permet d’analyser les performances des utilisateurs, la répartition de la charge de travail et l’affectation des ressources. Où trouver ces données Les informations sur les utilisateurs se trouvent généralement dans les champs createdBy ou modifiedBy des tables comme LedgerJournalTable, ou dans les journaux d’historique du flux de travail associés. Exemples Alice SmithBob Johnsonsystem.batch
	Statut du journal JournalStatus	Statut actuel ou final de l’écriture comptable.
Description Cet attribut indique l’état de l’écriture comptable à un moment donné, par exemple « Brouillon », « En cours de vérification », « Approuvé », « Rejeté » ou « Comptabilisé ». Il donne un aperçu de l’étape à laquelle se trouve l’écriture dans son cycle de vie. L’analyse du statut permet de mieux comprendre l’issue des cas. Vous pouvez filtrer les journaux rejetés ou suivre le volume de journaux à une étape donnée. Cet attribut apporte le contexte nécessaire à plusieurs Dashboards consacrés au débit et à l’analyse des statuts. Pourquoi est-ce important ? Indique clairement l’issue de chaque écriture comptable et permet d’analyser les taux de réussite et de rejet, ainsi que le volume de travail à chaque étape. Où trouver ces données Le statut figure souvent dans la table d’en-tête du journal, LedgerJournalTable, ou est déduit du statut du flux de travail. Exemples BrouillonSoumisApprouvéComptabiliséRejeté
	Type d’écriture JournalType	Catégorie de l’écriture comptable, par exemple écriture générale ou régularisation.
Description Le type d’écriture classe les écritures selon leur objectif métier, par exemple les écritures quotidiennes, les régularisations, les répartitions ou les éliminations. Cette segmentation est essentielle pour comprendre les différents parcours et comportements du processus. Cet attribut permet de filtrer et de comparer le processus selon les types d’écriture. Il est indispensable au Dashboard « Volume de traitement des écritures comptables par type », qui aide à déterminer si certains types d’écritures sont davantage sujets aux retards, aux rejets ou aux reprises. Pourquoi est-ce important ? Permet de segmenter l’analyse et de comparer les processus selon leurs objectifs métier, qui peuvent impliquer des parcours, des temps de cycle et des exigences d’approbation différents. Où trouver ces données Cette information est généralement stockée dans la table d’en-tête des écritures LedgerJournalTable, dans un champ lié aux noms ou aux types d’écriture, par exemple JournalName. Exemples Journal généralAjustement des charges à payerTransfert intersociétésPaie
	Approuvé dès la première soumission IsFirstTimeRight	Indique si le journal a été approuvé sans rejet préalable.
Description Cet attribut booléen au niveau du cas prend la valeur « vrai » si l’écriture comptable passe de la soumission à l’approbation sans activité intermédiaire « Écriture comptable rejetée » ou « Écriture comptable corrigée ». Il s’agit d’une mesure clé de la qualité du processus. L’indicateur de taux d’approbation dès la première soumission est calculé directement à partir de cet attribut. Un taux élevé indique un processus efficace et de qualité, tandis qu’un taux faible révèle des problèmes systémiques liés à la qualité initiale des données, à la clarté des exigences ou aux procédures de soumission. Pourquoi est-ce important ? Cette mesure essentielle de la qualité du processus indique combien de journaux sont approuvés sans reprise. Où trouver ces données Cet attribut est calculé au niveau du cas en analysant la séquence d’activités associée à chaque ID d’écriture comptable. Exemples truefalse
	Code de devise CurrencyCode	Devise du montant de l’écriture comptable.
Description Cet attribut indique la devise dans laquelle l’écriture comptable est libellée, par exemple USD, EUR ou GBP. Il apporte un contexte essentiel au montant total du journal. La devise n’est pas toujours utilisée pour analyser le flux du processus lui-même, mais elle est indispensable aux rapports et aux analyses financières fondés sur les montants des journaux. Elle permet d’agréger et de comparer correctement les valeurs, en particulier dans les organisations présentes dans plusieurs pays. Pourquoi est-ce important ? Fournit le contexte nécessaire aux analyses financières et garantit une interprétation correcte des montants, notamment dans les environnements multidevises. Où trouver ces données Le code de devise figure généralement dans la table des lignes de journal LedgerJournalTrans. Exemples USDEURGBPJPY
	Comptabilisation automatisée IsAutomatedPosting	Indique si l’écriture comptable a été créée ou comptabilisée automatiquement.
Description Cet attribut booléen distingue les écritures comptables saisies manuellement par un utilisateur de celles générées automatiquement par le système ou un sous-système, par exemple lors d’une intégration système ou d’une répartition automatisée. L’analyse de cet attribut permet de comparer l’efficacité et les taux d’erreur des processus automatisés et manuels. Elle peut révéler des possibilités d’automatisation supplémentaires, en montrant si les écritures manuelles sont davantage sujettes aux erreurs, aux reprises ou aux retards. Pourquoi est-ce important ? Distingue les processus manuels des processus automatisés et permet de comparer leur efficacité, leur exactitude et leur conformité. Où trouver ces données Cette information peut être indiquée par l’utilisateur associé au champ « Créé par » (par exemple, un compte système ou de traitement par lots) ou par un indicateur spécifique dans l’en-tête du journal ou la configuration du type de journal. Exemples truefalse
	Date de comptabilisation PostingDate	Date à laquelle l’écriture comptable est comptabilisée dans le grand livre.
Description La date de comptabilisation est la date officielle à laquelle la transaction modifie les soldes du grand livre. Elle est essentielle aux rapports financiers et à la clôture des périodes. Cet attribut sert à analyser le délai entre l’approbation et la comptabilisation, au cœur de l’indicateur de délai de comptabilisation des écritures. La réduction de ce délai est souvent un objectif important pour accélérer la clôture financière. Cet attribut permet également d’analyser l’évolution des volumes de comptabilisation. Pourquoi est-ce important ? Essentiel au calcul de l’indicateur de délai de comptabilisation et à l’analyse des retards entre l’approbation et l’enregistrement officiel d’une transaction dans le grand livre. Où trouver ces données Cette date est généralement enregistrée dans la table d’en-tête du journal (LedgerJournalTable) ou dans les tables associées aux transactions comptabilisées. Exemples 2023-10-282023-11-012023-10-31
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation des données depuis le système source.
Description Cet attribut indique la date et l’heure de la dernière extraction des données depuis le système source. Il précise le degré d’actualité de l’analyse et des données utilisées. L’affichage de cette information dans les Dashboards confirme aux utilisateurs que les données sont à jour et leur permet de connaître la période couverte par l’analyse du processus. Il s’agit d’une métadonnée essentielle pour tout projet de process mining. Pourquoi est-ce important ? Cet attribut précise l’actualité des données et permet aux utilisateurs de savoir à quelle date remonte l’analyse du processus. Où trouver ces données Cet horodatage est généré et enregistré lors du processus d’extraction, de transformation et de chargement des données (ETL). Exemples 2023-10-27T02:00:00Z
	Niveau d’approbation ApprovalLevel	Indique l’étape actuelle ou terminée d’un processus d’approbation à plusieurs niveaux.
Description Pour les écritures comptables nécessitant plusieurs approbations, cet attribut indique le niveau hiérarchique atteint, par exemple « Approbation du responsable » ou « Approbation du directeur ». Cet attribut permet d’analyser plus précisément les goulots d’étranglement liés aux approbations. Il peut montrer si les retards surviennent régulièrement à un niveau précis de la chaîne d’approbation, ce qui peut indiquer qu’il faut revoir le processus ou réaffecter des ressources à cette étape. Pourquoi est-ce important ? Donne une visibilité sur les circuits d’approbation à plusieurs étapes et aide à repérer les goulots d’étranglement à des niveaux d’approbation précis. Où trouver ces données Cette information est déduite de l’historique du flux de travail, qui indique la fin des différentes étapes d’approbation. Exemples Niveau 1 : responsableNiveau 2 : directeurNiveau 3 : vice-président des finances
	Reprise IsRework	Indique les activités qui font partie d’une boucle de reprise ou de correction.
Description Cet attribut booléen calculé prend la valeur « vrai » pour les activités qui suivent un rejet, comme « Écriture comptable corrigée » ou une nouvelle activité « Écriture comptable soumise pour approbation ». Il permet d’isoler et de quantifier les reprises. Cet attribut est essentiel au Dashboard « Boucles de reprise et de correction des écritures comptables » et à l’indicateur de taux de reprise. En signalant les reprises, il devient facile de visualiser et de mesurer la fréquence et l’incidence des cycles de correction, qui sont une source majeure d’inefficacité dans le processus. Pourquoi est-ce important ? Signale directement les boucles de reprise inefficaces et permet de mesurer facilement l’incidence des rejets et des corrections sur le temps de cycle global et les coûts. Où trouver ces données Cet attribut est calculé lors de la transformation des données, à partir de l’analyse de la séquence d’activités de chaque cas. Exemples truefalse
	Respect du SLA d’approbation ApprovalSlaState	Indique si l’approbation de l’écriture comptable a respecté le niveau de service convenu.
Description Cet attribut classe le cycle d’approbation de chaque écriture comptable selon que celui-ci s’est achevé ou non dans le délai cible défini par un accord de niveau de service (SLA). Les valeurs possibles sont généralement « Respecté » ou « Dépassé ». Il s’agit de la métrique centrale du Dashboard « Respect du SLA d’approbation des écritures comptables ». Elle présente les performances par rapport aux objectifs dans des termes clairs pour l’entreprise, afin de suivre et de gérer les délais d’approbation et d’apporter des améliorations lorsque les SLA ne sont pas respectés. Pourquoi est-ce important ? Traduit les données brutes de temps de cycle en un résultat clair pour l’entreprise (respecté ou dépassé) et facilite le suivi des performances par rapport aux objectifs clés. Où trouver ces données Cet attribut est calculé en comparant l’indicateur de temps de cycle d’approbation au délai cible du SLA défini au préalable. Exemples RespectéDépassé
	Service DepartmentName	Service ou centre de coûts associé à l’écriture comptable.
Description Le service ou le centre de coûts désigne l’unité opérationnelle interne responsable de la transaction financière ou concernée par celle-ci. Il s’agit d’une dimension importante pour le reporting de gestion interne. Cet attribut permet d’analyser le processus de traitement des écritures comptables par service. Il aide à répondre à des questions telles que : quels services soumettent le plus d’écritures ? Certains services ont-ils des taux de rejet plus élevés ou des délais d’approbation plus longs ? Ces informations sont utiles pour cibler les améliorations du processus. Pourquoi est-ce important ? Permet d’analyser les performances des processus par fonction métier et de repérer les goulots d’étranglement ou les besoins de formation propres à chaque service. Où trouver ces données Cette information se trouve généralement au niveau des lignes du journal (LedgerJournalTrans), sous la forme d’une dimension financière. Exemples VentesFinanceMarketingOpérations
	Système source SourceSystem	Système de référence depuis lequel les données ont été extraites.
Description Cet attribut identifie l’application source des données d’écritures comptables. Pour ce processus, sa valeur est généralement constante, par exemple « Microsoft Dynamics 365 ». Dans une analyse plus large, notamment lorsque plusieurs ERP ou systèmes intégrés sont utilisés, ce champ permet de distinguer les processus et les sources de données. Il précise la provenance des données et contribue à leur gouvernance et à leur validation. Pourquoi est-ce important ? Cet attribut indique l’origine des données. Il est essentiel à leur gouvernance et aux analyses qui couvrent plusieurs systèmes d’entreprise. Où trouver ces données Cette valeur statique est ajoutée lors du processus d’extraction, de transformation et de chargement des données (ETL) afin d’indiquer l’origine du jeu de données. Exemples Microsoft Dynamics 365D365 F&O

Obligatoire Recommandé Facultatif

Activités du processus de comptabilisation des écritures, de l’enregistrement au reporting

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

5 Recommandé 7 Facultatif

	Activité	Description
	Écriture approuvée	L’autorité désignée a approuvé l’écriture comptable, ce qui marque la dernière étape du flux de travail d’approbation. L’événement est généralement enregistré lorsque le statut de l’en-tête passe à « Approuvé ».
Pourquoi est-ce important ? Cette étape essentielle clôt le processus d’approbation et permet la comptabilisation. Elle est indispensable au calcul du temps de cycle d’approbation, du délai de comptabilisation et du taux de traitement correct dès la première fois. Où trouver ces données L’événement est déduit d’un changement de champ de statut, par exemple lorsque ApprovalStatus passe à ’Approved’ dans LedgerJournalTable, ou de la table d’historique du flux de travail indiquant l’approbation finale. Données à recueillir Repérez l’horodatage auquel le statut de l’écriture passe à « Approuvé ». Type d’événement inferred
	Écriture comptable comptabilisée	Cette activité marque la comptabilisation réussie de l’écriture dans le grand livre, où elle devient un enregistrement financier officiel. Cet événement essentiel est enregistré lorsque le statut de l’en-tête passe à « Comptabilisé ».
Pourquoi est-ce important ? Il s’agit de l’événement de fin qui marque la réussite du processus. Il sert à calculer le temps de cycle de bout en bout et le délai de comptabilisation, deux indicateurs clés de l’efficacité de la clôture financière. Où trouver ces données L’événement est enregistré à partir d’un changement de champ de statut, par exemple lorsque JournalStatus passe à ’Posted’ dans LedgerJournalTable, ainsi que de la création des écritures correspondantes dans la table GeneralJournalAccountEntry. Données à recueillir Repérez l’horodatage auquel le statut de l’écriture passe à « Comptabilisé ». Type d’événement inferred
	Écriture comptable créée	Cette activité marque le début d’une nouvelle écriture comptable. Elle est enregistrée lorsqu’un utilisateur crée un nouvel en-tête d’écriture dans le système. Un identifiant unique est alors attribué à l’écriture et sert d’identifiant de cas pour l’analyse du processus.
Pourquoi est-ce important ? Il s’agit de l’événement de début principal du processus. Mesurer le délai entre ce point et la comptabilisation est essentiel pour calculer le temps de cycle de bout en bout et repérer les retards initiaux de saisie des données. Où trouver ces données Cet événement est enregistré à partir de l’horodatage de création de l’en-tête d’écriture dans l’entité GeneralJournalEntry ou LedgerJournalTable. Il correspond généralement à la création explicite d’un enregistrement. Données à recueillir Utilisez le champ ’createdDateTime’ de GeneralJournalEntry ou LedgerJournalTable. Type d’événement explicit
	Écriture rejetée	Un réviseur ou un approbateur a rejeté l’écriture comptable, qui doit être corrigée. L’événement est enregistré à partir d’un changement de statut de l’écriture, par exemple lorsqu’elle passe à « Rejeté » ou « À corriger ».
Pourquoi est-ce important ? Le suivi des rejets est essentiel pour calculer leur taux et repérer les causes profondes des reprises. Il met en évidence les problèmes de qualité des données, de conformité ou de formation des utilisateurs. Où trouver ces données L’événement est déduit d’un changement de champ de statut, par exemple lorsque ApprovalStatus passe à ’Rejected’ dans LedgerJournalTable, ou du journal d’historique du flux de travail. Données à recueillir Repérez l’horodatage auquel le statut de l’écriture passe à « Rejeté ». Type d’événement inferred
	Écriture soumise pour approbation	Cet événement correspond à la soumission officielle d’une écriture comptable terminée pour examen et approbation. Il est généralement déduit d’un changement de statut de l’en-tête, par exemple de « Brouillon » à « En cours de vérification » ou « Soumis ».
Pourquoi est-ce important ? Cette étape clé marque le début du cycle d’approbation. Mesurer le délai entre la soumission et l’approbation finale est essentiel pour repérer les goulots d’étranglement lors de la vérification et suivre le respect des SLA. Où trouver ces données L’événement est déduit d’un changement de champ de statut, par exemple lorsque ApprovalStatus passe à ’InReview’ dans LedgerJournalTable, ou des journaux d’historique du flux de travail associés à l’écriture. Données à recueillir Repérez l’horodatage auquel le statut de l’écriture passe à « Soumis » ou « En cours de vérification ». Type d’événement inferred
	Annulation de l’écriture comptable lancée	Cet événement marque le début du processus d’annulation d’une écriture comptable déjà comptabilisée. Il est enregistré lorsqu’un utilisateur lance l’action d’annulation dans le système.
Pourquoi est-ce important ? Le suivi des annulations permet de repérer leur fréquence et les raisons qui conduisent à corriger des écritures comptabilisées. Il peut révéler des problèmes sous-jacents lors de la saisie initiale ou des étapes d’approbation. Où trouver ces données Il s’agit généralement d’une action explicite de l’utilisateur, qui peut être enregistrée dans les pistes d’audit ou repérée par la création d’une nouvelle écriture d’annulation liée à l’écriture d’origine. Données à recueillir Utilisez l’événement de création d’une nouvelle écriture comptable indiquée comme annulation d’une écriture comptabilisée. Type d’événement explicit
	Écriture comptable annulée	Cet événement marque la fin du processus d’annulation de l’écriture comptable, lorsque l’écriture d’annulation est comptabilisée. Il constitue un autre point de fin possible dans le cycle de vie d’une écriture incorrecte.
Pourquoi est-ce important ? Cette activité clôt le traitement des écritures corrigées et permet d’analyser le temps total consacré aux ajustements après comptabilisation, qui influent sur l’efficacité globale du processus. Où trouver ces données L’événement est enregistré lorsque la nouvelle écriture d’annulation passe elle-même au statut « Comptabilisé ». Un champ de référence conserve le lien avec l’écriture d’origine. Données à recueillir Repérez l’événement de statut « Comptabilisé » pour l’écriture d’annulation associée. Type d’événement inferred
	Écriture comptable corrigée	Cette activité indique qu’un utilisateur a modifié une écriture comptable précédemment rejetée. Elle est généralement déduite d’une modification de l’en-tête ou des lignes de l’écriture après l’enregistrement d’un statut « Rejeté ».
Pourquoi est-ce important ? Cette activité permet de repérer les reprises. L’analyse de la fréquence et de la durée des boucles de correction aide à simplifier le processus et à réduire les tâches manuelles. Où trouver ces données L’événement est déduit du suivi des champs ’modifiedDateTime’ et ’modifiedBy’ dans les tables LedgerJournalTable ou LedgerJournalTrans après un événement « Écriture rejetée ». Données à recueillir Comparez l’horodatage du statut « Rejeté » aux horodatages des modifications ultérieures effectuées par le créateur. Type d’événement inferred
	Écriture soumise à nouveau pour approbation	Une écriture comptable corrigée est renvoyée dans le flux de travail d’approbation pour un nouveau cycle de vérification. L’événement est déduit d’un changement de statut de « Rejeté » ou « Brouillon » à « En cours de vérification » ou « Soumis ».
Pourquoi est-ce important ? Cette activité marque le début d’une boucle de reprise. Le décompte de ces événements permet de mesurer le taux de reprise et le nombre moyen de cycles d’approbation par écriture comptable. Où trouver ces données L’événement est déduit de l’historique du flux de travail ou du suivi des changements de statut dans LedgerJournalTable, lorsque le statut passe de rejeté à soumis. Données à recueillir Repérez un événement de statut « Soumis » survenant après un événement de statut « Rejeté » pour la même écriture. Type d’événement inferred
	Ligne d’écriture ajoutée	Cet événement indique qu’une ligne de débit ou de crédit a été ajoutée à l’écriture comptable. Il est enregistré chaque fois qu’une nouvelle ligne de transaction est créée et associée à l’en-tête de l’écriture.
Pourquoi est-ce important ? Le suivi de la création des lignes permet de comprendre la complexité et le travail de saisie requis selon le type d’écriture. Il peut aussi révéler les retards entre la création de l’en-tête et la saisie complète des lignes. Où trouver ces données L’événement est enregistré à partir de l’horodatage de création des enregistrements dans l’entité LedgerJournalTrans, reliés à l’en-tête de l’écriture. Chaque création de ligne constitue un événement distinct. Données à recueillir Utilisez le champ ’createdDateTime’ de chaque enregistrement de la table LedgerJournalTrans. Type d’événement explicit
	Tentative de comptabilisation de l’écriture	Cette activité indique qu’un utilisateur a lancé la comptabilisation d’une écriture approuvée. Elle peut être enregistrée explicitement si le système consigne le démarrage du traitement de comptabilisation.
Pourquoi est-ce important ? Distinguer la tentative de comptabilisation de la comptabilisation réussie permet de diagnostiquer les problèmes de performances du système ou les retards des traitements par lots qui affectent la clôture financière. Où trouver ces données Il peut s’agir d’un événement explicitement enregistré dans une table d’historique des traitements par lots, ou déduit du passage du statut de LedgerJournalTable à « Comptabilisation en cours ». Données à recueillir Il faut analyser les journaux des traitements par lots ou du système associés au traitement de comptabilisation du grand livre. Type d’événement explicit
	Vérification de l’écriture commencée	Cette activité indique le moment où un réviseur commence à examiner une écriture soumise. Elle peut être déduite de l’affectation de l’écriture à un réviseur ou de la première ouverture de l’enregistrement par celui-ci.
Pourquoi est-ce important ? Cette activité permet de mesurer le délai de prise en charge par le réviseur, c’est-à-dire le temps entre la soumission et le début de la vérification. Elle peut révéler des problèmes d’affectation des ressources ou de notification. Où trouver ces données Cet événement n’est souvent pas enregistré explicitement. Il peut être déduit des journaux d’affectation du flux de travail ou en comparant l’horodatage de soumission au premier horodatage de modification par un réviseur. Données à recueillir Il faut analyser les journaux d’affectation des utilisateurs du flux de travail ou les journaux d’activité des utilisateurs, qui ne sont pas toujours disponibles par défaut. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

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

Étapes

Accédez à l’espace de travail de gestion des données : Connectez-vous à votre environnement Microsoft Dynamics 365. Utilisez la barre de recherche principale pour trouver l’espace de travail « Data management » et y accéder.
Créez un projet d’exportation : Dans l’espace de travail de gestion des données, sélectionnez la vignette « Export » pour créer un projet d’exportation. Donnez-lui un nom explicite, par exemple « ProcessMind_JournalEntry_Export ».
Choisissez le format des données : Dans les détails du projet, indiquez le format cible. Pour faciliter les transformations ultérieures, choisissez « CSV » ou « Excel ».
Ajoutez les entités de données requises : Cette étape est essentielle. Ajoutez au projet plusieurs entités afin de recueillir toutes les activités et tous les attributs nécessaires. Pour chaque entité, cliquez sur « Add entity » et recherchez les noms suivants. Il est recommandé de les ajouter une par une.
- Ledger journal headers : consigne les événements de création, de comptabilisation et d’extourne.
- Ledger journal lines : consigne l’ajout de chaque ligne de débit ou de crédit.
- Workflow tracking status table : consigne les événements du flux de travail, notamment la soumission, l’approbation et le rejet.
Configurez les filtres des entités : Pour chaque entité ajoutée, sélectionnez l’option « Filter ». Appliquez des filtres pour limiter le périmètre de l’exportation. Au minimum, filtrez par « Legal entity » (société) et définissez une période sur un champ de date pertinent, comme CREATEDDATETIME dans Ledger journal headers, afin de maîtriser le volume de données. Par exemple, exportez les données des trois à six derniers mois.
Associez les champs des entités : Vérifiez l’association des champs pour chaque entité. Assurez-vous que le fichier exporté contient tous les champs nécessaires aux attributs finaux. Par défaut, le système inclut généralement tous les champs.
Lancez l’exportation : Une fois le projet configuré, cliquez sur « Export » dans le volet Action. Le système crée un package de données contenant un fichier distinct pour chaque entité.
Téléchargez les données exportées : Une fois l’exportation terminée, consultez l’historique des tâches et téléchargez le package généré au format ZIP.
Transformez les données en journal d’événements : Cette étape doit être effectuée en dehors de Dynamics 365, à l’aide d’un script (par exemple en Python ou PowerShell) ou d’un outil de préparation des données. Il s’agit de combiner et de transformer les données des différents fichiers exportés afin de créer un seul fichier CSV de journal d’événements. Pour chaque fichier source, créez des lignes correspondant à des activités précises. Par exemple :
- À partir du fichier Ledger journal headers, créez des événements « Journal Entry Created » à l’aide de l’horodatage de création et des événements « Journal Entry Posted » à l’aide de celui de comptabilisation.
- À partir du fichier Ledger journal lines, créez des événements « Journal Line Added ».
- À partir du fichier Workflow tracking status table, associez les données aux en-têtes et créez des événements « Journal Submitted For Approval », « Journal Approved » et « Journal Rejected » selon le statut du flux de travail et les horodatages.
- Déduisez les événements tels que « Journal Entry Corrected » en repérant un horodatage de modification postérieur à un événement « Journal Rejected ».
Structurez le fichier CSV final : Vérifiez que le fichier transformé contient les colonnes requises : JournalEntryId, ActivityName et EventTime, ainsi que les attributs recommandés. Triez les lignes par JournalEntryId, puis par EventTime.
Importez le fichier dans ProcessMind : Le journal d’événements CSV final, qui ne contient qu’un seul fichier, est prêt à être importé dans la plateforme ProcessMind pour analyse.

Configuration

Entités de données : La configuration repose avant tout sur le choix des bonnes entités. Les principales sont Ledger journal headers, Ledger journal lines et Workflow tracking status table. Selon la configuration de votre flux de travail, d’autres entités peuvent être nécessaires.
Format d’exportation : Le format CSV est recommandé. Universel, il est facilement traité par les langages de script et les outils de données utilisés pour les transformations requises.
Filtres : Il est essentiel de filtrer par entité juridique (société) pour éviter d’exporter des données d’unités opérationnelles non pertinentes. Un filtre de période, par exemple sur CREATEDDATETIME, est également indispensable pour maîtriser les performances et la taille des fichiers. Pour une première analyse, une période de trois à six mois est généralement adaptée.
Exportations incrémentielles : Pour assurer un suivi régulier, configurez le projet afin qu’il effectue des exportations incrémentielles. Seuls les enregistrements modifiés depuis la dernière exécution seront alors extraits, ce qui est bien plus efficace qu’une exportation complète à chaque fois.
Autorisations : Le compte utilisateur qui configure et exécute l’exportation doit disposer du rôle « Data management administrator » ou d’autorisations équivalentes pour accéder à l’espace de travail de gestion des données et aux entités sous-jacentes.

Exemple de requête sql

/*
This is not a single executable query. Instead, it defines the configuration of a Data Management Framework export project. The following entities and fields must be selected and then combined using an external script to build the final event log.
*/

-- Configuration for Entity 1: Ledger journal headers
-- Purpose: Extracts core journal header data for Created, Posted, and Reversal events.
-- Source Entity: Ledger journal headers
-- Key Fields to Map:
--   JournalBatchNumber -> JournalEntryId
--   CREATEDDATETIME -> EventTime (for 'Journal Entry Created')
--   CREATEDBY -> UserName (for 'Journal Entry Created')
--   LedgerJournalWFApprovalStatus -> JournalStatus (for workflow context)
--   JournalType -> JournalType
--   company -> LegalEntity
--   PostedDateTime -> EventTime (for 'Journal Entry Posted')
--   PostedBy -> UserName (for 'Journal Entry Posted')
--   ReverseDate -> EventTime (for 'Journal Entry Reversal Initiated')
--   MODIFIEDDATETIME -> Used to infer 'Journal Entry Corrected'
--   MODIFIEDBY -> UserName

-- Configuration for Entity 2: Ledger journal lines
-- Purpose: Extracts individual transaction lines to create 'Journal Line Added' events.
-- Source Entity: Ledger journal lines
-- Key Fields to Map:
--   JournalBatchNumber -> JournalEntryId
--   CREATEDDATETIME -> EventTime (for 'Journal Line Added')
--   CREATEDBY -> UserName (for 'Journal Line Added')
--   AmountInTransactionCurrency -> JournalTotalAmount (Note: Must be aggregated per JournalEntryId)
--   company -> LegalEntity

-- Configuration for Entity 3: Workflow tracking status table
-- Purpose: Extracts detailed workflow history for approval and rejection events.
-- Source Entity: Workflow tracking status table
-- Key Fields to Map:
--   ContextRecId -> (This needs to be joined back to the RecId of the LedgerJournalTable to get the JournalBatchNumber)
--   ContextTableId -> (Used to filter for Journal related workflows)
--   CREATEDDATETIME -> EventTime
--   User -> UserName
--   TrackingStatus -> Used to derive ActivityName ('Submitted For Approval', 'Journal Approved', 'Journal Rejected')
--   Comment -> RejectionReason

-- **Post-Processing Transformation Logic (to be implemented in an external script)**

-- 1. For each row in 'Ledger journal headers' export:
--    - Create one row with ActivityName = 'Journal Entry Created', EventTime = CREATEDDATETIME.
--    - If PostedDateTime is not null, create one row with ActivityName = 'Journal Entry Posted', EventTime = PostedDateTime.
--    - If ReverseDate is not null, create one row with ActivityName = 'Journal Entry Reversal Initiated', EventTime = ReverseDate. (A separate 'Journal Entry Reversed' event may need to be derived from the creation of the reversing journal).

-- 2. For each row in 'Ledger journal lines' export:
--    - Create one row with ActivityName = 'Journal Line Added', EventTime = CREATEDDATETIME.

-- 3. For each row in 'Workflow tracking status table' export (after joining to get JournalBatchNumber):
--    - IF TrackingStatus indicates submission, create ActivityName = 'Journal Submitted For Approval'.
--    - IF TrackingStatus indicates approval, create ActivityName = 'Journal Approved'.
--    - IF TrackingStatus indicates rejection, create ActivityName = 'Journal Rejected'.
--    - Other activities like 'Journal Review Started', 'Journal Entry Corrected', 'Journal Resubmitted For Approval', and 'Journal Posting Attempted' are often not explicitly logged. They must be inferred from status changes, user actions within a timeframe, or modification timestamps on the journal header after a rejection event.

Étapes

Configurez l’exportation de D365 vers Azure Data Lake : Avant d’exécuter des requêtes, vérifiez que la fonctionnalité native « Export to Azure Data Lake » de Microsoft Dynamics 365 est configurée et active. Sélectionnez les entités nécessaires au processus de comptabilisation des écritures, au minimum : LedgerJournalTable, LedgerJournalTrans, GeneralJournalEntry, GeneralJournalAccountEntry et WorkflowTrackingStatusTable. Laissez le temps à la synchronisation initiale des données de s’effectuer.
Accédez à Azure Synapse Analytics : Ouvrez le portail Azure et accédez à l’espace de travail Synapse Analytics connecté au compte Azure Data Lake Storage qui contient vos données Dynamics 365.
Accédez à la base de données SQL : Dans Synapse Studio, ouvrez le hub « Data ». Repérez la base de données SQL serverless créée à partir des fichiers de votre lac de données. Les entités D365 y sont accessibles sous forme de tables ou de vues interrogeables.
Créez un script SQL : Ouvrez le hub « Develop » et créez un nouveau script SQL vierge. Vous y construirez la requête du journal d’événements.
Copiez et adaptez la requête : Copiez la requête SQL complète fournie dans la section « query » de ce document dans le nouvel éditeur de scripts de Synapse Studio.
Remplacez les valeurs de substitution : Examinez attentivement la requête et remplacez toutes les valeurs de substitution. Mettez à jour le nom de la base de données et du schéma, par exemple [YourD365DB].[dbo], puis définissez les paramètres StartDate et EndDate pour la période à analyser.
Exécutez la requête : Lancez le script avec le pool SQL serverless. La durée d’exécution dépendra de la période choisie et du volume de données dans votre système.
Vérifiez les résultats : Une fois la requête terminée, le volet des résultats affiche le journal d’événements généré. Vérifiez rapidement que les colonnes (JournalEntryId, ActivityName, EventTime, etc.) et les données sont correctes.
Exportez le journal d’événements : Utilisez la fonction d’exportation de votre outil de requête ou de Synapse Studio pour enregistrer les résultats au format CSV. Faites un clic droit sur les résultats et choisissez une option telle que « Save as CSV ».
Préparez l’importation : Vérifiez que le fichier CSV exporté est encodé en UTF-8 et que ses en-têtes de colonnes respectent les exigences de ProcessMind. Aucune autre transformation des données ne devrait être nécessaire.

Configuration

Prérequis : Cette méthode nécessite une intégration opérationnelle entre Microsoft Dynamics 365 Finance et un compte Azure Data Lake Storage Gen2. Vous devez également disposer d’un espace de travail Azure Synapse Analytics configuré pour interroger ces données. Les utilisateurs doivent avoir les autorisations de lecture appropriées dans Azure Synapse et dans le lac de données.
Entités de données : Vérifiez que les entités D365 suivantes sont incluses dans l’exportation vers le lac de données : LedgerJournalTable, LedgerJournalTrans, WorkflowTrackingStatusTable, GeneralJournalEntry et UserInfo.
Filtrage par période : La requête fournie comprend les paramètres @StartDate et @EndDate. Pour maîtriser les performances et les coûts des requêtes, il est fortement recommandé de commencer par une période limitée, par exemple de trois à six mois. Choisissez une période représentative de l’activité de l’entreprise.
Filtrage par entité juridique : La requête doit être filtrée à l’aide de DataAreaId (entité juridique) afin de limiter l’analyse à une société donnée. Dans les environnements D365 de grande taille, ce filtre est essentiel pour les performances. Remplacez la valeur de substitution [YourLegalEntity].
Configuration du flux de travail : La logique de la requête pour les événements d’approbation et de rejet suppose l’utilisation du moteur de flux de travail standard de D365, qui consigne les données dans WorkflowTrackingStatusTable. Si votre organisation utilise un autre mécanisme d’approbation ou une configuration personnalisée, la requête devra être adaptée.

Exemple de requête sql

DECLARE @StartDate DATETIME = '2023-01-01';
DECLARE @EndDate DATETIME = '2023-12-31';

WITH JournalHeaders AS (
    SELECT 
        JOURNALBATCHNUMBER AS JournalEntryId,
        JOURNALTYPE AS JournalType,
        DOCUMENTSTATUS AS JournalStatus, -- Captures Posted, etc.
        APPROVALSTATUS AS ApprovalStatus, -- Captures Draft, InReview, Approved, Rejected
        LOG AS RejectionReason, -- Often contains rejection comments
        POSTEDDATETIME, 
        CREATEDDATETIME,
        CREATEDBY,
        MODIFIEDDATETIME,
        MODIFIEDBY,
        DATA indignationId
    FROM 
        [YourD365DB].[dbo].LedgerJournalTable
    WHERE 
        CREATEDDATETIME BETWEEN @StartDate AND @EndDate
        AND DATA indignationId = '[YourLegalEntity]'
),
WorkflowEvents AS (
    SELECT 
        wtst.CONTEXTRECID,
        wtst.CONTEXTTABLEID,
        wtst.USERID,
        wtst.CREATEDDATETIME,
        wtst.TRACKINGSTATUS, -- Submitted, Approved, Rejected
        wtsi.INSTANCENUMBER
    FROM 
        [YourD365DB].[dbo].WorkflowTrackingStatusTable wtst
    JOIN 
        [YourD365DB].[dbo].WorkflowTrackingTable wtsi ON wtst.WORKFLOWTRACKINGTABLEINSTANCENUMBER = wtsi.RECID
    WHERE 
        wtst.CONTEXTTABLEID = (SELECT TABLEID FROM [YourD365DB].[dbo].SysTableIdTable WHERE NAME = 'LedgerJournalTable')
)

-- 1. Journal Entry Created
SELECT 
    jh.JournalEntryId AS JournalEntryId,
    'Journal Entry Created' AS ActivityName,
    jh.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    CAST(jh.ApprovalStatus AS VARCHAR) AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    (SELECT SUM(ABS(jlt.AMOUNTCREDIT)) FROM [YourD365DB].[dbo].LedgerJournalTrans jlt WHERE jlt.JOURNALBATCHNUMBER = jh.JournalEntryId) AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.CREATEDBY = u.ID

UNION ALL

-- 2. Journal Line Added
SELECT 
    jlt.JOURNALBATCHNUMBER AS JournalEntryId,
    'Journal Line Added' AS ActivityName,
    jlt.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    CAST(jh.ApprovalStatus AS VARCHAR) AS JournalStatus,
    NULL AS RejectionReason,
    jlt.DATA indignationId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    [YourD365DB].[dbo].LedgerJournalTrans jlt
JOIN 
    JournalHeaders jh ON jlt.JOURNALBATCHNUMBER = jh.JournalEntryId AND jlt.DATA indignationId = jh.DataAreaId
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jlt.CREATEDBY = u.ID

UNION ALL

-- 3. Journal Submitted For Approval
SELECT 
    jh.JournalEntryId,
    'Journal Submitted For Approval' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'InReview' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 1 -- Submitted

UNION ALL

-- 4. Journal Review Started (Approximation)
SELECT 
    jh.JournalEntryId,
    'Journal Review Started' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'InReview' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGTYPE = 5 -- Work item creation

UNION ALL

-- 5. Journal Approved
SELECT 
    jh.JournalEntryId,
    'Journal Approved' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Approved' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 5 -- Completion

UNION ALL

-- 6. Journal Rejected
SELECT 
    jh.JournalEntryId,
    'Journal Rejected' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Rejected' AS JournalStatus,
    jh.RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 3 -- Rejection

UNION ALL

-- 7. Journal Entry Corrected (Approximation)
SELECT 
    jh.JournalEntryId,
    'Journal Entry Corrected' AS ActivityName,
    jh.MODIFIEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Corrected' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.MODIFIEDBY = u.ID
WHERE 
    jh.MODIFIEDDATETIME > jh.CREATEDDATETIME AND
    EXISTS (
        SELECT 1 FROM WorkflowEvents we 
        WHERE we.CONTEXTRECID = jh.RecId AND we.TRACKINGSTATUS = 3 -- Rejection
        AND jh.MODIFIEDDATETIME > we.CREATEDDATETIME
    )

UNION ALL

-- 8. Journal Resubmitted For Approval
SELECT 
    jh.JournalEntryId,
    'Journal Resubmitted For Approval' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'InReview' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 1 -- Submitted
    AND EXISTS (
        SELECT 1 FROM WorkflowEvents rej_we 
        WHERE rej_we.CONTEXTRECID = jh.RecId AND rej_we.TRACKINGSTATUS = 3 -- Rejection
        AND we.CREATEDDATETIME > rej_we.CREATEDDATETIME
    )

UNION ALL

-- 9. Journal Posting Attempted (Approximation)
SELECT 
    jh.JournalEntryId,
    'Journal Posting Attempted' AS ActivityName,
    DATEADD(second, -5, jh.POSTEDDATETIME) AS EventTime, -- Approximated as just before posting
    jh.POSTEDDATETIME AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Posting' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.MODIFIEDBY = u.ID -- Often posted by the last modifier or a system account
WHERE 
    jh.POSTEDDATETIME IS NOT NULL

UNION ALL

-- 10. Journal Entry Posted
SELECT 
    jh.JournalEntryId,
    'Journal Entry Posted' AS ActivityName,
    jh.POSTEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Posted' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.MODIFIEDBY = u.ID
WHERE 
    jh.POSTEDDATETIME IS NOT NULL

UNION ALL

-- 11. Journal Entry Reversal Initiated
SELECT 
    gje.JOURNALNUMBER AS JournalEntryId,
    'Journal Entry Reversal Initiated' AS ActivityName,
    gje_rev.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Reversing' AS JournalStatus,
    NULL AS RejectionReason,
    gje.LEDGER AS LegalEntity,
    NULL AS JournalTotalAmount
FROM
    [YourD365DB].[dbo].GeneralJournalEntry gje
JOIN
    [YourD365DB].[dbo].GeneralJournalEntry gje_rev ON gje.JOURNALNUMBER = gje_rev.OriginalJournalNumber
JOIN
    JournalHeaders jh ON gje.JOURNALNUMBER = jh.JournalEntryId
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON gje_rev.CREATEDBY = u.ID
WHERE
    gje.REVERSED = 'Yes'

UNION ALL

-- 12. Journal Entry Reversed
SELECT 
    gje.JOURNALNUMBER AS JournalEntryId,
    'Journal Entry Reversed' AS ActivityName,
    gje.REVERSEDDATE AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Reversed' AS JournalStatus,
    NULL AS RejectionReason,
    gje.LEDGER AS LegalEntity,
    NULL AS JournalTotalAmount
FROM
    [YourD365DB].[dbo].GeneralJournalEntry gje
JOIN
    JournalHeaders jh ON gje.JOURNALNUMBER = jh.JournalEntryId
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON gje.MODIFIEDBY = u.ID
WHERE
    gje.REVERSED = 'Yes' AND gje.REVERSEDDATE IS NOT NULL;

Étapes

Prérequis et configuration de l’environnement : Installez Python 3.x sur votre machine. Installez les bibliothèques Python nécessaires avec pip : pip install pandas requests adal. La bibliothèque adal sert à l’authentification auprès d’Azure Active Directory, requise pour Dynamics 365.
Inscrivez une application dans Azure AD : Pour accéder à l’API Dynamics 365, inscrivez une application dans votre Azure Active Directory. Notez l’ID d’application (client) et l’ID de répertoire (locataire), puis créez un secret client. Accordez à cette application des autorisations déléguées pour accéder à Dynamics 365 Finance & Operations, par exemple Financials.Read.
Configurez le script Python : Copiez le script Python fourni dans un fichier, par exemple extract_journals.py. Remplacez les variables de substitution en haut du script par vos informations Azure AD et Dynamics 365 : TENANT_ID, CLIENT_ID, CLIENT_SECRET et D365_URL.
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 des données. Vous pouvez également personnaliser la liste LEGAL_ENTITIES afin de filtrer certaines sociétés.
Exécutez le script d’extraction : Lancez le script depuis la ligne de commande avec python extract_journals.py. Le script s’authentifie auprès d’Azure AD, récupère un jeton d’accès, puis interroge l’API OData de Dynamics 365 pour obtenir les données des en-têtes et des lignes d’écritures comptables correspondant à la période définie.
Suivez l’exécution du script : Le script affiche des messages de progression dans la console à mesure qu’il récupère les pages de données de l’API. Selon le volume de données, l’opération peut prendre un certain temps. La pagination de l’API est gérée automatiquement afin de récupérer tous les enregistrements pertinents.
Vérifiez les données brutes (facultatif) : Le script enregistre d’abord les données brutes interrogées dans raw_journal_headers.csv et raw_journal_lines.csv. Vous pouvez examiner ces fichiers pour vérifier que l’extraction initiale a réussi avant l’application des transformations.
Comprenez la déduction des événements : Le script traite les données brutes pour déduire les 12 activités requises. Par exemple, l’événement « Journal Submitted For Approval » est déduit lorsque le champ WorkflowApprovalStatus passe de « Draft » à « Submitted ». L’horodatage de l’événement provient du champ ModifiedDateTime de l’enregistrement.
Générez le journal d’événements final : Après le traitement, le script regroupe tous les événements déduits dans un journal d’événements structuré. Il crée les colonnes requises : JournalEntryId, ActivityName, EventTime ainsi que les autres attributs recommandés.
Exportez et vérifiez le fichier CSV : Le journal d’événements final est enregistré sous le nom journal_entry_event_log.csv. Ouvrez ce fichier pour en vérifier la structure et le contenu. Assurez-vous qu’il contient les colonnes attendues et que les données des différentes activités ont bien été générées.
Préparez l’importation dans ProcessMind : Le fichier CSV généré est prêt à être importé. Vérifiez qu’il est enregistré en UTF-8. Vous pouvez maintenant l’utiliser comme source de données dans ProcessMind pour analyser votre processus de comptabilisation des écritures, de l’enregistrement au reporting.

Configuration

URL du point de terminaison de l’API : URL de base de l’API OData de Dynamics 365 Finance & Operations. Elle doit être définie dans la variable D365_URL du script, par exemple https://your-org.operations.dynamics.com.
Identifiants Azure AD : Le script nécessite l’inscription d’une application dans Azure AD. Vous devez fournir TENANT_ID, CLIENT_ID et CLIENT_SECRET pour l’authentification.
Autorisations API requises : L’application Azure AD doit disposer d’autorisations déléguées pour lire les données de Dynamics 365. L’autorisation Financials.Read suffit généralement pour accéder aux données des écritures comptables.
Période : Les variables START_DATE et END_DATE du script définissent la période d’extraction. Pour une première analyse, une période de trois à six mois est recommandée afin de trouver un équilibre entre le volume de données et les informations sur le processus.
Filtre d’entité juridique : La liste LEGAL_ENTITIES du script vous permet de préciser les codes société (dataAreaId) à inclure dans l’extraction. Ce filtre est essentiel pour limiter l’analyse aux parties pertinentes de l’activité.
Entités de données : Le script interroge principalement les entités OData LedgerJournalHeaders et LedgerJournalLines, qui sont les entités standard pour les données d’écritures comptables dans Dynamics 365.
Association du champ de statut : La logique de déduction des activités du script repose sur le champ standard WorkflowApprovalStatus. Si votre implémentation utilise un champ personnalisé pour suivre le statut des écritures, vous devrez modifier le nom du champ dans le script.

Exemple de requête python

import adal
import requests
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration --- 
class=class="hl-string">"hl-comment"># Azure AD Application Details
TENANT_ID = class="hl-string">'[Your Tenant ID]'
CLIENT_ID = class="hl-string">'[Your Application Client ID]'
CLIENT_SECRET = class="hl-string">'[Your Client Secret]'

class=class="hl-string">"hl-comment"># Dynamics 365 F&O Environment Details
D365_URL = class="hl-string">'https://[your-d365-url].operations.dynamics.com'
RESOURCE = D365_URL
AUTHORITY_URL = fclass="hl-string">'https://login.microsoftonline.com/{TENANT_ID}'

class=class="hl-string">"hl-comment"># Extraction Parameters
START_DATE = class="hl-string">'2023-01-01T00:00:00Z'
END_DATE = class="hl-string">'2023-12-31T23:59:59Z'
LEGAL_ENTITIES = [class="hl-string">'[YourLegalEntity1]', class="hl-string">'[YourLegalEntity2]'] class=class="hl-string">"hl-comment"># e.g., [class="hl-string">'USMF']

class=class="hl-string">"hl-comment"># --- OData Helper Functions ---

def get_access_token():
    class="hl-string">"""Authenticates with Azure AD to get an access token."""
    context = adal.AuthenticationContext(AUTHORITY_URL)
    token = context.acquire_token_with_client_credentials(RESOURCE, CLIENT_ID, CLIENT_SECRET)
    if class="hl-string">'accessToken' not in token:
        raise Exception(fclass="hl-string">"Failed to get access token: {token.get('error_description')}")
    return token[class="hl-string">'accessToken']

def execute_odata_query(entity_url, headers):
    class="hl-string">"""Executes a paginated OData query and returns a list of records."""
    all_records = []
    next_link = entity_url
    page_num = 1
    while next_link:
        print(fclass="hl-string">"Fetching page {page_num} for entity: {entity_url.split('/')[-1].split('?')[0]}...")
        response = requests.get(next_link, headers=headers)
        if response.status_code != 200:
            raise Exception(fclass="hl-string">"Query failed with status {response.status_code}: {response.text}")
        data = response.json()
        all_records.extend(data[class="hl-string">'value'])
        next_link = data.get(class="hl-string">'@odata.nextLink')
        page_num += 1
    return all_records

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

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Journal Entry data extraction...")
    
    class=class="hl-string">"hl-comment"># 1. Get Access Token
    access_token = get_access_token()
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Accept': class="hl-string">'application/json'
    }

    class=class="hl-string">"hl-comment"># 2. Build and Execute Queries
    legal_entity_filter = class="hl-string">" or ".join([fclass="hl-string">"dataAreaId eq '{le}'" for le in LEGAL_ENTITIES])
    date_filter = fclass="hl-string">"CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}"

    class=class="hl-string">"hl-comment"># Query LedgerJournalHeaders
    headers_fields = [
        class="hl-string">'JournalBatchNumber', class="hl-string">'dataAreaId', class="hl-string">'LedgerJournalType', class="hl-string">'WorkflowApprovalStatus',
        class="hl-string">'CreatedBy', class="hl-string">'CreatedDateTime', class="hl-string">'ModifiedBy', class="hl-string">'ModifiedDateTime', class="hl-string">'PostedDateTime',
        class="hl-string">'JournalTotalDebit', class="hl-string">'Reversed', class="hl-string">'ReversedDate', class="hl-string">'RejectionReasonComment' class=class="hl-string">"hl-comment"># Assuming a field for rejection reason
    ]
    headers_select = fclass="hl-string">"$select={','.join(headers_fields)}"
    headers_filter = fclass="hl-string">"$filter=({legal_entity_filter}) and ({date_filter})"
    headers_url = fclass="hl-string">"{D365_URL}/data/LedgerJournalHeaders?{headers_select}&{headers_filter}&cross-company=true"
    
    journal_headers_raw = execute_odata_query(headers_url, headers)
    if not journal_headers_raw:
        print(class="hl-string">"No journal headers found for the specified criteria. Exiting.")
        exit()

    df_headers = pd.DataFrame(journal_headers_raw)
    df_headers.to_csv(class="hl-string">'raw_journal_headers.csv', index=False)
    print(fclass="hl-string">"Fetched and saved {len(df_headers)} journal headers.")

    class=class="hl-string">"hl-comment"># Query LedgerJournalLines for class="hl-string">'Line Added' activity
    journal_batch_numbers = df_headers[class="hl-string">'JournalBatchNumber'].unique().tolist()
    journal_batch_filter = class="hl-string">" or ".join([fclass="hl-string">"JournalBatchNumber eq '{jbn}'" for jbn in journal_batch_numbers])
    
    lines_fields = [class="hl-string">'JournalBatchNumber', class="hl-string">'CreatedDateTime', class="hl-string">'CreatedBy']
    lines_select = fclass="hl-string">"$select={','.join(lines_fields)}"
    lines_filter = fclass="hl-string">"$filter=({legal_entity_filter}) and ({journal_batch_filter})"
    lines_url = fclass="hl-string">"{D365_URL}/data/LedgerJournalLines?{lines_select}&{lines_filter}&cross-company=true"

    journal_lines_raw = execute_odata_query(lines_url, headers)
    df_lines = pd.DataFrame(journal_lines_raw)
    df_lines.to_csv(class="hl-string">'raw_journal_lines.csv', index=False)
    print(fclass="hl-string">"Fetched and saved {len(df_lines)} journal lines.")

    class=class="hl-string">"hl-comment"># 3. Transform Data into Event Log Format
    print(class="hl-string">"Transforming raw data into event log...")
    event_log_frames = []

    class=class="hl-string">"hl-comment"># Rename columns for consistency
    df_headers.rename(columns={
        class="hl-string">'JournalBatchNumber': class="hl-string">'JournalEntryId',
        class="hl-string">'dataAreaId': class="hl-string">'LegalEntity',
        class="hl-string">'LedgerJournalType': class="hl-string">'JournalType',
        class="hl-string">'JournalTotalDebit': class="hl-string">'JournalTotalAmount',
        class="hl-string">'WorkflowApprovalStatus': class="hl-string">'JournalStatus',
        class="hl-string">'RejectionReasonComment': class="hl-string">'RejectionReason'
    }, inplace=True)
    df_lines.rename(columns={class="hl-string">'JournalBatchNumber': class="hl-string">'JournalEntryId'}, inplace=True)

    class=class="hl-string">"hl-comment"># Activity: Journal Entry Created
    df_created = df_headers[[class="hl-string">'JournalEntryId', class="hl-string">'CreatedDateTime', class="hl-string">'CreatedBy']].copy()
    df_created[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Created'
    df_created.rename(columns={class="hl-string">'CreatedDateTime': class="hl-string">'EventTime', class="hl-string">'CreatedBy': class="hl-string">'UserName'}, inplace=True)
    event_log_frames.append(df_created)

    class=class="hl-string">"hl-comment"># Activity: Journal Line Added
    df_line_added = df_lines[[class="hl-string">'JournalEntryId', class="hl-string">'CreatedDateTime', class="hl-string">'CreatedBy']].copy()
    df_line_added[class="hl-string">'ActivityName'] = class="hl-string">'Journal Line Added'
    df_line_added.rename(columns={class="hl-string">'CreatedDateTime': class="hl-string">'EventTime', class="hl-string">'CreatedBy': class="hl-string">'UserName'}, inplace=True)
    event_log_frames.append(df_line_added)

    class=class="hl-string">"hl-comment"># Activities inferred from status changes and modifications
    class=class="hl-string">"hl-comment"># This part requires a more stateful analysis if audit trails are not directly available
    class=class="hl-string">"hl-comment"># We use ModifiedDateTime as a proxy for the event time of status changes.
    
    class=class="hl-string">"hl-comment"># NOTE: The logic below is a simplified inference. A real implementation might require parsing audit trail logs for precise timestamps.
    status_events_map = {
        class="hl-string">'Submitted': class="hl-string">'Journal Submitted For Approval',
        class="hl-string">'InProgress': class="hl-string">'Journal Review Started', class=class="hl-string">"hl-comment"># Approximation
        class="hl-string">'Approved': class="hl-string">'Journal Approved',
        class="hl-string">'Rejected': class="hl-string">'Journal Rejected',
        class="hl-string">'ChangeRequested': class="hl-string">'Journal Rejected', class=class="hl-string">"hl-comment"># Map another status to Rejected
        class="hl-string">'Canceled': class="hl-string">'Journal Rejected' class=class="hl-string">"hl-comment"># Map another status to Rejected
    }

    status_change_df = df_headers[df_headers[class="hl-string">'JournalStatus'].isin(status_events_map.keys())].copy()
    status_change_df[class="hl-string">'ActivityName'] = status_change_df[class="hl-string">'JournalStatus'].map(status_events_map)
    status_change_df.rename(columns={class="hl-string">'ModifiedDateTime': class="hl-string">'EventTime', class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
    event_log_frames.append(status_change_df[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName', class="hl-string">'RejectionReason']])

    class=class="hl-string">"hl-comment"># Activity: Journal Resubmitted For Approval & Journal Entry Corrected
    class=class="hl-string">"hl-comment"># Infer this by finding a class="hl-string">'Submitted' status that occurred after a class="hl-string">'Rejected' status for the same journal.
    class=class="hl-string">"hl-comment"># For simplicity, we assume any modification after rejection is a correction.
    df_rejected = status_change_df[status_change_df[class="hl-string">'ActivityName'] == class="hl-string">'Journal Rejected']
    for index, row in df_rejected.iterrows():
        class=class="hl-string">"hl-comment"># Check for modifications on the header after rejection
        header_row = df_headers[df_headers[class="hl-string">'JournalEntryId'] == row[class="hl-string">'JournalEntryId']].iloc[0]
        if pd.to_datetime(header_row[class="hl-string">'ModifiedDateTime']) > pd.to_datetime(row[class="hl-string">'EventTime']):
            class=class="hl-string">"hl-comment"># Add Corrected Event
            corrected_event = row.copy()
            corrected_event[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Corrected'
            corrected_event[class="hl-string">'EventTime'] = header_row[class="hl-string">'ModifiedDateTime']
            corrected_event[class="hl-string">'UserName'] = header_row[class="hl-string">'ModifiedBy']
            event_log_frames.append(pd.DataFrame([corrected_event]))
            
            class=class="hl-string">"hl-comment"># If status went back to submitted, it's a resubmission
            if header_row[class="hl-string">'JournalStatus'] == class="hl-string">'Submitted':
                resubmitted_event = row.copy()
                resubmitted_event[class="hl-string">'ActivityName'] = class="hl-string">'Journal Resubmitted For Approval'
                resubmitted_event[class="hl-string">'EventTime'] = header_row[class="hl-string">'ModifiedDateTime']
                resubmitted_event[class="hl-string">'UserName'] = header_row[class="hl-string">'ModifiedBy']
                event_log_frames.append(pd.DataFrame([resubmitted_event]))

    class=class="hl-string">"hl-comment"># Activity: Journal Posting Attempted (Approximation)
    class=class="hl-string">"hl-comment"># This is difficult to capture. We'll use the approval time as a proxy.
    df_approved_for_posting = status_change_df[status_change_df[class="hl-string">'ActivityName'] == class="hl-string">'Journal Approved'].copy()
    df_approved_for_posting[class="hl-string">'ActivityName'] = class="hl-string">'Journal Posting Attempted'
    event_log_frames.append(df_approved_for_posting[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])

    class=class="hl-string">"hl-comment"># Activity: Journal Entry Posted
    df_posted = df_headers[df_headers[class="hl-string">'PostedDateTime'].notna()].copy()
    if not df_posted.empty:
        df_posted[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Posted'
        class=class="hl-string">"hl-comment"># Use PostedDateTime if available, otherwise fallback to ModifiedDateTime
        df_posted[class="hl-string">'EventTime'] = df_posted[class="hl-string">'PostedDateTime'].fillna(df_posted[class="hl-string">'ModifiedDateTime'])
        df_posted.rename(columns={class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
        event_log_frames.append(df_posted[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])

    class=class="hl-string">"hl-comment"># Activity: Journal Entry Reversal Initiated & Reversed
    df_reversed = df_headers[df_headers[class="hl-string">'Reversed'] == True].copy()
    if not df_reversed.empty:
        class=class="hl-string">"hl-comment"># Reversal Initiated (approximated by modification date when Reversed flag is set)
        df_reversal_initiated = df_reversed.copy()
        df_reversal_initiated[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reversal Initiated'
        df_reversal_initiated.rename(columns={class="hl-string">'ModifiedDateTime': class="hl-string">'EventTime', class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
        event_log_frames.append(df_reversal_initiated[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])
        class=class="hl-string">"hl-comment"># Reversed (using the specific ReversedDate)
        df_reversed_final = df_reversed[df_reversed[class="hl-string">'ReversedDate'].notna()].copy()
        df_reversed_final[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reversed'
        df_reversed_final.rename(columns={class="hl-string">'ReversedDate': class="hl-string">'EventTime', class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
        event_log_frames.append(df_reversed_final[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])

    class=class="hl-string">"hl-comment"># 4. Assemble Final Event Log
    print(class="hl-string">"Assembling the final event log...")
    final_event_log = pd.concat(event_log_frames, ignore_index=True)

    class=class="hl-string">"hl-comment"># Merge attributes from the header file
    attributes_to_merge = df_headers[[class="hl-string">'JournalEntryId', class="hl-string">'LegalEntity', class="hl-string">'JournalType', class="hl-string">'JournalStatus', class="hl-string">'JournalTotalAmount', class="hl-string">'RejectionReason']].drop_duplicates()
    final_event_log = pd.merge(final_event_log, attributes_to_merge, on=class="hl-string">'JournalEntryId', how=class="hl-string">'left')

    class=class="hl-string">"hl-comment"># Clean up and order columns
    final_event_log[class="hl-string">'EventTime'] = pd.to_datetime(final_event_log[class="hl-string">'EventTime'])
    final_event_log.sort_values(by=[class="hl-string">'JournalEntryId', class="hl-string">'EventTime'], inplace=True)
    final_event_log.drop_duplicates(subset=[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    
    class=class="hl-string">"hl-comment"># Define column order
    final_columns = [
        class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName', class="hl-string">'LegalEntity',
        class="hl-string">'JournalType', class="hl-string">'JournalStatus', class="hl-string">'JournalTotalAmount', class="hl-string">'RejectionReason'
    ]
    class=class="hl-string">"hl-comment"># Add missing columns with None
    for col in final_columns:
        if col not in final_event_log.columns:
            final_event_log[col] = None
    final_event_log = final_event_log[final_columns]
    
    class=class="hl-string">"hl-comment"># Add EventEndTime (optional, can be populated if duration is known)
    final_event_log[class="hl-string">'EventEndTime'] = None
    
    class=class="hl-string">"hl-comment"># 5. Export to CSV
    final_event_log.to_csv(class="hl-string">'journal_entry_event_log.csv', index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Extraction complete. Event log with {len(final_event_log)} events saved to journal_entry_event_log.csv")

Étapes

Vérifiez que Power Platform Dataflows, le connecteur standard Dynamics 365 et les entités de données requises sont disponibles dans l’environnement cible. Obtenez les autorisations nécessaires pour lire les en-têtes et les lignes des écritures, l’historique des flux de travail ou des approbations, l’historique des statuts, les informations utilisateur, les données des entités juridiques, ainsi que l’historique des extournes et des comptabilisations. La disponibilité des entités dépend de l’application Dynamics 365 et de sa configuration. Si le connecteur n’expose pas une source requise, utilisez [Your table name] ou [Configure based on your system].
Dans Power Apps, ouvrez l’environnement cible et créez un flux de données. Sélectionnez le connecteur standard Dynamics 365, renseignez les informations de connexion à l’environnement et authentifiez-vous avec un compte autorisé à lire les entités requises. N’intégrez pas d’identifiants dans la logique de transformation.
Ajoutez l’entité des en-têtes d’écritures, celle des lignes et chaque source configurée qui consigne les événements de flux de travail, de statut, d’affectation, d’audit, de comptabilisation et d’extourne. Sélectionnez les champs nécessaires pour identifier l’écriture, l’horodatage de l’événement, l’utilisateur, le type d’écriture, le statut, le motif du rejet, l’entité juridique et le montant total. Consignez dans la documentation du flux de données les entités et associations de champs réellement utilisées.
Dans Power Query, appliquez la période et les filtres de société ou d’entité juridique configurés. Conservez les horodatages source et normalisez-les selon un même fuseau horaire documenté. Convertissez les identifiants en texte, les horodatages en un type date-heure cohérent, les montants en valeurs numériques et les statuts en valeurs textuelles uniformes. Supprimez les enregistrements sans JournalEntryId ou EventTime exploitable, sauf s’ils sont conservés dans une sortie distincte dédiée aux exceptions.
Créez une requête d’événements pour chacune des douze activités requises. Chaque requête doit produire explicitement des lignes contenant JournalEntryId, ActivityName, EventTime, EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity et JournalTotalAmount. Ne comptez pas sur ProcessMind pour déduire les activités à partir des changements de statut ou de champ.
Appliquez les règles d’événement aux données source disponibles. Utilisez les horodatages de création des écritures pour « Journal Entry Created », ceux de création des lignes pour « Journal Line Added », les transitions du flux de travail d’approbation ou des statuts pour la soumission, l’examen, l’approbation et le rejet, les modifications postérieures au rejet pour « Journal Entry Corrected », les transitions de soumission ultérieures pour « Journal Resubmitted For Approval », les enregistrements de lancement et de fin de comptabilisation pour « Journal Posting Attempted » et « Journal Entry Posted », et les enregistrements de lancement et de fin d’extourne pour « Journal Entry Reversal Initiated » et « Journal Entry Reversed ». Si un événement requis n’est pas explicitement disponible, définissez une méthode de déduction vérifiable à partir de l’historique source et documentez la règle.
Regroupez les douze requêtes d’événements dans une seule requête de journal d’événements. Vérifiez que chaque ligne comporte exactement les noms de colonnes requis, que ActivityName contient uniquement les libellés d’activité documentés et que EventTime est renseigné. Triez par JournalEntryId, puis par EventTime, et appliquez un critère de départage déterministe si la source en fournit un.
Configurez la destination du flux de données, par exemple un lac, un entrepôt, une base de données ou un fichier pris en charge par le processus d’ingestion de ProcessMind. Enregistrez le journal d’événements sous forme de table plate ou de fichier délimité, avec une ligne par événement. Conservez l’encodage UTF-8, des valeurs date-heure compatibles avec la norme ISO et un schéma stable.
Actualisez le flux de données pour la période choisie, examinez les erreurs d’actualisation et les lignes rejetées, puis rapprochez le nombre d’événements des entités et historiques source. Corrigez les associations ou les filtres avant de publier le résultat.
Exportez le journal d’événements final ou rendez-le accessible pour l’importation dans ProcessMind. Associez JournalEntryId à l’identifiant du cas, ActivityName à l’activité, EventTime à l’horodatage de l’événement et les autres colonnes aux attributs de l’événement ou du cas. ProcessMind lit le journal tel quel : vérifiez donc que toutes les activités nécessaires à la visualisation du processus figurent déjà dans les lignes.

Configuration

Connexion : utilisez le connecteur standard Dynamics 365 via Power Platform Dataflows. Configurez l’environnement et l’authentification dans les paramètres de connexion de la plateforme, et non dans le texte de la requête.
Entités source : sélectionnez les entités configurées pour les en-têtes et les lignes d’écritures, l’historique des flux de travail ou des approbations, des statuts, des audits, des comptabilisations et des extournes, ainsi que les utilisateurs et les entités juridiques. Les noms exacts varient selon l’application Dynamics 365 et ses personnalisations. Faites les associations à l’aide de [Your table name].
Colonnes de sortie requises : renseignez JournalEntryId, ActivityName et EventTime pour chaque ligne d’événement.
Colonnes de sortie recommandées : EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity et JournalTotalAmount.
Période : commencez par trois à six mois d’historique. N’élargissez la période qu’après avoir vérifié la durée d’actualisation, la durée de conservation des données source et l’exhaustivité des événements. Prévoyez une période de recouvrement si des événements peuvent être finalisés après la date de début sélectionnée.
Filtres : appliquez des filtres sur le code société ou l’entité juridique, le type d’écriture, le type de document, le statut de l’écriture et EventTime uniquement s’ils correspondent au périmètre de l’analyse. Évitez d’exclure les enregistrements rejetés, corrigés, soumis à nouveau, extournés ou comptabilisés qui sont nécessaires pour reconstituer le cycle de vie.
Actualisation incrémentielle : utilisez un horodatage fiable de modification de la source lorsqu’il est disponible. Conservez les événements tardifs liés aux flux de travail, aux audits, aux comptabilisations et aux extournes, puis éliminez les doublons à l’aide d’un identifiant d’événement source stable ou d’une clé composite documentée.
Fuseaux horaires : convertissez tous les horodatages source dans un même fuseau horaire documenté. Conservez l’horodatage d’origine si le rapprochement d’audit l’exige.
Performances : filtrez les données à la source lorsque cette option est disponible, sélectionnez uniquement les colonnes nécessaires, évitez les jointures superflues, agrégez les lignes d’écritures avant de joindre les totaux et partitionnez les historiques volumineux ou actualisez-les de manière incrémentielle.
Qualité des données : rejetez les lignes sans JournalEntryId ou EventTime, ou consignez-les séparément. Uniformisez les libellés de statut et les identifiants utilisateur avant de regrouper les requêtes d’événements.
Prérequis : accès à Power Platform Dataflows, connexion au connecteur Dynamics 365, autorisations de lecture sur toutes les entités sélectionnées, accès aux historiques des flux de travail, des audits, des comptabilisations et des extournes lorsque cela est nécessaire, ainsi qu’une destination ou une méthode d’importation ProcessMind sous licence ou autorisée.
Dépendance à la configuration : Dynamics 365 n’expose pas les mêmes entités ni les mêmes champs d’historique dans toutes les applications et implémentations. Avant le déploiement, remplacez les valeurs de substitution par les associations réelles des entités et des champs configurés.

Exemple de requête sql

WITH
JournalHeader AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [CreatedDateTime] AS CreatedDateTime,
        [ModifiedDateTime] AS ModifiedDateTime,
        [CreatedBy] AS CreatedBy,
        [ModifiedBy] AS ModifiedBy,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal header entity]
    WHERE [CreatedDateTime] >= '[Start date parameter]'
      AND [CreatedDateTime] < '[End date parameter]'
      AND ([LegalEntity] IN ([Your company filter]) OR [Your company filter] IS NULL)
),
JournalLines AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [CreatedDateTime] AS EventTime,
        [CreatedBy] AS UserName,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal line entity]
    WHERE [CreatedDateTime] >= '[Start date parameter]'
      AND [CreatedDateTime] < '[End date parameter]'
),
StatusHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [StatusChangeDateTime] AS EventTime,
        [StatusChangeEndDateTime] AS EventEndTime,
        [ChangedBy] AS UserName,
        [PreviousStatus] AS PreviousStatus,
        [NewStatus] AS NewStatus,
        [JournalType] AS JournalType,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal status history entity]
    WHERE [StatusChangeDateTime] >= '[Start date parameter]'
      AND [StatusChangeDateTime] < '[End date parameter]'
),
ReviewHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [ReviewStartDateTime] AS EventTime,
        [ReviewEndDateTime] AS EventEndTime,
        [Reviewer] AS UserName,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal review history entity]
    WHERE [ReviewStartDateTime] >= '[Start date parameter]'
      AND [ReviewStartDateTime] < '[End date parameter]'
),
PostingHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [PostingAttemptDateTime] AS PostingAttemptDateTime,
        [PostingDateTime] AS PostingDateTime,
        [PostingEndDateTime] AS PostingEndTime,
        [PostedBy] AS PostedBy,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal posting history entity]
    WHERE [PostingAttemptDateTime] >= '[Start date parameter]'
      AND [PostingAttemptDateTime] < '[End date parameter]'
),
ReversalHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [ReversalInitiatedDateTime] AS ReversalInitiatedDateTime,
        [ReversalCompletedDateTime] AS ReversalCompletedDateTime,
        [ReversalCompletedBy] AS ReversalCompletedBy,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal reversal history entity]
    WHERE [ReversalInitiatedDateTime] >= '[Start date parameter]'
      AND [ReversalInitiatedDateTime] < '[End date parameter]'
),
CorrectionHistory AS (
    SELECT
        CAST([JournalEntryId] AS varchar(255)) AS JournalEntryId,
        [ModificationDateTime] AS EventTime,
        [ModificationEndDateTime] AS EventEndTime,
        [ModifiedBy] AS UserName,
        [JournalType] AS JournalType,
        [JournalStatus] AS JournalStatus,
        [RejectionReason] AS RejectionReason,
        [LegalEntity] AS LegalEntity,
        [JournalTotalAmount] AS JournalTotalAmount
    FROM [Your journal audit or modification history entity]
    WHERE [ModificationDateTime] >= '[Start date parameter]'
      AND [ModificationDateTime] < '[End date parameter]'
),
EventLog AS (
    SELECT JournalEntryId, 'Journal Entry Created' AS ActivityName, CreatedDateTime AS EventTime, CreatedDateTime AS EventEndTime, CreatedBy AS UserName, JournalType, JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM JournalHeader WHERE JournalEntryId IS NOT NULL AND CreatedDateTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Line Added' AS ActivityName, EventTime, EventTime AS EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM JournalLines WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Submitted For Approval' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, NewStatus AS JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM StatusHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL AND (NewStatus IN ('In Review', 'Submitted') OR (PreviousStatus = 'Draft' AND NewStatus IN ('In Review', 'Submitted')))
    UNION ALL
    SELECT JournalEntryId, 'Journal Review Started' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM ReviewHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Approved' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, NewStatus AS JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM StatusHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL AND NewStatus = 'Approved'
    UNION ALL
    SELECT JournalEntryId, 'Journal Rejected' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, NewStatus AS JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM StatusHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL AND NewStatus IN ('Rejected', 'Needs Correction')
    UNION ALL
    SELECT c.JournalEntryId, 'Journal Entry Corrected' AS ActivityName, c.EventTime, c.EventEndTime, c.UserName, c.JournalType, c.JournalStatus, c.RejectionReason, c.LegalEntity, c.JournalTotalAmount FROM CorrectionHistory c WHERE c.JournalEntryId IS NOT NULL AND c.EventTime IS NOT NULL AND EXISTS (SELECT 1 FROM StatusHistory s WHERE s.JournalEntryId = c.JournalEntryId AND s.NewStatus IN ('Rejected', 'Needs Correction') AND s.EventTime < c.EventTime)
    UNION ALL
    SELECT JournalEntryId, 'Journal Resubmitted For Approval' AS ActivityName, EventTime, EventEndTime, UserName, JournalType, NewStatus AS JournalStatus, RejectionReason, LegalEntity, JournalTotalAmount FROM StatusHistory WHERE JournalEntryId IS NOT NULL AND EventTime IS NOT NULL AND PreviousStatus IN ('Rejected', 'Needs Correction', 'Draft') AND NewStatus IN ('In Review', 'Submitted')
    UNION ALL
    SELECT JournalEntryId, 'Journal Posting Attempted' AS ActivityName, PostingAttemptDateTime AS EventTime, PostingAttemptDateTime AS EventEndTime, PostedBy AS UserName, JournalType, JournalStatus, CAST(NULL AS varchar(255)) AS RejectionReason, LegalEntity, JournalTotalAmount FROM PostingHistory WHERE JournalEntryId IS NOT NULL AND PostingAttemptDateTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Entry Posted' AS ActivityName, PostingDateTime AS EventTime, PostingEndTime AS EventEndTime, PostedBy AS UserName, JournalType, 'Posted' AS JournalStatus, CAST(NULL AS varchar(255)) AS RejectionReason, LegalEntity, JournalTotalAmount FROM PostingHistory WHERE JournalEntryId IS NOT NULL AND PostingDateTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Entry Reversal Initiated' AS ActivityName, ReversalInitiatedDateTime AS EventTime, ReversalInitiatedDateTime AS EventEndTime, CAST(NULL AS varchar(255)) AS UserName, JournalType, JournalStatus, CAST(NULL AS varchar(255)) AS RejectionReason, LegalEntity, JournalTotalAmount FROM ReversalHistory WHERE JournalEntryId IS NOT NULL AND ReversalInitiatedDateTime IS NOT NULL
    UNION ALL
    SELECT JournalEntryId, 'Journal Entry Reversed' AS ActivityName, ReversalCompletedDateTime AS EventTime, ReversalCompletedDateTime AS EventEndTime, ReversalCompletedBy AS UserName, JournalType, JournalStatus, CAST(NULL AS varchar(255)) AS RejectionReason, LegalEntity, JournalTotalAmount FROM ReversalHistory WHERE JournalEntryId IS NOT NULL AND ReversalCompletedDateTime IS NOT NULL
)
SELECT
    JournalEntryId,
    ActivityName,
    EventTime,
    EventEndTime,
    UserName,
    JournalType,
    JournalStatus,
    RejectionReason,
    LegalEntity,
    JournalTotalAmount
FROM EventLog
WHERE JournalEntryId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY JournalEntryId, EventTime, ActivityName;

Prêt à commencer ?

Ce modèle vous fournit tout le nécessaire pour commencer à optimiser votre processus de comptabilisation des écritures, de l’enregistrement au reporting. Appuyez-vous dès aujourd’hui sur vos données pour gagner en efficacité et raccourcir vos cycles de reporting financier.

Retour au guide d’amélioration

Télécharger le modèle

Accélérez le traitement des écritures comptables dans Dynamics 365 et produisez vos rapports plus rapidement

Éliminez les goulots d’étranglement et réduisez de 30 % le temps de cycle des écritures comptables R2R.

Démarrez votre essai gratuit

Aucune carte bancaire requise. Commencez en quelques minutes.

Votre modèle de données pour le processus de clôture comptable et les écritures comptables

Votre modèle de données pour le processus de clôture comptable et les écritures comptables

Attributs du processus de comptabilisation des écritures, de l’enregistrement au reporting

Activités du processus de comptabilisation des écritures, de l’enregistrement au reporting

Guides d’extraction

Exportation via le framework de gestion des données de Microsoft Dynamics 365

Étapes

Configuration

Exemple de requête sql

Interroger Azure Data Lake via Synapse pour Dynamics 365

Étapes

Configuration

Exemple de requête sql

Extraction par script Python via l’API OData de Dynamics 365

Étapes

Configuration

Exemple de requête python

Extraction des données de Dynamics 365 avec Power Platform Dataflows

Étapes

Configuration

Exemple de requête sql

Prêt à commencer ?

Accélérez le traitement des écritures comptables dans Dynamics 365 et produisez vos rapports plus rapidement

Votre modèle de données pour le processus de clôture comptable et les écritures comptables

Votre modèle de données pour le processus de clôture comptable et les écritures comptables

Attributs du processus de comptabilisation des écritures, de l’enregistrement au reporting

Activités du processus de comptabilisation des écritures, de l’enregistrement au reporting

Guides d’extraction

Exportation via le framework de gestion des données de Microsoft Dynamics 365

Étapes

Configuration

Exemple de requête sql

Interroger Azure Data Lake via Synapse pour Dynamics 365

Étapes

Configuration

Exemple de requête sql

Extraction par script Python via l’API OData de Dynamics 365

Étapes

Configuration

Exemple de requête python

Extraction des données de Dynamics 365 avec Power Platform Dataflows

Étapes

Configuration

Exemple de requête sql

Prêt à commencer ?

Accélérez le traitement des écritures comptables dans Dynamics 365 et produisez vos rapports plus rapidement

Prêt à commencer ?