> Kontinuierliche Prozessverbesserung > Purchase to Pay Requisition > SAP ECC > Daten Template

Ihr Daten-Template für Purchase to Pay, Bestellanforderung

SAP ECC

Purchase to Pay - Requisition: Attribute (19) Purchase to Pay - Requisition: Aktivitäten (13) Anleitungen zur Extraktion (2)

Ihr Daten-Template für Purchase to Pay, Bestellanforderung

Dieses Template bietet eine umfassende Anleitung zur Erfassung der wesentlichen Daten für die Analyse Ihres Purchase-to-Pay-Prozesses für Bestellanforderungen. Es beschreibt die wichtigsten zu erfassenden Datenfelder, die zentralen zu verfolgenden Aktivitäten sowie praktische Hinweise zur Extraktion dieser Informationen aus Ihrem Quellsystem. Verwenden Sie diese Ressource, um Ihre Daten für ein aussagekräftiges Process Mining vorzubereiten.

Empfohlene zu erfassende Attribute
Wichtige zu verfolgende Aktivitäten
Anleitung zur Extraktion aus SAP ECC

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 5 Empfohlen 9 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name der Geschäftsaktivität, die zu einem bestimmten Zeitpunkt stattgefunden hat.
Beschreibung Dieses Attribut beschreibt einen bestimmten Schritt oder ein Ereignis im Lebenszyklus einer Bestellanforderung, etwa „Bestellanforderung angelegt“, „Genehmigung eingereicht“ oder „Bestellung angelegt“. Diese Aktivitäten werden typischerweise aus Statusänderungen, Workflow-Protokollen oder Änderungsbelegen in SAP abgeleitet. Die Analyse der Reihenfolge und Häufigkeit von Aktivitäten bildet die Grundlage des Process Mining. Sie ermöglicht es, die tatsächlichen Prozessabläufe zu erkennen, einschließlich häufig genutzter Pfade, Abweichungen und Engpässe. Das ist entscheidend für den Aufbau von Dashboards wie der Prozesslandkarte für den End-to-End-Prozess der Bestellanforderung sowie für die Berechnung von KPIs zu Nacharbeit und Compliance. Warum das wichtig ist Es definiert die Prozessschritte und ermöglicht dadurch die Visualisierung von Prozesslandkarten sowie die Analyse von Abweichungen im Prozessablauf. Bezugsquelle Abgeleitet aus den Tabellen für Änderungsbelege CDHDR und CDPOS, Workflow-Protokollen oder Statusfeldern wie EBAN-STATU. Beispiele Anforderung erstelltGenehmigungsschritt genehmigtAnforderung abgelehntBestellung angelegt
	Ereigniszeit EventTime	Der Timestamp, der angibt, wann die Aktivität stattgefunden hat.
Beschreibung Die Ereigniszeit erfasst das genaue Datum und die genaue Uhrzeit, zu der eine bestimmte Aktivität stattgefunden hat. Dieser Timestamp ist die Grundlage für alle zeitbezogenen Analysen im Process Mining, darunter die Berechnung von Durchlaufzeiten, die Erkennung von Engpässen und die Bewertung der Prozessleistung. Im Kontext von Bestellanforderungen ermöglicht dieses Attribut die Berechnung wichtiger KPIs wie „Durchschnittliche Genehmigungszeit der Bestellanforderung“ und „Zeit bis zur Anlage der Bestellung“. Es versorgt Dashboards zur Darstellung von Zeitdauern, etwa die Analyse der Durchlaufzeit der Genehmigung einer Bestellanforderung, mit den Rohdaten, die zur Messung der Zeit zwischen beliebigen Prozesspunkten erforderlich sind. Warum das wichtig ist Dieser Timestamp ist entscheidend für die Berechnung aller Zeitdauern, die Analyse der Prozessleistung und die Erkennung zeitbezogener Engpässe. Bezugsquelle Zu finden in der Kopfzeilentabelle für Änderungsbelege CDHDR, in den Feldern UDATE und UTIME. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:20:05Z
	ID der Bestellanforderung PurchaseRequisitionId	Die eindeutige Kennung eines Dokuments für eine Bestellanforderung.
Beschreibung Die ID der Bestellanforderung ist der Primärschlüssel, der jede Anfrage nach Waren oder Dienstleistungen innerhalb von SAP ECC eindeutig identifiziert. Sie dient als zentrale Case-Kennung und verknüpft alle Aktivitäten und Änderungen, die zu einer bestimmten Bestellanforderung gehören, von ihrer Anlage bis zur endgültigen Bearbeitung, etwa der Umwandlung in eine Bestellung oder dem Abschluss. Im Process Mining ist diese ID entscheidend, um den vollständigen Lebenszyklus jeder Bestellanforderung zu rekonstruieren. Durch die Nachverfolgung dieser Kennung können Analysten den gesamten Prozessablauf visualisieren, die Dauer zwischen Meilensteinen messen und Unterschiede in der Bearbeitung verschiedener Bestellanforderungen analysieren. So entsteht eine zusammenhängende Sicht auf den gesamten Verlauf der Bestellanforderung. Warum das wichtig ist Dies ist die zentrale Kennung, die alle zugehörigen Prozessereignisse zu einem einzelnen Case verbindet und dadurch eine End-to-End-Prozessanalyse ermöglicht. Bezugsquelle Zu finden in der Tabelle EBAN, Feld BANFN. Beispiele 100234567810023456791002345680
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der letzten Aktualisierung oder Extraktion der Daten aus dem Quellsystem.
Beschreibung Dieses Attribut gibt an, wann der Datensatz zuletzt aktualisiert wurde. Es handelt sich um einen statischen Timestamp, der bei jedem Datenladevorgang auf den gesamten Datensatz angewendet wird und als Referenz für die Aktualität der Analyse dient. Für jedes Process-Mining-Dashboard und jede Analyse ist es entscheidend zu wissen, wie aktuell die Daten sind, um fundierte Entscheidungen zu treffen. Dieses Attribut stellt sicher, dass alle Beteiligten den Zeitraum kennen, den die angezeigten Daten abdecken. So werden Schlussfolgerungen auf Basis veralteter Informationen vermieden. Warum das wichtig ist Informiert Benutzer über die Aktualität der Daten, die für die Relevanz und Genauigkeit der Prozessanalyse entscheidend ist. Bezugsquelle Dies ist ein statischer Wert, der den Timestamp der Datenextraktion darstellt und während des ETL-Prozesses ergänzt wird. Beispiele 2024-01-15T04:00:00Z2024-01-16T04:00:00Z
	Quellsystem SourceSystem	Identifiziert das Quellsystem, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt den Ursprung der Prozessdaten an, zum Beispiel „SAP ECC Production“ oder „S4HANA QA“. In Umgebungen mit mehreren Quellsystemen wird es typischerweise während der Datenextraktion als statischer Wert ergänzt, um den Kontext bereitzustellen. In der Prozessanalyse hilft dies, Daten aus verschiedenen Quellen zu unterscheiden. So wird verhindert, dass Daten aus Produktions-, Test- oder Entwicklungsumgebungen die Analyse verfälschen. Das Attribut ist ein grundlegender Bestandteil der Data Governance und Rückverfolgbarkeit. Warum das wichtig ist Liefert den erforderlichen Kontext zum Datenursprung, gewährleistet die Rückverfolgbarkeit und ermöglicht die Analyse mehrerer Systeme. Bezugsquelle Dies ist ein statischer Wert, der typischerweise während des Prozesses zur Extraktion, Transformation und zum Laden von Daten (ETL) ergänzt wird. Beispiele SAP_ECC_PRODS4HANA_EU_100ECC_US_FINANCE
	Abteilung Department	Die Abteilung des Anforderers oder die mit der Bestellanforderung verbundene Kostenstelle.
Beschreibung Dieses Attribut bezeichnet die Geschäftseinheit oder Abteilung, die die Bestellanforderung initiiert hat. Es wird häufig aus dem Benutzerprofil des Anforderers oder der der Bestellanforderungsposition zugewiesenen Kostenstelle abgeleitet. Die Analyse des Prozesses nach Abteilung ist entscheidend, um Leistungsunterschiede innerhalb der Organisation zu verstehen. Sie ist die zentrale Dimension für das Dashboard „Durchlaufzeit der Genehmigung von Bestellanforderungen“ und den KPI „Abweichung der Genehmigungszeit nach Abteilung“. Damit lässt sich erkennen, welche Abteilungen effizient arbeiten und wo Verbesserungen oder zusätzliche Ressourcen erforderlich sind. Warum das wichtig ist Ermöglicht den Leistungsvergleich zwischen Geschäftseinheiten und macht Abteilungsengpässe sowie Unterschiede im Prozess sichtbar. Bezugsquelle Häufig abgeleitet durch die Verknüpfung des Anforderers (EBAN-AFNAM) mit den Benutzerstammdaten (SU01) oder durch Verwendung der Kostenstelle (EBKN-KOSTL), die der Kontierung der Bestellanforderung zugeordnet ist. Beispiele FinanzenIT-BetriebMarketingFertigung
	Belegart RequisitionDocumentType	Eine Klassifizierung, die den Typ und die Eigenschaften der Bestellanforderung bestimmt.
Beschreibung Die Belegart in SAP steuert verschiedene Aspekte einer Bestellanforderung, darunter den Nummernkreis, die Feldauswahl und den übergeordneten Beschaffungsprozess. Beispiele sind „Standard-BA“, „Umlagerung“ oder „Dienstleistungs-BA“. Dieses Attribut ist eine wichtige Analysedimension, da verschiedene Belegarten häufig unterschiedlichen Prozessabläufen und Genehmigungsanforderungen folgen. Analysten können die Daten damit segmentieren und die Leistung verschiedener Prozesse für Bestellanforderungen vergleichen. Das ist entscheidend, um Compliance zu bewerten und Möglichkeiten für eine Standardisierung oder Spezialisierung von Prozessen zu erkennen. Warum das wichtig ist Ermöglicht die Einteilung von Bestellanforderungen in verschiedene Prozesskategorien und damit eine präzisere und relevantere Analyse. Bezugsquelle Zu finden in der Tabelle EBAN, Feld BSART. Beispiele NBUBRV
	Benutzername User	Die ID des Benutzers, der die Aktivität ausgeführt hat.
Beschreibung Dieses Attribut identifiziert den Benutzer, der für ein Ereignis verantwortlich ist, etwa für die Anlage einer Bestellanforderung, die Genehmigung eines Schritts oder die Änderung eines Dokuments. In SAP wird dies häufig als Benutzer-ID erfasst. Die Analyse nach Benutzer hilft, Schulungsbedarf, benutzerspezifische Leistung und mögliche Ursachen für Eingabefehler zu erkennen. Sie ist für Dashboards wie „Durchsatz bei der Anlage von Bestellanforderungen nach Anforderer“ sowie für die Bewertung der Arbeitsverteilung und der Einhaltung von Richtlinien zur Funktionstrennung erforderlich. Warum das wichtig ist Ordnet Aktivitäten bestimmten Personen zu und ermöglicht dadurch die Analyse von Benutzerleistung, Arbeitsauslastung, Compliance und Schulungsbedarf. Bezugsquelle Zu finden in der Kopfzeilentabelle für Änderungsbelege CDHDR, Feld USERNAME, für Änderungen sowie in EBAN, Feld ERNAM, für den Ersteller. Beispiele SMITHJR.DOEUSER123
	Gesamtwert der Bestellanforderung TotalRequisitionValue	Der gesamte Geldwert aller Positionen in der Bestellanforderung.
Beschreibung Dieses Attribut stellt den gesamten finanziellen Wert der Bestellanforderung dar. Der Wert ist häufig ein entscheidender Faktor für den erforderlichen Genehmigungs-Workflow. Bestellanforderungen mit höherem Wert erfordern in der Regel eine eingehendere Prüfung und zusätzliche Genehmigungsschritte. Die Analyse nach Wert ist entscheidend, um zu verstehen, wie sich die finanzielle Bedeutung auf das Prozessverhalten auswirkt. Sie kann zeigen, ob die Genehmigung wertintensiver Bestellanforderungen länger dauert, ob sie häufiger abgelehnt werden oder ob sie anderen Prozesspfaden folgen. Außerdem ist sie eine zentrale Kennzahl zur Bewertung des finanziellen Durchsatzes im Beschaffungsprozess. Warum das wichtig ist Hilft, das Prozessverhalten mit den finanziellen Auswirkungen zu verknüpfen. Das ist für die Risikoanalyse und das Verständnis der Genehmigungskomplexität entscheidend. Bezugsquelle Summe der Werte aller Positionen. Der Positionswert steht in der Tabelle EBAN, Feld GSWER. Die Währung steht in EBAN-WAERS. Beispiele 1500.00250.50125000.00
	Status der Bestellanforderung RequisitionStatus	Der aktuelle Bearbeitungsstatus der Bestellanforderung.
Beschreibung Dieses Attribut gibt den Gesamtstatus der Bestellanforderung zu einem bestimmten Zeitpunkt an, etwa „In Freigabe“, „Genehmigt“, „Abgelehnt“ oder „Geschlossen“. In SAP wird dieser Status häufig durch einen Statuscode dargestellt. Die Nachverfolgung des Status ist entscheidend, um das Ergebnis von Bestellanforderungen zu verstehen. Sie unterstützt direkt das Dashboard „Ergebnisse und Ablehnungsquoten von Bestellanforderungen“ sowie KPIs wie „Ablehnungsquote von Bestellanforderungen“ und „Rückzugsquote von Bestellanforderungen“. Die Analyse der Statusübergänge hilft, Ineffizienzen und Fehlerpunkte im Prozess zu erkennen. Warum das wichtig ist Es definiert das Ergebnis einer Bestellanforderung und ist damit entscheidend für die Analyse von Erfolgsquoten, Ablehnungsgründen und Prozessendpunkten. Bezugsquelle Der Bearbeitungsstatus befindet sich in der Tabelle EBAN, Feld STATU. Der Freigabestatus steht in EBAN-FRGZU. Beispiele N (Nicht bearbeitet)B (Bestellung erstellt)A (Anfrage erstellt)K (Geschlossen)
	Ablehnungsgrund RejectionReason	Der Grund, der bei der Ablehnung einer Bestellanforderung oder eines Genehmigungsschritts angegeben wird.
Beschreibung Dieses Attribut erfasst die Begründung für die Ablehnung einer Bestellanforderung. Die Information wird vom Genehmiger während der Ablehnungsaktivität typischerweise als Freitext eingegeben oder aus einer vordefinierten Liste von Codes ausgewählt. Die Analyse von Ablehnungsgründen ist für die Prozessverbesserung entscheidend. Sie liefert direkt verwertbare Hinweise darauf, warum Bestellanforderungen scheitern, etwa wegen Richtlinienverstößen, fehlerhafter Daten oder fehlenden Budgets. Diese Daten sind zentral für das Dashboard „Ergebnisse und Ablehnungsquoten von Bestellanforderungen“ und helfen, die Ursachen von Ineffizienzen zu erkennen. Warum das wichtig ist Liefert direkte Erkenntnisse darüber, warum Bestellanforderungen abgelehnt werden, und ermöglicht gezielte Prozessverbesserungen sowie Benutzerschulungen. Bezugsquelle Diese Daten werden typischerweise in Workflow-Protokollen oder einem mit dem Ablehnungsereignis verknüpften Langtext gespeichert. In EBAN gibt es dafür kein Standardfeld. Beispiele Falsche KostenstelleBudget überschrittenDoppelte AnforderungNicht richtlinienkonform
	Bestellnummer PurchaseOrderId	Die ID der Bestellung, die aus der Bestellanforderung angelegt wurde.
Beschreibung Dieses Attribut verknüpft eine Bestellanforderung mit der nachfolgenden Bestellung, die zu ihrer Erfüllung angelegt wurde. Aus einer einzelnen Bestellanforderung können mitunter mehrere Bestellungen entstehen. Diese Verbindung ist entscheidend für die Analyse der Übergabe zwischen Bestellanforderungs- und Einkaufsprozess. Sie wird benötigt, um den KPI „Zeit bis zur Anlage der Bestellung ab Bestellanforderung“ zu berechnen und das Dashboard „Verzögerung von genehmigter Bestellanforderung bis zur Bestellanlage“ zu unterstützen. Das Verständnis dieser Verbindung ist zentral für die Bewertung der Effizienz des gesamten Procure-to-Pay-Zyklus. Warum das wichtig ist Verbindet den Prozess der Bestellanforderung mit dem nachgelagerten Einkaufsprozess und ermöglicht die Analyse von Verzögerungen bei der Übergabe. Bezugsquelle Die Bestellnummer wird nach ihrer Anlage in der Tabelle EBAN, Feld EBELN, gespeichert. Beispiele 450001712345000171244500017125
	Einkäufergruppe PurchasingGroup	Die Gruppe von Einkäufern, die für die Beschaffung der angeforderten Positionen verantwortlich ist.
Beschreibung Die Einkäufergruppe ist eine Organisationseinheit, die für bestimmte Beschaffungsaktivitäten verantwortlich ist. Sie bezeichnet das Einkaufsteam, das die Bestellanforderung nach ihrer Genehmigung bearbeitet. Dieses Attribut eignet sich zur Analyse der Arbeitsauslastung und Leistung verschiedener Einkaufsteams. Es kann zeigen, ob bestimmte Einkäufergruppen bei der Umwandlung von Bestellanforderungen in Bestellungen Engpässe verursachen oder bestimmte Arten von Bestellanforderungen effizienter bearbeiten. Damit steht eine wichtige Dimension für das Ressourcen- und Leistungsmanagement im Einkauf zur Verfügung. Warum das wichtig ist Weist die Verantwortung für die Beschaffung zu und ermöglicht die Analyse der Arbeitsauslastung sowie den Leistungsvergleich verschiedener Einkaufsteams. Bezugsquelle Zu finden in der Tabelle EBAN, Feld EKGRP. Beispiele 001002P01
	Lieferanten-ID VendorId	Die eindeutige Kennung des vorgeschlagenen oder festgelegten Lieferanten.
Beschreibung Dieses Attribut enthält die ID eines bevorzugten oder vertraglich festgelegten Lieferanten für die angeforderte Position. Sie kann vom Anforderer vorab eingetragen oder vorgeschlagen werden. Die Analyse von Bestellanforderungen nach Lieferant kann zeigen, wie sich die Vorauswahl von Lieferanten auf den Beschaffungsprozess auswirkt. So lässt sich beispielsweise prüfen, ob Bestellanforderungen mit angegebenem Lieferanten schneller genehmigt werden oder ob bestimmte Lieferanten mit höheren Ablehnungsquoten verbunden sind. Das Attribut bietet Einblick in die frühe Einbindung von Lieferanten. Warum das wichtig ist Liefert Erkenntnisse zu bevorzugten Lieferantenbeziehungen und deren Einfluss auf Bearbeitungsgeschwindigkeit und Ergebnisse von Bestellanforderungen. Bezugsquelle Zu finden in der Tabelle EBAN, Feld LIFNR (fester Lieferant). Beispiele 100030025V9876
	Nacharbeit erforderlich IsRework	Ein boolesches Kennzeichen, das angibt, ob die Bestellanforderung eine Nacharbeitsschleife durchlaufen hat, etwa eine Änderung nach der Einreichung.
Beschreibung Dies ist ein abgeleitetes Attribut, das Aktivitäten oder Cases mit Nacharbeit kennzeichnet. Beispielsweise gilt eine Aktivität „Bestellanforderung angepasst“, die nach „Genehmigung eingereicht“ stattfindet, als Nacharbeit. Auch Ablehnungsereignisse, die den Prozess an eine frühere Phase zurückführen, können das Kennzeichen auslösen. Dieses Kennzeichen ist für das Dashboard „Analyse von Änderungen und Nacharbeit bei Bestellanforderungen“ entscheidend. Es ermöglicht die einfache Filterung und Quantifizierung von Nacharbeit, hilft bei der Messung ihrer Auswirkungen auf die Gesamtdurchlaufzeiten und macht die Ursachen von Ineffizienzen sichtbar. Hohe Nacharbeitsquoten weisen häufig auf Probleme mit der Datenqualität oder unklare Anforderungen hin. Warum das wichtig ist Hilft, Häufigkeit und Auswirkungen von Nacharbeit zu quantifizieren, und erleichtert die Erkennung und Analyse von Ineffizienzen und Schleifen im Prozess. Bezugsquelle Abgeleitet aus dem Event Log durch die Erkennung bestimmter Aktivitätsfolgen, etwa wenn „Bestellanforderung angepasst“ nach einer Genehmigungsaktivität auftritt. Beispiele truefalse
	Name des Anforderers RequesterName	Der Name der Person, die die Waren oder Dienstleistungen angefordert hat.
Beschreibung Dieses Attribut identifiziert die Person, die die Bestellanforderung initiiert hat. Sie hat den geschäftlichen Bedarf für die angeforderten Positionen. Die Nachverfolgung des Anforderers ermöglicht die Analyse von Mustern bei Bestellanforderungen nach Person oder Gruppe. Das Dashboard „Durchsatz bei der Anlage von Bestellanforderungen nach Anforderer“ verwendet dieses Attribut, um besonders aktive Benutzer, Benutzer mit zusätzlichem Schulungsbedarf oder Abteilungen mit hohem Beschaffungsaufkommen zu erkennen. Es bietet eine personenbezogene Sicht auf den Startpunkt des Prozesses. Warum das wichtig ist Identifiziert den Prozessverantwortlichen, ermöglicht die Analyse von Mustern bei der Anlage von Bestellanforderungen und unterstützt die gezielte Planung von Benutzerschulungen. Bezugsquelle Zu finden in der Tabelle EBAN, Feld AFNAM. Beispiele Alice WilliamsBob JohnsonCharlie Brown
	Priorität Priority	Die Dringlichkeitsstufe, die der Bestellanforderung zugewiesen wurde.
Beschreibung Dieses Attribut gibt die Priorität der Bestellanforderung an, häufig eingestuft als „Dringend“, „Hoch“ oder „Normal“. Das Kennzeichen signalisiert Genehmigern und Einkäufern, dass eine Anfrage bevorzugt bearbeitet werden muss. Dieses Attribut ist für das Dashboard „Leistung bei der Bearbeitung dringender Bestellanforderungen“ und den KPI „Wirksamkeit des Dringlichkeitskennzeichens“ entscheidend. Die Analyse prüft, ob als dringend gekennzeichnete Bestellanforderungen tatsächlich schneller bearbeitet werden als Standardanfragen. So lässt sich die Wirksamkeit des Priorisierungssystems bewerten und sicherstellen, dass geschäftskritische Anforderungen zeitnah erfüllt werden. Warum das wichtig ist Ermöglicht die Analyse, ob dringende Anfragen schneller bearbeitet werden, und bewertet damit die Wirksamkeit von Priorisierungsmechanismen. Bezugsquelle Dies ist kein Standardfeld in EBAN. Häufig wird es als kundenspezifisches Feld umgesetzt oder aus der Anforderungsverfolgungsnummer (EBAN-BEDNR) beziehungsweise einer bestimmten Belegart abgeleitet. Beispiele 123
	Warengruppe MaterialGroup	Die Gruppe oder Kategorie, zu der das angeforderte Material oder die angeforderte Dienstleistung gehört.
Beschreibung Die Warengruppe ist eine Klassifizierung, mit der Materialien oder Dienstleistungen mit ähnlichen Eigenschaften zusammengefasst werden. Dadurch wird eine kategoriebasierte Analyse von Beschaffungsaktivitäten ermöglicht. Die Analyse nach Warengruppe unterstützt strategische Beschaffung und Ausgabenanalysen. Im Process Mining kann sie zeigen, ob Bestellanforderungen für bestimmte Kategorien wie „IT-Hardware“ oder „Professionelle Dienstleistungen“ anderen Prozesspfaden folgen oder längere Genehmigungszeiten aufweisen. Diese Erkenntnis ist für den „Datenqualitätsbericht zu Bestellanforderungen“ und das Verständnis von Prozessabweichungen nach Beschaffungsgegenstand wertvoll. Warum das wichtig ist Ermöglicht die Analyse von Ausgaben und Prozessen nach Beschaffungskategorie, unterstützt die strategische Beschaffung und macht kategoriespezifische Engpässe sichtbar. Bezugsquelle Zu finden in der Tabelle EBAN, Feld MATKL. Beispiele 00101L001IT-SFTWR
	Werk Plant	Der Unternehmensstandort oder das Werk, für den beziehungsweise das die Waren oder Dienstleistungen angefordert werden.
Beschreibung Das Werk ist eine Organisationseinheit innerhalb eines Unternehmens und bezeichnet einen physischen Standort wie eine Fabrik, ein Lager oder ein Büro. In der Bestellanforderung wird das Werk angegeben, an dem die angeforderten Positionen benötigt werden. Die Analyse nach Werk ermöglicht eine geografische oder standortbezogene Betrachtung des Prozesses für Bestellanforderungen. Sie kann Leistungsunterschiede zwischen Standorten sichtbar machen, die auf lokale Verfahren, unterschiedliche Personalbesetzung oder abweichende Geschäftsanforderungen zurückzuführen sein können. Diese Dimension wird häufig in Dashboards zur regionalen Leistung verwendet. Warum das wichtig ist Liefert einen geografischen oder standortbezogenen Analysekontext und hilft, regionale Prozessabweichungen und Leistungsunterschiede zu erkennen. Bezugsquelle Zu finden in der Tabelle EBAN, Feld WERKS. Beispiele 10002100DE01

Erforderlich Empfohlen Optional

Purchase to Pay - Requisition: Aktivitäten

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

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Anforderung abgelehnt	Dies ist eine abschließende Aktivität, bei der die Purchase Requisition endgültig abgelehnt wird und nicht weiterbearbeitet werden kann. Sie wird abgeleitet, wenn der Freigabeindikator in der Tabelle EBAN durch einen Genehmiger auf einen endgültig abgelehnten Status gesetzt wird.
Warum das wichtig ist Diese Aktivität ist ein wichtiger Endpunkt des Prozesses und entscheidend für die Berechnung der KPI zur Ablehnungsquote von Requisitions. Die Analyse dieser Fälle hilft, Gründe für das Scheitern von Beschaffungsvorgängen und entstehenden Aufwand zu verstehen. Bezugsquelle Abgeleitet aus dem Timestamp des Eintrags im Änderungsprotokoll in CDPOS für die Tabelle EBAN und das Feld FRGZU, sobald sich der Wert in den Wert für die endgültige Ablehnung ändert. Erfassen Abgeleitet daraus, dass das Feld für den endgültigen Freigabeindikator in EBAN einen abschließenden Status „rejected“ erreicht. Ereignistyp inferred
	Anforderung erstellt	Diese Aktivität kennzeichnet die erstmalige Erstellung und Speicherung einer Purchase Requisition durch einen Benutzer. Das Event wird ausdrücklich erfasst, sobald ein neuer Datensatz in der Tabelle EBAN angelegt wird und Erstellungsdatum sowie Erstellungszeit gespeichert werden.
Warum das wichtig ist Als Ausgangspunkt des Prozesses ist diese Aktivität entscheidend für die Berechnung der gesamten Lebenszyklusdauer einer Requisition und die Analyse des Erstellungsdurchsatzes. Sie zeigt, wer Requisitions erstellt und wann dies geschieht. Bezugsquelle Dieses Event wird für eine bestimmte Purchase-Requisition-ID (BANFN) aus der Tabelle EBAN anhand der Felder für Erstellungsdatum (ERDAT) und Erstellungszeit (UZEIT) erfasst. Erfassen Timestamp aus den Feldern ERDAT und UZEIT der Tabelle EBAN beim erstmaligen Speichern des Datensatzes. Ereignistyp explicit
	Anforderung genehmigt	Diese Meilensteinaktivität zeigt an, dass die Purchase Requisition alle erforderlichen Genehmigungsschritte erfolgreich durchlaufen hat. Sie wird abgeleitet, wenn der letzte Freigabecode angewendet und der übergeordnete Freigabeindikator (FRGZU) in der Tabelle EBAN auf einen genehmigten Status gesetzt wird.
Warum das wichtig ist Dieser Meilenstein markiert das Ende des Genehmigungszyklus und den Beginn der Beschaffungsphase. Er ist entscheidend für die Berechnung der KPI zur gesamten Genehmigungszeit und für die Messung von Übergabeverzögerungen bis zur Erstellung einer Purchase Order. Bezugsquelle Abgeleitet aus dem Timestamp des Eintrags im Änderungsprotokoll in CDPOS für die Tabelle EBAN und das Feld FRGZU, sobald sich der Wert in den Wert für die endgültige Genehmigung ändert. Erfassen Abgeleitet daraus, dass das Feld für den endgültigen Freigabeindikator in EBAN einen abschließenden Status „approved“ erreicht. Ereignistyp inferred
	Bestellanforderung zurückgezogen	Dies ist eine abschließende Aktivität, bei der der Ersteller oder ein autorisierter Benutzer die Position der Bestellanforderung durch Setzen eines Löschkennzeichens storniert. Die Aktion wird ausdrücklich protokolliert und zeigt an, dass der Geschäftsbedarf nicht mehr besteht oder versehentlich angelegt wurde.
Warum das wichtig ist Dies ist ein wichtiger Fehlerendpunkt des Prozesses und für die Berechnung der Rückzugsquote erforderlich. Hohe Quoten können auf lange Genehmigungszeiten hindeuten, die Benutzer zum Abbruch ihrer Anfragen veranlassen, oder auf systematische Probleme in der Bedarfsplanung. Bezugsquelle Diese ausdrückliche Aktion wird erfasst, wenn das Feld „Deletion Indicator“ (LOEKZ) in der Tabelle EBAN für die Position der Bestellanforderung gesetzt wird. Die Änderung wird in CDHDR und CDPOS protokolliert. Erfassen Eintrag im Änderungsprotokoll, wenn das Löschkennzeichen (EBAN-LOEKZ) auf „L“ gesetzt wird. Ereignistyp explicit
	Bestellung angelegt	Diese Aktivität kennzeichnet die erfolgreiche Umwandlung einer genehmigten Bestellanforderung in ein Bestelldokument. Das Ereignis wird für die Bestellanforderung abgeleitet, indem eine zugehörige Bestellposition ermittelt wird, die auf sie verweist.
Warum das wichtig ist Als primäres erfolgreiches Ergebnis beendet diese Aktivität den Prozess der Bestellanforderung und leitet die Beschaffungsphase ein. Die Zeit zwischen „Bestellanforderung genehmigt“ und diesem Ereignis ist ein wichtiger KPI zur Messung der Effizienz der Übergabe. Bezugsquelle Abgeleitet aus einem Datensatz in der Tabelle EKPO (Bestellposition), in dem die Felder BANFN und BNFPO mit der Nummer und Position der Bestellanforderung aus der Tabelle EBAN übereinstimmen. Das Anlagedatum der Bestellung (EKKO.AEDAT) liefert den Timestamp. Erfassen Abgeleitet durch die Verknüpfung der Tabellen EBAN und EKPO sowie die Verwendung des Anlagedatums der Bestellung aus EKKO. Ereignistyp inferred
	Genehmigung eingereicht	Diese Aktivität zeigt an, dass die Requisition in den formellen Genehmigungs-Workflow eingetreten ist. Sie wird in der Regel abgeleitet, sobald sich der Status der Requisition gemäß der konfigurierten Freigabestrategie so ändert, dass eine erste Freigabe oder Genehmigungsaktion erforderlich ist.
Warum das wichtig ist Damit beginnt die Genehmigungsdurchlaufzeit, eine zentrale KPI zur Messung der Prozesseffizienz. Dieser Zeitpunkt hilft, Verzögerungen zwischen der Erstellung und dem Start der formellen Genehmigungen abzugrenzen. Bezugsquelle Abgeleitet aus der ersten Statusänderung im Zusammenhang mit der Freigabestrategie in der Tabelle EBAN, etwa wenn sich das Feld FRGZU vom Ausgangszustand in einen ausstehenden Status ändert, oder aus dem ersten Eintrag in Workflow-Logs zur Requisition. Erfassen Abgeleitet aus dem ersten Eintrag im Änderungsprotokoll, der die Aktivierung einer Freigabestrategie anzeigt. Ereignistyp inferred
	Anforderung geändert	Bezeichnet jede Änderung an einer Purchase Requisition nach ihrer erstmaligen Erstellung, etwa eine Anpassung von Menge, Preis oder Material. Diese Änderungen werden in den Änderungsprotokolltabellen von SAP erfasst und bilden einen detaillierten Audit-Trail der Anpassungen.
Warum das wichtig ist Die Nachverfolgung von Änderungen ist entscheidend, um Nacharbeitschleifen und Probleme bei der Datenqualität zu identifizieren. Eine hohe Änderungsfrequenz kann auf unklare ursprüngliche Anforderungen oder Schulungslücken hinweisen und dadurch zu Prozessverzögerungen führen. Bezugsquelle Erfasst aus den Änderungsprotokolltabellen CDHDR (Kopf) und CDPOS (Position), wenn die Objektklasse EINKBELEG und die Objekt-ID der Nummer der Purchase Requisition entsprechen. Bestimmte Feldänderungen können analysiert werden. Erfassen Event, das in den Änderungstabellen CDHDR und CDPOS für das Dokument der Purchase Requisition protokolliert wird. Ereignistyp explicit
	Anforderung gesperrt	Bezeichnet die ausdrückliche Sperrung einer Position einer Purchase Requisition, wodurch ihre Umwandlung in eine Purchase Order verhindert wird. Die Sperre wird über einen bestimmten Indikator auf Positionsebene der Requisition gesetzt.
Warum das wichtig ist Eine Sperre weist auf ein mögliches Problem oder einen vorübergehenden Halt im Beschaffungsprozess hin. Die Nachverfolgung dieser Ereignisse hilft, Engpässe zu erkennen, bei denen Bestellanforderungen genehmigt, aber nicht unmittelbar bearbeitet werden. Bezugsquelle Erfasst durch eine Änderung im Feld „Blocking Indicator“ (EBAKZ) der Tabelle EBAN. Die Änderung wird in CDHDR und CDPOS protokolliert. Erfassen Ereignis, das in den Änderungstabellen protokolliert wird, wenn das Feld EBAN-EBAKZ gesetzt ist. Ereignistyp explicit
	Bestellanforderung geschlossen	Stellt den endgültigen Abschluss einer Position der Bestellanforderung dar und zeigt an, dass keine weitere Bearbeitung erwartet wird. Dieser Status wird abgeleitet, wenn die Position vollständig in eine Bestellung umgewandelt und erfüllt oder manuell als geschlossen gekennzeichnet wurde.
Warum das wichtig ist Damit steht ein eindeutiger Endpunkt für Bestellanforderungen zur Verfügung, die abgeschlossen, aber nicht unbedingt gelöscht wurden. So lassen sich die Lebenszyklusdauern erfolgreich erfüllter Anfragen präzise berechnen. Bezugsquelle Abgeleitet aus dem Kennzeichen „Closed“ (EBAKZ mit dem Wert „S“ oder einem anderen konfigurierten Wert) in der Tabelle EBAN. Dieser Status wird häufig automatisch vom System gesetzt, sobald die vollständige Umwandlung in eine Bestellung und der Wareneingang erfolgt sind. Erfassen Abgeleitet aus einer Statusänderung des Feldes EBAN-EBAKZ auf einen Wert für „geschlossen“. Ereignistyp inferred
	Genehmigung zurückgesetzt	Zeigt an, dass der gesamte Genehmigungs-Workflow der Requisition zurückgesetzt wurde, häufig aufgrund einer wesentlichen Änderung. Dies wird abgeleitet, wenn der Freigabestatus nach einer vorherigen Aktivierung gelöscht wird und der Genehmigungsprozess dadurch von vorn beginnen muss.
Warum das wichtig ist Das Zurücksetzen einer Genehmigung ist ein bedeutendes Nacharbeitsereignis und wirkt sich stark auf die Durchlaufzeit aus. Die Identifizierung solcher Fälle macht Ineffizienzen und die nachgelagerten Auswirkungen von Änderungen an Requisitions auf den Workflow sichtbar. Bezugsquelle Abgeleitet aus Änderungsprotokollen (CDHDR/CDPOS) zur Tabelle EBAN, wenn Freigabestatusfelder wie FRGZU von einem ausstehenden oder genehmigten Status in einen Ausgangs- oder leeren Status geändert werden. Erfassen Abgeleitet aus Änderungsprotokollen, die zeigen, dass die Felder der Freigabestrategie gelöscht wurden. Ereignistyp inferred
	Genehmigungsschritt abgelehnt	Ein autorisierter Benutzer hat einen einzelnen Schritt der Freigabestrategie ausdrücklich abgelehnt. In der Regel wird die Requisition dadurch zur Änderung an den Ersteller zurückgegeben. Die Aktion wird als Änderung des Freigabestatus der Requisition protokolliert.
Warum das wichtig ist Ablehnungen sind eine wesentliche Ursache für Nacharbeit und Verzögerungen. Die Analyse ihrer Häufigkeit und Gründe hilft, Missverständnisse bei Richtlinien, Probleme bei der Datenqualität oder ineffiziente Genehmigungsschritte zu identifizieren. Bezugsquelle Erfasst aus den Änderungsprotokollen (CDHDR/CDPOS) zu den Freigabestatusfeldern in der Tabelle EBAN. Eine Ablehnung über die Transaktion ME54N oder einen ähnlichen T-Code löst die entsprechende Statusänderung aus. Erfassen Eintrag im Änderungsprotokoll, der erstellt wird, wenn ein Genehmiger eine Ablehnung ausführt. Ereignistyp explicit
	Genehmigungsschritt genehmigt	Bezeichnet die ausdrückliche Genehmigung eines einzelnen Schritts der Freigabestrategie durch einen autorisierten Benutzer. Diese Aktion wird als Änderung des Freigabestatus der Requisition erfasst und bringt sie der endgültigen Genehmigung näher.
Warum das wichtig ist Die Nachverfolgung einzelner Genehmigungen ist erforderlich, um die Dauer jedes Schritts zu messen und die Leistung verschiedener Genehmiger zu analysieren. Sie bildet eine wichtige Grundlage für das Verständnis der Workflow-Konformität. Bezugsquelle Erfasst aus den Änderungsprotokollen (CDHDR/CDPOS) zu den Freigabestatusfeldern der Tabelle EBAN. Die Aktion des Genehmigers über die Transaktion ME54N oder einen ähnlichen T-Code löst diese protokollierte Änderung aus. Erfassen Eintrag im Änderungsprotokoll, der erstellt wird, wenn ein Genehmiger eine Freigabetransaktion ausführt. Ereignistyp explicit
	Genehmigungsschritt gestartet	Zeigt an, dass die Requisition nun auf eine Aktion eines bestimmten Genehmigers oder einer Genehmigungsgruppe wartet, wie in der Freigabestrategie definiert. Dieses Event wird abgeleitet, wenn der Status der Requisition anzeigt, dass sie auf einen bestimmten Freigabecode wartet.
Warum das wichtig ist Diese Aktivität ermöglicht eine detaillierte Analyse jedes einzelnen Schritts in der Genehmigungskette. Sie hilft dabei, Genehmiger oder Prozessphasen zu identifizieren, die für die längsten Verzögerungen verantwortlich sind. Bezugsquelle Abgeleitet durch die Nachverfolgung der Abfolge von Änderungen an den Freigabestatusfeldern in der Tabelle EBAN. Jede Änderung in einen neuen ausstehenden Status kennzeichnet den Beginn eines neuen Genehmigungsschritts. Erfassen Abgeleitet aus Statusänderungen, die anzeigen, dass ein neuer Freigabecode aktiv ist und auf Genehmigung wartet. Ereignistyp inferred

Anleitungen zur Extraktion

So extrahieren Sie Ihre Daten aus SAP ECC

Schritte

Datenbankzugriff gewähren: Stellen Sie vor Beginn sicher, dass Sie Lesezugriff auf die zugrunde liegende SAP-ECC-Datenbank haben. Dafür benötigen Sie bestimmte Zugangsdaten (Benutzername, Passwort, Host, Port). Dieser Zugriff ist nicht standardmäßig vorgesehen und muss von Ihren SAP-Basis- und Sicherheitsteams genehmigt werden.
SAP-Schema identifizieren: Stellen Sie mit einem Standard-SQL-Client wie DBeaver, Toad oder SQL Developer eine Verbindung zur Datenbank her. Sie müssen das korrekte SAP-Schema identifizieren, in dem die Tabellen gespeichert sind. Es heißt häufig SAPSR3 oder SAPR3.
SQL-Abfrage vorbereiten: Verwenden Sie die vollständige SQL-Abfrage aus diesem Dokument. Die Abfrage extrahiert durch Verknüpfung von Stamm- und Änderungsprotokolldaten alle erforderlichen Aktivitäten und Attribute.
Abfrageparameter festlegen: Suchen Sie die Platzhalter in der Abfrage. Ersetzen Sie sie durch die Werte für Ihr System und Ihre fachlichen Anforderungen. Zu den wichtigsten Platzhaltern gehören '{source_system_name}', '{start_date}', '{end_date}', '{company_codes}' und '{document_types}'.
Datenbankspezifische Syntax anpassen: Die bereitgestellte Abfrage verwendet gängige SQL-Syntax. Funktionen zur Erstellung von Timestamps wie TO_TIMESTAMP oder zur Zeichenkettenverarbeitung müssen je nach Datenbanksystem, zum Beispiel Oracle, SQL Server, DB2 oder HANA, möglicherweise geringfügig angepasst werden.
Extraktion ausführen: Führen Sie die angepasste Abfrage in Ihrem SQL-Client aus. Bei großen Datenmengen empfiehlt sich die Ausführung außerhalb der Spitzenzeiten, damit die Systemleistung nicht beeinträchtigt wird.
Vorläufige Ergebnisse prüfen: Prüfen Sie nach Abschluss der Abfrage kurz, ob die erwarteten Spalten (PurchaseRequisitionId, ActivityName, EventTime usw.) enthalten sind und Datensätze für verschiedene Aktivitäten zurückgegeben werden.
Als CSV exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Stellen Sie sicher, dass die Datei UTF-8-codiert ist, damit Sonderzeichen korrekt verarbeitet werden.
Upload vorbereiten: Prüfen Sie, ob die CSV-Spaltenüberschriften exakt den in der SQL-Abfrage definierten Aliasnamen entsprechen. Die Datei sollte eine übersichtliche tabellarische Darstellung des Event Logs enthalten.
In ProcessMind hochladen: Laden Sie die fertige CSV-Datei in Ihr ProcessMind-Projekt hoch, um sie zu analysieren und zu visualisieren.

Konfiguration

Datenbankverbindung: Eine direkte Verbindung zur SAP-ECC-Datenbank ist erforderlich. Sie benötigen den Hostnamen, den Port, den Datenbanknamen und geeignete Benutzerzugangsdaten.
SAP-Schema: Der Name des Schemas mit den SAP-Tabellen muss bekannt sein, zum Beispiel SAPSR3. Die Abfrage muss im Kontext dieses Schemas ausgeführt werden.
Zeitraum: Um Performance und Datenvolumen zu steuern, ist die Filterung nach einem bestimmten Zeitraum entscheidend. Wir empfehlen, mit einem Zeitraum von 3 bis 6 Monaten zu beginnen. Setzen Sie die Platzhalter '{start_date}' und '{end_date}' im Format YYYYMMDD.
Organisationsfilter: Für eine gezieltere Analyse filtern Sie die Daten nach Buchungskreis (BUKRS) und Dokumenttyp der Bestellanforderung (BSART). Ersetzen Sie die Platzhalter '{company_codes}' und '{document_types}' durch kommagetrennte Wertelisten, zum Beispiel '1000','2000'.
Voraussetzungen: Für diese Methode ist die Genehmigung des SAP-Basis- und Sicherheitsteams erforderlich, um direkte Datenbankzugangsdaten zu erhalten. Sie gehört nicht zu den üblichen Tätigkeiten von Endbenutzern.
Performance-Hinweise: Die Abfrage verknüpft Änderungsprotokolltabellen (CDHDR, CDPOS), die sehr groß sein können. Ohne geeignete Filter kann die Abfrage langsam sein und erhebliche Systemressourcen beanspruchen. Führen Sie sie immer mit einem begrenzten Zeitraum und weiteren Filtern aus.

a Beispielabfrage sql

WITH REQUISITION_BASE AS (
    SELECT 
        EBAN.MANDT,
        EBAN.BANFN,
        EBAN.BNFPO,
        EBAN.BSART AS RequisitionDocumentType,
        EBAN.ERNAM,
        EBAN.ERDAT,
        EBAN.ERZET,
        EBAN.FRGZU AS CurrentRequisitionStatus,
        EBAKN.KOSTL AS Department,
        EBAKN.GSWRT
    FROM EBAN
    LEFT JOIN EBAKN ON EBAN.MANDT = EBAKN.MANDT AND EBAN.BANFN = EBAKN.BANFN AND EBAN.BNFPO = EBAKN.BNFPO
    WHERE EBAN.ERDAT BETWEEN '{start_date}' AND '{end_date}'
      AND EBAN.BUKRS IN ('{company_codes}')
      AND EBAN.BSART IN ('{document_types}')
),
REQUISITION_AGG AS (
    SELECT 
        MANDT, BANFN, RequisitionDocumentType, ERNAM, ERDAT, ERZET, CurrentRequisitionStatus, Department,
        SUM(GSWRT) AS TotalRequisitionValue
    FROM REQUISITION_BASE
    GROUP BY MANDT, BANFN, RequisitionDocumentType, ERNAM, ERDAT, ERZET, CurrentRequisitionStatus, Department
)
-- 1. Requisition Created
SELECT
    R.BANFN AS PurchaseRequisitionId,
    'Requisition Created' AS ActivityName,
    TO_TIMESTAMP(R.ERDAT || R.ERZET, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    R.ERNAM AS User,
    R.Department AS Department,
    R.CurrentRequisitionStatus AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM REQUISITION_AGG R

UNION ALL

-- 2. Requisition Amended, Approval Steps, Status Changes from Change Logs
SELECT 
    SUBSTRING(C.OBJECTID, 4, 10) AS PurchaseRequisitionId,
    CASE 
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW > C.VALUE_OLD THEN 'Approval Step Approved'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW < C.VALUE_OLD THEN 'Approval Step Rejected'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW = '{final_approval_status_code}' THEN 'Requisition Approved'
        WHEN C.FNAME = 'FRGZU' AND C.VALUE_NEW = '{final_rejection_status_code}' THEN 'Requisition Rejected'
        WHEN C.FNAME = 'FRGSX' AND C.VALUE_OLD IS NOT NULL AND C.VALUE_NEW IS NULL THEN 'Approval Reset'
        WHEN C.FNAME = 'FRGZU' AND C.CHNGIND = 'U' AND C.TCODE LIKE 'ME54%' THEN 'Approval Submitted' 
        WHEN C.FNAME = 'LOEKZ' AND C.VALUE_NEW IN ('L', 'X') THEN 'Requisition Withdrawn'
        WHEN C.FNAME = 'EBAKZ' AND C.VALUE_NEW = 'X' THEN 'Requisition Blocked'
        WHEN C.FNAME = 'STATU' AND C.VALUE_NEW = 'B' THEN 'Purchase Order Created'
        WHEN C.FNAME = 'EREKZ' AND C.VALUE_NEW = 'X' THEN 'Requisition Closed'
        ELSE 'Requisition Amended'
    END AS ActivityName,
    TO_TIMESTAMP(C.UDATE || C.UTIME, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    C.USERNAME AS User,
    R.Department AS Department,
    C.VALUE_NEW AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM CDHDR C
JOIN CDPOS P ON C.MANDANT = P.MANDANT AND C.OBJECTCLAS = P.OBJECTCLAS AND C.OBJECTID = P.OBJECTID AND C.CHANGENR = P.CHANGENR
JOIN REQUISITION_AGG R ON SUBSTRING(C.OBJECTID, 4, 10) = R.BANFN
WHERE C.OBJECTCLAS = 'BANF'
  AND C.UDATE || C.UTIME <> R.ERDAT || R.ERZET -- Exclude changes made at the exact time of creation
  AND NOT (C.TCODE IN ('ME51', 'ME51N') AND C.UDATE = R.ERDAT) -- Exclude initial creation events from being amendments

UNION ALL

-- 3. Approval Step Started (Inferred)
SELECT 
    SUBSTRING(C.OBJECTID, 4, 10) AS PurchaseRequisitionId,
    'Approval Step Started' AS ActivityName,
    TO_TIMESTAMP(C.UDATE || C.UTIME, 'YYYYMMDDHH24MISS') AS EventTime,
    '{source_system_name}' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    C.USERNAME AS User,
    R.Department AS Department,
    P.VALUE_OLD AS RequisitionStatus,
    R.RequisitionDocumentType AS RequisitionDocumentType,
    R.TotalRequisitionValue AS TotalRequisitionValue
FROM CDHDR C
JOIN CDPOS P ON C.MANDANT = P.MANDANT AND C.OBJECTCLAS = P.OBJECTCLAS AND C.OBJECTID = P.OBJECTID AND C.CHANGENR = P.CHANGENR
JOIN REQUISITION_AGG R ON SUBSTRING(C.OBJECTID, 4, 10) = R.BANFN
WHERE C.OBJECTCLAS = 'BANF' AND P.FNAME = 'FRGZU' AND P.CHNGIND = 'U'
  AND P.VALUE_OLD IS NOT NULL AND P.VALUE_NEW IS NOT NULL AND P.VALUE_NEW > P.VALUE_OLD; -- This logic infers that a step starts just before it is approved

Schritte

Python-Umgebung einrichten: Stellen Sie sicher, dass Python 3.6 oder höher installiert ist. Erstellen Sie einen Projektordner und richten Sie eine virtuelle Umgebung zur Verwaltung von Abhängigkeiten ein. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install pyrfc pandas numpy
SAP RFC SDK: Laden Sie das SAP NetWeaver RFC SDK aus dem SAP Support Portal herunter. Entpacken Sie den Inhalt und legen Sie die Bibliotheksdateien, zum Beispiel sapnwrfc.dll unter Windows oder libsapnwrfc.so unter Linux, in einem Verzeichnis ab, das über den Systempfad oder Ihr Python-Skript erreichbar ist.
SAP-Verbindung konfigurieren: Öffnen Sie das bereitgestellte Python-Skript. Suchen Sie den Abschnitt mit den Parametern für die SAP-Verbindung und ersetzen Sie die Platzhalterwerte (ashost, sysnr, client, user, passwd) durch die Zugangsdaten Ihres SAP-Systems. Stellen Sie sicher, dass der Benutzer über die erforderlichen Berechtigungen für die RFC-Ausführung und den Tabellenzugriff verfügt.
Extraktionsparameter festlegen: Setzen Sie im Skript die Variablen date_from und date_to, um den gewünschten Zeitraum für die Extraktion festzulegen. Beginnen Sie für einen Test der Extraktion möglichst mit einem kürzeren Zeitraum, zum Beispiel einem Monat.
Python-Skript ausführen: Führen Sie das Skript in Ihrem Terminal mit dem Befehl python your_script_name.py aus. Das Skript verbindet sich über RFC mit SAP, ruft für jede benötigte Tabelle (EBAN, EKKO, EKPO, CDHDR, CDPOS) RFC_READ_TABLE auf und lädt die Daten herunter.
Daten abrufen: Das Skript ruft Rohdaten zu BANF, Bestellungen und Änderungsbelegen ab. Mithilfe von Filterkriterien wie Zeiträumen und Objektklassen begrenzt es die übertragene Datenmenge.
Lokale Datentransformation: Nach dem Download der Daten verwendet das Skript die Bibliothek pandas, um alle Transformationen lokal durchzuführen. Es verarbeitet die Rohdaten der Tabellen und erzeugt für jede der 13 erforderlichen Aktivitäten eigene Event-Log-Einträge, zum Beispiel „BANF angelegt“, „Genehmigungsschritt genehmigt“ und „Bestellung angelegt“.
Event Log erzeugen: Das Skript führt die aus den einzelnen Tabellen erzeugten Ereignisse in einem einheitlichen DataFrame zusammen. Es berechnet Ereignis-Timestamps, ordnet Benutzernamen zu und strukturiert die Daten im erforderlichen Format mit Case-ID, Aktivität und Timestamp.
Attribute zuordnen: Wichtige Attribute wie PurchaseRequisitionId, ActivityName, EventTime, Benutzer und TotalRequisitionValue werden den entsprechenden Spalten im finalen DataFrame zugeordnet.
Als CSV exportieren: Das Skript speichert das finale Event Log als CSV-Datei mit dem Namen event_log_pr.csv im selben Verzeichnis. Diese Datei ist für den direkten Upload in ProcessMind formatiert.
Prüfen und hochladen: Öffnen Sie die erzeugte CSV-Datei und prüfen Sie die Daten auf Vollständigkeit und Richtigkeit. Nach der Validierung können Sie die Datei in Ihr ProcessMind-Projekt hochladen.

Konfiguration

SAP-Verbindung: Das Skript benötigt direkte RFC-Verbindungsdaten zum SAP-ECC-System, darunter Applikationsserver, Systemnummer, Mandant, Benutzer und Passwort. Der angegebene Benutzer muss über Berechtigungen für RFC-Aufrufe und Anzeigezugriff auf die Tabellen EBAN, EKPO, EKKO, CDHDR und CDPOS verfügen.
Zeitraum: Die Extraktion wird durch Start- und Enddatumparameter im Skript gesteuert. Für erste Ausführungen und zur Steuerung der Performance empfiehlt sich die Extraktion eines Zeitraums von 3 bis 6 Monaten.
Tabellenfilter: Soweit möglich, wird innerhalb der RFC-Aufrufe gefiltert. Bestellanforderungen werden beispielsweise nach dem Erstellungsdatum (EBAN-ERDAT) und Änderungsbelege nach Datum (CDHDR-UDATE) sowie Objektklasse (CDHDR-OBJECTCLAS = 'BANF') gefiltert.
Python-Bibliotheken: Das Skript verwendet pyrfc für die SAP-Anbindung und pandas für die Datenverarbeitung. Stellen Sie sicher, dass diese Bibliotheken in Ihrer Python-Umgebung installiert sind.
Performance: Die Extraktion über RFC_READ_TABLE kann bei sehr großen Datenmengen langsam sein, da die Daten sequenziell Tabelle für Tabelle abgerufen werden. Führen Sie die Extraktion möglichst außerhalb der Spitzenzeiten aus, um die Systemlast zu begrenzen.
Dokumenttypen: Das Skript extrahiert standardmäßig alle Dokumenttypen von Bestellanforderungen. Um den Umfang einzugrenzen, können Sie nach der Extraktion einen Filter im pandas-DataFrame auf Basis der Spalte BSART aus der Tabelle EBAN ergänzen.

a Beispielabfrage python

import pandas as pd
from pyrfc import Connection
import datetime

class=class="hl-string">"hl-comment"># --- 1. Configuration Settings ---
class=class="hl-string">"hl-comment"># Replace with your SAP system connection details
SAP_CONNECTION_PARAMS = {
    class="hl-string">"ashost": class="hl-string">"your_sap_host",      class=class="hl-string">"hl-comment"># Application server host
    class="hl-string">"sysnr": class="hl-string">"00",                 class=class="hl-string">"hl-comment"># System number
    class="hl-string">"client": class="hl-string">"100",               class=class="hl-string">"hl-comment"># Client
    class="hl-string">"user": class="hl-string">"your_rfc_user",       class=class="hl-string">"hl-comment"># RFC user
    class="hl-string">"passwd": class="hl-string">"your_password"      class=class="hl-string">"hl-comment"># Password
}

class=class="hl-string">"hl-comment"># Date range for the extraction (YYYYMMDD format)
date_from = class="hl-string">'20230101'
date_to = class="hl-string">'20231231'

source_system = class="hl-string">"SAP ECC"
last_data_update = datetime.datetime.now().isoformat()

class=class="hl-string">"hl-comment"># --- 2. Helper function for RFC_READ_TABLE ---
def rfc_read_table(conn, table_name, fields, options):
    class="hl-string">"""Fetches data from an SAP table using RFC_READ_TABLE."""
    try:
        result = conn.call(class="hl-string">'RFC_READ_TABLE',
                           QUERY_TABLE=table_name,
                           DELIMITER=class="hl-string">',',
                           FIELDS=fields,
                           OPTIONS=options)
        
        data = result[class="hl-string">'DATA']
        if not data:
            return pd.DataFrame(columns=[field[class="hl-string">'FIELDNAME'] for field in fields])

        records = [row[class="hl-string">'WA'].strip().split(class="hl-string">',') for row in data]
        df = pd.DataFrame(records, columns=[field[class="hl-string">'FIELDNAME'] for field in fields])
        class=class="hl-string">"hl-comment"># Trim whitespace from all cells
        df = df.apply(lambda x: x.str.strip() if x.dtype == class="hl-string">"object" else x)
        return df
    except Exception as e:
        print(fclass="hl-string">"Error reading table {table_name}: {e}")
        return pd.DataFrame(columns=[field[class="hl-string">'FIELDNAME'] for field in fields])

class=class="hl-string">"hl-comment"># --- 3. Main Extraction Logic ---
def main():
    print(class="hl-string">"Starting SAP data extraction...")
    try:
        conn = Connection(**SAP_CONNECTION_PARAMS)
    except Exception as e:
        print(fclass="hl-string">"Failed to connect to SAP: {e}")
        return

    class=class="hl-string">"hl-comment"># --- EBAN (Purchase Requisitions) ---
    print(class="hl-string">"Extracting EBAN...")
    eban_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'BANFN'}, {class="hl-string">'FIELDNAME': class="hl-string">'BNFPO'}, {class="hl-string">'FIELDNAME': class="hl-string">'BSART'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERNAM'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERDAT'}, {class="hl-string">'FIELDNAME': class="hl-string">'ERFZEIT'}, {class="hl-string">'FIELDNAME': class="hl-string">'PREIS'}, {class="hl-string">'FIELDNAME': class="hl-string">'MENGE'}, {class="hl-string">'FIELDNAME': class="hl-string">'KOSTL'}, {class="hl-string">'FIELDNAME': class="hl-string">'FRGZU'}, {class="hl-string">'FIELDNAME': class="hl-string">'FRGSX'}]
    eban_options = [fclass="hl-string">"ERDAT >= '{date_from}' AND ERDAT <= '{date_to}'"]
    df_eban = rfc_read_table(conn, class="hl-string">'EBAN', eban_fields, eban_options)
    if df_eban.empty:
        print(class="hl-string">"No requisitions found in EBAN for the given date range. Exiting.")
        conn.close()
        return

    df_eban[class="hl-string">'PREIS'] = pd.to_numeric(df_eban[class="hl-string">'PREIS'], errors=class="hl-string">'coerce').fillna(0)
    df_eban[class="hl-string">'MENGE'] = pd.to_numeric(df_eban[class="hl-string">'MENGE'], errors=class="hl-string">'coerce').fillna(0)
    df_eban[class="hl-string">'TotalRequisitionValue'] = df_eban[class="hl-string">'PREIS'] * df_eban[class="hl-string">'MENGE']
    df_eban_grouped = df_eban.groupby(class="hl-string">'BANFN').agg(
        TotalRequisitionValue=(class="hl-string">'TotalRequisitionValue', class="hl-string">'sum'),
        RequisitionDocumentType=(class="hl-string">'BSART', class="hl-string">'first'),
        Department=(class="hl-string">'KOSTL', class="hl-string">'first')
    ).reset_index()
    df_eban = df_eban.merge(df_eban_grouped, on=class="hl-string">'BANFN', suffixes=(class="hl-string">'', class="hl-string">'_agg'))

    class=class="hl-string">"hl-comment"># --- EKPO/EKKO (Purchase Orders) ---
    print(class="hl-string">"Extracting EKPO and EKKO...")
    banfn_list = class="hl-string">"'" + class="hl-string">"', '".join(df_eban[class="hl-string">'BANFN'].unique()) + class="hl-string">"'"
    ekpo_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'BANFN'}, {class="hl-string">'FIELDNAME': class="hl-string">'BNFPO'}, {class="hl-string">'FIELDNAME': class="hl-string">'EBELN'}]
    ekpo_options = [fclass="hl-string">"BANFN IN ({banfn_list})"]
    df_ekpo = rfc_read_table(conn, class="hl-string">'EKPO', ekpo_fields, ekpo_options)

    ekko_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'EBELN'}, {class="hl-string">'FIELDNAME': class="hl-string">'AEDAT'}]
    if not df_ekpo.empty:
        ebeln_list = class="hl-string">"'" + class="hl-string">"', '".join(df_ekpo[class="hl-string">'EBELN'].unique()) + class="hl-string">"'"
        ekko_options = [fclass="hl-string">"EBELN IN ({ebeln_list})"]
        df_ekko = rfc_read_table(conn, class="hl-string">'EKKO', ekko_fields, ekko_options)
        df_po = pd.merge(df_ekpo, df_ekko, on=class="hl-string">'EBELN')
    else:
        df_po = pd.DataFrame(columns=[class="hl-string">'BANFN', class="hl-string">'BNFPO', class="hl-string">'EBELN', class="hl-string">'AEDAT'])

    class=class="hl-string">"hl-comment"># --- CDHDR/CDPOS (Change Documents) ---
    print(class="hl-string">"Extracting CDHDR and CDPOS...")
    cdhdr_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'OBJECTID'}, {class="hl-string">'FIELDNAME': class="hl-string">'CHANGENR'}, {class="hl-string">'FIELDNAME': class="hl-string">'USERNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'UDATE'}, {class="hl-string">'FIELDNAME': class="hl-string">'UTIME'}]
    cdhdr_options = [fclass="hl-string">"OBJECTCLAS = 'BANF' AND UDATE >= '{date_from}' AND UDATE <= '{date_to}'"]
    df_cdhdr = rfc_read_table(conn, class="hl-string">'CDHDR', cdhdr_fields, cdhdr_options)
    
    df_cdpos = pd.DataFrame()
    if not df_cdhdr.empty:
        class=class="hl-string">"hl-comment"># Process changenr in chunks to avoid overly long SQL queries
        changenr_chunks = [df_cdhdr[class="hl-string">'CHANGENR'][i:i + 100] for i in range(0, df_cdhdr.shape[0], 100)]
        cdpos_fields = [{class="hl-string">'FIELDNAME': class="hl-string">'CHANGENR'}, {class="hl-string">'FIELDNAME': class="hl-string">'TABNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'FNAME'}, {class="hl-string">'FIELDNAME': class="hl-string">'VALUE_NEW'}, {class="hl-string">'FIELDNAME': class="hl-string">'VALUE_OLD'}]
        cdpos_frames = []
        for chunk in changenr_chunks:
            changenr_list = class="hl-string">"'" + class="hl-string">"', '".join(chunk) + class="hl-string">"'"
            cdpos_options = [fclass="hl-string">"OBJECTCLAS = 'BANF' AND CHANGENR IN ({changenr_list}) AND TABNAME = 'EBAN'"]
            cdpos_frames.append(rfc_read_table(conn, class="hl-string">'CDPOS', cdpos_fields, cdpos_options))
        if cdpos_frames:
            df_cdpos = pd.concat(cdpos_frames, ignore_index=True)

    conn.close()
    print(class="hl-string">"Extraction from SAP complete. Starting transformation...")

    class=class="hl-string">"hl-comment"># --- 4. Event Log Generation ---
    events = []

    class=class="hl-string">"hl-comment"># Activity: Requisition Created
    df_created = df_eban[[class="hl-string">'BANFN', class="hl-string">'ERNAM', class="hl-string">'ERDAT', class="hl-string">'ERFZEIT', class="hl-string">'RequisitionDocumentType', class="hl-string">'TotalRequisitionValue', class="hl-string">'Department']].drop_duplicates(subset=[class="hl-string">'BANFN'])
    for _, row in df_created.iterrows():
        events.append({
            class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'BANFN'],
            class="hl-string">'ActivityName': class="hl-string">'Requisition Created',
            class="hl-string">'EventTime': fclass="hl-string">"{row['ERDAT']} {row['ERFZEIT']}",
            class="hl-string">'User': row[class="hl-string">'ERNAM'],
            class="hl-string">'RequisitionDocumentType': row[class="hl-string">'RequisitionDocumentType'],
            class="hl-string">'TotalRequisitionValue': row[class="hl-string">'TotalRequisitionValue'],
            class="hl-string">'Department': row[class="hl-string">'Department'],
            class="hl-string">'RequisitionStatus': class="hl-string">'Created'
        })

    class=class="hl-string">"hl-comment"># Merge change documents
    df_changes = pd.DataFrame()
    if not df_cdhdr.empty and not df_cdpos.empty:
        df_changes = pd.merge(df_cdhdr, df_cdpos, on=class="hl-string">'CHANGENR')
        df_changes[class="hl-string">'PurchaseRequisitionId'] = df_changes[class="hl-string">'OBJECTID'].str[:10]
        df_changes[class="hl-string">'EventTime'] = pd.to_datetime(df_changes[class="hl-string">'UDATE'] + class="hl-string">' ' + df_changes[class="hl-string">'UTIME'], format=class="hl-string">'%Y%m%d %H%M%S')

    if not df_changes.empty:
        class=class="hl-string">"hl-comment"># Activities from Change Logs
        for _, row in df_changes.iterrows():
            activity = None
            status = None

            class=class="hl-string">"hl-comment"># Approval-related activities
            if row[class="hl-string">'FNAME'] in [class="hl-string">'FRGZU', class="hl-string">'FRGSX']:
                if row[class="hl-string">'VALUE_OLD'].strip() == class="hl-string">'' and row[class="hl-string">'VALUE_NEW'].strip() != class="hl-string">'':
                    activity = class="hl-string">'Approval Submitted'
                    status = class="hl-string">'In Approval'
                elif row[class="hl-string">'VALUE_OLD'] != class="hl-string">'' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'':
                    activity = class="hl-string">'Approval Reset'
                    status = class="hl-string">'In Progress'
                else:
                    class=class="hl-string">"hl-comment"># Logic to differentiate approve/reject might need config specifics
                    activity = class="hl-string">'Approval Step Approved' if row[class="hl-string">'VALUE_NEW'] > row[class="hl-string">'VALUE_OLD'] else class="hl-string">'Approval Step Rejected'
                    status = class="hl-string">'In Approval'
            class=class="hl-string">"hl-comment"># Final Approval/Rejection
            elif row[class="hl-string">'FNAME'] == class="hl-string">'FRGZU':
                 class=class="hl-string">"hl-comment"># This logic assumes specific final approval/rejection codes. Adjust if needed.
                 if row[class="hl-string">'VALUE_NEW'] in [class="hl-string">'X', class="hl-string">'Y', class="hl-string">'Z']: class=class="hl-string">"hl-comment"># Placeholder for final approval states
                     activity = class="hl-string">'Requisition Approved'
                     status = class="hl-string">'Approved'
                 elif row[class="hl-string">'VALUE_NEW'] in [class="hl-string">'R', class="hl-string">'S']: class=class="hl-string">"hl-comment"># Placeholder for final rejection states
                     activity = class="hl-string">'Requisition Rejected'
                     status = class="hl-string">'Rejected'
            class=class="hl-string">"hl-comment"># Other Amendments
            elif row[class="hl-string">'FNAME'] not in [class="hl-string">'FRGZU', class="hl-string">'FRGSX', class="hl-string">'LOEKZ', class="hl-string">'EBAKZ']:
                activity = class="hl-string">'Requisition Amended'
                status = class="hl-string">'Amended'
            class=class="hl-string">"hl-comment"># Blocked
            elif row[class="hl-string">'FNAME'] == class="hl-string">'EBAKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'B':
                activity = class="hl-string">'Requisition Blocked'
                status = class="hl-string">'Blocked'
            class=class="hl-string">"hl-comment"># Withdrawn
            elif row[class="hl-string">'FNAME'] == class="hl-string">'LOEKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'L':
                activity = class="hl-string">'Requisition Withdrawn'
                status = class="hl-string">'Withdrawn'
            class=class="hl-string">"hl-comment"># Closed
            elif row[class="hl-string">'FNAME'] == class="hl-string">'EBAKZ' and row[class="hl-string">'VALUE_NEW'] == class="hl-string">'L':
                activity = class="hl-string">'Requisition Closed'
                status = class="hl-string">'Closed'

            if activity:
                events.append({
                    class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'PurchaseRequisitionId'],
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': row[class="hl-string">'EventTime'].strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
                    class="hl-string">'User': row[class="hl-string">'USERNAME'],
                    class="hl-string">'RequisitionStatus': status
                })

    class=class="hl-string">"hl-comment"># Activity: Purchase Order Created
    if not df_po.empty:
        df_po_first = df_po.sort_values(class="hl-string">'AEDAT').drop_duplicates(class="hl-string">'BANFN', keep=class="hl-string">'first')
        for _, row in df_po_first.iterrows():
            events.append({
                class="hl-string">'PurchaseRequisitionId': row[class="hl-string">'BANFN'],
                class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created',
                class="hl-string">'EventTime': fclass="hl-string">"{row['AEDAT']} 00:00:00", class=class="hl-string">"hl-comment"># EKKO only has date
                class="hl-string">'User': None, class=class="hl-string">"hl-comment"># User info not directly in EKKO/EKPO for this event
                class="hl-string">'RequisitionStatus': class="hl-string">'PO Created'
            })
            
    class=class="hl-string">"hl-comment"># Dummy activities for Approval Step Started (inferred before approval)
    class=class="hl-string">"hl-comment"># This is a simplified inference. Real logic can be much more complex.
    approval_events = [e for e in events if e[class="hl-string">'ActivityName'] == class="hl-string">'Approval Step Approved']
    for event in approval_events:
        event_time = pd.to_datetime(event[class="hl-string">'EventTime'])
        class=class="hl-string">"hl-comment"># Infer class="hl-string">'started' event one minute before class="hl-string">'approved' for demonstration
        start_time = event_time - datetime.timedelta(minutes=1)
        events.append({
            class="hl-string">'PurchaseRequisitionId': event[class="hl-string">'PurchaseRequisitionId'],
            class="hl-string">'ActivityName': class="hl-string">'Approval Step Started',
            class="hl-string">'EventTime': start_time.strftime(class="hl-string">'%Y-%m-%d %H:%M:%S'),
            class="hl-string">'User': None, class=class="hl-string">"hl-comment"># Approver user is not known until they approve
            class="hl-string">'RequisitionStatus': class="hl-string">'In Approval'
        })

    class=class="hl-string">"hl-comment"># --- 5. Final Formatting ---
    if not events:
        print(class="hl-string">"No events generated. Exiting.")
        return

    df_event_log = pd.DataFrame(events)
    df_event_log = df_event_log.merge(df_eban_grouped, left_on=class="hl-string">'PurchaseRequisitionId', right_on=class="hl-string">'BANFN', how=class="hl-string">'left')
    df_event_log[class="hl-string">'EventTime'] = pd.to_datetime(df_event_log[class="hl-string">'EventTime'])
    df_event_log = df_event_log.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Fill forward attributes within each case
    df_event_log[class="hl-string">'RequisitionDocumentType'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'RequisitionDocumentType_agg'].transform(lambda x: x.ffill().bfill())
    df_event_log[class="hl-string">'TotalRequisitionValue'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'TotalRequisitionValue_agg'].transform(lambda x: x.ffill().bfill())
    df_event_log[class="hl-string">'Department'] = df_event_log.groupby(class="hl-string">'PurchaseRequisitionId')[class="hl-string">'Department_agg'].transform(lambda x: x.ffill().bfill())

    class=class="hl-string">"hl-comment"># Add standard columns
    df_event_log[class="hl-string">'SourceSystem'] = source_system
    df_event_log[class="hl-string">'LastDataUpdate'] = last_data_update

    class=class="hl-string">"hl-comment"># Select and rename final columns
    final_columns = {
        class="hl-string">'PurchaseRequisitionId': class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'ActivityName': class="hl-string">'ActivityName',
        class="hl-string">'EventTime': class="hl-string">'EventTime',
        class="hl-string">'SourceSystem': class="hl-string">'SourceSystem',
        class="hl-string">'LastDataUpdate': class="hl-string">'LastDataUpdate',
        class="hl-string">'User': class="hl-string">'User',
        class="hl-string">'Department': class="hl-string">'Department',
        class="hl-string">'RequisitionStatus': class="hl-string">'RequisitionStatus',
        class="hl-string">'RequisitionDocumentType': class="hl-string">'RequisitionDocumentType',
        class="hl-string">'TotalRequisitionValue': class="hl-string">'TotalRequisitionValue'
    }
    df_event_log = df_event_log[final_columns.keys()].rename(columns=final_columns)
    
    class=class="hl-string">"hl-comment"># Save to CSV
    df_event_log.to_csv(class="hl-string">'event_log_pr.csv', index=False)
    print(class="hl-string">"Event log successfully created: event_log_pr.csv")

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

Bereit für den Start?

Verwenden Sie dieses Template, um Ihre Daten optimal für Process Mining zu strukturieren und aussagekräftige Erkenntnisse über Ihren Purchase-to-Pay-Prozess für Bestellanforderungen zu gewinnen. Beginnen Sie noch heute mit der Optimierung Ihres Prozesses!

Zurück zum Leitfaden zur Verbesserung Template herunterladen

Steigern Sie die Effizienz Ihrer P2P-Bestellanforderungen, starten Sie jetzt Ihre Testphase

Lokalisieren und beheben Sie P2P-Engpässe und verkürzen Sie die Durchlaufzeit um 30 % oder mehr.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich, 14 Tage kostenloser Zugang

Ihr Daten-Template für Purchase to Pay, Bestellanforderung

Ihr Daten-Template für Purchase to Pay, Bestellanforderung

Purchase to Pay - Requisition: Attribute

Purchase to Pay - Requisition: Aktivitäten

Anleitungen zur Extraktion

Direkte SQL-Abfrage auf der zugrunde liegenden SAP-ECC-Datenbank

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit SAP RFC zur Tabellenextraktion

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Steigern Sie die Effizienz Ihrer P2P-Bestellanforderungen, starten Sie jetzt Ihre Testphase

Ihr Daten-Template für Purchase to Pay, Bestellanforderung

Ihr Daten-Template für Purchase to Pay, Bestellanforderung

Purchase to Pay - Requisition: Attribute

Purchase to Pay - Requisition: Aktivitäten

Anleitungen zur Extraktion

Direkte SQL-Abfrage auf der zugrunde liegenden SAP-ECC-Datenbank

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit SAP RFC zur Tabellenextraktion

Schritte

Konfiguration

a Beispielabfrage python

Bereit für den Start?

Steigern Sie die Effizienz Ihrer P2P-Bestellanforderungen, starten Sie jetzt Ihre Testphase

Ihre Privatsphäre ist uns wichtig