> Kontinuierliche Prozessoptimierung > Purchase to Pay Bestellanforderung > Microsoft Dynamics 365 > Datenvorlage

Ihr Purchase-to-Pay-Bestellanforderungsdaten-Template

Microsoft Dynamics 365

Procure-to-Pay – Attribute der Bestellanforderung (18) Purchase to Pay - Bestellanforderungsaktivitäten (12) Extraktionsleitfäden (3)

Ihr Purchase-to-Pay-Bestellanforderungsdaten-Template

Diese Vorlage umreißt die zu erfassenden Schlüsselattribute und die entscheidenden Aktivitäten, die verfolgt werden müssen, um einen tiefen Einblick in Ihren Bestellanforderungsprozess zu ermöglichen. Sie bietet auch praktische Anleitungen zur Extraktion dieser Daten, um Ihnen zu helfen, Ihren Event Log effizient für eine detaillierte Analyse vorzubereiten.

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten zur Verfolgung
Extraktionsanleitung

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

Vorlage herunterladen

Procure-to-Pay – Attribute der Bestellanforderung

Dies sind die empfohlenen Datenfelder, die in Ihrem Event Log enthalten sein sollten, um eine umfassende Analyse Ihres Procure-to-Pay – Bestellanforderungs-Prozesses zu ermöglichen.

5 Erforderlich 7 Empfohlen 6 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des spezifischen Geschäftsereignisses oder Schritts, der im Bestellanforderungsprozess aufgetreten ist.
Beschreibung Dieses Attribut erfasst den Namen jeder Aktivität, die innerhalb des Lebenszyklus der Bestellanforderung durchgeführt wird. Beispiele sind 'Bestellanforderung erstellt', 'Genehmigungsschritt genehmigt' und 'Bestellung erstellt'. Diese Aktivitäten bilden die Knoten in der entdeckten Prozesslandkarte. Die Analyse der Sequenz, Häufigkeit und Dauer zwischen diesen Aktivitäten ist der Kern des 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 Prozesslandkarte und ermöglicht es, den Bestellanforderungs-Workflow zu visualisieren, zu analysieren und zu verstehen. Datenquelle Dies wird typischerweise aus Statusänderungsprotokollen, Workflow-Verlaufstabellen oder spezifischen Ereignistabellen innerhalb von Microsoft Dynamics 365 abgeleitet, wie z.B. WorkflowTrackingStatusTable. Beispiele Bestellanforderung zur Genehmigung eingereichtGenehmigungsschritt genehmigtBestellanforderung geändert
	Bestellanforderungs-ID PurchaseRequisitionId	Der eindeutige Identifikator für eine Bestellanforderung, der als primärer Case-Identifikator 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 Bestellanforderungsprozess, von der Erstellung bis zur finalen Genehmigung und dem Abschluss, wird unter dieser eindeutigen ID verfolgt. Im Process Mining ist dieses Attribut grundlegend, um den End-to-End-Verlauf jeder Bestellanforderung zu rekonstruieren. Es ermöglicht die Analyse von Prozessvarianten, Zykluszeiten und Compliance für einzelne Cases und bietet eine vollständige Ansicht des Bestellanforderungs-Lebenszyklus. Bedeutung Es ist essenziell, alle zusammenhängenden Ereignisse zu einer einzigen Prozessinstanz zu gruppieren, um eine vollständige End-to-End-Analyse des Lebenszyklus jeder Bestellanforderung zu ermöglichen. Datenquelle Dies ist typischerweise der Primärschlüssel in der Hauptkopfdatentabelle für Bestellanforderungen, wie z.B. PurchReqTable in Microsoft Dynamics 365. Beispiele PR-001254PR-001255PR-001256
	Ereigniszeit EventTime	Der genaue Zeitstempel, wann eine spezifische Aktivität oder ein Ereignis aufgetreten ist.
Beschreibung Event Time, oder der Timestamp, 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 entscheidend für die Berechnung von Zykluszeiten, Dauern und Wartezeiten zwischen Aktivitäten. Es ermöglicht die Analyse der Prozessperformance, die Engpassidentifikation und die Überwachung der SLA-Compliance. Akkurate Timestamps sind essenziell für eine zuverlässige 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 Performance über die Zeit notwendig ist. Datenquelle Gefunden in Workflow-Historien- 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
	Letzte Datenaktualisierung LastDataIngestionTimestamp	Der Timestamp, 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 Timestamp ist entscheidend, 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 informiert 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 entscheidend 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 entscheidend 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 die Kostenstelle, die mit der Bestellanforderung verbunden ist.
Beschreibung Dieses Attribut spezifiziert die Geschäftseinheit oder Kostenstelle, die die Bestellanforderung initiiert hat, wie z.B. 'Marketing', 'IT' oder 'Operations'. Diese Information ist üblicherweise Teil des Bestellanforderungs-Headers. Die Segmentierung des Prozesses nach Abteilung ist entscheidend für die vergleichende Analyse. Sie ermöglicht es Ihnen zu sehen, welche Abteilungen die längsten Zykluszeiten, die höchsten Ablehnungsraten oder die häufigsten Änderungen aufweisen. Diese Erkenntnisse helfen, Prozessverbesserungen auf spezifische Abteilungsbedürfnisse zuzuschneiden. Bedeutung Es ermöglicht das Filtern und Vergleichen der Prozessperformance über verschiedene Geschäftseinheiten hinweg, wodurch abteilungsspezifische Muster, Engpässe oder Ineffizienzen aufgedeckt werden. Datenquelle Diese Information wird oft im Bestellanforderungs-Header (PurchReqTable) gespeichert und ist mit der Konfiguration der Finanzdimensionen in Dynamics 365 verknüpft. Beispiele IT-AbteilungFinanzenVorgänge
	Bearbeitungszeit ProcessingTime	Die aktive Arbeitszeit, die für eine bestimmte Aufgabe aufgewendet wird.
Beschreibung Bearbeitungszeit stellt die Dauer dar, die eine Ressource aktiv mit der Ausführung einer Aufgabe verbringt. Sie wird als Differenz zwischen Endzeit und Startzeit einer Aktivität berechnet. Im Gegensatz zur Zykluszeit schließt sie Warte- oder Queue-Zeiten aus. Diese berechnete Metrik ist entscheidend, um die Ressourceneffizienz und den tatsächlichen Aufwand für jeden Prozessschritt zu verstehen. Sie hilft bei der 'Genehmigungsschritt-Engpassanalyse', indem sie zwischen langen Bearbeitungszeiten, die auf eine komplexe Aufgabe hindeuten können, und langen Queue-Zeiten, die ein Problem mit der Ressourcenverfügbarkeit nahelegen, unterscheidet. Bedeutung Es misst die aktive Arbeitsdauer für Aktivitäten und hilft, zwischen wertschöpfender Zeit und Wartezeit für eine genaue Engpassanalyse zu unterscheiden. Datenquelle Dies wird während der Datentransformation berechnet, indem die Startzeit einer Aktivität von ihrer Endzeit abgezogen wird. Dies erfordert, dass sowohl StartTime als auch EndTime für jede Aktivität vorhanden sind. Beispiele 864000003600000600000
	Benutzer User	Die User-ID oder der 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 Bestellanforderung oder das 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 Performance, was entscheidend 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. UserInfo) verknüpft sind. Beispiele j.smitha.joness.patel
	Dringlichkeitsstufe UrgencyLevel	Eine Klassifizierung der Dringlichkeit der Bestellanforderung, wie 'Hoch', 'Mittel' oder 'Niedrig'.
Beschreibung Das Urgency Level oder die 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 die Arbeit für Genehmigende zu priorisieren. Die Analyse dieses Attributs hilft festzustellen, ob das Prioritätssystem effektiv ist. Sie können beispielsweise die Zykluszeiten von Bestellanforderungen 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 die 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 Bestellanforderung RequisitionTotalAmount	Der gesamte monetäre Wert der Bestellanforderung.
Beschreibung Dieses Attribut erfasst den Gesamtwert aller Positionen einer Bestellanforderung. Der Betrag beeinflusst oft die Komplexität des Genehmigungs-Workflows, wobei Bestellanforderungen 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 Bestellanforderungen mit hohem Wert länger?' oder 'Welchen Wert haben Bestellanforderungen, 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 Cases ermöglicht und versteht, wie monetärer Wert das Prozessverhalten beeinflusst. Datenquelle Dieser Wert befindet sich typischerweise in der Kopfdatentabelle für Bestellanforderungen oder wird als Summe der Positionsbeträge aus der Bestellanforderungspositionstabelle (PurchReqLine) berechnet. Beispiele 1500.0025000.50500.75
	Status der Bestellanforderung RequisitionStatus	Der aktuelle oder finale Status der Bestellanforderung.
Beschreibung Dieses Attribut gibt den Gesamtstatus der Bestellanforderung 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' Bestellanforderungen auf Probleme in der initialen Anfragephase oder einen umständlichen Genehmigungsprozess hindeuten. Es ist entscheidend 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 typischerweise in der Kopfdatentabelle für Bestellanforderungen, PurchReqTable, und wird oft als 'Status' oder 'PurchReqStatus' bezeichnet. Beispiele GenehmigtIn PrüfungAbgelehntEntwurf
	Anzahl der Änderungen AmendmentCount	Die Gesamtzahl der Änderungen einer Bestellanforderung.
Beschreibung Dies ist ein berechnetes numerisches Attribut, das die Vorkommen der Aktivität 'Bestellanforderung geändert' für jeden Bestellanforderungs-Case zählt. Dieses Attribut ist wesentlich für das Dashboard 'Häufigkeit der Bestellanforderungsänderungen' und den KPI 'Verhältnis der Bestellanforderungsänderungen'. Es quantifiziert den Umfang der Nacharbeit pro Case und erleichtert es, Bestellanforderungen, 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 'Bestellanforderung geändert' für jede eindeutige PurchaseRequisitionId gezählt werden. Beispiele 013
	Bestellnummer PurchaseOrderNumber	Die Kennung der aus der Bestellanforderung erstellten Bestellung.
Beschreibung Dieses Attribut speichert die eindeutige ID der Bestellung, die aus einer genehmigten Bestellanforderung generiert wurde. Es dient als Verbindung zwischen dem Bestellanforderungsprozess und dem nachgelagerten Beschaffungsprozess. Die Verfolgung dieser Nummer ist unerlässlich für die Analyse der 'Konversionszeit von Bestellanforderung zu Bestellung'. Sie bestätigt, dass eine Bestellanforderung erfolgreich in die nächste Phase des Procure-to-Pay-Zyklus übergegangen ist und ermöglicht eine End-to-End-Prozessanalyse, die sowohl Bestellanforderungen als auch Bestellungen umfasst. Bedeutung Es verbindet die Bestellanforderung mit der nachfolgenden Bestellung und ermöglicht so die Analyse der Bestellanforderungs-zu-Bestellungs-Konvertierung sowie die Verknüpfung verschiedener Phasen des P2P-Prozesses. Datenquelle Diese Information ist üblicherweise in der Bestellanforderungspositionstabelle (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 entscheidend, 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 zugewiesenen Benutzer oder die Benutzergruppe für jede Aufgabe aufzeichnet. Beispiele FinanzgenehmigerIT-ManagerFührungsebene
	Genehmigungs-Workflow-Pfad ApprovalWorkflowPath	Eine Darstellung der Abfolge der durchgeführten Genehmigungsschritte.
Beschreibung Dieses Attribut ist ein abgeleitetes Feld, das die Reihenfolge der Genehmigungsschritte für eine bestimmte Bestellanforderung konkateniert, wie z.B. 'Manager-Genehmigung -> Abteilungsleiter-Genehmigung -> Finanzgenehmigung'. Es fasst effektiv die Prozessvariante für den Genehmigungs-Subprozess zusammen. Dies ist entscheidend 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 Bestellanforderung ohne vorherige Änderungen oder Ablehnungen genehmigt wurde.
Beschreibung Dies ist ein berechnetes boolesches Attribut, das 'true' ist, wenn der Genehmigungspfad einer Bestellanforderung keine Aktivitäten wie 'Bestellanforderung geändert' oder 'Genehmigungsschritt abgelehnt' enthielt. Andernfalls ist es 'false'. Dieses Attribut unterstützt direkt den KPI 'Genehmigungsrate im ersten Durchgang der Bestellanforderung'. 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 Prozessverbesserung. Bedeutung Es misst direkt die Prozessqualität und -effizienz, indem es Cases 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 truefalsch
	Währung Currency	Der Währungscode für den Bestellanforderungsbetrag.
Beschreibung Dieses Attribut spezifiziert die Währung, zum Beispiel USD, EUR, GBP, in der der Gesamtbetrag der Bestellanforderung denominiert ist. Es ist entscheidend 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 monetäre Werte 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 gewährleistet eine genaue Interpretation und Aggregation monetärer Werte in Mehrwährungsumgebungen. Datenquelle Dieses Feld befindet sich typischerweise in der Kopfdatentabelle für Bestellanforderungen, PurchReqTable, neben den Betragsfeldern. Beispiele USDEURGBP

Erforderlich Empfohlen Optional

Purchase to Pay - Bestellanforderungsaktivitäten

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

7 Empfohlen 5 Optional

	Aktivität	Beschreibung
	`Bestellung` erstellt	Eine genehmigte Bestellanforderungsposition wird in eine Bestellposition umgewandelt, was die Übergabe an das Beschaffungsteam signalisiert. Dies wird erfasst, indem die Bestellanforderungsposition mit einer Bestellposition verknüpft wird.
Bedeutung Dies ist ein kritischer Meilenstein, der die Bestellanforderung mit dem nachgelagerten Beschaffungsprozess verbindet. Er ist wesentlich für die Messung des KPI 'Konversionszeit von Bestellanforderung zu Bestellung'. Datenquelle Abgeleitet durch das Auffinden eines Datensatzes in der Tabelle 'PurchLine', der die ID einer `PurchReqLine` referenziert, die dem Bestellanforderungs-Case zugeordnet ist. Erfassen Verknüpfen Sie `PurchReqLine` mit `PurchLine` über das verknüpfende Referenzfeld (z.B. `PurchReqLineRefId`). Ereignistyp inferred
	Anforderung erstellt	Dieses Ereignis markiert die initiale Erstellung des Bestellanforderungsdatensatzes im Entwurfsstatus. Es wird durch die Identifizierung des Erstellungs-Timestamps des Bestellanforderungs-Headers erfasst.
Bedeutung Als Prozessstart ist diese Aktivität unerlässlich für die Messung der gesamten Bestellanforderungs-Lebenszykluszeit und die Analyse des täglichen Bestellanforderungs-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-Timestamp des Datensatzes in der PurchReqTable. Ereignistyp inferred
	Bestellanforderung abgelehnt	Die Bestellanforderung wurde während des Genehmigungs-Workflows abgelehnt und wird nicht weiterbearbeitet. Dies stellt einen terminalen Fehlerzustand für die Bestellanforderung dar.
Bedeutung Dieses Endereignis ist entscheidend 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
	Bestellanforderung abgeschlossen	Die gesamte Bestellanforderung 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 Bestellanforderung. Sie ist der finale Endpunkt für die Messung der gesamten End-to-End-Prozessdauer. Datenquelle Dieser Status wird typischerweise 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
	Bestellanforderung genehmigt	Die Bestellanforderung 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 das Ende des Genehmigungszyklus und den Beginn der Beschaffungsphase markiert. Es ist das Endereignis für den KPI 'Durchlaufzeit der Bestellanforderungsgenehmigung'. 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
	Bestellanforderung zur Genehmigung eingereicht	Der Benutzer reicht die abgeschlossene Bestellanforderung 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 Genehmigungszyklus einleitet. Sie ist der Ausgangspunkt für die Messung der 'Durchlaufzeit der Bestellanforderungsgenehmigung' und der 'Genehmigungsrate im ersten Durchgang'. Datenquelle Aus der `WorkflowTrackingStatusTable` oder einer ähnlichen Workflow-Historientabelle erfasst, wo ein 'Einreichungs'-Ereignis für die Bestellanforderung protokolliert wird. Erfassen Filtern Sie Workflow-Historienprotokolle nach dem Ereignistyp 'Einreichung' oder 'Start', der mit der Bestellanforderung verknüpft ist. Ereignistyp explicit
	Genehmigungsschritt genehmigt	Ein Genehmiger schließt seine zugewiesene Aufgabe ab und genehmigt die Bestellanforderung für seine Prozessstufe. Dies verschiebt die Bestellanforderung 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-Historienprotokollen. Ereignistyp explicit
	Bestellanforderung geändert	Dieses Ereignis tritt auf, wenn ein Benutzer eine eingereichte Bestellanforderung aus dem Workflow zurückzieht, um Änderungen vorzunehmen. Die Aktivität wird typischerweise durch eine Rückrufaktion gefolgt von einer späteren erneuten Einreichung erfasst.
Bedeutung Die Verfolgung von Änderungen ist entscheidend, um Nacharbeit, unklare initiale Anfragen und Prozesseffizienzen zu identifizieren. Sie unterstützt direkt das Dashboard 'Häufigkeit der Bestellanforderungsänderungen'. Datenquelle Kann aus der Workflow-Historie (`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
	Bestellanforderung zurückgezogen	Der Ersteller oder ein autorisierter Benutzer storniert die Bestellanforderung, 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 Bestellanforderungsrückzüge'. Datenquelle Dies wird aus einer Statusänderung in der 'PurchReqTable' zu 'Cancelled' oder aus einem 'Cancel'-Ereignis in der 'WorkflowTrackingStatusTable' abgeleitet. Erfassen Statusänderung auf 'Storniert' in der `PurchReqTable` oder ein Workflow-Stornierungsereignis erkennen. Ereignistyp inferred
	Bestellanforderungsposition abgeschlossen	Eine einzelne Position der Bestellanforderung wird als vollständig bearbeitet betrachtet. Dies geschieht typischerweise, nachdem die Position vollständig in eine Bestellung umgewandelt wurde.
Bedeutung Bietet detaillierte Informationen zur Erfüllung von Bestellanforderungen und hilft zu identifizieren, ob Bestellanforderungen 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
	Genehmigungsschritt abgelehnt	Ein Genehmiger lehnt seine zugewiesene Aufgabe ab und sendet die Bestellanforderung typischerweise zur Korrektur an den Initiator zurück. Dies ist eine explizite Aktion, die von der Workflow-Engine protokolliert wird.
Bedeutung Diese Aktivität ist grundlegend für die Berechnung der 'Ablehnungsrate von Bestellanforderungen' und die Identifizierung, in welchen Phasen Ablehnungen am häufigsten auftreten, wobei Bereiche für Prozessverbesserungen 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-Historienprotokollen. 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 entscheidend 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 Bestellanforderung erstellt und zugewiesen wird. Erfassen Identifizieren Sie 'WorkItemCreated'- oder ähnliche Ereignisse in den Workflow-Historienprotokollen für die spezifische Bestellanforderung. Ereignistyp explicit

Extraktionsleitfäden

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 navigieren Sie zum Workspaces-Menü. Wählen Sie Data 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 der 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 Performance 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 entscheidend, 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, navigieren 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 Bestellanforderungen unter Verwendung der CorrelationId und des RecId des Bestellanforderungskopfs.
- Das Pivotieren von Statusänderungen und Workflow-Ereignissen aus den Workflow-Tabellen in separate Aktivitätszeilen (Bestellanforderung eingereicht, Genehmigungsschritt genehmigt, etc.).
- Das Erstellen einer neuen Zeile für jede Aktivität mit dem korrekten ActivityName, EventTime und PurchaseRequisitionId.
Attribute berechnen und zuordnen: Während der Transformation ordnen Sie Quellspalten den erforderlichen Attributen wie User und Department zu. Berechnen Sie abgeleitete Attribute wie RequisitionTotalAmount durch Summieren der Positionsbeträge. Setzen Sie einen statischen Wert für SourceSystemId (z.B. 'D365_F&O') und verwenden Sie die Ausführungszeit Ihres Skripts für LastDataIngestionTimestamp.
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 EventTime.

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-Identifikator, den Erstellungs-Timestamp 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-Timestamp der Bestellung zu finden, die mit einer Bestellanforderungsposition verknüpft ist.
Datumsbereichsfilterung: Es ist entscheidend, 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.
OData-Entitäten verstehen: Das Skript fragt drei Hauptdatenentitäten ab: PurchaseRequisitionHeaders für die wichtigsten Bestellanforderungsdetails, PurchaseRequisitionLines 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 Standard Event Log-Spalten wie PurchaseRequisitionId, ActivityName und EventTime zugeordnet werden.
Ereignisse kombinieren und standardisieren: Alle generierten Ereignisse werden in einer einzigen Liste gesammelt und dann in ein pandas DataFrame konvertiert. Das Skript fügt statische Spalten wie SourceSystemId und den LastDataIngestionTimestamp hinzu.
Nach CSV exportieren: Das finale DataFrame 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-Abonnement zur Registrierung einer Anwendung. Eine Anwendungs-(Client-)ID, ein Client-Secret und eine Tenant-ID aus Azure Active Directory. Der Benutzer, der das Skript ausführt, benötigt Anmeldeinformationen, die den Zugriff auf die Dynamics 365 Finance and Operations OData API-Endpunkte gewähren.
API-Endpunkt-Konfiguration: Das Skript benötigt die Basis-URL Ihrer Dynamics 365-Umgebung, typischerweise 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 OData-Filter anpassen und cross-company=true in die Anfrage-Header aufnehmen.
Performance-Überlegungen: Das Skript ruft mithilfe von $select in den OData-Abfragen nur die für das Event Log notwendigen Spalten ab, was die Performance 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 navigieren Sie zum Workspaces-Menü. Wählen Sie Data 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 der 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 Performance 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 entscheidend, 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, navigieren 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 Bestellanforderungen unter Verwendung der CorrelationId und des RecId des Bestellanforderungskopfs.
- Das Pivotieren von Statusänderungen und Workflow-Ereignissen aus den Workflow-Tabellen in separate Aktivitätszeilen (Bestellanforderung eingereicht, Genehmigungsschritt genehmigt, etc.).
- Das Erstellen einer neuen Zeile für jede Aktivität mit dem korrekten ActivityName, EventTime und PurchaseRequisitionId.
Attribute berechnen und zuordnen: Während der Transformation ordnen Sie Quellspalten den erforderlichen Attributen wie User und Department zu. Berechnen Sie abgeleitete Attribute wie RequisitionTotalAmount durch Summieren der Positionsbeträge. Setzen Sie einen statischen Wert für SourceSystemId (z.B. 'D365_F&O') und verwenden Sie die Ausführungszeit Ihres Skripts für LastDataIngestionTimestamp.
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 EventTime.

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-Identifikator, den Erstellungs-Timestamp 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-Timestamp der Bestellung zu finden, die mit einer Bestellanforderungsposition verknüpft ist.
Datumsbereichsfilterung: Es ist entscheidend, 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-Bestellanforderungsdaten-Template

Ihr Purchase-to-Pay-Bestellanforderungsdaten-Template

Procure-to-Pay – Attribute der Bestellanforderung

Purchase to Pay - Bestellanforderungsaktivitäten

Extraktionsleitfäden

Dynamics 365 Data Management Framework Export

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit Dynamics 365 OData REST API

Schritte

Konfiguration

a Beispielabfrage python

Microsoft Power BI Native Connector-Extraktion

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

Purchase to Pay - Bestellanforderung für schnellere Genehmigungen jetzt optimieren

Ihr Purchase-to-Pay-Bestellanforderungsdaten-Template

Ihr Purchase-to-Pay-Bestellanforderungsdaten-Template

Procure-to-Pay – Attribute der Bestellanforderung

Purchase to Pay - Bestellanforderungsaktivitäten

Extraktionsleitfäden

Dynamics 365 Data Management Framework Export

Schritte

Konfiguration

a Beispielabfrage config

Python-Skript mit Dynamics 365 OData 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 - Bestellanforderung für schnellere Genehmigungen jetzt optimieren