Ihre Einkauf zu Zahlung - Rechnungsverarbeitungs-Daten-Vorlage
Ihre Einkauf zu Zahlung - Rechnungsverarbeitungs-Daten-Vorlage
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsleitfaden für SAP S/4HANA
Einkauf zu Zahlung - Rechnungsverarbeitungs-Attribute
| Name | Beschreibung | ||
|---|---|---|---|
| Rechnungsnummer InvoiceNumber | Der eindeutige Identifikator für den Lieferantenrechnungsbeleg, der als primärer Fallidentifikator für den Prozess dient. | ||
| Beschreibung Die Rechnungsnummer ist der eindeutige Identifikator, der jeder Lieferantenrechnung in SAP S/4HANA zugewiesen wird. Sie verknüpft alle zugehörigen Aktivitäten, wie Erstellung, Parken, Genehmigung und Zahlung, zu einer einzigen, kohärenten Prozessinstanz. Im Process Mining ist dieses Attribut fundamental für die Verfolgung des End-to-End-Verlaufs jeder Rechnung. Es ermöglicht die Rekonstruktion des gesamten Prozessflusses, vom Eingang bis zur endgültigen Zahlung, und ermöglicht die Analyse von Durchlaufzeiten, Engpässen und Prozessabweichungen auf der Ebene der einzelnen Rechnung. Bedeutung Es ist der essenzielle Schlüssel, um alle zugehörigen Events zu verbinden und so eine vollständige Spur des Lebenszyklus einer Rechnung durch das System zu ermöglichen. Datenquelle Dies ist die Buchhaltungsbelegnummer, zu finden in Tabelle BKPF, Feld BELNR. Beispiele 190000000119000000451900000132 | |||
| Aktivitätsname ActivityName | Der Name der Geschäftsaktivität oder des Events, das zu einem bestimmten Zeitpunkt für eine Rechnung erfolgte. | ||
| Beschreibung Der Aktivitätsname beschreibt einen spezifischen Schritt oder Statuswechsel innerhalb des Rechnungsverarbeitungszyklus. Beispiele sind 'Rechnungsbeleg erstellt', 'Rechnung zur Genehmigung gesendet', 'Zahlsperre gesetzt' und 'Zahlung ausgeführt'. Dieses Attribut ist entscheidend für die Erstellung der Prozesslandkarte, die den Fluss der Aktivitäten visuell darstellt. Die Analyse der Reihenfolge, Häufigkeit und Dauer zwischen diesen Aktivitäten hilft, Engpässe, Nacharbeitsschleifen und nicht-konforme Prozessvarianten zu identifizieren. Es bildet das Rückgrat jeder Process Mining Analyse. Bedeutung Es definiert die Schritte im Prozess und ermöglicht die Visualisierung von Prozesskarten sowie die Analyse von Prozessabläufen und -varianten. Datenquelle Abgeleitet aus einer Kombination von SAP-Transaktionscodes (SY-TCODE), Änderungsbeleg-Objektstatus (CDHDR/CDPOS) und spezifischen Feldwerten, die Statusänderungen anzeigen. Beispiele Rechnung geparktRechnung freigegebenZahlung ausgeführt | |||
| Ereigniszeit EventTime | Das genaue Datum und die genaue Uhrzeit, zu der die Aktivität stattgefunden hat. | ||
| Beschreibung Event Time ist der Timestamp, der genau festhält, wann eine bestimmte Aktivität stattgefunden hat. Diese Daten sind essenziell für die Berechnung von Dauern, Zykluszeiten und Wartezeiten zwischen verschiedenen Prozessschritten. In der Process Mining-Analyse werden genaue Timestamps verwendet, um Performance-KPIs wie 'Durchschnittliche Rechnungszykluszeit' und 'Genehmigungszykluszeit für Rechnungen' zu messen. Durch die Analyse der zwischen Aktivitäten verstrichenen Zeit können Organisationen Engpässe identifizieren, an denen Rechnungen verzögert werden, und Möglichkeiten zur Prozessbeschleunigung erkennen. Bedeutung Dieser Timestamp ist die Grundlage für alle zeitbasierten Analysen, einschließlich Performance Monitoring, Engpassidentifikation und SLA-Tracking. Datenquelle Typischerweise aus Änderungsbelegtabellen CDHDR (Kopf) und CDPOS (Position) bezogen, unter Verwendung der Felder UDATE und UTIME. Für einige Ereignisse kann es aus Erstellungs- oder Erfassungsdaten in Tabellen wie BKPF (CPUDT, CPUTM) stammen. Beispiele 2023-04-15T10:30:00Z2023-04-18T14:05:21Z2023-05-02T09:00:00Z | |||
| Benutzername UserName | Die SAP-Benutzer-ID der Person oder des Systems, die/das die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut identifiziert den Benutzer, der eine spezifische Transaktion ausgeführt oder ein Dokument erstellt hat. Es kann die Benutzer-ID einer Einzelperson oder eine System-ID für automatisierte Batch-Jobs sein. Die Analyse nach Benutzer hilft, die Arbeitslastverteilung zu verstehen, Schulungsbedarfe zu identifizieren und ungewöhnliches Benutzerverhalten zu erkennen. Zum Beispiel kann es hervorheben, welche Benutzer häufig Ausnahmen bearbeiten oder welche Rechnungen automatisch verarbeitet werden (z. B. Benutzer 'BATCHUSER'), was für die Berechnung des KPI 'Rechnungsautomatisierungsrate' entscheidend ist. Bedeutung Es ordnet Prozessaktivitäten spezifischen Benutzern oder Systemkonten zu und ermöglicht so Arbeitslastanalysen, Performance-Vergleiche und die Erkennung von Automatisierungen. Datenquelle Aus Feldern wie BKPF-USNAM (Erfasst von) oder CDHDR-USERNAME (Geändert von) bezogen. Beispiele SMITHJMUELLERTWF-BATCH | |||
| Bestellung PurchasingDocument | Die Bestellnummer, auf die sich die Rechnung bezieht. | ||
| Beschreibung Die Einkaufsbelegnummer verknüpft die Lieferantenrechnung mit der ursprünglichen Bestellung (PO). Diese Verknüpfung ist fundamental für den Drei-Wege-Abgleich, der die Rechnung gegen die Bestellung und den Wareneingang prüft. Die Analyse nach diesem Attribut hilft, Probleme im Zusammenhang mit PO-gestützten vs. nicht-PO-Rechnungen zu verstehen. Sie ist entscheidend für die Untersuchung von Abweichungen beim Abgleich und für das Verständnis der Effizienz des Beschaffungsteils des Prozesses. Bedeutung Verknüpft die Rechnung mit dem Beschaffungsprozess, was für die Analyse von Abstimmungsdifferenzen und die Einhaltung von Bestellungen (POs) unerlässlich ist. Datenquelle Diese Information ist typischerweise zu finden in der Belegsegmenttabelle BSEG, Feld EBELN (Einkaufsbelegnummer). Beispiele 450000123445000056784500009012 | |||
| Buchungskreis CompanyCode | Die Organisationseinheit, die ein rechtlich unabhängiges Unternehmen repräsentiert, für das Finanzberichte erstellt werden. | ||
| Beschreibung Der Buchungskreis ist eine grundlegende Organisationseinheit im SAP-Finanzwesen. Jede Rechnung ist einem spezifischen Buchungskreis zugeordnet, der die für die Transaktion verantwortliche juristische Einheit bestimmt. Im Process Mining ist das Filtern oder Vergleichen nach Buchungskreis unerlässlich, um die Prozessleistung über verschiedene Geschäftseinheiten, juristische Einheiten oder Länder hinweg zu analysieren. Es hilft, regionale Unterschiede in Effizienz, Compliance und Automatisierungsgraden zu identifizieren und unterstützt gezielte Verbesserungsinitiativen. Bedeutung Es ermöglicht die Segmentierung und den Vergleich der Rechnungsverarbeitungs-Performance über verschiedene rechtliche Einheiten oder geografische Standorte innerhalb der Organisation hinweg. Datenquelle Dies ist ein Standardfeld in der Belegkopftabelle BKPF, Feld BUKRS. Beispiele 1000US01DE01 | |||
| Dokumententyp DocumentType | Ein Code, der verschiedene Arten von Buchhaltungsbelegen klassifiziert, wie z.B. Lieferantenrechnungen oder Gutschriften. | ||
| Beschreibung Die Belegart wird in SAP verwendet, um zwischen verschiedenen Geschäftsvorfällen zu unterscheiden. Zum Beispiel steht 'KR' typischerweise für eine Standard-Lieferantenrechnung, während 'KG' eine Lieferantengutschrift sein könnte. Die Analyse nach Belegart ermöglicht die Segmentierung des Prozesses, um zu verstehen, wie verschiedene Arten von Transaktionen bearbeitet werden. Zum Beispiel kann der Prozess für eine Gutschrift erheblich von dem einer Standardrechnung abweichen. Diese Segmentierung liefert präzisere und relevantere Prozesseinblicke. Bedeutung Es hilft, zwischen verschiedenen Arten von Finanztransaktionen zu unterscheiden, wie z.B. Standardrechnungen und Gutschriften, die oft unterschiedliche Prozesspfade durchlaufen. Datenquelle Gefunden in der Belegkopftabelle BKPF, Feld BLART. Beispiele KRREKG | |||
| Grund der Zahlungssperre PaymentBlockReason | Ein Code, der angibt, warum eine Rechnung für die Zahlung gesperrt ist. | ||
| Beschreibung Wenn eine Rechnung zur Zahlung gesperrt wird, liefert dieses Attribut den spezifischen Grund für die Sperre, wie 'Mengenabweichung' oder 'Preisabweichung'. Diese Gründe werden in SAP konfiguriert, um die Ausnahmebehandlung zu standardisieren. Dieses Attribut ist entscheidend für das Dashboard 'Zahlungssperren Auftreten & Dauer'. Die Analyse der Häufigkeit verschiedener Sperrgründe hilft, die Grundursachen für Zahlungsverzögerungen zu identifizieren, wie Probleme mit spezifischen Lieferanten, Materialien oder internen Prozessen, was gezielte Korrekturmaßnahmen ermöglicht. Bedeutung Liefert die spezifische Grundursache für Zahlungssperren und ermöglicht eine gezielte Analyse, um Verzögerungen zu reduzieren und die Datenquelle Befindet sich in der Lieferantenposition der Tabelle BSEG, Feld ZLSPR (Zahlungssperrschlüssel). Beispiele RIA | |||
| Lieferantennummer VendorNumber | Der eindeutige Identifikator für den Lieferanten, der die Rechnung eingereicht hat. | ||
| Beschreibung Die Lieferantennummer identifiziert den mit der Rechnung verbundenen Lieferanten oder Kreditor. Sie verknüpft die Rechnungstransaktion mit den Lieferantenstammdaten. Dieses Attribut ist entscheidend für die Lieferanten-zentrierte Analyse, wie die Bewertung der 'Lieferantenzahlungsperformance' oder die Identifizierung von Lieferanten, die häufig problematische Rechnungen einreichen, die zu Ausnahmen oder Zahlungssperren führen. Es hilft bei der Pflege der Lieferantenbeziehungen und der Bewertung der Lieferantenzuverlässigkeit. Bedeutung Ermöglicht die Analyse der Prozessperformance nach Lieferant, hilft Muster zu identifizieren, Beziehungen zu pflegen und lieferantenbezogene Probleme zu bewerten. Datenquelle Typischerweise zu finden in der Buchhaltungsbelegsegmenttabelle BSEG, Feld LIFNR. Beispiele 100345700012V9832 | |||
| Rechnungsbetrag AmountInCompanyCodeCurrency | Der Bruttogesamtbetrag der Rechnung in der lokalen Währung des Buchungskreises. | ||
| Beschreibung Dieses Attribut repräsentiert den Gesamtwert der Rechnung. Es ist eine Schlüsselmetrik, um die finanziellen Auswirkungen und das Ausmaß des Rechnungsverarbeitungsbetriebs zu verstehen. Die Analyse der Rechnungsbeträge hilft, hochvolumige Rechnungen für eine schnellere Verarbeitung zu priorisieren, Ausgabentrends zu identifizieren und Prozessprobleme mit dem finanziellen Wert zu korrelieren. Zum Beispiel kann es verwendet werden, um zu untersuchen, ob hochvolumige Rechnungen eher gesperrt werden oder längere Genehmigungszeiten haben. Bedeutung Bietet finanziellen Kontext für den Prozess, was eine Analyse auf Basis des Geldwertes ermöglicht, z. B. um zu erkennen, ob hochvolumige Rechnungen anders verarbeitet werden. Datenquelle Dieser Wert wird typischerweise abgeleitet aus der Summe relevanter Zeileneinträge in Tabelle BSEG, Feld WRBTR (Betrag in lokaler Währung). Beispiele 1500.75125000.00850.20 | |||
| Zahlungsfälligkeitsdatum PaymentDueDate | Das Datum, bis zu dem die Rechnung bezahlt werden muss, um eine Überfälligkeit zu vermeiden. | ||
| Beschreibung Das Zahlungszieldatum ist das errechnete Datum, an dem die Zahlung an den Lieferanten fällig ist, basierend auf dem Rechnungsdatum und den vereinbarten Zahlungsbedingungen. Es dient als kritische Frist im Prozess. Dieses Attribut ist wesentlich für den KPI 'Pünktliche Zahlungsquote' und das 'Lieferantenzahlungsperformance'-Dashboard. Durch den Vergleich des tatsächlichen Zahlungsdatums mit dem Fälligkeitsdatum kann ein Unternehmen seine Fähigkeit messen, Zahlungsverpflichtungen zu erfüllen, was sich auf Lieferantenbeziehungen und den finanziellen Ruf auswirkt. Bedeutung Es ist der primäre Benchmark zur Messung der Pünktlichkeit von Zahlungen, was entscheidend ist, um gute Lieferantenbeziehungen zu pflegen und Verzugsgebühren zu vermeiden. Datenquelle Dieses Datum ist oft direkt verfügbar im Kreditorenposten der Tabelle BSEG, Feld ZFBDT (Basisdatum für die Fälligkeitsberechnung). Das Netto-Fälligkeitsdatum wird aus diesem Basisdatum und den Zahlungsbedingungen berechnet. Beispiele 2023-05-302023-06-152023-07-01 | |||
| Anzahl der Genehmigungszyklen ApprovalCycleCount | Eine Zählung, wie oft eine Rechnung zur Genehmigung gesendet wurde. | ||
| Beschreibung Diese Metrik zählt die Häufigkeit der Aktivität 'Rechnung zur Genehmigung gesendet' für eine einzelne Rechnung. Ein Zähler größer als eins zeigt an, dass die Rechnung mindestens einmal abgelehnt oder zurückgesendet wurde, was einen neuen Genehmigungszyklus erfordert. Dieses Attribut unterstützt direkt den KPI 'First-Pass Approval Rate'. Durch die Analyse von Rechnungen mit hohen Genehmigungszykluszählungen können Unternehmen die Gründe für fehlgeschlagene Genehmigungen identifizieren, wie unzureichende Informationen oder fehlerhafte Kontierung, und Schritte zur Prozessverbesserung einleiten. Bedeutung Quantifiziert Nacharbeiten innerhalb des Genehmigungs-Teilprozesses, was hilft, die Datenquelle Berechnet durch Zählen der Vorkommen der Aktivität 'Rechnung zur Genehmigung gesendet' für jede eindeutige Rechnungsnummer. Beispiele 123 | |||
| Ausgleichsbelegnr. ClearingDocumentNumber | Die Belegnummer, die die Rechnung ausgleicht, typischerweise den Zahlungsbeleg darstellend. | ||
| Beschreibung Die Clearing-Belegnummer verknüpft einen offenen Rechnungsbeleg mit der Transaktion, die ihn ausgleicht, was fast immer der Zahlungsbeleg ist. Dies bestätigt, dass die Rechnung bezahlt wurde. Dieses Attribut ist die definitive Verknüpfung zwischen einer Rechnung und ihrer Zahlung. Es wird verwendet, um die Aktivität 'Zahlung ausgeführt' und ihren entsprechenden Timestamp zu identifizieren, was für die Berechnung der End-to-End-Durchlaufzeit und der pünktlichen Zahlungsrate unerlässlich ist. Bedeutung Bestätigt, dass eine Rechnung bezahlt wurde, und verknüpft sie mit der spezifischen Zahlungstransaktion, was entscheidend für die Zykluszeit- und Zahlungsleistungsanalyse ist. Datenquelle Gefunden in der Belegsegmenttabelle BSEG, Feld AUGBL (Ausgleichsbelegnummer). Beispiele 150000000115000000231500000088 | |||
| Extraktions-Timestamp ExtractionTimestamp | Das Datum und die Uhrzeit der Datenextraktion aus dem Quellsystem. | ||
| Beschreibung Dieses Attribut zeichnet den Timestamp des Datenextraktionsereignisses auf. Es spiegelt die Aktualität der Daten wider, die im Process Mining Tool analysiert werden. In der Analyse wird dies verwendet, um die Aktualität der generierten Erkenntnisse zu verstehen. Es ist entscheidend für operative Monitoring-Dashboards, um sicherzustellen, dass Entscheidungen auf aktuellen Informationen basieren und um Datenaktualisierungszyklen effektiv zu verwalten. Bedeutung Gibt die Aktualität der Daten an und stellt sicher, dass Analysen und Berichte auf den neuesten verfügbaren Informationen basieren. Datenquelle Dies ist kein SAP-Feld. Es wird vom Datenextraktionstool oder ETL-Prozess zum Zeitpunkt des Datenabrufs generiert und hinzugefügt. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| Ist automatisiert IsAutomated | Ein Flag, das anzeigt, ob eine Aktivität von einem automatisierten Systembenutzer durchgeführt wurde. | ||
| Beschreibung Dieses boolesche Attribut ist Bedeutung Unterscheidet zwischen manuellen und systemgesteuerten Aktivitäten, was grundlegend für die Messung von Automatisierungsraten und die Identifizierung von Möglichkeiten zur weiteren Automatisierung ist. Datenquelle Abgeleitet vom Attribut UserName. Eine Zuordnung oder Regel wird erstellt, um spezifische Benutzer-IDs als 'automatisiert' zu klassifizieren. Beispiele truefalsch | |||
| Ist Nacharbeit IsRework | Ein Flag, das anzeigt, ob eine Rechnung Nacharbeitsaktivitäten durchlaufen hat, wie z.B. eine abgelehnte Genehmigung oder eine entfernte Zahlungssperre. | ||
| Beschreibung Dieses Attribut kennzeichnet Rechnungen, die eine oder mehrere Nacharbeitsschleifen durchlaufen haben. Nacharbeit wird durch spezifische Abfolgen von Aktivitäten identifiziert, zum Beispiel 'Rechnung genehmigt' nach 'Rechnung abgelehnt' oder 'Zahlsperre aufgehoben' nach 'Zahlsperre gesetzt'. Dieses Attribut vereinfacht die Berechnung des KPI 'Rechnungs-Nacharbeitsrate'. Es ermöglicht Analysten, Fälle mit Nacharbeit leicht zu isolieren und zu untersuchen, um die Grundursachen für Ineffizienz und wiederholten manuellen Aufwand zu verstehen. Bedeutung Identifiziert ineffiziente Prozessabläufe, bei denen Arbeit wiederholt werden muss, hilft, Verschwendung zu quantifizieren und die Ursachen von Prozessausnahmen aufzudecken. Datenquelle Berechnet basierend auf der Reihenfolge der Aktivitäten im Event Log. Wenn beispielsweise 'Rechnung abgelehnt' in der Spur einer Rechnung auftritt, wäre dieses Flag auf wahr gesetzt. Beispiele truefalsch | |||
| Quellsystem-ID SourceSystemId | Der Identifikator des Quellsystems SAP S/4HANA, aus dem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt das Ursprungssystem an, zum Beispiel 'S4H_PROD' oder 'ERP_EU'. Es ist besonders wichtig in Umgebungen mit mehreren ERP-Instanzen oder einer Mischung aus Altsystemen und modernen Systemen. Für die Analyse ermöglicht es den Vergleich der Prozessleistung über verschiedene Systeme oder Regionen hinweg. Es gewährleistet die Datenherkunft und ist entscheidend für die Data Governance und Fehlerbehebung, wenn Daten aus mehreren Quellen in einer zentralen Process Mining Plattform kombiniert werden. Bedeutung Es liefert Kontext über den Ursprung der Daten, was für die Data Governance und den Vergleich von Prozessen über verschiedene Systeme oder Unternehmensstandorte hinweg unerlässlich ist. Datenquelle Dieser Wert wird typischerweise abgeleitet aus der SAP-System-ID (sy-sysid) während der Datenextraktion oder als statischer Wert in der ETL-Pipeline konfiguriert. Beispiele S4PS4H_PROD_100ECC_EU | |||
| Rechnungsbearbeitungszeit InvoiceProcessingTime | Die gesamte verstrichene Zeit von der ersten bis zur letzten Aktivität einer Rechnung. | ||
| Beschreibung Diese Metrik berechnet die Gesamtdauer für die Verarbeitung einer einzelnen Rechnung, typischerweise von der Rechnungserstellung oder dem Eingang bis zur endgültigen Zahlung. Es bietet eine Fall-basierte Zusammenfassung der End-to-End-Durchlaufzeit. Dieses berechnete Attribut ist die Grundlage für den KPI 'Durchschnittliche Rechnungsdurchlaufzeit' und das Dashboard 'End-to-End Rechnungsdurchlaufzeit'. Es ermöglicht die schnelle Identifizierung der längsten Fälle und die Analyse von Faktoren, die zu verlängerten Verarbeitungszeiten beitragen. Bedeutung Misst die End-to-End-Effizienz des Prozesses für jede Rechnung und hebt Fälle mit außergewöhnlich langen Dauern hervor, die einer Untersuchung bedürfen. Datenquelle Berechnet durch die Differenz zwischen dem Timestamp des letzten Events und dem ersten Event für jede eindeutige Rechnungsnummer. Beispiele 10 Tage 4 Stunden25 Tage 1 Stunde5 days 8 hours | |||
| Rechnungsdatum InvoiceDate | Das Datum, an dem der Lieferant das Rechnungsdokument ausgestellt hat. | ||
| Beschreibung Das Rechnungsdatum, auch Belegdatum genannt, ist das vom Lieferanten auf der Rechnung angegebene Datum. Es dient als Ausgangspunkt für die Berechnung des Zahlungszieldatums basierend auf den vereinbarten Zahlungsbedingungen. In der Analyse ist dieses Datum grundlegend für finanzielle Berechnungen, wie die Bestimmung des Rechnungsalters und der Berechtigung für Skonti bei frühzeitiger Zahlung. Es ist ein wichtiger Input für den KPI 'Skontoausnutzungsrate'. Bedeutung Dient als Grundlage für die Berechnung von Zahlungsbedingungen und Fälligkeitsterminen, was für das Working Capital Management und die Skontoausnutzung unerlässlich ist. Datenquelle Gefunden in der Belegkopftabelle BKPF, Feld BLDAT (Belegdatum). Beispiele 2023-04-122023-05-152023-06-20 | |||
| Stornogrund ReversalReason | Ein Code, der den Grund für die Stornierung eines Rechnungsbelegs angibt. | ||
| Beschreibung Wird eine Rechnung fehlerhaft gebucht, wird sie oft storniert. Der Stornogrund-Code erklärt, warum diese Aktion vorgenommen wurde, z.B. 'Falsches Buchungsdatum' oder 'Dateneingabefehler'. Die Analyse von Stornogründen hilft, Fehlermuster im Rechnungsbuchungsprozess zu identifizieren. Diese Erkenntnis kann zur Verbesserung von Schulungen, zur Stärkung der Systemkontrollen oder zur Behebung wiederkehrender Probleme genutzt werden, die zu finanzieller Nacharbeit und administrativem Aufwand führen. Bedeutung Erklärt, warum Rechnungen storniert wurden, und bietet direkten Einblick in Fehlerquellen und Nacharbeit im Buchungsprozess. Datenquelle Gefunden im Kopf des Originalbelegs in Tabelle BKPF, Feld STGRD (Stornogrund). Beispiele 010205 | |||
| Wurde pünktlich bezahlt IsPaidOnTime | Ein Flag, das wahr ist, wenn die Rechnung am oder vor ihrem Fälligkeitsdatum bezahlt wurde. | ||
| Beschreibung Dieses boolesche Attribut ist das Ergebnis des Vergleichs des tatsächlichen Zahlungsdatums (der Timestamp der Aktivität 'Zahlung ausgeführt') mit dem 'Zahlungszieldatum'. Es liefert ein klares, binäres Ergebnis für den Zahlungsstatus jeder Rechnung. Dies ist die Kernberechnung für den KPI 'Pünktliche Zahlungsrate'. Es ermöglicht eine einfache Filterung und Analyse, um die Merkmale verspäteter Zahlungen zu verstehen, wie häufige Lieferanten, Buchungskreise oder Rechnungsbeträge, die mit Verzögerungen verbunden sind. Bedeutung Misst direkt die Einhaltung von Zahlungsbedingungen, was ein entscheidender KPI für das Lieferantenbeziehungsmanagement und die Finanzoperationen ist. Datenquelle Berechnet durch den Vergleich der EventTime der Aktivität 'Zahlung ausgeführt' mit dem Attribut PaymentDueDate. (Zahlungsdatum <= Fälligkeitsdatum). Beispiele truefalsch | |||
| Zahlungsbedingungen PaymentTerms | Der Code, der die mit dem Lieferanten vereinbarten Zahlungsbedingungen definiert, wie Fälligkeitstermine und Skontofristen. | ||
| Beschreibung Zahlungsbedingungen legen die Regeln für die Zahlung einer Rechnung fest, einschließlich etwaiger Skonti für frühzeitige Zahlungen. Zum Beispiel könnte 'Z030' bedeuten 'zahlbar innerhalb von 30 Tagen netto'. Dieses Attribut ist wesentlich für die Finanzplanung und die Optimierung des Working Capital. Im Process Mining wird es zur Berechnung des 'Zahlungszieldatums' und zur Bestimmung der Berechtigung für Skonti bei frühzeitiger Zahlung verwendet, was direkt den KPI 'Skontoausnutzungsrate' unterstützt. Bedeutung Definiert die Regeln für Zahlungsfälligkeiten und Skonti, was sich direkt auf die KPIs für pünktliche Zahlungen und das Working Capital Management auswirkt. Datenquelle Gefunden in der Lieferantenposition in Tabelle BSEG, Feld ZTERM (Zahlungsbedingungsschlüssel). Beispiele 0001Z030NT60 | |||
Einkauf zu Zahlung - Rechnungsverarbeitungs-Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Rechnung freigegeben | Diese Aktivität signalisiert, dass die Rechnung von der zuständigen Autorität genehmigt wurde. Dies wird erfasst, wenn der Genehmigungs-Workflow erfolgreich abgeschlossen wird oder ein Freigabekennzeichen gesetzt wird. | ||
| Bedeutung Dies ist ein kritischer Meilenstein, der die Rechnung zur Zahlung freigibt. Verzögerungen bei Genehmigungen sind ein häufiger Engpass, und die Verfolgung dieser Aktivität hilft, langsame Genehmiger oder Prozessschritte zu identifizieren. Datenquelle Dies kann aus dem letzten Freigabeschritt in einem SAP Workflow oder durch Verfolgung von Änderungen an Freigabestatusfeldern in Tabellen abgeleitet werden, die mit der Rechnung oder ihrem Einkaufsbeleg verbunden sind. Erfassen Ableitung aus Workflow-Abschluss-Events oder Änderungen im Freigabestatusfeld eines Belegs. Ereignistyp inferred | |||
| Rechnung gebucht | Dies ist ein wichtiges Finanzereignis, bei dem die geparkte oder genehmigte Rechnung formell im Hauptbuch gebucht wird. Diese Aktion erkennt die Verbindlichkeit gegenüber dem Lieferanten an. | ||
| Bedeutung Die Buchung ist ein wichtiger Meilenstein, der die Datenerfassung und Genehmigung von der finanziellen Abwicklungsphase trennt. Die Zeit von der Rechnungserstellung bis zur Buchung ist ein Schlüsselindikator für die interne Verarbeitungseffizienz. Datenquelle Dieses Ereignis wird durch das Buchungsdatum (BKPF-BUDAT) im Belegkopf identifiziert. Bei Dokumenten, die zuerst geparkt werden, liefert der Übergang zu einem gebuchten Status den Event Timestamp. Erfassen Verwenden Sie das Buchungsdatum (BKPF-BUDAT) als Event Timestamp. Ereignistyp explicit | |||
| Rechnung storniert | Eine Aktivität, die die Stornierung eines zuvor gebuchten Rechnungsbelegs darstellt. Dies ist ein abschließendes Event für eine fehlerhafte Rechnung, die dann oft korrekt neu erfasst wird. | ||
| Bedeutung Stornierungen weisen auf kritische Fehler hin, die im Prozess nicht früher erkannt wurden. Die Verfolgung ihrer Häufigkeit und Grundursachen ist wesentlich für die Prozessverbesserung und die Reduzierung finanzieller Ungenauigkeiten. Datenquelle Eine Stornierung wird identifiziert, wenn ein Stornobeleg erstellt wird. Der Kopf des Originalbelegs (BKPF) wird die Nummer des Stornobelegs (BKPF-STBLG) enthalten und umgekehrt. Das Buchungsdatum des Stornobelegs ist die Event Time. Erfassen Identifizieren Sie Belege, die einen Wert im Feld BKPF-STBLG aufweisen, und verwenden Sie das Buchungsdatum des Stornobelegs. Ereignistyp explicit | |||
| Rechnungsbeleg angelegt | Dies ist das erste Ereignis, das die Erstellung eines Rechnungsbelegs in SAP kennzeichnet. Es kann erfasst werden, wenn ein Benutzer einen neuen Rechnungsbeleg speichert, der sich in einem geparkten oder vorläufig gebuchten Zustand befinden kann. | ||
| Bedeutung Diese Aktivität markiert den Beginn des Rechnungsverarbeitungslebenszyklus. Die Analyse der Zeit von diesem Ereignis zu anderen ist entscheidend für die Messung der gesamten Verarbeitungsdurchlaufzeit. Datenquelle Dieses Ereignis wird vom Erstellungsdatum und der Uhrzeit (CPUDT, CPUTM) in der Belegkopftabelle erfasst, typischerweise BKPF oder RBKP für Logistikrechnungen. Der Transaktionscode (BKPF-TCODE) wie FB60, MIRO oder MIR7 gibt die Erstellungsmethode an. Erfassen Verwenden Sie den Erstellungs-Timestamp aus BKPF-CPUDT und BKPF-CPUTM für den Rechnungsbeleg. Ereignistyp explicit | |||
| Zahlung ausgeführt | Dies ist die letzte Aktivität im Standardprozess, bei der die Zahlung erfolgt und die Rechnung ausgeglichen wird. Dies bedeutet, dass die Gelder an den Lieferanten ausgezahlt wurden. | ||
| Bedeutung Dies markiert das Ende des P2P-Rechnungslebenszyklus. Es ist wesentlich für die Berechnung der gesamten End-to-End-Durchlaufzeit und für die Messung der pünktlichen Zahlungsperformance im Vergleich zum Fälligkeitsdatum. Datenquelle Dieses Ereignis wird aus den Ausgleichsbeleginformationen im Kreditorenposten erfasst. Das Ausgleichsdatum (BSEG-AUGDT) und der Ausgleichsbeleg (BSEG-AUGBL) zeigen an, dass die Zahlung erfolgt ist. Erfassen Verwenden Sie das Ausgleichsdatum (BSEG-AUGDT) aus dem ausgeglichenen Kreditorenposten. Ereignistyp explicit | |||
| Rechnung abgelehnt | Stellt die Ablehnung einer Rechnung während des Genehmigungsprozesses dar. Dieses Ereignis löst Nacharbeit aus, was Korrektur und erneute Einreichung erfordert. | ||
| Bedeutung Rechnungsablehnungen sind ein Schlüsselindikator für Prozesseffizienz und Datenqualitätsprobleme. Die Analyse der Ablehnungshäufigkeit und -gründe hilft, Verbesserungspotenziale und Schulungsbedarfe zu identifizieren. Datenquelle Dies wird abgeleitet aus spezifischen Statusaktualisierungen in einem SAP Workflow, wie einem 'abgelehnt'-Status, oder aus Ereignissen, die den aktuellen Genehmigungs-Workflow abbrechen und ihn an den Bearbeiter zurücksenden. Erfassen Ableitung aus Änderungen des Workflow-Status, die eine Ablehnung anzeigen. Ereignistyp inferred | |||
| Rechnung geparkt | Stellt eine Rechnung dar, die ins System eingegeben wurde, aber noch nicht im Hauptbuch gebucht ist. Das Parken dient dazu, unvollständige Rechnungen zu speichern oder für eine spätere Prüfung vor der Buchung. | ||
| Bedeutung Das Parken signalisiert eine bewusste Pause im Prozess. Die Verfolgung der Dauer und Häufigkeit geparkter Rechnungen hilft, Gründe für Verzögerungen zu identifizieren, bevor der formelle Buchungs- und Genehmigungszyklus beginnt. Datenquelle Dies kann durch Dokumente identifiziert werden, die über Parktransaktionen erstellt wurden (z. B. MIR7, FV60) oder durch Prüfung spezifischer Statusfelder in der Tabelle BKPF oder dedizierten Tabellen für geparkte Dokumente wie VBKPF. Erfassen Identifizieren Sie Belege, die über Park-Transaktionen erstellt wurden, oder prüfen Sie auf den Status eines geparkten Belegs. Ereignistyp explicit | |||
| Rechnung zur Genehmigung gesendet | Diese Aktivität markiert den Beginn eines formellen Genehmigungs-Workflows für die Rechnung. Dies wird oft abgeleitet, wenn sich der Status der Rechnung in 'zur Genehmigung ausstehend' ändert oder ein Workflow-Element generiert wird. | ||
| Bedeutung Dies ist der Ausgangspunkt für die Messung der Genehmigungsdurchlaufzeit. Zu verstehen, wann Genehmigungen beginnen, ist wesentlich für die Identifizierung von Engpässen im Genehmigungs-Workflow selbst. Datenquelle Dies wird typischerweise abgeleitet vom Start eines SAP Business Workflows (Tabelle SWW_WI2OBJ), verknüpft mit dem Rechnungsobjekt (z. B. BUS2081), oder einer Änderung in einem kundeneigenen Statusfeld im Belegkopf. Erfassen Ableitung aus der Erstellung eines Workflow-Items, das mit dem Rechnungsbeleg verknüpft ist. Ereignistyp inferred | |||
| Rechnungsdaten aktualisiert | Diese Aktivität spiegelt eine Änderung wider, die am Rechnungsbeleg nach seiner initialen Erstellung vorgenommen wurde. Dies ist häufig bei Nacharbeitszyklen nach einer Ablehnung oder zur Fehlerkorrektur der Fall. | ||
| Bedeutung Häufige Aktualisierungen signalisieren Nacharbeit und potenzielle Datenqualitätsprobleme am Eingabepunkt. Die Verfolgung dieser Änderungen hilft, den Aufwand für Korrekturen zu quantifizieren und häufige Fehler zu identifizieren. Datenquelle Änderungen an Schlüsselfeldern werden in den Änderungsbelegtabellen von SAP, CDHDR (Kopf) und CDPOS (Position), protokolliert. Events können durch Filterung nach Änderungen am relevanten Rechnungsobjekt generiert werden. Erfassen Extrahieren Sie Änderungs-Events aus den Tabellen CDHDR und CDPOS für das Rechnungsobjekt. Ereignistyp explicit | |||
| Späte Zahlung ausgeführt | Dies ist ein berechnetes Ereignis, das eintritt, wenn die Zahlung einer Rechnung ausgeführt wird nach ihrem berechneten Fälligkeitsdatum. Es wird durch den Vergleich zweier Datumsfelder abgeleitet. | ||
| Bedeutung Diese Aktivität unterstützt direkt KPIs für pünktliche Zahlungen und hilft, Lieferanten oder Geschäftseinheiten mit häufigen Zahlungsverzögerungen zu identifizieren, was Lieferantenbeziehungen schaden und zu Vertragsstrafen führen kann. Datenquelle Dies wird berechnet durch den Vergleich des Ausgleichsdatums (BSEG-AUGDT) mit dem Nettofälligkeitsdatum. Das Fälligkeitsdatum selbst wird berechnet aus dem Basisdatum (BSEG-ZFBDT) und den Zahlungsbedingungen (BSEG-ZTERM). Erfassen Ableitung durch Vergleich von BSEG-AUGDT > (BSEG-ZFBDT + Zahlungszieltagen). Ereignistyp calculated | |||
| Zahlungssperre aufgehoben | Stellt die Lösung eines Problems dar, bei dem eine zuvor gesetzte Zahlungssperre aufgehoben wird. Dadurch wird die Rechnung wieder zahlungsfähig. | ||
| Bedeutung Die Zeit zwischen dem Setzen und Aufheben einer Sperre stellt die Lösungszeit für eine Prozessausnahme dar. Eine Verkürzung dieser Dauer ist entscheidend für die Verbesserung der Effizienz und der Lieferantenbeziehungen. Datenquelle Dieses Ereignis wird erfasst, wenn das Feld Zahlungssperre (BSEG-ZLSPR) gelöscht wird. Diese Änderung wird in den Tabellen CDHDR und CDPOS protokolliert, was einen Timestamp für die Aufhebung liefert. Erfassen Identifizieren Sie, wann das Feld BSEG-ZLSPR über Änderungsbelege (CDHDR/CDPOS) gelöscht wird. Ereignistyp explicit | |||
| Zahlungssperre gesetzt | Eine Aktivität, bei der eine Rechnung absichtlich gesperrt wird, um die Zahlung zu verhindern. Dies geschieht oft aufgrund von Preis- oder Mengenabweichungen oder einer ausstehenden Gutschrift. | ||
| Bedeutung Zahlungssperren sind eine Hauptursache für verspätete Zahlungen und Lieferantenstreitigkeiten. Die Analyse der Häufigkeit, Dauer und Gründe für Sperren ist entscheidend für die Verbesserung der pünktlichen Zahlungsquoten. Datenquelle Dieses Ereignis wird durch die Verfolgung von Änderungen am Feld Zahlungssperre (BSEG-ZLSPR) im Rechnungszeileneintrag erfasst. Die Änderungsbelege in CDHDR und CDPOS liefern den Timestamp und den Benutzer für den Zeitpunkt, zu dem die Sperre gesetzt wurde. Erfassen Identifizieren Sie, wann das Feld BSEG-ZLSPR über Änderungsbelege (CDHDR/CDPOS) gefüllt wird. Ereignistyp explicit | |||
| Zahlungsvorschlag erstellt | Die Rechnung wird ausgewählt und in einen Zahlungsvorschlag im Rahmen eines Zahlungslaufs aufgenommen. Dies ist der erste Schritt im automatisierten Zahlungsprozess. | ||
| Bedeutung Diese Aktivität zeigt die Absicht zur Zahlung an. Verzögerungen zwischen diesem Schritt und der endgültigen Zahlungsausführung können auf Probleme im Zahlungslaufprozess, bei Genehmigungen oder in der Bankkommunikation hinweisen. Datenquelle Dies ist in den Zahlungslauftabellen zu finden, insbesondere in REGUP, die die in einem Zahlungsvorschlag enthaltenen Posten enthält. Das Laufdatum in der entsprechenden Tabelle REGUH liefert den Timestamp. Erfassen Identifizieren Sie, wann eine Rechnung in der Tabelle REGUP aus einem Zahlungsvorschlagslauf erscheint. Ereignistyp explicit | |||
Extraktionsleitfäden
Schritte
- Voraussetzungen und Berechtigung: Stellen Sie sicher, dass der Benutzer, der die Extraktion ausführt, die erforderlichen Berechtigungen in SAP S/4HANA besitzt, um auf die benötigten Core Data Services (CDS) Views zuzugreifen. Wichtige Views sind
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemundI_PaymentProposalItem. Der Benutzer benötigt auch Berechtigungen zur Ausführung von Abfragen über die gewählte Schnittstelle, wie z.B. einen OData-Dienst oder eine direkte SQL-Verbindung. - Ihre Verbindungsmethode identifizieren: Legen Sie fest, wie Sie eine Verbindung zum SAP S/4HANA-System herstellen, um die SQL-Abfrage auszuführen. Gängige Methoden sind die Verwendung von SAP Data Services, SAP Data Intelligence, einem Drittanbieter-ETL-Tool mit SAP-Konnektor oder eine direkte SQL-Verbindung zur SAP HANA-Datenbank, sofern dies durch die Sicherheitsrichtlinien Ihres Unternehmens erlaubt ist.
- Extraktionsparameter definieren: Bevor Sie die Abfrage ausführen, definieren Sie die Schlüsselparameter. Geben Sie den Datumsbereich für die Extraktion an, z.B.
CreationDatezwischen'JJJJ-MM-TT'und'JJJJ-MM-TT'. Identifizieren Sie außerdem die spezifischenCompanyCode-Werte, die Sie einschließen möchten, um den Umfang der Datenextraktion zu begrenzen. - SQL-Abfrage anpassen: Kopieren Sie die bereitgestellte SQL-Abfrage in Ihren ausgewählten SQL-Client oder Ihr Datenextraktionstool. Überprüfen Sie sorgfältig die Platzhalter, wie z.B.
'{StartDate}','{EndDate}'und('{CompanyCode1}', '{CompanyCode2}'). Ersetzen Sie diese Platzhalter durch die tatsächlichen Werte, die Sie im vorherigen Schritt definiert haben. Möglicherweise müssen Sie auch Feldnamen für den Workflow-Status basierend auf Ihrer spezifischen SAP-Konfiguration anpassen. - Abfrage ausführen: Führen Sie die vollständige SQL-Abfrage gegen die SAP S/4HANA-Datenbank oder über die entsprechende Service-Schicht aus. Die Abfrage ist umfassend konzipiert und kann je nach Datenvolumen und ausgewähltem Datumsbereich eine erhebliche Ausführungszeit in Anspruch nehmen. Überwachen Sie die Ausführung auf mögliche Fehler oder Timeouts.
- Erste Ergebnisse überprüfen: Sobald die Abfrage abgeschlossen ist, führen Sie eine kurze Überprüfung der Ausgabe durch. Prüfen Sie, ob die Spalten
InvoiceNumber,ActivityNameundEventTimegefüllt sind. Vergewissern Sie sich, dass Sie eine Vielzahl unterschiedlicher Aktivitäten in der SpalteActivityNamesehen und nicht nur 'Invoice Document Created'. - Datenumwandlung berücksichtigen: Die Abfrage ist so strukturiert, dass sie ein sauberes Event Log-Format erzeugt. Stellen Sie jedoch sicher, dass die Spalte
EventTimein einem konsistenten Timestamp-Format vorliegt, z.B.JJJJ-MM-TTTHH:MM:SS. Die bereitgestellte Abfrage kombiniert Datum- und Zeitfelder bei Bedarf zu einem einzigen Timestamp. - Daten exportieren: Exportieren Sie das finale Ergebnis aus Ihrem Tool in eine CSV-Datei (Comma-Separated Values). Dieses Format ist universell kompatibel mit Process Mining-Tools, einschließlich ProcessMind.
- Vorbereitung für den Upload: Bestätigen Sie vor dem Hochladen, dass die CSV-Datei die UTF-8-Kodierung verwendet, um Zeichenprobleme zu vermeiden. Stellen Sie sicher, dass die Spaltenüberschriften in der Datei exakt den erforderlichen Attributen entsprechen:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, etc. - Upload zu ProcessMind: Laden Sie die vorbereitete CSV-Datei in Ihr Process Mining-Projekt hoch. Ordnen Sie die Spalten aus Ihrer Datei den entsprechenden Case-ID-, Aktivitätsnamen- und Timestamp-Feldern in der Datenmodellkonfiguration des Tools zu.
Konfiguration
- Verwendete CDS Views: Die primären Datenquellen sind Standard-SAP-CDS-Views. Die wichtigsten Views sind
I_InvoiceDocumentfür Kopfdaten,I_OperationalAcctgDocItemfür Details zu Finanzbuchungen und -ausgleichen sowieI_ChangeDocumentmitI_ChangeDocumentItemzur Verfolgung historischer Änderungen an Rechnungsattributen wie Zahlungssperren und Workflow-Status. - Filterung nach Datumsbereich: Es ist entscheidend, die Daten nach einem spezifischen Datumsbereich zu filtern, um die Performance zu steuern. Die bereitgestellte Abfrage verwendet einen Platzhalter für das
CreationDatein derI_InvoiceDocument-View. Ein empfohlener Startpunkt ist ein Datensatz von 3 bis 6 Monaten. - Buchungskreis-Filter: Um sicherzustellen, dass die Extraktion relevant und handhabbar ist, filtern Sie immer nach einem oder mehreren
CompanyCode. Die Abfrage enthält zu diesem Zweck einen PlatzhalterWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}'). - Belegart-Filter: Sie können die Extraktion weiter verfeinern, indem Sie nach
InvoiceDocumentTypefiltern. Zum Beispiel möchten Sie möglicherweise Standard-Lieferantenrechnungen (RE) einschließen, aber Gutschriften ausschließen. Dies kann derWHERE-Klausel des initialen CTE hinzugefügt werden. - Voraussetzungen: Der Benutzer, der die Abfrage ausführt, benötigt entsprechende Anzeigeberechtigungen für Finanz- und Einkaufsbelege innerhalb der angegebenen Buchungskreise. Der Zugriff auf die zugrunde liegende HANA-Datenbank über einen SQL-Client ist nicht Standard und erfordert spezielle Berechtigungen.
- Performance-Überlegungen: Das Extrahieren von Daten aus Änderungsbelegtabellen (
I_ChangeDocument,I_ChangeDocumentItem) kann performance-intensiv sein. Das Anwenden strenger Filter nach Datum, Buchungskreis und Objektklasse (INCOMINGINVOICE) ist unerlässlich, um lange Ausführungszeiten zu vermeiden.
a Beispielabfrage sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Schritte
- Voraussetzungen und Berechtigung: Stellen Sie sicher, dass der Benutzer, der die Extraktion ausführt, die erforderlichen Berechtigungen in SAP S/4HANA besitzt, um auf die benötigten Core Data Services (CDS) Views zuzugreifen. Wichtige Views sind
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemundI_PaymentProposalItem. Der Benutzer benötigt auch Berechtigungen zur Ausführung von Abfragen über die gewählte Schnittstelle, wie z.B. einen OData-Dienst oder eine direkte SQL-Verbindung. - Ihre Verbindungsmethode identifizieren: Legen Sie fest, wie Sie eine Verbindung zum SAP S/4HANA-System herstellen, um die SQL-Abfrage auszuführen. Gängige Methoden sind die Verwendung von SAP Data Services, SAP Data Intelligence, einem Drittanbieter-ETL-Tool mit SAP-Konnektor oder eine direkte SQL-Verbindung zur SAP HANA-Datenbank, sofern dies durch die Sicherheitsrichtlinien Ihres Unternehmens erlaubt ist.
- Extraktionsparameter definieren: Bevor Sie die Abfrage ausführen, definieren Sie die Schlüsselparameter. Geben Sie den Datumsbereich für die Extraktion an, z.B.
CreationDatezwischen'JJJJ-MM-TT'und'JJJJ-MM-TT'. Identifizieren Sie außerdem die spezifischenCompanyCode-Werte, die Sie einschließen möchten, um den Umfang der Datenextraktion zu begrenzen. - SQL-Abfrage anpassen: Kopieren Sie die bereitgestellte SQL-Abfrage in Ihren ausgewählten SQL-Client oder Ihr Datenextraktionstool. Überprüfen Sie sorgfältig die Platzhalter, wie z.B.
'{StartDate}','{EndDate}'und('{CompanyCode1}', '{CompanyCode2}'). Ersetzen Sie diese Platzhalter durch die tatsächlichen Werte, die Sie im vorherigen Schritt definiert haben. Möglicherweise müssen Sie auch Feldnamen für den Workflow-Status basierend auf Ihrer spezifischen SAP-Konfiguration anpassen. - Abfrage ausführen: Führen Sie die vollständige SQL-Abfrage gegen die SAP S/4HANA-Datenbank oder über die entsprechende Service-Schicht aus. Die Abfrage ist umfassend konzipiert und kann je nach Datenvolumen und ausgewähltem Datumsbereich eine erhebliche Ausführungszeit in Anspruch nehmen. Überwachen Sie die Ausführung auf mögliche Fehler oder Timeouts.
- Erste Ergebnisse überprüfen: Sobald die Abfrage abgeschlossen ist, führen Sie eine kurze Überprüfung der Ausgabe durch. Prüfen Sie, ob die Spalten
InvoiceNumber,ActivityNameundEventTimegefüllt sind. Vergewissern Sie sich, dass Sie eine Vielzahl unterschiedlicher Aktivitäten in der SpalteActivityNamesehen und nicht nur 'Invoice Document Created'. - Datenumwandlung berücksichtigen: Die Abfrage ist so strukturiert, dass sie ein sauberes Event Log-Format erzeugt. Stellen Sie jedoch sicher, dass die Spalte
EventTimein einem konsistenten Timestamp-Format vorliegt, z.B.JJJJ-MM-TTTHH:MM:SS. Die bereitgestellte Abfrage kombiniert Datum- und Zeitfelder bei Bedarf zu einem einzigen Timestamp. - Daten exportieren: Exportieren Sie das finale Ergebnis aus Ihrem Tool in eine CSV-Datei (Comma-Separated Values). Dieses Format ist universell kompatibel mit Process Mining-Tools, einschließlich ProcessMind.
- Vorbereitung für den Upload: Bestätigen Sie vor dem Hochladen, dass die CSV-Datei die UTF-8-Kodierung verwendet, um Zeichenprobleme zu vermeiden. Stellen Sie sicher, dass die Spaltenüberschriften in der Datei exakt den erforderlichen Attributen entsprechen:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode, etc. - Upload zu ProcessMind: Laden Sie die vorbereitete CSV-Datei in Ihr Process Mining-Projekt hoch. Ordnen Sie die Spalten aus Ihrer Datei den entsprechenden Case-ID-, Aktivitätsnamen- und Timestamp-Feldern in der Datenmodellkonfiguration des Tools zu.
Konfiguration
- Verwendete CDS Views: Die primären Datenquellen sind Standard-SAP-CDS-Views. Die wichtigsten Views sind
I_InvoiceDocumentfür Kopfdaten,I_OperationalAcctgDocItemfür Details zu Finanzbuchungen und -ausgleichen sowieI_ChangeDocumentmitI_ChangeDocumentItemzur Verfolgung historischer Änderungen an Rechnungsattributen wie Zahlungssperren und Workflow-Status. - Filterung nach Datumsbereich: Es ist entscheidend, die Daten nach einem spezifischen Datumsbereich zu filtern, um die Performance zu steuern. Die bereitgestellte Abfrage verwendet einen Platzhalter für das
CreationDatein derI_InvoiceDocument-View. Ein empfohlener Startpunkt ist ein Datensatz von 3 bis 6 Monaten. - Buchungskreis-Filter: Um sicherzustellen, dass die Extraktion relevant und handhabbar ist, filtern Sie immer nach einem oder mehreren
CompanyCode. Die Abfrage enthält zu diesem Zweck einen PlatzhalterWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}'). - Belegart-Filter: Sie können die Extraktion weiter verfeinern, indem Sie nach
InvoiceDocumentTypefiltern. Zum Beispiel möchten Sie möglicherweise Standard-Lieferantenrechnungen (RE) einschließen, aber Gutschriften ausschließen. Dies kann derWHERE-Klausel des initialen CTE hinzugefügt werden. - Voraussetzungen: Der Benutzer, der die Abfrage ausführt, benötigt entsprechende Anzeigeberechtigungen für Finanz- und Einkaufsbelege innerhalb der angegebenen Buchungskreise. Der Zugriff auf die zugrunde liegende HANA-Datenbank über einen SQL-Client ist nicht Standard und erfordert spezielle Berechtigungen.
- Performance-Überlegungen: Das Extrahieren von Daten aus Änderungsbelegtabellen (
I_ChangeDocument,I_ChangeDocumentItem) kann performance-intensiv sein. Das Anwenden strenger Filter nach Datum, Buchungskreis und Objektklasse (INCOMINGINVOICE) ist unerlässlich, um lange Ausführungszeiten zu vermeiden.
a Beispielabfrage sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Schritte
- Zugriff auf den ABAP Editor: Melden Sie sich in Ihrem SAP S/4HANA-System an. Öffnen Sie Transaktion
SE38(ABAP Editor). - Programm erstellen: Geben Sie einen Namen für Ihr neues Programm in das Feld "Programm" ein, z.B.
Z_PM_INVOICE_EXTRACT, und klicken Sie auf die Schaltfläche 'Anlegen'. Geben Sie einen Titel an, setzen Sie den Typ auf 'Ausführbares Programm' und speichern Sie es in einem geeigneten Paket. - Programmstruktur und Selektionsbild definieren: Definieren Sie im Editor die Datenstrukturen für die finale Event Log-Ausgabe. Erstellen Sie dann ein Selektionsbild, damit Benutzer Parameter wie einen Datumsbereich für das Rechnungseingangsdatum, Buchungskreise und Belegarten eingeben können. Dies macht das Programm wiederverwendbar und flexibel.
- Datenextraktionslogik implementieren: Schreiben Sie die zentralen ABAP SQL-Anweisungen, um Daten aus den verschiedenen SAP-Tabellen auszuwählen. Das Programm wird sequenziell für jede der 13 erforderlichen Aktivitäten abfragen.
- Kopf- und Positionsdaten extrahieren: Für grundlegende Events wie 'Rechnungsbeleg erstellt' und 'Rechnung gebucht' wählen Sie Daten aus primären Tabellen wie
RBKP(Logistik-Rechnungskopf) undBKPF(Buchhaltungsbelegkopf) aus. - Änderungsbelegdaten extrahieren: Für Aktivitäten wie 'Zahlungssperre gesetzt' und 'Zahlungssperre entfernt' fragen Sie die Änderungsbelegtabellen
CDHDR(Änderungsbelegkopf) undCDPOS(Änderungsbelegpositionen) ab. Sie müssen Änderungen an spezifischen Feldern identifizieren, zum BeispielZLSPRin TabelleBSEG. - Zahlungsdaten extrahieren: Um zahlungsbezogene Aktivitäten zu erfassen, fragen Sie Tabellen wie
REGUP(Verarbeitete Positionen aus dem Zahlprogramm) für Zahlungsvorschläge undBSAK(Ausgeglichene Lieferantenpositionen) für ausgeführte Zahlungen ab. Unterscheiden Sie 'Späte Zahlung ausgeführt', indem Sie das Ausgleichsdatum (AUGDT) mit dem Nettofälligkeitsdatum (ZFBDT) vergleichen. - Workflow-Daten extrahieren: Für Genehmigungsaktivitäten fragen Sie SAP Business Workflow-Tabellen wie
SWW_WI2OBJab, um Workflow-Positionen mit Rechnungs-Objekten zu verknüpfen. Dieser Teil hängt stark von Ihrer spezifischen Workflow-Konfiguration ab und erfordert möglicherweise erhebliche Anpassungen. - Daten in Event Log-Format vereinheitlichen: Formatieren Sie für jede ausgewählte Aktivität die Daten in eine gemeinsame interne Tabellenstruktur. Jede Zeile in dieser Tabelle repräsentiert ein einzelnes Event und muss den Case-Identifikator (
InvoiceNumber),ActivityNameundEventTimesowie weitere empfohlene Attribute enthalten. - Ausgabedatei generieren: Verwenden Sie ABAP-Anweisungen
OPEN DATASET,TRANSFERundCLOSE DATASET, um den Inhalt der finalen internen Tabelle in eine Flatfile auf dem SAP-Applikationsserver zu schreiben. Ein durch Kommas getrenntes Format (CSV) wird empfohlen. - Planen und Ausführen: Führen Sie das Programm im Vordergrund zum Testen aus (mittels
F8). Für Produktionsläufe planen Sie es als Hintergrundjob über TransaktionSM36ein, um es außerhalb der Stoßzeiten auszuführen und System-Performance-Engpässe zu vermeiden. - Abrufen und Hochladen: Verwenden Sie Transaktion
AL11, um zum Verzeichnis des Applikationsservers zu navigieren, in dem die Datei gespeichert wurde. Laden Sie die Datei auf Ihr lokales System herunter. Stellen Sie sicher, dass die Datei UTF-8-kodiert und korrekt formatiert ist, bevor Sie sie in das Process Mining-Tool hochladen.
Konfiguration
- Datumsbereich: Definieren Sie einen spezifischen Datumsbereich für die Extraktion basierend auf dem Rechnungseingangsdatum (
RBKP-CPUDT) oder Buchungsdatum (BKPF-BUDAT). Für die erste Analyse wird ein Zeitraum von 3 bis 6 Monaten empfohlen, um ein überschaubares Datenvolumen zu gewährleisten. - Buchungskreis (BUKRS): Es ist entscheidend, nach einem oder mehreren Buchungskreisen zu filtern. Das Extrahieren von Daten für alle Buchungskreise in einer großen Organisation kann zu extrem langen Laufzeiten und großen Dateien führen.
- Belegart (BLART): Filtern Sie nach relevanten Belegarten, um Lieferantenrechnungen zu isolieren. Häufige Typen sind 'RE' (Rechnung - Brutto) und 'KR' (Lieferantenrechnung). Dies hilft, irrelevante Belege von der Analyse auszuschließen.
- Lieferantenkonto (LIFNR): Das Programm kann einen optionalen Filter für spezifische Lieferantennummern enthalten, der für gezielte Analysen oder Tests nützlich ist.
- Ausgabedatei-Konfiguration: Das Programm sollte Parameter haben, um den Pfad der Ausgabedatei auf dem Applikationsserver und das Feldtrennzeichen, zum Beispiel ein Komma oder Semikolon, festzulegen.
- Voraussetzungen: Das Benutzer- oder Systemkonto, das dieses Programm ausführt, benötigt Entwicklerzugriff, um ABAP-Programme (über
SE38) zu erstellen und auszuführen, sowie umfangreiche Leseberechtigungen für FI-, MM- und Basis-Tabellen, einschließlichBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOS, und Workflow-Tabellen.
a Beispielabfrage abap
REPORT Z_PM_INVOICE_EXTRACT.
* --- Internal table structure for the final event log
TYPES: BEGIN OF ty_s_event_log,
invoicenumber TYPE char25,
activityname TYPE char50,
eventtime TYPE char19, "YYYY-MM-DD HH:MM:SS
username TYPE sy-uname,
companycode TYPE bukrs,
vendornumber TYPE lifnr,
amountincompanycodecurrency TYPE wrbtr,
paymentduedate TYPE char10, "YYYY-MM-DD
documenttype TYPE blart,
paymentblockreason TYPE char1,
purchasingdocument TYPE ebeln,
END OF ty_s_event_log.
DATA: lt_event_log TYPE STANDARD TABLE OF ty_s_event_log.
DATA: ls_event_log TYPE ty_s_event_log.
* --- Selection Screen for user inputs
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/tmp/invoice_events.csv'.
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY, " Entry Date
s_bukrs FOR bkpf-bukrs OBLIGATORY, " Company Code
s_blart FOR bkpf-blart. " Document Type
START-OF-SELECTION.
* --- 1. Invoice Document Created (from Logistics Invoice Verification)
SELECT CONCAT( rbkp~belnr, rbkp~gjahr ) AS invoicenumber,
'Invoice Document Created' AS activityname,
CONCAT( rbkp~cpudt, rbkp~cputm ) AS eventtime,
rbkp~usnam AS username,
rbkp~bukrs AS companycode,
rbkp~lifnr AS vendornumber,
rbkp~rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
rbkp~blart AS documenttype,
rbkp~zuonr AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_created)
WHERE rbkp~cpudt IN @s_erdat
AND rbkp~bukrs IN @s_bukrs
AND rbkp~blart IN @s_blart.
LOOP AT lt_created INTO DATA(ls_created).
ls_event_log-invoicenumber = ls_created-invoicenumber.
ls_event_log-activityname = ls_created-activityname.
ls_event_log-eventtime = |{ ls_created-eventtime(8) } { ls_created-eventtime+8(2) }:{ ls_created-eventtime+10(2) }:{ ls_created-eventtime+12(2) }|.
ls_event_log-username = ls_created-username.
ls_event_log-companycode = ls_created-companycode.
ls_event_log-vendornumber = ls_created-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_created-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_created-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ls_created-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 2. Invoice Parked (assuming status 'A' or 'B' in RBKP)
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
'Invoice Parked' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
lifnr AS vendornumber,
rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_parked)
WHERE rbstat IN ('A', 'B')
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs
AND blart IN @s_blart.
LOOP AT lt_parked INTO DATA(ls_parked).
ls_event_log-invoicenumber = ls_parked-invoicenumber.
ls_event_log-activityname = ls_parked-activityname.
ls_event_log-eventtime = |{ ls_parked-eventtime(8) } { ls_parked-eventtime+8(2) }:{ ls_parked-eventtime+10(2) }:{ ls_parked-eventtime+12(2) }|.
ls_event_log-username = ls_parked-username.
ls_event_log-companycode = ls_parked-companycode.
ls_event_log-vendornumber = ls_parked-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_parked-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_parked-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ''.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 3, 4, 5. Sent For Approval, Approved, Rejected (Placeholder logic, needs adaptation)
* --- This logic is a generic template for SAP Business Workflow.
* --- Your implementation will vary. You must identify the correct workflow tasks.
SELECT obj.instid, wi.wi_cd, wi.wi_ct, wi.wi_stat, wi.wi_aagent
FROM sww_wi2obj AS obj
JOIN swwlog AS wi ON obj~instid = wi~wi_id
INTO TABLE @DATA(lt_workflow)
WHERE obj~typeid = 'BUS2081' " Business Object for Incoming Invoice
AND obj~catid = 'BO'
AND wi~wi_cd IN s_erdat.
LOOP AT lt_workflow INTO DATA(ls_workflow).
* --- This is a placeholder, adapt task IDs and logic
CASE ls_workflow-wi_stat.
WHEN 'STARTED'.
ls_event_log-activityname = 'Invoice Sent For Approval'.
WHEN 'COMPLETED'.
ls_event_log-activityname = 'Invoice Approved'.
WHEN 'CANCELLED'.
ls_event_log-activityname = 'Invoice Rejected'.
WHEN OTHERS.
CONTINUE.
ENDCASE.
* --- Code to get invoice details based on ls_workflow-instid needed here
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 6, 7, 8. Payment Block Set/Removed, Data Updated (from Change Docs)
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new, p~value_old
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectclas = p~objectclas AND h~objectid = p~objectid AND h~changenr = p~changenr
INTO TABLE @DATA(lt_changes)
WHERE h~objectclas = 'BELEGV'
AND h~udate IN s_erdat.
LOOP AT lt_changes INTO DATA(ls_change).
ls_event_log-invoicenumber = |{ ls_change-objectid+10(10) }{ ls_change-objectid(4) }|.
ls_event_log-username = ls_change-username.
ls_event_log-eventtime = |{ ls_change-udate } { ls_change-utime(2) }:{ ls_change-utime+2(2) }:{ ls_change-utime+4(2) }|.
IF ls_change-fname = 'ZLSPR'. " Payment Block
IF ls_change-value_old IS INITIAL AND ls_change-value_new IS NOT INITIAL.
ls_event_log-activityname = 'Payment Block Set'.
ls_event_log-paymentblockreason = ls_change-value_new.
ELSEIF ls_change-value_old IS NOT INITIAL AND ls_change-value_new IS INITIAL.
ls_event_log-activityname = 'Payment Block Removed'.
ls_event_log-paymentblockreason = ''.
ELSE.
CONTINUE.
ENDIF.
ELSE.
ls_event_log-activityname = 'Invoice Data Updated'.
ENDIF.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 9. Invoice Posted
SELECT CONCAT( bkpf~belnr, bkpf~gjahr ) AS invoicenumber,
'Invoice Posted' AS activityname,
CONCAT( bkpf~cpudt, bkpf~cputm ) AS eventtime,
bkpf~usnam AS username,
bkpf~bukrs AS companycode,
bseg~lifnr AS vendornumber,
bseg~wrbtr AS amountincompanycodecurrency,
bseg~zfBDT AS paymentduedate,
bkpf~blart AS documenttype,
bseg~zlspr AS paymentblockreason,
bseg~ebeln AS purchasingdocument
FROM bkpf
JOIN bseg ON bkpf~bukrs = bseg~bukrs AND bkpf~belnr = bseg~belnr AND bkpf~gjahr = bseg~gjahr
INTO TABLE @DATA(lt_posted)
WHERE bkpf~cpudt IN @s_erdat
AND bkpf~bukrs IN @s_bukrs
AND bkpf~blart IN @s_blart
AND bseg~koart = 'K'. " Vendor line
LOOP AT lt_posted INTO DATA(ls_posted).
ls_event_log-invoicenumber = ls_posted-invoicenumber.
ls_event_log-activityname = ls_posted-activityname.
ls_event_log-eventtime = |{ ls_posted-eventtime(8) } { ls_posted-eventtime+8(2) }:{ ls_posted-eventtime+10(2) }:{ ls_posted-eventtime+12(2) }|.
ls_event_log-username = ls_posted-username.
ls_event_log-companycode = ls_posted-companycode.
ls_event_log-vendornumber = ls_posted-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_posted-amountincompanycodecurrency.
ls_event_log-paymentduedate = ls_posted-paymentduedate.
ls_event_log-documenttype = ls_posted-documenttype.
ls_event_log-paymentblockreason = ls_posted-paymentblockreason.
ls_event_log-purchasingdocument = ls_posted-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 10. Payment Proposal Created
SELECT CONCAT( regup~belnr, regup~gjahr ) AS invoicenumber,
'Payment Proposal Created' AS activityname,
CONCAT( reguh~erfdt, reguh~erfzt ) AS eventtime,
reguh~erfbu AS username,
regup~bukrs AS companycode,
regup~lifnr AS vendornumber,
regup~wrbtr AS amountincompanycodecurrency,
'' AS paymentduedate,
regup~blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM regup
JOIN reguh ON regup~laufd = reguh~laufd AND regup~laufi = reguh~laufi
INTO TABLE @DATA(lt_proposal)
WHERE reguh~erfdt IN @s_erdat
AND regup~bukrs IN @s_bukrs.
LOOP AT lt_proposal INTO DATA(ls_proposal).
ls_event_log-invoicenumber = ls_proposal-invoicenumber.
ls_event_log-activityname = ls_proposal-activityname.
ls_event_log-eventtime = |{ ls_proposal-eventtime(8) } { ls_proposal-eventtime+8(2) }:{ ls_proposal-eventtime+10(2) }:{ ls_proposal-eventtime+12(2) }|.
ls_event_log-username = ls_proposal-username.
ls_event_log-companycode = ls_proposal-companycode.
ls_event_log-vendornumber = ls_proposal-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_proposal-amountincompanycodecurrency.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 11, 12. Payment Executed / Late Payment Executed
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
augdt,
zfBDT
FROM bsak
INTO TABLE @DATA(lt_cleared)
WHERE augdt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_cleared INTO DATA(ls_cleared).
IF ls_cleared-augdt > ls_cleared-zfbdt.
ls_event_log-activityname = 'Late Payment Executed'.
ELSE.
ls_event_log-activityname = 'Payment Executed'.
ENDIF.
ls_event_log-invoicenumber = ls_cleared-invoicenumber.
ls_event_log-eventtime = |{ ls_cleared-augdt } 00:00:00|.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 13. Invoice Reversed
SELECT CONCAT( stblg, stjah ) AS invoicenumber,
'Invoice Reversed' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
'' AS vendornumber,
'' AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM bkpf
INTO TABLE @DATA(lt_reversed)
WHERE stblg IS NOT NULL
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_reversed INTO DATA(ls_reversed).
ls_event_log-invoicenumber = ls_reversed-invoicenumber.
ls_event_log-activityname = ls_reversed-activityname.
ls_event_log-eventtime = |{ ls_reversed-eventtime(8) } { ls_reversed-eventtime+8(2) }:{ ls_reversed-eventtime+10(2) }:{ ls_reversed-eventtime+12(2) }|.
ls_event_log-username = ls_reversed-username.
ls_event_log-companycode = ls_reversed-companycode.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- Write internal table to CSV file
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_any> TYPE any.
* --- Header row
lv_line = 'InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReason,PurchasingDocument'.
TRANSFER lv_line TO p_path.
LOOP AT lt_event_log INTO ls_event_log.
CLEAR lv_line.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE ls_event_log TO <fs_any>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF sy-index = 1.
lv_line = <fs_any>.
ELSE.
CONCATENATE lv_line <fs_any> INTO lv_line SEPARATED BY ','.
ENDIF.
ENDDO.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: / 'Extraction complete. File saved to:', p_path.