> Kontinuierliche Prozessverbesserung > Vom Bedarf bis zur Zahlung: Bestellanforderung > SAP ECC > Daten Template

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

SAP ECC

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Purchase-to-Pay-Bestellanforderungen(19) Aktivitäten für Purchase-to-Pay-Bestellanforderungen(13) Anleitungen zur Datenextraktion(2)

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

Dieses Template bietet eine umfassende Anleitung zur Erfassung der wichtigsten Daten für die Analyse Ihres Bestellanforderungsprozesses. Es beschreibt die erforderlichen Datenfelder, die zu erfassenden Aktivitäten und gibt praktische Hinweise zum Extrahieren der Informationen aus Ihrem Quellsystem. Mit dieser Anleitung bereiten Sie Ihre Daten für ein aussagekräftiges Process Mining vor.

Empfohlene Attribute für die Datenerfassung
Wichtige Aktivitäten für die Analyse
Anleitung zur Datenextraktion aus SAP ECC

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

Template herunterladen

Attribute für Purchase-to-Pay-Bestellanforderungen

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren Bestellanforderungsprozess umfassend zu analysieren.

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 bezeichnet einen bestimmten Schritt oder ein Ereignis im Lebenszyklus einer Bestellanforderung, etwa „Bestellanforderung erstellt“, „Genehmigung eingereicht“ oder „Bestellung erstellt“. Die Aktivitäten werden in der Regel aus Statusänderungen, Workflow-Protokollen oder Änderungsbelegen in SAP abgeleitet. Die Analyse der Abfolge und Häufigkeit von Aktivitäten bildet die Grundlage für Process Mining. Sie ermöglicht es, tatsächliche Prozessabläufe zu erkennen, einschließlich häufig genutzter Pfade, Abweichungen und Engpässe. Das ist entscheidend, um Dashboards wie die Prozessübersicht für Bestellanforderungen zu erstellen und KPIs zu Nachbearbeitungen und Compliance zu berechnen. Warum das wichtig ist Es legt die Prozessschritte fest und ermöglicht so die Visualisierung von Prozessmodellen sowie die Analyse unterschiedlicher Prozessabläufe. Woher beziehen Abgeleitet aus den Änderungsbelegtabellen CDHDR und CDPOS, Workflow-Protokollen oder Statusfeldern wie EBAN-STATU. Beispiele Bestellanforderung erstelltGenehmigungsschritt genehmigtBestellanforderung abgelehntBestellung erstellt
	Ereigniszeit EventTime	Der Timestamp gibt an, wann die Aktivität stattgefunden hat.
Beschreibung Die Ereigniszeit erfasst das genaue Datum und die Uhrzeit einer Aktivität. Dieser Timestamp ist die Grundlage für alle zeitbezogenen Analysen im Process Mining. Dazu gehören die Berechnung von Zykluszeiten, das Erkennen von Engpässen und die Bewertung der Prozessleistung. Bei Bestellanforderungen ermöglicht dieses Attribut die Berechnung wichtiger KPIs wie „Durchschnittliche Genehmigungszeit für Bestellanforderungen“ und „Zeit bis zur Erstellung der Bestellung“. Es liefert die Rohdaten für Dashboards, die Zeitspannen visualisieren, etwa für die Analyse der Genehmigungszykluszeit von Bestellanforderungen. So lässt sich die Zeit zwischen beliebigen Prozessschritten messen. Warum das wichtig ist Dieser Timestamp ist unverzichtbar, um Zeitspannen zu berechnen, die Prozessleistung zu analysieren und zeitbezogene Engpässe aufzudecken. Woher beziehen Zu finden in der Änderungsbeleg-Kopftabelle CDHDR (Felder 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 Anforderung von Waren oder Dienstleistungen in SAP ECC eindeutig kennzeichnet. Sie dient als zentrale Case-ID und verknüpft alle Aktivitäten und Änderungen zu einer bestimmten Bestellanforderung, von der Erstellung bis zum endgültigen Abschluss, etwa durch Umwandlung in eine Bestellung oder durch Schließung. Beim Process Mining ist diese ID unverzichtbar, um den durchgängigen Lebenszyklus jeder Bestellanforderung zu rekonstruieren. Anhand dieser Kennung können Analysten den vollständigen Prozessablauf visualisieren, die Dauer zwischen Meilensteinen messen und Unterschiede bei der Bearbeitung verschiedener Bestellanforderungen untersuchen. So lässt sich der gesamte Ablauf einer Bestellanforderung zusammenhängend betrachten. Warum das wichtig ist Diese zentrale Kennung verknüpft alle zugehörigen Prozessereignisse zu einem einzelnen Case und ermöglicht so die durchgängige Prozessanalyse. Woher beziehen Zu finden im Feld BANFN der Tabelle EBAN. 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. Bei jedem Datenladevorgang wird ein statischer Timestamp für den gesamten Datensatz gesetzt. Er dient als Bezugspunkt für die Aktualität der Analyse. Für jedes Process-Mining-Dashboard und jede Analyse ist es wichtig zu wissen, wie aktuell die Daten sind. Anhand dieses Attributs können alle Beteiligten erkennen, welchen Zeitraum die angezeigten Daten abdecken. So vermeiden sie Schlussfolgerungen auf Grundlage veralteter Informationen. Warum das wichtig ist Informiert Benutzer über die Aktualität der Daten, die für relevante und präzise Prozessanalysen entscheidend ist. Woher beziehen Dieser statische Wert gibt den Timestamp der Datenextraktion an und wird während des ETL-Prozesses hinzugefügt. Beispiele 2024-01-15T04:00:00Z2024-01-16T04:00:00Z
	Quellsystem SourceSystem	Gibt an, aus welchem System die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt die Herkunft der Prozessdaten an, zum Beispiel „SAP ECC Production“ oder „S4HANA QA“. In der Regel wird während der Datenextraktion ein statischer Wert hinzugefügt, der den Daten Kontext gibt, insbesondere wenn mehrere Quellsysteme im Einsatz sind. Bei der Prozessanalyse hilft diese Angabe, Daten aus verschiedenen Quellen voneinander zu unterscheiden. So werden Analysen nicht durch eine Vermischung von Produktions-, Test- und Entwicklungsdaten verfälscht. Als grundlegende Metainformation unterstützt sie außerdem die Data Governance und Rückverfolgbarkeit. Warum das wichtig ist Gibt wichtige Informationen zur Datenherkunft und ermöglicht Rückverfolgbarkeit sowie Analysen über mehrere Systeme hinweg. Woher beziehen Dieser statische Wert wird in der Regel während des ETL-Prozesses (Extraktion, Transformation und Laden) hinzugefügt. Beispiele SAP_ECC_PRODS4HANA_EU_100ECC_US_FINANCE
	Abteilung Department	Die Abteilung des Anforderers oder die der Bestellanforderung zugeordnete Kostenstelle.
Beschreibung Dieses Attribut bezeichnet die Geschäftseinheit oder Abteilung, von der die Bestellanforderung ausgeht. Die Angabe stammt häufig aus dem Benutzerprofil des Anforderers oder aus der Kostenstelle, die der Position der Bestellanforderung zugeordnet ist. Die Analyse nach Abteilungen ist wichtig, um Leistungsunterschiede innerhalb der Organisation zu verstehen. Sie bildet die zentrale Dimension für das Dashboard „Genehmigungszykluszeit von Bestellanforderungen“ und die KPI „Abweichung der Genehmigungszeit nach Abteilung“. Damit lässt sich feststellen, welche Abteilungen effizient arbeiten und wo Verbesserungen oder zusätzliche Ressourcen nötig sind. Warum das wichtig ist Ermöglicht den Leistungsvergleich zwischen Geschäftseinheiten und macht abteilungsspezifische Engpässe und Prozessabweichungen sichtbar. Woher beziehen Wird häufig ermittelt, indem der Anforderer (EBAN-AFNAM) mit den Benutzerstammdaten (SU01) verknüpft wird. Alternativ kann die Kostenstelle (EBKN-KOSTL) der Kontierungsdaten der Bestellanforderung verwendet werden. Beispiele FinanzenIT-BetriebMarketingFertigung
	Belegart RequisitionDocumentType	Eine Klassifizierung, die Art und Eigenschaften der Bestellanforderung festlegt.
Beschreibung Die Belegart in SAP steuert verschiedene Aspekte einer Bestellanforderung, darunter den Nummernkreis, die Feldauswahl und den zugehörigen Beschaffungsprozess. Beispiele sind „Standard-Bestellanforderung“, „Umlagerung“ und „Dienstleistungsanforderung“. Dieses Attribut eignet sich besonders für Analysen, da unterschiedliche Belegarten oft eigene Prozessabläufe und Genehmigungsanforderungen haben. Analysten können die Daten damit nach Belegart aufteilen und die Leistung verschiedener Prozesse für Bestellanforderungen vergleichen. Das ist wichtig, um die Compliance zu prüfen und Möglichkeiten zur Standardisierung oder Spezialisierung von Prozessen zu erkennen. Warum das wichtig ist Ermöglicht die Aufteilung von Bestellanforderungen nach Prozesskategorien und damit präzisere, aussagekräftigere Analysen. Woher beziehen Zu finden in Tabelle EBAN, Feld BSART. Beispiele NBUBRV
	Benutzername User	Die ID des Benutzers, der die Aktivität ausgeführt hat.
Beschreibung Dieses Attribut gibt an, welcher Benutzer für ein Ereignis verantwortlich war, etwa für das Anlegen einer Bestellanforderung, die Genehmigung eines Schritts oder die Änderung eines Dokuments. In SAP wird dafür häufig eine Benutzer-ID erfasst. Die Analyse nach Benutzern zeigt, wo Schulungsbedarf besteht, wie sich die Leistung einzelner Benutzer unterscheidet und wo Dateneingabefehler entstehen können. Das Attribut ist wichtig für Dashboards wie „Durchsatz bei der Erstellung von Bestellanforderungen nach Anforderer“. Außerdem hilft es, die Arbeitslast zu verteilen und die Einhaltung der Funktionstrennung zu prüfen. Warum das wichtig ist Ordnet Aktivitäten einzelnen Personen zu und ermöglicht Analysen zu Leistung, Arbeitslast, Compliance und Schulungsbedarf. Woher beziehen Zu finden in der Änderungsbeleg-Kopftabelle CDHDR (Feld USERNAME) für Änderungen und in EBAN (Feld ERNAM) für den Ersteller. Beispiele SMITHJR.DOEUSER123
	Gesamtwert der Bestellanforderung TotalRequisitionValue	Der Gesamtwert aller Positionen in der Bestellanforderung.
Beschreibung Dieses Attribut gibt den Gesamtbetrag der Bestellanforderung an. Der Wert bestimmt häufig, welcher Genehmigungsworkflow erforderlich ist. Bestellanforderungen mit höherem Wert werden in der Regel genauer geprüft und durchlaufen mehr Genehmigungsschritte. Die Analyse nach Wert zeigt, wie sich die finanziellen Auswirkungen auf den Prozess auswirken. Sie kann aufdecken, ob Bestellanforderungen mit hohem Wert länger auf eine Genehmigung warten, häufiger abgelehnt werden oder andere Prozesspfade durchlaufen. Außerdem ist der Wert eine wichtige Kennzahl für den finanziellen Durchsatz des Beschaffungsprozesses. Warum das wichtig ist Zeigt den Zusammenhang zwischen Prozessverhalten und finanziellen Auswirkungen. Das ist wichtig für die Risikoanalyse und die Bewertung der Komplexität von Genehmigungen. Woher beziehen Summe der Werte aller Positionen. Der Positionswert steht in Tabelle EBAN, Feld GSWER. Die Währung ist in EBAN-WAERS hinterlegt. 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, zum Beispiel „In Freigabe“, „Genehmigt“, „Abgelehnt“ oder „Abgeschlossen“. In SAP wird der Status häufig durch einen Statuscode dargestellt. Der Status zeigt, wie eine Bestellanforderung ausgegangen ist. Er unterstützt direkt das Dashboard „Ergebnisse und Ablehnungsquoten von Bestellanforderungen“ sowie KPIs wie „Ablehnungsquote von Bestellanforderungen“ und „Rücknahmequote von Bestellanforderungen“. Die Analyse der Statuswechsel hilft, ineffiziente Prozessschritte und Fehlerquellen zu erkennen. Warum das wichtig ist Der Status zeigt das Ergebnis einer Bestellanforderung und ist entscheidend für die Analyse von Erfolgsquoten, Ablehnungsgründen und Prozessenden. Woher beziehen Der Bearbeitungsstatus steht in Tabelle EBAN, Feld STATU. Der Freigabestatus ist in EBAN-FRGZU hinterlegt. Beispiele N (Nicht bearbeitet)B (Bestellung angelegt)A (Anfrage erstellt)K (Abgeschlossen)
	Ablehnungsgrund RejectionReason	Der angegebene Grund für die Ablehnung einer Bestellanforderung oder eines Genehmigungsschritts.
Beschreibung Dieses Attribut erfasst die Begründung für die Ablehnung einer Bestellanforderung. Genehmigende geben sie bei der Ablehnung meist als Freitext ein oder wählen einen Code aus einer vorgegebenen Liste aus. Die Analyse der Ablehnungsgründe ist wichtig für die Prozessverbesserung. Sie zeigt konkret, warum Bestellanforderungen scheitern, etwa wegen Richtlinienverstößen, fehlerhafter Daten oder fehlenden Budgets. Diese Daten sind wichtig für das Dashboard „Ergebnisse und Ablehnungsquoten von Bestellanforderungen“ und helfen, die Ursachen ineffizienter Prozesse zu ermitteln. Warum das wichtig ist Zeigt konkret, warum Bestellanforderungen abgelehnt werden, und ermöglicht gezielte Prozessverbesserungen und Schulungen. Woher beziehen Diese Daten sind in der Regel in Workflow-Protokollen oder als Langtext zum Ablehnungsereignis gespeichert. In EBAN gibt es dafür kein Standardfeld. Beispiele Falsche KostenstelleBudget überschrittenDoppelte AnforderungVerstoß gegen Richtlinien
	Bestellnummer PurchaseOrderId	Die ID der Bestellung, die aus der Bestellanforderung erstellt wurde.
Beschreibung Dieses Attribut verknüpft eine Bestellanforderung mit der anschließend zu ihrer Erfüllung erstellten Bestellung. Aus einer Bestellanforderung können mitunter mehrere Bestellungen entstehen. Die Verknüpfung ist wichtig, um die Übergabe vom Anforderungs- an den Beschaffungsprozess zu analysieren. Sie wird benötigt, um die KPI „Zeit von der Bestellanforderung bis zur Erstellung der Bestellung“ zu berechnen und das Dashboard „Verzögerung zwischen genehmigter Bestellanforderung und Bestellung“ zu unterstützen. Dieser Zusammenhang ist entscheidend, um die Effizienz des gesamten Beschaffungs- und Zahlungszyklus zu messen. Warum das wichtig ist Verknüpft den Prozess der Bestellanforderung mit dem nachgelagerten Beschaffungsprozess und ermöglicht die Analyse von Verzögerungen bei der Übergabe. Woher beziehen Die Bestellnummer wird nach der Erstellung in Tabelle EBAN, Feld EBELN, gespeichert. Beispiele 450001712345000171244500017125
	Einkäufergruppe PurchasingGroup	Die Gruppe der Einkäufer, die für die Beschaffung der angeforderten Positionen zuständig ist.
Beschreibung Die Einkäufergruppe ist eine Organisationseinheit, die für bestimmte Beschaffungsaktivitäten zuständig ist. Sie bezeichnet das Einkaufsteam, das die Bestellanforderung nach der Genehmigung bearbeitet. Dieses Attribut eignet sich, um Arbeitslast und Leistung verschiedener Einkaufsteams zu analysieren. Es zeigt, ob bestimmte Einkäufergruppen bei der Umwandlung von Bestellanforderungen in Bestellungen zum Engpass werden oder bestimmte Arten von Anforderungen effizienter bearbeiten. Damit ist es eine wichtige Dimension für die Ressourcen- und Leistungssteuerung im Einkauf. Warum das wichtig ist Ordnet die Beschaffungsverantwortung zu und ermöglicht den Vergleich von Arbeitslast und Leistung verschiedener Einkaufsteams. Woher beziehen Zu finden in Tabelle EBAN, Feld EKGRP. Beispiele 001002P01
	Ist Nacharbeit IsRework	Ein boolesches Kennzeichen dafür, ob die Bestellanforderung eine Nacharbeitsschleife durchlaufen hat, zum Beispiel eine Änderung nach der Einreichung.
Beschreibung Dieses abgeleitete Attribut kennzeichnet Aktivitäten oder Cases mit Nacharbeit. Eine Aktivität „Bestellanforderung geändert“ nach „Genehmigung eingereicht“ gilt beispielsweise als Nacharbeit. Auch Ablehnungsereignisse, die den Prozess zu einem früheren Schritt zurückführen, können das Kennzeichen auslösen. Das Kennzeichen ist wichtig für das Dashboard „Änderungen und Nacharbeitsanalyse bei Bestellanforderungen“. Damit lässt sich Nacharbeit einfach filtern und quantifizieren. So können Sie ihre Auswirkungen auf die Zykluszeiten messen und die Ursachen ineffizienter Prozesse ermitteln. Häufige Nacharbeit weist oft auf Probleme mit der Datenqualität oder unklare Anforderungen hin. Warum das wichtig ist Quantifiziert Häufigkeit und Auswirkungen von Nacharbeit und erleichtert es, ineffiziente Prozesse und Schleifen zu erkennen und zu analysieren. Woher beziehen Aus dem Event Log abgeleitet, indem bestimmte Aktivitätsfolgen erkannt werden, etwa „Bestellanforderung geändert“ nach einem Genehmigungsschritt. Beispiele truefalse
	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. Der Lieferant kann bereits eingetragen sein oder vom Anforderer vorgeschlagen werden. Die Analyse nach Lieferanten zeigt, wie sich die Vorauswahl von Lieferanten auf den Beschaffungsprozess auswirkt. Sie kann beispielsweise aufdecken, ob Bestellanforderungen mit festgelegtem Lieferanten schneller genehmigt werden oder ob bestimmte Lieferanten mit höheren Ablehnungsquoten verbunden sind. So wird die frühe Einbindung von Lieferanten sichtbar. Warum das wichtig ist Zeigt, wie sich bevorzugte Lieferantenbeziehungen auf Bearbeitungsdauer und Ergebnisse von Bestellanforderungen auswirken. Woher beziehen Zu finden in Tabelle EBAN, Feld LIFNR (fester Lieferant). Beispiele 100030025V9876
	Name des Anforderers RequesterName	Der Name der Person, die die Waren oder Dienstleistungen angefordert hat.
Beschreibung Dieses Attribut bezeichnet die Person, die die Bestellanforderung angelegt hat und den Bedarf an den angeforderten Positionen hat. Anhand des Anforderers lassen sich Muster bei Bestellanforderungen nach Person oder Gruppe analysieren. Das Dashboard „Durchsatz bei der Erstellung von Bestellanforderungen nach Anforderer“ verwendet dieses Attribut, um besonders aktive Benutzer, möglichen Schulungsbedarf und Abteilungen mit hohem Beschaffungsaufkommen zu erkennen. Es zeigt, von wem der Prozess ausgeht. Warum das wichtig ist Gibt an, wer den Prozess angestoßen hat. So lassen sich Muster bei der Erstellung von Bestellanforderungen analysieren und Schulungen gezielt planen. Woher beziehen Zu finden in Tabelle EBAN, Feld AFNAM. Beispiele Alice WilliamsBob JohnsonCharlie Brown
	Priorität Priority	Die Dringlichkeitsstufe der Bestellanforderung.
Beschreibung Dieses Attribut gibt die Priorität der Bestellanforderung an, häufig als „Dringend“, „Hoch“ oder „Normal“. Die Kennzeichnung weist Genehmigende und Einkäufer darauf hin, dass eine Anforderung bevorzugt bearbeitet werden soll. Das Attribut ist wichtig für das Dashboard „Bearbeitungsleistung dringender Bestellanforderungen“ und die KPI „Wirksamkeit der Dringlichkeitskennzeichnung“. Die Analyse zeigt, ob als dringend markierte Bestellanforderungen tatsächlich schneller bearbeitet werden als reguläre. So lässt sich prüfen, ob die Priorisierung funktioniert und geschäftskritische Anforderungen rechtzeitig erfüllt werden. Warum das wichtig ist Zeigt, ob dringende Anforderungen schneller bearbeitet werden, und hilft so, die Wirksamkeit der Priorisierung zu prüfen. Woher beziehen In EBAN gibt es dafür kein Standardfeld. Häufig wird die Angabe über ein benutzerdefiniertes Feld erfasst oder aus der Bedarfsverfolgungsnummer (EBAN-BEDNR) beziehungsweise einer bestimmten Belegart abgeleitet. Beispiele 123
	Warengruppe MaterialGroup	Die Gruppe oder Kategorie, zu der das angeforderte Material oder die Dienstleistung gehört.
Beschreibung Die Warengruppe fasst Materialien oder Dienstleistungen mit ähnlichen Eigenschaften zusammen. So lassen sich Beschaffungsaktivitäten nach Kategorie analysieren. Die Analyse nach Warengruppe unterstützt die strategische Beschaffung und Ausgabenanalyse. Im Process Mining zeigt sie beispielsweise, ob Bestellanforderungen für bestimmte Kategorien wie „IT-Hardware“ oder „Professionelle Dienstleistungen“ andere Prozesspfade durchlaufen oder länger auf eine Genehmigung warten. Diese Erkenntnisse sind für den „Datenqualitätsbericht zu Bestellanforderungen“ hilfreich und machen Prozessabweichungen je nach Beschaffungskategorie sichtbar. Warum das wichtig ist Ermöglicht die Ausgaben- und Prozessanalyse nach Beschaffungskategorie. Das unterstützt die strategische Beschaffung und zeigt kategoriespezifische Engpässe auf. Woher beziehen Zu finden in Tabelle EBAN, Feld MATKL. Beispiele 00101L001IT-SFTWR
	Werk Plant	Der Unternehmensstandort oder das Werk, für das die Waren oder Dienstleistungen angefordert werden.
Beschreibung Das Werk ist eine Organisationseinheit eines Unternehmens und bezeichnet einen physischen Standort, etwa 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 geografische Auswertungen und Vergleiche einzelner Standorte. Sie kann Leistungsunterschiede zwischen Standorten aufzeigen, die etwa auf abweichende lokale Verfahren, Personalstärken oder Geschäftsanforderungen zurückgehen. Diese Dimension wird häufig in regionalen Leistungs-Dashboards verwendet. Warum das wichtig ist Gibt der Analyse einen geografischen oder standortbezogenen Kontext und hilft, regionale Prozessabweichungen und Leistungsunterschiede zu erkennen. Woher beziehen Zu finden in Tabelle EBAN, Feld WERKS. Beispiele 10002100DE01

Erforderlich Empfohlen Optional

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

Erfassen Sie diese wichtigen Prozessschritte und Meilensteine in Ihrem Event Log, damit Sie Ihren Bestellanforderungs-Workflow zuverlässig entdecken und analysieren können.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Bestellanforderung abgelehnt	Diese abschließende Aktivität liegt vor, wenn die Bestellanforderung endgültig abgelehnt wurde und nicht weiterbearbeitet werden kann. Sie wird abgeleitet, wenn ein Genehmiger den Freigabeindikator in der Tabelle EBAN auf den endgültigen Ablehnungsstatus setzt.
Warum das wichtig ist Diese Aktivität ist ein wichtiger Endpunkt des Prozesses und entscheidend für die Berechnung der KPI zur Ablehnungsquote von Bestellanforderungen. Die Analyse dieser Fälle hilft, die Ursachen für gescheiterte Beschaffungsvorgänge und unnötigen Aufwand zu verstehen. Woher beziehen Abgeleitet aus dem Timestamp des Änderungsprotokolleintrags in CDPOS für die Tabelle EBAN und das Feld FRGZU, wenn dieses auf den Wert für die endgültige Ablehnung wechselt. Erfassung Abgeleitet, wenn das Feld für den endgültigen Freigabeindikator in EBAN den abschließenden Status „abgelehnt“ erreicht. Ereignistyp inferred
	Bestellanforderung erstellt	Diese Aktivität kennzeichnet die erstmalige Erstellung und Speicherung einer Bestellanforderung durch einen Benutzer. Das Ereignis wird ausdrücklich erfasst, wenn ein neuer Datensatz in der Tabelle EBAN angelegt und Datum und Uhrzeit der Erstellung gespeichert werden.
Warum das wichtig ist Als Ausgangspunkt des Prozesses ist diese Aktivität entscheidend, um die gesamte Laufzeit einer Bestellanforderung zu berechnen und die Erstellungsgeschwindigkeit zu analysieren. Sie zeigt, wer Bestellanforderungen erstellt und wann dies geschieht. Woher beziehen Dieses Ereignis wird für eine bestimmte ID der Bestellanforderung (BANFN) anhand der Felder für Erstellungsdatum (ERDAT) und Erstellungszeit (UZEIT) in der Tabelle EBAN erfasst. Erfassung Timestamp aus den Feldern ERDAT und UZEIT der Tabelle EBAN, wenn der Datensatz erstmals gespeichert wird. Ereignistyp explicit
	Bestellanforderung genehmigt	Dieser Meilenstein zeigt an, dass die Bestellanforderung alle erforderlichen Genehmigungsschritte erfolgreich durchlaufen hat. Er wird abgeleitet, wenn der letzte Freigabecode gesetzt und der Gesamtfreigabeindikator (FRGZU) in der Tabelle EBAN auf einen genehmigten Status gesetzt wird.
Warum das wichtig ist Dieser wichtige Meilenstein markiert das Ende des Genehmigungszyklus und den Beginn der Beschaffungsphase. Er ist entscheidend, um die KPI für die gesamte Genehmigungszeit zu berechnen und Verzögerungen bei der Übergabe zur Erstellung einer Bestellung zu messen. Woher beziehen Abgeleitet aus dem Timestamp des Änderungsprotokolleintrags in CDPOS für die Tabelle EBAN und das Feld FRGZU, wenn dieses auf den Wert für die endgültige Genehmigung wechselt. Erfassung Abgeleitet, wenn das Feld für den endgültigen Freigabeindikator in EBAN den abschließenden Status „genehmigt“ erreicht. Ereignistyp inferred
	Bestellanforderung zurückgezogen	Diese abschließende Aktivität liegt vor, wenn der Ersteller oder ein berechtigter Benutzer die Position der Bestellanforderung durch Setzen eines Löschkennzeichens storniert. Die Aktion wird ausdrücklich protokolliert und zeigt an, dass der Bedarf nicht mehr besteht oder die Anforderung versehentlich erstellt wurde.
Warum das wichtig ist Dies ist ein wichtiger Endpunkt für fehlgeschlagene Prozessfälle und entscheidend für die Berechnung der Rückzugsquote. Hohe Werte können darauf hindeuten, dass Benutzer wegen langer Genehmigungszeiten ihre Anträge aufgeben oder dass es grundlegende Probleme bei der Bedarfsplanung gibt. Woher beziehen Diese ausdrückliche Aktion wird erfasst, wenn das Feld „Löschkennzeichen“ (LOEKZ) in der Tabelle EBAN für die Position der Bestellanforderung gesetzt wird. Die Änderung wird in CDHDR und CDPOS protokolliert. Erfassung Änderungsprotokolleintrag, wenn das Löschkennzeichen (EBAN-LOEKZ) auf „L“ gesetzt wird. Ereignistyp explicit
	Bestellung erstellt	Diese Aktivität kennzeichnet die erfolgreiche Umwandlung einer genehmigten Bestellanforderung in ein Bestelldokument. Das Ereignis für die Bestellanforderung wird abgeleitet, indem eine zugehörige Bestellposition gesucht wird, die auf sie verweist.
Warum das wichtig ist Als wichtigstes erfolgreiches Ergebnis schließt diese Aktivität den Prozess der Bestellanforderung ab und leitet die Beschaffungsphase ein. Die Zeit zwischen „Bestellanforderung genehmigt“ und diesem Ereignis ist eine wichtige KPI zur Messung der Effizienz bei der Übergabe. Woher beziehen Abgeleitet, indem in der Tabelle EKPO (Bestellposition) ein Datensatz gesucht wird, dessen Felder BANFN und BNFPO mit der Nummer und Position der Bestellanforderung aus der Tabelle EBAN übereinstimmen. Das Erstellungsdatum der Bestellung (EKKO.AEDAT) liefert den Timestamp. Erfassung Abgeleitet durch Verknüpfung der Tabellen EBAN und EKPO und anhand des Erstellungsdatums der Bestellung aus EKKO. Ereignistyp inferred
	Genehmigung eingereicht	Diese Aktivität zeigt an, dass die Bestellanforderung in den formellen Genehmigungs-Workflow aufgenommen wurde. Sie wird in der Regel abgeleitet, wenn sich der Status der Bestellanforderung gemäß der konfigurierten Freigabestrategie so ändert, dass eine erste Freigabe oder Genehmigung erforderlich ist.
Warum das wichtig ist Damit beginnt die Genehmigungsdurchlaufzeit, eine wichtige KPI zur Messung der Prozesseffizienz. Dieser Zeitpunkt hilft, Verzögerungen zwischen der Erstellung und dem Beginn der formellen Genehmigung einzugrenzen. Woher beziehen Abgeleitet aus der ersten Statusänderung im Zusammenhang mit der Freigabestrategie in der Tabelle EBAN, zum Beispiel wenn das Feld FRGZU vom Anfangsstatus in einen ausstehenden Status wechselt, oder aus dem ersten Workflow-Protokolleintrag zur Bestellanforderung. Erfassung Abgeleitet aus dem ersten Änderungsprotokolleintrag, der die Aktivierung einer Freigabestrategie anzeigt. Ereignistyp inferred
	Bestellanforderung abgeschlossen	Bezeichnet den endgültigen Abschluss einer Position der Bestellanforderung. Es wird keine weitere Bearbeitung erwartet. Dieser Status wird abgeleitet, wenn die Position vollständig in eine Bestellung umgewandelt und erfüllt oder manuell als abgeschlossen gekennzeichnet wurde.
Warum das wichtig ist Damit wird ein eindeutiger Endpunkt für abgeschlossene Bestellanforderungen festgelegt, die nicht unbedingt gelöscht wurden. So lässt sich die Laufzeit erfolgreich erfüllter Anforderungen korrekt berechnen. Woher beziehen Abgeleitet aus dem Kennzeichen „Abgeschlossen“ (EBAKZ mit dem Wert „S“ oder einem anderen konfigurierten Wert) in der Tabelle EBAN. Das System setzt diesen Status häufig automatisch, wenn die Position vollständig in eine Bestellung umgewandelt und der Wareneingang gebucht wurde. Erfassung Abgeleitet aus einer Statusänderung des Feldes EBAN-EBAKZ auf einen Wert für „abgeschlossen“. Ereignistyp inferred
	Bestellanforderung geändert	Bezeichnet jede Änderung an einer Bestellanforderung nach ihrer erstmaligen Erstellung, etwa an Menge, Preis oder Material. SAP speichert diese Änderungen in den Änderungsprotokolltabellen. So entsteht ein detaillierter Prüfpfad aller Anpassungen.
Warum das wichtig ist Änderungen zu verfolgen ist wichtig, um Nachbearbeitungsschleifen und Probleme mit der Datenqualität zu erkennen. Häufige Änderungen können auf unklare Anforderungen bei der Erfassung oder Schulungsbedarf bei Benutzern hinweisen und den Prozess verzögern. Woher beziehen Erfasst in den Änderungsprotokolltabellen CDHDR (Kopf) und CDPOS (Position), wenn die Objektklasse EINKBELEG und die Objekt-ID die Nummer der Bestellanforderung ist. Änderungen an einzelnen Feldern lassen sich gezielt analysieren. Erfassung Ereignis im Änderungsprotokoll der Tabellen CDHDR und CDPOS für das Dokument der Bestellanforderung. Ereignistyp explicit
	Bestellanforderung gesperrt	Bezeichnet die ausdrückliche Sperrung einer Position in einer Bestellanforderung, durch die eine Umwandlung in eine Bestellung verhindert wird. Die Sperre wird über einen bestimmten Indikator an der Position der Bestellanforderung gesetzt.
Warum das wichtig ist Eine Sperre weist auf ein mögliches Problem oder eine vorübergehende Unterbrechung der Beschaffung hin. Durch die Erfassung solcher Ereignisse lassen sich Engpässe erkennen, bei denen genehmigte Bestellanforderungen nicht sofort weiterbearbeitet werden. Woher beziehen Erfasst, wenn sich das Feld „Sperrkennzeichen“ (EBAKZ) in der Tabelle EBAN ändert. Die Änderung wird in CDHDR und CDPOS protokolliert. Erfassung Ereignis in den Änderungsprotokolltabellen, wenn das Feld EBAN-EBAKZ gesetzt wird. Ereignistyp explicit
	Genehmigung zurückgesetzt	Zeigt an, dass der gesamte Genehmigungs-Workflow für die Bestellanforderung zurückgesetzt wurde, häufig aufgrund einer umfangreichen Änderung. Dies wird abgeleitet, wenn der Freigabestatus nach vorheriger Aktivierung gelöscht wird und der Genehmigungsprozess dadurch von vorn beginnen muss.
Warum das wichtig ist Das Zurücksetzen einer Genehmigung verursacht erhebliche Nachbearbeitung und wirkt sich stark auf die Durchlaufzeit aus. Werden solche Fälle erkannt, lassen sich Ineffizienzen und die Auswirkungen von Änderungen an Bestellanforderungen auf den Workflow nachvollziehen. Woher beziehen Abgeleitet aus den Änderungsprotokollen (CDHDR/CDPOS) zur Tabelle EBAN, wenn Freigabestatusfelder wie FRGZU von einem ausstehenden oder genehmigten Status in den Anfangsstatus oder einen leeren Status wechseln. Erfassung Abgeleitet aus Änderungsprotokollen, die zeigen, dass Felder der Freigabestrategie gelöscht wurden. Ereignistyp inferred
	Genehmigungsschritt abgelehnt	Ein berechtigter Benutzer hat einen einzelnen Schritt der Freigabestrategie ausdrücklich abgelehnt. In der Regel wird die Bestellanforderung zur Änderung an den Ersteller zurückgesendet. Die Aktion wird als Änderung des Freigabestatus der Bestellanforderung protokolliert.
Warum das wichtig ist Ablehnungen sind eine wesentliche Ursache für Nachbearbeitungen und Verzögerungen. Die Analyse ihrer Häufigkeit und Ursachen hilft, Missverständnisse bei Richtlinien, Probleme mit der Datenqualität oder ineffiziente Genehmigungsschritte zu erkennen. Woher beziehen Erfasst in den Änderungsprotokollen (CDHDR/CDPOS) zu den Freigabestatusfeldern der Tabelle EBAN. Eine Ablehnung über die Transaktion ME54N oder eine ähnliche Transaktion löst eine entsprechende Statusänderung aus. Erfassung Änderungsprotokolleintrag, der entsteht, wenn ein Genehmiger eine Ablehnung ausführt. Ereignistyp explicit
	Genehmigungsschritt genehmigt	Bezeichnet die ausdrückliche Genehmigung eines einzelnen Schritts der Freigabestrategie durch einen berechtigten Benutzer. Die Aktion wird als Änderung des Freigabestatus der Bestellanforderung erfasst und bringt sie der endgültigen Genehmigung näher.
Warum das wichtig ist Einzelne Genehmigungen zu verfolgen ist notwendig, um die Dauer jedes Schritts zu messen und die Leistung verschiedener Genehmiger zu analysieren. Das ist eine wichtige Grundlage, um die Einhaltung des Workflows zu beurteilen. Woher beziehen Erfasst in 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 den protokollierten Eintrag aus. Erfassung Änderungsprotokolleintrag, der entsteht, wenn ein Genehmiger eine Freigabetransaktion ausführt. Ereignistyp explicit
	Genehmigungsschritt gestartet	Zeigt an, dass die Bestellanforderung auf eine Aktion eines bestimmten Genehmigers oder einer Genehmigungsgruppe wartet, wie in der Freigabestrategie festgelegt. Das Ereignis wird abgeleitet, wenn der Status der Bestellanforderung anzeigt, dass ein bestimmter Freigabecode aussteht.
Warum das wichtig ist Mit dieser Aktivität lässt sich jeder einzelne Schritt der Genehmigungskette detailliert analysieren. So können Sie erkennen, welche Genehmiger oder Stufen die längsten Verzögerungen verursachen. Woher beziehen Abgeleitet aus der Abfolge von Änderungen an den Freigabestatusfeldern in der Tabelle EBAN. Jede Änderung in einen neuen ausstehenden Status kennzeichnet den Beginn eines weiteren Genehmigungsschritts. Erfassung Abgeleitet aus Statusänderungen, die anzeigen, dass ein neuer Freigabecode aktiv ist und auf Genehmigung wartet. Ereignistyp inferred

Anleitungen zur Datenextraktion

So extrahieren Sie Ihre Daten aus SAP ECC

Schritte

Datenbankzugriff einrichten: 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 und Port). Ein solcher Zugriff ist nicht standardmäßig vorgesehen und muss von Ihrem SAP-Basis- und Sicherheitsteam genehmigt werden.
SAP-Schema ermitteln: Stellen Sie mit einem gängigen SQL-Client wie DBeaver, Toad oder SQL Developer eine Verbindung zur Datenbank her. Ermitteln Sie das SAP-Schema, 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. Sie extrahiert alle erforderlichen Aktivitäten und Attribute, indem sie Stammdaten- und Änderungsbelegtabellen miteinander verknüpft.
Abfrageparameter festlegen: Suchen Sie in der Abfrage nach Platzhalterwerten und ersetzen Sie diese durch die Angaben für Ihr System und Ihre Geschäftsanforderungen. Zu den wichtigsten Platzhaltern gehören '{source_system_name}', '{start_date}', '{end_date}', '{company_codes}' und '{document_types}'.
Datenbankspezifische Syntax anpassen: Die Abfrage verwendet gängige SQL-Syntax. Funktionen zur Erstellung eines Timestamps wie TO_TIMESTAMP oder zur Zeichenfolgenverarbeitung müssen Sie möglicherweise geringfügig an Ihr Datenbanksystem anpassen, zum Beispiel Oracle, SQL Server, DB2 oder HANA.
Extraktion ausführen: Führen Sie die angepasste Abfrage in Ihrem SQL-Client aus. Bei großen Datenmengen empfiehlt es sich, die Abfrage außerhalb der Hauptnutzungszeiten auszuführen, um die Systemleistung nicht zu beeinträchtigen.
Ergebnisse prüfen: Prüfen Sie nach Abschluss kurz, ob die Ausgabe die erwarteten Spalten enthält, etwa PurchaseRequisitionId, ActivityName und EventTime, und ob Datensätze zu verschiedenen Aktivitäten ausgegeben werden.
Als CSV exportieren: Exportieren Sie das gesamte Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie UTF-8-Codierung, damit Sonderzeichen korrekt dargestellt werden.
Upload vorbereiten: Vergewissern Sie sich, dass die Spaltenüberschriften in der CSV-Datei exakt mit den in der SQL-Abfrage definierten Aliasnamen übereinstimmen. Die Datei sollte das Event Log übersichtlich in Tabellenform abbilden.
In ProcessMind hochladen: Laden Sie die fertige CSV-Datei in Ihr ProcessMind-Projekt hoch, um die Daten zu analysieren und zu visualisieren.

Konfiguration

Datenbankverbindung: Sie benötigen eine direkte Verbindung zur SAP-ECC-Datenbank. Dazu brauchen Sie den Hostnamen, Port, Datenbanknamen und passende Benutzerzugangsdaten.
SAP-Schema: Der Name des Schemas mit den SAP-Tabellen muss bekannt sein, zum Beispiel SAPSR3. Führen Sie die Abfrage im Kontext dieses Schemas aus.
Datumsbereich: Begrenzen Sie die Abfrage auf einen bestimmten Datumsbereich, um Leistung und Datenvolumen zu steuern. Wir empfehlen zunächst einen Zeitraum von 3 bis 6 Monaten. Geben Sie die Platzhalter '{start_date}' und '{end_date}' im Format YYYYMMDD an.
Organisationsfilter: Filtern Sie die Daten für eine gezieltere Analyse nach Buchungskreis (BUKRS) und Belegart der Bestellanforderung (BSART). Ersetzen Sie die Platzhalter '{company_codes}' und '{document_types}' durch kommagetrennte Wertelisten, zum Beispiel '1000','2000'.
Voraussetzungen: Für diese Methode benötigen Sie die Genehmigung des SAP-Basis- und Sicherheitsteams, um direkte Datenbankzugangsdaten zu erhalten. Sie ist nicht für die übliche Arbeit von Endbenutzern vorgesehen.
Leistungsaspekte: Die Abfrage verknüpft Änderungsbelegtabellen (CDHDR, CDPOS), die sehr groß sein können. Ohne geeignete Filter kann die Abfrage langsam sein und erhebliche Systemressourcen beanspruchen. Verwenden Sie stets einen begrenzten Datumsbereich und weitere Filter.

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 neuer installiert ist. Erstellen Sie einen Projektordner und richten Sie eine virtuelle Umgebung ein, um Abhängigkeiten zu verwalten. Installieren Sie die erforderlichen Bibliotheken mit pip: pip install pyrfc pandas numpy
SAP-RFC-SDK: Laden Sie das SAP NetWeaver RFC SDK im 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 SAP-Verbindungsparametern und ersetzen Sie die Platzhalterwerte (ashost, sysnr, client, user, passwd) durch die tatsächlichen Zugangsdaten Ihres SAP-Systems. Stellen Sie sicher, dass der Benutzer über die erforderlichen Berechtigungen für RFC-Aufrufe und den Tabellenzugriff verfügt.
Exportparameter festlegen: Legen Sie im Skript mit den Variablen date_from und date_to den gewünschten Zeitraum für den Datenexport fest. Es empfiehlt sich, zunächst einen kürzeren Zeitraum, zum Beispiel einen Monat, zu wählen und den Export zu testen.
Python-Skript ausführen: Starten Sie das Skript im Terminal mit dem Befehl python your_script_name.py. Das Skript stellt über RFC eine Verbindung zu SAP her, ruft für jede erforderliche Tabelle (EBAN, EKKO, EKPO, CDHDR, CDPOS) RFC_READ_TABLE auf und lädt die Daten herunter.
Daten abrufen: Das Skript ruft Rohdaten zu Bestellanforderungen, Bestellungen und Änderungsbelegen ab. Mithilfe von Filterkriterien wie Zeiträumen und Objektklassen begrenzt es die übertragene Datenmenge.
Daten lokal umwandeln: Nach dem Download verarbeitet das Skript die Daten lokal mit der Bibliothek pandas. Es wandelt die Rohdaten der Tabellen in separate Event-Log-Einträge für jede der 13 erforderlichen Aktivitäten um, zum Beispiel „Bestellanforderung erstellt“, „Genehmigungsschritt genehmigt“ und „Bestellung erstellt“.
Event Log erstellen: Das Skript führt die aus den einzelnen Tabellen erzeugten Ereignisse in einem einheitlichen DataFrame zusammen. Es berechnet die Ereigniszeitstempel, ordnet Benutzernamen zu und strukturiert die Daten im erforderlichen Format mit Case-ID, Aktivität und Zeitstempel.
Attribute zuordnen: Ordnen Sie wichtige Attribute wie PurchaseRequisitionId, ActivityName, EventTime, Benutzer und TotalRequisitionValue den entsprechenden Spalten im endgültigen DataFrame zu.
Als CSV exportieren: Das Skript speichert das fertige Event Log im selben Verzeichnis als CSV-Datei namens event_log_pr.csv. Diese Datei ist für den direkten Upload in ProcessMind formatiert.
Prüfen und hochladen: Öffnen Sie die erstellte CSV-Datei und prüfen Sie, ob die Daten vollständig und korrekt sind. Nach der Validierung können Sie die Datei in Ihr ProcessMind-Projekt hochladen.

Konfiguration

SAP-Verbindung: Das Skript benötigt die direkten RFC-Verbindungsdaten für das SAP-ECC-System, darunter Anwendungsserver, 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.
Datumsbereich: Die Extraktion richtet sich nach den im Skript festgelegten Start- und Enddaten. Für die ersten Ausführungen und zur Begrenzung des Aufwands empfiehlt sich ein Zeitraum von 3 bis 6 Monaten.
Tabellenfilter: Wo möglich, werden Filter direkt in den RFC-Aufrufen angewendet. Bestellanforderungen werden beispielsweise nach 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-Verbindung und pandas zur Datenverarbeitung. Installieren Sie beide Bibliotheken in Ihrer Python-Umgebung.
Leistung: Die Extraktion über RFC_READ_TABLE kann bei sehr großen Datenmengen langsam sein, da die Tabellen nacheinander ausgelesen werden. Führen Sie die Extraktion möglichst außerhalb der Hauptnutzungszeiten aus, um die Systemlast zu verringern.
Belegarten: Standardmäßig extrahiert das Skript alle Belegarten für Bestellanforderungen. Um den Umfang einzuschränken, können Sie nach der Extraktion den DataFrame anhand der Spalte BSART aus der Tabelle EBAN filtern.

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()

Möchten Sie starten?

Mit diesem Template strukturieren Sie Ihre Daten für Process Mining und gewinnen aussagekräftige Erkenntnisse zu Ihrem Bestellanforderungsprozess. Beginnen Sie noch heute mit der Optimierung Ihrer Prozesse.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Bestellanforderungen effizienter bearbeiten, starten Sie jetzt Ihre Testphase

Erkennen und beheben Sie Engpässe bei Bestellanforderungen und verkürzen Sie die Zykluszeit um mindestens 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich, 14 Tage kostenloser Zugang

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

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

Attribute für Purchase-to-Pay-Bestellanforderungen

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

Anleitungen zur Datenextraktion

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

Schritte

Konfiguration

Beispielabfrage sql

Python-Skript zur Tabellenextraktion über SAP RFC

Schritte

Konfiguration

Beispielabfrage python

Möchten Sie starten?

Bestellanforderungen effizienter bearbeiten, starten Sie jetzt Ihre Testphase