Ihre Beschaffung bis zur Zahlung – Rechnungsverarbeitungs-Daten-Vorlage
Ihre Beschaffung bis zur Zahlung – Rechnungsverarbeitungs-Daten-Vorlage
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten für das Tracking
- Extraktionsleitfaden für SAP S/4HANA
Beschaffung bis zur 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, zusammenhängenden Prozessinstanz. Im Process Mining ist dieses Attribut wesentlich für die Verfolgung des End-to-End-Prozesses 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 Ereignisse 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 den Antrag bearbeitet.es Ereignisse, 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 maßgeblich für die Erstellung der Prozessablauf, 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 ist die Basis 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 den Antrag bearbeitet.ie Aktivität stattgefunden hat. | ||
| Beschreibung Event Time ist der Zeitstempel, der genau festhält, wann eine bestimmte Aktivität stattgefunden hat. Diese Daten sind essenziell für die Berechnung von Dauern, Durchlaufzeiten und Wartezeiten zwischen verschiedenen Prozessschritten. In der Process Mining-Analyse werden genaue Zeitstempels verwendet, um Leistungsfähigkeit-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 Zeitstempel ist die Grundlage für alle zeitbasierten Analysen, einschließlich Leistungsfähigkeit Monitoring, Engpassidentifikation und SLA-Verfolgung. 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 den Antrag bearbeitet.es Systems, die/das die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut identifiziert den Anwender, 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' wichtig ist. Bedeutung Es ordnet Prozessaktivitäten spezifischen Benutzern oder Systemkonten zu und ermöglicht so Arbeitslastanalysen, Leistungsfähigkeit-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 Bestellnummer verknüpft die Lieferantenrechnung mit der ursprünglichen Bestellung (PO). Diese Verknüpfung ist wesentlich für den Drei-Wege-Abgleich, der den Antrag bearbeitet.ie 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 maßgeblich 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) notwendig ist. Datenquelle Diese Information ist in der Regel zu finden in der Belegsegmenttabelle BSEG, Feld EBELN (Bestellnummer). 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 den Antrag bearbeitet.ie 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 analysierenn. 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-Leistungsfähigkeit ü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' in der Regel 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 maßgeblich 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 den Antrag bearbeitet.ie 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 maßgeblich für die Lieferanten-zentrierte Analyse, wie die Bewertung der 'Lieferantenzahlungsperformance' oder den Antrag bearbeitet.ie 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 Lieferantenleistungsstarkkeit. Bedeutung Ermöglicht die Analyse der Prozess-Performance 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 in der Regel 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 wichtig 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 Prozessoptimierung 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, in der Regel 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 Zeitstempel zu identifizieren, was für die Berechnung der End-to-End-Durchlaufzeit und der pünktlichen Zahlungsrate notwendig ist. Bedeutung Bestätigt, dass eine Rechnung bezahlt wurde, und verknüpft sie mit der spezifischen Zahlungstransaktion, was wichtig für die Zykluszeit- und Zahlungsleistungsanalyse ist. Datenquelle Gefunden in der Belegsegmenttabelle BSEG, Feld AUGBL (Ausgleichsbelegnummer). Beispiele 150000000115000000231500000088 | |||
| Extraktions-Zeitstempel ExtractionTimestamp | Das Datum und die Uhrzeit der Datenextraktion aus dem Quellsystem. | ||
| Beschreibung Dieses Attribut zeichnet den Zeitstempel 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 maßgeblich 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 BenutzerName. Eine Zuordnung oder Regel wird erstellt, um spezifische Benutzer-IDs als 'automatisiert' zu klassifizieren. Beispiele JaNein | |||
| 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 JaNein | |||
| 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 stellt ... sicher die Datenherkunft und ist maßgeblich für die Daten 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 Daten Governance und den Vergleich von Prozessen über verschiedene Systeme oder Unternehmensstandorte hinweg notwendig ist. Datenquelle Dieser Wert wird in der Regel 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 | |||
| 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 notwendig ist. Datenquelle Gefunden in der Belegkopftabelle BKPF, Feld BLDAT (Belegdatum). Beispiele 2023-04-122023-05-152023-06-20 | |||
| Stornogrund ReversalReason | Ein Code, der den Antrag bearbeitet.en 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 geverwendet 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 Zeitstempel 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 'On-Time-Payment-Rate'. 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 wichtiger KPI für das Lieferantenbeziehungsmanagement und die Finanzprozesse ist. Datenquelle Berechnet durch den Vergleich der Ereigniszeitpunkt (Event Time) der Aktivität 'Zahlung ausgeführt' mit dem Attribut PaymentDueDate. (Zahlungsdatum <= Fälligkeitsdatum). Beispiele JaNein | |||
| Zahlungsbedingungen PaymentTerms | Der Code, der den Antrag bearbeitet.ie 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 | |||
Beschaffung bis zur 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 den Antrag bearbeitet.ie 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 den Antrag bearbeitet.urch Verfolgung von Änderungen an Freigabestatusfeldern in Tabellen abgeleitet werden, die mit der Rechnung oder ihrem Einkaufsbeleg verbunden sind. Erfassen Ableitung aus Workflow-Abschluss-Ereignisse 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 den Antrag bearbeitet.ie 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 Zeitstempel. Erfassen Verwenden Sie das Buchungsdatum (BKPF-BUDAT) als Event Zeitstempel. 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 Prozessoptimierung 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 maßgeblich für die Messung der gesamten Verarbeitungsdurchlaufzeit. Datenquelle Dieses Ereignis wird vom Erstellungsdatum und der Uhrzeit (CPUDT, CPUTM) in der Belegkopftabelle erfasst, in der Regel BKPF oder RBKP für Logistikrechnungen. Der Transaktionscode (BKPF-TCODE) wie FB60, MIRO oder MIR7 gibt die Erstellungsmethode an. Erfassen Verwenden Sie den Erstellungs-Zeitstempel 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 den Antrag bearbeitet.ie 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 AusgleichsbelegHinweisrmationen 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 den Antrag bearbeitet.urch Prüfung spezifischer Statusfelder in der Tabelle BKPF oder den Antrag bearbeitet.edizierten 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 ausstehende Zahlungen identifizieren.end' ä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 in der Regel 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. Ereignisse können durch Filterung nach Änderungen am relevanten Rechnungsobjekt generiert werden. Erfassen Extrahieren Sie Änderungs-Ereignisse 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 maßgeblich 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 Zeitstempel 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 ausstehende Zahlungen identifizieren.enden 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 maßgeblich 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 Zeitstempel 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 Zeitstempel. Erfassen Identifizieren Sie, wann eine Rechnung in der Tabelle REGUP aus einem Zahlungsvorschlagslauf erscheint. Ereignistyp explicit | |||
Extraktionsanleitungen
Schritte
- Voraussetzungen und Berechtigung: Stellen Sie sicher, dass der Benutzer, der den Antrag bearbeitet.ie Extraktion ausführt, die erforderlichen Berechtigungen in SAP S/4HANA besitzt, um auf die benötigten Core Daten Dienste (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 ODaten-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 Daten Dienste, SAP Daten 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 vollständig 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 Resultate überprüfen: Sobald die Abfrage abgeschlossen ist, führen Sie eine kurze Überprüfung der Ausgabe durch. Prüfen Sie, ob die Spalten
InvoiceNumber,ActivityNameundEreigniszeitpunkt (Event Time)gefü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
Ereigniszeitpunkt (Event Time)in einem konsistenten Zeitstempel-Format vorliegt, z.B.JJJJ-MM-TTTHH:MM:SS. Die bereitgestellte Abfrage kombiniert Datum- und Zeitfelder bei Bedarf zu einem einzigen Zeitstempel. - 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,Ereigniszeitpunkt (Event Time),BenutzerName,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 Zeitstempel-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 maßgeblich, die Daten nach einem spezifischen Datumsbereich zu filtern, um die Leistungsfähigkeit 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
InvoiceDocumentTypfiltern. 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 den Antrag bearbeitet.ie 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.
- Leistungsfähigkeit-Ü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 den Antrag bearbeitet.ie Extraktion ausführt, die erforderlichen Berechtigungen in SAP S/4HANA besitzt, um auf die benötigten Core Daten Dienste (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 ODaten-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 Daten Dienste, SAP Daten 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 vollständig 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 Resultate überprüfen: Sobald die Abfrage abgeschlossen ist, führen Sie eine kurze Überprüfung der Ausgabe durch. Prüfen Sie, ob die Spalten
InvoiceNumber,ActivityNameundEreigniszeitpunkt (Event Time)gefü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
Ereigniszeitpunkt (Event Time)in einem konsistenten Zeitstempel-Format vorliegt, z.B.JJJJ-MM-TTTHH:MM:SS. Die bereitgestellte Abfrage kombiniert Datum- und Zeitfelder bei Bedarf zu einem einzigen Zeitstempel. - 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,Ereigniszeitpunkt (Event Time),BenutzerName,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 Zeitstempel-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 maßgeblich, die Daten nach einem spezifischen Datumsbereich zu filtern, um die Leistungsfähigkeit 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
InvoiceDocumentTypfiltern. 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 den Antrag bearbeitet.ie 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.
- Leistungsfähigkeit-Ü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 Ereignisse 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-ID (
InvoiceNumber),ActivityNameundEreigniszeitpunkt (Event Time)sowie 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-Leistungsfähigkeit-Engpässe zu vermeiden. - Abrufen und Hochladen: Verwenden Sie Transaktion
AL11, um zum Verzeichnis des Applikationsservers zu bewältigen, 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 sicherstellen. - Buchungskreis (BUKRS): Es ist maßgeblich, 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 Typn 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.