Ihr Daten-Template für Purchase to Pay, Bestellanforderungen
Ihr Daten-Template für Purchase to Pay, Bestellanforderungen
- Empfohlene Attribute für eine detaillierte Analyse
- Wichtige Aktivitäten für die Prozesserkennung
- Hinweise zur Datenextraktion aus SAP S/4HANA
Purchase to Pay, Attribute der Bestellanforderung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name der Geschäftsaktivität, die zu einem bestimmten Zeitpunkt im Requisitionsprozess stattgefunden hat. | ||
| Beschreibung Der Aktivitätsname beschreibt ein bestimmtes Ereignis oder eine Aufgabe im Lebenszyklus einer Purchase Requisition. Diese Aktivitäten werden aus Systemprotokollen wie Änderungsbelegen und Workflow-Historien abgeleitet und stellen wichtige Prozessmeilensteine dar, etwa „Requisition erstellt“, „Genehmigungsschritt gestartet“ oder „Bestellung erstellt“. Die Analyse dieser Aktivitäten ermöglicht die Visualisierung des Prozessflusses, die Erkennung von Engpässen und die Messung der in den einzelnen Phasen verbrachten Zeit. Das Verständnis der Abfolge und Häufigkeit von Aktivitäten wie „Requisition geändert“ oder „Requisition abgelehnt“ ist entscheidend, um Ineffizienzen und Verbesserungsmöglichkeiten zu erkennen. Warum das wichtig ist Es definiert die Prozessschritte, bildet das Rückgrat der Prozessübersicht und ermöglicht die Analyse von Prozessfluss, Varianten und Engpässen. Bezugsquelle Dies ist ein abgeleitetes Attribut, das typischerweise durch die Interpretation von Daten aus Änderungsbelegtabellen (CDHDR, CDPOS) und Workflow-Protokollen, etwa SWWLOGHIST, erstellt wird. Beispiele Requisition erstelltGenehmigungsschritt abgeschlossenRequisition genehmigtBestellung erstellt | |||
| Ereigniszeit EventTime | Das genaue Datum und die genaue Uhrzeit, zu denen eine bestimmte Aktivität stattgefunden hat. | ||
| Beschreibung Die Ereigniszeit ist der Timestamp, der erfasst, wann eine Aktivität stattgefunden hat. Diese Daten sind entscheidend für die chronologische Anordnung von Ereignissen innerhalb eines Cases und bilden die Grundlage für sämtliche Berechnungen von Dauer und Leistung im Process Mining. Beispielsweise bestimmt die Zeitdifferenz zwischen den Ereignissen „Requisition eingereicht“ und „Requisition genehmigt“ die Dauer des Genehmigungszyklus. Präzise Timestamps sind unerlässlich, um die Prozessleistung zu analysieren, Verzögerungen zu erkennen und die Einhaltung von Service-Level-Vereinbarungen zu überwachen. Dieses Attribut ermöglicht Dashboards, die Zykluszeiten visualisieren, blockierte Requisitionen verfolgen und die Leistung über verschiedene Zeiträume vergleichen. Warum das wichtig ist Dieser Timestamp ist unerlässlich, um Ereignisse zu ordnen, Zykluszeiten zu berechnen sowie Prozessleistung und Engpässe zu analysieren. Bezugsquelle Timestamps stammen typischerweise aus Änderungsbelegköpfen (CDHDR-UDATE, CDHDR-UTIME) oder Workflow-Ereignisprotokollen. Beispiele 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| ID der Purchase Requisition PurchaseRequisitionId | Die eindeutige Kennung eines Dokuments für eine Purchase Requisition. | ||
| Beschreibung Die ID der Purchase Requisition ist der Primärschlüssel, der jede Anforderung von Waren oder Dienstleistungen in SAP S/4HANA eindeutig identifiziert. Sie dient als zentrale Case-Kennung und verknüpft alle Aktivitäten und Änderungen einer bestimmten Requisition von ihrer Erstellung bis zu ihrem endgültigen Status, etwa Genehmigung, Ablehnung oder Umwandlung in eine Bestellung. Im Process Mining ist dieses Attribut grundlegend für die Rekonstruktion des durchgängigen Lebenszyklus jeder Requisition. Indem alle zugehörigen Ereignisse unter einer einzigen ID der Purchase Requisition gruppiert werden, können Analysten Zykluszeiten präzise messen, Statusänderungen verfolgen und die verschiedenen Pfade analysieren, die eine Requisition im Genehmigungsprozess durchlaufen kann. Warum das wichtig ist Dies ist die zentrale Case-Kennung, die alle zugehörigen Prozessschritte verbindet und eine vollständige, konsistente Sicht auf den Lebenszyklus der Requisition ermöglicht. Bezugsquelle Dieses Attribut ist die Nummer der Purchase Requisition aus der Tabelle EBAN, Feld BANFN. Beispiele 100178901001789110017892 | |||
| Abteilung Department | Die Abteilung oder Kostenstelle, der die Kosten der Requisition belastet werden. | ||
| Beschreibung Das Attribut Abteilung, in SAP häufig durch die Kostenstelle abgebildet, identifiziert die Geschäftseinheit, die für den angeforderten Einkauf verantwortlich ist. Es ist eine wichtige finanzielle und organisatorische Information, die auf Positionsebene der Requisition zugewiesen wird. Im Process Mining ist dieses Attribut für die Analyse der Abteilungsleistung entscheidend. Es ermöglicht Dashboards, die zentrale Kennzahlen wie Zykluszeit, Änderungsquote und Ablehnungsquote zwischen Abteilungen vergleichen. So lassen sich leistungsstarke Abteilungen erkennen, deren Vorgehensweisen übernommen werden können, ebenso wie Abteilungen mit zusätzlichem Schulungs- oder Prozessunterstützungsbedarf. Warum das wichtig ist Ermöglicht den Leistungsvergleich zwischen Geschäftseinheiten. Unterschiede bei Zykluszeiten oder Ablehnungsquoten machen Best Practices und Verbesserungsbereiche sichtbar. Bezugsquelle Dies ist die Kostenstelle, die typischerweise in der Kontierungsstammtabelle EBKN, Feld KOSTL, zu finden ist. Beispiele FIN-1001IT-2005MKT-3010 | |||
| Benutzer-ID UserId | Die Kennung des Benutzers, der die Requisition erstellt oder eine bestimmte Aktivität ausgeführt hat. | ||
| Beschreibung Die Benutzer-ID identifiziert den Mitarbeitenden oder Systembenutzer, der für ein bestimmtes Ereignis im Lebenszyklus der Requisition verantwortlich ist. Dies kann die Person sein, die die Requisition erstellt, die Führungskraft, die sie genehmigt, oder der Bearbeitende, der sie ändert. Bei automatisierten Schritten kann es sich um die ID eines System- oder Batch-Benutzers handeln. Die Analyse nach Benutzer-ID hilft, benutzerspezifisches Verhalten, die Verteilung der Arbeitslast und die Prozesseinhaltung zu verstehen. Sie ist wichtig, um Schulungsbedarf zu erkennen, besonders leistungsstarke Mitarbeitende zu identifizieren und Verantwortlichkeiten im Prozess sicherzustellen. In Verbindung mit Benutzerdaten unterstützt sie außerdem die Analyse der Abteilungsleistung. Warum das wichtig ist Ermöglicht die Analyse von Benutzerleistung, Arbeitslastverteilung und Prozesseinhaltung. Das Attribut ist entscheidend, um Schulungsbedarf und Ressourcenengpässe zu erkennen. Bezugsquelle Für den Ersteller in EBAN-ERNAM zu finden. Bei nachfolgenden Änderungen steht die Information in CDHDR-USERNAME, bei Genehmigungen in den Workflow-Protokollen. Beispiele JSMITHRROEWF-BATCH | |||
| ID des Genehmigenden ApproverId | Die Kennung des Benutzers, der einen Genehmigungs- oder Ablehnungsschritt ausgeführt hat. | ||
| Beschreibung Die ID des Genehmigenden identifiziert den Benutzer, der eine Genehmigungs- oder Ablehnungsaktivität abgeschlossen hat. Sie unterscheidet sich von der allgemeinen Benutzer-ID, da sie ausschließlich die Entscheidungsträger im Genehmigungs-Workflow erfasst. Diese Information ist für eine detaillierte Analyse des Genehmigungsprozesses unverzichtbar. Mit diesem Attribut können Sie das Genehmigungsverhalten analysieren, etwa Führungskräfte mit langen Genehmigungszeiten oder Personen, die Requisitionen häufig ablehnen. Es bildet eine wichtige Grundlage für Dashboards zu Zykluszeiten einzelner Genehmigungsschritte und zur Analyse von Workflow-Engpässen. So lassen sich bestimmte Personen oder Rollen identifizieren, die Verzögerungen verursachen können. Warum das wichtig ist Identifiziert den konkreten Entscheidungsträger in einem Genehmigungsschritt und ermöglicht eine detaillierte Analyse von Genehmigungszykluszeiten und Engpässen nach Person oder Rolle. Bezugsquelle Diese Information wird typischerweise aus Tabellen des SAP Business Workflow wie SWW_WI2OBJ und SWWLOGHIST extrahiert, die Work Items mit dem abschließenden Benutzer verknüpfen. Beispiele MJOHNSONCWILLIAMSLBLACK | |||
| Requisition-Typ RequisitionType | Ein Code zur Klassifizierung der Purchase Requisition, etwa für Standardpositionen, Dienstleistungen oder Investitionsausgaben. | ||
| Beschreibung Der Requisition-Typ, in SAP auch als Belegart bezeichnet, ist ein wichtiges Konfigurationsfeld zur Kategorisierung von Purchase Requisitions. Unterschiedliche Typen können verschiedene Genehmigungs-Workflows auslösen, abweichende Feldeinstellungen verwenden und unterschiedlichen Geschäftszwecken dienen, etwa Standardlagerartikeln, externen Dienstleistungen oder Anlagenkäufen. Durch die Analyse nach Requisition-Typ können Unternehmen nachvollziehen, wie unterschiedliche Anforderungen bearbeitet werden. So lassen sich Leistung, Zykluszeiten und Genehmigungspfade zwischen Kategorien vergleichen. Dadurch wird sichtbar, ob bestimmte Requisition-Typen effizienter oder weniger effizient sind, und Prozessverbesserungen können gezielt angepasst werden. Warum das wichtig ist Kategorisiert Requisitionen für vergleichende Analysen und hilft zu verstehen, ob unterschiedliche Anforderungstypen abweichende Prozessflüsse, Engpässe oder Zykluszeiten aufweisen. Bezugsquelle Dies ist das Feld für die Belegart in der Tabelle EBAN, Feld BSART. Beispiele NBFORV | |||
| Requisitionsbetrag RequisitionAmount | Der gesamte Geldwert der Purchase Requisition. | ||
| Beschreibung Der Requisitionsbetrag entspricht den geschätzten Gesamtkosten der angeforderten Waren oder Dienstleistungen. Dieser Wert beeinflusst häufig die Komplexität und Dauer des Genehmigungs-Workflows, da Requisitionen mit höherem Wert typischerweise mehr Genehmigungsebenen erfordern. Durch die Analyse dieses Attributs lässt sich der Prozess nach Wert segmentieren. So können Sie Fragen beantworten wie: „Werden Requisitionen mit hohem Wert langsamer genehmigt?“ oder „Welchen Wert haben Requisitionen, die häufig abgelehnt werden?“ Das Attribut ist eine wichtige Dimension, um die finanziellen Auswirkungen von Prozessineffizienzen zu verstehen. Warum das wichtig ist Hilft, den Prozess nach finanzieller Auswirkung zu segmentieren, die häufig mit Genehmigungskomplexität und Zykluszeit zusammenhängt. Das Attribut ist für eine wertbasierte Prozessanalyse wesentlich. Bezugsquelle Der Gesamtwert steht in der Tabelle EBAN, Feld GFWERT. Der Wert auf Positionsebene befindet sich in EBAN-PREIS. Beispiele 1500.0075000.50250.75 | |||
| Requisitionsstatus RequisitionStatus | Der aktuelle Bearbeitungs- oder Genehmigungsstatus der Purchase Requisition. | ||
| Beschreibung Der Requisitionsstatus zeigt den aktuellen Zustand der Requisition innerhalb ihres Lebenszyklus an. In SAP wird er häufig durch den Freigabeindikator dargestellt. Dieser zeigt, ob eine Requisition gesperrt, in Genehmigung, teilweise genehmigt oder vollständig genehmigt ist. Der Status ändert sich, während die Requisition den Workflow durchläuft. Die zeitliche Nachverfolgung des Status ist grundlegend für das Verständnis des Prozessflusses. Sie hilft zu erkennen, an welchen Stellen Requisitionen festhängen und wie lange. Die Analyse von Statusübergängen ermöglicht eine detaillierte Sicht auf den Genehmigungsprozess und seine Varianten. Warum das wichtig ist Zeigt den aktuellen Zustand einer Requisition an und ist entscheidend, um den Fortschritt zu verfolgen, Engpässe zu erkennen und den Prozessfluss zu analysieren. Bezugsquelle Der Freigabestatus wird häufig durch den Freigabeindikator bestimmt, der sich in der Tabelle EBAN, Feld FRGZU, befindet. Beispiele B1S | |||
| Ablehnungsgrund RejectionReason | Der bei der Ablehnung einer Bestellanforderung angegebene Grund. | ||
| Beschreibung Die Rejection Reason erklärt, warum ein Genehmiger eine Bestellanforderung abgelehnt hat. Mögliche Gründe sind eine Überschreitung des Budgets, fehlerhafte Angaben, ein Verstoß gegen Richtlinien oder eine Duplizierung einer anderen Anforderung. Diese Information liefert wichtigen Kontext für das Verständnis von Prozessfehlern. Die Analyse der Ablehnungsgründe hilft dabei, die Ursachen für Ineffizienzen und Nacharbeit zu identifizieren. Ist beispielsweise „Incorrect Cost Center“ ein häufiger Grund, deutet dies auf einen Bedarf an besserer Anwenderschulung oder zusätzlicher Systemvalidierung hin. Dieses Attribut bildet die Grundlage für das Dashboard „Requisition Rejection Analysis“ und ist für gezielte Prozessverbesserungen entscheidend. Warum das wichtig ist Liefert die Ursache für Prozessfehler und ermöglicht gezielte Verbesserungen, um Nacharbeit zu reduzieren und die First-Time-Right-Rate von Anforderungen zu erhöhen. Bezugsquelle Dies ist häufig kein Standardfeld. Die Information kann in Workflow-Container-Elementen, einem mit der Anforderung verknüpften Langtext oder in kundenspezifischen Feldern erfasst werden. Beispiele Budget überschrittenFalscher LieferantDoppelte Anforderung | |||
| Benötigt-am-Datum RequiredByDate | Das Datum, bis zu dem der Anforderer die angeforderten Waren oder Dienstleistungen benötigt. | ||
| Beschreibung Das Required By Date, in SAP als Delivery Date bezeichnet, gibt an, wann die Waren oder Dienstleistungen aus der Anforderungsposition benötigt werden. Dieses Datum wird vom Anforderer festgelegt und dient als Zieltermin für den gesamten Beschaffungsprozess. Dieses Attribut ist für die Berechnung des KPI „On-Time Requisition Completion Rate“ entscheidend. Durch den Vergleich des Required By Date mit dem Datum der endgültigen Genehmigung oder der Erstellung der Bestellung kann das Unternehmen messen, inwieweit es interne Service Levels und geschäftliche Anforderungen erfüllt. Die Analyse von Anforderungen, bei denen dieses Datum überschritten wird, kann systematische Verzögerungen im Beschaffungsprozess sichtbar machen. Warum das wichtig ist Legt den Zieltermin für den Abschluss einer Anforderung fest und ermöglicht die Messung pünktlicher Lieferung sowie der Einhaltung interner Service Levels. Bezugsquelle Dies ist das Delivery Date auf Positionsebene in der Tabelle EBAN, Feld LFDAT. Beispiele 2023-11-152023-12-012024-01-20 | |||
| Bestellnummer PurchaseOrderNumber | Die Nummer der Bestellung, die aus der Requisition erstellt wurde. | ||
| Beschreibung Die Bestellnummer ist die Kennung des offiziellen Einkaufsdokuments, das aus einer genehmigten Bedarfsmeldung erstellt wird. Die Erstellung einer Bestellung ist häufig das erfolgreiche Endergebnis einer Bedarfsmeldung. Sie zeigt, dass die Anfrage in eine formelle Bestellung bei einem Lieferanten überführt wurde. Dieses Attribut ist entscheidend für die Messung des KPIs zur Durchlaufzeit von der Bedarfsmeldung bis zur Bestellung sowie der gesamten Umwandlungsrate. Es verbindet den Bedarfsmeldungsprozess mit dem nachgelagerten Beschaffungsprozess und ermöglicht eine umfassendere End-to-End-Sicht auf den gesamten Purchase-to-Pay-Zyklus. Warum das wichtig ist Verknüpft die Bedarfsmeldung mit dem nachfolgenden Beschaffungsdokument und ermöglicht die Messung der Umwandlungsrate sowie der Durchlaufzeit von der Bedarfsmeldung bis zur Bestellung. Bezugsquelle Zu finden in der Tabelle EBAN, Feld EBELN, sobald aus der Position der Bedarfsmeldung eine Bestellung erstellt wurde. Beispiele 450001789045000178914500017892 | |||
| Dringlichkeitsstufe UrgencyLevel | Eine Klassifizierung der Dringlichkeit einer Anforderung, die ihre Bearbeitungspriorität beeinflussen kann. | ||
| Beschreibung Das Urgency Level gibt die Priorität der Bestellanforderung an. Obwohl dafür kein eigenes Standardfeld vorgesehen ist, verwenden manche Unternehmen Felder wie die Requirement Tracking Number, um diese Information zu erfassen. So können Anforderer kritische Bedarfe kennzeichnen, die eine beschleunigte Bearbeitung erfordern. Die Analyse der Auswirkungen der Dringlichkeit ist wichtig, um zu bewerten, ob der Prozess kritische Anforderungen wirksam priorisiert. Das Dashboard „Urgency Level Impact Analysis“ verwendet dieses Attribut, um Durchlaufzeiten und Genehmigungsraten dringender und standardmäßiger Anforderungen zu vergleichen. So lässt sich feststellen, ob die priorisierte Bearbeitung wie vorgesehen funktioniert. Warum das wichtig ist Ermöglicht die Analyse von Leistungsunterschieden bei Anforderungen mit hoher Priorität und hilft zu prüfen, ob dringende Vorgänge tatsächlich beschleunigt werden. Bezugsquelle Es gibt kein standardmäßiges Feld für die Dringlichkeit. Manche Unternehmen verwenden dafür die Requirement Tracking Number (EBAN-BEDAR). Alternativ kann ein kundenspezifisches Feld zum Einsatz kommen. Beispiele HochMittelNiedrig | |||
| Endzeit EndTime | Das genaue Datum und die genaue Uhrzeit, zu denen eine bestimmte Aktivität abgeschlossen wurde. | ||
| Beschreibung EndTime ist der Timestamp, der den Abschluss einer Aktivität erfasst. Viele systemgenerierte Events erfolgen unmittelbar, sodass StartTime und EndTime identisch sind. Bei manuellen Aufgaben wie Genehmigungen können Start und Ende dagegen auseinanderliegen. Dieser Timestamp markiert den Abschluss der Arbeit. Ein separates EndTime ermöglicht eine genauere Messung der aktiven Bearbeitungszeit im Vergleich zur Wartezeit. Zusammen mit StartTime wird es zur Berechnung der Kennzahl ProcessingTime verwendet. Diese Detailtiefe verbessert die Analyse der Ressourcennutzung und Effizienz manueller Aufgaben. Warum das wichtig ist Kennzeichnet den Abschluss einer Aktivität, ermöglicht die Berechnung der aktiven Bearbeitungszeit und liefert ein detaillierteres Bild der Aufgabendauer. Bezugsquelle Dieses Attribut wird aus Workflow-Logs abgeleitet, die sowohl die Erstellung eines Arbeitselements (StartTime) als auch dessen Abschluss (EndTime) erfassen können. Beispiele 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Ist automatisiert IsAutomated | Ein Kennzeichen dafür, ob eine Aktivität von einem Systembenutzer statt von einer Person ausgeführt wurde. | ||
| Beschreibung Das Attribut Is Automated ist ein boolesches Kennzeichen. Es ist wahr, wenn eine Aktivität von einem System- oder Batch-Benutzer ausgeführt wurde, beispielsweise „WF-BATCH“ bei Workflow-Aktionen. Dadurch lassen sich manuelle und automatisierte Prozessschritte unterscheiden. Dieses Attribut ist entscheidend, um den Automatisierungsgrad im Anforderungsprozess zu messen und den KPI „Automated Approval Rate“ zu berechnen. Durch die Filterung nach automatisierten oder manuellen Schritten können Analysten deren Effizienz vergleichen und weitere Automatisierungsmöglichkeiten identifizieren, um Bearbeitungszeiten und manuellen Aufwand zu reduzieren. Warum das wichtig ist Unterscheidet zwischen menschlichen und systemgesteuerten Aktivitäten. Das ist entscheidend, um Automatisierungsraten zu messen und Möglichkeiten zur Automatisierung manueller Aufgaben zu erkennen. Bezugsquelle Dies ist ein abgeleitetes Attribut. Üblicherweise basiert es auf einer Regel, die prüft, ob die User ID eines Events zu einer Liste bekannter System- oder Batch-Benutzer gehört. Beispiele truefalse | |||
| Ist Nacharbeit IsRework | Ein Kennzeichen dafür, ob eine Aktivität Nacharbeit darstellt, beispielsweise eine Änderung nach der Einreichung. | ||
| Beschreibung Is Rework ist ein berechnetes boolesches Kennzeichen. Es identifiziert Aktivitäten, die keinen zusätzlichen Wert schaffen oder wiederholt ausgeführt werden. Ein typisches Beispiel in diesem Prozess ist die Aktivität „Requisition Amended“, nachdem die Anforderung bereits zur Genehmigung eingereicht wurde und der Genehmigungsprozess deshalb neu gestartet werden muss. Dieses Attribut ist entscheidend, um den Umfang der Nacharbeit und ihre Auswirkungen auf die gesamte Durchlaufzeit zu quantifizieren. Das Dashboard „Requisition Amendment and Rework Rate“ verwendet dieses Kennzeichen, um Ineffizienzen im Prozess sichtbar zu machen. Die Reduzierung von Nacharbeit ist häufig ein zentrales Ziel von Prozessverbesserungen, da sie unmittelbar Zeit und Aufwand spart. Warum das wichtig ist Kennzeichnet Aktivitäten, die unnötigen Aufwand oder Wiederholungen darstellen. Dadurch lassen sich Nacharbeit und ihre Auswirkungen auf die Prozesseffizienz direkt messen. Bezugsquelle Dies ist ein berechnetes Attribut. Die Logik kennzeichnet üblicherweise jede Aktivität „Requisition Amended“, die nach der ersten Aktivität „Requisition Submitted For Approval“ auftritt, als Nacharbeit. Beispiele truefalse | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten dieses Datensatzes zuletzt aus dem Quellsystem aktualisiert wurden. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder Aktualisierung aus dem Quellsystem. Es ist ein wichtiger Metadatenbestandteil, um die Aktualität der analysierten Daten zu beurteilen. Analysten und Fachanwender können anhand dieses Timestamps erkennen, ob die Prozessdaten den aktuellen Stand der Abläufe abbilden. Für jede Prozessanalyse ist die Aktualität der Daten eine wesentliche Grundlage für fundierte Entscheidungen. Dieses Attribut hilft, Erwartungen der Benutzer zu steuern und sicherzustellen, dass Schlussfolgerungen auf Daten beruhen, die für die jeweilige Analyse ausreichend aktuell sind. Warum das wichtig ist Zeigt die Aktualität der Daten an. Diese ist entscheidend, damit Sie der Analyse vertrauen und rechtzeitig geschäftliche Entscheidungen treffen können. Bezugsquelle Dieser Timestamp wird während des ETL-Prozesses für Extraktion, Transformation und Laden erzeugt und hinzugefügt. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Name des Genehmigungsschritts ApprovalStepName | Der konkrete Name oder die Beschreibung eines Genehmigungsschritts im Workflow. | ||
| Beschreibung Der Approval Step Name beschreibt eine bestimmte Phase im Genehmigungs-Workflow in verständlicher Form, beispielsweise „Manager Approval“ oder „VP Finance Approval“. Damit ist die Information aussagekräftiger als bei einer generischen Aktivität wie „Approval Step Completed“. Dieses Attribut ist für die Dashboards „Approval Step Cycle Time“ und „Workflow Bottleneck Analysis“ entscheidend. Es ermöglicht eine detaillierte Betrachtung des Genehmigungsprozesses. Dadurch lässt sich genau feststellen, welche Genehmigungsstufen die größten Verzögerungen verursachen und an welchen Stellen sich Arbeit ansammelt. Diese Detailtiefe ist für gezielte Maßnahmen zur Optimierung der Genehmigungskette erforderlich. Warum das wichtig ist Liefert detaillierte Informationen zu den Genehmigungsstufen und ermöglicht die präzise Identifikation von Engpässen innerhalb des mehrstufigen Genehmigungs-Workflows. Bezugsquelle Diese Information wird aus der Beschreibung der Workflow-Aufgabe abgeleitet. Sie kann durch die Verknüpfung des Workflow-Logs mit Aufgabendefinitionstabellen wie T528T ermittelt werden. Beispiele Genehmigung durch den ManagerGenehmigung durch den DirektorGenehmigung durch den VP Finanzen | |||
| Quellsystem SourceSystem | Identifiziert die konkrete SAP-S/4HANA-Instanz, aus der die Daten extrahiert wurden. | ||
| Beschreibung Das Attribut Quellsystem bezeichnet das Ursprungssystem, in dem die Prozessdaten erzeugt wurden. In Unternehmen mit mehreren SAP-Instanzen, etwa getrennten Systemen für Entwicklung, Qualitätssicherung und Produktion oder separaten Systemen für verschiedene Regionen, ist dieses Feld für Data Governance und Kontext entscheidend. Es stellt sicher, dass Daten aus unterschiedlichen Quellen unterschieden werden können. Dadurch werden fehlerhafte Aggregationen vermieden und systemspezifische Analysen ermöglicht. Für die Pflege der Datenherkunft und die Nachvollziehbarkeit der Prozessdaten ist dieses Attribut erforderlich. Warum das wichtig ist Liefert wichtigen Kontext zur Datenherkunft und Data Governance, insbesondere in Systemlandschaften mit mehreren Systemen, und gewährleistet die Nachvollziehbarkeit der Daten. Bezugsquelle Dabei handelt es sich typischerweise um die SAP-System-ID (SID), die aus Systemvariablen oder Konfigurationstabellen abgerufen werden kann. Beispiele S4PECCS4H_PROD_01 | |||
| Währung Currency | Der Währungscode für den Requisitionsbetrag. | ||
| Beschreibung Dieses Attribut gibt an, in welcher Währung der Requisitionsbetrag ausgewiesen ist, etwa USD, EUR oder JPY. Es liefert den erforderlichen Kontext für das Attribut Requisitionsbetrag, insbesondere in multinationalen Unternehmen mit mehreren Währungen. Für eine korrekte Finanzanalyse und Berichterstattung muss die Währung berücksichtigt werden. Beim Aggregieren oder Vergleichen von Requisitionswerten sollten alle Beträge in eine gemeinsame Währung umgerechnet werden, damit aussagekräftige Ergebnisse entstehen. Dieses Attribut ist Voraussetzung für solche Umrechnungen. Warum das wichtig ist Liefert den erforderlichen Kontext für den Requisitionsbetrag und ermöglicht präzise Finanzanalysen und Vergleiche in Umgebungen mit mehreren Währungen. Bezugsquelle Dieses Feld befindet sich in der Tabelle EBAN, Feld WAERS. Beispiele USDEURGBP | |||
Purchase to Pay, Aktivitäten der Bestellanforderung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Bestellung erstellt | Zeigt an, dass eine Bestellung mit Bezug auf die Requisitionsposition erstellt wurde. Dieses ausdrückliche Systemereignis verknüpft die Requisition mit einem nachfolgenden Beschaffungsbeleg. | ||
| Warum das wichtig ist Dies ist ein wichtiger Meilenstein und ein erfolgreiches Ergebnis des Requisitionsprozesses. Die Zeit zwischen Genehmigung der Requisition und Erstellung der Bestellung ist ein zentraler KPI für die Messung der Beschaffungseffizienz. Bezugsquelle Wird ausdrücklich erfasst, sobald eine Bestellposition erstellt wird. Die Verknüpfung ist in der Tabelle EKPO (Bestellposition) gespeichert, die die Nummer der Quell-Requisition (BANFN) und die Positionsnummer (BNFPO) enthält. Erfassen Verknüpfen Sie die Tabelle EKPO über Requisitionsnummer und Position mit EBAN. Das Erstellungsdatum der Bestellposition kennzeichnet das Ereignis. Ereignistyp explicit | |||
| Genehmigungsschritt abgeschlossen | Tritt auf, wenn ein Genehmigender eine positive Entscheidung zu einer Requisition trifft und damit einen Schritt im mehrstufigen Genehmigungs-Workflow abschließt. Dies wird aus einer Änderung des Freigabestatus der Requisition abgeleitet. | ||
| Warum das wichtig ist Diese Aktivität ermöglicht eine detaillierte Analyse des Genehmigungs-Workflows, einschließlich der Dauer jedes einzelnen Schritts. So lassen sich effiziente Genehmigende ebenso erkennen wie Engpässe im Prozess. Bezugsquelle Abgeleitet aus Änderungsbelegen (CDHDR/CDPOS) für die Tabelle EBAN. Eine Änderung des Status eines Freigabecodes, etwa im Feld FRGZU, von „nicht freigegeben“ zu „freigegeben“ für einen bestimmten Code kennzeichnet dieses Ereignis. Erfassen Verfolgen Sie für jeden in der Strategie definierten Freigabecode Änderungen an den Freigabestatusfeldern in EBAN. Ereignistyp inferred | |||
| Requisition abgelehnt | Bezeichnet die endgültige Ablehnung der Purchase Requisition durch einen Genehmigenden, wodurch der Prozess angehalten wird. Erfasst wird dies durch eine Statusaktualisierung, die eine Ablehnung anzeigt. | ||
| Warum das wichtig ist Diese Aktivität ist ein kritischer Endpunkt des Fehlschlags. Die Analyse von Ablehnungshäufigkeit, Gründen und Prozessstellen hilft, Probleme bei Richtlinienkonformität, Budget oder Qualität der Anforderung zu erkennen. Bezugsquelle Abgeleitet aus einer Statusänderung in der Tabelle EBAN. Der Bearbeitungsstatus (PROCSTAT) oder ein Freigabeindikator wird auf einen Wert gesetzt, der ausdrücklich „Abgelehnt“ bedeutet. Erfassen Ermitteln Sie über Änderungsbelege den Timestamp, zu dem der Gesamtstatus in EBAN auf „Abgelehnt“ aktualisiert wird. Ereignistyp inferred | |||
| Requisition abgeschlossen | Zeigt an, dass die Requisitionsposition vollständig bearbeitet wurde und daraus keine weiteren Bestellungen erstellt werden können. Dieser Status wird typischerweise automatisch gesetzt, sobald die gesamte Menge bestellt wurde. | ||
| Warum das wichtig ist Diese Aktivität kennzeichnet den endgültigen, erfolgreichen Abschluss des Lebenszyklus der Requisitionsposition. Sie bestätigt, dass der Geschäftsbedarf vollständig in einen Beschaffungsauftrag überführt wurde. Bezugsquelle Abgeleitet aus der Tabelle EBAN. Das Ereignis tritt ein, wenn das Kennzeichen „Abgeschlossen“ (EBAKZ) gesetzt wird. Dies geschieht typischerweise, sobald die in Bestellungen georderte Menge der Requisitionsmenge entspricht. Erfassen Ermitteln Sie über Änderungsbelege das Ereignis, bei dem das Kennzeichen „Abgeschlossen“ (EBAKZ) in der Tabelle EBAN gesetzt wird. Ereignistyp inferred | |||
| Requisition erstellt | Kennzeichnet die erstmalige Erstellung des Dokuments für die Purchase Requisition im System. Das Ereignis wird ausdrücklich erfasst, sobald ein Benutzer eine neue Requisition erstmals speichert, einschließlich des Erstellungszeitpunkts. | ||
| Warum das wichtig ist Diese Aktivität bildet den zentralen Startpunkt für die Analyse des Lebenszyklus einer Requisition. Sie ist entscheidend, um die durchgängige Zykluszeit von der Erkennung des ursprünglichen Bedarfs bis zur endgültigen Genehmigung oder Umwandlung in eine Bestellung zu messen. Bezugsquelle Dieses ausdrückliche Ereignis wird aus der Tabelle EBAN erfasst. Verwendet werden die Felder für Erstellungsdatum (ERDAT) und Erstellungszeit (ERZEIT) der jeweiligen Purchase Requisition (BANFN). Erfassen Verwenden Sie für jede Requisition (BANFN) die Felder für den Erstellungszeitpunkt (ERDAT, ERZEIT) aus der Tabelle EBAN. Ereignistyp explicit | |||
| Requisition genehmigt | Kennzeichnet die endgültige und vollständige Genehmigung der Purchase Requisition. Damit kann sie in eine Bestellung umgewandelt werden. Dieser Meilenstein wird daraus abgeleitet, dass der Gesamtfreigabestatus den endgültig genehmigten Status erreicht. | ||
| Warum das wichtig ist Dies ist ein wichtiger Erfolgsmeilenstein und ein häufiger Endpunkt der Zykluszeitanalyse. Er zeigt, dass die Requisition alle Prüfungen bestanden hat und von der Beschaffung bearbeitet werden kann. Bezugsquelle Abgeleitet aus einer Statusänderung in der Tabelle EBAN, insbesondere wenn der Gesamtfreigabeindikator (FRGZU) oder der Bearbeitungsstatus (PROCSTAT) auf den endgültigen Wert „Genehmigt“ aktualisiert wird. Erfassen Ermitteln Sie den Timestamp, zu dem der letzte Freigabecode angewendet wird oder sich der Gesamtstatus der Requisition in „Genehmigt“ ändert. Ereignistyp inferred | |||
| Bezugsquelle zugewiesen | Bezeichnet die Aktion eines Einkäufers, einer genehmigten Requisitionsposition einen bestimmten Lieferanten, Vertrag oder Infosatz zuzuweisen. Dies ist ein wichtiger Schritt, um die Requisition für die Erstellung einer Bestellung vorzubereiten. | ||
| Warum das wichtig ist Diese Aktivität verbindet Genehmigung und Bestellung. Die Messung der Zeit bis zur Zuweisung einer Bezugsquelle zeigt Verzögerungen bei der Arbeitslast des Einkäufers und bei der Effizienz der Beschaffung. Bezugsquelle Abgeleitet aus einem Wert, der in bezugsquellenbezogene Felder der Tabelle EBAN eingetragen wird, etwa fester Lieferant (LIFNR), Infosatz (INFNR) oder Vertrag (KONNR). Erfassen Verfolgen Sie über Änderungsbelege, wann Felder wie LIFNR, INFNR oder KONNR in der Tabelle EBAN befüllt werden. Ereignistyp inferred | |||
| Genehmigung zurückgesetzt | Bezeichnet ein Ereignis, bei dem der gesamte Genehmigungs-Workflow zurückgesetzt wird, häufig aufgrund einer wesentlichen Änderung an der Requisition. Dadurch beginnt der Genehmigungsprozess erneut auf der ersten Ebene. | ||
| Warum das wichtig ist Diese Aktivität weist auf umfangreiche Nacharbeit hin, die die Zykluszeit erheblich verlängert. Die Ursachen für das Zurücksetzen von Genehmigungen zu ermitteln, ist entscheidend, um den Prozess zu vereinfachen und Verzögerungen zu reduzieren. Bezugsquelle Abgeleitet aus Änderungsbelegen (CDHDR/CDPOS) zur Tabelle EBAN. Das Ereignis wird erkannt, wenn Felder für den Freigabestatus, etwa FRGKZ oder FRGZU, gelöscht werden, nachdem sie teilweise oder vollständig gesetzt waren. Erfassen Suchen Sie in den Änderungsprotokollen nach einem Wechsel des Freigabestatus von „freigegeben“ zurück zu „nicht freigegeben“. Ereignistyp inferred | |||
| Genehmigungsschritt gestartet | Zeigt an, dass eine Requisition auf eine Aktion eines bestimmten Genehmigenden oder einer Genehmigungsgruppe wartet. Dies wird daraus abgeleitet, dass der Status der Requisition auf einen bestimmten ausstehenden Freigabecode hinweist. | ||
| Warum das wichtig ist Diese Aktivität ist entscheidend, um Engpässe in der Genehmigungskette zu lokalisieren. Die Analyse der Dauer dieses Status zeigt, bei welchen Requisitionen die Bearbeitung stockt und welche Genehmigende überlastet sind. Bezugsquelle Abgeleitet aus den Freigabestatusfeldern der Tabelle EBAN, etwa FRGZU, und der zugrunde liegenden Konfiguration der Freigabestrategie. Das Ereignis beginnt, sobald ein bestimmter Freigabecode als nächster zu bearbeitender Code feststeht. Erfassen Ermitteln Sie anhand von Workflow-Protokollen oder Statusfeldern, wann eine Requisition in einen Status eintritt, in dem die Genehmigung eines bestimmten Freigabecodes aussteht. Ereignistyp inferred | |||
| Requisition geändert | Tritt auf, wenn ein Benutzer nach der erstmaligen Erstellung ein wichtiges Feld der Requisition ändert, etwa Menge, Preis oder Material. Diese Aktion wird ausdrücklich im Änderungsbelegsystem von SAP protokolliert. | ||
| Warum das wichtig ist Die Nachverfolgung von Änderungen ist entscheidend, um Nacharbeitschleifen und deren Auswirkungen auf die Zykluszeit zu erkennen. Eine hohe Änderungsquote deutet auf Probleme mit der Datenqualität oder wechselnde Anforderungen hin. Beide Bereiche sind für Prozessverbesserungen besonders relevant. Bezugsquelle Wird für Änderungen an der Tabelle EBAN ausdrücklich in den SAP-Tabellen für Änderungsbelege (CDHDR und CDPOS) protokolliert. Jede Änderung an einem überwachten Feld erzeugt einen Eintrag. Erfassen Extrahieren Sie Änderungsereignisse aus CDHDR/CDPOS, bei denen die Objektklasse BANF für Purchase Requisitions verwendet wird. Ereignistyp explicit | |||
| Requisition zur Genehmigung eingereicht | Bezeichnet den Zeitpunkt, zu dem der Anfordernde die Requisition formell einreicht und damit den Genehmigungs-Workflow auslöst. Dies wird typischerweise daraus abgeleitet, dass die Freigabestrategie der Requisition festgelegt wird und sich der Status in „In Genehmigung“ ändert. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein startet die Messung der KPIs für die Dauer des Genehmigungszyklus. Die Analyse der Zeit zwischen Erstellung und Einreichung kann Verzögerungen in der Vorbereitungsphase der Requisition sichtbar machen. Bezugsquelle Abgeleitet aus Änderungsbelegen (CDHDR/CDPOS) für die Tabelle EBAN, insbesondere wenn Felder der Freigabestrategie, etwa FRGST, befüllt werden oder sich der Gesamtstatus (PROCSTAT) in einen Status „In Genehmigung“ ändert. Erfassen Ermitteln Sie den ersten Eintrag im Änderungsbeleg, der den Beginn des Genehmigungs-Workflows oder einen Statuswechsel zu „In Genehmigung“ anzeigt. Ereignistyp inferred | |||
| Requisition zurückgezogen | Tritt auf, wenn der ursprüngliche Anfordernde die Requisition löscht oder storniert, bevor sie vollständig bearbeitet wurde. Dies ist typischerweise eine ausdrückliche Aktion, durch die das Löschkennzeichen für die Requisitionsposition gesetzt wird. | ||
| Warum das wichtig ist Die Nachverfolgung zurückgezogener Requisitionen hilft, Schwankungen im Bedarf und Gründe für Stornierungen zu verstehen. Sie kennzeichnet einen Endstatus der Requisition und verhindert eine weitere Bearbeitung. Bezugsquelle Wird ausdrücklich erfasst, sobald das Löschkennzeichen (LOEKZ) in der Tabelle EBAN für eine Requisitionsposition gesetzt wird. Die Änderung wird in CDHDR/CDPOS protokolliert. Erfassen Ermitteln Sie das Ereignis, bei dem das Löschkennzeichen (LOEKZ) in der Tabelle EBAN auf „L“ gesetzt wird. Ereignistyp explicit | |||
Extraktionsanleitungen
Schritte
- Voraussetzungen: Stellen Sie sicher, dass Sie in SAP S/4HANA über einen Benutzer mit den erforderlichen Berechtigungen für den Zugriff auf die benötigten CDS-Views verfügen. Dazu gehören typischerweise Berechtigungen für Objekte wie S_TABU_NAM sowie der Zugriff auf Werkzeuge zur Datenanzeige.
- Zugriffsmethode auf das System bestimmen: Legen Sie fest, wie Sie eine Verbindung zur SAP-S/4HANA-Datenbank herstellen, um SQL-Abfragen auszuführen. Übliche Werkzeuge sind SAP HANA Studio, die Eclipse IDE mit ADT (ABAP Development Tools) oder SQL-Clients von Drittanbietern wie DBeaver, die über den SAP-HANA-Datenbank-Client eine Verbindung herstellen können.
- SQL-Abfrage prüfen: Machen Sie sich mit dem bereitgestellten SQL-Skript vertraut. Es verwendet Common Table Expressions (CTEs), um Daten für verschiedene Aktivitäten zu erfassen und anschließend zu einem einheitlichen Event Log zusammenzuführen.
- Platzhalter anpassen: Suchen Sie die Platzhalter in der Abfrage und ersetzen Sie sie. Legen Sie den Datumsbereich im Format
[YYYY-MM-DD]für den Extraktionszeitraum fest und geben Sie die relevanten Buchungskreise ([Your Company Code]) Ihres Unternehmens an. - Abfrage ausführen: Führen Sie die vollständige, angepasste SQL-Abfrage gegen die SAP-S/4HANA-Datenbank aus. Abhängig vom Datenvolumen und dem gewählten Datumsbereich kann die Ausführung einige Zeit dauern.
- Erste Datenprüfung: Prüfen Sie nach Abschluss der Abfrage die ersten Zeilen der Ausgabe. Kontrollieren Sie, ob alle Spalten wie PurchaseRequisitionId, ActivityName und EventTime erwartungsgemäß befüllt sind und die Datenformate stimmen.
- Datentransformation berücksichtigen: Die bereitgestellte Abfrage gibt die Daten bereits in einem für Process Mining geeigneten Format aus. Die Funktionen
CASTundCONCATsorgen für konsistente Datentypen. Nach der Ausführung sollte keine wesentliche weitere Transformation erforderlich sein. - Event Log exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Stellen Sie sicher, dass die Dateikodierung auf UTF-8 gesetzt ist, um Zeichenfehler zu vermeiden.
- Upload vorbereiten: Prüfen Sie vor dem Upload in ein Process-Mining-Tool, ob die CSV-Datei die richtigen Spaltenüberschriften (
PurchaseRequisitionId,ActivityName,EventTimeusw.) enthält und das Datums- und Zeitformat vonEventTimekonsistent ist und von der Zielplattform unterstützt wird. - Upload in ProcessMind: Laden Sie die fertige CSV-Datei in Ihr ProcessMind-Projekt hoch. Konfigurieren Sie das Projekt, indem Sie
PurchaseRequisitionIdals Case ID,ActivityNameals Activity undEventTimeals Timestamp zuordnen.
Konfiguration
- Zentrale CDS-Views: Die Extraktion verwendet hauptsächlich
I_PurchaseRequisitionAPI01für die Kerndaten der Bestellanforderungen,I_ChangeDocumentundI_ChangeDocumentItemzur Nachverfolgung von Änderungen und Statusaktualisierungen sowieI_PurchaseOrderItemAPI01zur Verknüpfung mit Bestellungen. - Berechtigungen: Der ausführende Benutzer benötigt Lesezugriff auf die genannten CDS-Views. Wenden Sie sich an Ihr SAP-Sicherheitsteam, um die erforderlichen Rollen und Berechtigungen zu klären.
- Filterung nach Datumsbereich: Es ist entscheidend, den Erstellungszeitpunkt der Bestellanforderung (
CreationDate) durch einen Datumsfilter einzugrenzen, um das Datenvolumen zu begrenzen. Für eine erste Analyse empfiehlt sich ein Zeitraum von drei bis sechs Monaten. - Organisatorische Filterung: Filtern Sie die Daten nach
CompanyCode, damit Sie den Prozess für die richtige Geschäftseinheit analysieren. Zusätzlich können Sie nachPurchaseRequisitionTypefiltern, um bestimmte Beschaffungsprozesse zu untersuchen, beispielsweise Standardwaren im Vergleich zu Dienstleistungen. - Konfiguration der Änderungsbelege: Die Erfassung von Aktivitäten wie „Requisition Amended“ und verschiedenen Genehmigungsschritten setzt voraus, dass die Änderungsbelegprotokollierung für die relevanten Felder in Ihrem SAP-System aktiv ist. Fehlen diese Events, prüfen Sie die Systemkonfiguration für die Tabelle EBAN.
- Performance: In sehr großen Systemen mit Millionen von Bestellanforderungen kann eine Abfrage über einen langen Zeitraum die Systemleistung beeinträchtigen. Führen Sie die Abfrage möglichst außerhalb der Spitzenzeiten oder in einer Nicht-Produktionsumgebung mit kürzlich aktualisierten Daten aus.
a Beispielabfrage sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' Schritte
- Bestätigen Sie, dass direkter Lesezugriff auf das SAP-HANA-Schema mit EBAN und EBKN verfügbar ist. Identifizieren Sie außerdem die Änderungsbeleg- und Einkaufsbelegobjekte, die Ihr System für Änderungen an Bestellanforderungen, Freigabeverarbeitung, Bezugsquellenzuordnung, Bestellreferenzen und den Abschluss verwendet. Da diese Objekte und Felder je nach Release und Konfiguration variieren können, ersetzen Sie jeden Platzhalter in eckigen Klammern durch das entsprechende Objekt oder Feld Ihres Systems.
- Verwenden Sie in SAP GUI die Transaktion SE16H oder ein freigegebenes Datenbankadministrationswerkzeug, um EBAN und EBKN zu prüfen. Verifizieren Sie die Schlüsselfelder der Bestellanforderung und bestätigen Sie die verfügbaren Felder für Datum, Uhrzeit, Benutzer, Status, Löschung, Freigabe, Kontierung und Einkaufsbelegreferenz. Prüfen Sie die Felddefinitionen mit SE11 oder dem SAP Data Dictionary. Legen Sie bei Tests keine Produktionsdaten offen.
- Identifizieren Sie die konfigurierte Änderungsbelegquelle für Änderungen an Bestellanforderungen und Genehmigungsänderungen. Die Abfrage erwartet eine normalisierte Änderungsquelle mit dem Namen [Your requisition change document source]. Sie muss Felder für Bestellanforderungsnummer, Positionsnummer, geändertes Feld, alten Wert, neuen Wert, Änderungsdatum, Änderungszeit und Benutzer enthalten. Ordnen Sie diese Quelle vor der Ausführung den relevanten SAP-Änderungsbelegtabellen oder der entsprechenden CDS-View Ihres Systems zu.
- Identifizieren Sie die konfigurierte Workflow- oder Freigabequelle für Einreichung, Zurücksetzen der Genehmigung, Start und Abschluss von Genehmigungsschritten, endgültige Genehmigung und Ablehnung. Die Abfrage erwartet [Your requisition approval event source] mit einer Zeile pro Status- oder Freigabeübergang sowie Feldern für Bestellanforderungsnummer, Positionsnummer, Event-Typ, Freigabecode oder Genehmigungsgruppe, Genehmiger, Event-Datum, Event-Zeit und Status. Ordnen Sie diese Quelle der in Ihrer S/4HANA-Konfiguration verwendeten Freigabe- oder Workflow-Persistenz zu.
- Identifizieren Sie die Quellen für Bezugsquellenzuordnung, Bestellreferenz und Abschluss. Die Abfrage erwartet [Your requisition source assignment source], [Your requisition purchase order reference source] und [Your requisition closure source]. Ordnen Sie diese Platzhalter freigegebenen Tabellen oder Views Ihres Systems zu. Die Erstellung einer Bestellung muss durch eine explizite Referenz von der Bestellposition zur Position der Bestellanforderung dargestellt werden und darf nicht aus einer nicht verbundenen Einkaufsaktivität abgeleitet werden.
- Legen Sie das Extraktionsfenster mit [Start date] und [End date] fest. Für die erste Ausführung empfiehlt sich ein Zeitraum von drei bis sechs Monaten. Verwenden Sie erst dann einen längeren Zeitraum, wenn Sie Datenbankleistung und Event-Volumen geprüft haben. Die Abfrage filtert Erstellungs- und Event-Daten und verwendet die Kennung der Bestellanforderung weiterhin als Case ID.
- Führen Sie die Abfrage in einem freigegebenen SQL-Client aus, der mit SAP HANA verbunden ist. Ersetzen Sie nur Verbindungsdaten außerhalb der Abfrage, Datumsparameter, unternehmensspezifische Filter sowie die ausdrücklich dokumentierten Platzhalter für Quellen und Felder. Behalten Sie die Ausgabespalten exakt als PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount und RequisitionStatus bei.
- Prüfen Sie doppelte Events, Timestamp-Genauigkeit, Zeitzonenverarbeitung sowie die Granularität auf Positions- und Belegebene. Die Abfrage erzeugt Case IDs auf Belegebene und berücksichtigt den Positionskontext intern. Wenn mehrere Positionen dieselbe Aktivität und denselben Timestamp erzeugen, behalten Sie die einzelnen Zeilen bei, sofern Ihr ProcessMind-Design nicht ausdrücklich eine Deduplizierung vorsieht.
- Validieren Sie, dass jede erforderliche Aktivität als ActivityName-Wert vorhanden ist, EventTime befüllt und chronologisch plausibel ist und die erforderliche Case ID nicht null ist. Stimmen Sie die Mengen für denselben Datumsbereich mit SAP-Berichten oder freigegebenen operativen Extrakten ab.
- Exportieren Sie das Ergebnis als UTF-8-CSV oder in einem anderen von ProcessMind unterstützten Tabellenformat. Fügen Sie eine Kopfzeile ein, behalten Sie ISO-kompatible Timestamps bei, stellen Sie Nullwerte als leere Werte dar und laden Sie die Datei mit PurchaseRequisitionId als Case ID, ActivityName als Activity-Spalte und EventTime als Timestamp-Spalte hoch.
Konfiguration
- Case ID: Verwenden Sie die Belegnummer der Bestellanforderung aus EBAN, dargestellt als PurchaseRequisitionId. Wenn der Prozess auf Positionsebene konfiguriert ist, verwenden Sie stattdessen einen dokumentierten zusammengesetzten Schlüssel, beispielsweise aus Bestellanforderungsnummer und Positionsnummer, und wenden Sie denselben Schlüssel auf jedes Event an.
- Primärquelle: EBAN enthält die Positionsdaten der Bestellanforderung. EBKN dient zur Anreicherung um Kontierung sowie Abteilung oder Kostenstelle. Bestätigen Sie die exakten Feldnamen und Datentypen vor der Ausführung im SAP Data Dictionary.
- Event-Quellen: Die Abfrage verwendet bewusst professionelle Platzhalter für Änderungs-, Genehmigungs-, Bezugsquellen-, Bestellreferenz- und Abschlussquellen, da diese Quellen vom S/4HANA-Release, dem Workflow-Design, dem Freigabeverfahren, aktivierten Business Functions und kundenspezifischen Erweiterungen abhängen.
- Datumsbereich: Beginnen Sie mit drei bis sechs Monaten. Verwenden Sie, sofern verfügbar, einen begrenzten Bereich auf indizierten oder partitionierten Datumsfeldern. Bei inkrementellen Ladevorgängen sollten sich Extraktionsfenster ausreichend überschneiden, damit verspätet eintreffende Änderungen erfasst werden. Deduplizieren Sie anschließend anhand von Case, Activity, Timestamp, Position und Quell-Event-Schlüssel.
- Geschäftsfilter: Konfigurieren Sie [Company code filter], [Document type filter], [Purchasing group filter] und [Plant filter] nur, wenn diese Felder verfügbar sind und ihre fachliche Bedeutung bestätigt wurde. Vermeiden Sie eine Filterung nach Status, wenn der vollständige Lebenszyklus erfasst werden soll.
- Statuszuordnung: Konfigurieren Sie die Werte für In Approval, final approved, rejected, reset, pending release code und closed entsprechend der Freigabestrategie oder Workflow-Konfiguration des Zielsystems. Gehen Sie nicht davon aus, dass ein Statuscode in allen SAP-Mandanten dieselbe Bedeutung hat.
- Zuordnung von Änderungen: Berücksichtigen Sie Änderungen an Menge, Preis, Material, Lieferdatum, Kontierung und weiteren Feldern, die Ihr Prozess als Schlüsselfelder definiert. Die Abfrage enthält explizite Bedingungen für die genannten Schlüsselfelder und setzt voraus, dass die Quelle den Namen des geänderten Feldes bereitstellt.
- Verarbeitung von Timestamps: Kombinieren Sie Event-Datum und Event-Zeit in der Datenbankzeitzone und dokumentieren Sie anschließend jede Umrechnung in UTC. Wenn eine Quelle nur ein Datum speichert, verwenden Sie Mitternacht nur dann, wenn kein genauerer Timestamp verfügbar ist, und dokumentieren Sie diese Einschränkung.
- Performance: Begrenzen Sie die erste Extraktion nach Datum und Geschäftsbereich, wählen Sie nur erforderliche Spalten aus, vermeiden Sie uneingeschränkte Joins mit umfangreichen Änderungs- oder Workflow-Historien und prüfen Sie den HANA-Ausführungsplan. Wenn wiederholte Extraktionen erforderlich sind, materialisieren oder speichern Sie normalisierte Event-Quellen zwischen.
- Berechtigungen und Voraussetzungen: Beschaffen Sie Leseberechtigungen für EBAN, EBKN, die konfigurierten Änderungs- und Workflow-Quellen, Daten zur Bezugsquellenzuordnung, Bestellreferenzdaten und Abschlussdaten. Bestätigen Sie, dass der direkte Datenbankzugriff genehmigt ist, die relevanten Einkaufs- und Workflow-Funktionen aktiv sind und alle erforderlichen SAP-HANA-Datenbanklizenzen oder Administrationswerkzeuge verfügbar sind.
- Sicherheit: Setzen Sie das Prinzip der geringsten Berechtigung um, schützen Sie Kennungen von Benutzern und Genehmigern und befolgen Sie die organisatorischen Vorgaben für die Extraktion von Einkaufs- und Finanzinformationen.
a Beispielabfrage sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; Möchten Sie jetzt starten?
Verwenden Sie dieses Template, um Ihre Daten sicher vorzubereiten und das volle Potenzial von Process Mining für Ihren Purchase-to-Pay-Prozess für Bestellanforderungen auszuschöpfen. Beginnen Sie noch heute mit der Optimierung Ihrer Effizienz.
Beenden Sie Verzögerungen bei P2P-Bestellanforderungen: Optimieren Sie jetzt Ihren Workflow.
Gestalten Sie Prozesse effizienter, verkürzen Sie Durchlaufzeiten und reduzieren Sie die Zykluszeit um 30 %.
Keine Kreditkarte erforderlich, Einrichtung in 5 Minuten.