Ihr Daten-Template für Purchase to Pay – Bestellung
Ihr Daten-Template für Purchase to Pay – Bestellung
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für die Analyse
- Hinweise zum Datenexport aus SAP ECC
Attribute für Purchase to Pay – Bestellung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivität Activity | Die Bezeichnung des konkreten Geschäftsereignisses oder Prozessschritts im Lebenszyklus einer Bestellung. | ||
| Beschreibung Dieses Attribut beschreibt einen einzelnen Prozessschritt, etwa „Bestellung angelegt“, „Bestellung genehmigt“ oder „Wareneingang gebucht“. Die Abfolge dieser Aktivitäten bildet den Prozessfluss für jede Bestellung. Die Analyse der Reihenfolge, Häufigkeit und Dauer zwischen den Aktivitäten ist der Kern des Process Mining. Sie hilft, Engpässe, Nacharbeitsschleifen und Abweichungen vom Standardprozess zu erkennen und gezielte Verbesserungen sowie Standardisierungen umzusetzen. Warum das wichtig ist Aktivitäten bilden die Prozessschritte ab. Ihre Reihenfolge und Zeitpunkte zeigen den tatsächlichen Prozessfluss, Engpässe und Abweichungen. Woher beziehen Abgeleitet aus verschiedenen SAP-Tabellen und Transaktionsprotokollen, etwa CDHDR/CDPOS für Änderungen, EKBE für Wareneingang und Rechnungsprüfung sowie EBAN für Bestellanforderungen. Zur Generierung ist häufig eine individuelle Logik oder ein Extraktionsprogramm erforderlich. Beispiele Bestellung angelegtBestellung genehmigtWareneingang gebucht | |||
| Bestellung PurchaseOrder | Der eindeutige Bezeichner des Bestelldokuments (PO), das als zentraler Case für die Nachverfolgung des Beschaffungsprozesses dient. | ||
| Beschreibung Die Bestellnummer ist der zentrale Bezeichner, der alle Aktivitäten von der Erstellung bis zum endgültigen Wareneingang und Abschluss miteinander verknüpft. Jede eindeutige Bestellnummer steht für einen einzelnen Beschaffungsvorgang. Im Process Mining ist dieses Attribut entscheidend, um den gesamten Ablauf jeder Bestellung zu rekonstruieren. Es ermöglicht eine detaillierte Analyse der Zykluszeiten, Prozessvarianten und Compliance-Prüfungen für jede einzelne Bestellung und bildet die Grundlage für das gesamte Prozessmodell. Warum das wichtig ist Dieser zentrale Bezeichner verknüpft alle zugehörigen Ereignisse und ermöglicht so die Analyse des vollständigen Lebenszyklus jeder einzelnen Bestellung. Woher beziehen Tabelle: EKKO, Feld: EBELN Beispiele 450001762345000176244500017625 | |||
| Ereigniszeit EventTime | Das genaue Datum und die Uhrzeit, zu denen die Aktivität stattgefunden hat. | ||
| Beschreibung Dieser Timestamp kennzeichnet den genauen Zeitpunkt eines Ereignisses, etwa die Genehmigung einer Bestellung oder die Buchung eines Wareneingangs. Er legt die chronologische Reihenfolge aller Aktivitäten innerhalb eines Case fest. Timestamps sind eine wesentliche Grundlage für das Process Mining, da sie alle zeitbasierten Analysen ermöglichen. Dazu gehören die Berechnung von Zykluszeiten zwischen Aktivitäten, das Erkennen von Verzögerungen, die Analyse des Prozessdurchsatzes und der Leistungsvergleich mit Service Level Agreements (SLAs). Warum das wichtig ist Dieser Timestamp ist entscheidend für die Berechnung aller zeitbezogenen Kennzahlen, etwa Zykluszeiten und Engpässe, sowie für die chronologische Sortierung der Ereignisse. Woher beziehen Abgeleitet aus verschiedenen Datums- und Uhrzeitfeldern in SAP-Tabellen, etwa EKKO-AEDAT (Änderungsdatum), CDHDR-UDATE/UTIME (Timestamp des Änderungsprotokolls) oder EKBE-BUDAT (Buchungsdatum). Beispiele 2023-04-15T10:05:31Z2023-04-16T14:22:00Z2023-05-01T09:00:15Z | |||
| Belegart DocumentType | Ein Code zur Klassifizierung verschiedener Bestellarten. | ||
| Beschreibung Die Belegart ist eine SAP-Konfiguration, die den Nummernkreis, die Feldauswahl und den gesamten Prozessfluss einer Bestellung steuert. So kann es unterschiedliche Belegarten für Standardbestellungen, Dienstleistungsbestellungen oder Umlagerungsbestellungen geben. Dieses Attribut ist eine wichtige Analysedimension, da verschiedene Belegarten oft bewusst unterschiedlichen Prozessen folgen. Durch die Filterung nach Belegart lassen sich Zykluszeiten und Prozessflüsse präziser miteinander vergleichen. Warum das wichtig ist Unterscheidet verschiedene Beschaffungsprozesse, etwa Standard-, Dienstleistungs- oder Retourenprozesse, die oft eigene Abläufe und Leistungserwartungen haben. Woher beziehen Tabelle: EKKO, Feld: BSART Beispiele NBFOUB | |||
| Benutzername UserName | Die Benutzer-ID der Person, die die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst den SAP-Benutzernamen des Mitarbeitenden, der ein Dokument angelegt, geändert oder genehmigt hat. Bei automatisierten Schritten kann eine System- oder Batch-Benutzer-ID angezeigt werden. Die Analyse nach Benutzern hilft, Schulungsbedarf und besonders leistungsstarke Mitarbeitende zu erkennen sowie mögliche Compliance-Probleme aufzudecken. Sie ist wichtig für Dashboards zur Arbeitslastverteilung und zur Einhaltung der Genehmigungsmatrix und ermöglicht den Leistungsvergleich zwischen Teams und einzelnen Mitarbeitenden. Warum das wichtig ist Ordnet Benutzeraktionen bestimmten Personen zu und ermöglicht so die Analyse von Leistung, Arbeitslast und Einhaltung der Compliance-Vorgaben. Woher beziehen Tabelle: EKKO, Feld: ERNAM (Erstellt von); Tabelle: CDHDR, Feld: USERNAME (Geändert von). Beispiele JSMITHMBROWNBATCH_USER | |||
| Bestellwert OrderAmount | Der Gesamtwert der Bestellposition. | ||
| Beschreibung Dieses Attribut gibt den Gesamtwert einer bestimmten Bestellposition an. Er berechnet sich aus der Menge multipliziert mit dem Nettopreis. Für den Gesamtwert einer Bestellung müssen die Beträge aller Positionen addiert werden. Die Analyse nach Bestellwert ist entscheidend, um Transaktionen mit hohem Wert zu erkennen, für die strengere Kontrollen oder andere Genehmigungswege erforderlich sein können. Sie bildet die Grundlage für das Dashboard zur Analyse des Bestellwerts und hilft, Verbesserungsmaßnahmen auf finanziell besonders bedeutende Bestellungen auszurichten. Warum das wichtig ist Beziffert die finanziellen Auswirkungen jeder Bestellung und ermöglicht wertbasierte Analysen, um Bestellungen mit hohem Wert zu priorisieren oder Einsparpotenziale zu erkennen. Woher beziehen Tabelle: EKPO, Feld: NETWR (Nettobestellwert). Beispiele 1500.00250.7512345.50 | |||
| Buchungskreis CompanyCode | Der Bezeichner der juristischen Person oder des Unternehmens, das die Beschaffung veranlasst. | ||
| Beschreibung Der Buchungskreis steht in SAP für eine eigenständige juristische Person. Alle Transaktionen werden auf Ebene des Buchungskreises gebucht. Er ist damit eine grundlegende Organisationseinheit. Die Analyse nach Buchungskreis ermöglicht den Vergleich von Beschaffungseffizienz und Compliance zwischen verschiedenen Geschäftseinheiten oder Ländern. Sie hilft, bewährte Vorgehensweisen einer Einheit zu erkennen und an anderer Stelle zu übernehmen oder gezielt Einheiten zu identifizieren, die Unterstützung benötigen. Warum das wichtig ist Kennzeichnet die juristische Person und ermöglicht den Vergleich der Prozessleistung sowie Compliance-Prüfungen in verschiedenen Unternehmensbereichen. Woher beziehen Tabelle: EKKO, Feld: BUKRS Beispiele 10002100US01 | |||
| Lieferantennummer VendorNumber | Der eindeutige Bezeichner des Lieferanten. | ||
| Beschreibung Dieser Code kennzeichnet eindeutig den Lieferanten, von dem Waren oder Dienstleistungen beschafft werden. Er ist ein wichtiges Stammdatenattribut im Beschaffungsprozess. Dieses Attribut ist für lieferantenbezogene Analysen unverzichtbar. Es ermöglicht die Bewertung der Lieferanten-Lieferleistung, den Vergleich von Lieferzeiten verschiedener Lieferanten und die Analyse von Ausgabenmustern. Es ist die zentrale Dimension des Dashboards „Lieferanten-Lieferleistung“. Warum das wichtig ist Ermöglicht die Analyse der Lieferantenleistung und hilft, zuverlässige Lieferanten sowie Verursacher von Verzögerungen oder Qualitätsproblemen zu erkennen. Woher beziehen Tabelle: EKKO, Feld: LIFNR Beispiele 100345V-20598700112 | |||
| Warengruppe MaterialGroup | Eine Klassifizierung, mit der Waren oder Dienstleistungen mit ähnlichen Merkmalen gruppiert werden. | ||
| Beschreibung Die Warengruppe beziehungsweise Beschaffungskategorie klassifiziert die Art der beschafften Waren oder Dienstleistungen. Beispiele sind „IT-Hardware“, „Bürobedarf“ oder „professionelle Dienstleistungen“. Dieses Attribut ist wichtig für die Ausgabenanalyse und das Verständnis von Beschaffungsmustern. Damit lässt sich der Prozess filtern und untersuchen, wie verschiedene Kategorien bearbeitet werden, wer sie genehmigt und welche Lieferanten sie bereitstellen. Es ist eine zentrale Dimension des Dashboards zur Analyse des Bestellwerts. Warum das wichtig ist Ermöglicht die Segmentierung des Prozesses nach Produkt- oder Dienstleistungskategorie. So werden Unterschiede bei Abläufen, Zykluszeiten und Lieferanten für verschiedene Ausgabenarten sichtbar. Woher beziehen Tabelle: EKPO, Feld: MATKL Beispiele 00101IT-HardwareBERATUNG | |||
| Ablehnungsgrund RejectionReason | Der Grundcode oder Text, der erklärt, warum eine Bestellanforderung oder Bestellung abgelehnt wurde. | ||
| Beschreibung Dieses Attribut erfasst den konkreten Grund für die Ablehnung einer Bestellung im Freigabe-Workflow. Diese Information ist entscheidend, um die Ursachen für Nacharbeit und Verzögerungen zu verstehen. Die Analyse der Ablehnungsgründe zeigt häufige Probleme auf, etwa falsche Preise, überschrittene Budgets oder die Auswahl nicht konformer Lieferanten. So kann das Unternehmen die Ursachen angehen, die Qualität der ursprünglichen Bestellung verbessern und den Freigabeprozess vereinfachen. Warum das wichtig ist Zeigt direkt, warum Freigaben scheitern. So können Sie gezielt Verbesserungen umsetzen, Nacharbeit verringern und Freigabezeiten verkürzen. Woher beziehen Diese Information ist möglicherweise schwer zu finden. Sie kann in Langtextfeldern gespeichert sein oder von einer kundenspezifischen Workflow-Konfiguration abhängen. Für ihre Ermittlung sind häufig spezielle Implementierungskenntnisse erforderlich. Beispiele Falscher PreisBudget überschrittenDoppelte Anforderung | |||
| Änderung nach Freigabe IsPostApprovalChange | Kennzeichnet, ob eine Bestellung nach der ursprünglichen Freigabe geändert wurde. | ||
| Beschreibung Dieses boolesche Attribut ist wahr, wenn für dieselbe Bestellung nach der Aktivität „Bestellung freigegeben“ die Aktivität „Bestellung geändert“ erkannt wird. Damit lassen sich problematische Änderungen identifizieren, die erst spät im Prozess erfolgen. Dieses berechnete Feld unterstützt direkt die Kennzahl „Änderungsquote von Bestellungen nach Freigabe“ und das Dashboard „Nacharbeit und Änderungen bei Bestellungen“. Es quantifiziert und verdeutlicht störende Änderungen, die Verzögerungen verursachen und eine erneute Freigabe erfordern können. So werden mögliche Probleme bei der ursprünglichen Spezifikation oder der Abgrenzung des Umfangs sichtbar. Warum das wichtig ist Misst direkt die Nacharbeit nach der Freigabe, eine wichtige Kennzahl für Prozessstabilität und Effizienz. Hohe Werte weisen auf Probleme bei der vorgelagerten Anforderungsdefinition hin. Woher beziehen Dieses berechnete Attribut wird aus der Abfolge der Aktivitäten im Event Log abgeleitet. Beispiele truefalse | |||
| Angeforderter Liefertermin RequestedDeliveryDate | Das Datum, zu dem das Unternehmen die Lieferung der Waren oder Dienstleistungen angefordert hat. | ||
| Beschreibung Dies ist der in der Bestellung angegebene Zieltermin für die Lieferung. Er dient als Vergleichswert für die Bewertung der tatsächlichen Lieferleistung. Dieses Datum ist entscheidend für die Berechnung der Kennzahl zur pünktlichen Wareneingangsquote. Durch den Vergleich des tatsächlichen Wareneingangsdatums mit dem angeforderten Liefertermin können Unternehmen die Zuverlässigkeit der Lieferanten und die Effizienz der internen Warenannahme quantitativ bewerten. Das unterstützt direkt das Dashboard „Lieferanten-Lieferleistung“. Warum das wichtig ist Dieser Zieltermin ist entscheidend für die Berechnung von Kennzahlen zur Pünktlichkeit und die Bewertung der Lieferantenzuverlässigkeit. Woher beziehen Tabelle: EKPO, Feld: EINDT Beispiele 2023-06-102023-07-222023-08-01 | |||
| Bestellanforderung PurchaseRequisition | Der Bezeichner der Bestellanforderung, die der Bestellung vorausging. | ||
| Beschreibung Dieses Attribut verknüpft die Bestellung mit der ursprünglichen Bestellanforderung. Nicht jeder Bestellung geht eine Bestellanforderung voraus. Diese Verknüpfung ist wichtig für die Analyse des Dashboards zur Umwandlung von Bestellanforderungen in Bestellungen und der Kennzahl zur Umwandlungsquote. Damit lässt sich die Effizienz des vorgelagerten Prozesses von der ersten Anforderung bis zur Erstellung einer formellen Bestellung messen. Außerdem können nicht konforme Bestellungen erkannt werden, die ohne vorherige Bestellanforderung angelegt wurden. Warum das wichtig ist Verknüpft die Bestellung mit der ursprünglichen Anforderung und ermöglicht die Analyse der Umwandlung von Bestellanforderungen in Bestellungen sowie das Erkennen von Bestellungen ohne vorherige Anforderung. Woher beziehen Tabelle: EKPO, Feld: BANFN Beispiele 1001589010015891 | |||
| Einkäufergruppe PurchasingGroup | Der Einkäufer oder die Gruppe von Einkäufern, die für die Beschaffungsaktivität zuständig ist. | ||
| Beschreibung Die Einkäufergruppe bezeichnet die Person oder das Team, die beziehungsweise das für eine bestimmte Beschaffungsaktivität zuständig ist. Sie ist die zentrale Anlaufstelle für Lieferanten. Dieses Attribut ermöglicht eine detailliertere Analyse als die Einkaufsorganisation. Es hilft, die Arbeitslast unter den Einkäufern zu verstehen und Leistungsunterschiede auf Ebene der einzelnen Einkäufer zu erkennen. Diese Erkenntnisse können in die Ressourcenplanung und in Schulungsmaßnahmen einfließen. Warum das wichtig ist Ermöglicht eine detaillierte Übersicht darüber, wer für einen Einkauf verantwortlich ist. So lassen sich Arbeitsaufkommen und Leistung auf Ebene einzelner Einkäufer oder Teams analysieren. Woher beziehen Tabelle: EKKO, Feld: EKGRP Beispiele 001002N01 | |||
| Einkaufsorganisation PurchasingOrganization | Die Organisationseinheit, die für Preisverhandlungen und die Beschaffung von Materialien oder Dienstleistungen zuständig ist. | ||
| Beschreibung Die Einkaufsorganisation ist eine wichtige Organisationseinheit in SAP, die für Beschaffungsaktivitäten zuständig ist. Sie kann zentral für das gesamte Unternehmen oder dezentral nach Werk oder Region organisiert sein. Die Analyse der Prozessleistung nach Einkaufsorganisation zeigt, welche Beschaffungsteams besonders effizient arbeiten. Kennzahlen wie Zykluszeit, Nacharbeitsquote und Kosten lassen sich zwischen Organisationseinheiten vergleichen. So werden bewährte Vorgehensweisen und Bereiche mit Unterstützungsbedarf sichtbar. Warum das wichtig ist Kennzeichnet das zuständige Beschaffungsteam und ermöglicht Leistungsvergleiche sowie Analysen zwischen verschiedenen Organisationseinheiten. Woher beziehen Tabelle: EKKO, Feld: EKORG Beispiele 1000US01DE01 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten zuletzt aus dem Quellsystem aktualisiert wurden. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder -aktualisierung. So lässt sich die Aktualität der analysierten Daten einordnen. Die Anzeige dieser Information in Dashboards ist wichtig, damit Benutzer erkennen, ob die Erkenntnisse auf nahezu aktuellen Daten oder auf einem historischen Datenstand beruhen. Das schafft klare Erwartungen und stellt sicher, dass Entscheidungen auf Grundlage von Daten mit bekanntem Aktualitätsstand getroffen werden. Warum das wichtig ist Informiert Benutzer über die Aktualität der Daten und zeigt, ob die Analyse den neuesten Betriebsstand widerspiegelt. Woher beziehen Dieser Timestamp wird bei der Ausführung durch den Datenextraktions- oder ETL-Prozess erzeugt und hinzugefügt. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Lieferantenname VendorName | Der rechtliche Name des Lieferanten. | ||
| Beschreibung Der ausgeschriebene Name des Lieferanten, der verständlicher ist als die Lieferantennummer. Er stammt üblicherweise aus den Lieferantenstammdaten. Die Lieferantennummer dient zum Verknüpfen und zur eindeutigen Identifizierung. Der Lieferantenname ist dagegen für Dashboards und Berichte wichtig, die sich an Benutzer richten. Er macht Analysen für Fachanwender verständlicher, die mit den Lieferantencodes möglicherweise nicht vertraut sind. Warum das wichtig ist Zeigt den Lieferanten unter einem verständlichen Namen an und erleichtert Fachanwendern die Auswertung von Dashboards und Berichten. Woher beziehen Tabelle: LFA1, Feld: NAME1. Dazu ist eine Verknüpfung von EKKO-LIFNR mit LFA1-LIFNR erforderlich. Beispiele Staples Inc.Global Tech SolutionsOffice Supply Co. | |||
| Pünktliche Lieferung IsOnTimeDelivery | Kennzeichnet, ob die Waren am angeforderten Liefertermin oder früher eingegangen sind. | ||
| Beschreibung Dieses boolesche Attribut ist wahr, wenn der Timestamp der Aktivität „Wareneingang gebucht“ am oder vor dem „Angeforderten Liefertermin“ liegt. Damit wird die Lieferleistung für jede Bestellposition eindeutig als erfüllt oder nicht erfüllt ausgewiesen. Das Attribut bildet die Grundlage für die Kennzahl „Quote pünktlicher Wareneingänge“. Es vereinfacht die Analyse der Lieferantenleistung und der internen Wareneingangseffizienz, da pünktliche und verspätete Lieferungen einfach aggregiert und gefiltert werden können. Warum das wichtig ist Liefert eine eindeutige Kennzahl zur Pünktlichkeit der Lieferungen und unterstützt direkt Kennzahlen und Dashboards zur Lieferantenleistung. Woher beziehen Dieses berechnete Attribut ergibt sich aus dem Vergleich des Buchungsdatums des Wareneingangs (EKBE-BUDAT) mit dem angeforderten Liefertermin (EKPO-EINDT). Beispiele truefalse | |||
| Quellsystem SourceSystem | Das System, aus dem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut kennzeichnet die Herkunft der Daten. In der Regel handelt es sich um eine SAP-ECC-Instanzkennung, etwa „ECC_PROD_100“. In Umgebungen mit mehreren Systemen lassen sich damit die Datenquellen unterscheiden. Für Governance und Datenherkunft ist die Kenntnis des Quellsystems entscheidend. Sie unterstützt die Sicherung der Datenintegrität und die Fehlersuche bei Problemen mit der Datenextraktion oder -qualität, insbesondere wenn Daten aus verschiedenen ERP-Systemen oder Modulen zusammengeführt werden. Warum das wichtig ist Kennzeichnet die Herkunft der Daten. Das ist entscheidend für Data Governance, Validierung und die Verwaltung von Analysen über mehrere Systeme hinweg. Woher beziehen In der Regel wird während der Datenextraktion ein statischer Wert hinzugefügt, der den Datensatz mit seinem Ursprungssystem kennzeichnet. Beispiele SAP_ECC_PRODECC_EU_100S4H_FIN | |||
| Währung Currency | Der Währungscode des Bestellbetrags. | ||
| Beschreibung Dieses Attribut gibt an, in welcher Währung der Bestellwert ausgewiesen wird, etwa USD, EUR oder GBP. Es liefert den notwendigen Kontext für alle Geldbeträge. Für international tätige Unternehmen ist die Währung eine wichtige Grundlage für korrekte Finanzanalysen. Sie ermöglicht die sachgerechte Aggregation und den Vergleich von Bestellwerten. Alle monetären Kennzahlen müssen im Kontext der jeweiligen Währung interpretiert werden. Warum das wichtig ist Liefert den erforderlichen Kontext für alle Geldbeträge und ermöglicht korrekte Finanzanalysen, insbesondere in multinationalen Unternehmen. Woher beziehen Tabelle: EKKO, Feld: WAERS Beispiele USDEURJPY | |||
| Werk Plant | Der physische Standort oder das Werk, an das die Waren geliefert werden sollen. | ||
| Beschreibung Das Werk ist eine Organisationseinheit und steht für eine Produktionsstätte, ein Lager oder einen anderen Standort, an dem Waren oder Dienstleistungen eingehen. Die Analyse nach Werk zeigt geografische Unterschiede im Beschaffungsprozess. Sie kann beispielsweise abweichende Lieferzeiten von Lieferanten an bestimmte Standorte aufdecken oder Werke mit ineffizienten Wareneingangsprozessen identifizieren. So lässt sich die Pünktlichkeit des Wareneingangs besser beurteilen. Warum das wichtig ist Gibt den Lieferstandort an und eignet sich zur Analyse regionaler Prozessunterschiede und der Logistikleistung. Woher beziehen Tabelle: EKPO, Feld: WERKS Beispiele 100011002000 | |||
Aktivitäten für Purchase to Pay – Bestellung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Bestellanforderung angelegt | Diese Aktivität kennzeichnet die Erstellung einer formellen Anforderung für Waren oder Dienstleistungen. Das Ereignis wird explizit erfasst, wenn ein Benutzer ein neues Bestellanforderungsdokument speichert, beispielsweise über die Transaktion ME51N. Dabei entsteht ein eindeutiger Datensatz in der Tabelle EBAN. | ||
| Warum das wichtig ist Dies ist der zentrale Startpunkt des Beschaffungsprozesses. Die Zeitspanne zwischen diesem Ereignis und der Erstellung der Bestellung zeigt, wie effizient interne Bedarfe in konkrete Bestellungen überführt werden. Woher beziehen Das Ereignis wird erfasst, sobald ein Eintrag in der Kopftabelle der Bestellanforderungen (EBAN) angelegt wird. Erstellungsdatum (EBAN-BADAT) und -Uhrzeit dienen als Timestamp. Erfassung Ermitteln Sie anhand des Erstellungsdatums neue Einträge in der Tabelle EBAN. Ereignistyp explicit | |||
| Bestellung abgeschlossen | Dieses Ereignis zeigt an, dass eine Bestellposition als vollständig geliefert gilt. Es wird üblicherweise daraus abgeleitet, dass das Kennzeichen „Lieferung abgeschlossen“ für die Bestellposition automatisch oder manuell gesetzt wurde. | ||
| Warum das wichtig ist Diese Aktivität bildet den logischen Endpunkt der Auftragsabwicklung. Sie ist entscheidend für die Berechnung der gesamten Zykluszeit der Bestellung von der Erstellung bis zum Abschluss. Woher beziehen Das Ereignis wird aus den Änderungsbelegen (CDHDR/CDPOS) abgeleitet, die erfassen, wann das Kennzeichen „Lieferung abgeschlossen“ (EKPO-ELIKZ) für eine Bestellposition auf „X“ gesetzt wird. Wenn die letzte Position als abgeschlossen markiert ist, kann dies den Abschluss der gesamten Bestellung anzeigen. Erfassung Ermitteln Sie anhand der Änderungsbelege den Timestamp, zu dem das Kennzeichen EKPO-ELIKZ gesetzt wird. Ereignistyp inferred | |||
| Bestellung an Lieferanten gesendet | Diese Aktivität kennzeichnet den Zeitpunkt, zu dem die genehmigte Bestellung offiziell an den Lieferanten übermittelt wird, beispielsweise per EDI, E-Mail oder Druck. Das Ereignis wird explizit in den Nachrichtensteuerungstabellen erfasst, wenn eine Ausgabenachricht erfolgreich verarbeitet wurde. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein markiert den Beginn der Lieferzeit des Lieferanten. Die Zeitspanne von diesem Ereignis bis zum Wareneingang ist entscheidend für die Bewertung der Lieferantenleistung und der Pünktlichkeit. Woher beziehen Das Ereignis wird in der Nachrichtenstatustabelle (NAST) erfasst. Als Timestamp dienen NAST-DATVR und NAST-UHRVR, wenn der Verarbeitungsstatus (NAST-VSTAT) für die betreffende Bestellausgabe auf „1“ (erfolgreich verarbeitet) steht. Erfassung Verwenden Sie den Verarbeitungs-Timestamp der Ausgabenachricht zur Bestellung aus der Tabelle NAST. Ereignistyp explicit | |||
| Bestellung angelegt | Diese Aktivität kennzeichnet die Erstellung eines formellen Bestelldokuments, das einen verbindlichen Vertrag mit einem Lieferanten darstellt. Das Ereignis wird explizit erfasst, wenn ein Benutzer eine Bestellung anlegt und speichert, beispielsweise über die Transaktion ME21N. Dabei entstehen Einträge in den Tabellen EKKO und EKPO. | ||
| Warum das wichtig ist Damit beginnt offiziell der Lebenszyklus der Bestellung. Dieser Meilenstein dient als Grundlage für die Messung der Umwandlungszeit von der Bestellanforderung zur Bestellung sowie der gesamten Auftragsabwicklungszeit. Woher beziehen Der Timestamp wird aus dem Erstellungsdatum (EKKO-AEDAT) in der Kopftabelle der Bestellungen (EKKO) für die jeweilige Bestellnummer (EKKO-EBELN) übernommen. Erfassung Verwenden Sie für jede neue Bestellung den Erstellungs-Timestamp aus der Tabelle EKKO. Ereignistyp explicit | |||
| Bestellung genehmigt | Dieses Ereignis steht für die endgültige Genehmigung der Bestellung. Damit kann sie an den Lieferanten gesendet werden. Dieser wichtige Meilenstein wird üblicherweise aus einer Änderung des Freigabestatus der Bestellung in den Status „vollständig freigegeben“ oder „genehmigt“ abgeleitet. | ||
| Warum das wichtig ist Diese Aktivität ist entscheidend für die Berechnung der Kennzahl zur Genehmigungszykluszeit der Bestellung und für das Erkennen von Engpässen im Genehmigungs-Workflow. Sie ist Voraussetzung für die meisten nachfolgenden Aktivitäten, etwa das Senden der Bestellung an den Lieferanten. Woher beziehen Das Ereignis wird ermittelt, indem die Änderungsbelege (CDHDR/CDPOS) zur Kopftabelle der Bestellung (EKKO) daraufhin geprüft werden, wann der endgültige Freigabecode angewendet oder der Gesamtfreigabestatus (EKKO-FRGKE) auf „freigegeben“ gesetzt wurde. Erfassung Ermitteln Sie den Timestamp, zu dem sich der Gesamtfreigabestatus der Bestellung (EKKO-FRGKE) in den endgültigen Genehmigungsstatus ändert. Ereignistyp inferred | |||
| Wareneingang gebucht | Diese Aktivität kennzeichnet den physischen Eingang von Waren eines Lieferanten zu einer bestimmten Bestellung. Die Buchung des Wareneingangs ist eine explizite Aktion, beispielsweise über die Transaktion MIGO. Dabei wird ein Materialbeleg angelegt und der Bestand aktualisiert. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein dient der Überwachung der Lieferanten-Lieferleistung und markiert den Beginn der Rechnungsprüfung. Er wird zur Berechnung der pünktlichen Lieferungen und der Pünktlichkeit des Wareneingangs herangezogen. Woher beziehen Das Ereignis wird beim Anlegen eines Materialbelegs erfasst. Als Timestamp dient das Buchungsdatum (MKPF-BUDAT) oder das Erstellungsdatum (MKPF-CPUDT) aus der Materialbelegkopftabelle (MKPF). Über die Positionstabelle (MSEG) ist der Beleg mit der Bestellung verknüpft. Erfassung Verwenden Sie den Buchungs- oder Erstellungs-Timestamp aus der Tabelle MKPF für Materialbelege mit Bezug zur Bestellung. Ereignistyp explicit | |||
| Bestellanforderung genehmigt | Dieses Ereignis steht für die formelle Genehmigung einer Bestellanforderung. Damit ist sie zur Umwandlung in eine Bestellung freigegeben. Das Ereignis wird aus Änderungen der Freigabestatusfelder in den Daten der Bestellanforderung abgeleitet, die SAPs Freigabestrategie-Workflow erfasst. | ||
| Warum das wichtig ist Die Erfassung von Genehmigungen ist entscheidend, um Engpässe in der Phase vor der Bestellung zu erkennen und die Einhaltung der Genehmigungsrichtlinien sicherzustellen. Verzögerungen wirken sich unmittelbar auf die gesamte Zykluszeit der Beschaffung aus. Woher beziehen Das Ereignis wird aus den Änderungsbelegen zur Tabelle der Bestellanforderungen (EBAN) abgeleitet. Dabei werden insbesondere Änderungen an den Freigabestatusfeldern überwacht, etwa EBAN-FRGZU. Alternativ lassen sich die Änderungsbelege in CDHDR/CDPOS für das Objekt EBAN analysieren. Erfassung Überwachen Sie die Änderungsbelege zu den Freigabestatusfeldern in EBAN, um den Timestamp der endgültigen Genehmigung zu ermitteln. Ereignistyp inferred | |||
| Bestellung abgelehnt | Diese Aktivität tritt ein, wenn ein Genehmigender eine Bestellung während des Genehmigungs-Workflows ablehnt. Das Ereignis wird aus einer Statusänderung in den Freigabedaten der Bestellung abgeleitet, die eine Ablehnung anzeigt. | ||
| Warum das wichtig ist Die Erfassung von Ablehnungen hilft, Probleme mit der Datenqualität der Bestellung, Verstöße gegen Richtlinien oder Schwachstellen in der Genehmigungsmatrix zu erkennen. Häufig sind Nacharbeiten und längere Durchlaufzeiten die Folge. Woher beziehen Das Ereignis wird aus Änderungsbelegen (CDHDR/CDPOS) zum Freigabestatus der Bestellung abgeleitet. Eine Ablehnung wird üblicherweise erfasst, wenn ein Freigabecode zurückgenommen oder ein bestimmter Ablehnungsstatus gesetzt wird. Erfassung Überwachen Sie die Änderungsbelege auf die Rücknahme eines Freigabecodes oder eine Statusänderung, die eine Ablehnung anzeigt. Ereignistyp inferred | |||
| Bestellung geändert | Dieses Ereignis umfasst alle Änderungen an einer Bestellung nach ihrer erstmaligen Erstellung, etwa an Menge, Preis oder Lieferterminen. SAP protokolliert diese Änderungen explizit im Änderungsbelegsystem. | ||
| Warum das wichtig ist Häufige Änderungen, insbesondere nach der Genehmigung, weisen auf ineffiziente Abläufe, unzureichende Planung oder nachträgliche Ausweitung des Umfangs hin. Diese Aktivität ist eine wichtige Grundlage für das Dashboard zu Nacharbeiten und Änderungen an Bestellungen sowie für die zugehörigen Kennzahlen. Woher beziehen Die Änderungen werden explizit in den Tabellen für Änderungsbelegkopf (CDHDR) und -positionen (CDPOS) zum Bestellobjekt (EINKBELEG) protokolliert. Für jede Änderung wird ein neuer Eintrag mit Timestamp angelegt. Erfassung Extrahieren Sie Änderungsereignisse und Timestamps aus den Tabellen CDHDR und CDPOS, die mit der Bestellnummer verknüpft sind. Ereignistyp explicit | |||
| Bestellung gelöscht | Dieses Ereignis steht für die Stornierung oder logische Löschung einer Bestellposition. Dadurch werden weitere Schritte wie Wareneingang oder Rechnungsstellung verhindert. Das Ereignis wird abgeleitet, wenn das Löschkennzeichen für die Bestellposition gesetzt wird. | ||
| Warum das wichtig ist Diese abschließende Aktivität zeigt an, dass eine Bestellung storniert wurde. Die Analyse, warum und wann Bestellungen gelöscht werden, kann Probleme in der Bedarfsplanung oder Lieferantenauswahl aufdecken. Woher beziehen Das Ereignis wird aus Änderungsbelegen (CDHDR/CDPOS) abgeleitet, die zeigen, dass das Löschkennzeichen (EKPO-LOEKZ) für eine Bestellposition auf „L“ gesetzt wurde. Erfassung Ermitteln Sie anhand der Änderungsbelege den Timestamp, zu dem das Kennzeichen EKPO-LOEKZ gesetzt wird. Ereignistyp inferred | |||
| Genehmigung der Bestellung angefordert | Dieses Ereignis zeigt an, dass eine angelegte oder geänderte Bestellung gemäß der konfigurierten Freigabestrategie zur Genehmigung eingereicht wurde. Es wird abgeleitet, wenn die Freigabestrategie ausgelöst wird und die Bestellung den Status „Genehmigung ausstehend“ erhält. | ||
| Warum das wichtig ist Wenn Sie die Erstellung der Bestellung vom Beginn des Genehmigungsprozesses unterscheiden, lässt sich die Kennzahl für die Genehmigungszykluszeit präzise messen. So werden Verzögerungen vor dem Start des Genehmigungs-Workflows sichtbar. Woher beziehen Das Ereignis wird aus Änderungsbelegen (CDHDR/CDPOS) zur Bestellung (Objekt EINKBELEG) abgeleitet, die die erstmalige Festlegung eines Freigabestatus zeigen. Es kann auch ermittelt werden, wenn der Gesamtfreigabestatus (EKKO-FRGKE) erstmals auf einen Wert gesetzt wird, der einen laufenden Genehmigungsprozess anzeigt. Erfassung Ermitteln Sie den ersten Eintrag im Änderungsbeleg, der die Freigabestrategie für die Bestellung auslöst. Ereignistyp inferred | |||
| Leistungserfassung eingegeben | Bei dienstleistungsbezogenen Bestellungen steht diese Aktivität für die Bestätigung, dass die Leistungen erbracht wurden. Das Ereignis wird explizit durch das Anlegen eines Leistungserfassungsblatts erfasst, beispielsweise über die Transaktion ML81N. | ||
| Warum das wichtig ist Bei Dienstleistungen entspricht dies dem Wareneingang und ist entscheidend für die Überwachung der Erfüllung von Dienstleistungsaufträgen. Damit wird der Zahlungsprozess für die Dienstleistung angestoßen. Woher beziehen Der Timestamp wird aus dem Erstellungsdatum (ESSR-ERDAT) in der Kopftabelle des Leistungserfassungsblatts (ESSR) übernommen. Die Verknüpfung zur Bestellung befindet sich in der Tabelle ESLL. Erfassung Verwenden Sie den Erstellungs-Timestamp aus der Tabelle ESSR für Leistungserfassungsblätter mit Bezug zur Bestellung. Ereignistyp explicit | |||
| Qualitätsprüfung durchgeführt | Dieses Ereignis zeigt an, dass die eingegangenen Waren einer Qualitätsprüfung unterzogen wurden. Es wird üblicherweise abgeleitet, wenn für ein Prüflos, das beim Wareneingang angelegt wurde, im Qualitätsmanagement eine Verwendungsentscheidung getroffen wird. | ||
| Warum das wichtig ist In Branchen mit hohen Qualitätsanforderungen hilft diese Aktivität, Dauer und Ergebnisse des Prüfprozesses zu analysieren. Verzögerungen können Engpässe zwischen Wareneingang und Verfügbarkeit der Waren verursachen. Woher beziehen Das Ereignis wird aus dem Qualitätsmanagement abgeleitet. Beim Wareneingang wird ein Prüflos angelegt (Tabelle QALS). Die Aktivität wird durch das Anlegen einer Verwendungsentscheidung (Tabelle QAVE) gekennzeichnet, die einen Timestamp enthält. Erfassung Ermitteln Sie den Timestamp der Verwendungsentscheidung in der Tabelle QAVE für das mit dem Materialbeleg verknüpfte Prüflos. Ereignistyp inferred | |||
| Waren zurückgesendet | Dieses Ereignis steht für die Rücksendung zuvor eingegangener Waren an den Lieferanten, häufig aufgrund von Qualitätsproblemen oder einer fehlerhaften Lieferung. Es wird explizit durch die Buchung eines Materialbelegs mit einer speziellen Retourenbewegungsart erfasst. | ||
| Warum das wichtig ist Diese Aktivität weist auf Probleme mit der Lieferantenqualität oder der Bestellgenauigkeit hin und ist ein wichtiger Indikator für Nacharbeiten im Prozess. Sie ist entscheidend für die Berechnung der Kennzahl zur Abweichungsquote beim Wareneingang. Woher beziehen Das Ereignis wird in den Materialbelegtabellen (MKPF/MSEG) erfasst, wenn eine Retourenbewegungsart verwendet wird, etwa „122“ für die Rücklieferung an den Lieferanten. Als Timestamp dient das Buchungsdatum (MKPF-BUDAT). Erfassung Ermitteln Sie Materialbelege mit einer Retourenbewegungsart, beispielsweise 122, die sich auf die ursprüngliche Bestellung beziehen. Ereignistyp explicit | |||
Anleitungen zum Datenexport
Schritte
- ABAP-Programm erstellen: Öffnen Sie den ABAP Editor mit dem Transaktionscode SE38. Geben Sie einen Namen für das neue Programm ein, zum Beispiel Z_PM_PO_EXTRACT, und klicken Sie auf „Erstellen“. Vergeben Sie einen Titel wie „Process Mining PO Data Extraction“ und wählen Sie als Typ „Ausführbares Programm“.
- Selektionsbildschirm definieren: Legen Sie im Programm die Parameter für den Selektionsbildschirm fest. Damit können Benutzer die zu exportierenden Daten filtern. Zu den wichtigsten Parametern gehören der Zeitraum für das Erstellungsdatum der Bestellung, der Buchungskreis (BUKRS) und die Einkaufsbelegart (BSART).
- Datenstrukturen definieren: Deklarieren Sie eine interne Tabellenstruktur, die dem endgültigen Format des Event Logs entspricht. Sie sollte alle erforderlichen und empfohlenen Attribute enthalten: PurchaseOrder, Activity, EventTime, UserName, VendorNumber, OrderAmount, MaterialGroup, CompanyCode und DocumentType.
- Logik zur Datenauswahl implementieren: Schreiben Sie die zentrale ABAP-Logik, um Daten für jede der 14 erforderlichen Aktivitäten auszuwählen. Dazu werden mehrere SAP-Tabellen abgefragt, darunter EKKO, EKPO, EKBE, EBAN, CDHDR, CDPOS und NAST. Verwenden Sie für jede Aktivität eine eigene Unterroutine (PERFORM), damit der Code übersichtlich bleibt.
- Daten zu Bestellanforderungen auswählen: Fragen Sie die Tabelle EBAN nach Ereignissen vom Typ „Bestellanforderung erstellt“ ab und verknüpfen Sie diese über die Tabelle EKPO mit Bestellungen. Ermitteln Sie Ereignisse vom Typ „Bestellanforderung freigegeben“ anhand der Änderungstabellen CDHDR und CDPOS, indem Sie Änderungen an den Freigabestatusfeldern nachverfolgen.
- Zentrale Bestellereignisse auswählen: Fragen Sie die Tabellen EKKO und EKPO nach dem Ereignis „Bestellung erstellt“ ab. Verwenden Sie die Änderungstabellen CDHDR und CDPOS für das Objekt EINKBELEG, um anhand von Änderungen an bestimmten Feldern wie Freigabekennzeichen und Löschkennzeichen die Ereignisse „Bestellung geändert“, „Bestellung freigegeben“, „Bestellung abgelehnt“, „Bestellung abgeschlossen“ und „Bestellung gelöscht“ zu ermitteln.
- Kommunikationsereignisse zu Bestellungen auswählen: Fragen Sie die Tabelle NAST nach erfolgreich übermittelten Bestellungen ab und erfassen Sie die Aktivität „Bestellung an Lieferanten gesendet“.
- Waren- und Dienstleistungsereignisse auswählen: Fragen Sie die Tabelle EKBE nach Materialbelegbuchungen ab, um anhand der Bewegungsartkategorie die Aktivitäten „Wareneingang gebucht“ und „Waren zurückgesendet“ zu ermitteln. Fragen Sie ESSR und ESLL nach Leistungserfassungsblättern ab, um die Aktivität „Leistungserfassung bestätigt“ zu erfassen.
- Ereignisse des Qualitätsmanagements auswählen: Wenn das Qualitätsmanagement-Modul verwendet wird, fragen Sie die Tabellen QALS und QAVE ab, um festzustellen, wann für ein mit einer Bestellung verknüpftes Prüflos ein Verwendungsentscheid getroffen wurde. Dies entspricht der Aktivität „Qualitätsprüfung durchgeführt“.
- Daten zusammenführen und formatieren: Führen Sie die Daten aus allen einzelnen Abfragen in einer internen Tabelle zusammen. Achten Sie auf ein einheitliches Format für das Feld EventTime, zum Beispiel YYYY-MM-DDTHH:MI:SS.
- Datei-Download implementieren: Ergänzen Sie eine Funktion, mit der die endgültige interne Tabelle als Datei heruntergeladen werden kann. Empfohlen wird eine Datei mit Tabulatortrennung oder im CSV-Format. Dafür können Sie das Funktionsmodul GUI_DOWNLOAD verwenden.
- Ausführen und speichern: Führen Sie das Programm über die Transaktion SE38 oder SA38 aus. Geben Sie die Selektionskriterien ein und starten Sie den Report. Speichern Sie die Ausgabedatei bei entsprechender Aufforderung mit der Dateiendung .csv auf Ihrem lokalen Rechner. Sie ist dann für den Upload bereit.
Konfiguration
- Zeitraum: Legen Sie unbedingt einen bestimmten Zeitraum für den Datenexport fest, in der Regel anhand des Erstellungsdatums der Bestellung (EKKO-AEDAT). Ein Zeitraum von 3 bis 6 Monaten ist oft ein guter Ausgangspunkt, um Datenvolumen und Aussagekraft der Prozessanalyse auszubalancieren.
- Buchungskreis (BUKRS): Filtern Sie nach einem oder mehreren Buchungskreisen, um den Export auf relevante Rechtsträger zu beschränken. Dieser Parameter ist wichtig für Leistung und Relevanz der Analyse.
- Einkaufsbelegart (BSART): Filtern Sie nach bestimmten Belegarten, zum Beispiel „NB“ für Standardbestellungen. So konzentrieren Sie die Analyse auf Standardprozesse und schließen bei Bedarf Sonderbeschaffungen aus.
- Datengranularität: Der Export ist auf Ebene der Bestellpositionen ausgelegt. Die Case-ID ist die Bestellnummer (EBELN). Alle Ereignisse, auch solche auf Positionsebene wie Wareneingänge, werden dieser übergeordneten Case-ID zugeordnet.
- Leistungsaspekte: Bei großen Datenmengen sollten Sie das Programm als Hintergrundjob (SM36) einplanen, um Zeitüberschreitungen zu vermeiden. Stellen Sie sicher, dass für wichtige Felder in WHERE-Klauseln, insbesondere in Tabellen wie CDHDR und CDPOS, Datenbankindizes vorhanden sind.
- Voraussetzungen: Der Benutzer, der den Report ausführt, benötigt Zugriff auf die ABAP Workbench (SE38) für Entwicklung und Ausführungsberechtigungen für das Programm. Außerdem ist Lesezugriff auf alle zugrunde liegenden Tabellen erforderlich, darunter EKKO, EKPO, EKBE, CDHDR, CDPOS, EBAN, NAST, ESSR und QM-Tabellen.
Beispielabfrage abap
REPORT Z_PM_PO_EXTRACT.
TABLES: ekko, ekpo, eban.
*&---------------------------------------------------------------------*
*& Data Structures for Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
purchaseorder TYPE ebeln,
activity TYPE string,
eventtime TYPE timestamp,
username TYPE ernam,
vendornumber TYPE lifnr,
orderamount TYPE netwr_ak,
materialgroup TYPE matkl,
companycode TYPE bukrs,
documenttype TYPE bsart,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_aedat FOR ekko-aedat OBLIGATORY, " PO Creation Date
s_bukrs FOR ekko-bukrs, " Company Code
s_bsart FOR ekko-bsart, " PO Document Type
s_ebeln FOR ekko-ebeln. " PO Number
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
PERFORM get_po_headers.
IF gt_event_log IS NOT INITIAL.
PERFORM get_pr_created.
PERFORM get_pr_approved.
PERFORM get_po_created.
PERFORM get_po_release_events. " Approved, Rejected, Approval Requested
PERFORM get_po_sent_to_vendor.
PERFORM get_po_changed.
PERFORM get_goods_receipt_posted.
PERFORM get_services_confirmed.
PERFORM get_quality_inspection.
PERFORM get_goods_returned.
PERFORM get_po_completed.
PERFORM get_po_deleted.
PERFORM download_to_csv.
ELSE.
MESSAGE 'No Purchase Orders found for the given criteria.' TYPE 'I'.
ENDIF.
*&---------------------------------------------------------------------*
*& Form GET_PO_HEADERS (Base data)
*&---------------------------------------------------------------------*
FORM get_po_headers.
SELECT h~ebeln, h~lifnr, h~bukrs, h~bsart, p~netwr, p~matkl
FROM ekko AS h
INNER JOIN ekpo AS p ON h~ebeln = p~ebeln
INTO TABLE @DATA(lt_po_base)
WHERE h~aedat IN @s_aedat
AND h~bukrs IN @s_bukrs
AND h~bsart IN @s_bsart
AND h~ebeln IN @s_ebeln.
SORT lt_po_base BY ebeln.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PR_CREATED
*&---------------------------------------------------------------------*
FORM get_pr_created.
DATA: lt_pr_events TYPE TABLE OF ty_event_log.
SELECT p~ebeln AS purchaseorder,
'Purchase Requisition Created' AS activity,
b~erdat AS event_date,
'000000' AS event_time,
b~ernam AS username,
h~lifnr AS vendornumber,
p~netwr AS orderamount,
p~matkl AS materialgroup,
h~bukrs AS companycode,
h~bsart AS documenttype
FROM ekpo AS p
JOIN eban AS b ON p~banfn = b~banfn AND p~bnfpo = b~bnfpo
JOIN ekko AS h ON p~ebeln = h~ebeln
WHERE p~ebeln IN @s_ebeln
AND p~banfn IS NOT NULL AND p~banfn <> ''
AND h~aedat IN @s_aedat
AND h~bukrs IN @s_bukrs
AND h~bsart IN @s_bsart
INTO TABLE @DATA(lt_pr_created).
LOOP AT lt_pr_created ASSIGNING FIELD-SYMBOL(<fs_pr>).
DATA(ls_event) = CORRESPONDING ty_event_log(<fs_pr>).
CONCATENATE <fs_pr>-event_date <fs_pr>-event_time INTO DATA(lv_ts).
CONVERT DATE <fs_pr>-event_date TIME '000000' INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PR_APPROVED
*&---------------------------------------------------------------------*
FORM get_pr_approved.
DATA: lt_pr_list TYPE TABLE OF eban-banfn.
SELECT DISTINCT p~banfn FROM ekpo AS p
JOIN ekko AS h ON p~ebeln = h~ebeln
WHERE h~aedat IN @s_aedat
AND h~bukrs IN @s_bukrs
AND p~banfn IS NOT NULL AND p~banfn <> ''
INTO TABLE @lt_pr_list.
IF lt_pr_list IS INITIAL. RETURN. ENDIF.
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectid = p~objectid AND h~changenr = p~changenr
FOR ALL ENTRIES IN @lt_pr_list
WHERE h~objectclas = 'BANF'
AND h~objectid = @lt_pr_list-table_line
AND p~tabname = 'EBAN'
AND p~fname = 'FRGZU'
INTO TABLE @DATA(lt_cd_pr).
LOOP AT lt_cd_pr ASSIGNING FIELD-SYMBOL(<fs_cd>) WHERE <fs_cd>-value_new = 'X'.
SELECT SINGLE p~ebeln, p~netwr, p~matkl, h~lifnr, h~bukrs, h~bsart
FROM ekpo AS p
JOIN ekko AS h ON p~ebeln = h~ebeln
WHERE p~banfn = @<fs_cd>-objectid(10)
INTO @DATA(ls_po_info).
IF sy-subrc = 0.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = ls_po_info-ebeln
activity = 'Purchase Requisition Approved'
username = <fs_cd>-username
vendornumber = ls_po_info-lifnr
orderamount = ls_po_info-netwr
materialgroup = ls_po_info-matkl
companycode = ls_po_info-bukrs
documenttype = ls_po_info-bsart
).
CONVERT DATE <fs_cd>-udate TIME <fs_cd>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PO_CREATED
*&---------------------------------------------------------------------*
FORM get_po_created.
LOOP AT lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>).
SELECT SINGLE aedat, ernam FROM ekko INTO @DATA(ls_ekko)
WHERE ebeln = @<fs_po>-ebeln.
IF sy-subrc = 0.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Purchase Order Created'
username = ls_ekko-ernam
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE ls_ekko-aedat TIME '000000' INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PO_RELEASE_EVENTS
*&---------------------------------------------------------------------*
FORM get_po_release_events.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT h~objectid, h~username, h~udate, h~utime, p~value_new
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectid = p~objectid AND h~changenr = p~changenr
WHERE h~objectclas = 'EINKBELEG'
AND h~objectid IN lt_ebeln
AND p~tabname = 'EKKO'
AND p~fname = 'FRGKE'
INTO TABLE @DATA(lt_cd_po).
LOOP AT lt_cd_po ASSIGNING FIELD-SYMBOL(<fs_cd>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_cd>-objectid.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
username = <fs_cd>-username
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_cd>-udate TIME <fs_cd>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
CASE <fs_cd>-value_new.
WHEN '2' OR 'R'. " Final Release
ls_event-activity = 'Purchase Order Approved'.
WHEN '1'. " Blocked
ls_event-activity = 'Purchase Order Rejected'.
WHEN OTHERS. " Any other change implies a pending state
ls_event-activity = 'Purchase Order Approval Requested'.
ENDCASE.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PO_SENT_TO_VENDOR
*&---------------------------------------------------------------------*
FORM get_po_sent_to_vendor.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT objky, erdat, eruhr, ernam
FROM nast
WHERE kapol = 'EF' AND objky IN lt_ebeln AND vstat = '1'
INTO TABLE @DATA(lt_nast).
LOOP AT lt_nast ASSIGNING FIELD-SYMBOL(<fs_nast>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_nast>-objky.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Purchase Order Sent to Vendor'
username = <fs_nast>-ernam
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_nast>-erdat TIME <fs_nast>-eruhr INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PO_CHANGED
*&---------------------------------------------------------------------*
FORM get_po_changed.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT DISTINCT objectid, username, udate, utime
FROM cdhdr
WHERE objectclas = 'EINKBELEG' AND objectid IN lt_ebeln AND tcode <> 'ME21N' AND tcode <> 'ME22'
INTO TABLE @DATA(lt_cdhdr_chg).
LOOP AT lt_cdhdr_chg ASSIGNING FIELD-SYMBOL(<fs_cd>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_cd>-objectid.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Purchase Order Changed'
username = <fs_cd>-username
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_cd>-udate TIME <fs_cd>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_GOODS_RECEIPT_POSTED
*&---------------------------------------------------------------------*
FORM get_goods_receipt_posted.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT k~ebeln, m~cpudt, m~cputm, m~usnam, k~bewtp
FROM ekbe AS k JOIN mkpf AS m ON k~belnr = m~mblnr AND k~gjahr = m~mjahr
WHERE k~ebeln IN lt_ebeln AND k~bewtp = 'E' AND k~shkzg = 'S'
INTO TABLE @DATA(lt_gr).
LOOP AT lt_gr ASSIGNING FIELD-SYMBOL(<fs_gr>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_gr>-ebeln.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Goods Receipt Posted'
username = <fs_gr>-usnam
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_gr>-cpudt TIME <fs_gr>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_SERVICES_CONFIRMED
*&---------------------------------------------------------------------*
FORM get_services_confirmed.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT l~ebeln, h~erdat, h~eruhr, h~ernam
FROM essr AS h JOIN esll AS l ON h~lblni = l~lblni
WHERE l~ebeln IN lt_ebeln
INTO TABLE @DATA(lt_ses).
LOOP AT lt_ses ASSIGNING FIELD-SYMBOL(<fs_ses>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_ses>-ebeln.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Services Confirmation Entered'
username = <fs_ses>-ernam
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_ses>-erdat TIME <fs_ses>-eruhr INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_QUALITY_INSPECTION
*&---------------------------------------------------------------------*
FORM get_quality_inspection.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT q~ebeln, v~vdatum, v~vzeit, v~vname
FROM qals AS q JOIN qave AS v ON q~prueflos = v~prueflos
WHERE q~ebeln IN lt_ebeln
INTO TABLE @DATA(lt_qm).
LOOP AT lt_qm ASSIGNING FIELD-SYMBOL(<fs_qm>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_qm>-ebeln.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Quality Inspection Performed'
username = <fs_qm>-vname
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_qm>-vdatum TIME <fs_qm>-vzeit INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_GOODS_RETURNED
*&---------------------------------------------------------------------*
FORM get_goods_returned.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT k~ebeln, m~cpudt, m~cputm, m~usnam
FROM ekbe AS k JOIN mkpf AS m ON k~belnr = m~mblnr AND k~gjahr = m~mjahr
WHERE k~ebeln IN lt_ebeln AND k~bwart = '122'
INTO TABLE @DATA(lt_ret).
LOOP AT lt_ret ASSIGNING FIELD-SYMBOL(<fs_ret>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_ret>-ebeln.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Goods Returned'
username = <fs_ret>-usnam
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_ret>-cpudt TIME <fs_ret>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PO_COMPLETED
*&---------------------------------------------------------------------*
FORM get_po_completed.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT h~objectid, h~username, h~udate, h~utime
FROM cdhdr AS h JOIN cdpos AS p ON h~changenr = p~changenr AND h~objectid = p~objectid
WHERE h~objectclas = 'EINKBELEG' AND h~objectid IN lt_ebeln AND p~tabname = 'EKPO' AND p~fname = 'ELIKZ' AND p~value_new = 'X'
INTO TABLE @DATA(lt_cd_comp).
LOOP AT lt_cd_comp ASSIGNING FIELD-SYMBOL(<fs_cd>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_cd>-objectid.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Purchase Order Completed'
username = <fs_cd>-username
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_cd>-udate TIME <fs_cd>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form GET_PO_DELETED
*&---------------------------------------------------------------------*
FORM get_po_deleted.
DATA: lt_ebeln TYPE RANGE OF ebeln, ls_ebeln LIKE LINE OF lt_ebeln.
LOOP AT lt_po_base INTO DATA(ls_po_base).
ls_ebeln-sign = 'I'. ls_ebeln-option = 'EQ'. ls_ebeln-low = ls_po_base-ebeln.
APPEND ls_ebeln TO lt_ebeln.
ENDLOOP.
IF lt_ebeln IS INITIAL. RETURN. ENDIF.
SELECT h~objectid, h~username, h~udate, h~utime
FROM cdhdr AS h JOIN cdpos AS p ON h~changenr = p~changenr AND h~objectid = p~objectid
WHERE h~objectclas = 'EINKBELEG' AND h~objectid IN lt_ebeln AND p~tabname = 'EKPO' AND p~fname = 'LOEKZ' AND p~value_new = 'L'
INTO TABLE @DATA(lt_cd_del).
LOOP AT lt_cd_del ASSIGNING FIELD-SYMBOL(<fs_cd>).
READ TABLE lt_po_base ASSIGNING FIELD-SYMBOL(<fs_po>) WITH KEY ebeln = <fs_cd>-objectid.
IF sy-subrc <> 0. CONTINUE. ENDIF.
DATA(ls_event) = VALUE ty_event_log(
purchaseorder = <fs_po>-ebeln
activity = 'Purchase Order Deleted'
username = <fs_cd>-username
vendornumber = <fs_po>-lifnr
orderamount = <fs_po>-netwr
materialgroup = <fs_po>-matkl
companycode = <fs_po>-bukrs
documenttype = <fs_po>-bsart
).
CONVERT DATE <fs_cd>-udate TIME <fs_cd>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
APPEND ls_event TO gt_event_log.
ENDLOOP.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form DOWNLOAD_TO_CSV
*&---------------------------------------------------------------------*
FORM download_to_csv.
DATA: lv_filename TYPE string.
DATA: lt_fieldnames TYPE TABLE OF string.
APPEND 'PurchaseOrder' TO lt_fieldnames.
APPEND 'Activity' TO lt_fieldnames.
APPEND 'EventTime' TO lt_fieldnames.
APPEND 'UserName' TO lt_fieldnames.
APPEND 'VendorNumber' TO lt_fieldnames.
APPEND 'OrderAmount' TO lt_fieldnames.
APPEND 'MaterialGroup' TO lt_fieldnames.
APPEND 'CompanyCode' TO lt_fieldnames.
APPEND 'DocumentType' TO lt_fieldnames.
DATA(lv_header) = REDUCE string( INIT h = '' FOR f IN lt_fieldnames NEXT h = h && f && cl_abap_char_utilities=>horizontal_tab ).
REPLACE LAST OCCURRENCE OF cl_abap_char_utilities=>horizontal_tab IN lv_header WITH cl_abap_char_utilities=>cr_lf.
DATA(lv_file_content) = lv_header.
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_log>).
DATA lv_line TYPE string.
DATA lv_eventtime_str TYPE string.
lv_eventtime_str = |{ <fs_log>-eventtime TIMESTAMP = ISO }|.
lv_line = <fs_log>-purchaseorder && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-activity && cl_abap_char_utilities=>horizontal_tab &&
lv_eventtime_str && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-username && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-vendornumber && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-orderamount && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-materialgroup && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-companycode && cl_abap_char_utilities=>horizontal_tab &&
<fs_log>-documenttype && cl_abap_char_utilities=>cr_lf.
CONCATENATE lv_file_content lv_line INTO lv_file_content.
ENDLOOP.
CALL METHOD cl_gui_frontend_services=>gui_download
EXPORTING
filename = 'C:\temp\po_event_log.csv'
filetype = 'ASC'
CHANGING
data_tab = lv_file_content. Schritte
- Datenbankverbindung herstellen: Besorgen Sie sich schreibgeschützte Zugangsdaten und Verbindungsinformationen (Hostname, Port, Datenbankname) für die zugrunde liegende SAP-ECC-Datenbank. Stellen Sie sicher, dass die erforderlichen Client-Tools wie DBeaver, SQL Developer oder SSMS installiert sind.
- SAP-Schema ermitteln: Stellen Sie eine Verbindung zur Datenbank her und ermitteln Sie das primäre SAP-Schema, in dem sich die Tabellen befinden. Häufig heißt es SAPSR3, SAPHANADB oder ähnlich, je nach System. Wenn es nicht das Standardschema Ihres Benutzers ist, müssen Sie in der Abfrage allen Tabellennamen dieses Schema voranstellen.
- SQL-Abfrage prüfen: Öffnen Sie das bereitgestellte SQL-Skript in Ihrem Client-Tool. Die Abfrage extrahiert 14 verschiedene Aktivitäten aus dem Purchase-to-Pay-Prozess, indem sie mehrere SAP-Tabellen verknüpft.
- Abfrageparameter anpassen: Suchen Sie am Anfang des Skripts den Common Table Expression (CTE) PO_BASE. Ändern Sie die Platzhalterwerte, um den Umfang des Exports festzulegen:
- [START_DATE] und [END_DATE]: Legen Sie den Analysezeitraum fest, zum Beispiel „20230101“ und „20230630“. Es empfiehlt sich, nach dem Feld AEDAT (Änderungsdatum) zu filtern.
- [COMPANY_CODE_1], [COMPANY_CODE_2]: Geben Sie die einzubeziehenden SAP-Buchungskreise an.
- [DOC_TYPE_1], [DOC_TYPE_2]: Geben Sie die einzubeziehenden Bestellbelegarten an.
- [Your SAP Schema]: Ersetzen Sie diesen Platzhalter im gesamten Skript durch den Namen Ihres SAP-Schemas.
- Abfrage ausführen: Führen Sie das angepasste SQL-Skript für die SAP-Datenbank aus. Die Ausführungsdauer hängt vom Zeitraum, Datenvolumen und der Datenbankleistung ab.
- Ergebnisse prüfen: Überprüfen Sie nach Abschluss der Abfrage kurz die Ausgabe. Achten Sie auf eine plausible Zeilenanzahl und darauf, dass wichtige Spalten wie PurchaseOrder, Activity und EventTime wie erwartet gefüllt sind.
- Daten als CSV exportieren: Exportieren Sie das gesamte Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie UTF-8, um Probleme mit Sonderzeichen zu vermeiden.
- Upload vorbereiten: Stellen Sie sicher, dass die Spaltenüberschriften in der CSV-Datei exakt den erforderlichen Attributnamen entsprechen: PurchaseOrder, Activity, EventTime, UserName, VendorNumber, OrderAmount, MaterialGroup, CompanyCode, DocumentType.
- In Process-Mining-Tool hochladen: Laden Sie die fertige CSV-Datei in Ihre Process-Mining-Anwendung hoch, um die Daten zu analysieren und zu visualisieren.
Konfiguration
- Voraussetzungen: Erforderlich ist direkter, schreibgeschützter Zugriff auf die zugrunde liegende SAP-ECC-Datenbank. Benutzer benötigen ausreichende Berechtigungen, um Tabellen wie EKKO, EKPO, EKBE, EBAN, CDHDR, CDPOS und NAST abzufragen.
- Zeitraumfilter: Begrenzen Sie das Datenvolumen unbedingt durch einen Zeitraumfilter. Ein Zeitraum von 3 bis 6 Monaten auf Basis von EKKO.AEDAT (Änderungsdatum der Bestellung) ist ein üblicher Ausgangspunkt. Bei längeren Zeiträumen kann die Abfrage sehr lange dauern.
- Wichtige Datenfilter: Filtern Sie stets nach EKKO.BUKRS (Buchungskreis) und EKKO.BSART (Belegart), damit die Analyse auf relevante Rechtsträger und Geschäftsprozesse beschränkt bleibt.
- Leistungsaspekte: Die Abfrage verknüpft mehrere große Tabellen, darunter die Änderungshistorientabellen CDHDR und CDPOS. Das kann viele Ressourcen beanspruchen. Führen Sie den Export möglichst außerhalb der Spitzenzeiten oder auf einer replizierten Nicht-Produktivdatenbank aus, damit die Systemleistung nicht beeinträchtigt wird.
- Änderungsbelegprotokollierung: Die Genauigkeit der Aktivitäten „Freigegeben“, „Abgelehnt“, „Abgeschlossen“ und „Geändert“ hängt davon ab, ob die Änderungsbelegprotokollierung für die betreffenden SAP-Felder aktiviert ist. Lassen Sie sich von Ihrer SAP-Administration bestätigen, dass die Protokollierung eingeschaltet ist (über die Transaktion SCDO).
Beispielabfrage sql
WITH PO_BASE AS (
SELECT
H.EBELN, -- Purchase Order Number
I.EBELP, -- Purchase Order Item
H.LIFNR, -- Vendor Number
H.BUKRS, -- Company Code
H.BSART, -- Document Type
I.NETWR, -- Order Amount (Item Level)
I.MATKL, -- Material Group
I.BANFN, -- Purchase Requisition Number
I.BNFPO -- Purchase Requisition Item
FROM [Your SAP Schema].EKKO AS H
JOIN [Your SAP Schema].EKPO AS I ON H.EBELN = I.EBELN
WHERE H.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' -- Filter on PO Change Date, e.g., '20230101' and '20231231'
AND H.BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]') -- Specify Company Codes
AND H.BSART IN ('[DOC_TYPE_1]', '[DOC_TYPE_2]') -- Specify PO Document Types
)
-- 1. Purchase Requisition Created
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Requisition Created' AS "Activity",
TO_TIMESTAMP(CONCAT(pr.ERDAT, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime", -- Time is not available in EBAN
pr.ERNAM AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].EBAN pr ON po.BANFN = pr.BANFN AND po.BNFPO = pr.BNFPO
WHERE po.BANFN IS NOT NULL AND po.BANFN <> ''
UNION ALL
-- 2. Purchase Requisition Approved
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Requisition Approved' AS "Activity",
TO_TIMESTAMP(CONCAT(ch.UDATE, ' ', ch.UTIME), 'YYYYMMDD HH24MISS') AS "EventTime",
ch.USERNAME AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].CDHDR ch ON ch.OBJECTCLASS = 'BANF' AND ch.OBJECTID = po.BANFN
JOIN [Your SAP Schema].CDPOS cp ON ch.OBJECTCLASS = cp.OBJECTCLASS AND ch.OBJECTID = cp.OBJECTID AND ch.CHANGENR = cp.CHANGENR
WHERE cp.TABNAME = 'EBAN' AND cp.FNAME = 'FRGZU' AND cp.VALUE_NEW = 'X' -- Release indicator set to 'released'
UNION ALL
-- 3. Purchase Order Created
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Order Created' AS "Activity",
TO_TIMESTAMP(CONCAT(ekko.ERDAT, ' ', ekko.ERZET), 'YYYYMMDD HH24MISS') AS "EventTime",
ekko.ERNAM AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].EKKO ekko ON po.EBELN = ekko.EBELN
UNION ALL
-- 4. Purchase Order Approval Requested / 5. Approved / 6. Rejected (from Change Docs)
SELECT
po.EBELN AS "PurchaseOrder",
CASE
WHEN cp.VALUE_NEW > cp.VALUE_OLD THEN 'Purchase Order Approval Requested'
WHEN cp.VALUE_NEW = ekko.FRGKE AND ekko.FRGKE = 'R' THEN 'Purchase Order Approved'
ELSE 'Purchase Order Rejected' -- Simplified logic, may need adjustment
END AS "Activity",
TO_TIMESTAMP(CONCAT(ch.UDATE, ' ', ch.UTIME), 'YYYYMMDD HH24MISS') AS "EventTime",
ch.USERNAME AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].EKKO ekko ON po.EBELN = ekko.EBELN
JOIN [Your SAP Schema].CDHDR ch ON ch.OBJECTCLASS = 'EINKBELEG' AND ch.OBJECTID = po.EBELN
JOIN [Your SAP Schema].CDPOS cp ON ch.OBJECTCLASS = cp.OBJECTCLASS AND ch.OBJECTID = cp.OBJECTID AND ch.CHANGENR = cp.CHANGENR
WHERE cp.TABNAME = 'EKKO' AND cp.FNAME = 'FRGZU' -- Release status
UNION ALL
-- 7. Purchase Order Sent to Vendor
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Order Sent to Vendor' AS "Activity",
TO_TIMESTAMP(CONCAT(na.ERDAT, ' ', na.ERUHR), 'YYYYMMDD HH24MISS') AS "EventTime",
na.USNAM AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].NAST na ON na.OBJKY = po.EBELN AND na.KSCHL = '[Your PO Output Type]' -- e.g., 'NEU'
WHERE na.VSTAT = '1' -- Successfully processed
UNION ALL
-- 8. Purchase Order Changed
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Order Changed' AS "Activity",
TO_TIMESTAMP(CONCAT(ch.UDATE, ' ', ch.UTIME), 'YYYYMMDD HH24MISS') AS "EventTime",
ch.USERNAME AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].CDHDR ch ON ch.OBJECTCLASS = 'EINKBELEG' AND ch.OBJECTID = po.EBELN
WHERE ch.TCODE IN ('ME22', 'ME22N') -- Filter for change transactions
UNION ALL
-- 9. Goods Receipt Posted
SELECT
ekbe.EBELN AS "PurchaseOrder",
'Goods Receipt Posted' AS "Activity",
TO_TIMESTAMP(CONCAT(mkpf.CPUDT, ' ', mkpf.CPUTM), 'YYYYMMDD HH24MISS') AS "EventTime",
mkpf.USNAM AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM [Your SAP Schema].EKBE AS ekbe
JOIN [Your SAP Schema].MKPF AS mkpf ON ekbe.BELNR = mkpf.MBLNR AND ekbe.GJAHR = mkpf.MJAHR
JOIN PO_BASE AS po ON ekbe.EBELN = po.EBELN AND ekbe.EBELP = po.EBELP
WHERE ekbe.BEWTP = 'E' -- Goods Receipt
AND ekbe.SHKZG = 'S' -- Debit/Credit Indicator: Goods Receipt
UNION ALL
-- 10. Services Confirmation Entered
SELECT
po.EBELN AS "PurchaseOrder",
'Services Confirmation Entered' AS "Activity",
TO_TIMESTAMP(CONCAT(essr.ERDAT, ' ', essr.ERZET), 'YYYYMMDD HH24MISS') AS "EventTime",
essr.ERNAM AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].EKBE ekbe ON po.EBELN = ekbe.EBELN AND po.EBELP = ekbe.EBELP
JOIN [Your SAP Schema].ESSR essr ON ekbe.LBLNI = essr.LBLNI
WHERE ekbe.BEWTP = 'L' -- Service Entry Sheet
UNION ALL
-- 11. Quality Inspection Performed
SELECT
po.EBELN AS "PurchaseOrder",
'Quality Inspection Performed' AS "Activity",
TO_TIMESTAMP(CONCAT(qave.VDATUM, ' ', qave.VZEIT), 'YYYYMMDD HH24MISS') AS "EventTime",
qave.VNAME AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].EKBE ekbe ON po.EBELN = ekbe.EBELN AND po.EBELP = ekbe.EBELP
JOIN [Your SAP Schema].QALS qals ON qals.MBLNR = ekbe.BELNR AND qals.MJAHR = ekbe.GJAHR
JOIN [Your SAP Schema].QAVE qave ON qals.PRUEFLOS = qave.PRUEFLOS
WHERE ekbe.BEWTP = 'E' -- Linked to a Goods Receipt
UNION ALL
-- 12. Goods Returned
SELECT
ekbe.EBELN AS "PurchaseOrder",
'Goods Returned' AS "Activity",
TO_TIMESTAMP(CONCAT(mkpf.CPUDT, ' ', mkpf.CPUTM), 'YYYYMMDD HH24MISS') AS "EventTime",
mkpf.USNAM AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM [Your SAP Schema].EKBE AS ekbe
JOIN [Your SAP Schema].MKPF AS mkpf ON ekbe.BELNR = mkpf.MBLNR AND ekbe.GJAHR = mkpf.MJAHR
JOIN PO_BASE AS po ON ekbe.EBELN = po.EBELN AND ekbe.EBELP = po.EBELP
WHERE ekbe.BEWTP = 'E' -- Goods Movement
AND ekbe.SHKZG = 'H' -- Debit/Credit Indicator: Return
AND ekbe.BWART = '122' -- Movement type for return to vendor
UNION ALL
-- 13. Purchase Order Completed
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Order Completed' AS "Activity",
TO_TIMESTAMP(CONCAT(ch.UDATE, ' ', ch.UTIME), 'YYYYMMDD HH24MISS') AS "EventTime",
ch.USERNAME AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].CDHDR ch ON ch.OBJECTCLASS = 'EINKBELEG' AND ch.OBJECTID LIKE CONCAT(po.EBELN, po.EBELP, '%')
JOIN [Your SAP Schema].CDPOS cp ON ch.OBJECTCLASS = cp.OBJECTCLASS AND ch.OBJECTID = cp.OBJECTID AND ch.CHANGENR = cp.CHANGENR
WHERE cp.TABNAME = 'EKPO' AND cp.FNAME = 'ELIKZ' AND cp.VALUE_NEW = 'X' -- Delivery completed indicator
UNION ALL
-- 14. Purchase Order Deleted
SELECT
po.EBELN AS "PurchaseOrder",
'Purchase Order Deleted' AS "Activity",
TO_TIMESTAMP(CONCAT(ch.UDATE, ' ', ch.UTIME), 'YYYYMMDD HH24MISS') AS "EventTime",
ch.USERNAME AS "UserName",
po.LIFNR AS "VendorNumber",
po.NETWR AS "OrderAmount",
po.MATKL AS "MaterialGroup",
po.BUKRS AS "CompanyCode",
po.BSART AS "DocumentType"
FROM PO_BASE po
JOIN [Your SAP Schema].CDHDR ch ON ch.OBJECTCLASS = 'EINKBELEG' AND ch.OBJECTID LIKE CONCAT(po.EBELN, po.EBELP, '%')
JOIN [Your SAP Schema].CDPOS cp ON ch.OBJECTCLASS = cp.OBJECTCLASS AND ch.OBJECTID = cp.OBJECTID AND ch.CHANGENR = cp.CHANGENR
WHERE cp.TABNAME = 'EKPO' AND cp.FNAME = 'LOEKZ' AND cp.VALUE_NEW = 'L'; -- Deletion indicator Schritte
- Voraussetzungen und Verbindung: Stellen Sie sicher, dass der SAP-zertifizierte Konnektor in Ihrem ETL-Tool installiert und lizenziert ist. Richten Sie in der Administrationskonsole des Tools eine neue Verbindung zu Ihrem SAP-ECC-System ein. Sie benötigen den Host des Anwendungsservers, die Systemnummer, die Client-ID sowie ein dediziertes SAP-Benutzerkonto mit den erforderlichen RFC- und Tabellenleseberechtigungen.
- Quelltabellen ermitteln: Legen Sie in Ihrem ETL-Job oder Datenfluss die erforderlichen SAP-Tabellen als Datenquellen fest. Zu den wichtigsten Tabellen gehören EKKO (Bestellkopf), EKPO (Bestellposition), EBAN (Bestellanforderung), CDHDR (Änderungsbelegkopf), CDPOS (Änderungsbelegposition), MSEG (Materialbelegsegment), MKPF (Materialbelegkopf), NAST (Mitteilungsstatus), ESSR (Kopf des Leistungserfassungsblatts) und QALS (Prüflos).
- „Bestellung erstellt“ exportieren: Erstellen Sie einen Datenfluss aus der Tabelle EKKO. Filtern Sie die Datensätze nach dem gewünschten Zeitraum, zum Beispiel anhand von AEDAT, und dem organisatorischen Umfang, etwa BUKRS für den Buchungskreis und BSART für die Belegart. Ordnen Sie EKKO.EBELN dem Feld PurchaseOrder und „Bestellung erstellt“ dem Feld Activity zu. Ermitteln Sie EventTime aus AEDAT und ERZET. Ordnen Sie auch die übrigen erforderlichen Attribute zu.
- „Wareneingang gebucht“ exportieren: Erstellen Sie einen separaten Datenfluss aus MSEG und verknüpfen Sie die Tabelle über MBLNR und MJAHR mit MKPF. Filtern Sie nach relevanten Bewegungsarten, zum Beispiel „101“. Ordnen Sie MSEG.EBELN dem Feld PurchaseOrder und „Wareneingang gebucht“ dem Feld Activity zu. Verwenden Sie MKPF.CPUDT und MKPF.CPUTM für EventTime.
- Änderungsbasierte Ereignisse exportieren (Freigaben, Änderungen, Löschungen): Erstellen Sie einen Datenfluss aus CDHDR und CDPOS und verknüpfen Sie die Tabellen über CHANGENR. Aus dieser Quelle lassen sich mehrere Aktivitäten ableiten.
- Filtern Sie nach OBJECTCLAS = 'EINKBELEG' und TABNAME = 'EKPO'.
- Für „Bestellung freigegeben“ filtern Sie nach Änderungen am Freigabestatusfeld, zum Beispiel FNAME = 'FRGZU', bei denen der neue Wert (VALUE_NEW) die endgültige Freigabe anzeigt.
- Für „Bestellung gelöscht“ filtern Sie nach Änderungen am Löschkennzeichen (FNAME = 'LOEKZ'), bei denen der neue Wert „L“ lautet.
- Für „Bestellung geändert“ filtern Sie nach Änderungen an anderen relevanten Feldern. Schließen Sie die Statusfelder aus, die für andere Aktivitäten verwendet werden.
- Verwenden Sie für alle diese Ereignisse CDHDR.UDATE und CDHDR.UTIME als EventTime.
- Ereignisse zu Bestellanforderungen exportieren: Erstellen Sie aus EBAN einen Datenfluss für „Bestellanforderung erstellt“. Verknüpfen Sie EBAN über die Nummer der Bestellanforderung (BANFN) und die Position (BNFPO) mit EKPO, um das Ereignis einem Bestellungs-Case zuzuordnen. Verwenden Sie für „Bestellanforderung freigegeben“ CDHDR und CDPOS mit OBJECTCLAS = 'BANF'. Achten Sie auf eine sorgfältige Zuordnung, damit das Ereignis der späteren Bestellung zugeordnet wird.
- „Bestellung an Lieferanten gesendet“ exportieren: Erstellen Sie einen Datenfluss aus der Tabelle NAST. Filtern Sie nach OBJECTKEY (enthält die Bestellnummer), dem relevanten Ausgabetyp (KSCHL) und einem erfolgreichen Verarbeitungsstatus (VSTAT = '1'). Verwenden Sie ERDAT und UHR als EventTime.
- Aktivitätsdaten zusammenführen: Führen Sie die Ergebnisse aller in den vorherigen Schritten erstellten Datenflüsse mit einer „Union“- oder „Merge“-Transformation in Ihrem ETL-Tool zusammen. Achten Sie darauf, dass Spaltennamen und Datentypen in allen Datenströmen übereinstimmen (PurchaseOrder, Activity, EventTime usw.).
- Datentypen und Formate umwandeln: Stellen Sie sicher, dass die Spalte EventTime in ein einheitliches Timestamp-Format umgewandelt wird, zum Beispiel YYYY-MM-DD HH:MM:SS. Wandeln Sie OrderAmount in ein einheitliches Dezimalformat um.
- Ziel festlegen: Konfigurieren Sie ein Ziel oder einen „Sink“ für den zusammengeführten Datenstrom. Üblicherweise ist dies eine einfache Datei, zum Beispiel im CSV- oder Parquet-Format. Legen Sie Trennzeichen, Textbegrenzungszeichen und Kopfzeilenoptionen fest.
- Ausführen und prüfen: Führen Sie den gesamten ETL-Job aus. Prüfen Sie die Ausgabedatei: Sind alle 14 Aktivitäten enthalten? Ist die Zeilenanzahl plausibel? Sind die wichtigen Attribute korrekt gefüllt?
- Einplanen und exportieren: Planen Sie den ETL-Job nach erfolgreicher Prüfung regelmäßig ein, zum Beispiel jede Nacht, damit die Daten aktuell bleiben. Die erzeugte Datei kann nun in Ihr Process-Mining-Tool hochgeladen werden.
Konfiguration
- Voraussetzungen: Ein kommerzielles ETL-Tool (z. B. Informatica PowerCenter, Talend oder SAP Data Services) mit dem passenden, von SAP zertifizierten Connector für ECC. Ein SAP-Dialog- oder Systembenutzer mit Berechtigungen für S_RFC und S_TABU_DIS sowie Zugriff auf die benötigten Tabellen.
- SAP-Verbindung: Konfigurieren Sie den Connector mit SAP-Anwendungsserver, Systemnummer, Mandant, Benutzer und Passwort. Die Verwendung von Secure Network Communications (SNC) wird empfohlen.
- Filter für den Datumsbereich: Begrenzen Sie das Datenvolumen unbedingt mit einem Datumsfilter. Üblicherweise wird EKKO.AEDAT (Anlagedatum der Bestellung) auf die letzten 3 bis 12 Monate eingeschränkt. Wenden Sie den Filter bereits an der Quelle an, damit nicht zu viele Daten aus SAP extrahiert werden.
- Filter für den Organisationsbereich: Filtern Sie immer nach EKKO.BUKRS (Buchungskreis). Schränken Sie die Analyse bei Bedarf zusätzlich über EKPO.WERKS (Werk) oder EKKO.EKORG (Einkaufsorganisation) auf eine bestimmte Geschäftseinheit ein.
- Filter für die Belegart: Verwenden Sie EKKO.BSART, um nur relevante Bestellarten einzubeziehen und Umlagerungen oder andere interne Belege auszuschließen, die nicht zum Standard-P2P-Prozess gehören.
- Leistungsoptimierung: Die Extraktion aus den Änderungsbelegtabellen (CDHDR, CDPOS) kann langsam sein. Stellen Sie sicher, dass Filter für OBJECTCLAS, OBJECTID und UDATE gesetzt sind. Passen Sie die Einstellung „Packet Size“ im SAP-Connector an, um die Datenübertragung zu optimieren. Bei sehr großen Systemen empfiehlt sich zunächst ein vollständiger Ladevorgang mit historischen Daten, gefolgt von geplanten Delta-Ladevorgängen.
Beispielabfrage sql
/*
This is a logical representation of the transformations performed within the ETL tool.
The tool's graphical interface will be used to configure these separate data flows, which are then combined with a UNION transformation.
Placeholders like [Your ETL Tool Functions] and [Filter Values] must be configured in the tool.
*/
-- 1. Purchase Requisition Created
SELECT
ekpo.EBELN AS PurchaseOrder,
'Purchase Requisition Created' AS Activity,
[Your ETL Tool Functions].DateTime(eban.ERDAT, eban.ERZET) AS EventTime,
eban.ERNAM AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM EBAN AS eban
INNER JOIN EKPO AS ekpo ON eban.BANFN = ekpo.BANFN AND eban.BNFPO = ekpo.BNFPO
INNER JOIN EKKO AS ekko ON ekpo.EBELN = ekko.EBELN
WHERE ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 2. Purchase Requisition Approved (inferred from change documents)
SELECT
ekpo.EBELN AS PurchaseOrder,
'Purchase Requisition Approved' AS Activity,
[Your ETL Tool Functions].DateTime(cdhdr.UDATE, cdhdr.UTIME) AS EventTime,
cdhdr.USERNAME AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM CDHDR AS cdhdr
INNER JOIN CDPOS AS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
INNER JOIN EBAN AS eban ON cdhdr.OBJECTID = eban.BANFN
INNER JOIN EKPO AS ekpo ON eban.BANFN = ekpo.BANFN AND eban.BNFPO = ekpo.BNFPO
INNER JOIN EKKO AS ekko ON ekpo.EBELN = ekko.EBELN
WHERE cdhdr.OBJECTCLAS = 'BANF' AND cdpos.TABNAME = 'EBAN' AND cdpos.FNAME = 'FRGZU' AND cdpos.VALUE_NEW = '[Final Release Indicator for PR]'
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 3. Purchase Order Created
SELECT
EBELN AS PurchaseOrder,
'Purchase Order Created' AS Activity,
[Your ETL Tool Functions].DateTime(AEDAT, ERZET) AS EventTime,
ERNAM AS UserName,
LIFNR AS VendorNumber,
NULL AS OrderAmount, -- Amount is at item level
NULL AS MaterialGroup, -- Attribute is at item level
BUKRS AS CompanyCode,
BSART AS DocumentType
FROM EKKO
WHERE AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 4. Purchase Order Approval Requested / 5. Approved / 6. Rejected (inferred from change documents)
SELECT
ekpo.EBELN AS PurchaseOrder,
CASE
WHEN cdpos.VALUE_NEW = '[Final Release Code]' THEN 'Purchase Order Approved'
WHEN cdpos.VALUE_NEW = '[Rejection Release Code]' THEN 'Purchase Order Rejected'
ELSE 'Purchase Order Approval Requested'
END AS Activity,
[Your ETL Tool Functions].DateTime(cdhdr.UDATE, cdhdr.UTIME) AS EventTime,
cdhdr.USERNAME AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM CDHDR AS cdhdr
INNER JOIN CDPOS AS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
INNER JOIN EKKO AS ekko ON SUBSTRING(cdhdr.OBJECTID, 1, 10) = ekko.EBELN
INNER JOIN EKPO AS ekpo ON ekko.EBELN = ekpo.EBELN
WHERE cdhdr.OBJECTCLAS = 'EINKBELEG' AND cdpos.TABNAME = 'EKKO' AND cdpos.FNAME = 'FRGKE'
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 7. Purchase Order Sent to Vendor
SELECT
ekko.EBELN AS PurchaseOrder,
'Purchase Order Sent to Vendor' AS Activity,
[Your ETL Tool Functions].DateTime(nast.ERDAT, nast.UHR) AS EventTime,
nast.USNAM AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM NAST AS nast
INNER JOIN EKKO AS ekko ON nast.OBJKY = ekko.EBELN
INNER JOIN EKPO AS ekpo ON ekko.EBELN = ekpo.EBELN
WHERE nast.KAPPL = 'EF' AND nast.VSTAT = '1' AND nast.KSCHL IN ([Your PO Output Types])
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 8. Purchase Order Changed (inferred from change documents, simplified example)
SELECT DISTINCT
ekko.EBELN AS PurchaseOrder,
'Purchase Order Changed' AS Activity,
[Your ETL Tool Functions].DateTime(cdhdr.UDATE, cdhdr.UTIME) AS EventTime,
cdhdr.USERNAME AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM CDHDR AS cdhdr
INNER JOIN CDPOS AS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
INNER JOIN EKKO AS ekko ON SUBSTRING(cdhdr.OBJECTID, 1, 10) = ekko.EBELN
INNER JOIN EKPO AS ekpo ON ekko.EBELN = ekpo.EBELN
WHERE cdhdr.OBJECTCLAS = 'EINKBELEG' AND cdpos.FNAME NOT IN ('FRGKE', 'FRGZU', 'LOEKZ', 'ELIKZ')
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 9. Goods Receipt Posted
SELECT
mseg.EBELN AS PurchaseOrder,
'Goods Receipt Posted' AS Activity,
[Your ETL Tool Functions].DateTime(mkpf.CPUDT, mkpf.CPUTM) AS EventTime,
mkpf.USNAM AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM MSEG AS mseg
INNER JOIN MKPF AS mkpf ON mseg.MBLNR = mkpf.MBLNR AND mseg.MJAHR = mkpf.MJAHR
INNER JOIN EKPO AS ekpo ON mseg.EBELN = ekpo.EBELN AND mseg.EBELP = ekpo.EBELP
INNER JOIN EKKO AS ekko ON ekpo.EBELN = ekko.EBELN
WHERE mseg.BWART = '101' AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 10. Services Confirmation Entered
SELECT
essr.EBELN AS PurchaseOrder,
'Services Confirmation Entered' AS Activity,
[Your ETL Tool Functions].DateTime(essr.ERDAT, essr.ERZET) AS EventTime,
essr.ERNAM AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM ESSR AS essr
INNER JOIN EKKO AS ekko ON essr.EBELN = ekko.EBELN
INNER JOIN EKPO AS ekpo ON essr.EBELN = ekpo.EBELN AND essr.EBELP = ekpo.EBELP
WHERE ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 11. Quality Inspection Performed
SELECT
qals.EBELN AS PurchaseOrder,
'Quality Inspection Performed' AS Activity,
[Your ETL Tool Functions].DateTime(qals.PASTRTERM, '000000') AS EventTime, -- Time is often not available
qals.PRUEFER AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM QALS AS qals
INNER JOIN EKKO AS ekko ON qals.EBELN = ekko.EBELN
INNER JOIN EKPO AS ekpo ON qals.EBELN = ekpo.EBELN AND qals.EBELP = ekpo.EBELP
WHERE qals.VCODE <> '' -- A usage decision code exists
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 12. Goods Returned
SELECT
mseg.EBELN AS PurchaseOrder,
'Goods Returned' AS Activity,
[Your ETL Tool Functions].DateTime(mkpf.CPUDT, mkpf.CPUTM) AS EventTime,
mkpf.USNAM AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM MSEG AS mseg
INNER JOIN MKPF AS mkpf ON mseg.MBLNR = mkpf.MBLNR AND mseg.MJAHR = mkpf.MJAHR
INNER JOIN EKPO AS ekpo ON mseg.EBELN = ekpo.EBELN AND mseg.EBELP = ekpo.EBELP
INNER JOIN EKKO AS ekko ON ekpo.EBELN = ekko.EBELN
WHERE mseg.BWART = '122' AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 13. Purchase Order Completed (inferred from change documents)
SELECT
ekpo.EBELN AS PurchaseOrder,
'Purchase Order Completed' AS Activity,
[Your ETL Tool Functions].DateTime(cdhdr.UDATE, cdhdr.UTIME) AS EventTime,
cdhdr.USERNAME AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM CDHDR AS cdhdr
INNER JOIN CDPOS AS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
INNER JOIN EKPO AS ekpo ON SUBSTRING(cdhdr.OBJECTID, 1, 10) = ekpo.EBELN AND SUBSTRING(cdhdr.OBJECTID, 11, 5) = ekpo.EBELP
INNER JOIN EKKO AS ekko ON ekpo.EBELN = ekko.EBELN
WHERE cdhdr.OBJECTCLAS = 'EINKBELEG' AND cdpos.TABNAME = 'EKPO' AND cdpos.FNAME = 'ELIKZ' AND cdpos.VALUE_NEW = 'X'
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]);
UNION ALL
-- 14. Purchase Order Deleted (inferred from change documents)
SELECT
ekpo.EBELN AS PurchaseOrder,
'Purchase Order Deleted' AS Activity,
[Your ETL Tool Functions].DateTime(cdhdr.UDATE, cdhdr.UTIME) AS EventTime,
cdhdr.USERNAME AS UserName,
ekko.LIFNR AS VendorNumber,
ekpo.NETWR AS OrderAmount,
ekpo.MATKL AS MaterialGroup,
ekko.BUKRS AS CompanyCode,
ekko.BSART AS DocumentType
FROM CDHDR AS cdhdr
INNER JOIN CDPOS AS cdpos ON cdhdr.CHANGENR = cdpos.CHANGENR
INNER JOIN EKPO AS ekpo ON SUBSTRING(cdhdr.OBJECTID, 1, 10) = ekpo.EBELN AND SUBSTRING(cdhdr.OBJECTID, 11, 5) = ekpo.EBELP
INNER JOIN EKKO AS ekko ON ekpo.EBELN = ekko.EBELN
WHERE cdhdr.OBJECTCLAS = 'EINKBELEG' AND cdpos.TABNAME = 'EKPO' AND cdpos.FNAME = 'LOEKZ' AND cdpos.VALUE_NEW = 'L'
AND ekko.AEDAT BETWEEN '[START_DATE]' AND '[END_DATE]' AND ekko.BUKRS IN ([YOUR_COMPANY_CODES]); Möchten Sie loslegen?
Mit diesem Template erhalten Sie eine Vorlage zur Optimierung Ihres Purchase-to-Pay-Prozesses für Bestellungen in SAP ECC. Nutzen Sie Ihre Daten, um Erkenntnisse zu gewinnen und die Effizienz zu steigern.
Optimieren Sie P2P-Bestellungen: Starten Sie noch heute Ihre kostenlose Testphase
Beseitigen Sie Engpässe und verkürzen Sie die Zykluszeit um mindestens 30 %.
Keine Kreditkarte erforderlich. In wenigen Minuten startklar.