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

Ihr Daten-Template für Purchase to Pay und Bestellanforderungen

Microsoft Dynamics 365

Purchase to Pay - Requisition: Attribute (17) Purchase to Pay - Requisition: Aktivitäten (12) Anleitungen zur Datenextraktion (3)

Ihr Daten-Template für Purchase to Pay und Bestellanforderungen

Dieses Template beschreibt die wichtigsten zu erfassenden Attribute und die entscheidenden zu verfolgenden Aktivitäten. So erhalten Sie eine detaillierte Grundlage für die Analyse Ihres Bestellanforderungsprozesses. Außerdem enthält es praktische Hinweise zur Datenextraktion, damit Sie Ihr Event Log effizient für eine detaillierte Analyse vorbereiten können.

Empfohlene Attribute für die Erfassung
Wichtige zu verfolgende Aktivitäten
Hinweise zur Datenextraktion

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

Template herunterladen

Purchase to Pay - Requisition: Attribute

Dies sind die empfohlenen Datenfelder, die Sie für eine umfassende Analyse Ihres Purchase-to-Pay-Prozesses für Bedarfsanforderungen in das Event Log aufnehmen sollten.

5 Erforderlich 6 Empfohlen 6 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des konkreten Geschäftserignisses oder Prozessschritts, der im Bestellanforderungsprozess stattgefunden hat.
Beschreibung Dieses Attribut erfasst den Namen jeder Aktivität, die im Lebenszyklus einer Bestellanforderung ausgeführt wird. Beispiele sind 'Requisition Created', 'Approval Step Approved' und 'Purchase Order Created'. Diese Aktivitäten bilden die Knoten im ermittelten Prozessmodell. Die Analyse der Reihenfolge, Häufigkeit und Dauer zwischen diesen Aktivitäten bildet den Kern von Process Mining. Sie hilft, Engpässe, Nacharbeitschleifen und Abweichungen vom Standardprozess zu erkennen und macht operative Ineffizienzen sichtbar. Warum das wichtig ist Dieses Attribut definiert die Schritte im Prozessmodell und ermöglicht es, den Workflow für Bestellanforderungen zu visualisieren, zu analysieren und zu verstehen. Bezugsquelle Dieses Attribut wird typischerweise aus Protokollen zu Statusänderungen, Workflow-Historientabellen oder spezifischen Ereignistabellen in Microsoft Dynamics 365 abgeleitet, etwa aus der WorkflowTrackingStatusTable. Beispiele Bestellanforderung zur Genehmigung eingereichtGenehmigungsstufe genehmigtBestellanforderung geändert
	Ereigniszeit EventTime	Der genaue Timestamp, zu dem eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Die Ereigniszeit beziehungsweise der Timestamp erfasst Datum und Uhrzeit, zu denen ein Geschäftserignis im System protokolliert wurde. Sie bildet die zeitliche Grundlage für alle zeitbezogenen Prozessanalysen. Dieses Attribut ist entscheidend für die Berechnung von Durchlaufzeiten, Dauern und Wartezeiten zwischen Aktivitäten. Es ermöglicht die Analyse der Prozessleistung, die Erkennung von Engpässen und die Überwachung der SLA-Einhaltung. Präzise Timestamps sind für eine verlässliche Process-Mining-Analyse unerlässlich. Warum das wichtig ist Es liefert die chronologische Reihenfolge der Ereignisse. Diese ist erforderlich, um Prozessdauern zu berechnen, Engpässe zu erkennen und die Leistung im Zeitverlauf zu analysieren. Bezugsquelle Zu finden in Workflow-Historien- oder Dokumentprotokolltabellen, häufig als Feld 'CreatedDateTime' oder 'ModifiedDateTime', das dem jeweiligen Statusänderungs- oder Ereignisdatensatz zugeordnet ist. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:30:15Z2023-10-27T14:22:05Z
	ID der Bestellanforderung PurchaseRequisitionId	Die eindeutige Kennung einer Bestellanforderung, die als primäre Case-ID dient.
Beschreibung Die Purchase Requisition ID ist der zentrale Schlüssel, der alle Aktivitäten zu einer einzelnen Anforderung für Waren oder Dienstleistungen miteinander verknüpft. Jeder Bestellanforderungsprozess, von der Erstellung über die abschließende Genehmigung bis zum Abschluss, wird unter dieser eindeutigen ID verfolgt. Im Process Mining ist dieses Attribut grundlegend für die Rekonstruktion des durchgängigen Ablaufs jeder Bestellanforderung. Es ermöglicht die Analyse von Prozessvarianten, Durchlaufzeiten und Compliance für einzelne Cases und liefert ein vollständiges Bild des Lebenszyklus der Bestellanforderung. Warum das wichtig ist Das Attribut ist entscheidend, um alle zugehörigen Ereignisse zu einer einzelnen Prozessinstanz zusammenzufassen und eine vollständige End-to-End-Analyse des Lebenszyklus jeder Bestellanforderung zu ermöglichen. Bezugsquelle Dies ist typischerweise der Primärschlüssel in der zentralen Kopfdatentabelle für Bestellanforderungen, etwa PurchReqTable in Microsoft Dynamics 365. Beispiele PR-001254PR-001255PR-001256
	Letzte Datenaktualisierung LastDataIngestionTimestamp	Der Timestamp, zu dem die Daten zuletzt extrahiert und in das Process-Mining-Tool geladen wurden.
Beschreibung Dieses Attribut zeigt, wie aktuell die analysierten Daten sind. Es gibt Datum und Uhrzeit der letzten Datenaktualisierung aus dem Quellsystem an. Es handelt sich nicht um ein Feld aus Dynamics 365 selbst, sondern um Metadaten, die während der Datenübernahme hinzugefügt werden. Dieser Timestamp ist entscheidend, damit Benutzer die Aktualität der Erkenntnisse einschätzen können. Er zeigt, ob Echtzeitdaten oder eine Momentaufnahme zu einem bestimmten Zeitpunkt betrachtet werden, was die Aussagekraft der Schlussfolgerungen beeinflusst. Warum das wichtig ist Es informiert Benutzer über die Aktualität der Daten und stellt sicher, dass sie den Zeitraum der Analyse und die Relevanz der Erkenntnisse verstehen. Bezugsquelle Dieser Wert wird während der Datenübernahme oder des ETL-Prozesses erzeugt und an den Datensatz angehängt. Beispiele 2024-05-20T08:00:00Z2024-05-21T08:00:00Z2024-05-22T08:00:00Z
	Quellsystem SourceSystemId	Das führende System, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut identifiziert das Quellsystem, aus dem die Ereignisdaten stammen. In diesem Kontext wäre dies 'Microsoft Dynamics 365'. In Umgebungen mit mehreren integrierten Systemen ist dieses Feld für Datenherkunft und Kontext entscheidend. In der Analyse hilft es, Prozesse zu unterscheiden, die sich über mehrere Systeme erstrecken, oder zu bestätigen, dass die Daten aus einer einzigen maßgeblichen Quelle stammen. Das ist wichtig für die Datenvalidierung und stellt sicher, dass die Analyse auf dem richtigen Datensatz basiert. Warum das wichtig ist Es liefert Kontext zur Herkunft der Daten. Das ist für Data Governance, Validierung und Umgebungen mit integrierten Systemen entscheidend. Bezugsquelle Dies ist ein statischer Wert, 'Microsoft Dynamics 365', der während der Datenextraktion und -transformation hinzugefügt wird. Beispiele Microsoft Dynamics 365 F&OD365MSD365
	Abteilung Department	Die Abteilung des Antragstellers oder die mit der Bestellanforderung verbundene Kostenstelle.
Beschreibung Dieses Attribut gibt die Geschäftsabteilung oder Kostenstelle an, von der die Bestellanforderung initiiert wurde, etwa 'Marketing', 'IT' oder 'Operations'. Diese Information ist normalerweise im Kopfdatensatz der Bestellanforderung enthalten. Die Segmentierung des Prozesses nach Abteilung ist für vergleichende Analysen entscheidend. Sie zeigt, welche Abteilungen die längsten Durchlaufzeiten, höchsten Ablehnungsquoten oder häufigsten Änderungen aufweisen. Diese Erkenntnisse helfen dabei, Prozessverbesserungen auf die Anforderungen einzelner Abteilungen abzustimmen. Warum das wichtig ist Es ermöglicht, die Prozessleistung verschiedener Geschäftsbereiche zu filtern und zu vergleichen und dabei abteilungsspezifische Muster, Engpässe oder Ineffizienzen sichtbar zu machen. Bezugsquelle Diese Information wird häufig im Kopfdatensatz der Bestellanforderung, PurchReqTable, gespeichert und mit der Konfiguration der Finanzdimensionen in Dynamics 365 verknüpft. Beispiele IT-AbteilungFinanzenBetrieb
	Benutzer User	Die Benutzer-ID oder der Name der Person, die die Aktivität ausgeführt hat.
Beschreibung Dieses Attribut identifiziert den Mitarbeitenden oder Systembenutzer, der für die Ausführung eines bestimmten Prozessschritts verantwortlich ist, etwa für das Einreichen einer Bestellanforderung oder die Genehmigung einer Anforderung. Es kann sich um eine Benutzer-ID, den vollständigen Namen oder eine E-Mail-Adresse handeln. Die Analyse von Aktivitäten nach Benutzer hilft, Schulungsbedarf, besonders leistungsstarke Personen oder Teams sowie die Arbeitsverteilung zu erkennen. Sie ist außerdem für Compliance-Analysen wie die Funktionstrennung und für das Verständnis der Interaktion verschiedener Benutzerrollen mit dem Prozess wichtig. Warum das wichtig ist Es ermöglicht die Analyse benutzerspezifischen Verhaltens, der Arbeitslast und der Leistung. Das ist entscheidend für das Ressourcenmanagement und die Erkennung von Schulungsmöglichkeiten. Bezugsquelle Typischerweise zu finden in Workflow-Historientabellen, zum Beispiel WorkflowTrackingStatusTable, oder in Transaktionstabellen, zum Beispiel PurchReqTable, die mit einer Benutzertabelle wie UserInfo verknüpft sind. Beispiele j.smitha.joness.patel
	Dringlichkeitsstufe UrgencyLevel	Eine Klassifizierung der Dringlichkeit einer Bestellanforderung, zum Beispiel „Hoch“, „Mittel“ oder „Niedrig“.
Beschreibung Die Dringlichkeitsstufe beziehungsweise Priorität gibt an, wie schnell die angeforderten Waren oder Dienstleistungen benötigt werden. Dieses Attribut wird häufig verwendet, um den Genehmigungspfad zu beeinflussen oder die Arbeit für Genehmigende zu priorisieren. Die Analyse dieses Attributs zeigt, ob das Prioritätssystem wirksam ist. Beispielsweise können Sie die Durchlaufzeiten von Bestellanforderungen mit hoher Dringlichkeit mit denen von Anforderungen mit niedriger Dringlichkeit vergleichen. Gibt es keinen wesentlichen Unterschied, kann dies darauf hindeuten, dass das Prioritätsfeld ignoriert oder falsch verwendet wird. Diese Erkenntnis ist für das Dashboard „Auswirkungsanalyse der Dringlichkeitsstufe“ besonders relevant. Warum das wichtig ist Damit lässt sich beurteilen, ob Prioritätseinstellungen kritische Anforderungen tatsächlich beschleunigen. Außerdem werden mögliche Fehlverwendungen der Dringlichkeitsklassifizierung sichtbar. Bezugsquelle Dies kann ein Standardfeld oder ein benutzerdefiniertes Feld in PurchReqTable sein. Vorhandensein und Bezeichnung können je nach Systemkonfiguration variieren. Beispiele HochMittelNiedrig
	Genehmigungsschritt ApprovalStep	Die Bezeichnung oder Stufe eines bestimmten Genehmigungsschritts im Workflow.
Beschreibung Dieses Attribut identifiziert die jeweilige Stufe im Genehmigungsworkflow, zum Beispiel „Genehmigung durch die Führungskraft“ oder „Genehmigung durch die Finanzabteilung“. Es liefert detailliertere Informationen als der allgemeine Aktivitätsname. Dieses Attribut ist für die „Engpassanalyse der Genehmigungsschritte“ unverzichtbar. Wenn Sie die in den einzelnen Genehmigungsschritten verbrachte Zeit erfassen, können Sie genau feststellen, welche Stufen Verzögerungen im Gesamtprozess verursachen. So lassen sich gezielte Maßnahmen zur Verbesserung der Workflow-Effizienz ableiten. Warum das wichtig ist Es ermöglicht eine detaillierte Analyse des Genehmigungsworkflows und macht bestimmte Stufen sichtbar, die Engpässe verursachen. Bezugsquelle Diese Informationen sind in den Workflow-Verlaufstabellen enthalten, zum Beispiel in WorkflowTrackingStatusTable, die jeden Schritt des konfigurierten Workflows dokumentiert. Beispiele Genehmigung durch den ManagerGenehmigung durch die AbteilungsleitungPrüfung durch die Finanzabteilung
	Gesamtbetrag der Bestellanforderung RequisitionTotalAmount	Der gesamte Geldwert der Bestellanforderung.
Beschreibung Dieses Attribut erfasst den Gesamtwert aller Positionen einer Bestellanforderung. Der Betrag beeinflusst häufig die Komplexität des Genehmigungs-Workflows, da Bestellanforderungen mit höherem Wert möglicherweise zusätzliche Genehmigungsstufen erfordern. In der Prozessanalyse ist dieses Attribut für wertbasierte Filter und Auswertungen entscheidend. Es hilft bei Fragen wie: 'Werden Bestellanforderungen mit hohem Wert langsamer genehmigt?' oder 'Welchen Wert haben Bestellanforderungen, die derzeit im Prozess feststecken?'. Dadurch erhält die Prozessleistung einen finanziellen Kontext. Warum das wichtig ist Es ergänzt die Analyse um eine finanzielle Dimension. Dadurch lassen sich wertvolle Cases priorisieren und die Auswirkungen des Geldwerts auf das Prozessverhalten verstehen. Bezugsquelle Dieser Wert befindet sich typischerweise in der Kopfdatentabelle der Bestellanforderung oder wird als Summe der Positionsbeträge aus der Bestellanforderungszeilentabelle 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 einem bestimmten Zeitpunkt an, etwa 'In Review', 'Approved', 'Rejected' oder 'Closed'. Es handelt sich häufig um ein Case-Attribut, das das Endergebnis repräsentiert. Die Analyse des finalen Status hilft, die Gesamtergebnisse des Prozesses zu verstehen. Eine hohe Zahl 'Rejected' oder 'Withdrawn' Bestellanforderungen kann beispielsweise auf Probleme in der ursprünglichen Anforderungsphase oder einen umständlichen Genehmigungsprozess hinweisen. Das Attribut ist entscheidend für die Messung von Erfolgsquoten und Prozesseffizienz. Warum das wichtig ist Es liefert ein eindeutiges Ergebnis für jeden Case und ermöglicht die Analyse von Genehmigungs-, Ablehnungs- und Rückzugsquoten, die wichtige Leistungskennzahlen sind. Bezugsquelle Das Statusfeld befindet sich typischerweise in der Kopfdatentabelle der Bestellanforderung, PurchReqTable, und heißt häufig 'Status' oder 'PurchReqStatus'. Beispiele GenehmigtIn PrüfungAbgelehntEntwurf
	Anzahl der Änderungen AmendmentCount	Die Gesamtzahl der Änderungen an einer Bestellanforderung.
Beschreibung Dies ist ein berechnetes numerisches Attribut, das für jeden Case einer Bestellanforderung die Vorkommen der Aktivität „Requisition Amended“ zählt. Dieses Attribut ist für das Dashboard „Änderungshäufigkeit von Bestellanforderungen“ und die KPI „Änderungsquote von Bestellanforderungen“ unverzichtbar. Es quantifiziert die Nacharbeit pro Case und macht sichtbar, welche Bestellanforderungen, Abteilungen oder Benutzer mit besonders vielen Änderungen und Ineffizienzen verbunden sind. So können Maßnahmen zur Verbesserung der Qualität von Erstanfragen gezielt ausgerichtet werden. Warum das wichtig ist Es quantifiziert die Nacharbeit innerhalb eines Cases und erleichtert dadurch die Messung und Analyse der Änderungshäufigkeit sowie ihrer Auswirkungen auf die Prozesseffizienz. Bezugsquelle Dies ist ein berechnetes Attribut. Es wird während der Datentransformation abgeleitet, indem die Aktivitäten „Requisition Amended“ 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 erstellt wurde. Es bildet die Verbindung zwischen dem Prozess der Bestellanforderung und dem nachgelagerten Beschaffungsprozess. Die Erfassung dieser Nummer ist für die Analyse der „Umwandlungszeit von Bestellanforderung zu Bestellung“ unverzichtbar. Sie bestätigt, dass eine Bestellanforderung erfolgreich in die nächste Phase des Purchase-to-Pay-Zyklus übergegangen ist, und ermöglicht eine durchgängige Prozessanalyse über Bestellanforderungen und Bestellungen hinweg. Warum das wichtig ist Es verknüpft die Bestellanforderung mit der nachfolgenden Bestellung. Dadurch lassen sich die Umwandlung von Bestellanforderungen in Bestellungen analysieren und verschiedene Phasen des P2P-Prozesses verbinden. Bezugsquelle Diese Informationen befinden sich in der Regel in der Positionstabelle der Bestellanforderung, PurchReqLine, nachdem eine Bestellung erstellt wurde. Die Tabelle verweist auf 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 mit der Bearbeitung einer bestimmten Genehmigungsaufgabe betraut ist, zum Beispiel „Genehmigende der Finanzabteilung“ oder „IT-Manager“. Die Analyse der Prozessleistung nach Genehmigergruppe ist entscheidend, um die Verteilung der Arbeitslast zu verstehen und Gruppen zu identifizieren, denen Ressourcen fehlen oder die zusätzliche Schulungen benötigen. Sie unterstützt das Dashboard „Engpassanalyse der Genehmigungsschritte“ direkt, da sich die Leistung nach den für Genehmigungen verantwortlichen Teams aufschlüsseln lässt. Warum das wichtig ist Damit lassen sich Leistungsunterschiede zwischen Genehmigungsteams erkennen. Mögliche Ressourcenengpässe oder Schulungsbedarfe in bestimmten Gruppen werden sichtbar. Bezugsquelle Diese Informationen sind Teil des Workflow-Verlaufs, zum Beispiel von WorkflowTrackingStatusTable, in dem der zugewiesene Benutzer oder die Benutzergruppe für jede Aufgabe erfasst wird. Beispiele Genehmigende der FinanzabteilungIT-ManagerFührungsebene
	Im ersten Durchlauf genehmigt IsFirstPass	Ein Kennzeichen dafür, dass eine Bestellanforderung ohne vorherige Änderungen oder Ablehnungen genehmigt wurde.
Beschreibung Dies ist ein berechnetes boolesches Attribut. Es ist „true“, wenn der Genehmigungspfad einer Bestellanforderung weder die Aktivitäten „Requisition Amended“ noch „Approval Step Rejected“ enthält. Andernfalls ist der Wert „false“. Dieses Attribut unterstützt direkt die KPI „Genehmigungsquote von Bestellanforderungen im ersten Durchlauf“. Es vereinfacht die Analyse der Prozesseffizienz, indem es auf Case-Ebene eindeutig anzeigt, ob Nacharbeit erforderlich war. Eine niedrige Quote von Genehmigungen im ersten Durchlauf weist auf Probleme bei der anfänglichen Datenqualität oder auf unklare Anforderungen hin und zeigt eine Möglichkeit zur Prozessverbesserung auf. Warum das wichtig ist Es misst die Prozessqualität und -effizienz direkt, indem es Cases identifiziert, die Nacharbeit erforderten. Damit unterstützt es KPIs zur First-Time-Right-Quote. Bezugsquelle Dies ist ein berechnetes Attribut. Während der Datentransformation muss die vollständige Aktivitätsfolge jedes Cases analysiert werden, um vor der Genehmigung das Fehlen von Nacharbeitsaktivitäten zu prüfen. Beispiele truefalse
	Pfad des Genehmigungsworkflows ApprovalWorkflowPath	Eine Darstellung der Abfolge durchlaufener Genehmigungsschritte.
Beschreibung Dieses Attribut ist ein abgeleitetes Feld, das die Abfolge der Genehmigungsschritte für eine bestimmte Bestellanforderung zusammenführt, zum Beispiel „Genehmigung durch die Führungskraft -> Genehmigung durch die Abteilungsleitung -> Genehmigung durch die Finanzabteilung“. Es fasst die Prozessvariante des Genehmigungssubprozesses zusammen. Für das Dashboard „Überwachung von Compliance-Abweichungen“ ist dieses Attribut besonders wichtig. Durch den Vergleich des tatsächlichen Workflow-Pfads mit einem vorgegebenen Standard- oder Sollpfad lassen sich nicht konforme oder ungewöhnliche Prozessabläufe erkennen, die auf Richtlinienverstöße oder operative Risiken hindeuten können. Warum das wichtig ist Es vereinfacht die Compliance-Analyse, indem es die Prozessvariante als klaren Text darstellt. Dadurch lassen sich Abweichungen von Standardverfahren schnell erkennen. Bezugsquelle Dieses Attribut ist kein Standardfeld. Es muss während der Datentransformation erstellt werden, indem die Werte von „ApprovalStep“ für jeden Case chronologisch zusammengeführt werden. Beispiele Manager -> DirektorManager -> Direktor -> VP FinanzenManager -> Automatisch genehmigt
	Währung Currency	Der Währungscode für den Betrag der Bestellanforderung.
Beschreibung Dieses Attribut gibt die Währung an, in der der Gesamtbetrag der Bestellanforderung angegeben ist, zum Beispiel USD, EUR oder GBP. Es ist für die Finanzanalyse besonders wichtig, vor allem in multinationalen Unternehmen, die mit mehreren Währungen arbeiten. Mit dem Währungsattribut lassen sich Finanzdaten korrekt verarbeiten und aggregieren. Dadurch werden Geldbeträge richtig interpretiert und können für eine präzise Berichterstattung und den Vergleich zwischen Regionen oder Geschäftsbereichen in eine gemeinsame Währung umgerechnet werden. Warum das wichtig ist Es liefert den erforderlichen Kontext für Finanzattribute und stellt sicher, dass Geldbeträge in Umgebungen mit mehreren Währungen korrekt interpretiert und aggregiert werden. Bezugsquelle Dieses Feld befindet sich in der Regel in der Kopfzeilentabelle für Bestellanforderungen, PurchReqTable, zusammen mit den Betragsfeldern. Beispiele USDEURGBP

Erforderlich Empfohlen Optional

Purchase to Pay - Requisition: Aktivitäten

Dies sind die wesentlichen Prozessschritte und Meilensteine, die Sie für eine präzise Ermittlung und Analyse Ihres Workflows für Bedarfsanforderungen im Event Log erfassen sollten.

7 Empfohlen 5 Optional

	Aktivität	Beschreibung
	Bestellanforderung abgelehnt	Die Bestellanforderung wurde während des Genehmigungs-Workflows abgelehnt und wird nicht weiterbearbeitet. Damit befindet sie sich in einem endgültigen Fehlerstatus.
Warum das wichtig ist Dieses Endereignis ist entscheidend, um die Gesamtablehnungsquote zu analysieren und die finanziellen oder operativen Auswirkungen abgelehnter Anforderungen zu verstehen. Bezugsquelle Wird beim Abschluss des Workflows mit dem Status 'Rejected' ausdrücklich aus der 'WorkflowTrackingStatusTable' erfasst. Dadurch wird das Statusfeld der 'PurchReqTable' aktualisiert. Erfassen Filtern Sie nach 'Completion'-Ereignissen des Workflows mit dem Status 'Rejected' oder verfolgen Sie die Statusänderung in PurchReqTable. Ereignistyp explicit
	Bestellanforderung erstellt	Dieses Ereignis kennzeichnet die erstmalige Erstellung des Datensatzes einer Bestellanforderung im Entwurfsstatus. Es wird anhand des Erstellungs-Timestamps des Kopfdatensatzes der Bestellanforderung erfasst.
Warum das wichtig ist Als Prozessbeginn ist diese Aktivität entscheidend, um die gesamte Lebenszyklusdauer von Bestellanforderungen zu messen und das tägliche Bearbeitungsvolumen zu analysieren. Bezugsquelle Diese Aktivität wird aus dem Feld 'createdDateTime' in 'PurchReqTable' für jede neue Purchase Requisition ID abgeleitet. Erfassen Verwenden Sie den Erstellungs-Timestamp des Datensatzes in PurchReqTable. Ereignistyp inferred
	Bestellanforderung genehmigt	Die Bestellanforderung hat alle erforderlichen Genehmigungsstufen des Workflows erfolgreich durchlaufen. Diese Aktivität wird erfasst, wenn die Workflow-Instanz mit dem finalen Status 'Approved' abgeschlossen wird.
Warum das wichtig ist Dies ist ein wichtiger Meilenstein: Der Genehmigungszyklus endet und die Beschaffungsphase beginnt. Die Aktivität bildet das Endereignis für den KPI 'Requisition Approval Cycle Time'. Bezugsquelle Wird beim Abschluss des Workflows ausdrücklich aus der 'WorkflowTrackingStatusTable' erfasst. Gleichzeitig wird das Feld 'Status' in der 'PurchReqTable' auf 'Approved' aktualisiert. Erfassen Filtern Sie nach 'Completion'-Ereignissen des Workflows mit dem Status 'Approved' oder verfolgen Sie die Statusänderung in PurchReqTable. Ereignistyp explicit
	Bestellanforderung geschlossen	Die gesamte Bestellanforderung gilt als abgeschlossen. Alle ihre Zeilen wurden in Bestellungen überführt oder storniert. Dies ist ein erfolgreicher finaler Endstatus.
Warum das wichtig ist Diese Aktivität kennzeichnet den erfolgreichen Abschluss des Lebenszyklus der Bestellanforderung. Sie ist der Endpunkt für die Messung der gesamten Durchlaufzeit des Prozesses. Bezugsquelle Dieser Status wird typischerweise berechnet oder abgeleitet. Er tritt ein, wenn alle zugehörigen 'PurchReqLine'-Datensätze einen Endstatus erreicht haben, zum Beispiel 'Closed' oder 'Cancelled'. Erfassen Leiten Sie dieses Ereignis ab, indem Sie prüfen, ob alle untergeordneten PurchReqLine-Datensätze einer PurchReqTable einen finalen Status erreicht haben. Ereignistyp calculated
	Bestellanforderung zur Genehmigung eingereicht	Der Benutzer reicht die ausgefüllte Bestellanforderung ein und startet damit den formellen Genehmigungs-Workflow. Das System protokolliert diese ausdrückliche Aktion über seine Workflow-Engine.
Warum das wichtig ist Diese Aktivität ist ein wichtiger Meilenstein und leitet den Genehmigungszyklus ein. Sie bildet den Ausgangspunkt für die Messung der 'Requisition Approval Cycle Time' und der 'First-Pass Approval Rate'. Bezugsquelle Erfasst in der 'WorkflowTrackingStatusTable' oder einer vergleichbaren Workflow-Historientabelle, in der ein 'Submission'-Ereignis für die Bestellanforderung protokolliert wird. Erfassen Filtern Sie die Workflow-Historienprotokolle nach dem Ereignistyp 'Submission' oder 'Start', der der Bestellanforderung zugeordnet ist. Ereignistyp explicit
	Bestellung erstellt	Eine genehmigte Bestellanforderungszeile wird in eine Bestellzeile umgewandelt und signalisiert damit die Übergabe an das Beschaffungsteam. Dies wird durch die Verknüpfung der Bestellanforderungszeile mit einer Bestellzeile erfasst.
Warum das wichtig ist Dies ist ein wichtiger Meilenstein, der die Bestellanforderung mit dem nachgelagerten Beschaffungsprozess verbindet. Er ist entscheidend für die Messung des KPIs 'Requisition to PO Conversion Time'. Bezugsquelle Wird abgeleitet, indem in der Tabelle 'PurchLine' ein Datensatz gefunden wird, der auf die ID einer mit dem Bestellanforderungsfall verbundenen 'PurchReqLine' verweist. Erfassen Verknüpfen Sie PurchReqLine und PurchLine über das Referenzfeld für die Verbindung, zum Beispiel PurchReqLineRefId. Ereignistyp inferred
	Genehmigungsstufe genehmigt	Ein Genehmigender schließt seine zugewiesene Aufgabe ab und genehmigt die Bestellanforderung für seine Prozessstufe. Dadurch wird die Bestellanforderung zur nächsten Stufe oder zur abschließenden Genehmigung weitergeleitet.
Warum das wichtig ist Misst die Bearbeitungszeit jeder Genehmigungsstufe und hilft dabei, effiziente Bereiche des Workflows zu erkennen. Die Aktivität ist ein wichtiger Bestandteil der Variantenanalyse. Bezugsquelle Wird in der 'WorkflowTrackingStatusTable' ausdrücklich protokolliert, wenn ein Benutzer ein Arbeitselement mit dem Ergebnis 'Approve' abschließt. Erfassen Identifizieren Sie in den Workflow-Historienprotokollen 'WorkItemCompleted'-Ereignisse mit dem Ergebnis 'Approve'. Ereignistyp explicit
	Bestellanforderung geändert	Dieses Ereignis tritt ein, wenn ein Benutzer eine eingereichte Bestellanforderung aus dem Workflow zurückruft, um Änderungen vorzunehmen. Die Aktivität wird typischerweise anhand einer Rückrufaktion erkannt, auf die später eine erneute Einreichung folgt.
Warum das wichtig ist Die Erfassung von Änderungen ist entscheidend, um Nacharbeit, unklare ursprüngliche Anforderungen und Ineffizienzen im Prozess zu erkennen. Sie unterstützt direkt das Dashboard 'Requisition Amendment Frequency'. Bezugsquelle Die Aktivität kann aus der Workflow-Historie ('WorkflowTrackingStatusTable') abgeleitet werden, indem eine 'Recall'- oder 'RequestChange'-Aktion erkannt wird. Alternativ lässt sie sich aus Änderungen am Feld 'modifiedDateTime' in 'PurchReqTable' nach der Einreichung ableiten. Erfassen Erkennen Sie Rückrufereignisse im Workflow oder Änderungen an Datensatzversionen zwischen Einreichungsereignissen. Ereignistyp inferred
	Bestellanforderung zurückgezogen	Der Ersteller oder ein autorisierter Benutzer storniert die Bestellanforderung, nachdem sie eingereicht wurde. Dadurch werden der Workflow und die Anforderung beendet.
Warum das wichtig ist Die Erfassung von Rücknahmen hilft dabei, Probleme bei der Bedarfsplanung oder übermäßig komplexe Prozesse zu erkennen. Dies unterstützt das Dashboard „Requisition Withdrawal Erkenntnisse“. Bezugsquelle Die Aktivität wird aus einer Statusänderung in der 'PurchReqTable' auf 'Cancelled' oder aus einem 'Cancel'-Ereignis in der 'WorkflowTrackingStatusTable' abgeleitet. Erfassen Erkennen Sie eine Statusänderung auf 'Cancelled' in PurchReqTable oder ein Stornierungsereignis im Workflow. Ereignistyp inferred
	Bestellanforderungszeile geschlossen	Eine einzelne Position der Bestellanforderung gilt als vollständig bearbeitet. Dies geschieht normalerweise, nachdem die Position vollständig in eine Bestellung umgewandelt wurde.
Warum das wichtig ist Liefert detaillierte Informationen zur Erfüllung der Bestellanforderung und zeigt, ob Bestellanforderungen teilweise oder vollständig in Bestellungen umgewandelt wurden. Bezugsquelle Wird aus dem Statusfeld der einzelnen Tabelle 'PurchReqLine' abgeleitet. Ein Status wie 'ordered' oder 'received' weist auf den Abschluss hin. Erfassen Überwachen Sie das Statusfeld in der Tabelle PurchReqLine auf einen Endwert wie 'Invoiced' oder 'Closed'. Ereignistyp inferred
	Genehmigungsstufe abgelehnt	Ein Genehmigender lehnt seine zugewiesene Aufgabe ab und sendet die Bestellanforderung normalerweise zur Korrektur an den Antragsteller zurück. Die Workflow-Engine protokolliert diese ausdrückliche Aktion.
Warum das wichtig ist Diese Aktivität ist grundlegend für die Berechnung der 'Requisition Rejection Rate' und zeigt, in welchen Stufen Ablehnungen besonders häufig auftreten. So werden Bereiche für Prozessverbesserungen sichtbar. Bezugsquelle Wird in der 'WorkflowTrackingStatusTable' ausdrücklich protokolliert, wenn ein Benutzer ein Arbeitselement mit dem Ergebnis 'Reject' abschließt. Erfassen Identifizieren Sie in den Workflow-Historienprotokollen 'WorkItemCompleted'-Ereignisse mit dem Ergebnis 'Reject'. Ereignistyp explicit
	Genehmigungsstufe gestartet	Eine einzelne Genehmigungsaufgabe wird im Rahmen des Workflows einem Benutzer oder einer Gruppe zugewiesen. Damit beginnt die Warte- oder Bearbeitungszeit für den jeweiligen Genehmigenden.
Warum das wichtig ist Diese Aktivität ist für die 'Approval Step Bottleneck Analysis' entscheidend, da sich damit Wartezeiten in bestimmten Genehmigungsstufen messen lassen. Bezugsquelle Erfasst in der 'WorkflowTrackingStatusTable', wenn ein neues Arbeitselement erstellt und der Workflow-Instanz der Bestellanforderung zugewiesen wird. Erfassen Identifizieren Sie 'WorkItemCreated'- oder vergleichbare Ereignisse in den Workflow-Historienprotokollen der jeweiligen Bestellanforderung. Ereignistyp explicit

Anleitungen zur Datenextraktion

So rufen Sie Ihre Daten aus Microsoft Dynamics 365 ab

Schritte

Data Management Workspace öffnen: Melden Sie sich bei Microsoft Dynamics 365 an und öffnen Sie das Menü Workspaces. Wählen Sie Data management, um die zentrale Umgebung für Datenimport und -export zu öffnen.
Neues Exportprojekt erstellen: Klicken Sie im Data-Management-Workspace auf die Kachel Export. Geben Sie einen eindeutigen Group name und eine aussagekräftige Description ein und setzen Sie die Project category auf Project. So strukturieren Sie Ihre Datenextraktionsaufgaben.
Datenentitäten hinzufügen: Fügen Sie Ihrem Projekt die erforderlichen Standarddatenentitäten hinzu. Klicken Sie auf Add entity, suchen Sie nach den folgenden Entitäten und fügen Sie sie einzeln hinzu:
- Purchase requisition headers
- Purchase requisition lines
- Workflow tracking status table
- Workflow work items
- Purchase order lines V2
Exportformat festlegen: Wählen Sie für jede hinzugefügte Entität ein Target data format, zum Beispiel CSV oder Excel. Für Leistung und Kompatibilität mit Tools zur Datentransformation wird in der Regel CSV empfohlen.
Datenfilter anwenden: Wählen Sie eine Entität aus und klicken Sie auf Filter. Geben Sie auf der Registerkarte Range die Legal entity an, also den Firmencode, damit die Daten aus dem richtigen Geschäftsbereich extrahiert werden. Außerdem sollten Sie im Feld Created date and time der Entität Purchase requisition headers einen Datumsfilter setzen, um das Datenvolumen zu begrenzen. Für den Anfang empfehlen wir einen Zeitraum von drei bis sechs Monaten.
Exportauftrag ausführen: Wenn alle Entitäten und Filter konfiguriert sind, klicken Sie im Action Pane auf Export. Das System erstellt ein Auftragspaket und beginnt mit der Verarbeitung. Den Fortschritt können Sie im Bereich Job history verfolgen.
Datenpaket herunterladen: Öffnen Sie nach erfolgreichem Abschluss des Exportauftrags die Details von Job history und klicken Sie auf Download package. Dadurch wird eine ZIP-Datei mit separaten Dateien für jede Entität heruntergeladen.
Rohdaten in ein Event Log umwandeln: Die exportierten Dateien enthalten rohe Systemtabellen und noch kein fertiges Event Log. Sie müssen ein externes Tool wie Python, Power Query oder eine ETL-Plattform verwenden, um die Daten zusammenzuführen und neu zu strukturieren. Dazu gehören:
- Zusammenführen der Kopf- und Positionsdateien.
- Verknüpfen der Workflow-Daten mit den Bestellanforderungen über CorrelationId und die RecId der Kopfzeile der Bestellanforderung.
- Umwandeln von Statusänderungen und Workflow-Ereignissen aus den Workflow-Tabellen in einzelne Aktivitätszeilen, zum Beispiel Requisition Submitted und Approval Step Approved.
- Erstellen einer neuen Zeile für jede Aktivität mit der korrekten ActivityName, EventTime und PurchaseRequisitionId.
Attribute berechnen und zuordnen: Ordnen Sie während der Transformation 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, zum Beispiel D365_F&O, und verwenden Sie die Ausführungszeit Ihres Skripts für LastDataIngestionTimestamp.
Ausgabe fertigstellen und formatieren: Stellen Sie sicher, dass die fertige Ausgabe aus einer einzelnen CSV-Datei besteht, in der 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 benötigen eine Sicherheitsrolle mit Berechtigungen für den Workspace Data management und Zugriff auf die zu exportierenden Datenentitäten, zum Beispiel Data management administrator oder eine vergleichbare benutzerdefinierte Rolle.
Wichtige Datenentitäten:
- Purchase requisition headers: Enthält die zentrale Case-Kennung, den Erstellungszeitpunkt und den Gesamtstatus.
- Purchase requisition lines: Enthält Details zu den angeforderten Artikeln, einschließlich Beträgen und Verknüpfungen zu Bestellungen.
- Workflow tracking status table: Die wichtigste Quelle für Workflow-Ereignisse wie Einreichung, Genehmigung, Ablehnung und Rücknahme.
- Workflow work items: Enthält Details zu den einzelnen Aufgaben, die Benutzern während des Genehmigungsprozesses zugewiesen werden.
- Purchase order lines V2: Wird verwendet, um den Erstellungszeitpunkt der mit einer Bestellanforderungsposition verknüpften Bestellung zu ermitteln.
Filterung nach Zeitraum: Auf das Feld Created date and time der Entität Purchase requisition headers muss ein Datumsfilter angewendet werden. Für die erste Analyse wird ein Zeitraum von drei bis sechs Monaten empfohlen, um Datenvolumen und Erkenntnisgewinn ausgewogen zu halten.
Filterung nach Firmencode: Wenden Sie immer einen Filter für die Legal entity an, damit keine Daten aus unbeabsichtigten oder Testunternehmen extrahiert werden. Dadurch sinkt das Datenvolumen deutlich und die Leistung des Auftrags verbessert sich.
Datentransformation: Diese Methode erfordert außerhalb von Dynamics 365 einen umfangreichen Nachbearbeitungsschritt, um die Rohdatenexporte in ein strukturiertes Event Log umzuwandeln. Planen Sie dafür den Einsatz eines Skript- oder ETL-Tools ein.

a Beispielabfrage sql

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

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

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

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

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

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

Schritte

Azure-Active-Directory-Anwendung registrieren: Öffnen Sie das Azure-Portal und registrieren Sie eine neue Anwendung. Diese Anwendung dient zur Authentifizierung bei der Dynamics-365-API. Notieren Sie die Anwendungs-ID (Client-ID) und die Verzeichnis-ID (Tenant-ID).
Client Secret erstellen: Erstellen Sie in der neu registrierten Anwendung in Azure unter „Certificates & secrets“ ein neues Client Secret. Kopieren Sie den Secret-Wert sicher, da er später nicht erneut angezeigt wird.
API-Berechtigungen erteilen: Fügen Sie im Bereich „API permissions“ der Anwendung eine Berechtigung für „Dynamics ERP“ hinzu. Wählen Sie „Delegated permissions“ und erteilen Sie Financials.ReadWrite.All oder eine restriktivere Berechtigung mit Lesezugriff. Erteilen Sie anschließend die Administratoreinwilligung für diese Berechtigungen.
Python-Bibliotheken installieren: Stellen Sie sicher, dass Python installiert ist. Installieren Sie anschließend die erforderlichen Bibliotheken mit pip: pip install requests pandas.
Python-Skript konfigurieren: Kopieren Sie das bereitgestellte Python-Skript in eine Datei, zum Beispiel extract_d365_requisitions.py. Füllen Sie die Platzhaltervariablen am Anfang des Skripts aus: Ihre Dynamics-365-URL, Tenant-ID, Client-ID, Client Secret, den gewünschten Zeitraum und die Unternehmens-ID.
OData-Entitäten verstehen: Das Skript fragt drei zentrale Datenentitäten ab: PurchaseRequisitionHeaders für die wichtigsten Details der Bestellanforderung, PurchaseRequisitionLines für Positionsdetails einschließlich der Umwandlung in Bestellungen und WorkflowTrackingStatusTable für alle Workflow-bezogenen Ereignisse wie Einreichungen und Genehmigungen.
Skript ausführen: Führen Sie das Skript über die Befehlszeile aus: python extract_d365_requisitions.py. Das Skript authentifiziert sich, ruft die Daten für jede Aktivität ab und verarbeitet die API-Paginierung automatisch.
Datentransformation: Das Skript verarbeitet die Rohdaten aus den API-Aufrufen im JSON-Format. Es strukturiert die Daten neu, indem es die Datensätze durchläuft und für jede der zwölf Geschäftsaktivitäten eine eigene Zeile erstellt. Dabei werden Quellfelder den Standardspalten des Event Logs wie PurchaseRequisitionId, ActivityName und EventTime zugeordnet.
Ereignisse zusammenführen und standardisieren: Alle erzeugten Ereignisse werden in einer gemeinsamen Liste gesammelt und anschließend in einen pandas DataFrame umgewandelt. Das Skript ergänzt statische Spalten wie SourceSystemId und LastDataIngestionTimestamp.
Als CSV exportieren: Der fertige DataFrame wird in eine CSV-Datei mit dem Namen d365_purchase_requisition_log.csv exportiert. Diese Datei ist für den direkten Upload in ein Process-Mining-Tool formatiert. Prüfen Sie, ob die Datei UTF-8-kodiert ist.

Konfiguration

Voraussetzungen: Zugriff auf ein Azure-Abonnement zur Registrierung einer Anwendung sowie eine Anwendungs-ID (Client-ID), ein Client Secret und eine Tenant-ID aus Azure Active Directory. Der Benutzer, der das Skript ausführt, benötigt Zugangsdaten mit Zugriff auf die OData-API-Endpunkte von Dynamics 365 Finance and Operations.
Konfiguration des API-Endpunkts: Das Skript benötigt die Basis-URL Ihrer Dynamics-365-Umgebung, üblicherweise im Format https://[your-environment-name].operations.dynamics.com.
Zeitraum: Legen Sie die Variablen START_DATE und END_DATE im Skript fest, um das Extraktionsfenster zu definieren. Für die erste Analyse wird ein Zeitraum von drei bis sechs Monaten empfohlen, um Datenvolumen und Erkenntnisgewinn ausgewogen zu berücksichtigen.
Unternehmensfilter: Das Skript filtert über die Variable COMPANY_ID nach einer bestimmten Legal entity. Um Daten für alle Unternehmen zu extrahieren, müssen Sie möglicherweise den OData-Filter anpassen und cross-company=true in die Request-Header aufnehmen.
Überlegungen zur Leistung: Das Skript ruft über $select in den OData-Abfragen nur die für das Event Log erforderlichen Spalten ab, was die Leistung verbessert. Außerdem verarbeitet es die Paginierung, um große Datenmengen zu verwalten, ohne die API zu überlasten. Für sehr große historische Datenbestände sollten Sie das Skript in Batches mit kürzeren Zeiträumen ausfü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

Bestätigen Sie, dass der native Microsoft Dynamics 365 Finance-Konnektor in Power BI Desktop verfügbar ist und der Benutzer über die erforderlichen Berechtigungen für den Zugriff auf die benötigten Datenentitäten, den Workflow-Verlauf, Anforderungsdaten und zugehörige Bestelldaten verfügt.
Wählen Sie in Power BI Desktop „Daten abrufen“, wählen Sie den Microsoft Dynamics 365 Finance-Konnektor aus und geben Sie die URL der Dynamics 365 Finance-Instanz ein. Authentifizieren Sie sich mit einem Konto, das zum Lesen der benötigten Entitäten berechtigt ist. Ersetzen Sie [Your Dynamics 365 Finance instance URL] durch die Instanz-URL Ihrer Umgebung.
Wählen Sie im Navigator die für Ihre Implementierung erforderlichen Entitäten für Anforderungsheader und -zeilen, Workflow-Verlauf oder Workflow-Tracking, Benutzer und Organisation sowie Bestellungen aus. Entitätsnamen und verfügbare Felder unterscheiden sich je nach Umgebung. Verwenden Sie die Entitätsmetadaten und ersetzen Sie jeden Platzhalter in der Abfrage durch die entsprechende Entität und das von Ihrem System bereitgestellte Feld.
Laden Sie die ausgewählten Entitäten in Power Query. Filtern Sie die Daten nach der benötigten juristischen Einheit oder dem Unternehmen, dem Dokumenttyp und dem Extraktionszeitraum. Verwenden Sie Parameter für [Start date] und [End date] und behalten Sie Datensätze bei, deren Event-Timestamp innerhalb des ausgewählten Zeitraums liegt. Berücksichtigen Sie auch Datensätze, die vor dem Startdatum erstellt wurden, wenn ihre Workflow- oder Abschlussereignisse innerhalb des Zeitraums liegen, damit die Fallhistorien vollständig bleiben.
Vereinheitlichen Sie Identifikatoren und Timestamps. Konvertieren Sie die Anforderungs-ID in Text, bringen Sie alle Event-Timestamps auf eine einheitliche UTC- oder Geschäftszeitzone und bewahren Sie die Genauigkeit der Quell-Timestamps. Stellen Sie sicher, dass die Anforderungsheader-ID in jeder Event-Zeile verfügbar ist. Wenn Workflow-Datensätze nur eine Workflow-Korrelations-ID enthalten, verknüpfen Sie sie über die in Ihrer Umgebung dokumentierte Beziehung mit dem Anforderungsheader.
Erstellen Sie für jede erforderliche Aktivität eine eigene Event-Abfrage. Die Event-Abfragen müssen explizit Zeilen für Requisition Created, Requisition Submitted for Approval, Requisition Amended, Approval Step Started, Approval Step Approved, Approval Step Rejected, Requisition Approved, Requisition Rejected, Requisition Withdrawn, Purchase Order Created, Requisition Line Closed und Requisition Closed zurückgeben. Verlassen Sie sich nicht darauf, dass ProcessMind Aktivitäten aus Statusänderungen oder der Reihenfolge von Ereignissen ableitet.
Wenden Sie für Requisition Amended die dokumentierte Logik für Rücknahme und erneute Einreichung aus Ihrem Workflow-Verlauf an. Eine Rücknahme mit anschließender späterer Einreichung muss ein Änderungsereignis zum Timestamp der Rücknahme oder zum von der Quellentität bereitgestellten Änderungs-Timestamp erzeugen. Erstellen Sie keine Änderungszeile ausschließlich aufgrund eines geänderten Anforderungsstatus, es sei denn, das Quellsystem erfasst diese Änderung ausdrücklich als Änderung.
Verknüpfen Sie für Zeilen- und Bestellereignisse die Anforderungszeilen anhand der dokumentierten Quellbeziehung mit den Bestellzeilen. Wenn das Event Log auf PurchaseRequisitionId als Case basiert, aggregieren Sie Ereignisse auf Zeilenebene oder behalten Sie sie als separate Zeilen mit derselben Case-ID bei. Bewahren Sie verfügbare Zeilen-IDs in zusätzlichen Spalten auf, auch wenn sie nicht zu den erforderlichen Attributen gehören.
Fügen Sie die erforderlichen Ausgabespalten PurchaseRequisitionId, ActivityName, EventTime, SourceSystemId und LastDataIngestionTimestamp hinzu. Ergänzen Sie die empfohlenen Spalten User, Department, RequisitionStatus, RequisitionTotalAmount, UrgencyLevel und ApprovalStep. Setzen Sie nicht verfügbare Werte auf null, statt Werte zu erfinden, und verwenden Sie für SourceSystemId einen einheitlichen Quellwert wie Dynamics 365 Finance.
Führen Sie alle Aktivitätsabfragen mit UNION ALL zusammen, entfernen Sie Zeilen mit fehlenden Case-IDs oder Event-Timestamps und sortieren Sie nach PurchaseRequisitionId und EventTime. Bewahren Sie doppelte Ereignisse auf, wenn sie separate Workflow-Aufgaben oder separate Anforderungszeilen darstellen. Entfernen Sie Duplikate nur, wenn die Quelldatensätze nachweislich doppelte Extrakte sind.
Validieren Sie das resultierende Event Log anhand der unten beschriebenen Prüfungen. Stellen Sie sicher, dass jede erforderliche Aktivität durch explizite Zeilen vertreten ist, die Timestamps innerhalb des ausgewählten Zeitraums liegen und Verknüpfungen nicht unerwartet zu einer Vervielfachung von Ereignissen führen.
Laden oder exportieren Sie die finale Tabelle als CSV oder in einem anderen von ProcessMind unterstützten Event-Log-Format. Ordnen Sie PurchaseRequisitionId als Case-ID, ActivityName als Aktivität und EventTime als Event-Timestamp zu. Behalten Sie SourceSystemId und LastDataIngestionTimestamp als Event-Attribute bei und übernehmen Sie alle verfügbaren empfohlenen Attribute.

Konfiguration

Konnektor und Quelle: Verwenden Sie den nativen Microsoft Dynamics 365 Finance-Konnektor in Power BI Desktop. Ersetzen Sie [Your Dynamics 365 Finance instance URL] durch die Umgebungs-URL. Entitätsnamen und Felder müssen anhand der Navigator-Metadaten für die konkrete Implementierung bestätigt werden.
Erforderliche Entitäten: Wählen Sie die Entitäten für Anforderungsheader und -zeilen, Workflow-Tracking oder Workflow-Verlauf, Bestellheader und -zeilen sowie Benutzer oder Organisation für die benötigte Anreicherung aus. Verwenden Sie [Your entity name], bis die genauen Entitäten bestätigt sind.
Datumsbereich: Beginnen Sie mit Daten aus drei bis sechs Monaten. Berücksichtigen Sie historische Anforderungsheader für Fälle, die im ausgewählten Zeitraum Workflow-, Bestell-, Zeilenabschluss- oder Anforderungsabschlussereignisse aufweisen.
Unternehmens- und Dokumentfilter: Filtern Sie, sofern zutreffend, nach [Your company or legal entity filter] und [Your document type filter]. Prüfen Sie, ob die Anforderungs-ID global eindeutig oder nur innerhalb eines Unternehmens eindeutig ist.
Workflow-Umfang: Berücksichtigen Sie Einreichung, Rücknahme, erneute Einreichung, Aufgabenzuweisung, Genehmigung, Ablehnung, Rückzug, Abschluss und Abbruch. Konfigurieren Sie die Zuordnungen von Workflow-Aktionen und Statuswerten anhand der in Ihrer Umgebung verwendeten Werte.
Ereignisbedeutung: Jede Aktivität muss als explizite Event-Zeile ausgegeben werden. ProcessMind leitet Genehmigungs-, Änderungs-, Abschluss- oder Konvertierungsereignisse nicht aus anderen Zeilen ab.
Umgang mit Timestamps: Vereinheitlichen Sie alle Timestamps auf eine Zeitzone. Dokumentieren Sie, ob die Quell-Timestamps in UTC oder in der lokalen Geschäftszeit gespeichert sind. Verwenden Sie den Timestamp mit der höchsten verfügbaren Genauigkeit.
Inkrementelle Aktualisierung: Verwenden Sie bei wiederkehrenden Extraktionen einen Watermark, der auf dem höchsten Änderungs- oder Event-Timestamp der Quelle basiert, ergänzt um ein Überlappungsfenster für verspätet eintreffende Workflow-Datensätze. Stimmen Sie das Überlappungsfenster vor dem Laden des finalen Event Logs ab.
Leistung: Filtern Sie Quellentitäten vor Verknüpfungen, wählen Sie nur benötigte Spalten aus, vermeiden Sie das Laden unnötiger historischer Workflow-Datensätze und verwenden Sie, sofern unterstützt, Query Folding. Extrahieren Sie Header, Zeilen, Workflow-Ereignisse und Bestellbeziehungen zunächst getrennt, bevor Sie sie zusammenführen.
Berechtigungen und Voraussetzungen: Das Konto benötigt Lesezugriff auf die ausgewählten Microsoft Dynamics 365 Finance-Datenentitäten und Workflow-Daten. Bestätigen Sie, dass die relevanten Funktionen für Beschaffung und Workflow aktiviert sind und dass Power BI Desktop, der Konnektor, die Gateway-Konfiguration, sofern zutreffend, sowie die Sicherheitsrichtlinien des Unternehmens die Extraktion erlauben.
Währung und Beträge: Prüfen Sie, welche Währung durch RequisitionTotalAmount dargestellt wird. Wenn Anforderungen mehrere Währungen enthalten können, fügen Sie die Quellwährung als zusätzliches Attribut hinzu und konvertieren Sie Beträge nicht stillschweigend.
Umgang mit Nullwerten: Empfohlene Attribute können null sein, wenn die Quelle keinen Wert speichert, der Wert durch Sicherheitsregeln eingeschränkt ist oder die Beziehung nicht aufgelöst werden kann. Erforderliche Werte für Case, Aktivität und Event-Timestamp müssen vor dem Export validiert werden.

a Beispielabfrage sql

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

    UNION ALL

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

    UNION ALL

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

    UNION ALL

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

    UNION ALL

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

    UNION ALL

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

    UNION ALL

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

    UNION ALL

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

    UNION ALL

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

    UNION ALL

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

    UNION ALL

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

    UNION ALL

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

Bereit für den Start?

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

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Optimieren Sie Purchase to Pay für Bestellanforderungen und beschleunigen Sie Genehmigungen

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

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.

Ihr Daten-Template für Purchase to Pay und Bestellanforderungen

Ihr Daten-Template für Purchase to Pay und Bestellanforderungen

Purchase to Pay - Requisition: Attribute

Purchase to Pay - Requisition: Aktivitäten

Anleitungen zur Datenextraktion

Export über das Data Management Framework von Dynamics 365

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript über die Dynamics-365-OData-REST-API

Schritte

Konfiguration

a Beispielabfrage python

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

Schritte

Konfiguration

a Beispielabfrage sql

Bereit für den Start?

Optimieren Sie Purchase to Pay für Bestellanforderungen und beschleunigen Sie Genehmigungen

Ihr Daten-Template für Purchase to Pay und Bestellanforderungen

Ihr Daten-Template für Purchase to Pay und Bestellanforderungen

Purchase to Pay - Requisition: Attribute

Purchase to Pay - Requisition: Aktivitäten

Anleitungen zur Datenextraktion

Export über das Data Management Framework von Dynamics 365

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript über die Dynamics-365-OData-REST-API

Schritte

Konfiguration

a Beispielabfrage python

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

Schritte

Konfiguration

a Beispielabfrage sql

Bereit für den Start?

Optimieren Sie Purchase to Pay für Bestellanforderungen und beschleunigen Sie Genehmigungen

Ihre Privatsphäre ist uns wichtig