Ihr Daten-Template für den Purchase-to-Pay-Prozess mit Bestellanforderungen
Ihr Daten-Template für den Purchase-to-Pay-Prozess mit Bestellanforderungen
- Empfohlene Attribute für detaillierte Analysen
- Wichtige Aktivitäten für die Prozesserkennung
- Anleitung zur Datenextraktion aus SAP S/4HANA
Attribute für den Purchase-to-Pay-Prozess mit Bestellanforderungen
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name der geschäftlichen Aktivität, die zu einem bestimmten Zeitpunkt im Prozess der Bestellanforderung stattgefunden hat. | ||
| Beschreibung Der Aktivitätsname bezeichnet ein bestimmtes Ereignis oder eine Aufgabe im Lebenszyklus einer Bestellanforderung. Die Aktivitäten werden aus Systemprotokollen abgeleitet, etwa aus Änderungsbelegen und Workflow-Verläufen. Sie kennzeichnen wichtige Prozessmeilensteine wie „Bestellanforderung angelegt“, „Genehmigungsschritt gestartet“ oder „Bestellung angelegt“. Durch die Analyse dieser Aktivitäten lässt sich der Prozessfluss visualisieren, Engpässe lassen sich erkennen und die Dauer einzelner Phasen messen. Die Reihenfolge und Häufigkeit von Aktivitäten wie „Bestellanforderung geändert“ oder „Bestellanforderung abgelehnt“ zu verstehen, ist entscheidend, um Ineffizienzen und Verbesserungspotenziale zu erkennen. Warum das wichtig ist Dieses Attribut definiert die Prozessschritte. Es bildet die Grundlage der Prozesslandkarte und ermöglicht die Analyse von Prozessfluss, Varianten und Engpässen. Woher beziehen Dieses abgeleitete Attribut wird üblicherweise durch die Auswertung von Daten aus Änderungsbelegt Tabellen (CDHDR, CDPOS) und Workflow-Protokollen (z. B. SWWLOGHIST) erstellt. Beispiele Bestellanforderung angelegtGenehmigungsschritt abgeschlossenBestellanforderung genehmigtBestellung angelegt | |||
| Ereigniszeit EventTime | Das genaue Datum und die Uhrzeit, zu denen eine bestimmte Aktivität stattgefunden hat. | ||
| Beschreibung Die Ereigniszeit ist der Timestamp, der festhält, wann eine Aktivität stattgefunden hat. Diese Daten sind entscheidend, um Ereignisse innerhalb eines Case chronologisch zu ordnen. Sie bilden die Grundlage für alle Berechnungen von Dauer und Leistung im Process Mining. So ergibt sich die Zykluszeit für die Genehmigung aus der Zeit zwischen den Ereignissen „Bestellanforderung eingereicht“ und „Bestellanforderung genehmigt“. Genaue Timestamps sind unverzichtbar, um die Prozessleistung zu analysieren, Verzögerungen zu erkennen und die Einhaltung von Service-Level-Vereinbarungen zu überwachen. Mit diesem Attribut lassen sich Dashboards erstellen, die Zykluszeiten visualisieren, unbearbeitete Bestellanforderungen nachverfolgen und die Leistung über verschiedene Zeiträume vergleichen. Warum das wichtig ist Dieser Timestamp ist entscheidend, um Ereignisse zu ordnen, Zykluszeiten zu berechnen und Prozessleistung sowie Engpässe zu analysieren. Woher beziehen Timestamps stammen üblicherweise aus den Änderungsbelegköpfen (CDHDR-UDATE, CDHDR-UTIME) oder aus Workflow-Ereignisprotokollen. Beispiele 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| ID der Bestellanforderung PurchaseRequisitionId | Der eindeutige Bezeichner eines Bestellanforderungsbelegs. | ||
| Beschreibung Die ID der Bestellanforderung ist der Primärschlüssel, der jede Anforderung von Waren oder Dienstleistungen in SAP S/4HANA eindeutig identifiziert. Sie dient als zentrale Case-ID und verknüpft alle Aktivitäten und Änderungen zu einer bestimmten Bestellanforderung, von der Anlage bis zum endgültigen Status, etwa Genehmigung, Ablehnung oder Umwandlung in eine Bestellung. Im Process Mining ist dieses Attribut grundlegend, um den durchgängigen Lebenszyklus jeder Bestellanforderung zu rekonstruieren. Wenn alle zugehörigen Ereignisse unter einer einzigen ID der Bestellanforderung gruppiert werden, können Analysten Zykluszeiten präzise messen, Statusänderungen nachverfolgen und die verschiedenen Wege durch den Genehmigungsprozess analysieren. Warum das wichtig ist Diese zentrale Case-ID verknüpft alle zugehörigen Prozessschritte und ermöglicht so einen vollständigen, konsistenten Überblick über den Lebenszyklus der Bestellanforderung. Woher beziehen Dieses Attribut ist die Bestellanforderungsnummer aus dem Feld BANFN der Tabelle EBAN. Beispiele 100178901001789110017892 | |||
| Abteilung Department | Die Abteilung oder der Kostenrechnungskreis, der die Kosten der Bestellanforderung trägt. | ||
| Beschreibung Das Attribut „Abteilung“, in SAP häufig durch die Kostenstelle abgebildet, bezeichnet die Geschäftseinheit, die für den angeforderten Einkauf verantwortlich ist. Es ist eine wichtige Finanz- und Organisationsinformation, die auf Positionsebene der Bestellanforderung zugeordnet wird. Im Process Mining ist dieses Attribut für die Leistungsanalyse nach Abteilung unverzichtbar. Dashboards können damit wichtige Kennzahlen wie Zykluszeit, Änderungsquote und Ablehnungsquote zwischen Abteilungen vergleichen. So lassen sich leistungsstarke Abteilungen erkennen, deren Vorgehensweisen sich andernorts übernehmen lassen, ebenso wie Abteilungen, die zusätzliche Schulungen oder Unterstützung bei Prozessen benötigen. Warum das wichtig ist Ermöglicht den Leistungsvergleich zwischen Geschäftseinheiten. Unterschiede bei Zykluszeiten oder Ablehnungsquoten machen bewährte Vorgehensweisen und Verbesserungspotenziale sichtbar. Woher beziehen Dies ist die Kostenstelle, üblicherweise im Feld KOSTL der Kontierungsstammtabelle EBKN. Beispiele FIN-1001IT-2005MKT-3010 | |||
| Art der Bestellanforderung RequisitionType | Ein Code zur Klassifizierung der Bestellanforderung, zum Beispiel für Standardartikel, Dienstleistungen oder Investitionsausgaben. | ||
| Beschreibung Die Art der Bestellanforderung, in SAP auch Belegart genannt, ist ein wichtiges Konfigurationsfeld zur Kategorisierung von Bestellanforderungen. Je nach Art können unterschiedliche Genehmigungsworkflows und Feldeinstellungen gelten. Außerdem dient sie verschiedenen Geschäftszwecken, etwa für Standardlagerartikel, externe Dienstleistungen oder Anlagenbeschaffungen. Durch die Analyse nach Art der Bestellanforderung können Unternehmen nachvollziehen, wie verschiedene Anforderungen bearbeitet werden. So lassen sich Leistung, Zykluszeiten und Genehmigungswege zwischen Kategorien vergleichen. Dadurch wird sichtbar, ob bestimmte Arten von Bestellanforderungen effizienter oder weniger effizient bearbeitet werden, und Prozessverbesserungen können gezielt angepasst werden. Warum das wichtig ist Kategorisiert Bestellanforderungen für vergleichende Analysen. So lässt sich feststellen, ob unterschiedliche Anforderungsarten verschiedene Prozessabläufe, Engpässe oder Zykluszeiten aufweisen. Woher beziehen Dies ist das Feld für die Belegart, BSART in der Tabelle EBAN. Beispiele NBFORV | |||
| Benutzer-ID UserId | Der Bezeichner des Benutzers, der die Bestellanforderung angelegt 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 Bestellanforderung verantwortlich ist. Das kann die Person sein, die die Bestellanforderung angelegt, die Führungskraft, die sie genehmigt, oder der Sachbearbeiter, der sie geändert hat. Bei automatisierten Schritten kann es sich um die ID eines System- oder Batch-Benutzers handeln. Die Analyse nach Benutzer-ID zeigt benutzerspezifisches Verhalten, die Verteilung der Arbeitslast und die Prozesseinhaltung. Sie hilft, Schulungsbedarf zu erkennen, leistungsstarke Mitarbeitende zu identifizieren und die Verantwortlichkeit im Prozess sicherzustellen. In Verbindung mit Benutzerdaten unterstützt sie außerdem die Leistungsanalyse auf Abteilungsebene. Warum das wichtig ist Ermöglicht die Analyse der Benutzerleistung, der Arbeitslastverteilung und der Prozesseinhaltung. Das Attribut ist wichtig, um Schulungsbedarf und Engpässe bei Ressourcen zu erkennen. Woher beziehen Für den Ersteller steht die Benutzer-ID in EBAN-ERNAM. Bei späteren Änderungen findet sie sich in CDHDR-USERNAME, bei Genehmigungen in den Workflow-Protokollen. Beispiele JSMITHRROEWF-BATCH | |||
| Betrag der Bestellanforderung RequisitionAmount | Der Gesamtwert der Bestellanforderung. | ||
| Beschreibung Der Betrag der Bestellanforderung entspricht den geschätzten Gesamtkosten der angeforderten Waren oder Dienstleistungen. Dieser Wert beeinflusst häufig die Komplexität und Dauer des Genehmigungsworkflows. Bestellanforderungen mit höheren Beträgen erfordern in der Regel mehr Genehmigungsebenen. Mit diesem Attribut lässt sich der Prozess nach Wert segmentieren. So können Sie beispielsweise untersuchen, ob Bestellanforderungen mit hohen Beträgen länger bis zur Genehmigung brauchen oder welchen Wert häufig abgelehnte Bestellanforderungen haben. Das Attribut ist eine wichtige Dimension, um die finanziellen Auswirkungen von Prozessineffizienzen zu verstehen. Warum das wichtig ist Ermöglicht die Segmentierung des Prozesses nach finanzieller Auswirkung. Der Betrag hängt häufig mit der Komplexität der Genehmigung und der Zykluszeit zusammen und ist daher für wertbasierte Prozessanalysen wichtig. Woher beziehen Der Gesamtwert steht im Feld GFWERT der Tabelle EBAN. Der Positionswert findet sich in EBAN-PREIS. Beispiele 1500.0075000.50250.75 | |||
| ID des Genehmigenden ApproverId | Der Bezeichner des Benutzers, der einen Genehmigungs- oder Ablehnungsschritt ausgeführt hat. | ||
| Beschreibung Die ID des Genehmigenden identifiziert den Benutzer, der eine Genehmigung oder Ablehnung vorgenommen hat. Anders als die allgemeine Benutzer-ID bezieht sie sich ausschließlich auf die Entscheidungsträger im Genehmigungsworkflow. Diese Information ist für eine detaillierte Analyse des Genehmigungsprozesses unverzichtbar. Mit diesem Attribut lässt sich das Genehmigungsverhalten analysieren, etwa um Führungskräfte mit langen Genehmigungszeiten oder häufigen Ablehnungen zu erkennen. Es ist eine wichtige Grundlage für Dashboards zu Zykluszeiten einzelner Genehmigungsschritte und zur Engpassanalyse im Workflow. So lassen sich bestimmte Personen oder Rollen ermitteln, die Verzögerungen verursachen können. Warum das wichtig ist Zeigt, wer in einem Genehmigungsschritt die Entscheidung getroffen hat. So lassen sich Zykluszeiten und Engpässe nach Person oder Rolle detailliert analysieren. Woher beziehen Diese Informationen stammen üblicherweise aus SAP-Business-Workflow-Tabellen wie SWW_WI2OBJ und SWWLOGHIST, die Arbeitselemente mit dem Benutzer verknüpfen, der sie abgeschlossen hat. Beispiele MJOHNSONCWILLIAMSLBLACK | |||
| Status der Bestellanforderung RequisitionStatus | Der aktuelle Bearbeitungs- oder Genehmigungsstatus der Bestellanforderung. | ||
| Beschreibung Der Status der Bestellanforderung gibt ihren aktuellen Stand im Lebenszyklus an. In SAP wird er häufig durch den Freigabeindikator dargestellt. Dieser zeigt, ob eine Bestellanforderung gesperrt, in Genehmigung, teilweise genehmigt oder vollständig genehmigt ist. Der Status ändert sich, während die Bestellanforderung den Workflow durchläuft. Den Status im Zeitverlauf nachzuverfolgen, ist grundlegend, um den Prozessfluss zu verstehen. So lässt sich erkennen, an welchen Stellen Bestellanforderungen ins Stocken geraten und wie lange sie dort bleiben. Die Analyse der Statusübergänge zeigt den Genehmigungsprozess und seine Varianten im Detail. Warum das wichtig ist Zeigt den aktuellen Stand einer Bestellanforderung an. Das ist entscheidend, um den Fortschritt nachzuverfolgen, Engpässe zu erkennen und den Prozessfluss zu analysieren. Woher beziehen Der Freigabestatus wird häufig anhand des Freigabeindikators im Feld FRGZU der Tabelle EBAN bestimmt. Beispiele B1S | |||
| Ablehnungsgrund RejectionReason | Der Grund, der bei der Ablehnung einer Bestellanforderung angegeben wird. | ||
| Beschreibung Der Ablehnungsgrund erläutert, warum ein Genehmigender eine Bestellanforderung abgelehnt hat. Mögliche Gründe sind eine Budgetüberschreitung, fehlerhafte Angaben, Verstöße gegen Richtlinien oder eine doppelte Anforderung. Diese Information liefert wichtigen Kontext zu Problemen im Prozess. Die Analyse von Ablehnungsgründen hilft, die Ursachen für Ineffizienzen und Nacharbeit zu erkennen. Ist beispielsweise „Falsche Kostenstelle“ ein häufiger Grund, kann dies auf zusätzlichen Schulungsbedarf oder fehlende Systemprüfungen hinweisen. Dieses Attribut ist die Grundlage des Dashboards zur Analyse abgelehnter Bestellanforderungen und wichtig für gezielte Prozessverbesserungen. Warum das wichtig ist Zeigt die Ursachen für Probleme im Prozess auf. So lassen sich gezielte Verbesserungen umsetzen, die Nacharbeit verringern und den Anteil korrekt bearbeiteter Bestellanforderungen beim ersten Versuch erhöhen. Woher beziehen Häufig gibt es dafür kein Standardfeld. Der Grund kann in Workflow-Container-Elementen, einem Langtext zur Bestellanforderung oder in benutzerdefinierten Feldern erfasst sein. Beispiele Budget überschrittenFalscher LieferantDoppelte Anforderung | |||
| Automatisiert IsAutomated | Ein Kennzeichen dafür, ob eine Aktivität von einem Systembenutzer statt von einem Menschen ausgeführt wurde. | ||
| Beschreibung Das Attribut „Automatisiert“ ist ein boolescher Wert, der auf „wahr“ gesetzt ist, wenn eine Aktivität von einem System- oder Batch-Benutzer ausgeführt wurde, beispielsweise von „WF-BATCH“ bei Workflow-Aktionen. So lassen sich manuelle und automatisierte Prozessschritte unterscheiden. Dieses Attribut ist wichtig, um den Automatisierungsgrad im Bestellanforderungsprozess zu messen und die KPI „Automatisierte Genehmigungsquote“ zu berechnen. Durch die Filterung nach automatisierten oder manuellen Schritten können Analysten deren Effizienz vergleichen und weitere Automatisierungsmöglichkeiten erkennen, um Bearbeitungszeiten und manuellen Aufwand zu reduzieren. Warum das wichtig ist Unterscheidet menschlich ausgeführte von systemgesteuerten Aktivitäten. Das ist entscheidend, um Automatisierungsquoten zu messen und Möglichkeiten zur Automatisierung manueller Aufgaben zu erkennen. Woher beziehen Dieses abgeleitete Attribut basiert in der Regel auf einer Regel, die prüft, ob die User ID eines Ereignisses zu einer Liste bekannter System- oder Batch-Benutzer gehört. Beispiele truefalse | |||
| Benötigt bis RequiredByDate | Das Datum, bis zu dem der Anforderer die angeforderten Waren oder Dienstleistungen benötigt. | ||
| Beschreibung Das Datum „Benötigt bis“, in SAP auch Lieferdatum genannt, gibt an, wann die Waren oder Dienstleistungen der Bestellanforderungsposition benötigt werden. Der Anforderer legt dieses Datum fest. Es dient als Zieltermin für den gesamten Beschaffungsprozess. Dieses Attribut ist wichtig, um den KPI „Pünktliche Erledigung von Bestellanforderungen“ zu berechnen. Durch den Vergleich des Datums „Benötigt bis“ mit dem Datum der endgültigen Genehmigung oder der Bestellanlage kann das Unternehmen messen, ob interne Service-Level und Geschäftsanforderungen erfüllt werden. Die Analyse von Bestellanforderungen, bei denen dieser Termin überschritten wird, kann systematische Verzögerungen im Beschaffungsprozess aufzeigen. Warum das wichtig ist Legt den Zieltermin für die Erledigung einer Anforderung fest. So lassen sich die pünktliche Lieferung und die Einhaltung interner Service-Level messen. Woher beziehen Dies ist das Lieferdatum auf Positionsebene im Feld LFDAT der Tabelle EBAN. Beispiele 2023-11-152023-12-012024-01-20 | |||
| Bestellnummer PurchaseOrderNumber | Die Nummer der Bestellung, die aus der Bestellanforderung angelegt wurde. | ||
| Beschreibung Die Bestellnummer identifiziert den offiziellen Einkaufsbeleg, der aus einer genehmigten Bestellanforderung angelegt wurde. Die Anlage einer Bestellung ist häufig das erfolgreiche Endergebnis einer Bestellanforderung. Sie zeigt, dass die Anforderung in eine verbindliche Bestellung bei einem Lieferanten überführt wurde. Dieses Attribut ist entscheidend, um den KPI zur Durchlaufzeit von der Bestellanforderung bis zur Bestellung und die Umwandlungsquote zu messen. Es verknüpft den Prozess der Bestellanforderung mit dem nachgelagerten Beschaffungsprozess und ermöglicht so einen umfassenderen, durchgängigen Überblick über den gesamten Purchase-to-Pay-Zyklus. Warum das wichtig ist Verknüpft die Bestellanforderung mit dem nachfolgenden Beschaffungsbeleg. So lassen sich die Umwandlungsquote und die Durchlaufzeit von der Bestellanforderung bis zur Bestellung messen. Woher beziehen Steht im Feld EBELN der Tabelle EBAN, sobald aus der Position der Bestellanforderung eine Bestellung angelegt wurde. Beispiele 450001789045000178914500017892 | |||
| Bezeichnung des Genehmigungsschritts ApprovalStepName | Der Name oder die Beschreibung eines bestimmten Genehmigungsschritts im Workflow. | ||
| Beschreibung Die Bezeichnung des Genehmigungsschritts beschreibt eine bestimmte Phase im Genehmigungs-Workflow verständlich, zum Beispiel „Genehmigung durch die Führungskraft“ oder „Genehmigung durch den Finanzvorstand“. Sie ist aussagekräftiger als eine allgemeine Aktivität wie „Genehmigungsschritt abgeschlossen“. Dieses Attribut ist zentral für die Dashboards zur Zykluszeit von Genehmigungsschritten und zur Engpassanalyse im Workflow. Es ermöglicht eine detaillierte Sicht auf den Genehmigungsprozess. So lässt sich genau feststellen, welche Genehmigungsphasen die größten Verzögerungen verursachen und wo sich Arbeit ansammelt. Diese Detailtiefe ist notwendig, um gezielt Maßnahmen zur Verbesserung der Genehmigungskette einzuleiten. Warum das wichtig ist Liefert detaillierte Informationen zu den Genehmigungsphasen und ermöglicht es, Engpässe im mehrstufigen Genehmigungs-Workflow genau zu lokalisieren. Woher beziehen Diese Information stammt aus der Beschreibung der Workflow-Aufgabe. Sie lässt sich ermitteln, indem das Workflow-Protokoll mit Aufgabendefinitionstabellen wie T528T verknüpft wird. Beispiele Genehmigung durch die FührungskraftGenehmigung durch die DirektionGenehmigung durch den Finanzvorstand | |||
| Dringlichkeitsstufe UrgencyLevel | Einstufung der Dringlichkeit einer Bestellanforderung, die sich auf ihre Bearbeitungspriorität auswirken kann. | ||
| Beschreibung Die Dringlichkeitsstufe gibt die Priorität einer Bestellanforderung an. Ein eigenes Standardfeld dafür gibt es nicht. Manche Organisationen verwenden jedoch Felder wie die Bedarfsverfolgungsnummer, um diese Information zu erfassen. So können Anfordernde auf kritische Bedarfe hinweisen, die möglicherweise schneller bearbeitet werden müssen. Die Auswirkungen der Dringlichkeit zu analysieren, ist wichtig, um zu beurteilen, ob der Prozess kritische Anforderungen wirksam priorisiert. Das Dashboard zur Analyse der Auswirkungen der Dringlichkeitsstufe verwendet dieses Attribut, um Durchlaufzeiten und Genehmigungsquoten dringender und regulärer Bestellanforderungen zu vergleichen. So lässt sich feststellen, ob die Priorisierung wie vorgesehen funktioniert. Warum das wichtig ist Ermöglicht die Analyse der Prozessleistung bei Anfragen mit hoher Priorität und zeigt, ob dringende Vorgänge tatsächlich schneller bearbeitet werden. Woher beziehen Es gibt kein standardisiertes Feld für die Dringlichkeit. Manche Unternehmen verwenden dafür die Bedarfsverfolgungsnummer (EBAN-BEDAR). Möglich ist auch ein kundenspezifisches Feld. Beispiele HochMittelNiedrig | |||
| Endzeit EndTime | Datum und Uhrzeit, zu denen eine bestimmte Aktivität abgeschlossen wurde. | ||
| Beschreibung EndTime ist der Timestamp, der den Abschluss einer Aktivität erfasst. Viele systemgenerierte Ereignisse erfolgen unmittelbar, sodass StartTime und EndTime übereinstimmen. Bei Aufgaben, die von Mitarbeitenden ausgeführt werden, etwa Genehmigungen, können sich Start- und Endzeit unterscheiden. Dieser Timestamp markiert den Abschluss der Aufgabe. Eine separate EndTime ermöglicht eine genauere Messung der aktiven Bearbeitungszeit im Vergleich zur Wartezeit. Zusammen mit StartTime wird sie zur Berechnung der Kennzahl ProcessingTime verwendet. Diese Detailtiefe verbessert die Analyse der Ressourcennutzung und Effizienz bei manuellen Aufgaben. Warum das wichtig ist Kennzeichnet den Abschluss einer Aktivität. So lässt sich die aktive Bearbeitungszeit berechnen und die Dauer einer Aufgabe genauer analysieren. Woher beziehen Dieser Wert stammt aus Workflow-Protokollen, die sowohl den Zeitpunkt der 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 | |||
| 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. Diese Metadaten sind entscheidend, um die Aktualität der analysierten Daten einzuschätzen. Analysten und Fachanwender können anhand dieses Timestamps erkennen, ob die Prozessdaten den aktuellen Betriebsstand abbilden. Für jede Prozessanalyse ist es wichtig zu wissen, wie aktuell die Daten sind, um fundierte Entscheidungen zu treffen. Dieses Attribut hilft, Erwartungen der Benutzer zu steuern und sicherzustellen, dass Schlussfolgerungen auf Daten beruhen, die für die jeweilige Analyse aktuell genug sind. Warum das wichtig ist Zeigt an, wie aktuell die Daten sind. Das ist entscheidend, um der Analyse zu vertrauen und rechtzeitig Geschäftsentscheidungen zu treffen. Woher beziehen Dieser Timestamp wird während des ETL-Prozesses (Extraktion, Transformation und Laden) erzeugt und hinzugefügt. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Nacharbeit IsRework | Kennzeichnet, ob eine Aktivität Nacharbeit darstellt, zum Beispiel eine Änderung nach der Einreichung. | ||
| Beschreibung „Nacharbeit“ ist ein berechneter boolescher Wert, der Aktivitäten kennzeichnet, die unnötigen oder wiederholten Aufwand verursachen. Ein typisches Beispiel in diesem Prozess ist die Aktivität „Bestellanforderung geändert“, nachdem die Anforderung bereits zur Genehmigung eingereicht wurde. Dadurch muss der Genehmigungsprozess erneut beginnen. Dieses Attribut ist wichtig, um den Umfang der Nacharbeit und ihre Auswirkungen auf die gesamte Durchlaufzeit zu quantifizieren. Das Dashboard zu Änderungen und Nacharbeitsquote bei Bestellanforderungen verwendet diese Kennzeichnung, um Ineffizienzen im Prozess sichtbar zu machen. Nacharbeit zu reduzieren, ist häufig ein zentrales Ziel von Prozessverbesserungen, da dadurch unmittelbar Zeit und Aufwand eingespart werden. Warum das wichtig ist Kennzeichnet Aktivitäten, die Aufwand verschwenden oder wiederholen. So lassen sich Nacharbeit und ihre Auswirkungen auf die Prozesseffizienz direkt messen. Woher beziehen Dies ist ein berechnetes Attribut. Die Logik kennzeichnet üblicherweise jede Aktivität „Bestellanforderung geändert“ als Nacharbeit, die nach der ersten Aktivität „Bestellanforderung zur Genehmigung eingereicht“ auftritt. Beispiele truefalse | |||
| Quellsystem SourceSystem | Gibt die SAP-S/4HANA-Instanz an, aus der die Daten extrahiert wurden. | ||
| Beschreibung Das Attribut „Quellsystem“ gibt an, in welchem Ursprungssystem die Prozessdaten erzeugt wurden. In Unternehmen mit mehreren SAP-Instanzen, etwa für Entwicklung, Qualitätssicherung und Produktion oder für verschiedene Regionen, ist dieses Feld für Data Governance und die Einordnung der Daten entscheidend. Es ermöglicht, Daten aus verschiedenen Quellen zu unterscheiden. So werden fehlerhafte Zusammenfassungen vermieden und systembezogene Analysen möglich. Das Attribut ist erforderlich, um die Datenherkunft zu dokumentieren und die Rückverfolgbarkeit der Prozessdaten sicherzustellen. Warum das wichtig ist Liefert wichtige Informationen zur Datenherkunft und Data Governance, insbesondere bei mehreren Systemen, und gewährleistet die Rückverfolgbarkeit der Daten. Woher beziehen In der Regel handelt es sich um die SAP-System-ID (SID), die sich aus Systemvariablen oder Konfigurationstabellen abrufen lässt. Beispiele S4PECCS4H_PROD_01 | |||
| Währung Currency | Der Währungscode für den Betrag der Bestellanforderung. | ||
| Beschreibung Dieses Attribut gibt an, in welcher Währung der Betrag der Bestellanforderung angegeben ist, zum Beispiel USD, EUR oder JPY. Es liefert den erforderlichen Kontext für den Betrag der Bestellanforderung, insbesondere in multinationalen Unternehmen, die mit mehreren Währungen arbeiten. Für korrekte Finanzanalysen und Berichte muss die Währung berücksichtigt werden. Beim Zusammenfassen oder Vergleichen von Beträgen der Bestellanforderungen sollten alle Werte in eine gemeinsame Währung umgerechnet werden, damit die Ergebnisse aussagekräftig sind. Dieses Attribut ist Voraussetzung für solche Umrechnungen. Warum das wichtig ist Liefert den erforderlichen Kontext zum Betrag der Bestellanforderung und ermöglicht korrekte Finanzanalysen und Vergleiche in Umgebungen mit mehreren Währungen. Woher beziehen Der Wert steht im Feld WAERS der Tabelle EBAN. Beispiele USDEURGBP | |||
Aktivitäten im Purchase-to-Pay-Prozess mit Bestellanforderungen
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Bestellanforderung abgelehnt | Kennzeichnet die endgültige Ablehnung der Bestellanforderung durch einen Genehmigenden, wodurch der Prozess beendet wird. Sie wird durch eine bestimmte Statusänderung erfasst, die eine Ablehnung anzeigt. | ||
| Warum das wichtig ist Diese Aktivität kennzeichnet einen kritischen Endpunkt des Prozesses. Die Häufigkeit und Gründe von Ablehnungen sowie die jeweiligen Prozessschritte zu analysieren, hilft dabei, Probleme mit Richtlinien, Budgets oder der Qualität der Anforderungen zu erkennen. Woher beziehen 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. Erfassung Ermitteln Sie anhand der Änderungsbelege den Timestamp, zu dem der Gesamtstatus in EBAN auf „Abgelehnt“ gesetzt wird. Ereignistyp inferred | |||
| Bestellanforderung abgeschlossen | Zeigt an, dass die Position der Bestellanforderung vollständig bearbeitet wurde und daraus keine weiteren Bestellungen angelegt werden können. Dieser Status wird üblicherweise automatisch gesetzt, sobald die gesamte Menge bestellt wurde. | ||
| Warum das wichtig ist Diese Aktivität kennzeichnet den erfolgreichen Abschluss des Lebenszyklus der Position der Bestellanforderung. Sie bestätigt, dass der Bedarf vollständig in eine Bestellung überführt wurde. Woher beziehen Abgeleitet aus der Tabelle EBAN. Das Ereignis tritt ein, wenn das Kennzeichen „Abgeschlossen“ (EBAKZ) gesetzt wird. Dies geschieht üblicherweise, sobald die in Bestellungen georderte Menge der Menge der Bestellanforderung entspricht. Erfassung Ermitteln Sie anhand der Änderungsbelege das Ereignis, bei dem das Kennzeichen „Abgeschlossen“ (EBAKZ) in der Tabelle EBAN gesetzt wird. Ereignistyp inferred | |||
| Bestellanforderung angelegt | Kennzeichnet die erstmalige Anlage des Bestellanforderungsbelegs im System. Dieses Ereignis wird explizit erfasst, wenn ein Benutzer eine neue Bestellanforderung zum ersten Mal speichert. Dabei wird der Erstellungszeitpunkt festgehalten. | ||
| Warum das wichtig ist Diese Aktivität ist der zentrale Startpunkt für die Analyse des Lebenszyklus einer Bestellanforderung. Sie ist entscheidend, um die durchgängige Zykluszeit zu messen, vom Erkennen des Bedarfs bis zur endgültigen Genehmigung oder Umwandlung in eine Bestellung. Woher beziehen Dieses explizite Ereignis wird aus der Tabelle EBAN anhand der Felder für Erstellungsdatum (ERDAT) und Erstellungszeit (ERZEIT) für die jeweilige Bestellanforderungsnummer (BANFN) erfasst. Erfassung Verwenden Sie für jede Bestellanforderung (BANFN) die Felder für den Erstellungszeitpunkt (ERDAT, ERZEIT) aus der Tabelle EBAN. Ereignistyp explicit | |||
| Bestellanforderung genehmigt | Kennzeichnet die endgültige und vollständige Genehmigung der Bestellanforderung. Damit kann sie in eine Bestellung umgewandelt werden. Dieser Meilenstein wird abgeleitet, sobald der Gesamtfreigabestatus den endgültigen Genehmigungsstatus erreicht. | ||
| Warum das wichtig ist Dies ist ein wichtiger Erfolgsmeilenstein und ein häufig verwendeter Endpunkt für die Zykluszeitanalyse. Er zeigt, dass die Bestellanforderung alle Prüfungen bestanden hat und von der Einkaufsabteilung weiterbearbeitet werden kann. Woher beziehen Abgeleitet aus einer Statusänderung in der Tabelle EBAN, insbesondere wenn der Gesamtfreigabeindikator (FRGZU) oder der Bearbeitungsstatus (PROCSTAT) auf den endgültigen Wert „Genehmigt“ gesetzt wird. Erfassung Ermitteln Sie den Timestamp, zu dem der letzte Freigabecode gesetzt wird oder sich der Gesamtstatus der Bestellanforderung zu „Genehmigt“ ändert. Ereignistyp inferred | |||
| Bestellung angelegt | Zeigt an, dass eine Bestellung angelegt wurde, die auf die Position der Bestellanforderung verweist. Dieses explizite Systemereignis verknüpft die Bestellanforderung mit einem nachfolgenden Beschaffungsbeleg. | ||
| Warum das wichtig ist Dies ist ein wichtiger Meilenstein und ein erfolgreiches Ergebnis des Bestellanforderungsprozesses. Die Zeit zwischen der Genehmigung der Bestellanforderung und der Anlage der Bestellung ist ein entscheidender KPI für die Beschaffungseffizienz. Woher beziehen Wird explizit erfasst, wenn eine Bestellposition angelegt wird. Die Verknüpfung ist in der Tabelle EKPO (Bestellposition) gespeichert. Sie enthält die Nummer der zugrunde liegenden Bestellanforderung (BANFN) und die Positionsnummer (BNFPO). Erfassung Verknüpfen Sie die Tabelle EKPO über die Nummer und Position der Bestellanforderung mit EBAN. Das Erstellungsdatum der Bestellposition kennzeichnet das Ereignis. Ereignistyp explicit | |||
| Genehmigungsschritt abgeschlossen | Tritt ein, wenn ein Genehmigender eine Bestellanforderung positiv entscheidet und damit einen Schritt im mehrstufigen Genehmigungsworkflow abschließt. Dies wird aus einer Änderung des Freigabestatus der Bestellanforderung abgeleitet. | ||
| Warum das wichtig ist Mit dieser Aktivität lässt sich der Genehmigungsworkflow detailliert analysieren und die Bearbeitungszeit für jeden einzelnen Schritt messen. So können Sie effiziente Genehmigende und Engpässe im Prozess erkennen. Woher beziehen Abgeleitet aus Änderungsbelegen (CDHDR/CDPOS) zur Tabelle EBAN. Eine Änderung des Freigabestatus für einen bestimmten Code (z. B. im Feld FRGZU) von nicht freigegeben zu freigegeben kennzeichnet dieses Ereignis. Erfassung Verfolgen Sie die Änderungen der Freigabestatusfelder in EBAN für jeden in der Strategie definierten Freigabecode. Ereignistyp inferred | |||
| Bestellanforderung geändert | Tritt ein, wenn ein Benutzer nach der erstmaligen Anlage ein wichtiges Feld der Bestellanforderung ändert, etwa Menge, Preis oder Material. Diese Änderung wird explizit im Änderungsbelegsystem von SAP protokolliert. | ||
| Warum das wichtig ist Änderungen nachzuverfolgen ist entscheidend, um Nacharbeitsschleifen und ihre Auswirkungen auf die Zykluszeit zu erkennen. Häufige Änderungen deuten auf Probleme mit der Datenqualität oder auf veränderte Anforderungen hin. Beides sind wichtige Ansatzpunkte für Prozessverbesserungen. Woher beziehen Änderungen an der Tabelle EBAN werden explizit in den SAP-Änderungsbelegt Tabellen CDHDR und CDPOS protokolliert. Für jede Änderung an einem überwachten Feld wird ein Eintrag angelegt. Erfassung Extrahieren Sie Änderungsereignisse aus CDHDR/CDPOS, bei denen die Objektklasse für Bestellanforderungen BANF lautet. Ereignistyp explicit | |||
| Bestellanforderung zur Genehmigung eingereicht | Kennzeichnet den Zeitpunkt, zu dem der Anforderer die Bestellanforderung offiziell einreicht und damit den Genehmigungsworkflow auslöst. Dies wird üblicherweise daraus abgeleitet, dass die Freigabestrategie der Bestellanforderung festgelegt wird und sich der Status zu „In Genehmigung“ ändert. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein startet die Messung der Zykluszeit für Genehmigungs-KPIs. Die Zeit zwischen Anlage und Einreichung kann Verzögerungen bei der Vorbereitung der Bestellanforderung sichtbar machen. Woher beziehen Abgeleitet aus Änderungsbelegen (CDHDR/CDPOS) für die Tabelle EBAN, insbesondere wenn Felder der Freigabestrategie (z. B. FRGST) befüllt werden oder sich der Gesamtstatus (PROCSTAT) in einen Status „In Genehmigung“ ändert. Erfassung Ermitteln Sie den ersten Änderungsbelegeintrag, der den Beginn des Genehmigungsworkflows oder einen Statuswechsel zu „In Genehmigung“ anzeigt. Ereignistyp inferred | |||
| Bestellanforderung zurückgezogen | Tritt ein, wenn der ursprüngliche Anforderer die Bestellanforderung storniert oder löscht, bevor sie vollständig bearbeitet wurde. Dabei wird üblicherweise explizit ein Löschkennzeichen für die Position der Bestellanforderung gesetzt. | ||
| Warum das wichtig ist Die Nachverfolgung zurückgezogener Anforderungen hilft, Schwankungen im Bedarf und Gründe für Stornierungen zu verstehen. Sie kennzeichnet einen Endstatus der Bestellanforderung, nach dem keine weitere Bearbeitung möglich ist. Woher beziehen Wird explizit erfasst, wenn das Löschkennzeichen (LOEKZ) für eine Position der Bestellanforderung in der Tabelle EBAN gesetzt wird. Die Änderung wird in CDHDR/CDPOS protokolliert. Erfassung Ermitteln Sie das Ereignis, bei dem das Löschkennzeichen (LOEKZ) in der Tabelle EBAN auf „L“ gesetzt wird. Ereignistyp explicit | |||
| Bezugsquelle zugeordnet | Kennzeichnet, dass ein Einkäufer einer genehmigten Position der Bestellanforderung einen bestimmten Lieferanten, Vertrag oder Infosatz zuordnet. Dies ist ein wichtiger Schritt, um die Bestellanforderung für die Anlage einer Bestellung vorzubereiten. | ||
| Warum das wichtig ist Diese Aktivität schließt die Lücke zwischen Genehmigung und Bestellung. Die Zeit bis zur Zuordnung einer Bezugsquelle zeigt Verzögerungen bei der Arbeitslast des Einkäufers und bei der Beschaffungseffizienz. Woher beziehen Abgeleitet aus einem Eintrag in den Feldern der Tabelle EBAN, die sich auf die Bezugsquelle beziehen, etwa Festlieferant (LIFNR), Infosatz (INFNR) oder Vertrag (KONNR). Erfassung Verfolgen Sie anhand der Änderungsbelege, wann Felder wie LIFNR, INFNR oder KONNR in der Tabelle EBAN befüllt werden. Ereignistyp inferred | |||
| Genehmigung zurückgesetzt | Kennzeichnet das Zurücksetzen des gesamten Genehmigungsworkflows, häufig aufgrund einer wesentlichen Änderung an der Bestellanforderung. Dadurch beginnt der Genehmigungsprozess erneut auf der ersten Ebene. | ||
| Warum das wichtig ist Diese Aktivität macht erhebliche Nacharbeit sichtbar, die die Zykluszeit stark beeinträchtigt. Die Ursachen für das Zurücksetzen von Genehmigungen zu ermitteln, ist entscheidend, um den Prozess zu vereinfachen und Verzögerungen zu verringern. Woher beziehen Abgeleitet aus Änderungsbelegen (CDHDR/CDPOS) zur Tabelle EBAN. Das Ereignis wird erkannt, wenn Felder für den Freigabestatus (z. B. FRGKZ oder FRGZU) zurückgesetzt werden, nachdem sie teilweise oder vollständig gesetzt waren. Erfassung Suchen Sie in den Änderungsprotokollen nach einem Wechsel des Freigabestatus von freigegeben zu nicht freigegeben. Ereignistyp inferred | |||
| Genehmigungsschritt gestartet | Zeigt an, dass eine Bestellanforderung auf eine Aktion eines bestimmten Genehmigenden oder einer Genehmigungsgruppe wartet. Dies wird daraus abgeleitet, dass der Status der Bestellanforderung auf einen ausstehenden bestimmten Freigabecode hinweist. | ||
| Warum das wichtig ist Diese Aktivität ist entscheidend, um Engpässe in der Genehmigungskette zu erkennen. Die Dauer dieses Status zeigt, welche Bestellanforderungen nicht weiterbearbeitet werden und welche Genehmigenden überlastet sind. Woher beziehen Abgeleitet aus den Freigabestatusfeldern der Tabelle EBAN (z. B. FRGZU) und der zugrunde liegenden Konfiguration der Freigabestrategie. Das Ereignis beginnt, sobald ein bestimmter Freigabecode als Nächstes bearbeitet werden muss. Erfassung Ermitteln Sie anhand von Workflow-Protokollen oder Statusfeldern, wann eine Bestellanforderung in einen Status wechselt, in dem ein bestimmter Freigabecode auf Genehmigung wartet. Ereignistyp inferred | |||
Anleitungen zur Datenextraktion
Schritte
- Voraussetzungen: Stellen Sie sicher, dass Sie über einen Benutzer mit den erforderlichen Berechtigungen in SAP S/4HANA verfügen, um auf die benötigten CDS Views zuzugreifen. Dazu gehören in der Regel Berechtigungen für Objekte wie S_TABU_NAM sowie der Zugriff auf Werkzeuge zur Datenanzeige.
- Zugriffsmethode auf das System ermitteln: Legen Sie fest, wie Sie eine Verbindung zur SAP-S/4HANA-Datenbank herstellen, um SQL-Abfragen auszuführen. Gängige 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 Database 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 zu verschiedenen Aktivitäten zu erfassen und zu einem einheitlichen Event Log zusammenzuführen.
- Platzhalter anpassen: Suchen Sie die Platzhalter in der Abfrage und ersetzen Sie sie. Legen Sie den Datumsbereich für den Extraktionszeitraum im Format
[YYYY-MM-DD]fest und geben Sie die relevanten Buchungskreise Ihrer Organisation als[Your Company Code]an. - Abfrage ausführen: Führen Sie die vollständige, angepasste SQL-Abfrage für die SAP-S/4HANA-Datenbank aus. Je nach Datenvolumen und ausgewähltem Zeitraum kann die Ausführung einige Zeit dauern.
- Daten zunächst prüfen: Prüfen Sie nach Abschluss der Abfrage die ersten Zeilen der Ausgabe. Kontrollieren Sie, ob alle Spalten, etwa PurchaseRequisitionId, ActivityName und EventTime, wie erwartet befüllt sind und die Datenformate stimmen.
- Datentransformation berücksichtigen: Die Abfrage gibt die Daten in einem für Process Mining geeigneten Format aus. Die Funktionen
CASTundCONCATsorgen für einheitliche Datentypen. Eine umfangreiche nachträgliche Transformation sollte nicht erforderlich sein. - Event Log exportieren: Exportieren Sie das gesamte Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Stellen Sie sicher, dass die Datei UTF-8-kodiert ist, um Zeichenfehler zu vermeiden.
- Upload vorbereiten: Prüfen Sie vor dem Upload in ein Process-Mining-Werkzeug, ob die CSV-Datei die richtigen Spaltenüberschriften enthält (
PurchaseRequisitionId,ActivityName,EventTimeusw.) und ob das Datums- und Zeitformat vonEventTimeeinheitlich ist und von der Zielplattform unterstützt wird. - In ProcessMind hochladen: Laden Sie die fertige CSV-Datei in Ihr ProcessMind-Projekt hoch. Konfigurieren Sie das Projekt, indem Sie
PurchaseRequisitionIdals Case-ID,ActivityNameals Aktivität undEventTimeals Timestamp zuordnen.
Konfiguration
- Zentrale CDS Views: Für die Extraktion werden hauptsächlich
I_PurchaseRequisitionAPI01für die Kerndaten der Bestellanforderungen,I_ChangeDocumentundI_ChangeDocumentItemzur Erfassung von Änderungen und Statusaktualisierungen sowieI_PurchaseOrderItemAPI01zur Verknüpfung mit Bestellungen verwendet. - Berechtigungen: Der ausführende Benutzer benötigt Lesezugriff auf die genannten CDS Views. Erkundigen Sie sich bei Ihrem SAP-Sicherheitsteam nach den erforderlichen Rollen und Berechtigungen.
- Filter für den Datumsbereich: Begrenzen Sie das Datenvolumen unbedingt mit einem Filter auf das Erstellungsdatum der Bestellanforderung (
CreationDate). Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten. - Filter nach Organisation: Filtern Sie die Daten nach
CompanyCode, damit Sie den Prozess für die richtige Geschäftseinheit analysieren. Sie können zusätzlich nachPurchaseRequisitionTypefiltern, um bestimmte Beschaffungsprozesse zu untersuchen, etwa Standardwaren oder Dienstleistungen. - Konfiguration der Änderungsbelege: Aktivitäten wie „Bestellanforderung geändert“ und verschiedene Genehmigungsschritte lassen sich nur erfassen, wenn die Änderungsbelegprotokollierung für die betreffenden Felder in Ihrem SAP-System aktiviert ist. Fehlen solche Ereignisse, prüfen Sie die Systemkonfiguration für die Tabelle EBAN.
- Leistung: Bei 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.
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
- Prüfen Sie, ob direkter Lesezugriff auf das SAP-HANA-Schema mit EBAN und EBKN verfügbar ist. Ermitteln Sie außerdem, welche Änderungsbeleg- und Einkaufsbelegobjekte Ihr System für Änderungen an Bestellanforderungen, Freigabeverarbeitung, Bezugsquellenzuordnung, Bestellreferenzen und Abschlüsse 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.
- Prüfen Sie EBAN und EBKN in der SAP GUI mit der Transaktion SE16H oder einem zugelassenen Datenbankverwaltungstool. Verifizieren Sie die Schlüsselfelder der Bestellanforderungen und kontrollieren Sie, welche Felder für Datum, Uhrzeit, Benutzer, Status, Löschung, Freigabe, Kontierung und Einkaufsbelegreferenz verfügbar sind. Prüfen Sie die Felddefinitionen mit SE11 oder im SAP Data Dictionary. Legen Sie bei Tests keine Produktivdaten offen.
- Ermitteln Sie die konfigurierte Änderungsbelegquelle für Änderungen an Bestellanforderungen und Genehmigungen. Die Abfrage erwartet eine normalisierte Änderungsquelle mit dem Namen [Your requisition change document source]. Diese Quelle muss Felder für Bestellanforderungsnummer, Positionsnummer, geändertes Feld, alten Wert, neuen Wert, Änderungsdatum, Änderungsuhrzeit und Benutzer enthalten. Ordnen Sie die Quelle vor der Ausführung den relevanten SAP-Änderungsbelegtabellen oder der CDS View Ihres Systems zu.
- Ermitteln Sie die konfigurierte Workflow- oder Freigabequelle für Einreichung, Zurücksetzen der Genehmigung, Beginn und Abschluss eines Genehmigungsschritts, endgültige Genehmigung und Ablehnung. Die Abfrage erwartet [Your requisition approval event source] mit einer Zeile pro Status- oder Freigabeübergang und Feldern für Bestellanforderungsnummer, Positionsnummer, Ereignistyp, Freigabecode oder Genehmigungsgruppe, genehmigende Person, Ereignisdatum, Ereignisuhrzeit und Status. Ordnen Sie diese Quelle den Freigabe- oder Workflow-Daten Ihres S/4HANA-Systems zu.
- Ermitteln 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 zugelassenen Tabellen oder Views Ihres Systems zu. Die Erstellung einer Bestellung muss durch eine ausdrückliche Referenz von der Bestellposition zur Bestellanforderungsposition belegt sein. Leiten Sie sie nicht aus nicht zugehörigen Einkaufsaktivitäten ab.
- Legen Sie den Extraktionszeitraum 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 nach Prüfung der Datenbankleistung und des Ereignisvolumens einen längeren Zeitraum. Die Abfrage filtert nach Erstellungs- und Ereignisdatum und verwendet weiterhin die Bestellanforderungs-ID als Case-ID.
- Führen Sie die Abfrage mit einem zugelassenen SQL-Client aus, der mit SAP HANA verbunden ist. Ersetzen Sie ausschließlich Verbindungsdetails außerhalb der Abfrage, Datumsparameter, unternehmensspezifische Filter sowie ausdrücklich dokumentierte Platzhalter für Quellen und Felder. Übernehmen Sie die Ausgabespaltennamen exakt wie folgt: PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount und RequisitionStatus.
- Prüfen Sie doppelte Ereignisse, Timestamp-Genauigkeit, Zeitzonenbehandlung sowie die Granularität auf Positions- oder Belegebene. Die Abfrage gibt Case-IDs auf Belegebene aus und enthält intern den Positionskontext. Wenn mehrere Positionen dieselbe Aktivität und denselben Timestamp aufweisen, behalten Sie separate Zeilen bei, sofern Ihr ProcessMind-Design nicht ausdrücklich eine Deduplizierung vorsieht.
- Prüfen Sie, ob jede erforderliche Aktivität als Wert in ActivityName vorkommt, EventTime befüllt und chronologisch plausibel ist und die erforderliche Case-ID nicht leer ist. Gleichen Sie die Anzahl der Datensätze mit SAP-Berichten oder zugelassenen operativen Datenextrakten für denselben Zeitraum ab.
- Exportieren Sie das Ergebnis als UTF-8-kodierte CSV-Datei 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 Aktivitätsspalte und EventTime als Timestamp-Spalte hoch.
Konfiguration
- Case-ID: Verwenden Sie die Belegnummer der Bestellanforderung aus EBAN als PurchaseRequisitionId. Ist der Prozess auf Positionsebene konfiguriert, verwenden Sie stattdessen einen dokumentierten zusammengesetzten Schlüssel, zum Beispiel aus Bestellanforderungsnummer und Positionsnummer, und wenden Sie denselben Schlüssel auf alle Ereignisse an.
- Primärquelle: EBAN enthält die Positionsdaten der Bestellanforderungen. EBKN dient dazu, Kontierungsdaten sowie Angaben zu Abteilung oder Kostenstelle zu ergänzen. Prüfen Sie vor der Ausführung die genauen Feldnamen und Datentypen im SAP Data Dictionary.
- Ereignisquellen: Die Abfrage verwendet bewusst allgemeine Platzhalter für Änderungs-, Genehmigungs-, Bezugsquellenzuordnungs-, Bestellreferenz- und Abschlussquellen. Diese hängen vom S/4HANA-Release, Workflow-Design, Freigabeverfahren, aktivierten Geschäftsfunktionen und kundenspezifischen Erweiterungen ab.
- Datumsbereich: Beginnen Sie mit drei bis sechs Monaten. Verwenden Sie, sofern verfügbar, ein begrenztes Intervall für indizierte Datumsfelder oder Felder, die eine Partitionsbereinigung ermöglichen. Bei inkrementellen Ladevorgängen sollten sich die Extraktionszeiträume ausreichend überschneiden, damit verspätet eintreffende Änderungen erfasst werden. Deduplizieren Sie anschließend anhand von Case, Aktivität, Timestamp, Position und Quellereignisschlüssel.
- Geschäftsfilter: Richten Sie [Company code filter], [Document type filter], [Purchasing group filter] und [Plant filter] nur ein, wenn die entsprechenden Felder verfügbar und ihre fachliche Bedeutung bestätigt sind. Filtern Sie nicht nach Status, wenn der vollständige Lebenszyklus erfasst werden soll.
- Statuszuordnung: Konfigurieren Sie die Werte für „In Genehmigung“, endgültig genehmigt, abgelehnt, zurückgesetzt, ausstehender Freigabecode und abgeschlossen entsprechend der Freigabestrategie oder Workflow-Konfiguration des Zielsystems. Gehen Sie nicht davon aus, dass ein Statuscode für alle SAP-Mandanten gilt.
- 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 ausdrückliche Bedingungen für die aufgeführten Schlüsselfelder. Die Quelle muss den Namen des geänderten Feldes bereitstellen.
- Behandlung von Timestamps: Führen Sie Ereignisdatum und Ereignisuhrzeit in der Datenbankzeitzone zusammen und dokumentieren Sie anschließend jede Umrechnung in UTC. Speichert eine Quelle nur ein Datum, verwenden Sie Mitternacht nur dann, wenn kein genauerer Timestamp verfügbar ist, und dokumentieren Sie diese Einschränkung.
- Leistung: Begrenzen Sie die erste Extraktion nach Datum und Geschäftsbereich, wählen Sie nur erforderliche Spalten aus, vermeiden Sie uneingeschränkte Verknüpfungen mit umfangreichen Änderungs- oder Workflow-Verläufen und prüfen Sie den HANA-Ausführungsplan. Wenn wiederholte Extraktionen erforderlich sind, materialisieren oder speichern Sie normalisierte Ereignisquellen zwischen.
- Berechtigungen und Voraussetzungen: Beschaffen Sie Lesezugriff auf EBAN, EBKN, die konfigurierten Änderungs- und Workflow-Quellen, Daten zur Bezugsquellenzuordnung, Bestellreferenzdaten und Abschlussdaten. Prüfen Sie, ob der direkte Datenbankzugriff genehmigt ist, die relevanten Einkaufs- und Workflow-Funktionen aktiv sind und die erforderliche SAP-HANA-Datenbanklizenz oder Administrationswerkzeuge verfügbar sind.
- Sicherheit: Beschränken Sie Berechtigungen auf das notwendige Minimum, schützen Sie Benutzer- und Genehmigerkennungen und halten Sie die organisatorischen Vorgaben zur Extraktion von Einkaufs- und Finanzdaten ein.
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 loslegen?
Mit diesem Template können Sie Ihre Daten gezielt vorbereiten und das Potenzial von Process Mining für Ihren Purchase-to-Pay-Prozess mit Bestellanforderungen ausschöpfen. Beginnen Sie noch heute damit, die Effizienz zu verbessern.
Schluss mit Verzögerungen bei P2P-Bestellanforderungen: Optimieren Sie jetzt Ihren Workflow!
Vereinfachen Sie Prozesse, verkürzen Sie Durchlaufzeiten und reduzieren Sie die Zykluszeit um 30 %.
Keine Kreditkarte erforderlich. Die Einrichtung dauert 5 Minuten.