> Kontinuierliche Prozessoptimierung > Record to Report Journaleintrag > Microsoft Dynamics 365 > Datenvorlage

Ihre Record to Report - Journaleintrag Datenvorlage

Microsoft Dynamics 365

Record to Report - Journaleintrag Attribute (21) Record to Report - Journaleintrag Aktivitäten (12) Extraktionsleitfäden (4)

Ihre Record to Report - Journaleintrag Datenvorlage

Diese Vorlage bietet eine umfassende Anleitung zu den wesentlichen Datenpunkten, die für die Analyse Ihres Record to Report - Journaleintragsprozesses erforderlich sind. Sie beschreibt die entscheidenden Attribute, die gesammelt werden müssen, und die Schlüsselaktivitäten, die zu verfolgen sind, um sicherzustellen, dass Sie alle notwendigen Informationen für eine effektive Process Mining-Initiative erfassen. Zusätzlich finden Sie praktische Anleitungen zur Extraktion dieser Daten aus Ihrem Quellsystem.

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten zur Verfolgung
Extraktionsanleitung für Microsoft Dynamics 365

Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Vorlage herunterladen

Record to Report - Journaleintrag Attribute

Dies sind die empfohlenen Datenfelder, die in Ihrem Event Log für eine umfassende Record to Report - Journaleintrag-Analyse enthalten sein sollten.

3 Erforderlich 7 Empfohlen 11 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des spezifischen Geschäftsprozessschritts oder Ereignisses, das aufgetreten ist.
Beschreibung Dieses Attribut beschreibt ein einzelnes Ereignis oder eine Aufgabe innerhalb des Journaleintrag-Lebenszyklus, wie z. B. 'Journal Entry Created', 'Journal Submitted For Approval' oder 'Journal Entry Posted'. Diese Aktivitäten bilden die Knotenpunkte der entdeckten Prozesslandkarte. Die Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten ist das Herzstück des Process Mining. Sie enthüllt den tatsächlichen Prozessfluss, hilft, Abweichungen vom Standardverfahren zu identifizieren und zeigt Engpässe auf, wo Aktivitäten länger als erwartet dauern oder wiederholt werden. Bedeutung Dieses Attribut definiert die Schritte im Prozess, bildet das Rückgrat der Prozesslandkarte und ermöglicht die Analyse von Prozessfluss und Variationen. Datenquelle Dies ist ein konzeptionelles Attribut, das aus Systemereignissen, Statusänderungen oder Workflow-Protokollen innerhalb von Microsoft Dynamics 365 abgeleitet wird. Beispiele Buchungsjournaleintrag erstelltJournal zur Genehmigung eingereichtJournal genehmigtJournalbuchung gebucht
	Ereigniszeit EventTime	Der genaue Timestamp, der angibt, wann eine Aktivität oder ein Event aufgetreten ist.
Beschreibung Die Ereigniszeit erfasst Datum und Uhrzeit, zu der eine spezifische Aktivität im Journaleintragsprozess stattfand. Diese chronologischen Daten sind unerlässlich, um Ereignisse zu ordnen und die Dauer zwischen ihnen zu berechnen. In der Analyse wird dieser Timestamp verwendet, um die Zeitachse für jeden Case zu konstruieren, was entscheidend für die Berechnung aller zeitbasierten Metriken wie Zykluszeiten, Bearbeitungszeiten und Wartezeiten ist. Er ermöglicht die Identifizierung von Verzögerungen zwischen den Schritten und unterstützt Dashboards bezüglich Engpässen und SLA-Compliance. Bedeutung Dieser Timestamp ist unerlässlich für die korrekte Reihenfolge der Ereignisse und die Berechnung aller dauerbasierten KPIs, wie Zykluszeit und Bearbeitungsverzögerungen. Datenquelle Ereignis-Zeitstempel finden sich typischerweise in Workflow-Verlaufsprotokollen, Audit-Trail-Tabellen (z. B. SysDatabaseLog) oder als Erstellungs-/Änderungs-Zeitstempel auf verwandten Datensätzen wie LedgerJournalTable und LedgerJournalTrans. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:10Z
	Journalbuchungs-ID JournalEntryId	Der eindeutige Identifikator für einen Journaleintrag, der als primärer Case-Identifikator dient.
Beschreibung Die Journaleintrag-ID verknüpft alle Aktivitäten und Datenpunkte einer einzelnen Journaleintragstransaktion eindeutig. Sie ermöglicht die vollständige End-to-End-Verfolgung des Lebenszyklus eines Journals, von der Erstellung und Prüfung bis zur endgültigen Buchung im Hauptbuch. In der Process Mining-Analyse ist dieses Attribut grundlegend für die Rekonstruktion des Prozessflusses. Jede eindeutige Journaleintrag-ID repräsentiert eine einzelne Instanz des Prozesses und ermöglicht eine detaillierte Untersuchung von Prozessvarianten, Zykluszeiten und Compliance für einzelne Finanztransaktionen. Bedeutung Dies ist der essenzielle Schlüssel zur Verfolgung eines Journaleintrags von Anfang bis Ende, der die Analyse des gesamten Prozessflusses für jeden Case ermöglicht. Datenquelle Dieser Identifikator ist typischerweise in der Journalkopf-Tabelle, wie z. B. LedgerJournalTable, oft in einem Feld namens JournalNum zu finden. Beispiele JRN-0012345JV-2023-08-156GENJ0000891
	Ablehnungsgrund RejectionReason	Der angegebene Grund, wenn ein Journaleintrag während des Genehmigungsprozesses abgelehnt wird.
Beschreibung Wenn ein Journaleintrag abgelehnt wird, gibt der Genehmiger oft einen Grund für die Ablehnung an. Dieses Attribut erfasst diese Information, die für die Ursachenanalyse unverzichtbar ist. Dies ist das primäre Attribut für das Dashboard 'Journaleintrag: Ablehnungsratenanalyse'. Durch das Kategorisieren und Analysieren von Ablehnungsgründen können Organisationen häufige Probleme wie fehlerhafte Dokumentation, Richtlinienverstöße oder Datenerfassungsfehler identifizieren und dann gezielte Schulungen oder Prozessverbesserungen implementieren. Bedeutung Erklärt, warum Nacharbeit auftritt, und liefert die direkten Erkenntnisse, die zur Reduzierung der Ablehnungsquoten und zur Verbesserung der erstmaligen Genehmigungen erforderlich sind. Datenquelle Diese Information wird typischerweise in der Workflow-Historie oder im Kommentarbereich gespeichert, der dem Ablehnungsschritt zugeordnet ist. Beispiele Unzureichende BelegdokumentationFalsches Konto verwendetGenehmigungsschwelle überschrittenDoppelte Eingabe
	Benutzername UserName	Der Name des Benutzers, der die Aktivität durchgeführt hat.
Beschreibung Dieses Attribut identifiziert den Mitarbeiter oder Systembenutzer, der für die Ausführung einer spezifischen Aktivität verantwortlich ist, wie z. B. das Erstellen, Genehmigen oder Buchen eines Journaleintrags. Es verknüpft Prozessschritte mit Personalressourcen. Die Analyse der Leistung pro Benutzer ist eine Schlüsselkompetenz im Process Mining. Sie hilft, das Dashboard 'Journaleintrag: Benutzerleistung' zu erstellen, um Aktivitätsdauern und Durchsatz über verschiedene Benutzer oder Teams hinweg zu vergleichen. Dies kann Spitzenleister hervorheben, Schulungsbedarfe identifizieren und bei der Arbeitslastverteilung unterstützen. Bedeutung Verknüpft Prozessaktivitäten mit bestimmten Personen und ermöglicht so die Analyse der Benutzerleistung, Arbeitslastverteilung und Ressourcenzuweisung. Datenquelle Benutzerinformationen sind typischerweise in createdBy- oder modifiedBy-Feldern auf Tabellen wie LedgerJournalTable oder in zugehörigen Workflow-Historienprotokollen zu finden. Beispiele Alice SmithBob Johnsonsystem.batch
	Endzeit des Events EventEndTime	Der Timestamp, der anzeigt, wann eine Aktivität oder ein Event abgeschlossen wurde.
Beschreibung Die Ereignis-Endzeit markiert den Abschluss einer spezifischen Aktivität. Während die StartTime angibt, wann ein Ereignis beginnt, bietet die EndTime die andere Begrenzung, was eine präzise Dauerberechnung individueller Aufgaben ermöglicht. Im Process Mining ermöglicht das Vorhandensein von Start- und Endzeit die Berechnung der Aktivitätsbearbeitungszeit, die sich von der Wartezeit unterscheidet. Dies ist entscheidend für Dashboards, die die Benutzerleistung analysieren und identifizieren, welche spezifischen Aufgaben, nicht nur die Lücken dazwischen, die meiste Zeit beanspruchen. Bedeutung Ermöglicht die präzise Berechnung der Dauer jeder Aktivität, was für die Analyse der Benutzerleistung und die Identifizierung ressourcenintensiver Aufgaben unerlässlich ist. Datenquelle Diese Daten können explizit in Workflow-Protokollen gespeichert sein oder müssen durch die Verwendung der StartTime der nachfolgenden Aktivität in der Sequenz abgeleitet werden. Beispiele 2023-10-26T10:05:15Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
	Journal Gesamtbetrag JournalTotalAmount	Der gesamte Geldwert des Journaleintrags, typischerweise die Summe der Sollbeträge.
Beschreibung Dieses Attribut repräsentiert den gesamten finanziellen Wert des Journaleintrags. Es kann verwendet werden, um Einträge in Wertbereiche zu kategorisieren, wie z. B. niedriger, mittlerer und hoher Wert. Die Analyse des Prozesses basierend auf dem finanziellen Wert kann wichtige Muster aufdecken. Zum Beispiel könnten hochwertige Journaleinträge einem strengeren Genehmigungsprozess mit mehr Schritten und längeren Zykluszeiten folgen. Dieses Attribut ist unerlässlich für die Wesentlichkeitsanalyse und das Verständnis der finanziellen Auswirkungen von Prozesseffizienzproblemen. Bedeutung Ermöglicht die Segmentierung des Prozesses nach finanziellen Werten, die oft mit der Prozesskomplexität, dem Risiko und den Genehmigungs-Workflows korrelieren. Datenquelle Dieser Wert muss möglicherweise durch Summierung der Sollbeträge aus der Journallinien-Tabelle, LedgerJournalTrans, für jeden Journaleintrag berechnet werden. Beispiele 1500.75125000.0050.25
	Journalart JournalType	Die Klassifizierung des Journaleintrags, wie z. B. General Journal oder Accrual.
Beschreibung Der Journaltyp kategorisiert Einträge nach ihrem Geschäftszweck, z. B. tägliche Buchungen, Abgrenzungen, Umbuchungen oder Eliminierungen. Diese Segmentierung ist entscheidend, um verschiedene Prozesspfade und Verhaltensweisen zu verstehen. Dieses Attribut ermöglicht das Filtern und Vergleichen des Prozesses über unterschiedliche Journaltypen hinweg. Es ist unerlässlich für das Dashboard 'Journalbuchungen: Durchsatz nach Typ' und hilft zu analysieren, ob bestimmte Journaltypen anfälliger für Verzögerungen, Ablehnungen oder Nacharbeiten sind. Bedeutung Ermöglicht die Segmentierung der Analyse, um Prozesse für verschiedene Geschäftszwecke zu vergleichen, die unterschiedliche Pfade, Zykluszeiten und Genehmigungsanforderungen aufweisen können. Datenquelle Dies wird typischerweise in der Journalkopf-Tabelle, LedgerJournalTable, in einem Feld gespeichert, das mit Journalnamen oder -typen (z. B. JournalName) in Verbindung steht. Beispiele HauptbuchAbgrenzungsanpassungInnerbetriebliche ÜbertragungGehaltsabrechnung
	Journalstatus JournalStatus	Der aktuelle oder finale Status des Journaleintrags.
Beschreibung Dieses Attribut gibt den Status des Journaleintrags zu einem bestimmten Zeitpunkt an, wie z. B. 'Draft', 'In Review', 'Approved', 'Rejected' oder 'Posted'. Es bietet einen Überblick darüber, wo sich der Eintrag in seinem Lebenszyklus befindet. Die Analyse des Status ist hilfreich, um die Ergebnisse von Cases zu verstehen. Sie kann verwendet werden, um nach allen abgelehnten Journalen zu filtern oder das Volumen der Journale in einer bestimmten Phase zu verfolgen. Dieses Attribut unterstützt mehrere Dashboards, indem es Kontext für Durchsatz- und Statusanalysen liefert. Bedeutung Bietet ein klares Ergebnis für jeden Journaleintrag und ermöglicht die Analyse von Erfolgsraten, Ablehnungsraten und dem Arbeitsvolumen in verschiedenen Phasen. Datenquelle Der Status ist oft in der Journalkopf-Tabelle, LedgerJournalTable, zu finden oder wird aus dem Workflow-Status abgeleitet. Beispiele EntwurfEingereichtGenehmigtGebuchtAbgelehnt
	Rechtsträger LegalEntity	Die juristische Einheit oder der Buchungskreis, für den der Journaleintrag erfasst wird.
Beschreibung Die juristische Einheit repräsentiert die spezifische Firma oder Geschäftseinheit innerhalb einer Organisation, für die die Finanztransaktion erfasst wird. Dies ist eine grundlegende organisatorische Dimension in Finanzsystemen. Im Process Mining ermöglicht dieses Attribut den Vergleich des Journaleintragsprozesses über verschiedene Teile der Organisation hinweg. Es kann aufzeigen, ob bestimmte juristische Einheiten effizientere Prozesse, höhere Ablehnungsraten oder längere Zykluszeiten aufweisen, was hilft, Best Practices zu identifizieren und zu teilen. Bedeutung Ermöglicht den Vergleich der Prozessleistung über verschiedene Unternehmen oder Geschäftsbereiche hinweg, wobei Abweichungen und Verbesserungsmöglichkeiten aufgezeigt werden. Datenquelle Dies ist ein Kernfeld in Dynamics 365, oft verfügbar in Transaktionstabellen wie LedgerJournalTable, typischerweise an die DataAreaId gebunden. Beispiele USMFDEMFGBSI
	Abteilung DepartmentName	Die Abteilung oder Kostenstelle, die dem Journaleintrag zugeordnet ist.
Beschreibung Die Abteilung oder Kostenstelle identifiziert die interne Geschäftseinheit, die für die Finanztransaktion verantwortlich oder davon betroffen ist. Dies ist eine Schlüsseldimension für die interne Managementberichterstattung. Dieses Attribut ermöglicht die Analyse des Journaleintragsprozesses nach Abteilung. Es kann helfen, Fragen zu beantworten wie: Welche Abteilungen reichen die meisten Journale ein? Haben bestimmte Abteilungen höhere Ablehnungsraten oder längere Genehmigungszeiten? Dies ist nützlich für gezielte Prozessverbesserungsbemühungen. Bedeutung Bietet eine Möglichkeit, die Prozessleistung nach Geschäftsfunktion zu analysieren, um abteilungsspezifische Engpässe oder Schulungsbedarfe zu identifizieren. Datenquelle Diese Information ist typischerweise auf Journallinien-Ebene (LedgerJournalTrans) als Finanzdimension zu finden. Beispiele VertriebFinanzenMarketingVorgänge
	Bearbeitungszeit ProcessingTime	Die Dauer der aktiven Bearbeitung einer Aktivität.
Beschreibung Die Bearbeitungszeit misst die Zeit zwischen dem Start und Ende einer Aktivität und stellt die tatsächliche Arbeitsdauer dar. Dies unterscheidet sich von der Zykluszeit, die Wartezeiten zwischen Aktivitäten einschließt. Diese berechnete Metrik ist entscheidend für das Dashboard 'Journaleintrag: Benutzerleistung'. Sie hilft zu verstehen, wie lange Benutzer oder Teams für die Erledigung spezifischer Aufgaben benötigen, und eliminiert den Einfluss von Warteschlangen oder Wartezeiten. Dies ermöglicht eine gerechtere und genauere Beurteilung der Ressourceneffizienz. Bedeutung Misst die aktive Arbeitszeit für eine Aktivität und ermöglicht so die Analyse der Benutzer- und Teameffizienz ohne die Störung von Wartezeiten. Datenquelle Dies wird berechnet, indem die Differenz zwischen der EventEndTime und der EventTime (StartTime) für jede Aktivität genommen wird. Beispiele PT5M15SPT1H15MP1DT2H
	Buchungsdatum PostingDate	Das Datum, an dem der Journaleintrag im Hauptbuch gebucht wird.
Beschreibung Das Buchungsdatum ist das offizielle Datum, an dem die Transaktion die Hauptbuchsalden beeinflusst. Dieses Datum ist entscheidend für die Finanzberichterstattung und die Abschlussperioden. Dieses Attribut wird verwendet, um die Verzögerung zwischen Genehmigung und Buchung zu analysieren, was der Fokus des KPIs 'Journaleintrag: Buchungsdurchlaufzeit' ist. Die Reduzierung dieser Verzögerung ist oft ein Schlüsselziel zur Beschleunigung des Finanzabschlussprozesses. Es kann auch zur Analyse des Buchungsvolumens über die Zeit verwendet werden. Bedeutung Entscheidend für die Berechnung des KPI der Buchungsdurchlaufzeit und das Verständnis von Verzögerungen zwischen der Genehmigung und dem Zeitpunkt, zu dem eine Transaktion im Hauptbuch offiziell wird. Datenquelle Dieses Datum wird typischerweise in der Journalkopf-Tabelle (LedgerJournalTable) oder verwandten gebuchten Transaktionstabellen gespeichert. Beispiele 2023-10-282023-11-012023-10-31
	Genehmigungs-SLA-Status ApprovalSlaState	Gibt an, ob die Genehmigung der Journalbuchung die Service Level Agreement erfüllt hat.
Beschreibung Dieses Attribut kategorisiert den Genehmigungszyklus jedes Journaleintrags danach, ob er innerhalb der durch ein Service Level Agreement (SLA) definierten Zielzeit abgeschlossen wurde. Mögliche Werte sind typischerweise 'Met' oder 'Breached'. Dies ist die Kernmetrik für das Dashboard 'Journaleintrag: SLA-Compliance der Genehmigung'. Es bietet eine klare, geschäftsorientierte Ansicht der Leistung im Vergleich zu den Zielen, hilft, die Rechtzeitigkeit des Genehmigungsprozesses zu überwachen und zu verwalten und Verbesserungen voranzutreiben, wo SLAs häufig verfehlt werden. Bedeutung Übersetzt Roh-Zykluszeitdaten in ein klares Geschäftsergebnis (met oder breached), wodurch die Leistungsverfolgung gegenüber Schlüsselzielen vereinfacht wird. Datenquelle Dies ist ein berechnetes Attribut. Die Logik erfordert den Vergleich des berechneten KPI für die Genehmigungs-Zykluszeit mit einem vordefinierten SLA-Ziel. Beispiele ErfülltVerletzt
	Genehmigungsstufe ApprovalLevel	Gibt die aktuelle oder abgeschlossene Phase in einem mehrstufigen Genehmigungs-Workflow an.
Beschreibung Für Journalbuchungen, die mehrere Genehmigungen erfordern, verfolgt dieses Attribut, welche Ebene der Hierarchie der Eintrag erreicht hat, zum Beispiel „Manager Approval“ oder „Director Approval“. Dieses Attribut ist nützlich, um Genehmigungsengpässe detaillierter zu analysieren. Es kann helfen, festzustellen, ob Verzögerungen konsistent auf einer bestimmten Ebene in der Genehmigungskette auftreten, was auf die Notwendigkeit einer Prozessneugestaltung oder Ressourcenumverteilung in dieser Phase hindeutet. Bedeutung Bietet Transparenz über mehrstufige Genehmigungs-Workflows und hilft, Engpässe auf spezifischen Genehmigungsebenen zu identifizieren. Datenquelle Diese Information würde aus dem Workflow-Historienprotokoll abgeleitet, das den Abschluss verschiedener Genehmigungsschritte verfolgt. Beispiele Ebene 1: ManagerEbene 2: DirektorEbene 3: VP Finanzen
	Is First Time Right IsFirstTimeRight	Ein Kennzeichen, das angibt, ob das Journal ohne vorherige Ablehnungen genehmigt wurde.
Beschreibung Dieses Case-Level boolesche Attribut ist 'true', wenn ein Journaleintrag von der Einreichung zur Genehmigung ohne dazwischenliegende Aktivitäten wie 'Journal Rejected' oder 'Journal Entry Corrected' verläuft. Es ist ein Schlüsselmaß für die Prozessqualität. Der KPI 'First-Time Right Approval Rate' wird direkt aus diesem Attribut berechnet. Eine hohe Rate weist auf einen effizienten und hochwertigen Prozess hin, während eine niedrige Rate systemische Probleme mit der anfänglichen Datenqualität, der Klarheit der Anforderungen oder den Einreichungsverfahren signalisiert. Bedeutung Dies ist ein kritisches Maß für die Prozessqualität, das aufzeigt, wie viele Journale reibungslos und ohne Nacharbeit den Genehmigungsprozess durchlaufen. Datenquelle Dies ist ein berechnetes Attribut, das auf Case-Ebene durch Analyse der Abfolge von Aktivitäten für jede Journaleintrag-ID abgeleitet wird. Beispiele truefalsch
	Ist automatisierte Buchung IsAutomatedPosting	Ein Kennzeichen, das angibt, ob die Journalbuchung automatisch erstellt oder gebucht wurde.
Beschreibung Dieses boolesche Attribut unterscheidet zwischen Journaleinträgen, die manuell von einem Benutzer erstellt werden, und solchen, die automatisch vom System oder einem Subsystem generiert werden, wie z. B. einer Systemintegration oder einem automatisierten Verrechnungsprozess. Die Analyse dieses Attributs hilft, die Effizienz und Fehlerraten von automatisierten gegenüber manuellen Prozessen zu vergleichen. Sie kann Möglichkeiten für weitere Automatisierung aufzeigen, indem sie zeigt, ob manuelle Einträge anfälliger für Fehler, Nacharbeit oder Verzögerungen sind. Bedeutung Trennt manuelle von automatisierten Prozessen und ermöglicht so einen Vergleich ihrer Effizienz, Genauigkeit und Compliance. Datenquelle Dies kann durch den 'Created by'-Benutzer (z. B. ein System- oder Batch-Benutzer) oder ein spezifisches Flag in der Journalkopf- oder Typkonfiguration angezeigt werden. Beispiele truefalsch
	Ist Nacharbeit IsRework	Ein Kennzeichen, das Aktivitäten identifiziert, die Teil eines Nacharbeits- oder Korrekturschleife sind.
Beschreibung Dieses berechnete boolesche Attribut wird für Aktivitäten, die nach einer Ablehnung auftreten, wie z. B. 'Journal Entry Corrected' oder ein wiederholtes 'Journal Submitted For Approval', auf 'true' gesetzt. Es hilft, Nacharbeit zu isolieren und zu quantifizieren. Dieses Attribut ist unerlässlich für das Dashboard 'Journaleintrag: Nacharbeits- und Korrekturschleifen' und den KPI 'Rework Rate'. Durch die Kennzeichnung von Nacharbeit wird es einfach, die Häufigkeit und Auswirkungen von Korrekturzyklen zu visualisieren und zu messen, die eine primäre Quelle der Ineffizienz im Prozess sind. Bedeutung Kennzeichnet direkt ineffiziente Nacharbeitschleifen und erleichtert die Quantifizierung der Auswirkungen von Ablehnungen und Korrekturen auf die Gesamtzykluszeit und die Kosten. Datenquelle Dies ist ein berechnetes Attribut, das während der Datentransformation durch Analyse der Abfolge von Aktivitäten innerhalb eines Cases abgeleitet wird. Beispiele truefalsch
	Letzte Datenaktualisierung LastDataUpdate	Der `Timestamp`, wann die `Daten` zuletzt aus dem Quellsystem aktualisiert wurden.
Beschreibung Dieses Attribut gibt Datum und Uhrzeit der letzten Datenextraktion aus dem Quellsystem an. Es bietet Kontext für die Aktualität der Analyse und der enthaltenen Daten. Das Anzeigen dieser Informationen in Dashboards versichert den Benutzern die Aktualität der Daten und hilft ihnen, den von der aktuellen Prozessanalyse abgedeckten Zeitrahmen zu verstehen. Es ist ein Schlüsselstück an Metadaten für jedes Process Mining-Projekt. Bedeutung Bietet entscheidenden Kontext zur Aktualität der Daten und stellt sicher, dass Benutzer verstehen, wie aktuell die Prozessanalyse ist. Datenquelle Dieser Timestamp wird während des Datenextraktions-, Transformations- und Ladevorgangs (ETL) generiert und gespeichert. Beispiele 2023-10-27T02:00:00Z
	Quellsystem SourceSystem	Das System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut identifiziert die Quellanwendung, aus der die Journaleintragsdaten stammen. Für diesen Prozess ist der Wert typischerweise eine Konstante, wie z. B. 'Microsoft Dynamics 365'. In einem breiteren Analysezusammenhang, insbesondere in Umgebungen mit mehreren ERPs oder integrierten Systemen, hilft dieses Feld, Prozesse und Datenquellen zu differenzieren. Es gewährleistet Klarheit über die Datenherkunft und ist wichtig für Datengovernance und Validierung. Bedeutung Identifiziert den Ursprung der Daten, was für die Data Governance und für Analysen entscheidend ist, die möglicherweise mehrere Unternehmenssysteme umfassen. Datenquelle Dies ist ein statischer Wert, der während des Datenextraktions-, Transformations- und Ladeprozesses (ETL) hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Microsoft Dynamics 365D365 F&O
	Währungscode CurrencyCode	Die Währung des Journaleintragsbetrags.
Beschreibung Dieses Attribut gibt die Währung an, in der der Journaleintrag denominiert ist, wie z. B. USD, EUR oder GBP. Es bietet wesentlichen Kontext für den Gesamtbetrag des Journals. Obwohl nicht immer zur Analyse des Prozessflusses selbst verwendet, ist die Währung entscheidend für jede Finanzberichterstattung oder Analyse basierend auf den Journalbeträgen. Sie ermöglicht die korrekte Aggregation und den Vergleich von Werten, insbesondere in multinationalen Organisationen. Bedeutung Bietet den notwendigen Kontext für jede Finanzanalyse und stellt sicher, dass Geldwerte korrekt interpretiert werden, insbesondere in Mehrwährungsumgebungen. Datenquelle Der Währungscode ist typischerweise in der Journallinien-Tabelle, LedgerJournalTrans, verfügbar. Beispiele USDEURGBPJPY

Erforderlich Empfohlen Optional

Record to Report - Journaleintrag Aktivitäten

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem `Event Log` erfassen sollten, um eine präzise `Process Discovery` und Analyse zu ermöglichen.

5 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Buchungsjournaleintrag erstellt	Diese Aktivität markiert die Initiierung eines neuen Journaleintrags. Sie wird erfasst, wenn ein Benutzer einen neuen Journalkopf-Datensatz im System erstellt, wodurch eine eindeutige Journaleintrag-ID festgelegt wird, die als Case-Identifikator für die Prozessanalyse dient.
Bedeutung Dies ist das primäre Start-Ereignis für den Prozess. Die Analyse der Zeit von diesem Punkt bis zur Buchung ist entscheidend zur Messung der End-to-End-Zykluszeit und zur Identifizierung anfänglicher Dateneingabeverzögerungen. Datenquelle Dieses Ereignis wird aus dem Erstellungs-Timestamp des Journalkopfes in der GeneralJournalEntry- oder LedgerJournalTable-Entität erfasst. Es ist typischerweise ein explizites Datensatzerstellungsereignis. Erfassen Verwenden Sie das Feld 'createdDateTime' in GeneralJournalEntry oder LedgerJournalTable. Ereignistyp explicit
	Journal abgelehnt	Der Journaleintrag wurde von einem Prüfer oder Genehmiger abgelehnt und erfordert eine Korrektur. Dieses Ereignis wird durch eine Statusänderung des Journals erfasst, z. B. den Wechsel in den Status 'Rejected' oder 'Needs Correction'.
Bedeutung Die Verfolgung von Ablehnungen ist grundlegend für die Berechnung der Ablehnungsrate und die Identifizierung der Grundursachen für Nacharbeit. Sie zeigt Probleme mit Datenqualität, Compliance oder Benutzerschulung auf. Datenquelle Abgeleitet aus einer Statusfeldänderung (z. B. ApprovalStatus wechselt zu 'Rejected') auf der LedgerJournalTable oder aus dem Workflow-Historienlog. Erfassen Identifizieren Sie den Zeitstempel, zu dem der Journalstatus auf 'Rejected' wechselt. Ereignistyp inferred
	Journal genehmigt	Der Journaleintrag wurde von der zuständigen Instanz genehmigt, wodurch der letzte Schritt im Genehmigungs-Workflow abgeschlossen ist. Dies wird typischerweise durch eine Statusänderung in der Journal-Kopfzeile erfasst, wie z. B. der Wechsel zu 'Approved'.
Bedeutung Dies ist ein kritischer Meilenstein, der den Genehmigungsprozess abschließt und die Buchung ermöglicht. Er ist unerlässlich für die Berechnung der Genehmigungs-Zykluszeit, der Buchungsdurchlaufzeit und der First-Time-Right-Rate. Datenquelle Abgeleitet aus einer Statusfeldänderung (z. B. ApprovalStatus wechselt zu 'Approved') auf der LedgerJournalTable oder aus der Workflow-Historientabelle, die einen finalen Genehmigungsstatus anzeigt. Erfassen Identifizieren Sie den Zeitstempel, zu dem der Journalstatus auf 'Approved' wechselt. Ereignistyp inferred
	Journal zur Genehmigung eingereicht	Stellt die formelle Einreichung eines abgeschlossenen Journaleintrags in einen Prüfungs- und Genehmigungs-Workflow dar. Dies wird typischerweise aus einer Statusänderung in der Journal-Kopfzeile abgeleitet, z. B. von 'Draft' zu 'In Review' oder 'Submitted'.
Bedeutung Dies ist ein wichtiger Meilenstein, der den Genehmigungszyklus initiiert. Die Messung der Zeit von der Einreichung bis zur endgültigen Genehmigung ist entscheidend für die Identifizierung von Engpässen im Prüfungsprozess und die Überwachung der SLA-Compliance. Datenquelle Abgeleitet aus einer Statusfeldänderung (z. B. ApprovalStatus wechselt zu 'InReview') auf der LedgerJournalTable oder aus den Workflow-Historieprotokollen, die mit dem Journal verbunden sind. Erfassen Identifizieren Sie den Zeitstempel, zu dem der Journalstatus in einen 'submitted' oder 'in review' Zustand wechselt. Ereignistyp inferred
	Journalbuchung gebucht	Diese Aktivität markiert die erfolgreiche Buchung des Journaleintrags im Hauptbuch, wodurch er zu einem offiziellen Finanzdatensatz wird. Dies ist ein kritisches Ereignis, das erfasst wird, wenn der Journalkopf-Status auf 'Posted' aktualisiert wird.
Bedeutung Dies ist das primäre erfolgreiche End-Ereignis für den Prozess. Es wird zur Berechnung der End-to-End-Zykluszeit und der Buchungsdurchlaufzeit verwendet, die Schlüsselindikatoren für die Effizienz des Finanzabschlusses sind. Datenquelle Erfasst aus einer Statusfeldänderung (z. B. JournalStatus wechselt zu 'Posted') auf der LedgerJournalTable und der Erstellung entsprechender Einträge in der GeneralJournalAccountEntry Tabelle. Erfassen Identifizieren Sie den Zeitstempel, zu dem der Status des Journals 'Posted' wird. Ereignistyp inferred
	Journal zur Genehmigung erneut eingereicht	Ein korrigierter Journaleintrag wird für einen neuen Prüfzyklus zurück in den Genehmigungs-Workflow gesendet. Dies wird aus einer Statusänderung von „Rejected“ oder „Draft“ zurück zu „In Review“ oder „Submitted“ abgeleitet.
Bedeutung Diese Aktivität markiert den Beginn einer Nacharbeits-Schleife. Das Zählen dieser Ereignisse hilft, die Nacharbeitsquote und die durchschnittliche Anzahl von Genehmigungsschleifen pro Journaleintrag zu quantifizieren. Datenquelle Abgeleitet aus dem Workflow-Verlauf oder durch Verfolgung von Statusänderungen in der LedgerJournalTable, bei denen der Status von einem abgelehnten Zustand zurück in einen eingereichten Zustand wechselt. Erfassen Identifizieren Sie ein 'Submitted'-Statusereignis, das nach einem 'Rejected'-Statusereignis für dasselbe Journal auftritt. Ereignistyp inferred
	Journalbuchung korrigiert	Diese Aktivität zeigt an, dass ein zuvor abgelehnter Journaleintrag von einem Benutzer geändert wurde. Dies wird typischerweise durch das Erkennen einer Änderung an der Journal-Kopfzeile oder ihren Positionen nach dem Status 'Rejected' abgeleitet.
Bedeutung Diese Aktivität identifiziert explizit Nacharbeit. Die Analyse der Häufigkeit und Dauer von Korrekturschleifen hilft, den Prozess zu optimieren und den manuellen Aufwand zu reduzieren. Datenquelle Abgeleitet durch die Verfolgung der Felder 'modifiedDateTime' und 'modifiedBy' in den Tabellen LedgerJournalTable oder LedgerJournalTrans, nachdem ein 'Journal Rejected' Ereignis aufgetreten ist. Erfassen Vergleichen Sie den Zeitstempel eines 'Rejected'-Status mit nachfolgenden Änderungszeitstempeln durch den Ersteller. Ereignistyp inferred
	Journalbuchung storniert	Kennzeichnet den Abschluss des Stornierungsprozesses für Journaleinträge, bei dem eine Stornobuchung erfolgreich verbucht wird. Dies dient als alternativer Endpunkt für den Lebenszyklus eines fehlerhaften Journals.
Bedeutung Diese Aktivität schließt korrigierte Einträge ab und hilft, den gesamten Aufwand für Nachbuchungsanpassungen zu analysieren, was die gesamte Prozesseffizienz beeinflusst. Datenquelle Erfasst, wenn die neue stornierende Journalbuchung selbst in den Status 'Posted' übergeht. Die Verknüpfung zum ursprünglichen Journal wird über ein Referenzfeld aufrechterhalten. Erfassen Identifizieren Sie das 'Posted'-Statusereignis für die zugehörige stornierende Journalbuchung. Ereignistyp inferred
	Journalbuchung versucht	Diese Aktivität bedeutet, dass ein Benutzer den Buchungsprozess für ein genehmigtes Journal initiiert hat. Dies kann explizit erfasst werden, wenn das System den Start des Buchungsauftrags protokolliert.
Bedeutung Die Unterscheidung zwischen dem Versuch der Buchung und der erfolgreichen Buchung kann helfen, Systemleistungsprobleme oder Batchjob-Verzögerungen zu diagnostizieren, die den Finanzabschluss beeinflussen. Datenquelle Dies kann ein explizites Ereignis sein, das in einer Batch-Job-Historientabelle protokolliert wird, oder aus einer Statusänderung zu 'Posting in progress' in der LedgerJournalTable abgeleitet werden. Erfassen Erfordert die Analyse von Batch-Job- oder Systemprotokollen bezüglich der Hauptbuch-Buchungsroutine. Ereignistyp explicit
	Journalprüfung gestartet	Diese Aktivität markiert, wann ein Prüfer aktiv mit der Bearbeitung eines eingereichten Journals beginnt. Sie kann abgeleitet werden, wenn das Journal einem Prüfer zugewiesen wird oder wenn der Prüfer den Datensatz zum ersten Mal zur Prüfung öffnet.
Bedeutung Diese Aktivität hilft, die Übergabezeit an den Prüfer zu messen, d.h. die Verzögerung zwischen Einreichung und Beginn der Prüfung. Sie kann Probleme bei der Ressourcenzuweisung oder Benachrichtigung aufdecken. Datenquelle Dies wird oft nicht explizit protokolliert. Es kann aus Workflow-Zuweisungsprotokollen abgeleitet werden oder erfordert den Vergleich des Einreichungs-Timestamps mit dem ersten Änderungs-Timestamp durch einen Prüfer-Benutzer. Erfassen Erfordert die Analyse von Workflow-Benutzerzuweisungs- oder Benutzeraktivitätsprotokollen, die möglicherweise nicht Standard sind. Ereignistyp inferred
	Journalzeile hinzugefügt	Dieses Ereignis bedeutet, dass eine Soll- oder Habenposition dem Journaleintrag hinzugefügt wurde. Es wird jedes Mal erfasst, wenn eine neue Transaktionsposition erstellt und mit der Journal-Kopfzeile verknüpft wird.
Bedeutung Die Verfolgung der Belegpositionserstellung hilft, die Komplexität und den Datenerfassungsaufwand für verschiedene Journaltypen zu verstehen. Sie kann auch Verzögerungen zwischen der Kopfzeilen-Erstellung und dem Positionen-Abschluss aufzeigen. Datenquelle Erfasst aus dem Erstellungszeitstempel von Datensätzen in der Entität LedgerJournalTrans, zurückverlinkt zum Journal-Header. Jede Zeilenerstellung ist ein diskretes Ereignis. Erfassen Verwenden Sie das Feld 'createdDateTime' für jeden Datensatz in der Tabelle LedgerJournalTrans. Ereignistyp explicit
	Stornierung der Journalbuchung initiiert	Dieses Ereignis stellt den Beginn eines Prozesses zur Stornierung eines zuvor gebuchten Journaleintrags dar. Dies wird erfasst, wenn ein Benutzer die Stornierungsaktion im System initiiert.
Bedeutung Die Verfolgung von Stornierungen hilft, die Häufigkeit und Gründe für die Korrektur gebuchter Einträge zu identifizieren. Dies kann auf zugrunde liegende Probleme in den initialen Dateneingabe- oder Genehmigungsphasen hinweisen. Datenquelle Dies ist typischerweise eine explizite Benutzeraktion, die aus Audit-Trails erfasst oder durch die Identifizierung der Erstellung eines neuen Stornierungsjournals, das mit dem Original verknüpft ist, abgeleitet werden kann. Erfassen Verwenden Sie das Erstellungsereignis eines neuen Journaleintrags, der als Stornierung eines gebuchten Journals gekennzeichnet ist. Ereignistyp explicit

Extraktionsleitfäden

So rufen Sie Ihre Daten aus Microsoft Dynamics 365 ab

Schritte

Zum Datenmanagement-Arbeitsbereich navigieren: Melden Sie sich in Ihrer Microsoft Dynamics 365-Umgebung an. Verwenden Sie die Hauptsuchleiste, um den Arbeitsbereich „Datenmanagement“ zu finden und dorthin zu navigieren.
Neues Exportprojekt erstellen: Wählen Sie im Datenmanagement-Arbeitsbereich die Kachel „Exportieren“, um ein neues Datenexportprojekt zu erstellen. Geben Sie dem Projekt einen aussagekräftigen Namen, z. B. „ProcessMind_JournalEntry_Export“.
Datenformat auswählen: Geben Sie in den Projektdetails das Zieldatenformat an. Für eine einfache Verwendung in späteren Transformationsschritten wählen Sie „CSV“ oder „Excel“.
Erforderliche Datenentitäten hinzufügen: Dies ist der wichtigste Schritt. Sie fügen dem Projekt mehrere Entitäten hinzu, um alle erforderlichen Aktivitäten und Attribute zu erfassen. Klicken Sie für jede Entität auf „Entität hinzufügen“ und suchen Sie nach den folgenden Entitätsnamen. Es wird empfohlen, sie einzeln hinzuzufügen.
- Ledger journal headers: Erfasst Erstellungs-, Buchungs- und Stornierungsereignisse.
- Ledger journal lines: Erfasst das Hinzufügen einzelner Soll-/Habenzeilen.
- Workflow tracking status table: Erfasst alle workflowbezogenen Ereignisse wie Einreichung, Genehmigung und Ablehnung.
Entitätsfilter konfigurieren: Wählen Sie für jede hinzugefügte Entität die Option „Filter“. Wenden Sie Filter an, um den Umfang des Exports zu begrenzen. Filtern Sie mindestens nach „Juristischer Person“ (Unternehmen) und einem bestimmten Datumsbereich auf einem relevanten Datumsfeld, wie z. B. CREATEDDATETIME bei Ledger journal headers, um das Datenvolumen überschaubar zu halten. Exportieren Sie beispielsweise Daten der letzten 3 bis 6 Monate.
Entitätsfelder zuordnen: Überprüfen Sie die Feldzuordnungen für jede Entität. Stellen Sie sicher, dass alle Felder, die für die finalen Attribute benötigt werden, in der Exportdatei enthalten sind. Das System enthält normalerweise standardmäßig alle Felder.
Exportauftrag ausführen: Sobald das Projekt konfiguriert ist, klicken Sie im Aktionsbereich auf „Exportieren“. Das System erstellt ein Datenpaket, das separate Dateien für jede Datenentität enthält.
Exportierte Daten herunterladen: Nachdem der Exportauftrag erfolgreich abgeschlossen wurde, gehen Sie zur Jobhistorie und laden Sie das generierte Datenpaket herunter, das eine Zip-Datei ist.
Daten in ein Event Log umwandeln: Dieser Schritt muss außerhalb von Dynamics 365 mit einem Skript (z. B. Python, PowerShell) oder einem Datenvorbereitungstool durchgeführt werden. Ziel ist es, die Daten aus den mehreren exportierten Dateien zu kombinieren und in eine einzige Event-Log-CSV-Datei zu transformieren. Erstellen Sie für jede Quelldatei Zeilen, die bestimmten Aktivitäten entsprechen. Zum Beispiel:
- Aus der Datei Ledger journal headers erstellen Sie „Journal Entry Created“-Ereignisse mithilfe des Erstellungs-Timestamps und „Journal Entry Posted“-Ereignisse mithilfe des Buchungs-Timestamps.
- Aus der Datei Ledger journal lines erstellen Sie „Journal Line Added“-Ereignisse.
- Aus der Datei Workflow tracking status table verknüpfen Sie sie mit Header-Daten und erstellen Ereignisse für „Journal Submitted For Approval“, „Journal Approved“ und „Journal Rejected“ basierend auf dem Workflow-Status und den Timestamps.
- Leiten Sie Ereignisse wie „Journal Entry Corrected“ ab, indem Sie nach einem geänderten Timestamp nach einem „Journal Rejected“-Ereignis suchen.
Finale CSV-Datei strukturieren: Stellen Sie sicher, dass die final transformierte Datei die erforderlichen Spalten JournalEntryId, ActivityName und EventTime sowie alle empfohlenen Attribute enthält. Die Datei sollte nach JournalEntryId und dann nach EventTime sortiert sein.
Auf ProcessMind hochladen: Das finale, einzelne CSV-Event-Log ist nun bereit, auf die ProcessMind-Plattform zur Analyse hochgeladen zu werden.

Konfiguration

Datenentitäten: Der Kern der Konfiguration ist die Auswahl der korrekten Entitäten. Die primären sind Ledger journal headers, Ledger journal lines und Workflow tracking status table. Je nach Ihrer spezifischen Workflow-Konfiguration benötigen Sie möglicherweise zusätzliche Entitäten.
Exportformat: CSV wird empfohlen, da es ein universelles Format ist, das von Skriptsprachen und Daten-Tools für den erforderlichen Transformationsschritt leicht verarbeitet werden kann.
Filterung: Die Filterung nach juristischer Person (Unternehmen) ist unerlässlich, um den Export von Daten aus irrelevanten Geschäftseinheiten zu vermeiden. Die Anwendung eines Datumsbereichsfilters (z. B. auf CREATEDDATETIME) ist entscheidend für die Verwaltung von Performance und Dateigröße. Ein Bereich von 3-6 Monaten ist typisch für eine erste Analyse.
Inkrementelle Exporte: Für die kontinuierliche Überwachung konfigurieren Sie das Exportprojekt so, dass inkrementelle Exporte durchgeführt werden. Dadurch werden nur Datensätze extrahiert, die sich seit dem letzten Lauf geändert haben, was wesentlich effizienter ist als ein vollständiger Export bei jedem Mal.
Berechtigungen: Das Benutzerkonto, das den Exportauftrag konfiguriert und ausführt, muss die Rolle 'Datenverwaltungsadministrator' oder gleichwertige Berechtigungen besitzen, um auf den Arbeitsbereich 'Datenverwaltung' und die zugrunde liegenden Datenentitäten zugreifen zu können.

a Beispielabfrage config

/*
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.

Schritte

D365-Export zu Azure Data Lake konfigurieren: Stellen Sie vor dem Ausführen von Abfragen sicher, dass die native Microsoft Dynamics 365-Funktion „Export to Azure Data Lake“ konfiguriert und aktiv ist. Wählen Sie die erforderlichen Datenentitäten für den Journalbuchungsprozess aus, mindestens: LedgerJournalTable, LedgerJournalTrans, GeneralJournalEntry, GeneralJournalAccountEntry und WorkflowTrackingStatusTable. Planen Sie Zeit für den Abschluss der anfänglichen Datensynchronisierung ein.
Zu Azure Synapse Analytics navigieren: Öffnen Sie Ihr Azure-Portal und navigieren Sie zum Synapse Analytics-Workspace, der mit dem Azure Data Lake Storage-Konto verbunden ist, das Ihre Dynamics 365-Daten enthält.
Auf die SQL-Datenbank zugreifen: Gehen Sie innerhalb von Synapse Studio zum „Data“-Hub. Suchen Sie die Serverless-SQL-Datenbank, die über Ihren Data Lake-Dateien erstellt wurde. Die D365-Entitäten sind als abfragbare Tabellen oder Ansichten verfügbar.
Neues SQL-Skript erstellen: Öffnen Sie den „Develop“-Hub und erstellen Sie ein neues, leeres SQL-Skript. Hier erstellen Sie die Event-Log-Abfrage.
Abfrage kopieren und anpassen: Kopieren Sie die vollständige SQL-Abfrage, die im Abschnitt „query“ dieses Dokuments bereitgestellt wird, in den neuen Skripteditor in Synapse Studio.
Platzhalter aktualisieren: Überprüfen Sie die Abfrage sorgfältig und ersetzen Sie alle Platzhalterwerte. Sie müssen den Datenbank- und Schemanamen aktualisieren, z. B. [YourD365DB].[dbo], und die gewünschten StartDate- und EndDate-Parameter für Ihren Analysezeitraum festlegen.
Abfrage ausführen: Führen Sie das Skript mithilfe des Serverless-SQL-Pools aus. Die Ausführungszeit variiert je nach Datumsbereich und Datenvolumen in Ihrem System.
Ergebnisse überprüfen: Sobald die Abfrage abgeschlossen ist, zeigt der Ergebnisbereich das generierte Event Log an. Führen Sie eine kurze Überprüfung durch, um sicherzustellen, dass die Spalten (JournalEntryId, ActivityName, EventTime usw.) und Daten korrekt aussehen.
Event Log exportieren: Verwenden Sie die in Ihrem Abfragetool oder Synapse Studio verfügbare Exportfunktion, um den Ergebnissatz als CSV-Datei zu speichern. Klicken Sie mit der rechten Maustaste auf die Ergebnisse und wählen Sie eine Option wie „Save as CSV“.
Für den Upload vorbereiten: Stellen Sie sicher, dass die exportierte CSV-Datei UTF-8-kodiert ist und dass die Spaltenüberschriften den Anforderungen von ProcessMind entsprechen. Eine weitere Datentransformation sollte nicht erforderlich sein.

Konfiguration

Voraussetzungen: Diese Methode erfordert eine funktionierende Integration zwischen Microsoft Dynamics 365 Finance und einem Azure Data Lake Storage Gen2-Konto. Ein Azure Synapse Analytics Workspace muss eingerichtet und konfiguriert sein, um diese Daten abzufragen. Benutzer benötigen entsprechende Leseberechtigungen sowohl in Azure Synapse als auch im Data Lake.
Datenentitäten: Stellen Sie sicher, dass die folgenden D365-Entitäten in den Export zum Data Lake eingeschlossen sind: LedgerJournalTable, LedgerJournalTrans, WorkflowTrackingStatusTable, GeneralJournalEntry und UserInfo.
Datumsbereichsfilterung: Die bereitgestellte Abfrage enthält die Parameter @StartDate und @EndDate. Es wird dringend empfohlen, mit einem begrenzten Datumsbereich von 3 bis 6 Monaten zu beginnen, um die Abfrageleistung und Kosten zu steuern. Analysieren Sie einen repräsentativen Zeitraum der Geschäftsaktivitäten.
Filterung nach juristischer Person: Die Abfrage sollte nach der DataAreaId (juristische Person) gefiltert werden, um die Analyse auf ein bestimmtes Unternehmen zu konzentrieren. Dies ist ein kritischer Filter für die Leistung in großen D365-Umgebungen. Der Platzhalter [YourLegalEntity] sollte ersetzt werden.
Workflow-Konfiguration: Die Logik der Abfrage für Genehmigungs- und Ablehnungsereignisse setzt die Verwendung der Standard-D365-Workflow-Engine voraus, die Daten in der WorkflowTrackingStatusTable protokolliert. Falls Ihre Organisation einen anderen oder benutzerdefinierten Genehmigungsmechanismus verwendet, muss die Abfrage angepasst werden.

a Beispielabfrage 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;

Schritte

Voraussetzungen und Umgebungseinrichtung: Installieren Sie Python 3.x auf Ihrem Rechner. Installieren Sie die erforderlichen Python-Bibliotheken mit pip: pip install pandas requests adal. Die adal-Bibliothek wird für die Azure Active Directory-Authentifizierung verwendet, die für Dynamics 365 erforderlich ist.
Anwendung in Azure AD registrieren: Um auf die Dynamics 365 API zuzugreifen, müssen Sie eine Anwendung in Ihrem Azure Active Directory registrieren. Notieren Sie die Anwendungs- (Client-) ID, die Verzeichnis- (Tenant-) ID und erstellen Sie ein Client-Geheimnis. Erteilen Sie dieser Anwendung delegierte Berechtigungen für den Zugriff auf Dynamics 365 Finance & Operations, wie z. B. Financials.Read.
Python-Skript konfigurieren: Kopieren Sie das bereitgestellte Python-Skript in eine Datei, zum Beispiel extract_journals.py. Füllen Sie die Platzhaltervariablen am Anfang des Skripts mit Ihren Azure AD- und Dynamics 365-Informationen aus: TENANT_ID, CLIENT_ID, CLIENT_SECRET und D365_URL.
Extraktionsparameter festlegen: Passen Sie die Variablen START_DATE und END_DATE im Skript an, um das Zeitfenster für die Datenextraktion zu definieren. Sie können auch die Liste LEGAL_ENTITIES anpassen, um nach spezifischen Firmencodes zu filtern.
Extraktionsskript ausführen: Führen Sie das Skript über Ihre Befehlszeile mit python extract_journals.py aus. Das Skript authentifiziert sich bei Azure AD, ruft ein Zugriffstoken ab und beginnt, die Dynamics 365 OData API nach Journal-Header- und Zeilendaten innerhalb des angegebenen Datumsbereichs abzufragen.
Skriptausführung überwachen: Das Skript gibt Fortschrittsmeldungen in der Konsole aus, während es Datenseiten von der API abruft. Dies kann je nach Datenvolumen eine erhebliche Zeit in Anspruch nehmen. Das Skript handhabt die API-Paginierung automatisch, um alle relevanten Datensätze abzurufen.
Rohdaten überprüfen (Optional): Das Skript speichert die ursprünglich abgefragten Rohdaten zunächst in raw_journal_headers.csv und raw_journal_lines.csv. Sie können diese Dateien überprüfen, um sicherzustellen, dass der anfängliche Datenabzug erfolgreich war, bevor die Transformationslogik angewendet wird.
Ereignis-Ableitung verstehen: Das Skript verarbeitet die Rohdaten, um die 12 erforderlichen Prozessaktivitäten abzuleiten. Zum Beispiel wird „Journal Submitted For Approval“ abgeleitet, wenn sich das Feld WorkflowApprovalStatus von „Draft“ zu „Submitted“ ändert. Der Timestamp für solche Ereignisse wird dem Feld ModifiedDateTime des Datensatzes entnommen.
Finales Ereignisprotokoll generieren: Nach der Verarbeitung kombiniert das Skript alle abgeleiteten Ereignisse zu einem einzigen, strukturierten Ereignisprotokoll. Es erstellt die erforderlichen Spalten: JournalEntryId, ActivityName, EventTime und andere empfohlene Attribute.
CSV-Datei exportieren und überprüfen: Das finale Ereignisprotokoll wird als journal_entry_event_log.csv gespeichert. Öffnen Sie diese Datei, um ihre Struktur und ihren Inhalt zu überprüfen. Stellen Sie sicher, dass sie die erwarteten Spalten enthält und dass Daten für verschiedene Aktivitäten generiert wurden.
Für den ProcessMind-Upload vorbereiten: Die generierte CSV-Datei hat ein geeignetes Format für den Upload. Stellen Sie sicher, dass die Datei mit UTF-8-Kodierung gespeichert wird. Sie können diese Datei nun als Datenquelle in ProcessMind verwenden, um Ihren Record to Report Journal Entry-Prozess zu analysieren.

Konfiguration

API Endpoint URL: Die Basis-URL für Ihre Dynamics 365 Finance & Operations OData API. Diese sollte in der Variablen D365_URL im Skript festgelegt werden, zum Beispiel https://your-org.operations.dynamics.com.
Azure AD Zugangsdaten: Das Skript erfordert eine Azure AD Anwendungsregistrierung. Sie müssen die TENANT_ID, CLIENT_ID und CLIENT_SECRET für die Authentifizierung angeben.
Erforderliche API-Berechtigungen: Die Azure AD Anwendung benötigt delegierte Berechtigungen, um Daten aus Dynamics 365 zu lesen. Die Berechtigung Financials.Read ist typischerweise ausreichend für den Zugriff auf Journaldaten.
Datumsbereich: Die Variablen START_DATE und END_DATE im Skript steuern den Extraktionszeitraum. Für eine erste Analyse wird ein Zeitraum von 3 bis 6 Monaten empfohlen, um Datenvolumen und Prozess-Erkenntnisse auszugleichen.
Filter für juristische Personen: Die Liste LEGAL_ENTITIES im Skript ermöglicht es Ihnen, anzugeben, welche Firmencodes (dataAreaId) in die Extraktion einbezogen werden sollen. Dies ist entscheidend, um die Analyse auf relevante Geschäftsbereiche zu konzentrieren.
Datenentitäten: Das Skript fragt primär die OData-Entitäten LedgerJournalHeaders und LedgerJournalLines ab. Dies sind Standardentitäten für Buchungsjournaldaten in Dynamics 365.
Statusfeldzuordnung: Die Logik des Skripts zur Ableitung von Aktivitäten basiert auf dem Standardfeld WorkflowApprovalStatus. Wenn Ihre Implementierung ein benutzerdefiniertes Feld zur Verfolgung des Journalstatus verwendet, müssen Sie den Feldnamen im Skript aktualisieren.

a Beispielabfrage 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")

Schritte

Zum Datenmanagement-Arbeitsbereich navigieren: Melden Sie sich in Ihrer Microsoft Dynamics 365-Umgebung an. Verwenden Sie die Hauptsuchleiste, um den Arbeitsbereich „Datenmanagement“ zu finden und dorthin zu navigieren.
Neues Exportprojekt erstellen: Wählen Sie im Datenmanagement-Arbeitsbereich die Kachel „Exportieren“, um ein neues Datenexportprojekt zu erstellen. Geben Sie dem Projekt einen aussagekräftigen Namen, z. B. „ProcessMind_JournalEntry_Export“.
Datenformat auswählen: Geben Sie in den Projektdetails das Zieldatenformat an. Für eine einfache Verwendung in späteren Transformationsschritten wählen Sie „CSV“ oder „Excel“.
Erforderliche Datenentitäten hinzufügen: Dies ist der wichtigste Schritt. Sie fügen dem Projekt mehrere Entitäten hinzu, um alle erforderlichen Aktivitäten und Attribute zu erfassen. Klicken Sie für jede Entität auf „Entität hinzufügen“ und suchen Sie nach den folgenden Entitätsnamen. Es wird empfohlen, sie einzeln hinzuzufügen.
- Ledger journal headers: Erfasst Erstellungs-, Buchungs- und Stornierungsereignisse.
- Ledger journal lines: Erfasst das Hinzufügen einzelner Soll-/Habenzeilen.
- Workflow tracking status table: Erfasst alle workflowbezogenen Ereignisse wie Einreichung, Genehmigung und Ablehnung.
Entitätsfilter konfigurieren: Wählen Sie für jede hinzugefügte Entität die Option „Filter“. Wenden Sie Filter an, um den Umfang des Exports zu begrenzen. Filtern Sie mindestens nach „Juristischer Person“ (Unternehmen) und einem bestimmten Datumsbereich auf einem relevanten Datumsfeld, wie z. B. CREATEDDATETIME bei Ledger journal headers, um das Datenvolumen überschaubar zu halten. Exportieren Sie beispielsweise Daten der letzten 3 bis 6 Monate.
Entitätsfelder zuordnen: Überprüfen Sie die Feldzuordnungen für jede Entität. Stellen Sie sicher, dass alle Felder, die für die finalen Attribute benötigt werden, in der Exportdatei enthalten sind. Das System enthält normalerweise standardmäßig alle Felder.
Exportauftrag ausführen: Sobald das Projekt konfiguriert ist, klicken Sie im Aktionsbereich auf „Exportieren“. Das System erstellt ein Datenpaket, das separate Dateien für jede Datenentität enthält.
Exportierte Daten herunterladen: Nachdem der Exportauftrag erfolgreich abgeschlossen wurde, gehen Sie zur Jobhistorie und laden Sie das generierte Datenpaket herunter, das eine Zip-Datei ist.
Daten in ein Event Log umwandeln: Dieser Schritt muss außerhalb von Dynamics 365 mit einem Skript (z. B. Python, PowerShell) oder einem Datenvorbereitungstool durchgeführt werden. Ziel ist es, die Daten aus den mehreren exportierten Dateien zu kombinieren und in eine einzige Event-Log-CSV-Datei zu transformieren. Erstellen Sie für jede Quelldatei Zeilen, die bestimmten Aktivitäten entsprechen. Zum Beispiel:
- Aus der Datei Ledger journal headers erstellen Sie „Journal Entry Created“-Ereignisse mithilfe des Erstellungs-Timestamps und „Journal Entry Posted“-Ereignisse mithilfe des Buchungs-Timestamps.
- Aus der Datei Ledger journal lines erstellen Sie „Journal Line Added“-Ereignisse.
- Aus der Datei Workflow tracking status table verknüpfen Sie sie mit Header-Daten und erstellen Ereignisse für „Journal Submitted For Approval“, „Journal Approved“ und „Journal Rejected“ basierend auf dem Workflow-Status und den Timestamps.
- Leiten Sie Ereignisse wie „Journal Entry Corrected“ ab, indem Sie nach einem geänderten Timestamp nach einem „Journal Rejected“-Ereignis suchen.
Finale CSV-Datei strukturieren: Stellen Sie sicher, dass die final transformierte Datei die erforderlichen Spalten JournalEntryId, ActivityName und EventTime sowie alle empfohlenen Attribute enthält. Die Datei sollte nach JournalEntryId und dann nach EventTime sortiert sein.
Auf ProcessMind hochladen: Das finale, einzelne CSV-Event-Log ist nun bereit, auf die ProcessMind-Plattform zur Analyse hochgeladen zu werden.

Konfiguration

Datenentitäten: Der Kern der Konfiguration ist die Auswahl der korrekten Entitäten. Die primären sind Ledger journal headers, Ledger journal lines und Workflow tracking status table. Je nach Ihrer spezifischen Workflow-Konfiguration benötigen Sie möglicherweise zusätzliche Entitäten.
Exportformat: CSV wird empfohlen, da es ein universelles Format ist, das von Skriptsprachen und Daten-Tools für den erforderlichen Transformationsschritt leicht verarbeitet werden kann.
Filterung: Die Filterung nach juristischer Person (Unternehmen) ist unerlässlich, um den Export von Daten aus irrelevanten Geschäftseinheiten zu vermeiden. Die Anwendung eines Datumsbereichsfilters (z. B. auf CREATEDDATETIME) ist entscheidend für die Verwaltung von Performance und Dateigröße. Ein Bereich von 3-6 Monaten ist typisch für eine erste Analyse.
Inkrementelle Exporte: Für die kontinuierliche Überwachung konfigurieren Sie das Exportprojekt so, dass inkrementelle Exporte durchgeführt werden. Dadurch werden nur Datensätze extrahiert, die sich seit dem letzten Lauf geändert haben, was wesentlich effizienter ist als ein vollständiger Export bei jedem Mal.
Berechtigungen: Das Benutzerkonto, das den Exportauftrag konfiguriert und ausführt, muss die Rolle 'Datenverwaltungsadministrator' oder gleichwertige Berechtigungen besitzen, um auf den Arbeitsbereich 'Datenverwaltung' und die zugrunde liegenden Datenentitäten zugreifen zu können.

a Beispielabfrage config

/*
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.

Ihre Record to Report - Journaleintrag Datenvorlage

Ihre Record to Report - Journaleintrag Datenvorlage

Record to Report - Journaleintrag Attribute

Record to Report - Journaleintrag Aktivitäten

Extraktionsleitfäden

Microsoft Dynamics 365 Data Management Framework Export

Schritte

Konfiguration

a Beispielabfrage config

Azure Data Lake Abfrage über Synapse für Dynamics 365

Schritte

Konfiguration

a Beispielabfrage sql

Python Skript-Extraktion via Dynamics 365 OData API

Schritte

Konfiguration

a Beispielabfrage python

Power Platform Dataflows Extraktion aus Dynamics 365

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

Journalbuchungen in Dynamics 365 optimieren, jetzt schneller berichten

Ihre Record to Report - Journaleintrag Datenvorlage

Ihre Record to Report - Journaleintrag Datenvorlage

Record to Report - Journaleintrag Attribute

Record to Report - Journaleintrag Aktivitäten

Extraktionsleitfäden

Microsoft Dynamics 365 Data Management Framework Export

Schritte

Konfiguration

a Beispielabfrage config

Azure Data Lake Abfrage über Synapse für Dynamics 365

Schritte

Konfiguration

a Beispielabfrage sql

Python Skript-Extraktion via Dynamics 365 OData API

Schritte

Konfiguration

a Beispielabfrage python

Power Platform Dataflows Extraktion aus Dynamics 365

Schritte

Konfiguration

a Beispielabfrage config

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Journalbuchungen in Dynamics 365 optimieren, jetzt schneller berichten