> Kontinuierliche Prozessoptimierung > Purchase to Pay – Purchase Requisition > Microsoft Dynamics 365 > Datenvorlage

Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template

Microsoft Dynamics 365

Purchase-to-Pay – Purchase Requisitions-Attribute (17) Purchase-to-Pay – Purchase Requisitions-Aktivitäten (12) Extraktionsanleitungen (3)

Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template

Diese Vorlage beschreibt die wichtigsten Attribute und die wichtigen Aktivitäten, die verfolgt werden müssen, um eine detaillierte Analyse in Ihren Purchase Requisitionsprozess zu ermöglichen. Sie bietet auch praktische Anleitungen zur Extraktion dieser Daten, um Sie zu helfen, Ihren Event Log effizient für eine detaillierte Analyse vorzubereiten.

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten für das Tracking
Extraktionsanleitung

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

Vorlage herunterladen

Purchase-to-Pay – Purchase Requisitions-Attribute

Dies sind die empfohlenen Datenfelder, die in Ihrem Event Log enthalten sein sollten, um eine vollständige Analyse Ihres Purchase-to-Pay: Purchase Requisitions-Prozesses zu ermöglichen.

5 Erforderlich 6 Empfohlen 6 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des spezifischen Geschäftsereignisses oder Schritts, der im Purchase Requisitionsprozess aufgetreten ist.
Beschreibung Dieses Attribut erfasst den Namen jeder Aktivität, die innerhalb des Lebenszyklus der Purchase Requisition durchgeführt wird. Beispiele sind 'Purchase Requisition erstellt', 'Genehmigungsschritt genehmigt' und 'Bestellung erstellt'. Diese Aktivitäten bilden die Knoten in der entdeckten Prozessablauf. Die Analyse der Sequenz, Häufigkeit und Dauer zwischen diesen Aktivitäten ist die Grundlage für Process Mining. Sie hilft, Engpässe, Nacharbeitszyklen und Abweichungen vom Standardprozessfluss zu identifizieren und liefert Einblicke in operative Ineffizienzen. Bedeutung Dieses Attribut definiert die Schritte in der Prozessablauf und ermöglicht es, den Purchase Requisitions-Workflow zu visualisieren, zu analysierenn und zu verstehen. Datenquelle Dies wird in der Regel aus Statusänderungsprotokollen, Workflow-Verlaufstabellen oder spezifischen Ereignistabellen innerhalb von Microsoft Dynamics 365 abgeleitet, wie z.B. WorkflowTrackingStatusTable. Beispiele Purchase Requisition zur Genehmigung eingereichtGenehmigungsschritt genehmigtPurchase Requisition geändert
	Ereigniszeit EventTime	Der genaue Zeitstempel, wann eine spezifische Aktivität oder ein Ereignis aufgetreten ist.
Beschreibung Event Time, oder den Antrag bearbeitet.er Zeitstempel, erfasst Datum und Uhrzeit, zu der ein Geschäftsereignis im System aufgezeichnet wurde. Es ist die zeitliche Grundlage für alle zeitbasierten Prozessanalysen. Dieses Attribut ist maßgeblich für die Berechnung von Durchlaufzeiten, Dauern und Wartezeiten zwischen Aktivitäten. Es ermöglicht die Analyse der Prozess-Performance, die Engpassidentifikation und die Überwachung der SLA-Compliance. Akkurate Zeitstempels sind essenziell für eine leistungsstarke Process Mining-Analyse. Bedeutung Es liefert die chronologische Reihenfolge der Ereignisse, die für die Berechnung von Prozessdauern, die Identifizierung von Engpässen und die Analyse der Leistungsfähigkeit über die Zeit notwendig ist. Datenquelle Gefunden in Workflow-Verlaufn- oder Dokumentprotokoll-Tabellen, oft als 'CreatedDateTime'- oder 'ModifiedDateTime'-Feld, das mit jeder Statusänderung oder jedem EreignisDatensatz verknüpft ist. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
	Purchase Requisitions-ID PurchaseRequisitionId	Der eindeutige Identifikator für eine Purchase Requisition, der als primärer Case-ID dient.
Beschreibung Die Purchase Requisition ID ist der zentrale Schlüssel, der alle Aktivitäten im Zusammenhang mit einer einzelnen Anforderung für Waren oder Dienstleistungen verknüpft. Jeder Purchase Requisitionsprozess, von der Erstellung bis zur finalen Genehmigung und dem Abschluss, wird unter dieser eindeutigen ID verfolgt. Im Process Mining ist dieses Attribut wichtig, um den End-to-End-Verlauf jeder Purchase Requisition zu rekonstruieren. Es ermöglicht die Analyse von Prozessvarianten, Durchlaufzeiten und Compliance für einzelne Fälle und bietet eine vollständige Ansicht des Purchase Requisitions-Lebenszyklus. Bedeutung Es ist wichtig, alle zusammenhängenden Ereignisse zu einer einzigen Prozessinstanz zu gruppieren, um eine vollständige End-to-End-Analyse des Lebenszyklus jeder Purchase Requisition zu ermöglichen. Datenquelle Dies ist in der Regel der Primärschlüssel in der HauptkopfDatentabelle für Purchase Requisitionen, wie z.B. PurchReqTable in Microsoft Dynamics 365. Beispiele PR-001254PR-001255PR-001256
	Letzte Datenaktualisierung LastDataIngestionTimestamp	Der Zeitstempel, wann die Daten zuletzt extrahiert und in das Process-Mining-Tool geladen wurden.
Beschreibung Dieses Attribut gibt die Aktualität der analysierten Daten an. Es zeigt Datum und Uhrzeit der letzten Datenaktualisierung aus dem Quellsystem. Dies ist kein Feld aus Dynamics 365 selbst, sondern MetaDaten, die während der Datenerfassung hinzugefügt wurden. Dieser Zeitstempel ist maßgeblich, damit Benutzer die Aktualität der Erkenntnisse verstehen. Er hilft ihnen zu wissen, ob sie EchtzeitDaten oder einen Schnappschuss von einem bestimmten Zeitpunkt betrachten, was die Relevanz ihrer Schlussfolgerungen beeinflusst. Bedeutung Es Hinweisrmiert Benutzer über die Aktualität der Daten und stellt sicher, dass sie den Analysezeitraum und die Relevanz der Erkenntnisse verstehen. Datenquelle Dieser Wert wird während des Datenerfassungs- oder ETL-Prozesses generiert und dem Datensatz hinzugefügt. Beispiele 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Quellsystem SourceSystemId	Das System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut identifiziert das Quellsystem, aus dem die Event-Daten stammen. In diesem Kontext wäre es 'Microsoft Dynamics 365'. In Umgebungen mit mehreren integrierten Systemen ist dieses Feld wichtig für die Datenherkunft und den Kontext. In der Analyse hilft es, Prozesse zu unterscheiden, die sich über mehrere Systeme erstrecken können, oder bestätigt, dass die Daten aus einer einzigen, autoritativen Quelle stammen. Dies ist wichtig für die Datenvalidierung und um sicherzustellen, dass die Analyse auf dem korrekten Datensatz basiert. Bedeutung Es liefert Kontext über den Ursprung der Daten, was wichtig für die Datengovernance, Validierung und in Umgebungen ist, in denen mehrere Systeme integriert sind. Datenquelle Dies ist ein statischer Wert, 'Microsoft Dynamics 365', der während des Datenextraktions- und Transformationsprozesses hinzugefügt wird. Beispiele Microsoft Dynamics 365 F&OD365MSD365
	Abteilung Department	Die Abteilung des Anfordernden oder den Antrag bearbeitet.ie Kostenstelle, die mit der Purchase Requisition verbunden ist.
Beschreibung Dieses Attribut spezifiziert die Geschäftseinheit oder Kostenstelle, die die Purchase Requisition initiiert hat, wie z.B. 'Marketing', 'IT' oder 'Operations'. Diese Information ist üblicherweise Teil des Purchase Requisitions-Headers. Die Segmentierung des Prozesses nach Abteilung ist maßgeblich für die vergleichende Analyse. Sie ermöglicht es Sie zu sehen, welche Abteilungen die längsten Durchlaufzeiten, die höchsten Ablehnungsraten oder den Antrag bearbeitet.ie häufigsten Änderungen aufweisen. Diese Erkenntnisse helfen, Prozessoptimierungen auf spezifische Abteilungsbedürfnisse zuzuschneiden. Bedeutung Es ermöglicht das Filtern und Vergleichen der Prozess-Performance über verschiedene Geschäftseinheiten hinweg, wodurch abteilungsspezifische Muster, Engpässe oder Ineffizienzen aufgedeckt werden. Datenquelle Diese Information wird oft im Purchase Requisitions-Header (PurchReqTable) gespeichert und ist mit der Konfiguration der Finanzdimensionen in Dynamics 365 verknüpft. Beispiele IT-AbteilungFinanzenOperations
	Benutzer User	Die Benutzer-ID oder den Antrag bearbeitet.er Name der Person, die die Aktivität ausgeführt hat.
Beschreibung Dieses Attribut identifiziert den Mitarbeiter oder Systembenutzer, der für die Ausführung eines spezifischen Prozessschritts verantwortlich ist, wie z.B. das Einreichen einer Purchase Requisition oder den Antrag bearbeitet.as Genehmigen einer Anfrage. Es kann eine Benutzer-ID, ein vollständiger Name oder eine E-Mail-Adresse sein. Die Analyse von Aktivitäten nach Benutzer hilft, Schulungsbedarfe, leistungsstarke Einzelpersonen oder Teams sowie die Arbeitslastverteilung zu identifizieren. Sie ist auch wesentlich für die Compliance-Analyse, wie z.B. die Trennung von Funktionen, und für das Verständnis, wie verschiedene Benutzerrollen mit dem Prozess interagieren. Bedeutung Es ermöglicht die Analyse des benutzerspezifischen Verhaltens, der Arbeitslast und der Leistungsfähigkeit, was wichtig für das Ressourcenmanagement und die Identifizierung von Schulungsmöglichkeiten ist. Datenquelle Typischerweise in Workflow-Verlaufstabellen (z.B. WorkflowTrackingStatusTable) oder Transaktionstabellen (z.B. PurchReqTable) zu finden, die mit einer Benutzertabelle (z.B. BenutzerInfo) verknüpft sind. Beispiele j.smitha.joness.patel
	Dringlichkeitsstufe UrgencyLevel	Eine Klassifizierung der Dringlichkeit der Purchase Requisition, wie 'Hoch', 'Mittel' oder 'Niedrig'.
Beschreibung Das Urgency Level oder den Antrag bearbeitet.ie Priorität gibt an, wie schnell die angeforderten Waren oder Dienstleistungen benötigt werden. Dieses Attribut wird oft verwendet, um den Genehmigungspfad zu beeinflussen oder den Antrag bearbeitet.ie Arbeit für Genehmigende zu priorisieren. Die Analyse dieses Attributs hilft festzustellen, ob das Prioritätssystem effektiv ist. Sie können beispielsweise die Durchlaufzeiten von Purchase Requisitionen mit 'hoher' Dringlichkeit mit denen mit 'geringer' Dringlichkeit vergleichen. Wenn es keinen signifikanten Unterschied gibt, kann dies darauf hindeuten, dass das Prioritätsfeld ignoriert oder missbraucht wird, was eine wichtige Erkenntnis für das 'Urgency Level Impact Analysis' Dashboard ist. Bedeutung Es hilft zu beurteilen, ob Prioritätseinstellungen kritische Anfragen effektiv beschleunigen und deckt potenziellen Missbrauch der Dringlichkeitsklassifizierung auf. Datenquelle Dies könnte ein Standard- oder benutzerdefiniertes Feld in der PurchReqTable sein. Seine Existenz und sein Name können je nach SystemKonfiguration variieren. Beispiele HochMittelNiedrig
	Genehmigungsschritt ApprovalStep	Der Name oder den Antrag bearbeitet.ie Phase eines spezifischen Genehmigungsschritts im Workflow.
Beschreibung Dieses Attribut identifiziert die jeweilige Phase im Genehmigungs-Workflow, wie z.B. 'Manager-Genehmigung' oder 'Finanzgenehmigung'. Es bietet detailliertere Informationen als der allgemeine Aktivitätsname. Dieses Attribut ist wesentlich für die 'Engpassanalyse von Genehmigungsschritten'. Durch die Verfolgung der in jedem einzelnen Genehmigungsschritt verbrachten Zeit wird es möglich, genau zu bestimmen, welche Phasen Verzögerungen im Gesamtprozess verursachen. Dies ermöglicht gezielte Interventionen zur Verbesserung der Workflow-Effizienz. Bedeutung Es ermöglicht eine granulare Analyse des Genehmigungs-Workflows und macht es möglich, spezifische Phasen zu identifizieren, die Engpässe verursachen. Datenquelle Diese Information ist in den Workflow-Verlaufstabellen enthalten, wie z.B. WorkflowTrackingStatusTable, die jeden Schritt des konfigurierten Workflows detaillieren. Beispiele Manager-GenehmigungAbteilungsleiter-GenehmigungFinanzprüfung
	Gesamtbetrag der Purchase Requisition RequisitionTotalAmount	Der Gesamtbetrag der Purchase Requisition.
Beschreibung Dieses Attribut erfasst den Gesamtwert aller Positionen einer Purchase Requisition. Der Betrag beeinflusst oft die Komplexität des Genehmigungs-Workflows, wobei Purchase Requisitionen mit höherem Wert mehr Genehmigungsschritte erfordern. In der Prozessanalyse ist dieses Attribut wesentlich für eine wertbasierte Filterung und Analyse. Es hilft, Fragen zu beantworten wie: 'Dauert die Genehmigung von Purchase Requisitionen mit hohem Wert länger?' oder 'Welchen Wert haben Purchase Requisitionen, die derzeit im Prozess feststecken?'. Dies liefert einen finanziellen Kontext zur Prozessleistung. Bedeutung Es fügt der Analyse eine finanzielle Dimension hinzu, die die Priorisierung von hochpreisigen Fälle ermöglicht und versteht, wie monetärer Wert das Prozessverhalten beeinflusst. Datenquelle Dieser Wert befindet sich in der Regel in der KopfDatentabelle für Purchase Requisitionen oder wird als Summe der Positionsbeträge aus der Purchase Requisitionspositionstabelle (PurchReqLine) berechnet. Beispiele 1500.0025000.50500.75
	Purchase Requisitionsstatus RequisitionStatus	Der aktuelle oder endgültige Status der Purchase Requisition.
Beschreibung Dieses Attribut gibt den Gesamtstatus der Purchase Requisition zu jedem Zeitpunkt an, z.B. 'In Prüfung', 'Genehmigt', 'Abgelehnt' oder 'Abgeschlossen'. Dies ist oft ein Case-Level-Attribut, das das Endergebnis darstellt. Die Analyse des finalen Status hilft, die Gesamtergebnisse des Prozesses zu verstehen. Zum Beispiel kann eine hohe Anzahl von 'Abgelehnten' oder 'Zurückgezogenen' Purchase Requisitionen auf Probleme in der initialen Anfragephase oder einen umständlichen Genehmigungsprozess hindeuten. Es ist maßgeblich für die Messung von Erfolgsquoten und Prozesseffizienz. Bedeutung Es bietet ein klares Ergebnis für jeden Case und ermöglicht die Analyse von Genehmigungs-, Ablehnungs- und Rückzugsraten, die wichtige Leistungsindikatoren sind. Datenquelle Das Statusfeld befindet sich in der Regel in der KopfDatentabelle für Purchase Requisitionen, PurchReqTable, und wird oft als 'Status' oder 'PurchReqStatus' bezeichnet. Beispiele GenehmigtIn PrüfungAbgelehntEntwurf
	Anzahl der Änderungen AmendmentCount	Die Gesamtzahl der Änderungen einer Purchase Requisition.
Beschreibung Dies ist ein berechnetes numerisches Attribut, das die Vorkommen der Aktivität 'Purchase Requisition geändert' für jeden Purchase Requisitions-Case zählt. Dieses Attribut ist wesentlich für das Dashboard 'Häufigkeit der Purchase Requisitionsänderungen' und den KPI 'Verhältnis der Purchase Requisitionsänderungen'. Es quantifiziert den Umfang der Nacharbeit pro Case und erleichtert es, Purchase Requisitionen, Abteilungen oder Benutzer zu identifizieren, die mit einem hohen Grad an Änderungen und Ineffizienz verbunden sind. Dies hilft, die Anstrengungen zur Verbesserung der initialen Anfragequalität zu fokussieren. Bedeutung Es quantifiziert die Nacharbeit innerhalb eines Case und erleichtert die Messung und Analyse der Häufigkeit von Änderungen und deren Auswirkungen auf die Prozesseffizienz. Datenquelle Dies ist ein berechnetes Attribut. Es wird während der Datentransformation abgeleitet, indem die Aktivitäten 'Purchase Requisition geändert' für jede eindeutige PurchaseRequisitionId gezählt werden. Beispiele 013
	Bestellnummer PurchaseOrderNumber	Die Kennung der aus der Purchase Requisition erstellten Bestellung.
Beschreibung Dieses Attribut speichert die eindeutige ID der Bestellung, die aus einer genehmigten Purchase Requisition generiert wurde. Es dient als Verbindung zwischen dem Purchase Requisitionsprozess und dem nachgelagerten Beschaffungsprozess. Die Verfolgung dieser Nummer ist unerlässlich für die Analyse der 'Konversionszeit von Purchase Requisition zu Bestellung'. Sie bestätigt, dass eine Purchase Requisition erfolgreich in die nächste Phase des Purchase-to-Pay-Zyklus übergegangen ist und ermöglicht eine End-to-End-Prozessanalyse, die sowohl Purchase Requisitionen als auch Bestellungen umfasst. Bedeutung Es verbindet die Purchase Requisition mit der nachfolgenden Bestellung und ermöglicht so die Analyse der Purchase Requisitions-zu-Bestellungs-Konvertierung sowie die Verknüpfung verschiedener Phasen des P2P-Prozesses. Datenquelle Diese Information ist üblicherweise in der Purchase Requisitionspositionstabelle (PurchReqLine) zu finden, nachdem eine Bestellung erstellt wurde, und verknüpft diese zurück mit der PurchTable. Beispiele PO-000987PO-000988PO-000989
	Genehmigergruppe ApproverGroup	Die Benutzergruppe oder Rolle, die für einen Genehmigungsschritt verantwortlich ist.
Beschreibung Dieses Attribut identifiziert die Gruppe, Rolle oder Warteschlange, die für die Bearbeitung einer spezifischen Genehmigungsaufgabe zugewiesen ist, z.B. 'Finanzgenehmigende' oder 'IT-Manager'. Die Analyse der Prozessleistung nach Genehmigenden-Gruppe ist maßgeblich, um die Arbeitslastverteilung zu verstehen und zu identifizieren, welche Gruppen möglicherweise unterbesetzt sind oder zusätzliche Schulungen benötigen. Es unterstützt direkt das Dashboard zur 'Engpassanalyse von Genehmigungsschritten', indem es ermöglicht, die Leistung nach den für Genehmigungen verantwortlichen Teams aufzuschlüsseln. Bedeutung Es hilft, Leistungsunterschiede zwischen Genehmigungsteams zu identifizieren, was potenzielle Ressourcenengpässe oder Schulungsbedarfe innerhalb spezifischer Gruppen aufzeigt. Datenquelle Diese Information ist Teil des Workflow-Verlaufs (z.B. WorkflowTrackingStatusTable), der den Antrag bearbeitet.en zugewiesenen Benutzer oder den Antrag bearbeitet.ie Benutzergruppe für jede Aufgabe aufzeichnet. Beispiele FinanzgenehmigerIT-ManagerFührungsebene
	Genehmigungs-Workflow-Pfad ApprovalWorkflowPath	Eine Darstellung der Abfolge der den Antrag bearbeitet.urchgeführten Genehmigungsschritte.
Beschreibung Dieses Attribut ist ein abgeleitetes Feld, das die Reihenfolge der Genehmigungsschritte für eine bestimmte Purchase Requisition konkateniert, wie z.B. 'Manager-Genehmigung -> Abteilungsleiter-Genehmigung -> Finanzgenehmigung'. Es fasst effektiv die Prozessvariante für den Genehmigungs-Subprozess zusammen. Dies ist maßgeblich für das Dashboard 'Compliance Deviation Monitor'. Durch den Vergleich des tatsächlichen Workflow-Pfades mit einem vordefinierten Standard- oder erwarteten Pfad wird es einfach, nicht-konforme oder ungewöhnliche Prozessabläufe zu kennzeichnen, die Richtlinienverletzungen oder operationelle Risiken darstellen können. Bedeutung Es vereinfacht die Compliance-Analyse, indem es eine klare String-Repräsentation der Prozessvariante liefert, wodurch Abweichungen von Standardprozeduren leicht zu erkennen sind. Datenquelle Dieses Attribut ist kein Standardfeld. Es muss durch die chronologische Verkettung der 'ApprovalStep'-Werte für jeden Case während der Datentransformation abgeleitet werden. Beispiele Manager -> DirektorManager -> Direktor -> VP FinanzenManager -> Automatisch genehmigt
	Ist erstmalig genehmigt IsFirstPass	Ein Flag, das anzeigt, ob eine Purchase Requisition ohne vorherige Änderungen oder Ablehnungen genehmigt wurde.
Beschreibung Dies ist ein berechnetes boolesches Attribut, das 'Ja' ist, wenn der Genehmigungspfad einer Purchase Requisition keine Aktivitäten wie 'Purchase Requisition geändert' oder 'Genehmigungsschritt abgelehnt' enthielt. Andernfalls ist es 'false'. Dieses Attribut unterstützt direkt den KPI 'Genehmigungsrate im ersten Durchgang der Purchase Requisition'. Es vereinfacht die Analyse der Prozesseffizienz, indem es einen klaren, Case-Level-Indikator für Nacharbeit bereitstellt. Eine niedrige Rate an Genehmigungen im ersten Durchgang weist auf Probleme mit der initialen Datenqualität oder unklare Anforderungen hin und signalisiert eine Chance zur Prozessoptimierung. Bedeutung Es misst direkt die Prozessqualität und -effizienz, indem es Fälle identifiziert, die Nacharbeit erforderten, und unterstützt KPIs, die sich auf "First-Time-Right"-Raten konzentrieren. Datenquelle Dies ist ein berechnetes Attribut. Es erfordert die Analyse der gesamten Aktivitätssequenz für jeden Case während der Datentransformation, um das Fehlen von Nacharbeitsaktivitäten vor der Genehmigung zu überprüfen. Beispiele JaNein
	Währung Currency	Der Währungscode für den Purchase Requisitionsbetrag.
Beschreibung Dieses Attribut spezifiziert die Währung, zum Beispiel USD, EUR, GBP, in der den Antrag bearbeitet.er Gesamtbetrag der Purchase Requisition denominiert ist. Es ist maßgeblich für die Finanzanalyse, insbesondere in multinationalen Organisationen, die mit mehreren Währungen umgehen. Die Verwendung des Währungsattributs ermöglicht eine korrekte Handhabung und Aggregation von FinanzDaten. Es stellt sicher, dass Geldwerte richtig interpretiert werden und ermöglicht Umrechnungen in eine gemeinsame Währung für genaue Berichterstattung und Vergleiche über verschiedene Regionen oder Geschäftseinheiten hinweg. Bedeutung Es bietet den notwendigen Kontext für Finanzattribute und stellt ... sicher eine genaue Interpretation und Aggregation monetärer Werte in Mehrwährungsumgebungen. Datenquelle Dieses Feld befindet sich in der Regel in der KopfDatentabelle für Purchase Requisitionen, PurchReqTable, neben den Betragsfeldern. Beispiele USDEURGBP

Erforderlich Empfohlen Optional

Purchase-to-Pay – Purchase Requisitions-Aktivitäten

Dies sind die wesentlichen Prozessschritte und Meilensteine, die in Ihrem Event Log erfasst werden müssen, um Ihren Purchase Requisitions-Workflow genau zu entdecken und zu analysierenn.

7 Empfohlen 5 Optional

	Aktivität	Beschreibung
	Anforderung erstellt	Dieses Ereignis markiert die initiale Erstellung des Purchase RequisitionsDatensatzes im Entwurfsstatus. Es wird durch die Identifizierung des Erstellungs-Zeitstempels des Purchase Requisitions-Headers erfasst.
Bedeutung Als Prozessstart ist diese Aktivität unerlässlich für die Messung der gesamten Purchase Requisitions-Lebenszykluszeit und die Analyse des täglichen Purchase Requisitions-Durchsatzvolumens. Datenquelle Diese Aktivität wird aus dem Feld 'createdDateTime' in der 'PurchReqTable' für jede neue Purchase Requisition ID abgeleitet. Erfassen Verwenden Sie den Erstellungs-Zeitstempel des Datensatzes in der PurchReqTable. Ereignistyp inferred
	Bestellung erstellt	Eine genehmigte Purchase Requisitionsposition wird in eine Bestellposition umgewandelt, was die Übergabe an das Beschaffungsteam signalisiert. Dies wird erfasst, indem die Purchase Requisitionsposition mit einer Bestellposition verknüpft wird.
Bedeutung Dies ist ein kritischer Meilenstein, der den Antrag bearbeitet.ie Purchase Requisition mit dem nachgelagerten Beschaffungsprozess verbindet. Er ist wesentlich für die Messung des KPI 'Konversionszeit von Purchase Requisition zu Bestellung'. Datenquelle Abgeleitet durch das Auffinden eines Datensatzes in der Tabelle 'PurchLine', der den Antrag bearbeitet.ie ID einer `PurchReqLine` referenziert, die dem Purchase Requisitions-Case zugeordnet ist. Erfassen Verknüpfen Sie `PurchReqLine` mit `PurchLine` über das verknüpfende Referenzfeld (z.B. `PurchReqLineRefId`). Ereignistyp inferred
	Genehmigungsschritt genehmigt	Ein Genehmiger schließt seine zugewiesene Aufgabe ab und genehmigt die Purchase Requisition für seine Prozessstufe. Dies verschiebt die Purchase Requisition zum nächsten Schritt oder zur finalen Genehmigung.
Bedeutung Misst die Bearbeitungszeit für jede Genehmigungsstufe und hilft, effiziente Teile des Workflows zu identifizieren. Es ist eine Schlüsselkomponente der Variantenanalyse. Datenquelle Explizit in der `WorkflowTrackingStatusTable` protokolliert, wenn ein Benutzer ein Arbeitselement mit einem 'Genehmigen'-Ergebnis abschließt. Erfassen Identifizieren Sie 'WorkItemCompleted'-Ereignisse mit einem 'Genehmigen'-Ergebnis in den Workflow-Verlaufnprotokollen. Ereignistyp explicit
	Purchase Requisition abgelehnt	Die Purchase Requisition wurde während des Genehmigungs-Workflows abgelehnt und wird nicht weiterbearbeitet. Dies stellt einen terminalen Fehlerzustand für die Purchase Requisition dar.
Bedeutung Dieses Endereignis ist maßgeblich für die Analyse der gesamten Ablehnungsraten und das Verständnis der finanziellen oder operativen Auswirkungen fehlgeschlagener Anfragen. Datenquelle Explizit aus der `WorkflowTrackingStatusTable` erfasst bei Workflow-Abschluss mit dem Status 'Abgelehnt', wodurch das Statusfeld der `PurchReqTable` aktualisiert wird. Erfassen Filtern Sie nach Workflow-'Abschluss'-Ereignissen mit dem Status 'Abgelehnt' oder verfolgen Sie Statusänderungen in der `PurchReqTable`. Ereignistyp explicit
	Purchase Requisition abgeschlossen	Die gesamte Purchase Requisition gilt als abgeschlossen, d. h. alle ihre Positionen wurden zu Bestellungen verarbeitet oder storniert. Dies ist ein finaler, erfolgreicher Endzustand.
Bedeutung Diese Aktivität kennzeichnet den erfolgreichen Abschluss des Lebenszyklus der Purchase Requisition. Sie ist der finale Endpunkt für die Messung der gesamten End-to-End-Prozessdauer. Datenquelle Dieser Status wird in der Regel berechnet oder abgeleitet. Er tritt auf, wenn alle zugehörigen 'PurchReqLine'-Datensätze einen terminalen Status erreicht haben (z.B. 'Abgeschlossen', 'Storniert'). Erfassen Leiten Sie dieses Ereignis ab, indem Sie prüfen, ob alle untergeordneten `PurchReqLine`-Datensätze für eine `PurchReqTable` einen finalen Status haben. Ereignistyp calculated
	Purchase Requisition genehmigt	Die Purchase Requisition hat alle erforderlichen Genehmigungsschritte im Workflow erfolgreich durchlaufen. Diese Aktivität wird erfasst, wenn die Workflow-Instanz mit einem finalen genehmigten Status abgeschlossen wird.
Bedeutung Dies ist ein wichtiger Meilenstein, der den Antrag bearbeitet.as Ende des Genehmigungszyklus und den Beginn der Beschaffungsphase markiert. Es ist das Endereignis für den KPI 'Durchlaufzeit der Purchase Requisitionsgenehmigung'. Datenquelle Explizit aus der `WorkflowTrackingStatusTable` erfasst, wenn der Workflow abgeschlossen ist. Dies aktualisiert auch das Feld 'Status' in der `PurchReqTable` auf 'Genehmigt'. Erfassen Filtern Sie nach Workflow-'Abschluss'-Ereignissen mit dem Status 'Genehmigt' oder verfolgen Sie Statusänderungen in der `PurchReqTable`. Ereignistyp explicit
	Purchase Requisition zur Genehmigung eingereicht	Der Benutzer reicht die abgeschlossene Purchase Requisition ein, was den formellen Genehmigungs-Workflow initiiert. Dies ist eine explizite Aktion, die von der Workflow-Engine des Systems protokolliert wird.
Bedeutung Diese Aktivität ist ein kritischer Meilenstein, der den Antrag bearbeitet.en Genehmigungszyklus einleitet. Sie ist der Ausgangspunkt für die Messung der 'Durchlaufzeit der Purchase Requisitionsgenehmigung' und der 'Genehmigungsrate im ersten Durchgang'. Datenquelle Aus der `WorkflowTrackingStatusTable` oder einer ähnlichen Workflow-Verlaufntabelle erfasst, wo ein 'Einreichungs'-Ereignis für die Purchase Requisition protokolliert wird. Erfassen Filtern Sie Workflow-Verlaufnprotokolle nach dem Ereignistyp 'Einreichung' oder 'Start', der mit der Purchase Requisition verknüpft ist. Ereignistyp explicit
	Genehmigungsschritt abgelehnt	Ein Genehmiger lehnt seine zugewiesene Aufgabe ab und sendet die Purchase Requisition in der Regel zur Korrektur an den Initiator zurück. Dies ist eine explizite Aktion, die von der Workflow-Engine protokolliert wird.
Bedeutung Diese Aktivität ist die Basis für die Berechnung der 'Ablehnungsrate von Purchase Requisitionen' und die Identifizierung, in welchen Phasen Ablehnungen am häufigsten auftreten, wobei Bereiche für Prozessoptimierungen hervorgehoben werden. Datenquelle Explizit in der `WorkflowTrackingStatusTable` protokolliert, wenn ein Benutzer ein Arbeitselement mit einem 'Ablehnen'-Ergebnis abschließt. Erfassen Identifizieren Sie 'WorkItemCompleted'-Ereignisse mit einem 'Ablehnen'-Ergebnis in den Workflow-Verlaufnprotokollen. Ereignistyp explicit
	Genehmigungsschritt gestartet	Eine einzelne Genehmigungsaufgabe wird einem Benutzer oder einer Gruppe als Teil des Workflows zugewiesen. Dies stellt den Beginn einer Warte- oder Bearbeitungszeit für einen spezifischen Genehmiger dar.
Bedeutung Diese Aktivität ist maßgeblich für die 'Engpassanalyse von Genehmigungsschritten' und ermöglicht die Messung von Wartezeiten für spezifische Genehmigungsphasen. Datenquelle Aus der `WorkflowTrackingStatusTable` erfasst, wenn ein neues Arbeitselement für die Workflow-Instanz der Purchase Requisition erstellt und zugewiesen wird. Erfassen Identifizieren Sie 'WorkItemCreated'- oder ähnliche Ereignisse in den Workflow-Verlaufnprotokollen für die spezifische Purchase Requisition. Ereignistyp explicit
	Purchase Requisition geändert	Dieses Ereignis tritt auf, wenn ein Benutzer eine eingereichte Purchase Requisition aus dem Workflow zurückzieht, um Änderungen vorzunehmen. Die Aktivität wird in der Regel durch eine Rückrufaktion gefolgt von einer späteren erneuten Einreichung erfasst.
Bedeutung Die Verfolgung von Änderungen ist maßgeblich, um Nacharbeit, unklare initiale Anfragen und Prozesseffizienzen zu identifizieren. Sie unterstützt direkt das Dashboard 'Häufigkeit der Purchase Requisitionsänderungen'. Datenquelle Kann aus der Workflow-Verlauf (`WorkflowTrackingStatusTable`) abgeleitet werden, indem eine 'Rückruf'- oder 'Änderungsanforderung'-Aktion erkannt wird. Es kann auch aus Änderungen am Feld 'modifiedDateTime' in der `PurchReqTable` nach der Einreichung abgeleitet werden. Erfassen Workflow-Rückrufereignisse oder Datensatz-Versionsänderungen zwischen Einreichungsereignissen erkennen. Ereignistyp inferred
	Purchase Requisition zurückgezogen	Der Ersteller oder ein autorisierter Benutzer storniert die Purchase Requisition, nachdem sie eingereicht wurde. Diese Aktion beendet den Workflow und die Anfrage.
Bedeutung Die Verfolgung von Rückzügen hilft, Probleme bei der Bedarfsplanung oder übermäßig komplexen Prozessen zu identifizieren. Dies unterstützt das Dashboard 'Einblicke in Purchase Requisitionsrückzüge'. Datenquelle Dies wird aus einer Statusänderung in der 'PurchReqTable' zu 'Abbrechenled' oder aus einem 'Abbrechen'-Ereignis in der 'WorkflowTrackingStatusTable' abgeleitet. Erfassen Statusänderung auf 'Storniert' in der `PurchReqTable` oder ein Workflow-Stornierungsereignis erkennen. Ereignistyp inferred
	Purchase Requisitionsposition abgeschlossen	Eine einzelne Position der Purchase Requisition wird als vollständig bearbeitet betrachtet. Dies geschieht in der Regel, nachdem die Position vollständig in eine Bestellung umgewandelt wurde.
Bedeutung Bietet detaillierte Informationen zur Erfüllung von Purchase Requisitionen und hilft zu identifizieren, ob Purchase Requisitionen teilweise oder vollständig in Bestellungen umgewandelt werden. Datenquelle Abgeleitet aus dem Statusfeld der einzelnen `PurchReqLine`-Tabelle. Ein Status, der "bestellt" oder "erhalten" anzeigt, würde den Abschluss bedeuten. Erfassen Überwachen Sie das Statusfeld in der `PurchReqLine`-Tabelle auf einen Endwert wie 'Invoiced' oder 'Closed'. Ereignistyp inferred

Extraktionsanleitungen

So rufen Sie Ihre Daten aus Microsoft Dynamics 365 ab

Schritte

Auf den Datenmanagement-Arbeitsbereich zugreifen: Melden Sie sich bei Microsoft Dynamics 365 an und bewältigen Sie zum Workspaces-Menü. Wählen Sie Daten management, um die zentrale Drehscheibe für Datenimport- und -exportvorgänge zu öffnen.
Neues Exportprojekt erstellen: Innerhalb des Datenmanagement-Arbeitsbereichs klicken Sie auf die Kachel Export. Geben Sie einen eindeutigen Group name, eine beschreibende Description an und setzen Sie die Project category auf Project. Dies organisiert Ihre Datenextraktionsaufgaben.
Datenentitäten hinzufügen: Fügen Sie die erforderlichen Standard-Datenentitäten zu Ihrem Projekt hinzu. Klicken Sie auf Add entity und suchen Sie nach jeder den Antrag bearbeitet.er folgenden, indem Sie sie einzeln hinzufügen:
- Purchase requisition headers
- Purchase requisition lines
- Workflow tracking status table
- Workflow work items
- Purchase order lines V2
Exportformat definieren: Für jede hinzugefügte Entität wählen Sie ein Target data format wie CSV oder Excel. CSV wird im Allgemeinen für Leistungsfähigkeit und Kompatibilität mit Datentransformationstools empfohlen.
Datenfilter anwenden: Wählen Sie eine Entität aus, dann klicken Sie auf die Schaltfläche Filter. Auf der Registerkarte Range geben Sie die Legal entity (Unternehmenscode) an, um sicherzustellen, dass Sie Daten aus der korrekten Geschäftseinheit extrahieren. Es ist auch wichtig, einen Datumsfilter auf das Feld Created date and time der Entität Purchase requisition headers anzuwenden, um das Datenvolumen zu begrenzen. Wir empfehlen, mit einem Zeitraum von 3 bis 6 Monaten zu beginnen.
Exportauftrag ausführen: Sobald alle Entitäten und Filter konfiguriert sind, klicken Sie auf Export im Aktionsbereich. Das System erstellt ein Auftragspaket und beginnt mit der Verarbeitung. Sie können den Fortschritt des Auftrags im Bereich Job history überwachen.
Datenpaket herunterladen: Nachdem der Exportauftrag erfolgreich abgeschlossen wurde, bewältigen Sie zu den Details des Job history und klicken Sie auf Download package. Dadurch wird eine ZIP-Datei heruntergeladen, die die separaten Datendateien für jede Entität enthält.
RohDaten in Event Log umwandeln: Die exportierten Dateien stellen rohe Systemtabellen dar, nicht ein finales Event Log. Sie müssen ein externes Tool wie Python, Power Query oder eine ETL-Plattform verwenden, um die Daten zu kombinieren und umzuformen. Dies beinhaltet:
- Das Verknüpfen der Kopf- und Positionsdateien.
- Das Verknüpfen von Workflow-Daten mit Purchase Requisitionen unter Verwendung der CorrelationId und des RecId des Purchase Requisitionskopfs.
- Das Pivotieren von Statusänderungen und Workflow-Ereignissen aus den Workflow-Tabellen in separate Aktivitätszeilen (Purchase Requisition eingereicht, Genehmigungsschritt genehmigt, etc.).
- Das Erstellen einer neuen Zeile für jede Aktivität mit dem korrekten ActivityName, Ereigniszeitpunkt (Event Time) und PurchaseRequisitionId.
Attribute berechnen und zuordnen: Während der Transformation ordnen Sie Quellspalten den erforderlichen Attributen wie Benutzer und Department zu. Berechnen Sie abgeleitete Attribute wie RequisitionTotalAmount durch Summieren der Positionsbeträge. Setzen Sie einen statischen Wert für (SourceSystem)Id (z.B. 'D365_F&O') und verwenden Sie die Ausführungszeit Ihres Skripts für LastDatenIngestionZeitstempel.
Ausgabe finalisieren und formatieren: Stellen Sie sicher, dass die finale Ausgabedatei eine einzelne CSV-Datei ist, wobei jede Zeile ein Ereignis im Prozess darstellt. Die Spalten müssen der erforderlichen Event Log-Struktur entsprechen, einschließlich PurchaseRequisitionId, ActivityName und Ereigniszeitpunkt (Event Time).

Konfiguration

Erforderliche Berechtigungen: Benutzer müssen über eine Sicherheitsrolle mit Berechtigungen für den Datenmanagement-Arbeitsbereich und Zugriff auf die spezifischen zu exportierenden Datenentitäten verfügen, wie zum Beispiel Datenmanagement-Administrator oder eine ähnliche benutzerdefinierte Rolle.
Wichtige Datenentitäten:
- Purchase requisition headers: Bietet den primären Case-ID, den Erstellungs-Zeitstempel und den Gesamtstatus.
- Purchase requisition lines: Enthält Details zu jedem angeforderten Artikel, einschließlich Beträgen und Verknüpfungen zu Bestellungen.
- Workflow tracking status table: Die primäre Quelle für Workflow-Ereignisse wie Einreichung, Genehmigung, Ablehnung und Rückruf.
- Workflow work items: Detailliert die spezifischen Aufgaben, die Benutzern während des Genehmigungsprozesses zugewiesen wurden.
- Purchase order lines V2: Wird verwendet, um den Erstellungs-Zeitstempel der Bestellung zu finden, die mit einer Purchase Requisitionsposition verknüpft ist.
Datumsbereichsfilterung: Es ist maßgeblich, einen Datumsbereichsfilter auf das Feld Created date and time der Entität Purchase requisition headers anzuwenden. Ein Bereich von 3-6 Monaten wird für die initiale Analyse empfohlen, um Datenvolumen und Prozesskenntnisse auszugleichen.
Unternehmenscode-Filterung: Wenden Sie immer einen Filter für die Legal entity an, um die Extraktion von Daten aus unbeabsichtigten oder Testunternehmen zu vermeiden. Dies reduziert die Datengröße erheblich und verbessert die Auftragsleistung.
Datentransformation: Diese Methode erfordert einen erheblichen Nachbearbeitungsschritt außerhalb von Dynamics 365, um die RohDatenexporte der Entitäten in ein strukturiertes Event Log umzuwandeln. Bereiten Sie sich auf die Verwendung eines Skript- oder ETL-Tools vor.

a Beispielabfrage config

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

Eine Azure Active Directory-Anwendung registrieren: Navigieren Sie zum Azure-Portal und registrieren Sie eine neue Anwendung. Diese Anwendung wird zur Authentifizierung mit der Dynamics 365 API verwendet. Notieren Sie die Anwendungs-(Client-)ID und die Verzeichnis-(Tenant-)ID.
Ein Client-Secret generieren: Innerhalb der neu registrierten Anwendung in Azure erstellen Sie ein neues Client-Secret unter 'Zertifikate & Secrets'. Kopieren Sie den Secret-Wert sicher, da er danach nicht mehr sichtbar sein wird.
API-Berechtigungen erteilen: Im Abschnitt 'API-Berechtigungen' der Anwendung fügen Sie eine Berechtigung für 'Dynamics ERP' hinzu. Wählen Sie 'Delegierte Berechtigungen' und gewähren Sie Financials.ReadWrite.All oder eine restriktivere schreibgeschützte Entsprechung. Erteilen Sie die Administratorzustimmung für die Berechtigungen.
Python-Bibliotheken installieren: Stellen Sie sicher, dass Python installiert ist. Installieren Sie dann die notwendigen Bibliotheken mit pip: pip install requests pandas.
Das Python-Skript konfigurieren: Kopieren Sie das bereitgestellte Python-Skript in eine Datei, zum Beispiel extract_d365_requisitions.py. Füllen Sie die Platzhaltervariablen am Anfang des Skripts aus: Ihre Dynamics 365 URL, Tenant-ID, Client-ID, Client-Secret, den gewünschten Datumsbereich und die Unternehmens-ID.
ODaten-Entitäten verstehen: Das Skript fragt drei HauptDatenentitäten ab: PurchaseRequisitionHeaders für die wichtigsten Purchase Requisitionsdetails, PurchaseRequisitionLinien für Positionsdetails einschließlich der Umwandlung in Bestellungen und WorkflowTrackingStatusTable für alle Workflow-bezogenen Ereignisse wie Einreichungen und Genehmigungen.
Das Skript ausführen: Führen Sie das Skript über Ihre Kommandozeile aus: python extract_d365_requisitions.py. Das Skript authentifiziert sich, ruft Daten für jede Aktivität ab und handhabt die API-Paginierung automatisch.
Datentransformation: Das Skript verarbeitet die rohen JSON-Daten aus den API-Aufrufen. Es formt die Daten um, indem es Datensätze durchläuft und eine separate Zeile für jede der 12 Geschäftsaktivitäten erstellt, wobei Quellfelder den Antrag bearbeitet.en Standard Event Log-Spalten wie PurchaseRequisitionId, ActivityName und Ereigniszeitpunkt (Event Time) zugeordnet werden.
Ereignisse kombinieren und standardisieren: Alle generierten Ereignisse werden in einer einzigen Listee gesammelt und dann in ein pandas DatenFrame konvertiert. Das Skript fügt statische Spalten wie (SourceSystem)Id und den LastDatenIngestionZeitstempel hinzu.
Nach CSV exportieren: Das finale DatenFrame wird in eine CSV-Datei namens d365_purchase_requisition_log.csv exportiert. Diese Datei ist für den direkten Upload in ein Process Mining-Tool formatiert. Überprüfen Sie, ob die Datei in UTF-8 kodiert ist.

Konfiguration

Voraussetzungen: Zugriff auf ein Azure-Abonnementnnement zur Registrierung einer Anwendung. Eine Anwendungs-(Client-)ID, ein Client-Secret und eine Tenant-ID aus Azure Active Directory. Der Benutzer, der den Antrag bearbeitet.as Skript ausführt, benötigt AnmeldeHinweisrmationen, die den Zugriff auf die Dynamics 365 Finance and Operations ODaten API-Endpunkte gewähren.
API-Endpunkt-Konfiguration: Das Skript benötigt die Basis-URL Ihrer Dynamics 365-Umgebung, in der Regel im Format https://[your-environment-name].operations.dynamics.com.
Datumsbereich: Setzen Sie die Variablen START_DATE und END_DATE im Skript, um das Extraktionsfenster zu definieren. Für die initiale Analyse wird ein Zeitraum von 3 bis 6 Monaten empfohlen, um Datenvolumen und Erkenntnisse auszugleichen.
Unternehmensfilter: Das Skript ist so konfiguriert, dass es mithilfe der Variable COMPANY_ID nach einer bestimmten juristischen Person filtert. Um Daten für alle Unternehmen zu extrahieren, müssen Sie möglicherweise den ODaten-Filter anpassen und cross-company=Ja in die Anfrage-Header aufnehmen.
Leistungsfähigkeit-Überlegungen: Das Skript ruft mithilfe von $select in den ODaten-Abfragen nur die für das Event Log notwendigen Spalten ab, was die Leistungsfähigkeit verbessert. Es handhabt auch die Paginierung, um große Datensätze zu verwalten, ohne die API zu überlasten. Bei sehr großen historischen Lasten sollten Sie erwägen, das Skript in Batches mit kleineren Datumsbereichen auszuführen.

a 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

Auf den Datenmanagement-Arbeitsbereich zugreifen: Melden Sie sich bei Microsoft Dynamics 365 an und bewältigen Sie zum Workspaces-Menü. Wählen Sie Daten management, um die zentrale Drehscheibe für Datenimport- und -exportvorgänge zu öffnen.
Neues Exportprojekt erstellen: Innerhalb des Datenmanagement-Arbeitsbereichs klicken Sie auf die Kachel Export. Geben Sie einen eindeutigen Group name, eine beschreibende Description an und setzen Sie die Project category auf Project. Dies organisiert Ihre Datenextraktionsaufgaben.
Datenentitäten hinzufügen: Fügen Sie die erforderlichen Standard-Datenentitäten zu Ihrem Projekt hinzu. Klicken Sie auf Add entity und suchen Sie nach jeder den Antrag bearbeitet.er folgenden, indem Sie sie einzeln hinzufügen:
- Purchase requisition headers
- Purchase requisition lines
- Workflow tracking status table
- Workflow work items
- Purchase order lines V2
Exportformat definieren: Für jede hinzugefügte Entität wählen Sie ein Target data format wie CSV oder Excel. CSV wird im Allgemeinen für Leistungsfähigkeit und Kompatibilität mit Datentransformationstools empfohlen.
Datenfilter anwenden: Wählen Sie eine Entität aus, dann klicken Sie auf die Schaltfläche Filter. Auf der Registerkarte Range geben Sie die Legal entity (Unternehmenscode) an, um sicherzustellen, dass Sie Daten aus der korrekten Geschäftseinheit extrahieren. Es ist auch wichtig, einen Datumsfilter auf das Feld Created date and time der Entität Purchase requisition headers anzuwenden, um das Datenvolumen zu begrenzen. Wir empfehlen, mit einem Zeitraum von 3 bis 6 Monaten zu beginnen.
Exportauftrag ausführen: Sobald alle Entitäten und Filter konfiguriert sind, klicken Sie auf Export im Aktionsbereich. Das System erstellt ein Auftragspaket und beginnt mit der Verarbeitung. Sie können den Fortschritt des Auftrags im Bereich Job history überwachen.
Datenpaket herunterladen: Nachdem der Exportauftrag erfolgreich abgeschlossen wurde, bewältigen Sie zu den Details des Job history und klicken Sie auf Download package. Dadurch wird eine ZIP-Datei heruntergeladen, die die separaten Datendateien für jede Entität enthält.
RohDaten in Event Log umwandeln: Die exportierten Dateien stellen rohe Systemtabellen dar, nicht ein finales Event Log. Sie müssen ein externes Tool wie Python, Power Query oder eine ETL-Plattform verwenden, um die Daten zu kombinieren und umzuformen. Dies beinhaltet:
- Das Verknüpfen der Kopf- und Positionsdateien.
- Das Verknüpfen von Workflow-Daten mit Purchase Requisitionen unter Verwendung der CorrelationId und des RecId des Purchase Requisitionskopfs.
- Das Pivotieren von Statusänderungen und Workflow-Ereignissen aus den Workflow-Tabellen in separate Aktivitätszeilen (Purchase Requisition eingereicht, Genehmigungsschritt genehmigt, etc.).
- Das Erstellen einer neuen Zeile für jede Aktivität mit dem korrekten ActivityName, Ereigniszeitpunkt (Event Time) und PurchaseRequisitionId.
Attribute berechnen und zuordnen: Während der Transformation ordnen Sie Quellspalten den erforderlichen Attributen wie Benutzer und Department zu. Berechnen Sie abgeleitete Attribute wie RequisitionTotalAmount durch Summieren der Positionsbeträge. Setzen Sie einen statischen Wert für (SourceSystem)Id (z.B. 'D365_F&O') und verwenden Sie die Ausführungszeit Ihres Skripts für LastDatenIngestionZeitstempel.
Ausgabe finalisieren und formatieren: Stellen Sie sicher, dass die finale Ausgabedatei eine einzelne CSV-Datei ist, wobei jede Zeile ein Ereignis im Prozess darstellt. Die Spalten müssen der erforderlichen Event Log-Struktur entsprechen, einschließlich PurchaseRequisitionId, ActivityName und Ereigniszeitpunkt (Event Time).

Konfiguration

Erforderliche Berechtigungen: Benutzer müssen über eine Sicherheitsrolle mit Berechtigungen für den Datenmanagement-Arbeitsbereich und Zugriff auf die spezifischen zu exportierenden Datenentitäten verfügen, wie zum Beispiel Datenmanagement-Administrator oder eine ähnliche benutzerdefinierte Rolle.
Wichtige Datenentitäten:
- Purchase requisition headers: Bietet den primären Case-ID, den Erstellungs-Zeitstempel und den Gesamtstatus.
- Purchase requisition lines: Enthält Details zu jedem angeforderten Artikel, einschließlich Beträgen und Verknüpfungen zu Bestellungen.
- Workflow tracking status table: Die primäre Quelle für Workflow-Ereignisse wie Einreichung, Genehmigung, Ablehnung und Rückruf.
- Workflow work items: Detailliert die spezifischen Aufgaben, die Benutzern während des Genehmigungsprozesses zugewiesen wurden.
- Purchase order lines V2: Wird verwendet, um den Erstellungs-Zeitstempel der Bestellung zu finden, die mit einer Purchase Requisitionsposition verknüpft ist.
Datumsbereichsfilterung: Es ist maßgeblich, einen Datumsbereichsfilter auf das Feld Created date and time der Entität Purchase requisition headers anzuwenden. Ein Bereich von 3-6 Monaten wird für die initiale Analyse empfohlen, um Datenvolumen und Prozesskenntnisse auszugleichen.
Unternehmenscode-Filterung: Wenden Sie immer einen Filter für die Legal entity an, um die Extraktion von Daten aus unbeabsichtigten oder Testunternehmen zu vermeiden. Dies reduziert die Datengröße erheblich und verbessert die Auftragsleistung.
Datentransformation: Diese Methode erfordert einen erheblichen Nachbearbeitungsschritt außerhalb von Dynamics 365, um die RohDatenexporte der Entitäten in ein strukturiertes Event Log umzuwandeln. Bereiten Sie sich auf die Verwendung eines Skript- oder ETL-Tools vor.

a Beispielabfrage config

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

Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template

Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template

Purchase-to-Pay – Purchase Requisitions-Attribute

Purchase-to-Pay – Purchase Requisitions-Aktivitäten

Extraktionsanleitungen

Dynamics 365 Daten Management Framework Export

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit Dynamics 365 ODaten REST API

Schritte

Konfiguration

a Beispielabfrage python

Microsoft Power BI Native Connector-Extraktion

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

Purchase-to-Pay – Purchase Requisition für schnellere Genehmigungen jetzt optimieren

Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template

Ihr Purchase-to-Pay-Purchase RequisitionsDaten-Template

Purchase-to-Pay – Purchase Requisitions-Attribute

Purchase-to-Pay – Purchase Requisitions-Aktivitäten

Extraktionsanleitungen

Dynamics 365 Daten Management Framework Export

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit Dynamics 365 ODaten REST API

Schritte

Konfiguration

a Beispielabfrage python

Microsoft Power BI Native Connector-Extraktion

Schritte

Konfiguration

a Beispielabfrage config

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Purchase-to-Pay – Purchase Requisition für schnellere Genehmigungen jetzt optimieren