> Kontinuierliche Prozessverbesserung > Purchase to Pay Anforderung > Microsoft Dynamics 365 > Daten Template

Ihr Daten-Template für den Purchase-to-Pay-Prozess bei Bestellanforderungen

Microsoft Dynamics 365

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für den Purchase-to-Pay-Prozess bei Bestellanforderungen(17) Aktivitäten im Purchase-to-Pay-Prozess für Bestellanforderungen(12) Anleitungen zur Datenextraktion(3)

Ihr Daten-Template für den Purchase-to-Pay-Prozess bei Bestellanforderungen

Dieses Template beschreibt die wichtigsten Attribute, die Sie erfassen sollten, und die zentralen Aktivitäten, die Sie verfolgen sollten. So können Sie Ihren Prozess für Bestellanforderungen detailliert analysieren. Außerdem enthält es praktische Hinweise zur Datenextraktion, damit Sie Ihr Event Log effizient für eine eingehende Analyse vorbereiten können.

Empfohlene Attribute für die Datenerfassung
Wichtige Aktivitäten für die Nachverfolgung
Hinweise zur Datenextraktion

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute für den Purchase-to-Pay-Prozess bei Bestellanforderungen

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren Purchase-to-Pay-Prozess für Bestellanforderungen umfassend zu analysieren.

5 Erforderlich 6 Empfohlen 6 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des konkreten Geschäftsereignisses oder Prozessschritts im Anforderungsprozess.
Beschreibung Dieses Attribut erfasst den Namen jeder Aktivität im Lebenszyklus einer Bestellanforderung. Beispiele sind 'Anforderung erstellt', 'Genehmigungsschritt genehmigt' und 'Bestellung erstellt'. Diese Aktivitäten bilden die Knoten in der ermittelten Prozesslandkarte. Die Abfolge, Häufigkeit und Dauer der Aktivitäten zu analysieren, ist der Kern des Process Mining. So lassen sich Engpässe, Schleifen mit Nacharbeit und Abweichungen vom Standardprozess erkennen. Die Erkenntnisse zeigen Ineffizienzen im Betrieb auf. Warum das wichtig ist Dieses Attribut legt die Schritte in der Prozesslandkarte fest und ermöglicht es, den Anforderungsworkflow zu visualisieren, zu analysieren und nachzuvollziehen. Woher beziehen In der Regel wird dieses Attribut aus Protokollen zu Statusänderungen, Workflow-Verlaufstabellen oder spezifischen Ereignistabellen in Microsoft Dynamics 365 abgeleitet, zum Beispiel aus der WorkflowTrackingStatusTable. Beispiele Anforderung zur Genehmigung eingereichtGenehmigungsschritt genehmigtAnforderung geändert
	Ereigniszeitpunkt EventTime	Der genaue Timestamp, zu dem eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Der Ereigniszeitpunkt, also der Timestamp, gibt Datum und Uhrzeit an, zu denen ein Geschäftsereignis im System erfasst wurde. Er bildet die zeitliche Grundlage für alle zeitbezogenen Prozessanalysen. Dieses Attribut ist entscheidend für die Berechnung von Zykluszeiten, Dauern und Wartezeiten zwischen Aktivitäten. Es ermöglicht die Analyse der Prozessleistung, das Erkennen von Engpässen und die Überwachung der SLA-Einhaltung. Genaue Timestamps sind Voraussetzung für eine verlässliche Process-Mining-Analyse. Warum das wichtig ist Das Attribut gibt die chronologische Reihenfolge der Ereignisse an. Diese ist erforderlich, um Prozessdauern zu berechnen, Engpässe zu erkennen und die Leistung im Zeitverlauf zu analysieren. Woher beziehen Zu finden in Workflow-Verlaufs- oder Dokumentprotokolltabellen, häufig als Feld 'CreatedDateTime' oder 'ModifiedDateTime' zu jeder Statusänderung oder jedem Ereignisdatensatz. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
	Purchase Requisition ID PurchaseRequisitionId	Der eindeutige Bezeichner einer Bestellanforderung, der als primäre Case-ID dient.
Beschreibung Die Purchase Requisition ID ist der zentrale Schlüssel, der alle Aktivitäten zu einer einzelnen Anforderung von Waren oder Dienstleistungen miteinander verknüpft. Der gesamte Anforderungsprozess, von der Erstellung bis zur endgültigen Genehmigung und zum Abschluss, wird unter dieser eindeutigen ID erfasst. Beim Process Mining ist dieses Attribut grundlegend, um den durchgängigen Ablauf jeder Anforderung zu rekonstruieren. Es ermöglicht die Analyse von Prozessvarianten, Zykluszeiten und Compliance für einzelne Cases und liefert einen vollständigen Überblick über den Lebenszyklus der Anforderungen. Warum das wichtig ist Damit lassen sich alle zugehörigen Ereignisse zu einer einzelnen Prozessinstanz zusammenfassen und der Lebenszyklus jeder Anforderung vollständig und durchgängig analysieren. Woher beziehen In der Regel ist dies der Primärschlüssel in der Haupttabelle mit den Köpfen der Bestellanforderungen, zum Beispiel in der PurchReqTable von Microsoft Dynamics 365. Beispiele Bestellanforderung-001254Bestellanforderung-001255Bestellanforderung-001256
	Letzte Datenaktualisierung LastDataIngestionTimestamp	Der Timestamp, zu dem die Daten zuletzt exportiert und in das Process-Mining-Werkzeug geladen wurden.
Beschreibung Dieses Attribut gibt an, wie aktuell die analysierten Daten sind. Es zeigt Datum und Uhrzeit der letzten Datenaktualisierung aus dem Quellsystem. Das Feld stammt nicht aus Dynamics 365 selbst, sondern wird bei der Datenübernahme als Metadatum hinzugefügt. Anhand dieses Timestamps können Benutzer die Aktualität der Erkenntnisse einschätzen. Sie sehen, ob sie Echtzeitdaten oder einen Datenstand von einem bestimmten Zeitpunkt betrachten. Das beeinflusst, wie relevant ihre Schlussfolgerungen sind. Warum das wichtig ist Das Attribut informiert Benutzer über die Aktualität der Daten. So können sie den Zeitraum der Analyse und die Relevanz der Erkenntnisse besser einschätzen. Woher beziehen Dieser Wert wird bei der Datenübernahme oder im ETL-Prozess erzeugt und an den Datensatz angehängt. Beispiele 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Quellsystem SourceSystemId	Das führende System, aus dem die Daten exportiert wurden.
Beschreibung Dieses Attribut gibt an, aus welchem Quellsystem die Ereignisdaten stammen. In diesem Fall wäre der Wert 'Microsoft Dynamics 365'. In Umgebungen mit mehreren integrierten Systemen ist das Feld wichtig, um die Datenherkunft und den Kontext nachzuvollziehen. Bei der Analyse hilft es, Prozesse zu unterscheiden, die sich über mehrere Systeme erstrecken, oder zu bestätigen, dass die Daten aus einer einzigen maßgeblichen Quelle stammen. Das ist wichtig für die Datenvalidierung und stellt sicher, dass die Analyse auf dem richtigen Datensatz basiert. Warum das wichtig ist Das Attribut gibt Aufschluss über die Herkunft der Daten. Das ist wichtig für Data Governance und Validierung sowie für Umgebungen, in denen mehrere Systeme integriert sind. Woher beziehen Dies ist ein statischer Wert, 'Microsoft Dynamics 365', der beim Export und bei der Transformation der Daten hinzugefügt wird. Beispiele Microsoft Dynamics 365 F&OD365MSD365
	Abteilung Department	Die Abteilung der anfordernden Person oder die der Anforderung zugeordnete Kostenstelle.
Beschreibung Dieses Attribut gibt die Fachabteilung oder Kostenstelle an, von der die Bestellanforderung ausgeht, zum Beispiel 'Marketing', 'IT' oder 'Betrieb'. Diese Information ist üblicherweise im Anforderungskopf enthalten. Die Aufschlüsselung des Prozesses nach Abteilung ist für Vergleichsanalysen wichtig. So sehen Sie, welche Abteilungen die längsten Zykluszeiten, die höchsten Ablehnungsquoten oder die meisten Änderungen aufweisen. Diese Erkenntnisse helfen, Verbesserungen gezielt auf den Bedarf einzelner Abteilungen auszurichten. Warum das wichtig ist Damit können Sie die Prozessleistung verschiedener Geschäftseinheiten filtern und vergleichen. So werden abteilungsspezifische Muster, Engpässe und Ineffizienzen sichtbar. Woher beziehen Diese Informationen sind häufig im Kopf der Bestellanforderung (PurchReqTable) gespeichert und mit der Konfiguration der Finanzdimensionen in Dynamics 365 verknüpft. Beispiele IT-AbteilungFinanzenBetrieb
	Benutzer User	Die Benutzer-ID oder der Name der Person, die die Aktivität ausgeführt hat.
Beschreibung Dieses Attribut gibt an, welcher Mitarbeitende oder Systembenutzer für einen bestimmten Prozessschritt verantwortlich war, etwa für das Einreichen einer Anforderung oder die Genehmigung eines Antrags. Als Wert kann eine Benutzer-ID, ein vollständiger Name oder eine E-Mail-Adresse dienen. Die Analyse nach Benutzern hilft, Schulungsbedarf, besonders leistungsstarke Personen oder Teams und die Verteilung der Arbeitslast zu erkennen. Sie ist auch für Compliance-Analysen wichtig, etwa zur Funktionstrennung, und zeigt, wie unterschiedliche Benutzerrollen mit dem Prozess interagieren. Warum das wichtig ist Das Attribut ermöglicht die Analyse des benutzerspezifischen Verhaltens, der Arbeitslast und der Leistung. Das ist wichtig für das Ressourcenmanagement und hilft, Schulungsbedarf zu erkennen. Woher beziehen In der Regel zu finden in Workflow-Verlaufstabellen, zum Beispiel der WorkflowTrackingStatusTable, oder in Transaktionstabellen wie der PurchReqTable, die mit einer Benutzertabelle wie UserInfo verknüpft sind. Beispiele j.smitha.joness.patel
	Dringlichkeitsstufe UrgencyLevel	Einstufung der Dringlichkeit einer Bestellanforderung, zum Beispiel „Hoch“, „Mittel“ oder „Niedrig“.
Beschreibung Die Dringlichkeitsstufe oder Priorität gibt an, wie schnell die angeforderten Waren oder Dienstleistungen benötigt werden. Dieses Attribut beeinflusst häufig den Freigabeweg oder die Priorisierung der Aufgaben für die Freigebenden. Die Analyse zeigt, ob das Prioritätssystem wirksam ist. Vergleichen Sie zum Beispiel die Zykluszeiten von dringenden und weniger dringenden Bestellanforderungen. Gibt es keinen nennenswerten Unterschied, wird das Prioritätsfeld möglicherweise ignoriert oder falsch verwendet. Das ist eine wichtige Erkenntnis für das Dashboard „Auswirkungen der Dringlichkeitsstufe“. Warum das wichtig ist Damit lässt sich prüfen, ob Prioritätseinstellungen dringende Anforderungen tatsächlich beschleunigen. Außerdem werden mögliche Fehlverwendungen der Dringlichkeitseinstufung sichtbar. Woher beziehen Dies kann ein Standard- oder benutzerdefiniertes Feld in PurchReqTable sein. Ob es vorhanden ist und wie es heißt, hängt von der Systemkonfiguration ab. Beispiele HochMittelNiedrig
	Freigabeschritt ApprovalStep	Name oder Phase eines bestimmten Freigabeschritts im Workflow.
Beschreibung Dieses Attribut bezeichnet eine bestimmte Phase im Freigabe-Workflow, zum Beispiel „Freigabe durch die Führungskraft“ oder „Freigabe durch die Finanzabteilung“. Es liefert genauere Informationen als der allgemeine Aktivitätsname. Das Attribut ist für die „Engpassanalyse der Freigabeschritte“ wichtig. Wenn Sie die Dauer jedes einzelnen Freigabeschritts erfassen, können Sie genau feststellen, welche Phasen den Gesamtprozess verzögern. So lassen sich gezielte Maßnahmen zur Verbesserung der Workflow-Effizienz ergreifen. Warum das wichtig ist Das Attribut ermöglicht eine detaillierte Analyse des Freigabe-Workflows und zeigt, in welchen Phasen Engpässe entstehen. Woher beziehen Diese Informationen stehen in den Workflow-Verlaufstabellen, zum Beispiel WorkflowTrackingStatusTable. Dort ist jeder Schritt des konfigurierten Workflows aufgeführt. Beispiele Freigabe durch die FührungskraftFreigabe durch die AbteilungsleitungPrüfung durch die Finanzabteilung
	Gesamtbetrag der Bestellanforderung RequisitionTotalAmount	Der Gesamtwert der Bestellanforderung.
Beschreibung Dieses Attribut erfasst den Gesamtwert aller Positionen einer Bestellanforderung. Der Betrag beeinflusst häufig den Umfang des Freigabe-Workflows: Bei höheren Beträgen sind in der Regel mehr Freigabeschritte erforderlich. Für die Prozessanalyse ist dieses Attribut wichtig, um nach Wert zu filtern und auszuwerten. Damit lässt sich beispielsweise untersuchen, ob Bestellanforderungen mit hohem Wert länger bis zur Freigabe brauchen oder welchen Wert die Anforderungen haben, die derzeit im Prozess feststecken. So lässt sich die Prozessleistung finanziell einordnen. Warum das wichtig ist Das Attribut ergänzt die Analyse um eine finanzielle Dimension. So können Sie Cases mit hohem Wert priorisieren und nachvollziehen, wie sich der Betrag auf den Prozessverlauf auswirkt. Woher beziehen Der Wert steht üblicherweise in der Kopftabelle der Bestellanforderung oder wird als Summe der Positionsbeträge aus der Positionstabelle der Bestellanforderung (PurchReqLine) berechnet. Beispiele 1500.0025000.50500.75
	Status der Bestellanforderung RequisitionStatus	Der aktuelle oder endgültige Status der Bestellanforderung.
Beschreibung Dieses Attribut gibt den Gesamtstatus der Bestellanforderung zu einem bestimmten Zeitpunkt an, zum Beispiel „In Prüfung“, „Genehmigt“, „Abgelehnt“ oder „Geschlossen“. Häufig handelt es sich um ein Case-Attribut, das das endgültige Ergebnis abbildet. Die Analyse des endgültigen Status zeigt, wie der Prozess insgesamt ausgeht. Eine hohe Zahl abgelehnter oder zurückgezogener Bestellanforderungen kann beispielsweise auf Probleme bei der ursprünglichen Anforderung oder auf einen umständlichen Freigabeprozess hindeuten. Der Status ist entscheidend, um Erfolgsquoten und Prozesseffizienz zu messen. Warum das wichtig ist Das Attribut zeigt für jeden Case ein eindeutiges Ergebnis und ermöglicht die Analyse von Freigabe-, Ablehnungs- und Rückzugsquoten, die wichtige Leistungskennzahlen sind. Woher beziehen Das Statusfeld befindet sich üblicherweise in der Kopftabelle der Bestellanforderung, PurchReqTable, und heißt häufig „Status“ oder „PurchReqStatus“. Beispiele GenehmigtIn PrüfungAbgelehntEntwurf
	Anzahl der Änderungen AmendmentCount	Gesamtzahl der Änderungen an einer Bestellanforderung.
Beschreibung Dieses berechnete numerische Attribut zählt, wie oft die Aktivität „Bestellanforderung geändert“ für jeden Case einer Bestellanforderung auftritt. Das Attribut ist wichtig für das Dashboard „Häufigkeit von Änderungen an Bestellanforderungen“ und die KPI „Änderungsquote von Bestellanforderungen“. Es beziffert die Nacharbeit pro Case und zeigt, bei welchen Bestellanforderungen, Abteilungen oder Benutzern besonders viele Änderungen und Ineffizienzen auftreten. So können Sie gezielt die Qualität der ursprünglichen Anforderungen verbessern. Warum das wichtig ist Das Attribut beziffert die Nacharbeit innerhalb eines Cases. So lassen sich Häufigkeit und Auswirkungen von Änderungen auf die Prozesseffizienz einfach messen und analysieren. Woher beziehen Dieses Attribut wird berechnet. Bei der Datentransformation wird es ermittelt, indem die Aktivitäten „Bestellanforderung geändert“ für jede eindeutige PurchaseRequisitionId gezählt werden. Beispiele 013
	Bestellnummer PurchaseOrderNumber	Kennung der aus der Bestellanforderung erstellten Bestellung.
Beschreibung Dieses Attribut speichert die eindeutige ID der Bestellung, die aus einer genehmigten Bestellanforderung erstellt wurde. Es verknüpft den Anforderungsprozess mit dem nachgelagerten Beschaffungsprozess. Die Erfassung dieser Nummer ist wichtig, um die „Umwandlungszeit von Bestellanforderung zu Bestellung“ zu analysieren. Sie bestätigt, dass eine Bestellanforderung die nächste Phase des Purchase-to-Pay-Zyklus erreicht hat, und ermöglicht eine durchgängige Prozessanalyse über Bestellanforderungen und Bestellungen hinweg. Warum das wichtig ist Das Attribut verknüpft die Bestellanforderung mit der anschließenden Bestellung. So lassen sich die Umwandlung von der Bestellanforderung zur Bestellung analysieren und verschiedene Phasen des P2P-Prozesses miteinander verbinden. Woher beziehen Diese Informationen stehen nach Erstellung einer Bestellung in der Positionstabelle der Bestellanforderung (PurchReqLine), die auf PurchTable verweist. Beispiele PO-000987PO-000988PO-000989
	Freigabe-Workflow-Pfad ApprovalWorkflowPath	Abbildung der Abfolge durchlaufener Freigabeschritte.
Beschreibung Dieses abgeleitete Feld fasst die Abfolge der Freigabeschritte für eine Bestellanforderung zusammen, zum Beispiel „Freigabe durch die Führungskraft -> Freigabe durch die Abteilungsleitung -> Freigabe durch die Finanzabteilung“. Damit wird die Prozessvariante des Freigabe-Teilprozesses zusammengefasst. Das ist für das Dashboard „Überwachung von Compliance-Abweichungen“ entscheidend. Vergleichen Sie den tatsächlichen Workflow-Pfad mit einem festgelegten Standard oder dem erwarteten Ablauf, lassen sich nicht konforme oder ungewöhnliche Prozessverläufe leicht erkennen. Sie können auf Verstöße gegen Richtlinien oder betriebliche Risiken hindeuten. Warum das wichtig ist Das Attribut vereinfacht die Compliance-Analyse: Die Prozessvariante wird als klar lesbare Zeichenfolge dargestellt, sodass Abweichungen von Standardverfahren leicht erkennbar sind. Woher beziehen Dieses Attribut ist kein Standardfeld. Es muss bei der Datentransformation aus den Werten von „ApprovalStep“ gebildet werden, die für jeden Case chronologisch aneinandergereiht werden. Beispiele Führungskraft -> GeschäftsleitungFührungskraft -> Geschäftsleitung -> FinanzvorstandFührungskraft -> Automatisch genehmigt
	Freigabegruppe ApproverGroup	Benutzergruppe oder Rolle, die für einen Freigabeschritt zuständig ist.
Beschreibung Dieses Attribut bezeichnet die Gruppe, Rolle oder Warteschlange, die eine bestimmte Freigabeaufgabe bearbeitet, zum Beispiel „Freigebende der Finanzabteilung“ oder „IT-Leiter“. Die Analyse der Prozessleistung nach Freigabegruppe zeigt, wie die Arbeitslast verteilt ist und welche Gruppen möglicherweise zu wenig Ressourcen haben oder zusätzliche Schulungen benötigen. Das Attribut unterstützt direkt das Dashboard „Engpassanalyse der Freigabeschritte“, da sich die Leistung nach den für Freigaben zuständigen Teams aufschlüsseln lässt. Warum das wichtig ist Damit lassen sich Leistungsunterschiede zwischen Freigabeteams erkennen und mögliche Ressourcenengpässe oder Schulungsbedarfe in einzelnen Gruppen aufzeigen. Woher beziehen Diese Informationen sind im Workflow-Verlauf enthalten, zum Beispiel in WorkflowTrackingStatusTable. Dort wird für jede Aufgabe der zugewiesene Benutzer oder die Benutzergruppe erfasst. Beispiele Freigebende der FinanzabteilungIT-LeiterGeschäftsleitung
	Im ersten Durchlauf genehmigt IsFirstPass	Kennzeichen dafür, ob eine Bestellanforderung ohne vorherige Änderungen oder Ablehnungen genehmigt wurde.
Beschreibung Dieses berechnete boolesche Attribut ist „true“, wenn der Weg zur Genehmigung keine Aktivitäten wie „Bestellanforderung geändert“ oder „Freigabeschritt abgelehnt“ enthält. Andernfalls ist der Wert „false“. Das Attribut unterstützt direkt die KPI „Erstfreigabequote von Bestellanforderungen“. Es vereinfacht die Analyse der Prozesseffizienz, indem es Nacharbeit auf Case-Ebene eindeutig kennzeichnet. Eine niedrige Erstfreigabequote weist auf Probleme mit der Datenqualität der ursprünglichen Anforderung oder auf unklare Anforderungen hin. Das zeigt Möglichkeiten zur Prozessverbesserung auf. Warum das wichtig ist Das Attribut misst Prozessqualität und Effizienz direkt, indem es Cases mit Nacharbeit kennzeichnet. So unterstützt es KPIs zur Quote der beim ersten Mal korrekt abgeschlossenen Vorgänge. Woher beziehen Dieses Attribut wird berechnet. Bei der Datentransformation muss die vollständige Aktivitätsfolge jedes Cases darauf geprüft werden, ob vor der Genehmigung Nacharbeitsaktivitäten aufgetreten sind. Beispiele truefalse
	Währung Currency	Der Währungscode des Betrags der Bestellanforderung.
Beschreibung Dieses Attribut gibt an, in welcher Währung, zum Beispiel USD, EUR oder GBP, der Gesamtbetrag der Bestellanforderung ausgewiesen ist. Das ist besonders für die Finanzanalyse in multinationalen Unternehmen mit mehreren Währungen wichtig. Mit dem Währungsattribut lassen sich Finanzdaten korrekt verarbeiten und aggregieren. Es stellt sicher, dass Geldbeträge richtig interpretiert werden, und ermöglicht die Umrechnung in eine gemeinsame Währung. So können Sie Berichte erstellen und Regionen oder Geschäftseinheiten zuverlässig vergleichen. Warum das wichtig ist Das Attribut liefert den nötigen Kontext für Finanzattribute und ermöglicht die korrekte Interpretation und Aggregation von Geldbeträgen in Umgebungen mit mehreren Währungen. Woher beziehen Dieses Feld befindet sich üblicherweise in der Kopftabelle der Bestellanforderung, PurchReqTable, neben den Betragsfeldern. Beispiele USDEURGBP

Erforderlich Empfohlen Optional

Aktivitäten im Purchase-to-Pay-Prozess für Bestellanforderungen

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, damit Sie Ihren Workflow für Bestellanforderungen zuverlässig entdecken und analysieren können.

7 Empfohlen 5 Optional

	Aktivität	Beschreibung
	Anforderung abgelehnt	Die Anforderung wurde im Genehmigungsworkflow abgelehnt und wird nicht weiterbearbeitet. Damit befindet sie sich in einem endgültigen Fehlerzustand.
Warum das wichtig ist Dieses Endereignis ist wichtig, um die Gesamtablehnungsquote zu analysieren und die finanziellen oder operativen Auswirkungen abgelehnter Anforderungen zu verstehen. Woher beziehen Wird beim Abschluss des Workflows mit dem Status 'Rejected' explizit aus der 'WorkflowTrackingStatusTable' erfasst. Dabei wird das Statusfeld in der 'PurchReqTable' aktualisiert. Erfassung Filtern Sie nach Workflow-Ereignissen vom Typ 'Completion' mit dem Status 'Rejected' oder verfolgen Sie die Statusänderung in der PurchReqTable. Ereignistyp explicit
	Anforderung abgeschlossen	Die gesamte Bestellanforderung gilt als abgeschlossen, wenn alle Positionen in Bestellungen umgewandelt oder storniert wurden. Damit ist ein erfolgreicher Endzustand erreicht.
Warum das wichtig ist Diese Aktivität markiert den erfolgreichen Abschluss des Lebenszyklus der Anforderung. Sie bildet den Endpunkt für die Messung der gesamten Prozessdauer. Woher beziehen Dieser Status wird in der Regel berechnet oder abgeleitet. Er tritt ein, wenn alle zugehörigen Datensätze in 'PurchReqLine' einen Endstatus erreicht haben, zum Beispiel 'Closed' oder 'Cancelled'. Erfassung Leiten Sie dieses Ereignis ab, indem Sie prüfen, ob alle untergeordneten PurchReqLine-Datensätze einer PurchReqTable einen Endstatus haben. Ereignistyp calculated
	Anforderung erstellt	Dieses Ereignis kennzeichnet die erstmalige Erstellung des Datensatzes einer Bestellanforderung im Entwurfsstatus. Es wird anhand des Erstellungs-Timestamps des Anforderungskopfs erfasst.
Warum das wichtig ist Als Start des Prozesses ist diese Aktivität wichtig, um die Gesamtdauer des Anforderungsprozesses und die Zahl der täglich bearbeiteten Anforderungen zu messen. Woher beziehen Diese Aktivität wird für jede neue Purchase Requisition ID aus dem Feld 'createdDateTime' in der Tabelle 'PurchReqTable' abgeleitet. Erfassung Verwenden Sie den Erstellungs-Timestamp des Datensatzes in der PurchReqTable. Ereignistyp inferred
	Anforderung genehmigt	Die Anforderung hat alle erforderlichen Genehmigungsschritte im Workflow erfolgreich durchlaufen. Diese Aktivität wird erfasst, wenn die Workflowinstanz mit dem endgültigen Status 'Approved' abgeschlossen wird.
Warum das wichtig ist Dieser wichtige Meilenstein markiert das Ende des Genehmigungszyklus und den Beginn der Beschaffungsphase. Er ist das Endereignis für die KPI 'Genehmigungszykluszeit für Anforderungen'. Woher beziehen Wird beim Abschluss des Workflows explizit aus der 'WorkflowTrackingStatusTable' erfasst. Gleichzeitig wird das Feld 'Status' in der 'PurchReqTable' auf 'Approved' gesetzt. Erfassung Filtern Sie nach Workflow-Ereignissen vom Typ 'Completion' mit dem Status 'Approved' oder verfolgen Sie die Statusänderung in der PurchReqTable. Ereignistyp explicit
	Anforderung zur Genehmigung eingereicht	Der Benutzer reicht die ausgefüllte Anforderung ein und startet damit den formellen Genehmigungsworkflow. Die Aktion wird explizit von der Workflow-Engine des Systems protokolliert.
Warum das wichtig ist Diese Aktivität ist ein wichtiger Meilenstein, denn sie markiert den Beginn des Genehmigungszyklus. Sie bildet die Grundlage für die Messung der 'Genehmigungszykluszeit für Anforderungen' und der 'Erstgenehmigungsquote'. Woher beziehen Erfasst in der 'WorkflowTrackingStatusTable' oder einer vergleichbaren Workflow-Verlaufstabelle, in der ein Ereignis vom Typ 'Submission' für die Bestellanforderung protokolliert wird. Erfassung Filtern Sie die Workflow-Verlaufsprotokolle nach Ereignissen vom Typ 'Submission' oder 'Start', die der Anforderung zugeordnet sind. Ereignistyp explicit
	Bestellung erstellt	Eine genehmigte Bestellanforderungsposition wird in eine Bestellposition umgewandelt. Damit wird die Übergabe an das Beschaffungsteam markiert. Die Aktivität wird erfasst, indem die Anforderungsposition mit einer Bestellposition verknüpft wird.
Warum das wichtig ist Dieser wichtige Meilenstein verbindet die Anforderung mit dem nachgelagerten Beschaffungsprozess. Er ist entscheidend für die Messung der KPI 'Zeit von der Anforderung bis zur Bestellung'. Woher beziehen Die Aktivität wird abgeleitet, indem in der Tabelle 'PurchLine' ein Datensatz gesucht wird, der auf die ID einer 'PurchReqLine' verweist, die dem Anforderungs-Case zugeordnet ist. Erfassung Verknüpfen Sie PurchReqLine und PurchLine über das Referenzfeld, zum Beispiel PurchReqLineRefId. Ereignistyp inferred
	Genehmigungsschritt genehmigt	Eine genehmigende Person schließt die zugewiesene Aufgabe ab und genehmigt die Anforderung für die jeweilige Prozessphase. Anschließend wird die Anforderung an den nächsten Schritt oder zur endgültigen Genehmigung weitergeleitet.
Warum das wichtig ist Die Aktivität misst die Bearbeitungszeit jeder Genehmigungsphase und hilft, effiziente Teile des Workflows zu erkennen. Sie ist ein wichtiger Bestandteil der Variantenanalyse. Woher beziehen Explizit in der 'WorkflowTrackingStatusTable' protokolliert, wenn ein Benutzer ein Arbeitselement mit dem Ergebnis 'Approve' abschließt. Erfassung Suchen Sie in den Workflow-Verlaufsprotokollen nach 'WorkItemCompleted'-Ereignissen mit dem Ergebnis 'Approve'. Ereignistyp explicit
	Anforderung geändert	Dieses Ereignis tritt ein, wenn ein Benutzer eine eingereichte Anforderung aus dem Workflow zurückruft, um sie zu ändern. Die Aktivität lässt sich in der Regel daran erkennen, dass auf einen Rückruf später eine erneute Einreichung folgt.
Warum das wichtig ist Änderungen zu verfolgen ist wichtig, um Nacharbeit, unklare Erstanforderungen und Ineffizienzen im Prozess zu erkennen. Die Daten fließen direkt in das Dashboard 'Änderungshäufigkeit von Anforderungen' ein. Woher beziehen Die Aktivität lässt sich aus dem Workflow-Verlauf ('WorkflowTrackingStatusTable') ableiten, indem eine Aktion vom Typ 'Recall' oder 'RequestChange' erkannt wird. Alternativ können Änderungen am Feld 'modifiedDateTime' in der 'PurchReqTable' nach der Einreichung herangezogen werden. Erfassung Erkennen Sie Rückrufereignisse im Workflow oder Änderungen an Datensatzversionen zwischen Einreichungen. Ereignistyp inferred
	Anforderung zurückgezogen	Der Ersteller oder ein berechtigter Benutzer storniert die Anforderung nach dem Einreichen. Dadurch werden der Workflow und die Anforderung beendet.
Warum das wichtig ist Die Rücknahmen zu verfolgen hilft, Probleme bei der Bedarfsplanung oder übermäßig komplexe Prozesse zu erkennen. Die Daten fließen in das Dashboard 'Erkenntnisse zu zurückgezogenen Anforderungen' ein. Woher beziehen Die Aktivität wird aus einer Statusänderung in der 'PurchReqTable' zu 'Cancelled' oder aus einem 'Cancel'-Ereignis in der 'WorkflowTrackingStatusTable' abgeleitet. Erfassung Erkennen Sie eine Statusänderung zu 'Cancelled' in der PurchReqTable oder ein Stornierungsereignis im Workflow. Ereignistyp inferred
	Anforderungsposition abgeschlossen	Eine einzelne Position der Bestellanforderung gilt als vollständig bearbeitet. Das ist in der Regel der Fall, wenn die Position vollständig in eine Bestellung umgewandelt wurde.
Warum das wichtig ist Die Aktivität liefert detaillierte Informationen zur Erfüllung von Anforderungen. So lässt sich erkennen, ob Anforderungen teilweise oder vollständig in Bestellungen umgewandelt wurden. Woher beziehen Die Aktivität wird aus dem Statusfeld der einzelnen Tabelle 'PurchReqLine' abgeleitet. Ein Status wie 'Ordered' oder 'Received' weist auf den Abschluss hin. Erfassung Überwachen Sie das Statusfeld in der Tabelle PurchReqLine auf einen Endstatus wie 'Invoiced' oder 'Closed'. Ereignistyp inferred
	Genehmigungsschritt abgelehnt	Eine genehmigende Person lehnt die zugewiesene Aufgabe ab. In der Regel wird die Anforderung zur Korrektur an die einreichende Person zurückgegeben. Die Workflow-Engine protokolliert diese Aktion explizit.
Warum das wichtig ist Diese Aktivität ist grundlegend für die Berechnung der 'Ablehnungsquote von Anforderungen'. Sie zeigt außerdem, in welchen Phasen Ablehnungen besonders häufig vorkommen und wo Verbesserungen am Prozess ansetzen können. Woher beziehen Explizit in der 'WorkflowTrackingStatusTable' protokolliert, wenn ein Benutzer ein Arbeitselement mit dem Ergebnis 'Reject' abschließt. Erfassung Suchen Sie in den Workflow-Verlaufsprotokollen nach 'WorkItemCompleted'-Ereignissen mit dem Ergebnis 'Reject'. Ereignistyp explicit
	Genehmigungsschritt gestartet	Im Rahmen des Workflows wird einem Benutzer oder einer Gruppe eine einzelne Genehmigungsaufgabe zugewiesen. Damit beginnt die Warte- oder Bearbeitungszeit für eine bestimmte genehmigende Person.
Warum das wichtig ist Diese Aktivität ist entscheidend für die 'Engpassanalyse von Genehmigungsschritten', da sich damit die Wartezeiten in einzelnen Genehmigungsphasen messen lassen. Woher beziehen Erfasst in der 'WorkflowTrackingStatusTable', wenn ein neues Arbeitselement erstellt und der Workflowinstanz der Anforderung zugewiesen wird. Erfassung Suchen Sie in den Workflow-Verlaufsprotokollen der jeweiligen Anforderung nach 'WorkItemCreated' oder ähnlichen Ereignissen. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Microsoft Dynamics 365

Schritte

Data Management Workspace öffnen: Melden Sie sich bei Microsoft Dynamics 365 an und öffnen Sie das Menü Workspaces. Wählen Sie Data management, um die zentrale Oberfläche für den Datenimport und -export zu öffnen.
Neues Exportprojekt erstellen: Klicken Sie im Data Management Workspace auf die Kachel Export. Geben Sie einen eindeutigen Gruppennamen und eine aussagekräftige Beschreibung ein. Legen Sie für Project category den Wert Project fest. So sind Ihre Datenexporte übersichtlich organisiert.
Datenentitäten hinzufügen: Fügen Sie Ihrem Projekt die erforderlichen Standarddatenentitäten hinzu. Klicken Sie auf Add entity, suchen Sie nach den folgenden Entitäten und fügen Sie sie einzeln hinzu:
- Purchase requisition headers
- Purchase requisition lines
- Workflow tracking status table
- Workflow work items
- Purchase order lines V2
Exportformat festlegen: Wählen Sie für jede hinzugefügte Entität ein Target data format, zum Beispiel CSV oder Excel. CSV empfiehlt sich in der Regel aufgrund der Leistung und der Kompatibilität mit Datentransformationstools.
Datenfilter anwenden: Wählen Sie eine Entität aus und klicken Sie auf Filtern. Geben Sie auf der Registerkarte Bereich unter Legal entity die juristische Person (den Unternehmenscode) an, damit Sie Daten aus der richtigen Geschäftseinheit exportieren. Wichtig ist auch ein Datumsfilter für das Feld Created date and time der Entität Purchase requisition headers, um das Datenvolumen zu begrenzen. Beginnen Sie am besten mit einem Zeitraum von drei bis sechs Monaten.
Exportauftrag ausführen: Wenn alle Entitäten und Filter eingerichtet sind, klicken Sie im Aktionsbereich auf Export. Das System erstellt ein Auftragspaket und startet die Verarbeitung. Den Fortschritt sehen Sie im Abschnitt Job history.
Datenpaket herunterladen: Sobald der Exportauftrag erfolgreich abgeschlossen ist, öffnen Sie die Details unter Job history und klicken Sie auf Download package. Dadurch wird eine ZIP-Datei mit separaten Datendateien für jede Entität heruntergeladen.
Rohdaten in ein Event Log umwandeln: Die exportierten Dateien enthalten rohe Systemtabellen, kein fertiges Event Log. Verwenden Sie ein externes Tool wie Python, Power Query oder eine ETL-Plattform, um die Daten zusammenzuführen und neu zu strukturieren. Dazu gehört:
- Die Dateien mit Kopf- und Positionsdaten zusammenzuführen.
- Workflow-Daten anhand von CorrelationId und RecId der Kopfzeile der Bestellanforderung mit den Bestellanforderungen zu verknüpfen.
- Statusänderungen und Workflow-Ereignisse aus den Workflow-Tabellen in einzelne Aktivitätszeilen umzuwandeln, zum Beispiel Requisition Submitted und Approval Step Approved.
- Für jede Aktivität eine Zeile mit den passenden Werten für ActivityName, EventTime und PurchaseRequisitionId anzulegen.
Attribute berechnen und zuordnen: Ordnen Sie bei der Transformation Quellspalten den erforderlichen Attributen wie Benutzer und Abteilung zu. Berechnen Sie abgeleitete Attribute wie RequisitionTotalAmount, indem Sie die Positionsbeträge summieren. Weisen Sie SourceSystemId einen festen Wert zu, zum Beispiel 'D365_F&O', und verwenden Sie für LastDataIngestionTimestamp die Ausführungszeit Ihres Skripts.
Ausgabe fertigstellen und formatieren: Stellen Sie sicher, dass die fertige Ausgabe aus einer einzelnen CSV-Datei besteht, in der jede Zeile ein Prozessereignis darstellt. Die Spalten müssen der erforderlichen Event-Log-Struktur entsprechen und unter anderem PurchaseRequisitionId, ActivityName und EventTime enthalten.

Konfiguration

Erforderliche Berechtigungen: Benutzer benötigen eine Sicherheitsrolle mit Berechtigungen für den Data management-Workspace und Zugriff auf die zu exportierenden Datenentitäten, zum Beispiel Data management administrator oder eine vergleichbare benutzerdefinierte Rolle.
Wichtige Datenentitäten:
- Purchase requisition headers: Enthält die zentrale Case-ID, den Erstellungszeitstempel und den Gesamtstatus.
- Purchase requisition lines: Enthält Angaben zu den angeforderten Artikeln, darunter Beträge und Verknüpfungen zu Bestellungen.
- Workflow tracking status table: Zentrale Quelle für Workflow-Ereignisse wie Einreichung, Freigabe, Ablehnung und Rücknahme.
- Workflow work items: Enthält Details zu den Aufgaben, die Benutzern während des Freigabeprozesses zugewiesen werden.
- Purchase order lines V2: Dient dazu, den Erstellungszeitstempel der Bestellung zu ermitteln, die mit einer Bestellanforderungsposition verknüpft ist.
Datumsbereich filtern: Filtern Sie unbedingt das Feld Created date and time der Entität Purchase requisition headers nach einem Datumsbereich. Für die erste Analyse empfiehlt sich ein Zeitraum von drei bis sechs Monaten, um Datenvolumen und Prozesserkenntnisse in ein ausgewogenes Verhältnis zu bringen.
Unternehmenscode filtern: Filtern Sie immer nach Legal entity, damit keine Daten aus nicht vorgesehenen oder Testunternehmen exportiert werden. Das verringert das Datenvolumen erheblich und verbessert die Leistung des Auftrags.
Datentransformation: Bei dieser Methode müssen die Rohdatenexporte außerhalb von Dynamics 365 in einem umfangreichen Nachbearbeitungsschritt in ein strukturiertes Event Log umgewandelt werden. Planen Sie dafür den Einsatz eines Skript- oder ETL-Tools ein.

Beispielabfrage sql

/*
This is not a single executable query. Instead, it is a configuration manifest for a Dynamics 365 Data Management Framework Export Project.
You must add each entity listed below to the project and select the specified fields for export.
The transformation logic to create the final event log must be applied after exporting these files.
*/

-- Entity 1: Purchase requisition headers
-- Purpose: Captures requisition creation, overall status, and header-level attributes.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    REQUISITIONSTATUS AS RequisitionStatus,
    CREATEDDATETIME AS EventTime_RequisitionCreated,
    MODIFIEDDATETIME AS EventTime_RequisitionClosed, -- Used if status is Closed
    PREPARERPERSONNELNUMBER AS User_Preparer,
    REQUESTERPERSONNELNUMBER AS User_Requester,
    DEFAULTLEDGERDIMENSIONDISPLAYVALUE AS Department, -- Or similar dimension field
    REQUISITIONTOTAL AS RequisitionTotalAmount
FROM PurchaseRequisitionHeaderEntity;

-- Entity 2: Purchase requisition lines
-- Purpose: Provides line-level details, amounts, and links to Purchase Orders.
SELECT
    REQUISITIONNUMBER AS PurchaseRequisitionId,
    LINENUMBER,
    REQUISITIONINGSTATUS AS LineStatus,
    MODIFIEDDATETIME AS EventTime_LineClosed, -- Used if status is Closed
    PURCHASEORDERNUMBER,
    PURCHASEORDERLINENUMBER
FROM PurchaseRequisitionLineEntity;

-- Entity 3: Workflow tracking status table
-- Purpose: The primary source for all workflow-driven activities.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CONTEXT, -- Contains information like step name
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_WorkflowStep,
    TRACKINGSTATUS AS ActivityName, -- (e.g., Submitted, Approved, Rejected, Canceled)
    USERID AS User
FROM WorkflowTrackingStatusTableEntity;

-- Entity 4: Workflow work items
-- Purpose: Captures the start of an approval task assigned to a user.
-- Note: Requires joining to PurchReqTable on RecId = CorrelationId post-export.
SELECT
    CORRELATIONID, -- Links to source document's RecId
    CREATEDDATETIME AS EventTime_ApprovalStepStarted,
    USERID AS User, -- The user assigned the task
    DESCRIPTION AS ApprovalStep
FROM WorkflowWorkItemTableEntity;

-- Entity 5: Purchase order lines V2
-- Purpose: Used to find the creation date of the resulting Purchase Order.
-- Note: Requires joining to PurchaseRequisitionLineEntity on PO/Line number post-export.
SELECT
    PURCHASEORDERNUMBER,
    LINENUMBER,
    CREATEDDATETIME AS EventTime_PurchaseOrderCreated
FROM PurchaseOrderLinesV2Entity;

Schritte

Azure Active Directory-Anwendung registrieren: Öffnen Sie das Azure-Portal und registrieren Sie eine neue Anwendung. Diese dient der Authentifizierung bei der Dynamics-365-API. Notieren Sie sich die Anwendungs-ID (Client-ID) und die Verzeichnis-ID (Mandanten-ID).
Client Secret erstellen: Erstellen Sie in der neu registrierten Azure-Anwendung unter 'Certificates & secrets' ein neues Client Secret. Kopieren Sie den Wert sicher, da er später nicht erneut angezeigt wird.
API-Berechtigungen erteilen: Fügen Sie im Bereich 'API permissions' der Anwendung eine Berechtigung für 'Dynamics ERP' hinzu. Wählen Sie 'Delegated permissions' und erteilen Sie Financials.ReadWrite.All oder eine restriktivere, schreibgeschützte Berechtigung. Erteilen Sie für die Berechtigungen die Administratoreinwilligung.
Python-Bibliotheken installieren: Stellen Sie sicher, dass Python installiert ist. Installieren Sie anschließend die erforderlichen Bibliotheken mit pip: pip install requests pandas.
Python-Skript konfigurieren: Kopieren Sie das bereitgestellte Python-Skript in eine Datei, zum Beispiel extract_d365_requisitions.py. Tragen Sie oben im Skript die Platzhalterwerte ein: Ihre Dynamics-365-URL, Mandanten-ID, Client-ID, Client Secret, den gewünschten Datumsbereich und die Unternehmens-ID.
OData-Entitäten verstehen: Das Skript fragt drei zentrale Datenentitäten ab: PurchaseRequisitionHeaders mit den wichtigsten Angaben zur Bestellanforderung, PurchaseRequisitionLines mit Details zu den Positionen einschließlich der Umwandlung in Bestellungen sowie WorkflowTrackingStatusTable mit allen Workflow-Ereignissen wie Einreichungen und Freigaben.
Skript ausführen: Starten Sie das Skript über die Befehlszeile: python extract_d365_requisitions.py. Das Skript authentifiziert sich, ruft die Daten zu den einzelnen Aktivitäten ab und übernimmt die API-Paginierung automatisch.
Daten transformieren: Das Skript verarbeitet die Rohdaten im JSON-Format aus den API-Aufrufen. Es strukturiert die Daten neu, indem es die Datensätze durchläuft und für jede der zwölf Geschäftsaktivitäten eine eigene Zeile erstellt. Dabei ordnet es Quellfelder den Standardspalten des Event Logs zu, zum Beispiel PurchaseRequisitionId, ActivityName und EventTime.
Ereignisse zusammenführen und vereinheitlichen: Alle erzeugten Ereignisse werden in einer Liste gesammelt und anschließend in einen pandas DataFrame umgewandelt. Das Skript ergänzt feste Spalten wie SourceSystemId und LastDataIngestionTimestamp.
Als CSV exportieren: Der fertige DataFrame wird in eine CSV-Datei namens d365_purchase_requisition_log.csv exportiert. Diese Datei kann direkt in ein Process-Mining-Tool hochgeladen werden. Prüfen Sie, ob die Datei UTF-8-codiert ist.

Konfiguration

Voraussetzungen: Zugriff auf ein Azure-Abonnement, um eine Anwendung zu registrieren. Sie benötigen eine Anwendungs-ID (Client-ID), ein Client Secret und eine Mandanten-ID aus Azure Active Directory. Das Benutzerkonto, mit dem das Skript ausgeführt wird, muss über Zugangsdaten mit Zugriff auf die OData-API-Endpunkte von Dynamics 365 Finance and Operations verfügen.
API-Endpunkt konfigurieren: Für das Skript ist die Basis-URL Ihrer Dynamics-365-Umgebung erforderlich. Sie hat üblicherweise das Format https://[your-environment-name].operations.dynamics.com.
Datumsbereich: Legen Sie im Skript mit den Variablen START_DATE und END_DATE den Exportzeitraum fest. Für die erste Analyse empfiehlt sich ein Zeitraum von drei bis sechs Monaten, um Datenvolumen und Erkenntnisgewinn auszubalancieren.
Unternehmensfilter: Das Skript filtert mithilfe der Variablen COMPANY_ID nach einer bestimmten juristischen Person. Um Daten aller Unternehmen zu exportieren, müssen Sie möglicherweise den OData-Filter anpassen und cross-company=true in die Anforderungsheader aufnehmen.
Leistungshinweise: Mit $select in den OData-Abfragen ruft das Skript nur die für das Event Log erforderlichen Spalten ab und verbessert so die Leistung. Außerdem verarbeitet es die Paginierung, damit große Datenmengen die API nicht überlasten. Bei sehr umfangreichen historischen Daten empfiehlt es sich, das Skript in mehreren Durchläufen mit kürzeren Datumsbereichen auszuführen.

Beispielabfrage python

import requests
import pandas as pd
from datetime import datetime, timezone
import os

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Dynamics 365 environment details
D365_URL = class="hl-string">"https://[your-d365-url].operations.dynamics.com"
TENANT_ID = class="hl-string">"[your-tenant-id]"
CLIENT_ID = class="hl-string">"[your-client-id]"
CLIENT_SECRET = class="hl-string">"[your-client-secret]"

class=class="hl-string">"hl-comment"># --- Parameters ---
class=class="hl-string">"hl-comment"># Set the data extraction window
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"
COMPANY_ID = class="hl-string">"[YourCompanyLegalEntity]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">"USMF"
OUTPUT_FILENAME = class="hl-string">"d365_purchase_requisition_log.csv"


def get_access_token():
    class="hl-string">"""Authenticates with Azure AD to get an access token."""
    auth_url = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}/oauth2/token"
    payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET,
        class="hl-string">'resource': D365_URL
    }
    response = requests.post(auth_url, data=payload)
    response.raise_for_status()
    return response.json()[class="hl-string">'access_token']

def fetch_data(access_token, entity_url):
    class="hl-string">"""Fetches all pages of data from a given D365 OData entity URL."""
    all_records = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Accept': class="hl-string">'application/json'
    }
    while entity_url:
        response = requests.get(entity_url, headers=headers)
        response.raise_for_status()
        data = response.json()
        all_records.extend(data[class="hl-string">'value'])
        entity_url = data.get(class="hl-string">'@odata.nextLink')
    return all_records

def main():
    class="hl-string">"""Main function to extract, transform, and save the event log."""
    print(class="hl-string">"Acquiring access token...")
    access_token = get_access_token()
    events = []
    last_ingestion_ts = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Purchase Requisition Headers for class="hl-string">'Created' and class="hl-string">'Closed' events
    print(class="hl-string">"Fetching Purchase Requisition Headers...")
    pr_headers_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionHeaders?" 
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}" 
        fclass="hl-string">"&$select=RequisitionNumber,RequisitionStatus,CreatedDateTime,CreatedBy,RequestingDepartmentName,RequisitionTotalAmount,RequisitionUrgencyLevel"
    )
    pr_headers = fetch_data(access_token, pr_headers_url)

    for prh in pr_headers:
        case_id = prh.get(class="hl-string">'RequisitionNumber')
        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        events.append({
            class="hl-string">'PurchaseRequisitionId': case_id,
            class="hl-string">'ActivityName': class="hl-string">'Requisition Created',
            class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'),
            class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
            class="hl-string">'RequisitionStatus': prh.get(class="hl-string">'RequisitionStatus'),
            class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
            class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
            class="hl-string">'ApprovalStep': None,
            class="hl-string">'ProcessingTime': None
        })
        class=class="hl-string">"hl-comment"># Activity: Requisition Closed
        if prh.get(class="hl-string">'RequisitionStatus') == class="hl-string">'Closed':
            class=class="hl-string">"hl-comment"># Note: We need a reliable timestamp for closure. Using CreatedDateTime as a placeholder.
            class=class="hl-string">"hl-comment"># A better source might be the last workflow approval or line closure date.
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Closed',
                class="hl-string">'EventTime': prh.get(class="hl-string">'CreatedDateTime'), class=class="hl-string">"hl-comment"># Placeholder timestamp
                class="hl-string">'User': prh.get(class="hl-string">'CreatedBy'), class=class="hl-string">"hl-comment"># Placeholder user
                class="hl-string">'Department': prh.get(class="hl-string">'RequestingDepartmentName'),
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': prh.get(class="hl-string">'RequisitionTotalAmount'),
                class="hl-string">'UrgencyLevel': prh.get(class="hl-string">'RequisitionUrgencyLevel'),
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 2. Fetch Workflow History for workflow-related events
    print(class="hl-string">"Fetching Workflow Tracking Status Table...")
    workflow_url = (
        fclass="hl-string">"{D365_URL}/data/WorkflowTrackingStatusTable?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE} and startswith(Context,'PurchReq')"
        fclass="hl-string">"&$select=Context,CreatedDateTime,TrackingType,User,WorkItemSubject"
    )
    workflow_items = fetch_data(access_token, workflow_url)

    for item in workflow_items:
        context_parts = item.get(class="hl-string">'Context', class="hl-string">'').split(class="hl-string">':')
        if len(context_parts) < 2:
            continue
        case_id = context_parts[1].strip()
        tracking_type = item.get(class="hl-string">'TrackingType')
        activity_map = {
            class="hl-string">'Submission': class="hl-string">'Requisition Submitted for Approval',
            class="hl-string">'Started': class="hl-string">'Approval Step Started',
            class="hl-string">'Completion': class="hl-string">'Approval Step Approved',
            class="hl-string">'Rejection': class="hl-string">'Approval Step Rejected',
            class="hl-string">'Cancellation': class="hl-string">'Requisition Withdrawn',
            class="hl-string">'Recall': class="hl-string">'Requisition Amended',
            class="hl-string">'Approved': class="hl-string">'Requisition Approved',
            class="hl-string">'Fault': class="hl-string">'Requisition Rejected'
        }
        activity_name = activity_map.get(tracking_type)
        if activity_name:
            events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': activity_name,
                class="hl-string">'EventTime': item.get(class="hl-string">'CreatedDateTime'),
                class="hl-string">'User': item.get(class="hl-string">'User'),
                class="hl-string">'Department': None, class=class="hl-string">"hl-comment"># Department info is not in this entity
                class="hl-string">'RequisitionStatus': None, class=class="hl-string">"hl-comment"># Status info is not in this entity
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': item.get(class="hl-string">'WorkItemSubject'),
                class="hl-string">'ProcessingTime': None
            })

    class=class="hl-string">"hl-comment"># 3. Fetch Purchase Requisition Lines for PO Creation and Line Closure
    print(class="hl-string">"Fetching Purchase Requisition Lines...")
    pr_lines_url = (
        fclass="hl-string">"{D365_URL}/data/PurchaseRequisitionLines?"
        fclass="hl-string">"$filter=dataAreaId eq '{COMPANY_ID}' and CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}"
        fclass="hl-string">"&$select=RequisitionNumber,PurchaseOrderNumber,IsPrepaymentRequired,LineStatus,ModifiedDateTime,ModifiedBy"
    )
    pr_lines = fetch_data(access_token, pr_lines_url)

    for prl in pr_lines:
        case_id = prl.get(class="hl-string">'RequisitionNumber')
        po_number = prl.get(class="hl-string">'PurchaseOrderNumber')
        line_status = prl.get(class="hl-string">'LineStatus')
        
        class=class="hl-string">"hl-comment"># Activity: Purchase Order Created
        if po_number:
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': None,
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': fclass="hl-string">"PO: {po_number}",
                class="hl-string">'ProcessingTime': None
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Line Closed
        if line_status == class="hl-string">'Closed':
             events.append({
                class="hl-string">'PurchaseRequisitionId': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Requisition Line Closed',
                class="hl-string">'EventTime': prl.get(class="hl-string">'ModifiedDateTime'),
                class="hl-string">'User': prl.get(class="hl-string">'ModifiedBy'),
                class="hl-string">'Department': None,
                class="hl-string">'RequisitionStatus': class="hl-string">'Closed',
                class="hl-string">'RequisitionTotalAmount': None,
                class="hl-string">'UrgencyLevel': None,
                class="hl-string">'ApprovalStep': None,
                class="hl-string">'ProcessingTime': None
            })

    if not events:
        print(class="hl-string">"No events found for the specified criteria.")
        return

    class=class="hl-string">"hl-comment"># 4. Create and format the DataFrame
    print(class="hl-string">"Formatting data...")
    df = pd.DataFrame(events)
    df[class="hl-string">'SourceSystemId'] = class="hl-string">'Microsoft Dynamics 365'
    df[class="hl-string">'LastDataIngestionTimestamp'] = last_ingestion_ts

    class=class="hl-string">"hl-comment"># Fill forward missing data within each case
    df = df.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTime'])
    df[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']] = \
        df.groupby(class="hl-string">'PurchaseRequisitionId')[[class="hl-string">'Department', class="hl-string">'RequisitionTotalAmount', class="hl-string">'UrgencyLevel']].ffill().bfill()

    class=class="hl-string">"hl-comment"># Ensure required columns exist and are in order
    final_columns = [
        class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'SourceSystemId',
        class="hl-string">'LastDataIngestionTimestamp',
        class="hl-string">'User',
        class="hl-string">'Department',
        class="hl-string">'RequisitionStatus',
        class="hl-string">'RequisitionTotalAmount',
        class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalStep',
        class="hl-string">'ProcessingTime'
    ]
    for col in final_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[final_columns]

    class=class="hl-string">"hl-comment"># 5. Save to CSV
    df.to_csv(OUTPUT_FILENAME, index=False, encoding=class="hl-string">'utf-8')
    print(fclass="hl-string">"Successfully extracted {len(df)} events to {OUTPUT_FILENAME}")

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

Schritte

Vergewissern Sie sich, dass der native Konnektor für Microsoft Dynamics 365 Finance in Power BI Desktop verfügbar ist und das Benutzerkonto auf die erforderlichen Datenentitäten, den Workflowverlauf, die Bestellanforderungsdaten und zugehörige Bestelldaten zugreifen darf.
Wählen Sie in Power BI Desktop „Daten abrufen“, dann den Konnektor für Microsoft Dynamics 365 Finance, und geben Sie die URL Ihrer Dynamics-365-Finance-Instanz ein. Melden Sie sich mit einem Konto an, das zum Lesen der benötigten Entitäten berechtigt ist. Ersetzen Sie [Your Dynamics 365 Finance instance URL] durch die URL Ihrer Instanz.
Wählen Sie im Navigator die Kopf- und Positionsentitäten für Bestellanforderungen, Workflowverlauf oder Workflow-Tracking, Benutzer- und Organisationseinheiten sowie die für Ihre Implementierung erforderlichen Bestellentitäten aus. Entitätsnamen und verfügbare Felder unterscheiden sich je nach Umgebung. Prüfen Sie die Entitätsmetadaten und ersetzen Sie jeden Platzhalter in der Abfrage durch die entsprechende Entität und das Feld, die Ihr System bereitstellt.
Laden Sie die ausgewählten Entitäten in Power Query. Filtern Sie die Daten nach der erforderlichen juristischen Person oder dem Unternehmen, dem Belegtyp und dem Exportzeitraum. Verwenden Sie die Parameter [Start date] und [End date] und behalten Sie Datensätze bei, deren Ereigniszeitstempel in den gewählten Zeitraum fällt. Berücksichtigen Sie auch vor dem Startdatum erstellte Datensätze, wenn sie Workflow- oder Abschlussereignisse innerhalb des Zeitraums enthalten, damit die Case-Verläufe vollständig bleiben.
Vereinheitlichen Sie Bezeichner und Zeitstempel. Wandeln Sie die ID der Bestellanforderung in Text um, bringen Sie alle Ereigniszeitstempel auf eine einheitliche Zeitzone (UTC oder Geschäftszeitzone) und bewahren Sie die Genauigkeit der Quellzeitstempel. Stellen Sie sicher, dass die ID der Kopfzeile der Bestellanforderung in jeder Ereigniszeile enthalten ist. Wenn Workflow-Datensätze nur eine Workflow-Korrelations-ID enthalten, verknüpfen Sie sie anhand der in Ihrer Umgebung dokumentierten Beziehung mit der Kopfzeile der Bestellanforderung.
Erstellen Sie für jede erforderliche Aktivität eine Ereignisabfrage. Die Abfragen müssen explizit Zeilen für folgende Aktivitäten zurückgeben: Bestellanforderung erstellt, Bestellanforderung zur Freigabe eingereicht, Bestellanforderung geändert, Freigabeschritt gestartet, Freigabeschritt genehmigt, Freigabeschritt abgelehnt, Bestellanforderung genehmigt, Bestellanforderung abgelehnt, Bestellanforderung zurückgezogen, Bestellung erstellt, Bestellanforderungsposition geschlossen und Bestellanforderung geschlossen. Verlassen Sie sich nicht darauf, dass ProcessMind Aktivitäten aus Statusänderungen oder der Ereignisreihenfolge ableitet.
Wenden Sie bei „Bestellanforderung geändert“ die dokumentierte Logik für Rücknahme und erneute Einreichung aus Ihrem Workflowverlauf an. Auf eine Rücknahme folgende erneute Einreichung sollte zum Zeitpunkt der Rücknahme ein Änderungsereignis erzeugen oder zum Änderungszeitpunkt, den die Quellentität bereitstellt. Erstellen Sie nicht allein aufgrund eines geänderten Status der Bestellanforderung eine Änderungszeile, es sei denn, das Quellsystem erfasst diese Änderung ausdrücklich als Änderung.
Verknüpfen Sie für Positions- und Bestellereignisse die Bestellanforderungspositionen anhand der dokumentierten Quellbeziehung mit den Bestellpositionen. Wenn das Event Log nach PurchaseRequisitionId in Cases gegliedert ist, fassen Sie Positionsereignisse zusammen oder behalten Sie sie als separate Zeilen mit derselben Case-ID bei. Bewahren Sie verfügbare Positions-IDs in zusätzlichen Spalten auf, auch wenn sie keine Pflichtattribute sind.
Fügen Sie die erforderlichen Ausgabespalten PurchaseRequisitionId, ActivityName, EventTime, SourceSystemId und LastDataIngestionTimestamp hinzu. Ergänzen Sie die empfohlenen Spalten User, Department, RequisitionStatus, RequisitionTotalAmount, UrgencyLevel und ApprovalStep. Nicht verfügbare Werte müssen null bleiben und dürfen nicht erfunden werden. Verwenden Sie für SourceSystemId einen einheitlichen Quellwert wie Dynamics 365 Finance.
Fügen Sie alle Aktivitätsabfragen mit UNION ALL zusammen, entfernen Sie Zeilen ohne Case-ID oder Ereigniszeitstempel und sortieren Sie nach PurchaseRequisitionId und EventTime. Behalten Sie doppelte Ereignisse bei, wenn sie getrennte Workflowaufgaben oder Bestellanforderungspositionen darstellen. Entfernen Sie Duplikate nur, wenn die Quelldatensätze nachweislich doppelte Exporte sind.
Prüfen Sie das resultierende Event Log anhand der unten beschriebenen Kontrollen. Vergewissern Sie sich, dass jede erforderliche Aktivität durch explizite Zeilen dargestellt wird, die Zeitstempel im gewählten Zeitraum liegen und Verknüpfungen nicht unerwartet zu mehrfachen Ereignissen führen.
Laden oder exportieren Sie die fertige Tabelle als CSV oder in einem anderen von ProcessMind unterstützten Event-Log-Format. Ordnen Sie PurchaseRequisitionId der Case-ID, ActivityName der Aktivität und EventTime dem Ereigniszeitstempel zu. Behalten Sie SourceSystemId und LastDataIngestionTimestamp als Ereignisattribute bei und übernehmen Sie alle verfügbaren empfohlenen Attribute.

Konfiguration

Konnektor und Quelle: Verwenden Sie den nativen Konnektor für Microsoft Dynamics 365 Finance in Power BI Desktop. Ersetzen Sie [Your Dynamics 365 Finance instance URL] durch die URL Ihrer Umgebung. Prüfen Sie die Entitätsnamen und Felder anhand der Navigator-Metadaten für die jeweilige Implementierung.
Erforderliche Entitäten: Wählen Sie die Kopf- und Positionsentitäten für Bestellanforderungen, Workflow-Tracking- oder Workflowverlauf-Entitäten, Kopf- und Positionsentitäten für Bestellungen sowie die zur Anreicherung benötigten Benutzer- oder Organisationseinheiten aus. Verwenden Sie zunächst Platzhalter wie [Your entity name], bis die genauen Entitäten feststehen.
Datumsbereich: Beginnen Sie mit Daten aus einem Zeitraum von drei bis sechs Monaten. Berücksichtigen Sie auch ältere Kopfdatensätze von Bestellanforderungen, für die Workflow-, Bestell-, Positionsabschluss- oder Abschlussereignisse im gewählten Zeitraum vorliegen.
Unternehmens- und Belegfilter: Filtern Sie gegebenenfalls nach [Your company or legal entity filter] und [Your document type filter]. Prüfen Sie, ob die ID der Bestellanforderung global eindeutig ist oder nur innerhalb eines Unternehmens.
Workflowumfang: Berücksichtigen Sie Einreichung, Rücknahme, erneute Einreichung, Aufgabenzuweisung, Freigabe, Ablehnung, Rückzug, Abschluss und Stornierung. Richten Sie die Zuordnung von Workflowaktionen und -status anhand der in Ihrer Umgebung verwendeten Werte ein.
Ereignissemantik: Jede Aktivität muss als explizite Ereigniszeile ausgegeben werden. ProcessMind leitet Freigabe-, Änderungs-, Abschluss- oder Umwandlungsereignisse nicht aus anderen Zeilen ab.
Zeitstempelverarbeitung: Vereinheitlichen Sie alle Zeitstempel auf eine Zeitzone. Dokumentieren Sie, ob die Quellzeitstempel in UTC oder in der lokalen Geschäftszeitzone gespeichert sind. Verwenden Sie den Quellzeitstempel mit der höchsten verfügbaren Genauigkeit.
Inkrementelle Aktualisierung: Verwenden Sie bei wiederkehrenden Exporten einen Wasserstand auf Basis des neuesten Änderungs- oder Ereigniszeitstempels der Quelle sowie einen Überlappungszeitraum, um verspätet eintreffende Workflow-Datensätze zu erfassen. Gleichen Sie den Überlappungszeitraum ab, bevor Sie das fertige Event Log laden.
Leistung: Filtern Sie Quellentitäten vor Verknüpfungen, wählen Sie nur erforderliche Spalten aus, vermeiden Sie das Laden unnötiger historischer Workflow-Datensätze und verwenden Sie, sofern unterstützt, Query Folding. Exportieren Sie Kopfzeilen, Positionen, Workflowereignisse und Bestellbeziehungen zunächst getrennt und führen Sie sie anschließend zusammen.
Berechtigungen und Voraussetzungen: Das Konto benötigt Lesezugriff auf die ausgewählten Datenentitäten und Workflowdaten in Dynamics 365 Finance. Vergewissern Sie sich, dass die relevanten Beschaffungs- und Workflowfunktionen aktiviert sind und dass Power BI Desktop, der Konnektor, eine gegebenenfalls erforderliche Gateway-Konfiguration sowie die Sicherheitsrichtlinien Ihrer Organisation den Export zulassen.
Währung und Beträge: Prüfen Sie, welche Währung in RequisitionTotalAmount angegeben ist. Wenn Bestellanforderungen mehrere Währungen umfassen können, nehmen Sie die Quellwährung als zusätzliches Attribut auf und rechnen Sie Beträge nicht stillschweigend um.
Umgang mit Nullwerten: Empfohlene Attribute können null sein, wenn die Quelle keinen Wert speichert, der Wert durch Sicherheitsregeln geschützt ist oder sich die Beziehung nicht auflösen lässt. Prüfen Sie vor dem Export, ob die erforderlichen Werte für Case, Aktivität und Ereigniszeitstempel vorhanden sind.

Beispielabfrage sql

WITH
RequisitionHeader AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [CreatedDateTimeField] AS CreatedDateTime,
        [RequisitionStatusField] AS RequisitionStatus,
        [RequisitionTotalAmountField] AS RequisitionTotalAmount,
        [UrgencyLevelField] AS UrgencyLevel,
        [RequesterUserField] AS RequesterUser,
        [DepartmentField] AS Department
    FROM [Your requisition header entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [DocumentTypeField] = '[Your document type filter]'
),
WorkflowEvents AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [WorkflowEventTimestampField] AS EventTime,
        [WorkflowActionField] AS WorkflowAction,
        [WorkflowStatusField] AS WorkflowStatus,
        [ApprovalStepField] AS ApprovalStep,
        [WorkflowUserField] AS EventUser,
        [WorkflowCorrelationField] AS WorkflowCorrelation
    FROM [Your workflow history or workflow tracking entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
      AND [WorkflowEventTimestampField] >= CAST('[Start date]' AS datetime2)
      AND [WorkflowEventTimestampField] < CAST('[End date]' AS datetime2)
),
PurchaseOrderLinks AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [PurchaseRequisitionLineIdField] AS PurchaseRequisitionLineId,
        [PurchaseOrderIdField] AS PurchaseOrderId,
        [PurchaseOrderLineIdField] AS PurchaseOrderLineId,
        [PurchaseOrderCreatedDateTimeField] AS PurchaseOrderCreatedDateTime,
        [RequisitionLineClosedDateTimeField] AS RequisitionLineClosedDateTime
    FROM [Your requisition to purchase order relationship entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
RequisitionClosure AS (
    SELECT
        CAST([PurchaseRequisitionIdField] AS varchar(100)) AS PurchaseRequisitionId,
        [RequisitionClosedDateTimeField] AS RequisitionClosedDateTime
    FROM [Your requisition closure entity]
    WHERE [CompanyField] = '[Your company or legal entity filter]'
),
Events AS (
    SELECT
        h.PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        h.CreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionHeader h
    WHERE h.CreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Submitted for Approval' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your submission action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your recall action value]')
      AND EXISTS (
          SELECT 1
          FROM WorkflowEvents w2
          WHERE w2.PurchaseRequisitionId = w.PurchaseRequisitionId
            AND w2.WorkflowAction IN ('[Your resubmission action value]')
            AND w2.EventTime > w.EventTime
      )

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval task assigned action value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your approval action value]')
      AND w.WorkflowStatus IN ('[Your approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]')
      AND w.WorkflowStatus IN ('[Your final approved status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your workflow completion action value]', '[Your rejection action value]')
      AND w.WorkflowStatus IN ('[Your final rejected status value]')

    UNION ALL

    SELECT
        w.PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        w.EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        w.EventUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        w.ApprovalStep
    FROM WorkflowEvents w
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = w.PurchaseRequisitionId
    WHERE w.WorkflowAction IN ('[Your withdrawal or cancellation action value]')

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        p.PurchaseOrderCreatedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.PurchaseOrderCreatedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.PurchaseOrderCreatedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        p.PurchaseRequisitionId,
        'Requisition Line Closed' AS ActivityName,
        p.RequisitionLineClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM PurchaseOrderLinks p
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = p.PurchaseRequisitionId
    WHERE p.RequisitionLineClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND p.RequisitionLineClosedDateTime < CAST('[End date]' AS datetime2)

    UNION ALL

    SELECT
        c.PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        c.RequisitionClosedDateTime AS EventTime,
        'Dynamics 365 Finance' AS SourceSystemId,
        CAST(CURRENT_TIMESTAMP AS datetime2) AS LastDataIngestionTimestamp,
        h.RequesterUser AS [User],
        h.Department,
        h.RequisitionStatus,
        h.RequisitionTotalAmount,
        h.UrgencyLevel,
        CAST(NULL AS varchar(255)) AS ApprovalStep
    FROM RequisitionClosure c
    LEFT JOIN RequisitionHeader h ON h.PurchaseRequisitionId = c.PurchaseRequisitionId
    WHERE c.RequisitionClosedDateTime >= CAST('[Start date]' AS datetime2)
      AND c.RequisitionClosedDateTime < CAST('[End date]' AS datetime2)
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    SourceSystemId,
    LastDataIngestionTimestamp,
    [User],
    Department,
    RequisitionStatus,
    RequisitionTotalAmount,
    UrgencyLevel,
    ApprovalStep
FROM Events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

Möchten Sie loslegen?

Mit diesem Template haben Sie alles, was Sie für den Einstieg in die Optimierung Ihres Purchase-to-Pay-Prozesses für Bestellanforderungen benötigen. Entdecken Sie noch heute wertvolle Erkenntnisse.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Bestellanforderungen im Purchase-to-Pay-Prozess optimieren und Freigaben beschleunigen

Beseitigen Sie Verzögerungen und verkürzen Sie die Durchlaufzeiten in Dynamics 365 um 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.

Ihr Daten-Template für den Purchase-to-Pay-Prozess bei Bestellanforderungen

Ihr Daten-Template für den Purchase-to-Pay-Prozess bei Bestellanforderungen

Attribute für den Purchase-to-Pay-Prozess bei Bestellanforderungen

Aktivitäten im Purchase-to-Pay-Prozess für Bestellanforderungen

Anleitungen zur Datenextraktion

Datenexport aus dem Data Management Framework von Dynamics 365

Schritte

Konfiguration

Beispielabfrage sql

Python-Skript mit der Dynamics 365 OData REST API

Schritte

Konfiguration

Beispielabfrage python

Datenexport über den nativen Microsoft-Power-BI-Konnektor

Schritte

Konfiguration

Beispielabfrage sql

Möchten Sie loslegen?

Bestellanforderungen im Purchase-to-Pay-Prozess optimieren und Freigaben beschleunigen