Ihr Daten-Template für den Purchase-to-Pay-Prozess mit Bestellungen
Ihr Daten-Template für den Purchase-to-Pay-Prozess mit Bestellungen
- Empfohlene Attribute für detaillierte Analysen
- Wichtige Aktivitäten im Prozess, die Sie verfolgen sollten
- Anleitung zur Datenextraktion in einzelnen Schritten
Attribute für den Purchase-to-Pay-Prozess mit Bestellungen
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivität ActivityName | Der Name des Geschäftsvorfalls oder Prozessschritts, der im Bestellprozess stattgefunden hat. | ||
| Beschreibung Dieses Attribut beschreibt eine bestimmte Aktion oder Statusänderung im Lebenszyklus einer Bestellung, zum Beispiel „Bestellung erstellt“, „Bestellung genehmigt“ oder „Wareneingang gebucht“. Die Abfolge dieser Aktivitäten bildet den Prozessfluss. Die Analyse der Reihenfolge und Häufigkeit von Aktivitäten ist der Kern von Process Mining. Sie hilft, den tatsächlichen Prozess zu entdecken, ihn mit dem Sollmodell zu vergleichen, Engpässe zu erkennen, etwa lange Wartezeiten nach „Rechnung eingegangen“, und Nacharbeit zu quantifizieren, zum Beispiel wiederholte Aktivitäten vom Typ „Bestellung geändert“. Warum das wichtig ist Das Attribut definiert die Prozessschritte und ermöglicht die Visualisierung und Analyse des durchgängigen Ablaufs, die Variantenanalyse und das Erkennen von Engpässen. Woher beziehen Üblicherweise aus einer Kombination von Tabellen und Feldern abgeleitet, etwa aus Statusfeldern in EKKO/EKPO oder Änderungsbelegen in CDHDR/CDPOS, um wichtige geschäftliche Meilensteine abzubilden. Beispiele Bestellung erstelltBestellung genehmigtWareneingang gebuchtRechnung eingegangen | |||
| Bestellung PurchaseOrderNumber | Die eindeutige Kennung der Bestellung (PO), die als primäre Case-ID zur Nachverfolgung des Beschaffungslebenszyklus dient. | ||
| Beschreibung Die Bestellnummer ist die zentrale Kennung, über die alle zugehörigen Aktivitäten verknüpft werden, von der ursprünglichen Erstellung bis zum endgültigen Wareneingang und Abschluss. Sie dient als Case-ID für die Process-Mining-Analyse. Wenn Sie Ereignisse in der Analyse nach dieser Nummer gruppieren, lässt sich der Ablauf jeder einzelnen Bestellung rekonstruieren. Das ist wichtig, um Durchlaufzeiten zu berechnen, Prozessvarianten zu analysieren und Engpässe oder Abweichungen bei einzelnen Bestellungen zu erkennen. Warum das wichtig ist Dieser Schlüssel verbindet alle Beschaffungsereignisse zu einem durchgängigen Prozess und ermöglicht eine detaillierte Analyse des Lebenszyklus jeder Bestellung. Woher beziehen Dieses Attribut befindet sich in der SAP-S/4HANA-Tabelle EKKO, Feld EBELN. Beispiele 450001712345000171244500017125 | |||
| Ereigniszeit EventTime | Der Timestamp, der angibt, wann die Aktivität stattgefunden hat. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit jeder Aktivität im Prozess. Es bildet die Grundlage für alle zeitbasierten Analysen im Process Mining. Die Ereigniszeit dient dazu, Aktivitäten chronologisch zu ordnen und den Prozessfluss aufzubauen. Außerdem bildet sie die Grundlage für alle zeitbezogenen Kennzahlen, etwa Durchlaufzeiten zwischen Aktivitäten, Wartezeiten und Bearbeitungszeiten. Diese sind entscheidend für die Leistungsanalyse und das Erkennen von Engpässen. Warum das wichtig ist Dieser Timestamp ist entscheidend, um Ereignisse korrekt zu ordnen und alle Leistungskennzahlen zu berechnen, einschließlich Durchlauf-, Liefer- und Wartezeiten. Woher beziehen Timestamp-Felder zu bestimmten Aktivitäten, etwa Erstellungsdatum (EKKO-AEDAT für Änderungen) oder Buchungsdatum (MKPF-BUDAT für Wareneingänge). Häufig müssen dafür Daten aus mehreren Tabellen kombiniert werden. Beispiele 2023-04-15T10:00:00Z2023-04-15T14:30:00Z2023-05-01T09:15:00Z | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp der letzten Aktualisierung oder Extraktion der Daten aus dem Quellsystem. | ||
| Beschreibung Dieses Attribut gibt an, wie aktuell die analysierten Daten sind. Es zeigt Datum und Uhrzeit des letzten Datenabrufs aus SAP S/4HANA. Der Zeitpunkt der letzten Datenaktualisierung hilft Benutzern, die Aktualität ihrer Analyse einzuschätzen. So können sie die Ergebnisse richtig einordnen und erkennen, ob sie Echtzeitinformationen oder eine Momentaufnahme zu einem bestimmten Zeitpunkt betrachten. Das beeinflusst, wie relevant die darauf basierenden Maßnahmen sind. Warum das wichtig ist Informiert Benutzer über die Aktualität der Daten und hilft ihnen, Kontext und Relevanz ihrer Analyseergebnisse richtig einzuschätzen. Woher beziehen Dieser Metadaten-Timestamp wird während der Datenextraktion, -transformation und -ladung (ETL) hinzugefügt. Beispiele 2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z | |||
| Quellsystem SourceSystem | Gibt an, aus welchem Quellsystem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut bezeichnet das Ursprungssystem der Ereignisdaten, zum Beispiel „SAP S/4HANA Production“ oder „SAP ECC“. In Umgebungen mit mehreren Systemen ist dieses Feld wichtig für die Datenherkunft, die Fehlerbehebung und die korrekte Interpretation von Daten aus unterschiedlichen Quellen. Es liefert Kontext zu den Daten und ermöglicht es, Analysen auf bestimmte Systemumgebungen zu beschränken. Warum das wichtig ist Liefert wichtigen Kontext zur Herkunft der Daten, der für Data Governance, Validierung und Analysen in Umgebungen mit mehreren Systemen entscheidend ist. Woher beziehen Üblicherweise ein statischer Wert, der während der Datenextraktion, -transformation und -ladung (ETL) hinzugefügt wird, um den Ursprung des Datensatzes zu kennzeichnen. Beispiele S4H_PROD_100ECC_EU_200S4H_US_300 | |||
| Angeforderter Liefertermin RequestedDeliveryDate | Das Datum, zu dem das Unternehmen die Lieferung der Waren oder Dienstleistungen angefordert hat. | ||
| Beschreibung Dieses Attribut gibt den in der Bestellung vereinbarten Liefertermin an. Er dient als Grundlage für die Messung der Lieferantenleistung. Im Process Mining wird dieses Datum mit dem tatsächlichen Wareneingangsdatum (Timestamp von „Wareneingang gebucht“) verglichen, um die Kennzahl „Pünktlichkeitsquote der Lieferanten“ zu berechnen. Abweichungen von diesem Datum helfen bei der Bewertung der Zuverlässigkeit von Lieferanten und beim Management von Risiken in der Lieferkette. Warum das wichtig ist Dient als Grundlage für die Messung der Pünktlichkeit von Lieferanten, einer wichtigen Kennzahl für das Lieferkettenmanagement und die betriebliche Planung. Woher beziehen Dieses Feld befindet sich in der Einteilungstabelle EKET, Feld EINDT. Beispiele 2023-06-012023-06-152023-07-01 | |||
| Benutzer UserName | Die Kennung des Benutzers, der eine bestimmte Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die SAP-Benutzer-ID der Person, die ein Dokument erstellt, geändert oder genehmigt hat. Dadurch lassen sich Aktionen im System nachvollziehen. Die Analyse nach Benutzern hilft, Schulungsbedarf, Arbeitsverteilung und individuelle Leistung zu erkennen. So lässt sich beispielsweise feststellen, ob bestimmte Benutzer regelmäßig mit langen Genehmigungszeiten oder häufigen Änderungen nach der Genehmigung verbunden sind. Diese Erkenntnisse können in die Ressourcenplanung und Prozessverbesserung einfließen. Warum das wichtig ist Schafft Verantwortlichkeit und ermöglicht Leistungsanalysen auf Ebene einzelner Personen oder Teams. So lassen sich Schulungsbedarf und Ressourcenengpässe erkennen. Woher beziehen Diese Information findet sich in Feldern wie ERNAM (Erstellt von) in EKKO oder im Benutzerfeld der Änderungsbelegtabelle (CDHDR-USERNAME). Beispiele CB9980000012JSMITHRROE | |||
| Bestellanforderung PurchaseRequisitionNumber | Die Kennung der Bestellanforderung (PR), aus der die Bestellung hervorgegangen ist. | ||
| Beschreibung Dieses Attribut verknüpft die Bestellung mit der ursprünglichen Bestellanforderung. Direkt erstellte Bestellungen haben nicht immer eine zugehörige Bestellanforderung. Diese Verknüpfung ist wichtig, um den gesamten Beschaffungsprozess von der ursprünglichen Anforderung an zu analysieren. Sie unterstützt Kennzahlen wie „Genehmigungszeit der Bestellanforderung“ und ist entscheidend, um nicht genehmigte Beschaffung zu erkennen, bei der Bestellungen ohne vorherige genehmigte Anforderung erstellt werden. Warum das wichtig ist Verknüpft die Bestellung mit der ursprünglichen Anforderung und ermöglicht so eine durchgängige Prozessanalyse sowie das Erkennen nicht konformer, nicht genehmigter Ausgaben. Woher beziehen Dieses Attribut befindet sich in der SAP-S/4HANA-Tabelle EKPO (Bestellposition), Feld BANFN. Beispiele 1001005110010052 | |||
| Bestellbelegart DocumentType | Eine Klassifizierung, die verschiedene Bestellarten unterscheidet, etwa Standardbestellungen, Dienstleistungsbestellungen oder Umlagerungsbestellungen. | ||
| Beschreibung Die Belegart ist ein wichtiges Konfigurationselement in SAP. Sie steuert den Prozessablauf, den Nummernkreis und die Felder einer Bestellung. Unternehmen können damit den Beschaffungsprozess an unterschiedliche Szenarien anpassen. Die Analyse nach Belegart ist entscheidend, um Prozessvarianten zu verstehen. Der Ablauf einer Standardbestellung für Waren kann sich beispielsweise deutlich von dem einer Dienstleistungsbestellung oder einer Umlagerung unterscheiden. Mit diesem Attribut lassen sich die verschiedenen Prozessabläufe filtern und vergleichen, um gezielte Verbesserungsmöglichkeiten zu finden. Warum das wichtig ist Kategorisiert Bestellungen und ermöglicht den Vergleich verschiedener Beschaffungsprozesse. So lassen sich Unterschiede bei Prozessabläufen und Durchlaufzeiten erklären. Woher beziehen Dieses Attribut befindet sich in der SAP-S/4HANA-Tabelle EKKO, Feld BSART. Beispiele NBFOUB | |||
| Gesamtnettobetrag TotalNetAmount | Der Gesamtwert der Bestellung ohne Steuern und Frachtkosten. | ||
| Beschreibung Dieses Attribut gibt den Nettogeldwert der Bestellung an. Es ist eine wichtige Finanzkennzahl, die den Umfang des Beschaffungsvorgangs zeigt. Der Betrag ist für Finanzanalysen entscheidend. So können Bestellungen nach Wert kategorisiert werden, etwa in hohe und niedrige Beträge, um unterschiedliche Prozessabläufe zu erkennen. Außerdem lässt sich die Analyse damit priorisieren, indem Sie sich auf Bestellungen mit hohem Wert konzentrieren, die ein größeres finanzielles Risiko oder stärkere Auswirkungen auf das Unternehmen mit sich bringen können. Warum das wichtig ist Ermöglicht finanzbezogene Analysen, mit denen Sie Bestellungen nach Wert aufschlüsseln und Prozessverbesserungen auf Bereiche mit hohen Ausgaben konzentrieren können. Woher beziehen Dieses Attribut befindet sich in der SAP-S/4HANA-Tabelle EKKO, Feld NETWR. Beispiele 1500.0025000.50125.75 | |||
| Lieferanten-ID VendorId | Die eindeutige Kennung des Lieferanten, der Waren oder Dienstleistungen bereitstellt. | ||
| Beschreibung Die Lieferanten-ID ist ein wichtiges Stammdatenattribut, das eine Bestellung mit einem bestimmten Lieferanten verknüpft. Sie wird während des gesamten Beschaffungsprozesses für Kommunikation, Lieferung und Zahlung verwendet. Im Process Mining ermöglicht dieses Attribut eine nach Lieferanten aufgeschlüsselte Leistungsanalyse. Es ist wichtig für Dashboards wie „Lieferzeit der Lieferanten“ und „Warenrücksendungen nach Lieferant“. Damit lassen sich zuverlässige Lieferanten ebenso erkennen wie solche, die möglicherweise Verzögerungen oder Qualitätsprobleme verursachen. Warum das wichtig ist Ermöglicht lieferantenbezogene Analysen, mit denen Sie die Leistung bewerten, besonders leistungsstarke und leistungsschwache Lieferanten erkennen und die Lieferkette optimieren können. Woher beziehen Dieses Attribut befindet sich in der SAP-S/4HANA-Tabelle EKKO, Feld LIFNR. Beispiele 100023100045100088 | |||
| Buchungskreis CompanyCode | Kennung der juristischen Person oder des Unternehmens, für das die Bestellung angelegt wird. | ||
| Beschreibung Der Buchungskreis ist eine eigenständige Rechnungslegungseinheit innerhalb einer Organisation. Alle Finanztransaktionen zu einer Bestellung werden einem bestimmten Buchungskreis zugeordnet. Dieses grundlegende Organisationsattribut ermöglicht es, Beschaffungsprozesse verschiedener juristischer Personen zu filtern und miteinander zu vergleichen. Eine Analyse nach Buchungskreis kann Unstimmigkeiten bei der Prozessausführung, unterschiedliche Effizienzgrade oder abweichende Compliance-Raten innerhalb der Organisation aufdecken. Warum das wichtig ist Ermöglicht eine nach juristischen Personen gegliederte Prozessanalyse und erleichtert so den Vergleich von Leistung und Compliance in verschiedenen Unternehmensbereichen. Woher beziehen Dieses Attribut befindet sich in der SAP-S/4HANA-Tabelle EKKO im Feld BUKRS. Beispiele 101017102000 | |||
| Einkäufergruppe PurchasingGroup | Gruppe von Einkäufern, die für bestimmte Beschaffungsaktivitäten zuständig ist. | ||
| Beschreibung Eine Einkäufergruppe besteht aus einem oder mehreren Einkäufern, die für bestimmte Einkaufsaktivitäten, Materialien oder Lieferanten zuständig sind. Sie sind die zentralen Ansprechpartner für Lieferanten. Mit diesem Attribut lässt sich die Arbeitsauslastung und Leistung detaillierter analysieren als auf Ebene der Einkaufsorganisation. So können Sie überlastete Teams erkennen, die Effizienz verschiedener Einkäufergruppen messen und feststellen, bei welchen Gruppen Prozessabweichungen wie nicht genehmigte Ausgaben häufiger auftreten. Warum das wichtig ist Ermöglicht eine detaillierte Betrachtung der Leistung von Einkäufergruppen und damit die Analyse von Arbeitsauslastung, Effizienz und Prozesseinhaltung auf Teamebene. Woher beziehen Dieses Attribut befindet sich in der SAP-S/4HANA-Tabelle EKKO im Feld EKGRP. Beispiele 001002N00 | |||
| Einkaufsorganisation PurchasingOrganization | Organisationseinheit, die für die Beschaffung von Materialien und Dienstleistungen sowie für Verhandlungen mit Lieferanten zuständig ist. | ||
| Beschreibung Die Einkaufsorganisation ist eine zentrale Organisationseinheit in der Beschaffung. Sie kann auf Konzern-, Unternehmens- oder Werksebene angesiedelt sein und verantwortet sämtliche Einkaufsaktivitäten. Eine Analyse nach Einkaufsorganisation hilft dabei, die Effizienz und Leistung verschiedener Beschaffungsteams oder Regionen zu bewerten. Sie kann Unterschiede bei Lieferantenverhandlungen, der Einhaltung von Prozessen oder Verzögerungen bei Freigaben zwischen Organisationseinheiten sichtbar machen. Warum das wichtig ist Ermöglicht den Leistungsvergleich zwischen verschiedenen Beschaffungsabteilungen oder Regionen und hilft dabei, bewährte Vorgehensweisen sowie Verbesserungspotenziale zu erkennen. Woher beziehen Dieses Attribut befindet sich in der SAP-S/4HANA-Tabelle EKKO im Feld EKORG. Beispiele 10101710US01 | |||
| Materialnummer MaterialNumber | Kennung des beschafften Materials oder Produkts. | ||
| Beschreibung Die Materialnummer ist ein eindeutiger Code für jeden Materialstammsatz in SAP. Sie wird für alle Transaktionen zu diesem Material verwendet, darunter Beschaffung, Bestandsverwaltung und Vertrieb. Eine Analyse nach Materialnummer oder Materialgruppe ermöglicht eine warengruppenbezogene Auswertung. Sie zeigt, ob die Beschaffung bestimmter Materialien weniger effizient ist, längere Durchlaufzeiten aufweist oder häufiger zu Rücksendungen führt. Diese Erkenntnisse unterstützen das Warengruppenmanagement. Warum das wichtig ist Ermöglicht eine warengruppenbezogene Analyse, mit der sich Prozessprobleme oder Leistungsschwächen von Lieferanten bei bestimmten Produkten oder Materialien erkennen lassen. Woher beziehen Dieses Attribut befindet sich in der SAP-S/4HANA-Tabelle EKPO im Feld MATNR. Beispiele RM100-100FG210SERV-CONSULT | |||
| Nacharbeit IsRework | Berechnetes Kennzeichen dafür, ob bei der Bestellung Nacharbeit erforderlich war, etwa aufgrund einer Änderung nach der Freigabe oder einer Warenrücksendung. | ||
| Beschreibung Dieses boolesche Attribut wird anhand der Aktivitätsabfolge für jede Bestellung berechnet. Es wird auf „true“ gesetzt, wenn nach dem Ereignis „Bestellung genehmigt“ das Ereignis „Bestellung geändert“ auftritt oder ein Ereignis „Waren zurückgesendet“ vorliegt. Das Kennzeichen vereinfacht die Berechnung der KPI „Straight-Through-Processing-Rate“. Damit lassen sich alle Bestellungen, die manuelle Eingriffe oder Korrekturen erforderten, einfach filtern und visualisieren. So können Kosten und Häufigkeit der Nacharbeit quantifiziert werden. Warum das wichtig ist Hilft, Ineffizienzen im Prozess zu quantifizieren, indem Fälle mit Nacharbeit gekennzeichnet werden. Das ist wichtig, um die Straight-Through-Processing-Rate zu berechnen und Ursachen für Abweichungen zu ermitteln. Woher beziehen Berechnetes Feld auf Grundlage der Aktivitätsabfolge. Die Logik prüft, ob auf eine Freigabe das Ereignis „Bestellung geändert“ folgt oder ob ein Ereignis „Waren zurückgesendet“ vorliegt. Beispiele truefalse | |||
| Nicht genehmigte Ausgaben IsMaverickSpend | Berechnetes Kennzeichen dafür, ob eine Bestellung ohne vorherige genehmigte Bestellanforderung angelegt wurde. | ||
| Beschreibung Dieses boolesche Kennzeichen wird bei der Datenverarbeitung abgeleitet. Es wird auf „true“ gesetzt, wenn einer Bestellung keine Bestellanforderung zugeordnet ist oder die Bestellung den standardmäßigen Freigabe-Workflow umgeht. Das Attribut unterstützt direkt das Dashboard „Erkennung nicht genehmigter Ausgaben“ und die zugehörigen KPIs. Es hilft dabei, das Ausmaß nicht konformer Beschaffung zu quantifizieren. So können Unternehmen gezielt Abteilungen oder Benutzergruppen ansprechen, um Beschaffungsrichtlinien und Kontrollen zu stärken. Warum das wichtig ist Kennzeichnet nicht konforme Beschaffung direkt. So lassen sich Prozessabweichungen quantifizieren und Finanzkontrollen sowie Beschaffungsrichtlinien durchsetzen. Woher beziehen Berechnetes Feld, das auf einem fehlenden Wert in „PurchaseRequisitionNumber“ bei bestimmten Belegarten oder auf der Analyse der Ereignisabfolge basiert. Beispiele truefalse | |||
| Positionsart ItemCategory | Klassifiziert eine Bestellposition, zum Beispiel als Standardposition, Konsignation, Lohnbearbeitung oder Dienstleistung. | ||
| Beschreibung Die Positionsart legt fest, wie die Beschaffung eines bestimmten Materials oder einer Dienstleistung gesteuert und abgewickelt wird. Sie beeinflusst nachfolgende Schritte wie Wareneingang und Rechnungsprüfung. Dieses Attribut ist wichtig, um Prozessvarianten nach Art der Beschaffung zu analysieren. Der Ablauf für eine Dienstleistungsposition, für die ein Leistungserfassungsblatt erforderlich ist, unterscheidet sich beispielsweise deutlich von dem für eine Standardlagerposition. Die Analyse nach Positionsart hilft, diese Unterschiede zu verstehen und gezielte Prozessverbesserungen umzusetzen. Warum das wichtig ist Erläutert Prozessvarianten, indem zwischen verschiedenen Beschaffungsarten wie Waren, Dienstleistungen und Fremdbearbeitung unterschieden wird. Woher beziehen Dieses Attribut befindet sich in der SAP-S/4HANA-Tabelle EKPO im Feld PSTYP. Beispiele 093 | |||
| Pünktliche Lieferung durch Lieferanten SupplierOnTimeDelivery | Berechnetes Kennzeichen dafür, ob der Wareneingang am angeforderten Liefertermin oder früher gebucht wurde. | ||
| Beschreibung Dieses boolesche Attribut wird ermittelt, indem der Timestamp der Aktivität „Wareneingang gebucht“ mit dem „Angeforderten Liefertermin“ verglichen wird. Erfolgt der Wareneingang am angeforderten Termin oder früher, wird das Attribut auf „true“ gesetzt. Das Attribut unterstützt direkt die KPI „Pünktliche Lieferungen durch Lieferanten“. Es vereinfacht die Analyse, da Benutzer pünktliche und verspätete Lieferungen gezielt filtern können. Das ist wichtig für Dashboards zur Lieferantenleistung und Lieferantenbewertungen. Warum das wichtig ist Misst direkt die Zuverlässigkeit von Lieferanten. Damit bildet das Attribut die Grundlage für die KPI zur pünktlichen Lieferung und unterstützt ein wirksames Lieferantenmanagement. Woher beziehen Berechnet durch den Vergleich des Timestamps der Aktivität „Wareneingang gebucht“ mit dem Attribut „RequestedDeliveryDate“. Beispiele truefalse | |||
| Werk Plant | Betriebsstätte oder Standort, an den die Waren geliefert oder an dem die Dienstleistungen erbracht werden. | ||
| Beschreibung In SAP ist ein Werk ein physischer Standort, an dem Waren produziert oder gelagert beziehungsweise Dienstleistungen erbracht werden. Es ist ein wichtiges Element für Logistik und Planung. Eine nach Werk gegliederte Prozessanalyse kann regionale oder standortspezifische Unterschiede in der Beschaffung aufzeigen. So lässt sich beispielsweise feststellen, ob bestimmte Werke längere Lieferzeiten oder höhere Warenrückgabequoten aufweisen. Das kann auf lokale Probleme in der Logistik oder Qualitätskontrolle hindeuten. Warum das wichtig ist Ermöglicht eine standortbezogene Analyse und macht Leistungsunterschiede zwischen Betriebsstätten, Werken oder Lagern sichtbar. Woher beziehen Dieses Attribut befindet sich in der SAP-S/4HANA-Tabelle EKPO im Feld WERKS. Beispiele 10101710DE01 | |||
Aktivitäten im Purchase-to-Pay-Prozess mit Bestellungen
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Bestellanforderung erstellt | Diese Aktivität dokumentiert die formelle Anforderung von Waren oder Dienstleistungen und leitet den Beschaffungsprozess ein. Das Ereignis wird ausdrücklich erfasst, wenn ein Benutzer ein neues Bestellanforderungsdokument speichert, zum Beispiel über die Transaktion ME51N. | ||
| Warum das wichtig ist Für viele Bestellprozesse ist dies der zentrale Startpunkt. Die Zeitspanne zwischen diesem Ereignis und der Erstellung der Bestellung zeigt Verzögerungen bei der Beschaffung und der internen Bearbeitung auf. Woher beziehen Erfasst in der Tabelle EBAN (Bestellanforderung). Der Timestamp der Erstellung ist in den Änderungshistorientabellen CDHDR und CDPOS für das Objekt EBAN zu finden. Erfassung Ereignis, das bei der Erstellung eines Dokuments in der Tabelle EBAN erfasst wird. Ereignistyp explicit | |||
| Bestellanforderung genehmigt | Bezeichnet die formelle Genehmigung einer Bestellanforderung durch eine Führungskraft oder eine zuständige genehmigende Person. Sie wird üblicherweise aus einer Statusänderung im Anforderungsdokument abgeleitet und zeigt an, dass die Anforderung in eine Bestellung umgewandelt werden kann. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein dient dazu, Genehmigungszeiten zu verfolgen und Engpässe zu erkennen. Verzögerungen wirken sich direkt darauf aus, wie schnell eine Bestellung erstellt und an einen Lieferanten gesendet werden kann. Woher beziehen Abgeleitet aus den Freigabestatusfeldern in der Tabelle EBAN, zum Beispiel FRGZU (Freigabekennzeichen). Der Timestamp stammt aus den Änderungsbelegen (CDHDR/CDPOS), in denen die endgültige Freigabe dokumentiert ist. Erfassung Abgeleitet aus den Änderungsprotokollen (CDHDR/CDPOS) zu den Freigabestatusfeldern in der Tabelle EBAN. Ereignistyp inferred | |||
| Bestellung abgeschlossen | Diese Aktivität zeigt an, dass eine Bestellposition aus logistischer Sicht als abgeschlossen gilt. Sie wird abgeleitet, wenn sowohl das Kennzeichen „Lieferung abgeschlossen“ als auch das Kennzeichen „Endrechnung“ gesetzt sind. | ||
| Warum das wichtig ist Dies ist der Endpunkt für die Analyse des Bestelllebenszyklus. Die Zeit bis zu diesem Ereignis entspricht der durchgängigen Durchlaufzeit der Beschaffung. Woher beziehen Abgeleitet aus den Statuskennzeichen der Bestellpositionstabelle EKPO. Das Ereignis tritt ein, wenn sowohl das Kennzeichen „Lieferung abgeschlossen“ (ELIKZ) als auch das Kennzeichen „Endrechnung“ (EREKZ) auf „wahr“ gesetzt sind. Erfassung Abgeleitet aus Änderungsprotokollen, wenn die EKPO-Felder ELIKZ und EREKZ beide als abgeschlossen gekennzeichnet sind. Ereignistyp inferred | |||
| Bestellung erstellt | Dokumentiert die Erstellung des offiziellen Bestelldokuments, mit oder ohne Bezug zu einer Bestellanforderung. Das Ereignis wird ausdrücklich erfasst, sobald das Bestelldokument erstmals im System gespeichert wird. | ||
| Warum das wichtig ist Diese Aktivität kann als alternativer Startpunkt des Prozesses dienen, insbesondere bei der Analyse nicht genehmigter Beschaffung. Sie ist ein grundlegendes Ereignis, um die gesamte Bearbeitungszeit der Bestellung zu verfolgen. Woher beziehen Erfasst in der Bestellkopftabelle EKKO. Das Erstellungsdatum (AEDAT) und die Uhrzeit des Dokuments sind direkt in dieser Tabelle gespeichert. Erfassung Erstellungs-Timestamp (AEDAT) des Bestelldokuments in der Tabelle EKKO. Ereignistyp explicit | |||
| Bestellung genehmigt | Zeigt an, dass alle erforderlichen internen Genehmigungen für die Bestellung vorliegen und sie an den Lieferanten freigegeben werden darf. Das Ereignis wird aus einer Statusänderung in der Freigabestrategie der Bestellung abgeleitet. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein dient dazu, die Effizienz der Genehmigung und die Nacharbeit nach der Genehmigung zu messen. Die Zeit zwischen Erstellung und Genehmigung der Bestellung macht interne Verzögerungen sichtbar. Woher beziehen Abgeleitet aus dem Freigabekennzeichen (FRGKE) in der Tabelle EKKO. Der Timestamp wird anhand der Änderungshistorie (CDHDR/CDPOS) ermittelt, die dokumentiert, wann dieses Feld auf den Status „freigegeben“ gesetzt wurde. Erfassung Abgeleitet aus den Änderungsprotokollen zum Freigabekennzeichen (FRGKE) in der Tabelle EKKO. Ereignistyp inferred | |||
| Rechnung eingegangen | Bezeichnet die Erfassung einer Lieferantenrechnung im SAP-System und ihre Verknüpfung mit der zugehörigen Bestellung. Diese ausdrückliche Finanzbuchung erzeugt einen Buchhaltungsbeleg. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein verbindet den Beschaffungsprozess mit der Kreditorenbuchhaltung. Er ermöglicht die Analyse der Zeit zwischen Wareneingang und Rechnungsverarbeitung. Woher beziehen Ein Buchhaltungsbeleg wird in der Tabelle BKPF (Kopf) erstellt. Die Positionen befinden sich in BSEG oder im Universal Journal ACDOCA. Der Beleg ist in der Tabelle RSEG mit der Bestellung verknüpft. Erfassung Erfassungsdatum des Belegs (CPUDT) aus der Buchhaltungsbelegkopftabelle BKPF. Ereignistyp explicit | |||
| Wareneingang gebucht | Bezeichnet den physischen Eingang der Waren vom Lieferanten und die entsprechende Buchung im System. Diese Transaktion aktualisiert ausdrücklich die Bestellhistorie. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein beendet die Lieferzeit des Lieferanten und leitet die interne Rechnungsprüfung ein. Er ist für die Ermittlung der Pünktlichkeitsquote von Lieferungen unerlässlich. Woher beziehen Erfasst als Materialbeleg in den Tabellen MKPF (Kopf) und MSEG (Position) und über eine bestimmte Bewegungsart, zum Beispiel 101, mit der Bestellhistorie in der Tabelle EKBE verknüpft. Erfassung Buchungsdatum (BUDAT) aus dem Materialbelegkopf (MKPF), verknüpft über EKBE. Ereignistyp explicit | |||
| Bestellung an Lieferanten gesendet | Bezeichnet den Zeitpunkt, zu dem die Bestellung an den Lieferanten übermittelt wird, zum Beispiel per EDI, E-Mail oder Ausdruck. Dieses Ereignis wird häufig in den Protokollen der Ausgabeverwaltung des Systems erfasst. | ||
| Warum das wichtig ist Mit dieser Aktivität beginnt die Lieferzeit des Lieferanten. Sie ist entscheidend, um die Lieferantenleistung ab dem Zeitpunkt des Auftragseingangs korrekt zu messen. Woher beziehen Erfasst in der Ausgabesteuertabelle NAST, in der die für ein Einkaufsdokument gesendeten Mitteilungen protokolliert werden. Datum und Uhrzeit der relevanten Ausgabeart, zum Beispiel EDI oder E-Mail, können verwendet werden. Erfassung Timestamp der ersten erfolgreich gesendeten Ausgabemitteilung zur Bestellung in der Tabelle NAST. Ereignistyp inferred | |||
| Bestellung geändert | Diese Aktivität zeigt an, dass die Bestellung nach ihrer ursprünglichen Erstellung geändert wurde, zum Beispiel hinsichtlich Menge, Preis oder Liefertermin. Die Änderung wird ausdrücklich in den Systemprotokollen erfasst. | ||
| Warum das wichtig ist Änderungen zu verfolgen, insbesondere nach der Genehmigung, ist entscheidend, um Ineffizienzen, Nacharbeit und mögliche Compliance-Probleme zu erkennen. Häufige Änderungen können auf ungenaue ursprüngliche Angaben hindeuten. Woher beziehen Erfasst in den Änderungsbelegt Tabellen CDHDR (Kopf) und CDPOS (Position) für Bestellobjekte (EINKBELEG). Jede Änderung erzeugt einen detaillierten Protokolleintrag. Erfassung Ereignis, das bei Änderungen wichtiger Felder in den Tabellen EKKO oder EKPO protokolliert und in CDHDR/CDPOS erfasst wird. Ereignistyp explicit | |||
| Bestellung gelöscht | Bezeichnet die Stornierung oder logische Löschung einer Bestellposition oder des gesamten Dokuments. Dies wird erfasst, wenn ein Benutzer das Löschkennzeichen im Dokument setzt. | ||
| Warum das wichtig ist Diese Aktivität ist ein alternativer Endpunkt des Prozesses und weist auf einen Abbruch oder eine Stornierung hin. Die Analyse der Gründe für gelöschte Bestellungen kann Probleme in der Bedarfsplanung oder bei der Definition von Anforderungen aufdecken. Woher beziehen Erfasst über das Löschkennzeichen (LOEKZ) in den Tabellen für den Bestellkopf (EKKO) oder die Bestellposition (EKPO). Der Timestamp stammt aus den Änderungsbelegen (CDHDR/CDPOS). Erfassung Timestamp aus den Änderungsbelegen (CDHDR/CDPOS), wenn das Löschkennzeichen (LOEKZ) gesetzt wird. Ereignistyp explicit | |||
| Leistungsbestätigung erfasst | Diese Aktivität dokumentiert die Bestätigung, dass eine in einer Bestellung aufgeführte Dienstleistung erbracht wurde. Sie wird ausdrücklich durch die Erstellung eines Leistungserfassungsblatts erfasst. | ||
| Warum das wichtig ist Bei der Beschaffung von Dienstleistungen entspricht dies einem Wareneingang. Die Aktivität ist entscheidend, um Leistungsfristen zu verfolgen und Lieferanten rechtzeitig zu bezahlen. Woher beziehen Erfasst durch die Erstellung eines Leistungserfassungsblatts. Die Daten sind in den Tabellen ESSR (Kopf) und ESLL (Positionen) gespeichert. Das Erstellungsdatum dient als Timestamp. Erfassung Erstellungsdatum des Leistungserfassungsblatts in der Tabelle ESSR. Ereignistyp explicit | |||
| Rechnung bezahlt | Bezeichnet den endgültigen Ausgleich der Lieferantenrechnung durch einen Zahlungslauf oder eine manuelle Zahlung. Diese ausdrückliche Finanztransaktion erzeugt einen Ausgleichsbeleg. | ||
| Warum das wichtig ist Obwohl diese Aktivität technisch zum Zahlungsprozess gehört, ermöglicht sie einen vollständigen Überblick über den Beschaffungs- und Zahlungszyklus. Sie ist wichtig für die Analyse von Zahlungsbedingungen und Zahlungsleistung. Woher beziehen Die Zahlung wird als Ausgleichsbeleg in BKPF/ACDOCA erfasst. Das Ausgleichsdatum (AUGDT) der Rechnungsposition in BSEG oder ACDOCA kennzeichnet das Zahlungsereignis. Erfassung Ausgleichsdatum (AUGDT) des Rechnungsbelegs in BSEG oder ACDOCA. Ereignistyp explicit | |||
| Waren zurückgesendet | Zeigt an, dass zuvor erhaltene Waren an den Lieferanten zurückgesendet wurden, üblicherweise aufgrund von Qualitätsmängeln, Beschädigungen oder falschen Lieferungen. Dies wird ausdrücklich als Warenbewegung zur Stornierung erfasst. | ||
| Warum das wichtig ist Diese Aktivität macht Nacharbeit und mögliche Probleme mit der Lieferantenqualität oder der Bestellgenauigkeit sichtbar. Häufige Rücksendungen bei einem bestimmten Lieferanten oder Material weisen auf ein Problem hin. Woher beziehen Erfasst als Materialbeleg mit einer bestimmten Rücklieferungsbewegungsart, zum Beispiel 122. Das Ereignis wird in MKPF/MSEG protokolliert und in der Historientabelle EKBE mit der Bestellung verknüpft. Erfassung Buchungsdatum des Materialbelegs mit Rücklieferungsbewegungsart in EKBE. Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
- Voraussetzungen und Zugriff: Stellen Sie sicher, dass Sie über einen Benutzer mit den erforderlichen Berechtigungen zum Abfragen von Core Data Services (CDS)-Views im SAP-S/4HANA-System verfügen. Der Zugriff kann über SAP HANA Studio, ABAP Development Tools (ADT) für Eclipse oder ein Datenextraktionstool eines Drittanbieters erfolgen, das SQL-Verbindungen zur SAP-HANA-Datenbank unterstützt.
- Verbindungsdaten des Systems ermitteln: Beschaffen Sie die erforderlichen Verbindungsparameter für Ihr SAP-S/4HANA-System, darunter Host, Instanznummer und Ihre Anmeldedaten.
- Mit der Datenbank verbinden: Stellen Sie mit dem SQL-Client Ihrer Wahl eine Verbindung zur SAP-S/4HANA-Datenbank her, in der sich die CDS-Views befinden.
- SQL-Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus dem Abfrageabschnitt dieses Dokuments in Ihren SQL-Editor. Die Abfrage extrahiert alle erforderlichen Aktivitäten und Attribute.
- Filterparameter festlegen: Suchen Sie die Platzhalterwerte in der Abfrage. Ersetzen Sie _start_date und _end_date durch den gewünschten Zeitraum für Ihre Analyse, zum Beispiel '20230101' und '20231231'. Passen Sie den Filter poh.CompanyCode so an, dass er die zu analysierenden Buchungskreise enthält.
- Abfrage ausführen: Führen Sie die angepasste SQL-Abfrage für die S/4HANA-Datenbank aus. Je nach Datenmenge und gewähltem Zeitraum kann die Ausführung einige Zeit dauern.
- Erste Ergebnisse prüfen: Prüfen Sie nach Abschluss der Abfrage kurz die Ausgabe in Ihrem SQL-Client. Kontrollieren Sie, ob verschiedene Aktivitäten enthalten sind, die Timestamps korrekt befüllt wurden und die Case-ID (PurchaseOrderNumber) einheitlich ist.
- Daten exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Tool in eine CSV-Datei (Comma Separated Values). Verwenden Sie UTF-8, um Probleme mit Zeichenkodierungen zu vermeiden.
- Upload vorbereiten: Öffnen Sie vor dem Upload zu ProcessMind die CSV-Datei und prüfen Sie, ob die Spaltenüberschriften exakt mit den in den Datenanforderungen definierten Attributen übereinstimmen (PurchaseOrderNumber, ActivityName, EventTime usw.). Passen Sie Spaltennamen an, falls Ihr Exporttool sie geändert hat.
- Upload zu ProcessMind: Laden Sie die fertige CSV-Datei in Ihr ProcessMind-Projekt hoch. Ordnen Sie beim Import die Spalten Ihrer Datei den entsprechenden Feldern für Case-ID, Aktivität und Timestamp zu.
Konfiguration
- Verwendete CDS-Views: Die Extraktionslogik basiert auf mehreren standardisierten CDS-Views mit umfangreicher Semantik. Dazu gehören insbesondere:
- I_PurchaseOrderItemAPI01: Kerndaten zu Bestellpositionen.
- I_PurchaseRequisitionItemAPI01: Details zu Bestellanforderungen.
- I_MaterialDocumentItem: Warenbewegungen wie Wareneingänge und Retouren.
- I_ServiceEntrySheetAPI01: Ereignisse zu Leistungsbestätigungen.
- I_SupplierInvoiceAPI01: Informationen zu Lieferantenrechnungen.
- I_OperationalAcctgDocItem: Verknüpfung von Rechnungen mit Finanzbelegen zur Nachverfolgung von Zahlungen.
- I_ChangeDocument: Änderungen an Bestellungen.
- Filter für den Zeitraum: Ein Datumsfilter ist entscheidend, um Leistung und Datenvolumen zu steuern. Die Abfrage verwendet die Platzhalter _start_date und _end_date für das Anlagedatum der Bestellung (PurchaseOrderDate). Als erster Zeitraum empfehlen sich drei bis sechs Monate.
- Filter nach Organisation: Die Abfrage sollte immer nach CompanyCode gefiltert werden, damit nur relevante Geschäftseinheiten extrahiert werden. Für eine genauere Eingrenzung können Sie in der CTE PO_base zusätzlich nach PurchaseOrderType oder PurchasingOrganization filtern.
- Voraussetzungen: Der ausführende Benutzer benötigt SELECT-Berechtigungen für alle oben aufgeführten CDS-Views. Der Zugriff auf diese Views wird in S/4HANA üblicherweise über bestimmte Geschäfts- oder Analyse-Rollen gewährt. Ohne die erforderlichen Berechtigungen schlägt die Abfrage fehl.
a Beispielabfrage sql
WITH PO_base AS (
SELECT
poh.PurchaseOrder AS PurchaseOrderNumber,
poi.PurchaseOrderItem AS PurchaseOrderItem,
poh.CompanyCode,
poh.PurchaseOrderType AS DocumentType,
poh.Supplier AS VendorId,
poh.PurchaseOrderDate,
poi.PurchaseRequisition AS PurchaseRequisitionNumber,
poi.NetPriceAmount * poi.OrderQuantity AS TotalNetAmount, -- Note: This is item-level net amount
poh.CreationDate AS POCreationDate,
poh.CreationTime AS POCreationTime,
poh.LastChangeDateTime AS POLastChangeDateTime,
poi.IsDeleted,
poi.DeliveryIsCompleted,
poi.FinalInvoiceIsExpected,
poi.GoodsReceiptIsExpected,
poi.LastGoodsReceiptDate,
poi.LastInvoiceReceiptDate
FROM I_PurchaseOrderAPI01 poh
JOIN I_PurchaseOrderItemAPI01 poi
ON poh.PurchaseOrder = poi.PurchaseOrder
WHERE
poh.PurchaseOrderDate BETWEEN '_start_date' AND '_end_date' -- Placeholder: e.g., '20230101' and '20230630'
AND poh.CompanyCode IN ('[YourCompanyCode]') -- Placeholder: e.g., '1010'
)
-- 1. Purchase Requisition Created
SELECT
po.PurchaseOrderNumber,
'Purchase Requisition Created' AS ActivityName,
CAST(CONCAT(pr.CreationDate, 'T', pr.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem, -- Placeholder
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
pr.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate, -- Available in PR, add if needed
po.DocumentType
FROM I_PurchaseRequisitionItemAPI01 pr
JOIN PO_base po
ON pr.PurchaseRequisition = po.PurchaseRequisitionNumber AND pr.PurchaseRequisitionItem = po.PurchaseOrderItem
UNION ALL
-- 2. Purchase Requisition Approved
SELECT
po.PurchaseOrderNumber,
'Purchase Requisition Approved' AS ActivityName,
CAST(CONCAT(pr.PurReqnReleaseDate, 'T', '000000') AS TIMESTAMP) AS EventTime, -- Time is not available in this view
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- Approver info requires complex joins
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_PurchaseRequisitionItemAPI01 pr
JOIN PO_base po
ON pr.PurchaseRequisition = po.PurchaseRequisitionNumber AND pr.PurchaseRequisitionItem = po.PurchaseOrderItem
WHERE
pr.PurReqnReleaseDate IS NOT NULL
UNION ALL
-- 3. Purchase Order Created
SELECT
po.PurchaseOrderNumber,
'Purchase Order Created' AS ActivityName,
CAST(CONCAT(po.POCreationDate, 'T', po.POCreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
poh.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
UNION ALL
-- 4. Purchase Order Approved
SELECT DISTINCT
po.PurchaseOrderNumber,
'Purchase Order Approved' AS ActivityName,
CAST(poh.ReleaseDate AS TIMESTAMP) AS EventTime, -- Assuming ReleaseDate reflects final approval
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- Approver info requires complex joins
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
WHERE poh.ReleaseDate IS NOT NULL
UNION ALL
-- 5. Purchase Order Sent to Vendor
SELECT DISTINCT
po.PurchaseOrderNumber,
'Purchase Order Sent to Vendor' AS ActivityName,
CAST(poh.ReleaseDate AS TIMESTAMP) AS EventTime, -- Using ReleaseDate as a proxy for sending time
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
WHERE poh.ReleaseDate IS NOT NULL
UNION ALL
-- 6. Purchase Order Changed
SELECT DISTINCT
ch.OBJECTID AS PurchaseOrderNumber,
'Purchase Order Changed' AS ActivityName,
CAST(CONCAT(ch.ChangeDocumentDate, 'T', ch.ChangeDocumentTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
ch.UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_ChangeDocument ch
JOIN PO_base po ON ch.OBJECTID = po.PurchaseOrderNumber
WHERE
ch.ObjectClassName = 'EINKBELEG' -- Object Class for Purchase Documents
AND CAST(CONCAT(ch.ChangeDocumentDate, 'T', ch.ChangeDocumentTime) AS TIMESTAMP) > CAST(CONCAT(po.POCreationDate, 'T', po.POCreationTime) AS TIMESTAMP)
UNION ALL
-- 7. Goods Receipt Posted
SELECT
po.PurchaseOrderNumber,
'Goods Receipt Posted' AS ActivityName,
CAST(CONCAT(md.PostingDate, 'T', md.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
md.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_MaterialDocumentItem md
JOIN PO_base po
ON md.PurchaseOrder = po.PurchaseOrderNumber AND md.PurchaseOrderItem = po.PurchaseOrderItem
WHERE
md.GoodsMovementType = '101'
UNION ALL
-- 8. Services Confirmation Entered
SELECT
po.PurchaseOrderNumber,
'Services Confirmation Entered' AS ActivityName,
CAST(se.PostingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
se.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_ServiceEntrySheetAPI01 se
JOIN PO_base po
ON se.PurchaseOrder = po.PurchaseOrderNumber AND se.PurchaseOrderItem = po.PurchaseOrderItem
UNION ALL
-- 9. Goods Returned
SELECT
po.PurchaseOrderNumber,
'Goods Returned' AS ActivityName,
CAST(CONCAT(md.PostingDate, 'T', md.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
md.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_MaterialDocumentItem md
JOIN PO_base po
ON md.PurchaseOrder = po.PurchaseOrderNumber AND md.PurchaseOrderItem = po.PurchaseOrderItem
WHERE
md.GoodsMovementType = '122'
UNION ALL
-- 10. Invoice Received
SELECT
po.PurchaseOrderNumber,
'Invoice Received' AS ActivityName,
CAST(inv.PostingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
inv.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_SupplierInvoiceAPI01 inv
JOIN PO_base po
ON inv.PurchaseOrderReference = po.PurchaseOrderNumber
WHERE
inv.DebitCreditCode = 'H' -- 'H' for Credit (Supplier Invoice)
UNION ALL
-- 11. Invoice Paid
SELECT
po.PurchaseOrderNumber,
'Invoice Paid' AS ActivityName,
CAST(doc.ClearingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
doc.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_SupplierInvoiceAPI01 inv
JOIN I_OperationalAcctgDocItem doc
ON inv.AccountingDocument = doc.AccountingDocument
JOIN PO_base po
ON inv.PurchaseOrderReference = po.PurchaseOrderNumber
WHERE
doc.IsCleared = 'X' AND doc.ClearingDate IS NOT NULL
UNION ALL
-- 12. Purchase Order Completed
SELECT
po.PurchaseOrderNumber,
'Purchase Order Completed' AS ActivityName,
CAST(GREATEST(po.LastGoodsReceiptDate, po.LastInvoiceReceiptDate) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
'SYSTEM' AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
WHERE
po.DeliveryIsCompleted = 'X'
AND (po.FinalInvoiceIsExpected = 'X' OR po.GoodsReceiptIsExpected = '') -- Logic for completion
AND GREATEST(po.LastGoodsReceiptDate, po.LastInvoiceReceiptDate) IS NOT NULL
UNION ALL
-- 13. Purchase Order Deleted
SELECT
po.PurchaseOrderNumber,
'Purchase Order Deleted' AS ActivityName,
CAST(po.POLastChangeDateTime AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- User who set the flag is in change docs
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
WHERE
po.IsDeleted = 'X' Schritte
- Prüfen Sie, ob direkter SQL-Zugriff auf das SAP-HANA-Schema mit EKKO und EKPO verfügbar ist, und beschaffen Sie die erforderlichen Leseberechtigungen. Ersetzen Sie Schema- und Verbindungsplatzhalter durch die für Ihr System konfigurierten Werte.
- Legen Sie den Extraktionszeitraum mit [Start timestamp] und [End timestamp] fest. Für den ersten Ladevorgang empfehlen sich drei bis sechs Monate. Filtern Sie nach Buchungskreis und Belegart nur, wenn der Berichtsumfang dies erfordert.
- Ermitteln Sie die Bestellungen in EKKO und EKPO. Übernehmen Sie Bestellnummer, Lieferant, Belegart, Buchungskreis, Anlagedatum, Anlagezeit und Attribute auf Positionsebene. Summieren Sie die Nettowerte aus EKPO, um TotalNetAmount auf Bestellebene zu berechnen.
- Extrahieren Sie die Ereignisse zur Anlage und Freigabe von Bestellanforderungen aus EBAN. Verknüpfen Sie die Anforderungen anhand der in EKPO verfügbaren Bestellanforderungsnummer und Positionsreferenz mit den Bestellungen. Da Freigabeindikatoren und Timestamps je nach Release-Konfiguration variieren, richten Sie die Ausdrücke für Freigabestatus und Timestamp anhand der aktiven SAP-Freigabestrategie unter [Configure based on your system] ein.
- Extrahieren Sie Ereignisse zur Anlage, Freigabe, Änderung, Löschung und zum Abschluss von Bestellungen. Für die Anlage verwenden Sie Anlagedatum und Anlagezeit aus EKKO. Für Freigabe, Änderung und Löschung sind Quellen zur Freigabe- oder Änderungshistorie erforderlich. Konfigurieren Sie die entsprechenden Quellausdrücke mit [Your table name] und [Your column name], wenn die relevanten Daten in dem ausgewählten Schema nicht verfügbar sind.
- Extrahieren Sie Ereignisse zu Lieferantenkommunikation, Wareneingang, Leistungsbestätigung, Warenretoure, Rechnungseingang und Rechnungszahlung aus den jeweils passenden Quellen für Ausgaben, Materialbelege, Leistungserfassungsblätter, Rechnungen, Buchhaltung und Ausgleich. Die Abfrage enthält ausdrücklich Platzhalter für systemspezifische Objekte, da EKKO und EKPO allein diese Quellen nicht abbilden.
- Überführen Sie alle Quellereignisse in dieselbe Event-Log-Struktur. Jede Zeile muss PurchaseOrderNumber, ActivityName, EventTime, SourceSystem, LastDataUpdate, VendorId, UserName, TotalNetAmount, PurchaseRequisitionNumber, RequestedDeliveryDate und DocumentType enthalten. Übernehmen Sie mehrere Vorkommen einer Aktivität, wenn die Quelle mehrere gültige Ereignisse enthält.
- Prüfen Sie die Timestamps, entfernen Sie ausschließlich exakt doppelte Quellzeilen und leiten Sie keine Aktivitäten ohne Quelldatensatz ab. ProcessMind liest das Event Log unverändert ein. Daher muss jede in der Prozessvisualisierung angezeigte Aktivität als eigene Zeile enthalten sein.
- Exportieren Sie das Ergebnis als Datei mit Trennzeichen oder als Datenbank-Ergebnismenge mit einer Kopfzeile und stabilen Spaltennamen. Verwenden Sie ein Timestamp-Format, das von der ProcessMind-Upload-Konfiguration unterstützt wird, speichern Sie PurchaseOrderNumber als Text und laden Sie das vollständige Event Log über die konfigurierte ProcessMind-Datenverbindung hoch.
Konfiguration
- Quellobjekte: EKKO und EKPO sind die bestätigten Quellen für Bestellkopf- und Bestellpositionsdaten. Weitere Objekte für Bestellanforderungen, Freigabestatus, Änderungshistorie, Ausgaben, Warenbewegungen, Leistungserfassungsblätter, Rechnungen, Zahlungen und Ausgleich müssen entsprechend dem SAP-S/4HANA-Release und dem aktiven Datenmodell konfiguriert werden.
- Case-ID: Verwenden Sie PurchaseOrderNumber als Case-ID. Ordnen Sie Ereignisse auf Positionsebene der Bestellnummer zu. Falls erforderlich, übernehmen Sie Positionsreferenzen in einer zusätzlichen quellenspezifischen Spalte.
- Zeitraum: Beginnen Sie mit drei bis sechs Monaten. Verarbeiten Sie historische Daten in kleineren Zeiträumen und gleichen Sie überlappende Grenzen ab, damit keine Daten fehlen.
- Filter: Konfigurieren Sie Filter für Company Code, Document Type, VendorId, Einkaufsorganisation, Einkäufergruppe und Ereignisdatum entsprechend dem benötigten Umfang. Die Filter für Buchungskreis und Belegart müssen gültige Werte des Zielsystems verwenden.
- Ereignissemantik: Anlage und Löschung lassen sich explizit abbilden, wenn die entsprechenden Belegfelder oder Protokolle verfügbar sind. Freigabe und Abschluss sind statusbasierte Ereignisse und erfordern konfigurierte Status-Timestamps. Erstellen Sie keine Zeilen allein anhand eines aktuellen Status, wenn kein belastbarer Ereignis-Timestamp vorliegt.
- Leistung: Filtern Sie früh nach Ereignisdatum und Organisationsbereich. Summieren Sie EKPO möglichst vor dem Verknüpfen mit Ereignisquellen und führen Sie umfangreiche historische Ladevorgänge in Zeitabschnitten aus. Sorgen Sie für geeignete Datenbankstatistiken und vermeiden Sie uneingeschränkte Verknüpfungen zwischen Positions-, Buchhaltungs- und Änderungshistorienquellen.
- Aktualisierungszeitpunkt: Setzen Sie LastDataUpdate für jede Zeile eines Laufs auf den Ausführungszeitpunkt der Extraktion.
- Voraussetzungen: Erforderlich sind eine Verbindung zu SAP HANA, Leseberechtigungen für alle konfigurierten Quellobjekte, Zugriff auf die relevanten Daten aus Einkauf, Bestandsführung, Dienstleistungsbeschaffung, Rechnungsprüfung und Kreditorenbuchhaltung sowie eine ProcessMind-Verbindung, über die die ausgewählte Datei oder Ergebnismenge importiert werden kann.
- Systemspezifische Konfiguration: Ersetzen Sie jeden in eckigen Klammern stehenden Quellenplatzhalter in der Abfrage durch eine freigegebene Tabelle, View, Spalte oder einen Ausdruck aus dem SAP-S/4HANA-Zielsystem. Geben Sie keine Anmeldedaten in der Abfrage oder Extraktionskonfiguration an.
a Beispielabfrage sql
WITH
params AS (
SELECT
CAST('[Start timestamp]' AS TIMESTAMP) AS start_ts,
CAST('[End timestamp]' AS TIMESTAMP) AS end_ts,
CAST(CURRENT_TIMESTAMP AS TIMESTAMP) AS last_data_update,
CAST('[Source system]' AS NVARCHAR(100)) AS source_system
FROM DUMMY
),
po_base AS (
SELECT
h.MANDT,
h.EBELN AS PurchaseOrderNumber,
h.LIFNR AS VendorId,
h.BSART AS DocumentType,
h.BUKRS AS CompanyCode,
CAST(h.AEDAT AS DATE) AS POChangedDate,
CAST(h.AEDAT AS TIMESTAMP) AS POChangedTimestamp,
CAST(h.ERNAM AS NVARCHAR(100)) AS POCreatedBy,
CAST(h.BEDAT AS DATE) AS PODate,
CAST(h.EBELN AS NVARCHAR(20)) AS PurchaseOrderKey,
CAST(SUM(COALESCE(i.NETWR, 0)) AS DECIMAL(23, 2)) AS TotalNetAmount,
CAST(MIN(i.BEDNR) AS NVARCHAR(20)) AS PurchaseRequisitionNumber,
CAST(MIN(i.EINDT) AS DATE) AS RequestedDeliveryDate
FROM EKKO h
INNER JOIN EKPO i
ON i.MANDT = h.MANDT
AND i.EBELN = h.EBELN
WHERE h.AEDAT >= (SELECT start_ts FROM params)
AND h.AEDAT < (SELECT end_ts FROM params)
AND h.BUKRS IN ([Company Code filter])
AND h.BSART IN ([Document Type filter])
GROUP BY
h.MANDT,
h.EBELN,
h.LIFNR,
h.BSART,
h.BUKRS,
h.AEDAT,
h.ERNAM,
h.BEDAT
),
po_items AS (
SELECT
i.MANDT,
i.EBELN AS PurchaseOrderNumber,
i.EBELP,
i.BANFN AS PurchaseRequisitionNumber,
i.BEDNR,
i.EINDT AS RequestedDeliveryDate
FROM EKPO i
),
events AS (
SELECT
p.PurchaseOrderNumber,
'Purchase Requisition Created' AS ActivityName,
CAST(r.[Purchase requisition creation timestamp] AS TIMESTAMP) AS EventTime,
s.source_system AS SourceSystem,
s.last_data_update AS LastDataUpdate,
p.VendorId,
CAST(r.[Purchase requisition created by] AS NVARCHAR(100)) AS UserName,
p.TotalNetAmount,
CAST(r.[Purchase requisition number] AS NVARCHAR(20)) AS PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your requisition source table or view] r
ON r.[Client] = p.MANDT
AND r.[Purchase requisition number] = p.PurchaseRequisitionNumber
CROSS JOIN params s
WHERE r.[Purchase requisition creation timestamp] >= s.start_ts
AND r.[Purchase requisition creation timestamp] < s.end_ts
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Requisition Approved' AS ActivityName,
CAST(r.[Purchase requisition approval timestamp] AS TIMESTAMP) AS EventTime,
s.source_system,
s.last_data_update,
p.VendorId,
CAST(r.[Purchase requisition approver] AS NVARCHAR(100)),
p.TotalNetAmount,
CAST(r.[Purchase requisition number] AS NVARCHAR(20)),
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your requisition approval history table or view] r
ON r.[Client] = p.MANDT
AND r.[Purchase requisition number] = p.PurchaseRequisitionNumber
CROSS JOIN params s
WHERE r.[Purchase requisition approval timestamp] >= s.start_ts
AND r.[Purchase requisition approval timestamp] < s.end_ts
AND r.[Approval status] = '[Approved status value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Created',
CAST(p.PODate AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
p.POCreatedBy,
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
CROSS JOIN params s
WHERE p.PODate >= CAST(s.start_ts AS DATE)
AND p.PODate < CAST(s.end_ts AS DATE)
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Approved',
CAST(a.[Purchase order approval timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(a.[Approver] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order release history table or view] a
ON a.[Client] = p.MANDT
AND a.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE a.[Purchase order approval timestamp] >= s.start_ts
AND a.[Purchase order approval timestamp] < s.end_ts
AND a.[Release status] = '[Approved release status value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Sent to Vendor',
CAST(o.[Output timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(o.[Output user] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order output source table or view] o
ON o.[Client] = p.MANDT
AND o.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE o.[Output timestamp] >= s.start_ts
AND o.[Output timestamp] < s.end_ts
AND o.[Output status] = '[Successfully processed output status]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Changed',
CAST(c.[Change timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(c.[Changed by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order change history table or view] c
ON c.[Client] = p.MANDT
AND c.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE c.[Change timestamp] >= s.start_ts
AND c.[Change timestamp] < s.end_ts
AND c.[Change indicator] = '[Changed indicator value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Goods Receipt Posted',
CAST(g.[Goods movement timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(g.[Posted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your goods movement source table or view] g
ON g.[Client] = p.MANDT
AND g.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE g.[Goods movement timestamp] >= s.start_ts
AND g.[Goods movement timestamp] < s.end_ts
AND g.[Movement type] IN ([Goods receipt movement types])
AND g.[Reversal indicator] IS NULL
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Services Confirmation Entered',
CAST(v.[Service entry timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(v.[Entered by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your service entry sheet source table or view] v
ON v.[Client] = p.MANDT
AND v.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE v.[Service entry timestamp] >= s.start_ts
AND v.[Service entry timestamp] < s.end_ts
AND v.[Service entry status] = '[Accepted service entry status]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Goods Returned',
CAST(g.[Goods movement timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(g.[Posted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your goods movement source table or view] g
ON g.[Client] = p.MANDT
AND g.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE g.[Goods movement timestamp] >= s.start_ts
AND g.[Goods movement timestamp] < s.end_ts
AND g.[Movement type] IN ([Goods return movement types])
AND g.[Reversal indicator] IS NULL
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Invoice Received',
CAST(i.[Invoice posting timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(i.[Posted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your supplier invoice source table or view] i
ON i.[Client] = p.MANDT
AND i.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE i.[Invoice posting timestamp] >= s.start_ts
AND i.[Invoice posting timestamp] < s.end_ts
AND i.[Invoice status] = '[Posted invoice status]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Invoice Paid',
CAST(i.[Clearing timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(i.[Cleared by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your supplier invoice clearing source table or view] i
ON i.[Client] = p.MANDT
AND i.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE i.[Clearing timestamp] >= s.start_ts
AND i.[Clearing timestamp] < s.end_ts
AND i.[Clearing status] = '[Cleared status value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Completed',
CAST(x.[Completion timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(x.[Completion user] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order item status source table or view] x
ON x.[Client] = p.MANDT
AND x.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE x.[Completion timestamp] >= s.start_ts
AND x.[Completion timestamp] < s.end_ts
AND x.[Delivery completed indicator] = '[Set indicator value]'
AND x.[Final invoice indicator] = '[Set indicator value]'
UNION ALL
SELECT
p.PurchaseOrderNumber,
'Purchase Order Deleted',
CAST(d.[Deletion timestamp] AS TIMESTAMP),
s.source_system,
s.last_data_update,
p.VendorId,
CAST(d.[Deleted by] AS NVARCHAR(100)),
p.TotalNetAmount,
p.PurchaseRequisitionNumber,
p.RequestedDeliveryDate,
p.DocumentType
FROM po_base p
INNER JOIN [Your purchase order deletion history table or view] d
ON d.[Client] = p.MANDT
AND d.[Purchase order number] = p.PurchaseOrderNumber
CROSS JOIN params s
WHERE d.[Deletion timestamp] >= s.start_ts
AND d.[Deletion timestamp] < s.end_ts
AND d.[Deletion indicator] = '[Set deletion indicator value]'
)
SELECT
PurchaseOrderNumber,
ActivityName,
EventTime,
SourceSystem,
LastDataUpdate,
VendorId,
UserName,
TotalNetAmount,
PurchaseRequisitionNumber,
RequestedDeliveryDate,
DocumentType
FROM events
WHERE PurchaseOrderNumber IS NOT NULL
AND ActivityName IS NOT NULL
AND EventTime IS NOT NULL
ORDER BY PurchaseOrderNumber, EventTime, ActivityName; Schritte
- Spezifikation und Design: Definieren Sie die endgültige Datenstruktur der Event-Log-Datei einschließlich aller erforderlichen und empfohlenen Attribute. Dokumentieren Sie die SAP-Tabellen, zum Beispiel EKKO, EKPO, EKBE, CDHDR und CDPOS, aus denen die Daten für jede der 13 erforderlichen Aktivitäten stammen.
- Programm erstellen: Öffnen Sie in der SAP GUI den ABAP Editor über den Transaktionscode SE38 oder SE80. Erstellen Sie ein neues ausführbares Programm, zum Beispiel Z_PM_PO_EXTRACT.
- Selektionsbildschirm definieren: Programmieren Sie den Selektionsbildschirm des Reports. Darüber können Benutzer die zu extrahierenden Daten filtern. Fügen Sie Parameter für den Zeitraum des Bestellanlagedatums (P_AEDAT), den Buchungskreis (P_BUKRS) und die Einkaufsbelegart (P_BSART) hinzu.
- Datendeklarationen: Definieren Sie die für das Programm benötigten internen Tabellen und Datenstrukturen. Dazu gehört eine interne Tabelle für das endgültige Event Log, die der im Spezifikationsschritt festgelegten Struktur entspricht.
- Logik zur Datenauswahl implementieren: Schreiben Sie die zentrale ABAP-Logik zur Auswahl der Daten für jede der 13 Aktivitäten. Dazu gehören mehrere SELECT-Anweisungen für die relevanten SAP-Tabellen, die bei Bedarf verknüpft werden. Lesen Sie bei änderungsbasierten Ereignissen die Änderungstabellen CDHDR und CDPOS aus.
- Daten umwandeln und zuordnen: Ordnen Sie für jeden abgerufenen Datensatz die SAP-Tabellenfelder den entsprechenden Spalten der internen Tabelle für das endgültige Event Log zu. Setzen Sie ActivityName entsprechend dem verarbeiteten Ereignis, zum Beispiel 'Purchase Order Created'. Wandeln Sie Datums- und Zeitfelder in ein einheitliches Timestamp-Format für EventTime um.
- Ereignisdaten zusammenführen: Stellen Sie nach der Verarbeitung aller 13 Aktivitätstypen sicher, dass sämtliche Daten in einer gemeinsamen internen Tabelle zusammengeführt sind. Diese Tabelle enthält nun das vollständige Event Log für die ausgewählten Bestellungen.
- Dateiausgabe implementieren: Ergänzen Sie eine Funktion, die die endgültige interne Tabelle in eine Datei schreibt. Empfohlen wird die Methode cl_gui_frontend_services=>gui_download, mit der Benutzer die Datei lokal als CSV speichern können. Alternativ können Sie OPEN DATASET verwenden, um sie für die Hintergrundverarbeitung auf dem SAP-Applikationsserver zu speichern.
- Transaktionscode erstellen (optional): Damit Fachanwender das Programm leicht aufrufen können, erstellen Sie mit dem Transaktionscode SE93 einen eigenen Transaktionscode, zum Beispiel ZPM_PO_EXTRACT, der Ihr ABAP-Programm ausführt.
- Hintergrundjob einplanen: Planen Sie bei großen Datenmengen oder automatisierten Extraktionen mit dem Transaktionscode SM36 die Ausführung des Programms als Hintergrundjob ein. Die Ausgabedatei wird in dem in der Programmlogik angegebenen Pfad auf dem Applikationsserver gespeichert.
Konfiguration
- Selektionskriterien: Das Programm sollte Parameter zur gezielten Filterung der Daten enthalten. Zu den wichtigsten Filtern gehören:
- Zeitraum: Ein verpflichtender Zeitraum für das Anlagedatum der Bestellung (EKKO-AEDAT). Um Datenvolumen und Reportlaufzeit zu steuern, empfiehlt sich zunächst ein Zeitraum von 3 bis 6 Monaten.
- Buchungskreis (BUKRS): Für Unternehmen mit mehreren Rechtsträgern unerlässlich, um den Umfang der Extraktion einzugrenzen.
- Einkaufsbelegart (BSART): Ermöglicht die Filterung nach bestimmten Bestellarten, etwa Standardbestellung, Rahmenbestellung oder Umlagerungsbestellung, und damit eine gezielte Analyse.
- Änderungsprotokolle auslesen: Für die Extraktion von Aktivitäten wie 'Purchase Order Approved' oder 'Purchase Order Changed' müssen die SAP-Änderungsprotokolltabellen CDHDR und CDPOS ausgelesen werden. Dies kann ressourcenintensiv sein. Optimieren Sie die ABAP-Logik so, dass nur die erforderlichen Objektklassen (EINKBELEG, BANF) sowie Tabellen- und Feldkombinationen ausgewählt werden.
- Berechtigungen: Der Benutzer oder das technische Konto, mit dem der Report ausgeführt wird, benötigt umfangreiche Leseberechtigungen für Tabellen aus mehreren SAP-Modulen, darunter Materialwirtschaft (MM), Finanzbuchhaltung (FI) und systemweite Tabellen. Dazu gehören beispielsweise EKKO, EKPO, EBAN, EKBE, BKPF, BSAK, RBKP, NAST, CDHDR und CDPOS.
- Hintergrundausführung: Führen Sie das Programm bei Extraktionen über mehrere Monate oder bei hohem Transaktionsvolumen immer im Hintergrund aus, um Zeitüberschreitungen bei Dialogprozessen zu vermeiden.
a Beispielabfrage abap
REPORT z_pm_po_extract.
" ====================================================================
" SELECTION SCREEN
" ====================================================================
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
SELECT-OPTIONS: s_aedat FOR sy-datum OBLIGATORY.
SELECT-OPTIONS: s_bukrs FOR ekko-bukrs.
SELECT-OPTIONS: s_bsart FOR ekko-bsart.
PARAMETERS: p_sysid TYPE string DEFAULT '[Your SAP System ID]'.
SELECTION-SCREEN END OF BLOCK b1.
" ====================================================================
" DATA DECLARATIONS
" ====================================================================
TYPES: BEGIN OF ty_event_log,
purchaseordernumber TYPE ebeln,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
vendorid TYPE lifnr,
username TYPE ernam,
totalnetamount TYPE netwr,
purchaserequisitionnumber TYPE banfn,
requesteddeliverydate TYPE eedat,
documenttype TYPE bsart,
END OF ty_event_log.
DATA: lt_event_log TYPE TABLE OF ty_event_log,
ls_event_log TYPE ty_event_log.
DATA: lt_ekko TYPE TABLE OF ekko,
lt_ekpo TYPE TABLE OF ekpo.
" ====================================================================
" START OF SELECTION
" ====================================================================
START-OF-SELECTION.
" Get current timestamp for LastDataUpdate
GET TIME STAMP FIELD ls_event_log-lastdataupdate.
ls_event_log-sourcesystem = p_sysid.
" --- Initial Data Selection: Purchase Orders in Scope ---
SELECT * FROM ekko INTO TABLE lt_ekko
WHERE aedat IN s_aedat
AND bukrs IN s_bukrs
AND bsart IN s_bsart.
IF lt_ekko IS INITIAL.
MESSAGE 'No Purchase Orders found for the given criteria.' TYPE 'S' DISPLAY LIKE 'E'.
RETURN.
ENDIF.
SELECT * FROM ekpo INTO TABLE lt_ekpo
FOR ALL ENTRIES IN lt_ekko
WHERE ebeln = lt_ekko-ebeln.
" --- 1. Purchase Requisition Created ---
SELECT ban.banfn, ban.erdat, ban.erzet, ban.ernam,
ekpo.ebeln, ekpo.netwr, ekpo.eindt, ekpo.bsart, ekpo.lifnr, ekko.bukrs
FROM eban AS ban
INNER JOIN ekpo AS ekpo ON ban.banfn = ekpo.banfn AND ban.bnfpo = ekpo.bnfpo
INNER JOIN ekko AS ekko ON ekpo.ebeln = ekko.ebeln
WHERE ekko.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_pr_created).
LOOP AT lt_pr_created INTO DATA(ls_pr_created).
ls_event_log-purchaseordernumber = ls_pr_created-ebeln.
ls_event_log-activityname = 'Purchase Requisition Created'.
CONVERT DATE ls_pr_created-erdat TIME ls_pr_created-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-vendorid = ls_pr_created-lifnr.
ls_event_log-username = ls_pr_created-ernam.
ls_event_log-totalnetamount = ls_pr_created-netwr.
ls_event_log-purchaserequisitionnumber = ls_pr_created-banfn.
ls_event_log-requesteddeliverydate = ls_pr_created-eindt.
ls_event_log-documenttype = ls_pr_created-bsart.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 2. Purchase Requisition Approved (via Change Docs on Release Indicator) ---
SELECT h.objectid, h.udate, h.utime, h.username
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.objectclas = p.objectclas AND h.objectid = p.objectid AND h.changenr = p.changenr
INNER JOIN ekpo AS ekpo ON h.objectid = ekpo.banfn
INNER JOIN ekko AS ekko ON ekpo.ebeln = ekko.ebeln
WHERE h.objectclas = 'BANF'
AND p.tabname = 'EBAN'
AND p.fname = 'FRGZU'
AND p.value_new = 'X' "Configure based on your system release indicator for 'Approved'
AND ekko.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_pr_approved).
LOOP AT lt_pr_approved INTO DATA(ls_pr_approved).
SELECT SINGLE ebeln FROM ekpo INTO ls_event_log-purchaseordernumber WHERE banfn = ls_pr_approved-objectid.
ls_event_log-activityname = 'Purchase Requisition Approved'.
CONVERT DATE ls_pr_approved-udate TIME ls_pr_approved-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_pr_approved-username.
" Other attributes can be populated with another SELECT if needed.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 3. Purchase Order Created ---
LOOP AT lt_ekko INTO DATA(ls_ekko_created).
ls_event_log-purchaseordernumber = ls_ekko_created-ebeln.
ls_event_log-activityname = 'Purchase Order Created'.
CONVERT DATE ls_ekko_created-aedat TIME ls_ekko_created-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-vendorid = ls_ekko_created-lifnr.
ls_event_log-username = ls_ekko_created-ernam.
ls_event_log-totalnetamount = ls_ekko_created-rlwrt.
ls_event_log-purchaserequisitionnumber = ''. "Can be enriched later if needed
ls_event_log-requesteddeliverydate = ''. "Can be enriched from EKPO
ls_event_log-documenttype = ls_ekko_created-bsart.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 4. Purchase Order Approved (via Change Docs on Release Indicator) ---
SELECT h.objectid, h.udate, h.utime, h.username
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.objectclas = p.objectclas AND h.objectid = p.objectid AND h.changenr = p.changenr
WHERE h.objectclas = 'EINKBELEG'
AND p.tabname = 'EKKO'
AND p.fname = 'FRGKE'
AND p.value_new = 'R' "R for Released
AND h.objectid IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_approved).
LOOP AT lt_po_approved INTO DATA(ls_po_approved).
ls_event_log-purchaseordernumber = ls_po_approved-objectid.
ls_event_log-activityname = 'Purchase Order Approved'.
CONVERT DATE ls_po_approved-udate TIME ls_po_approved-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_approved-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 5. Purchase Order Sent to Vendor ---
SELECT n.objky, n.vstat, n.datvr, n.uhrvr, e.ernam
FROM nast AS n
INNER JOIN ekko AS e ON n.objky = e.ebeln
WHERE n.kappl = 'EF' "Application for Purchasing
AND n.kschl = '[Your PO Output Type]' "e.g. NEU
AND n.vstat = '1' "Successfully processed
AND n.objky IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_sent).
LOOP AT lt_po_sent INTO DATA(ls_po_sent).
ls_event_log-purchaseordernumber = ls_po_sent-objky.
ls_event_log-activityname = 'Purchase Order Sent to Vendor'.
CONVERT DATE ls_po_sent-datvr TIME ls_po_sent-uhrvr INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_sent-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 6. Purchase Order Changed ---
SELECT objectid, udate, utime, username FROM cdhdr
WHERE objectclas = 'EINKBELEG'
AND tcode IN ('ME22', 'ME22N')
AND objectid IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_changed).
LOOP AT lt_po_changed INTO DATA(ls_po_changed).
ls_event_log-purchaseordernumber = ls_po_changed-objectid.
ls_event_log-activityname = 'Purchase Order Changed'.
CONVERT DATE ls_po_changed-udate TIME ls_po_changed-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_changed-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 7. Goods Receipt Posted & 9. Goods Returned ---
SELECT e.ebeln, m.budat, m.cpudt, m.cputm, m.usnam, b.shkzg, b.bwart
FROM mkpf AS m
INNER JOIN mseg AS s ON m.mblnr = s.mblnr AND m.mjahr = s.mjahr
INNER JOIN t156 AS t ON s.bwart = t.bwart
INNER JOIN ekbe AS e ON s.ebeln = e.ebeln AND s.ebelp = e.ebelp AND s.mblnr = e.belnr AND s.mjahr = e.gjahr
WHERE e.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
AND e.bwart IN ('101', '102', '122', '123') "GR, GR Reversal, Return
INTO TABLE @DATA(lt_goods_mvmt).
LOOP AT lt_goods_mvmt INTO DATA(ls_goods_mvmt).
ls_event_log-purchaseordernumber = ls_goods_mvmt-ebeln.
IF ls_goods_mvmt-bwart = '101'.
ls_event_log-activityname = 'Goods Receipt Posted'.
ELSE.
ls_event_log-activityname = 'Goods Returned'.
ENDIF.
CONVERT DATE ls_goods_mvmt-cpudt TIME ls_goods_mvmt-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_goods_mvmt-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 8. Services Confirmation Entered ---
SELECT h.erdat, h.erzeit, h.ernam, l.ebeln
FROM essr AS h
INNER JOIN esll AS l ON h.lblni = l.lblni
WHERE l.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_services).
LOOP AT lt_services INTO DATA(ls_services).
ls_event_log-purchaseordernumber = ls_services-ebeln.
ls_event_log-activityname = 'Services Confirmation Entered'.
CONVERT DATE ls_services-erdat TIME ls_services-erzeit INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_services-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 10. Invoice Received ---
SELECT r.ebeln, r.cpudt, r.cputm, r.usnam
FROM rbkp AS r
WHERE r.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_invoice_rcvd).
LOOP AT lt_invoice_rcvd INTO DATA(ls_invoice_rcvd).
ls_event_log-purchaseordernumber = ls_invoice_rcvd-ebeln.
ls_event_log-activityname = 'Invoice Received'.
CONVERT DATE ls_invoice_rcvd-cpudt TIME ls_invoice_rcvd-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_invoice_rcvd-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 11. Invoice Paid ---
SELECT b.ebeln, s.augdt, s.augbl, b.usnam
FROM rbkp AS b
INNER JOIN bseg AS e ON b.belnr = e.belnr AND b.gjahr = e.gjahr
INNER JOIN bsak AS s ON e.bukrs = s.bukrs AND e.belnr = s.belnr AND e.gjahr = s.gjahr AND e.buzei = s.buzei
WHERE b.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
AND s.augdt IS NOT NULL
INTO TABLE @DATA(lt_invoice_paid).
LOOP AT lt_invoice_paid INTO DATA(ls_invoice_paid).
ls_event_log-purchaseordernumber = ls_invoice_paid-ebeln.
ls_event_log-activityname = 'Invoice Paid'.
CONVERT DATE ls_invoice_paid-augdt INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_invoice_paid-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 12. Purchase Order Completed & 13. Purchase Order Deleted (via Change Docs) ---
SELECT h.objectid, h.udate, h.utime, h.username, p.fname
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.changenr = p.changenr
INNER JOIN ekpo AS ekpo ON h.objectid = |{ ekpo.ebeln }{ ekpo.ebelp }|
WHERE h.objectclas = 'EINKBELEG'
AND p.tabname = 'EKPO'
AND p.fname IN ('ELIKZ', 'EREKZ', 'LOEKZ')
AND p.value_new = 'X'
AND ekpo.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_status_change).
LOOP AT lt_po_status_change INTO DATA(ls_po_status_change).
ls_event_log-purchaseordernumber = substring( val = ls_po_status_change-objectid, off = 0, len = 10 ).
CASE ls_po_status_change-fname.
WHEN 'LOEKZ'.
ls_event_log-activityname = 'Purchase Order Deleted'.
WHEN 'ELIKZ' OR 'EREKZ'.
"This logic may need refinement to check if both are now set.
ls_event_log-activityname = 'Purchase Order Completed'.
ENDCASE.
CONVERT DATE ls_po_status_change-udate TIME ls_po_status_change-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_status_change-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- Final Output to CSV ---
CALL METHOD cl_gui_frontend_services=>gui_download
EXPORTING
filename = 'C:\temp\po_event_log.csv'
filetype = 'ASC'
CHANGING
data_tab = lt_event_log. Bereit für den Einstieg?
Dieses Template bietet eine solide Grundlage für Ihren Einstieg in Process Mining. Nutzen Sie Ihre SAP-S/4HANA-Daten, um Effizienzpotenziale aufzudecken und Ihren Purchase-to-Pay-Prozess noch heute zu verbessern.
Optimieren Sie Ihren P2P-Bestellprozess und verkürzen Sie jetzt die Zykluszeit
Beseitigen Sie Ineffizienzen und verkürzen Sie die Zykluszeit Ihres P2P-Bestellprozesses um 30 %.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.