Ihr Order to Cash - Fakturierungs- & Rechnungsstellungs-Data Template
Ihr Order to Cash - Fakturierungs- & Rechnungsstellungs-Data Template
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsleitfaden für SAP S/4HANA
Order to Cash - Fakturierungs- und Rechnungsstellungsattribute
| Name | Beschreibung | ||
|---|---|---|---|
| Rechnungsnummer InvoiceNumber | Der eindeutige Identifikator für einen Fakturabeleg, der als primärer Case-Identifikator für den Rechnungsstellungsprozess dient. | ||
| Beschreibung Die Rechnungsnummer, in SAP als Fakturabelegnummer bekannt, identifiziert jede Fakturierungstransaktion eindeutig. Sie fungiert als zentraler Schlüssel, der alle verbundenen Aktivitäten verknüpft, von der Rechnungserstellung und -buchung bis zum Zahlungseingang und der Abstimmung.\n\nIm Process Mining ist dieses Attribut für die Case Correlation unerlässlich. Alle Events, die dieselbe Rechnungsnummer teilen, werden zu einer einzigen Prozessinstanz gruppiert, was eine vollständige End-to-End-Analyse des Fakturierungslebenszyklus für jede einzelne Rechnung ermöglicht. Dies erlaubt die Verfolgung von Zykluszeiten, die Identifizierung von Abweichungen und die Analyse des Verlaufs jeder Rechnung. Bedeutung Es ist der fundamentale Identifikator, der alle zusammenhängenden Fakturierungsaktivitäten in einem einzigen Case verbindet und somit eine End-to-End-Prozessanalyse ermöglicht. Datenquelle SAP Tabelle: VBRK, Feld: VBELN Beispiele 900012349000567890009012 | |||
| Aktivitätsname ActivityName | Der Name der Geschäftsaktivität oder des Events, das innerhalb des Fakturierungsprozesses aufgetreten ist, wie z.B. „Rechnung erstellt“ oder „Zahlung erhalten“. | ||
| Beschreibung Der Aktivitätsname beschreibt einen spezifischen Schritt oder Meilenstein im Fakturierungslebenszyklus. Diese Aktivitäten werden aus verschiedenen Datenpunkten in SAP abgeleitet, wie z.B. Transaktionscodes, Dokumentstatusänderungen oder spezifischen Log-Einträgen, um einen sequenziellen Prozessablauf zu erstellen.\n\nDie Analyse der Reihenfolge und Häufigkeit dieser Aktivitäten ist der Kern des Process Mining. Sie hilft, die Prozesslandkarte zu visualisieren, gängige und seltene Prozessvarianten zu entdecken, Bottlenecks zwischen den Schritten zu identifizieren und die Häufigkeit von nicht wertschöpfenden Aktivitäten wie Nacharbeit oder Stornierungen zu messen. Bedeutung Dieses Attribut definiert die Schritte im Prozess und ermöglicht die Visualisierung von Prozesslandkarten sowie die Analyse von Prozessabläufen, Variationen und Bottlenecks. Datenquelle Abgeleitet aus verschiedenen Quellen, einschließlich Transaktionscodes (SY-TCODE), Änderungsbeleg-Status (Tabellen CDHDR/CDPOS) oder Geschäfts-Workflow-Protokollen (z. B. SWW_WI2OBJ). Beispiele Rechnung erstelltRechnung an Buchhaltung gebuchtKundenzahlung eingegangenRechnung storniert | |||
| Ereigniszeit EventTime | Der genaue Timestamp, der angibt, wann eine Aktivität oder ein Event aufgetreten ist. | ||
| Beschreibung Die Event Time liefert Datum und Uhrzeit für jede Aktivität und bildet das chronologische Rückgrat des Prozesses. Dieser Timestamp ist entscheidend für die Berechnung von Dauern, Zykluszeiten und Wartezeiten zwischen verschiedenen Schritten im Fakturierungsprozess. In der Analyse wird die Event Time verwendet, um Aktivitäten sequenziell zu ordnen, wichtige Key Performance Indicators wie Days Sales Outstanding und die Zykluszeit der Rechnungserstellung zu berechnen und zeitbasierte Engpässe zu identifizieren. Sie ermöglicht eine dynamische Sicht auf den Prozess, die zeigt, wie sich die Performance im Laufe der Zeit ändert und wie lange jede Phase des Fakturierungszyklus dauert. Bedeutung Es liefert die chronologische Reihenfolge der Ereignisse, die für die Berechnung aller zeitbasierten Metriken, wie Zykluszeiten und Dauern, unerlässlich ist. Datenquelle Extrahierter Wert aus verschiedenen Datums- und Zeitfeldern je nach Aktivität, wie Erstellungsdatum und -zeit (VBRK-ERDAT, VBRK-ERZET), Änderungs-Timestamps (CDHDR-UDATE, CDHDR-UTIME) oder Buchungsdatum (BKPF-BUDAT). Beispiele 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Benutzername UserName | Die Benutzer-ID des Mitarbeiters, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die SAP Benutzer-ID, die für ein bestimmtes Event verantwortlich ist, wie z.B. das Erstellen einer Rechnung, das Buchen eines Dokuments oder das Ausgleichen einer Zahlung. Es stellt eine Verknüpfung zwischen Prozessschritten und den Personen oder Teams her, die sie ausführen.\n\nDie Analyse nach Benutzernamen hilft, leistungsstarke Mitarbeiter, Schulungsbedarfe oder Ungleichgewichte in der Arbeitslastverteilung zu identifizieren. Sie ist auch entscheidend für die Compliance-Analyse, da sie zeigt, wer kritische Aktivitäten durchgeführt hat, und für das Verständnis von Variationen in der Prozessausführung durch verschiedene Benutzer. Bedeutung Es verknüpft Prozessaktivitäten mit spezifischen Benutzern und ermöglicht die Analyse von Arbeitslast, Leistung und Compliance auf Einzel- oder Teamebene. Datenquelle Für Erstellungsereignisse ist dies in VBRK-ERNAM zu finden. Für nachfolgende Änderungen findet es sich in Änderungshistorien-Tabellen wie CDHDR-USERNAME oder in Workflow-Protokollen. Beispiele CBURNSHSIMPSONLLEONARD | |||
| Endzeit EndTime | Der genaue Timestamp, der angibt, wann eine Aktivität oder ein Event abgeschlossen wurde. | ||
| Beschreibung Die Endzeit markiert den Abschluss einer Aktivität. Im Process Mining wird dies oft als die Startzeit der nachfolgenden Aktivität im Case interpretiert, oder es kann direkt bezogen werden, wenn das System sowohl Start- als auch End-Events protokolliert.\n\nDieses Attribut ist entscheidend für die Berechnung der Bearbeitungszeit einzelner Aktivitäten. Durch Subtraktion der Startzeit von der Endzeit kann die Dauer jedes Schritts gemessen werden, was für die Bottleneck-Analyse, wie z.B. die Identifizierung von Verzögerungen in der Rechnungsfreigabephase, von entscheidender Bedeutung ist. Bedeutung Es ermöglicht die Berechnung der genauen Dauer (Verarbeitungszeit) jeder Aktivität, was für die Engpassanalyse grundlegend ist. Datenquelle Dies ist ein abgeleitetes Attribut für Process Mining. Es wird typischerweise als die Startzeit des nächsten Events in der Case-Sequenz berechnet. In einigen Szenarien könnten spezifische Tabellen Abschlusszeiten protokollieren. Beispiele 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Kundenname CustomerName | Der Name des Customers, to whom the Invoice was issued. | ||
| Beschreibung Dieses Attribut identifiziert den rechtlichen Namen des fakturierten Kunden. Es stammt aus den zentralen Kundenstammdaten in SAP.\n\nDie Analyse des Prozesses nach Kunden ermöglicht die Identifizierung von Mustern, die für bestimmte Konten spezifisch sind. Zum Beispiel kann sie aufzeigen, welche Kunden konstant zu spät zahlen, welche die meisten Dispute verursachen oder für welche der Fakturierungsprozess am ineffizientesten ist. Dies ermöglicht ein gezieltes Kundenbeziehungsmanagement und maßgeschneiderte Inkassostrategien. Bedeutung Es ermöglicht eine kundenorientierte Analyse, die hilft, Zahlungsverhalten, Streitfallhäufigkeiten und Prozessineffizienzen für spezifische Konten zu identifizieren. Datenquelle Abgerufen aus der Kundenstammdatentabelle KNA1 (Feld: NAME1), verknüpft über die Zahler-ID im Rechnungsheader (VBRK-KUNRG). Beispiele Springfield Power PlantKwik-E-MartCyberdyne Systems | |||
| Rechnungsbetrag InvoiceAmount | Der Gesamtnetto-Wert der Rechnung. | ||
| Beschreibung Dieses Attribut repräsentiert den monetären Gesamtwert der fakturierten Waren oder Dienstleistungen, exklusive Steuern. Es ist ein grundlegender Finanzdatenpunkt für jeden Rechnungsfall.\n\nDer Rechnungsbetrag wird in einer Vielzahl von Analysen verwendet. Er ermöglicht die Segmentierung des Prozesses nach Wert, um beispielsweise zu sehen, ob hochvolumige Rechnungen anders verarbeitet werden oder mehr Verzögerungen aufweisen. Er ist auch die Basis für das Finanzreporting und die Berechnung des Gesamtwerts ausstehender Forderungen. Bedeutung Es quantifiziert den finanziellen Wert jeder Rechnung und ermöglicht so eine wertbasierte Analyse, die Priorisierung von Inkassomaßnahmen und die Bewertung finanzieller Auswirkungen. Datenquelle SAP Tabelle: VBRK, Feld: NETWR Beispiele 1500.0025000.50125.75 | |||
| Rechnungsdatum InvoiceDate | Das offizielle Datum, an dem die Rechnung an den Kunden ausgestellt wurde. | ||
| Beschreibung Das Rechnungsdatum, in SAP auch als Fakturierungsdatum bekannt, dient als Ausgangspunkt für viele Finanzberechnungen. Es ist das Datum, ab dem Zahlungsbedingungen, Fälligkeitstermine und das Alter der Forderung bestimmt werden.\n\nDieses Datum ist ein kritisches Case-Level-Attribut für die Finanzanalyse. Es ist die Basis für die Berechnung des Days Sales Outstanding (DSO) KPI und für die Erstellung von Berichten über ausstehende Rechnungen (Aging Reports), die wesentliche Instrumente für das Cashflow-Management und das Forderungsmanagement sind. Bedeutung Es ist das primäre Datum für Finanzberechnungen und dient als Ausgangspunkt für DSO, Zahlungsfälligkeiten und Rechnungsalterungsanalysen. Datenquelle SAP Tabelle: VBRK, Feld: FKDAT Beispiele 2023-03-202023-04-012023-05-18 | |||
| Region Region | Die geografische Region des Kunden. | ||
| Beschreibung Das Attribut „Region“ gibt das geografische Gebiet, z.B. einen Bundesstaat oder eine Provinz, an, das mit der Kundenadresse verknüpft ist. Diese Daten sind typischerweise Teil des Kundenstammsatzes.\n\nDieses Attribut ist entscheidend für das Dashboard „Regionale Fakturierungsleistung“. Es ermöglicht das Benchmarking wichtiger Kennzahlen wie Zykluszeiten, Fehlerraten und DSO über verschiedene Regionen hinweg. Dieser Vergleich kann regionale Unterschiede in der Prozessausführung, Compliance oder Effizienz aufzeigen und den Weg für gezielte Verbesserungen und die Standardisierung von Best Practices ebnen. Bedeutung Es ermöglicht den Vergleich der Fakturierungs-Performance über verschiedene geografische Gebiete hinweg, was hilft, regionale Unterschiede zu identifizieren und Prozesse zu standardisieren. Datenquelle Abgerufen aus der Kundenstammdatentabelle KNA1 (Feld: REGIO), verknüpft über die Zahler-ID im Rechnungsheader (VBRK-KUNRG). Beispiele CANYTXBA | |||
| Zahlungsfälligkeitsdatum PaymentDueDate | Das Date by which the Customer expected ist, to pay the Invoice. | ||
| Beschreibung Das Zahlungsfälligkeitsdatum wird basierend auf dem Rechnungsdatum und den vereinbarten Zahlungsbedingungen berechnet. Es stellt die Frist für den Zahlungseingang dar, ohne dass die Rechnung überfällig wird.\n\nDieses Attribut ist unerlässlich für die Überwachung der Effektivität des Forderungsmanagements und der Cashflow-Prognose. Es wird direkt zur Berechnung des KPI „Pünktliche Zahlungsrate“ und zur Segmentierung von Rechnungen in Aging Reports verwendet. Die Analyse von Abweichungen zwischen dem Fälligkeitsdatum und dem tatsächlichen Zahlungsdatum hilft, die Wirksamkeit verschiedener Zahlungsbedingungen zu bewerten. Bedeutung Es legt die Zahlungsfrist für den Kunden fest, was für die Berechnung der Pünktlichkeitsraten und die Verwaltung der Debitorenbuchhaltung entscheidend ist. Datenquelle Dieses Datum wird nicht direkt gespeichert, sondern wird basierend auf dem Rechnungsdatum (VBRK-FKDAT) und dem Zahlungsbedingungsschlüssel (VBRK-ZTERM) mithilfe der SAP-Standardfunktionen zur Datumsermittlung berechnet. Beispiele 2023-04-192023-05-012023-06-17 | |||
| `Verkaufsauftragsnummer` SalesOrderNumber | Der Identifikator des ursprünglichen Kundenauftrags, der zur Rechnung führte. | ||
| Beschreibung Die Kundenauftragsnummer verknüpft den Fakturabeleg mit den vorhergehenden Verkaufsaktivitäten. Ein einziger Kundenauftrag kann zu einer oder mehreren Rechnungen führen, und diese Verknüpfung bietet den vollständigen Dokumentenfluss.\n\nDieses Attribut ist entscheidend für eine echte End-to-End Order-to-Cash Analyse. Es ermöglicht die Erweiterung der Prozessansicht stromaufwärts, indem Fakturierungsprobleme mit ihren potenziellen Ursachen in den Phasen der Auftragserstellung oder -erfüllung verbunden werden. Zum Beispiel hilft es, die gesamte Zykluszeit der Rechnungserstellung zu berechnen, beginnend mit der Erfüllung des Auftrags. Bedeutung Es verknüpft die Rechnung mit dem ursprünglichen Kundenauftrag und ermöglicht so eine breitere, End-to-End-Sicht auf den Order-to-Cash-Prozess über die reine Fakturierung hinaus. Datenquelle SAP Tabelle: VBRP (Fakturabeleg Positionsdaten), Feld: AUBEL Beispiele 100001231000045610000789 | |||
| Bearbeitungszeit ProcessingTime | Die Dauer einer Aktivität, berechnet von ihrer Start- bis zur Endzeit. | ||
| Beschreibung Die Bearbeitungszeit misst die Zeit, die aktiv an einer Aufgabe gearbeitet wird, im Gegensatz zur Wartezeit zwischen Aufgaben. Sie wird als Differenz zwischen der Endzeit und der Startzeit einer Aktivität berechnet.\n\nDiese berechnete Metrik ist ein Eckpfeiler der Leistungsanalyse. Sie wird in Dashboards wie der „Invoice Approval Bottleneck Analysis“ verwendet, um zu quantifizieren, wie lange bestimmte Schritte dauern. Hohe Bearbeitungszeiten für bestimmte Aktivitäten können auf Ineffizienzen, Komplexität oder die Notwendigkeit einer Automatisierung hindeuten. Bedeutung Es misst die aktive Dauer von Prozessschritten und hilft, ineffiziente Aktivitäten zu identifizieren, die hervorragende Kandidaten für Optimierung oder Automatisierung sind. Datenquelle Kalkulierte Metrik, abgeleitet durch Subtraktion der 'StartTime' von der 'EndTime' während des Datentransformationsprozesses. Beispiele PT30MPT5MPT1H15M | |||
| Buchungskreis CompanyCode | Die Organisationseinheit, für die die Finanztransaktion erfasst wird. | ||
| Beschreibung Der Buchungskreis ist eine grundlegende Organisationseinheit in SAP Financials, die ein rechtlich unabhängiges Unternehmen repräsentiert, für das Finanzberichte erstellt werden. Jeder Fakturabeleg ist einem spezifischen Buchungskreis zugeordnet.\n\nDie Analyse nach Buchungskreis ist in Mehrmandantenorganisationen unerlässlich, um die Prozessleistung, Finanzkennzahlen wie DSO und Compliance über verschiedene juristische Einheiten hinweg zu vergleichen. Er bietet einen übergeordneten organisatorischen Filter für alle Prozess-Dashboards. Bedeutung Es ermöglicht die Segmentierung der Prozessanalyse nach juristischen Einheiten, wodurch Performance-Vergleiche und finanzielle Konsolidierungen innerhalb der Organisation ermöglicht werden. Datenquelle SAP Tabelle: VBRK, Feld: BUKRS Beispiele 10002000US01 | |||
| Fakturabelegart BillingDocumentType | Ein Code, der den Fakturabeleg klassifiziert, z. B. eine Rechnung, Gutschrift oder Stornierung. | ||
| Beschreibung Der Fakturabelegtyp ist ein Schlüsselfeld, das Transaktionen innerhalb des Fakturierungsprozesses kategorisiert. Er steuert, wie das Dokument verarbeitet wird, einschließlich seines Nummernkreises und der Regeln für die Buchung in der Finanzbuchhaltung.\n\nDieses Attribut ermöglicht die Filterung des Prozesses zur Analyse spezifischer Transaktionstypen. Zum Beispiel könnte man eine separate Prozessansicht nur für Gutschriften erstellen, um die Gründe und den Prozessablauf für Finanzkorrekturen zu verstehen, oder Standardrechnungen separat von Stornierungen analysieren, um ein klareres Bild des primären Fakturierungsprozesses zu erhalten. Bedeutung Es klassifiziert Transaktionen und ermöglicht eine fokussierte Analyse spezifischer Belegflüsse wie Standardrechnungen, Gutschriften oder Stornierungen. Datenquelle SAP Tabelle: VBRK, Feld: FKART Beispiele F2G2S1L2 | |||
| Gutschriftsgrund CreditMemoReason | Der Grundcode, der angibt, warum eine Gutschrift ausgestellt wurde. | ||
| Beschreibung Wenn eine Rechnung falsch ist und gutgeschrieben werden muss, wird dem Gutschriftsbeleg typischerweise ein Grund zugewiesen. Dies bietet eine strukturierte Möglichkeit, die Quellen von Fakturierungsfehlern zu kategorisieren.\n\nDieses Attribut unterstützt direkt den KPI „Fakturierungsfehlerquote“. Durch die Aggregation und Analyse der Gründe für Gutschriften kann ein Unternehmen die häufigsten Fehlerarten identifizieren, wie z.B. Preisfehler oder Produktrücksendungen. Diese Analyse treibt Prozessverbesserungen voran, die darauf abzielen, den Bedarf an Finanzkorrekturen und Nacharbeit zu reduzieren. Bedeutung Es kategorisiert die Gründe für die Ausstellung von Gutschriften, was hilft, die häufigsten Quellen von Fakturierungsfehlern zu identifizieren und Qualitätsverbesserungen voranzutreiben. Datenquelle SAP Tabelle: VBRK, Feld: AUGRU (Auftragsgrund). Dieses Feld wird bei Gutschrifts-/Lastschriftsanforderungen verwendet, die dann fakturiert werden. Beispiele 001 - Preisdifferenz002 - Schlechte Qualität005 - Kundenretoure | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten für dieses Event zuletzt extrahiert oder aktualisiert wurden. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit des letzten Datenabzugs aus dem Quellsystem. Es ist ein Metadatenfeld, das entscheidend ist, um die Aktualität der analysierten Daten zu verstehen.\n\nDiese Informationen werden verwendet, um die Aktualität der Analyse zu validieren und Datenaktualisierungspläne zu verwalten. Es stellt sicher, dass Stakeholder sich der Aktualität der Daten bewusst sind, wenn sie Entscheidungen basierend auf den Process Mining Dashboards und Erkenntnissen treffen. Bedeutung Es gibt Aufschluss über die Aktualität der Daten, was für das Vertrauen in die Analyse und das Verständnis ihrer Relevanz für den aktuellen Betriebszustand entscheidend ist. Datenquelle Dieser Timestamp wird während des Datenextraktions- und Ladeprozesses (ETL) generiert und auf jeden Datensatz gestempelt. Beispiele 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Quellsystem SourceSystem | Identifiziert das spezifische Quellsystem, aus dem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut spezifiziert den Ursprung der Daten, was besonders nützlich in Umgebungen mit mehreren SAP-Instanzen oder anderen integrierten Systemen ist. Es umfasst typischerweise die System-ID und die Mandantennummer.\n\nIn der Analyse hilft es, Prozesse und Leistungen über verschiedene Systeme oder Organisationseinheiten hinweg zu differenzieren. Es gewährleistet die Datenherkunft und liefert Kontext, insbesondere wenn Daten aus mehreren Quellen für eine umfassende Prozessansicht kombiniert werden. Bedeutung Es liefert entscheidenden Kontext über den Ursprung der Daten, gewährleistet Klarheit in Multi-System-Umgebungen und unterstützt die Data Governance. Datenquelle Dies ist typischerweise ein statischer Wert, der während der Datenextraktion definiert wird und oft die System-ID (SY-SYSID) und den Mandanten (SY-MANDT) kombiniert. Beispiele S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
| Streitfallgrund CustomerDisputeReason | Der Grund, den ein Kunde für die Anfechtung einer Rechnung angegeben hat. | ||
| Beschreibung Wenn ein Kunde eine Rechnung anficht, wird oft der Grund für den Dispute erfasst. Dies könnte auf Preisfehler, falsche Mengen oder beschädigte Waren zurückzuführen sein. Diese Informationen können im SAP Dispute Management Modul oder als Textnotizen gespeichert werden.\n\nDie Analyse der Dispute-Gründe ist grundlegend für den KPI „Fakturierungsfehlerquote“ und die damit verbundene Fehleranalyse. Sie hilft, die Ursachen von Fakturierungsungenauigkeiten zu identifizieren, wodurch das Unternehmen systemische Probleme in vorgelagerten Prozessen angehen, die Rechnungsqualität verbessern und die Kundenzufriedenheit steigern kann. Bedeutung Es erklärt, warum Rechnungen beanstandet werden, und liefert direkten Einblick in die Ursachen von Fakturierungsfehlern und Kundenunzufriedenheit. Datenquelle Wenn SAP Dispute Management verwendet wird, sind diese Informationen in Tabellen wie UDM_DISPUTE zu finden. Andernfalls können sie aus Grundcodes auf verwandten Belegen oder Textfeldern abgeleitet werden. Beispiele Falscher PreisMengenabweichungBeschädigte Ware erhalten | |||
| Währung Currency | Der Währungscode für den Rechnungsbetrag. | ||
| Beschreibung Dieses Attribut gibt die Währung an, in der die Rechnungsbeträge ausgedrückt sind, z.B. USD, EUR oder JPY. Es liefert den notwendigen Kontext für alle monetären Werte.\n\nIn einer globalen Organisation ist die Währung für die korrekte Finanzanalyse und -berichterstattung unerlässlich. Sie ermöglicht die ordnungsgemäße Aggregation von Finanzdaten durch Umrechnung aller Beträge in eine gemeinsame Berichtswährung und ermöglicht den Vergleich der Fakturierungsleistung in verschiedenen Regionen mit unterschiedlichen lokalen Währungen. Bedeutung Es bietet den wesentlichen Kontext für alle monetären Werte und gewährleistet eine genaue Finanzanalyse und -berichterstattung, insbesondere bei multinationalen Operationen. Datenquelle SAP Tabelle: VBRK, Feld: WAERK Beispiele USDEURGBP | |||
| Wurde pünktlich bezahlt IsPaidOnTime | Ein boolesches Flag, das anzeigt, ob die Rechnung am oder vor ihrem Fälligkeitsdatum bezahlt wurde. | ||
| Beschreibung Dies ist ein berechnetes Attribut, das das tatsächliche Zahlungsdatum mit dem geplanten Zahlungsfälligkeitsdatum vergleicht. Es ergibt „true“, wenn die Zahlung pünktlich erfolgte, und „false“, wenn sie verspätet war.\n\nDieses Flag vereinfacht die Berechnung und Visualisierung des KPI „Pünktliche Zahlungsrate“. Es ermöglicht eine einfache Filterung und Segmentierung, um die Merkmale von Rechnungen zu analysieren, die verspätet gegenüber denen, die pünktlich bezahlt werden. Dies kann helfen, Muster aufzudecken, die mit spezifischen Kunden, Regionen oder Zahlungsbedingungen zusammenhängen und zu verspäteten Zahlungen führen. Bedeutung Es vereinfacht die Performance-Messung, indem jede Rechnung klar als 'pünktlich' oder 'verspätet' gekennzeichnet wird, was den KPI der Pünktlichkeitsrate direkt unterstützt. Datenquelle Dies ist ein berechnetes Feld. Die Logik vergleicht den Timestamp der Aktivität „Kundenzahlung erhalten“ mit dem Wert im Attribut „PaymentDueDate“. Beispiele truefalsch | |||
| Zahlungsbedingungen PaymentTerms | Der Code, der die Zahlungsbedingungen definiert, wie z.B. die zulässige Zahlungsfrist. | ||
| Beschreibung Zahlungsbedingungen sind vordefinierte Konditionen, die mit einem Kunden vereinbart werden und festlegen, wann eine Rechnungszahlung fällig ist. Beispiele hierfür sind „Netto 30“ (Zahlung fällig in 30 Tagen) oder „2/10 Netto 30“ (2 % Rabatt bei Zahlung innerhalb von 10 Tagen, ansonsten fällig in 30 Tagen).\n\nDie Analyse nach Zahlungsbedingungen hilft, deren Wirksamkeit zu bewerten. Durch die Korrelation verschiedener Zahlungsbedingungen mit der tatsächlich benötigten Zeit bis zum Zahlungseingang kann ein Unternehmen ermitteln, welche Bedingungen am erfolgreichsten eine prompte Zahlung fördern, und seine Bedingungen optimieren, um den Cashflow zu verbessern. Bedeutung Es definiert den vereinbarten Zahlungsplan und ermöglicht die Analyse, welche Bedingungen am effektivsten sind, um eine pünktliche Zahlung von Kunden zu gewährleisten. Datenquelle SAP Tabelle: VBRK, Feld: ZTERM Beispiele Z030Z060ZB60 | |||
| Zahlungsstatus PaymentStatus | Der aktuelle Status der Rechnungszahlung, z.B. Offen, Bezahlt oder Überfällig. | ||
| Beschreibung Der Zahlungsstatus bietet eine Momentaufnahme des Stands einer Rechnung im Inkassolebenszyklus. Dies ist kein einzelnes Feld in SAP, sondern wird durch Überprüfung des Ausgleichsstatus des entsprechenden Buchhaltungsbelegs abgeleitet. Dieses Attribut ist unerlässlich für das Dashboard zur Alterung der offenen Rechnungen. Es ermöglicht die Segmentierung aller offenen Rechnungen nach ihrem Status und Alter, wodurch das Inkassoteam seine Anstrengungen effektiv priorisieren kann. Die Verfolgung der Übergänge zwischen den Status ist auch eine Möglichkeit, den Inkassoprozess selbst zu überwachen. Bedeutung Es bietet einen klaren, auf einen Blick erkennbaren Überblick über den Inkasso-Status einer Rechnung, was für das Management von Forderungen und die Priorisierung von Inkassobemühungen entscheidend ist. Datenquelle Abgeleitet durch Überprüfung des Ausgleichsstatus des Buchhaltungsbelegs (VBRK-BELNR) in Finanztabellen wie BSID (offene Posten) und BSAD (ausgeglichene Posten). Beispiele OffenBezahltÜberfälligTeilweise bezahlt | |||
Order to Cash - Fakturierungs- und Rechnungsstellungsaktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Kundenzahlung eingegangen | Diese Aktivität markiert die Buchung eines eingehenden Kundenzahlung in das Finanzsystem. Die Zahlung ist in diesem Stadium möglicherweise noch keiner spezifischen Rechnung zugeordnet, aber die Gelder wurden erfasst. | ||
| Bedeutung Ein entscheidender Meilenstein zur Berechnung der durchschnittlichen Forderungslaufzeit (DSO). Er signalisiert den Geldeingang, auch wenn die Abstimmung noch aussteht. Datenquelle Erfasst aus dem Buchungsdatum (BKPF-BUDAT) des Kundenbelegdokuments (typischerweise Belegart 'DZ' in Tabelle BKPF). Erfassen Das Ereignis basiert auf der Erstellung des Zahlungsbelegs in BKPF/BSEG. Ereignistyp explicit | |||
| Rechnung abgeschlossen | Diese Aktivität kennzeichnet den Endzustand einer erfolgreich bezahlten Rechnung. Funktional ist sie identisch mit „Cash Applied/Reconciled“ und zeigt an, dass der Prozess für diese Rechnung abgeschlossen ist. | ||
| Bedeutung Dient als primäres End-Event des „Happy Path“ für den Prozess. Die Messung der Gesamtzykluszeit bis zu diesem Punkt bietet eine vollständige Übersicht über den End-to-End-Fakturierungs- und Rechnungsstellungsprozess. Datenquelle Abgeleitet vom Status des Kundenpostens im Buchhaltungsbeleg. Ein Posten ist geschlossen oder 'ausgeglichen', wenn die Felder Ausgleichsdatum (BSEG-AUGDT) und Ausgleichsbeleg (BSEG-AUGBL) gefüllt sind. Erfassen Abgeleitet aus der Befüllung des Ausgleichsdatums (AUGDT) in der BSEG/ACDOCA-Tabelle für den Rechnungszeilenposten. Ereignistyp inferred | |||
| Rechnung an Buchhaltung gebucht | Stellt die erfolgreiche Buchung des Fakturabelegs in das Finanzbuchhaltungsmodul dar. Dies ist ein kritischer Meilenstein, bei dem die Rechnung zu einem offiziellen Debitoreneintrag wird und Buchungen im Hauptbuch erzeugt werden. | ||
| Bedeutung Diese Aktivität bestätigt, dass die Rechnung ein rechtlich bindendes Finanzdokument ist. Die Zeitspanne zwischen Erstellung und Buchung ist ein wichtiger Leistungsindikator, der die interne Bearbeitungseffizienz hervorhebt. Datenquelle Dieses Event wird erfasst, wenn der entsprechende Buchhaltungsbeleg erstellt wird. Der Fakturabeleg (VBRK-VBELN) ist über VBRK-BELNR mit dem Buchhaltungsbeleg (BKPF-BELNR) verknüpft, und das Buchungsdatum ist BKPF-BUDAT. Erfassen Erfasst aus dem Buchungsdatum (BUDAT) des Buchhaltungsbelegs in Tabelle BKPF, der mit dem Fakturabeleg verknüpft ist. Ereignistyp explicit | |||
| Rechnung erstellt | Diese Aktivität markiert die Erstellung des Fakturabelegs im System. Es handelt sich um ein explizites Event, das erfasst wird, wenn ein Benutzer eine Transaktion wie VF01 ausführt oder wenn ein Hintergrundjob die Rechnung erstellt, was zu einem neuen Eintrag in der Fakturabelegkopf-Tabelle führt. | ||
| Bedeutung Dies ist das primäre Start-Event für den Fakturierungsprozess. Die Analyse der Zeit von der Auftragserfüllung bis zu dieser Aktivität ist entscheidend für die Messung der Zykluszeit der Rechnungserstellung und die Identifizierung anfänglicher Prozessverzögerungen. Datenquelle Bei der Erstellung in der SAP S/4HANA Tabelle VBRK (Fakturabeleg: Kopfdaten) erfasst. Das Erstellungsdatum (VBRK-ERDAT) und die Uhrzeit (VBRK-ERZET) dienen als Timestamp. Erfassen Das Ereignis wird aus dem Erstellungs-Timestamp des Fakturabelegdatensatzes in Tabelle VBRK erfasst. Ereignistyp explicit | |||
| Zahlung zugeordnet/abgestimmt | Stellt den Moment dar, in dem der eingehende Kundenzahlung abgeglichen und zur Ausbuchung des offenen Rechnungsbetrags aus dem Nebenbuch der Debitorenbuchhaltung verwendet wird. Diese Aktivität schließt die Transaktion aus finanzieller Sicht ab. | ||
| Bedeutung Misst die Effizienz des Zahlungszuordnungsprozesses. Verzögerungen hier können den tatsächlichen Zustand der Kundenkonten falsch darstellen und unnötigen Aufwand für Inkassoteams verursachen. Datenquelle Dieses Event wird durch das Ausgleichsdatum (BSEG-AUGDT) auf der Buchungsbelegposition der Originalrechnung erfasst. Dieses Datum wird gefüllt, wenn ein Ausgleichsbeleg den Posten ausgleicht. Erfassen Erfasst aus dem Feld Ausgleichsdatum (AUGDT) in der Tabelle BSEG/ACDOCA für den Rechnungszeilenposten. Ereignistyp explicit | |||
| `Rechnung an Kunden gesendet` | Diese Aktivität markiert den Zeitpunkt, zu dem die Rechnung an den Kunden übermittelt wurde, z.B. per Druck, E-Mail oder EDI. Der Erfassungsmechanismus hängt von der Konfiguration des Output-Managements in SAP ab. | ||
| Bedeutung Der offizielle Start der Zahlungsfrist aus Sicht des Kunden. Verzögerungen beim Rechnungsversand wirken sich direkt auf die Days Sales Outstanding (DSO) und den Cashflow aus. Datenquelle Kann explizit in den Ausgabesteuerungstabellen (wie NAST für ältere Methoden oder deren S/4HANA-Äquivalent) protokolliert werden. Wenn nicht explizit protokolliert, wird oft angenommen, dass es gleichzeitig mit 'Rechnung an Buchhaltung gebucht' auftritt. Erfassen Prüfen Sie die Verarbeitungsprotokolle in den Ausgabemanagement-Tabellen auf einen Timestamp, der dem Rechnungs-Ausgabetyp zugeordnet ist. Ereignistyp explicit | |||
| Gutschrift erstellt | Diese Aktivität stellt die Erstellung einer Gutschrift dar, die an einen Kunden ausgestellt wird, um eine Überberechnung zu korrigieren oder eine Gutschrift für zurückgesendete Waren zu gewähren. Sie ist oft mit einer Originalrechnung verknüpft. | ||
| Bedeutung Hebt Probleme hervor, die zu finanziellen Anpassungen nach der Fakturierung führen. Die Analyse von Gutschriften kann Preisfehler, Produktprobleme oder andere Ursachen für Umsatzverluste aufdecken. Datenquelle Explizit als neuer Fakturabeleg (in VBRK) mit einer spezifischen Belegart für Gutschriften (z. B. 'G2') erstellt. Er referenziert oft den ursprünglichen Kundenauftrag oder die Rechnung. Erfassen Erfasst aus der Erstellung eines Fakturabelegs in VBRK mit einer Gutschriftsfakturabelegart. Ereignistyp explicit | |||
| Kundenreklamation eröffnet | Diese Aktivität tritt auf, wenn ein Kunde einen Einspruch gegen eine Rechnung erhebt, der dann formell im System protokolliert wird. Dies erfordert die Nutzung des SAP Dispute Management Moduls. | ||
| Bedeutung Zeigt Probleme mit der Fakturierungsgenauigkeit, Produktqualität oder Servicebereitstellung auf, die zu Zahlungsverzögerungen führen. Die Analyse von Streitgründen kann helfen, Ursachen zu beheben und die Kundenzufriedenheit zu verbessern. Datenquelle Protokolliert bei der Erstellung eines Streitfalls in den Dispute-Management-Tabellen (z. B. UDM_CASE), der mit dem Buchhaltungsbelegposten verknüpft ist. Erfassen Erfasst aus dem Erstellungs-Timestamp des mit der Rechnung verknüpften Dispute Case-Datensatzes. Ereignistyp explicit | |||
| Rechnung storniert | Tritt auf, wenn eine zuvor erstellte Rechnung storniert wird, was typischerweise die Erstellung eines entsprechenden Stornobelegs beinhaltet. Dies kehrt die ursprüngliche Rechnung und ihre buchhalterische Auswirkung effektiv um. | ||
| Bedeutung Zeigt Nacharbeit, Korrekturen oder Fakturierungsfehler an. Eine hohe Häufigkeit von Stornierungen weist auf erhebliche vorgelagerte Probleme bei der Kundenauftragserfassung oder der Fakturierungskonfiguration hin. Datenquelle Erfasst, wenn ein Stornierungs-Fakturabeleg erstellt wird (z. B. Belegart 'S1'). Dieses neue Dokument in VBRK referenziert die ursprüngliche Rechnungsnummer im Feld VBRK-SFAKN. Erfassen Das Ereignis wird aus dem Erstellungsdatum des Stornierungsbelegs in VBRK erfasst, der die Originalrechnung referenziert. Ereignistyp explicit | |||
| Rechnungsbuchung gesperrt | Dieses Event tritt auf, wenn eine Rechnung erstellt, aber aufgrund verschiedener Gründe, wie Kreditprüfungen oder Dateninkonsistenzen, automatisch von der Buchung in der Finanzbuchhaltung gesperrt wird. Dieser Status wird aus dem Buchungsstatusfeld im Fakturabeleg abgeleitet. | ||
| Bedeutung Identifiziert Engpässe, an denen Rechnungen erstellt, aber nicht sofort an die Finanzabteilung freigegeben werden, was den gesamten Cash-Collection-Zyklus verzögert. Dies ist ein Schlüsselindikator für Datenqualitätsprobleme oder Kreditmanagementprobleme. Datenquelle Abgeleitet aus dem Buchungsstatusfeld in der Fakturabelegkopf-Tabelle (VBRK-RFBSK). Ein Status wie 'A' (Fakturabeleg für Weiterleitung an FI gesperrt) weist auf eine Sperre hin. Erfassen Abgeleitet durch Überprüfung des Wertes des Buchungsstatusfeldes (VBRK-RFBSK) unmittelbar nach der Rechnungserstellung. Ereignistyp inferred | |||
| Rechnungsnacharbeit identifiziert | Ein kalkuliertes Ereignis, das eine Nacharbeits-Schleife identifiziert, bei der eine Rechnung storniert und dann eine neue für denselben Kundenauftrag erstellt wurde. Es ist keine einzelne Transaktion, sondern ein Ereignismuster. | ||
| Bedeutung Unterstützt direkt den KPI der Rechnungsnacharbeitsrate, indem Korrekturinstanzen quantifiziert werden. Dies hilft, Ineffizienzen zu identifizieren und die Kosten mangelhafter Qualität im Fakturierungsprozess zu messen. Datenquelle Dieses Muster wird berechnet, indem ein Event „Rechnung storniert“ gefolgt von einem neuen Event „Rechnung erstellt“ identifiziert wird, die beide auf dasselbe Quelldokument, wie z.B. eine Kundenauftragsnummer, zurückzuführen sind. Erfassen Abgeleitet durch Erkennung einer Sequenz von 'Rechnung storniert' und 'Rechnung erstellt' für denselben Kundenauftrag. Ereignistyp calculated | |||
| Zahlungserinnerung ausgestellt | Stellt das Senden einer Zahlungserinnerung oder Mahnung an einen Kunden für eine überfällige Rechnung dar. Dies ist ein explizites Event, das durch den automatisierten Mahnprozess generiert wird. | ||
| Bedeutung Ermöglicht die Analyse der Wirksamkeit des Mahnprozesses. Es hilft festzustellen, ob Mahnungen Zahlungen beschleunigen und welche Mahnstufen am effektivsten sind. Datenquelle Erfasst in den Mahnhistorietabellen (MAHNV, MHND), wenn der Mahnlauf (Transaktion F150) für den offenen Posten der Rechnung ausgeführt wird. Erfassen Erfasst vom Ausführungsdatum der Mahnung, das in den Mahnhistorientabellen aufgezeichnet ist. Ereignistyp explicit | |||
| Zahlungsfälligkeitsdatum erreicht | Ein kalkuliertes Ereignis, das das offizielle Fälligkeitsdatum der Rechnungszahlung gemäß den vereinbarten Zahlungsbedingungen darstellt. Es ist kein transaktionelles Ereignis, sondern wird aus Rechnungsdaten abgeleitet. | ||
| Bedeutung Dies bietet eine kritische Grundlage zur Messung der pünktlichen Zahlungsleistung und zur Analyse des Kunden-Zahlungsverhaltens. Es hilft, zwischen fristgerechten und überfälligen Zahlungen zu unterscheiden. Datenquelle Berechnet auf Basis des Basisdatums für die Zahlung (BSEG-ZFBDT) und der Zahlungsbedingungen, die im Kundenposten des Buchhaltungsbelegs gespeichert sind. Erfassen Abgeleitet durch Addition der Zahlungszieltage zum Basiszahlungsdatum, das im Buchhaltungsbelegposten (BSEG) gefunden wird. Ereignistyp calculated | |||
Extraktionsleitfäden
Schritte
- Voraussetzungen: Stellen Sie sicher, dass Sie über ein Benutzerkonto in SAP S/4HANA mit den notwendigen Berechtigungen verfügen, um Core Data Services (CDS)-Views abzufragen. Speziell benötigen Sie Lesezugriff auf Views wie I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase und I_DunningHistory.
- Datenextraktions-Tool aufrufen: Melden Sie sich in Ihrem SAP S/4HANA-System an. Sie können verschiedene Tools verwenden, um SQL-Abfragen gegen CDS-Views auszuführen, wie z. B. SAP HANA Studio, DBeaver (verbunden über den SAP HANA Client) oder das SAP Analysis for Microsoft Excel-Plugin. Für diesen Leitfaden gehen wir von einem Standard-SQL-Client aus.
- Systemparameter identifizieren: Bevor Sie die Abfrage ausführen, identifizieren Sie die spezifischen Buchungskreise und den relevanten Datumsbereich für Ihre Analyse. Es wird empfohlen, mit einem begrenzten Umfang zu beginnen, z. B. den Daten der letzten 3 bis 6 Monate, um überschaubare Abfrageausführungszeiten zu gewährleisten.
- SQL-Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt 'query' dieses Dokuments in Ihren ausgewählten SQL-Client.
- Platzhalter anpassen: Ändern Sie die Platzhalterwerte in der Abfrage. Ersetzen Sie
'JJJJ-MM-TT'durch Ihre gewünschten Start- und Enddaten. Ersetzen Sie'XXXX'durch Ihre Ziel-Buchungskreise. Möglicherweise müssen Sie auch den Platzhalter für Gutschriftsbelegarten, z. B.'G2', basierend auf Ihrer Systemkonfiguration anpassen. - Abfrage ausführen: Führen Sie die geänderte SQL-Abfrage gegen die SAP S/4HANA-Datenbank aus. Die Ausführungszeit variiert je nach Datenvolumen innerhalb Ihres ausgewählten Datumsbereichs.
- Ergebnisse überprüfen: Sobald die Abfrage abgeschlossen ist, überprüfen Sie die Ausgabe. Das Ergebnis sollte eine flache Tabelle sein, wobei jede Zeile eine einzelne Aktivität im Fakturierungsprozess darstellt. Dies ist Ihr Event Log.
- Datentransformation (falls erforderlich): Die Abfrage ist so konzipiert, dass sie ein sauberes Event-Log-Format erzeugt. Überprüfen Sie jedoch das Timestamp-Format, um sicherzustellen, dass es mit Ihrem Process-Mining-Tool kompatibel ist. Die Abfrage verwendet
ABAP_SYSTEM_UTCL_TO_TIMESTAMP, um in einen Standard-UTC-Timestamp zu konvertieren, der weitgehend kompatibel sein sollte. - Event Log exportieren: Exportieren Sie das gesamte Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Stellen Sie sicher, dass die Datei UTF-8-kodiert ist, um Zeichenprobleme zu vermeiden.
- In ProcessMind hochladen: Laden Sie die generierte CSV-Datei auf die ProcessMind-Plattform hoch und mappen Sie die Spalten aus der Datei, wie Rechnungsnummer, Aktivitätsname und Event-Zeit, auf die entsprechenden Felder im Tool.
Konfiguration
- Datumsbereich: Legen Sie die Start- und Enddaten in der
WHERE-Klausel der initialen Common Table Expression (CTE) fest. Ein Zeitraum von 3 bis 6 Monaten wird für eine erste Analyse empfohlen, um Datenvolumen und Performance auszugleichen. Der Filter bezieht sich aufBillingDocumentDate. - Buchungskreis: Filtern Sie nach einem oder mehreren
CompanyCode-Werten, um die Extraktion auf relevante juristische Einheiten zu beschränken. Dies ist ein entscheidender Filter zur Verwaltung des Datenumfangs. - Belegarten: Die Abfrage enthält Logik zur Identifizierung von Gutschriften basierend auf der
BillingDocumentType. Sie müssen den Platzhalter, z. B.('G2', 'CR'), mit den spezifischen Belegarten konfigurieren, die in Ihrer Organisation für Gutschriften verwendet werden. - Voraussetzungen: Der Zugriff auf die zugrunde liegenden CDS-Views ist zwingend erforderlich. Dies erfordert spezifische Rollen und Berechtigungen, die von Ihrem SAP-Sicherheitsteam zugewiesen werden. Darüber hinaus müssen für Aktivitäten wie 'Kundenreklamation eröffnet' oder 'Zahlungserinnerung gesendet' die jeweiligen SAP-Module, SAP Dispute Management und SAP Financials Dunning, in Ihrem System aktiv genutzt werden.
- Performance: Die Abfrage verwendet mehrere Joins und Unions. Für sehr große Datensätze, beispielsweise Daten mehrerer Jahre, sollten Sie die Ausführung außerhalb der Spitzenzeiten in Betracht ziehen oder restriktivere Filter anwenden, um die initiale Datenabfrage zu begrenzen.
a Beispielabfrage sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; Schritte
- Voraussetzungen: Stellen Sie sicher, dass Sie über ein Benutzerkonto in SAP S/4HANA mit den notwendigen Berechtigungen verfügen, um Core Data Services (CDS)-Views abzufragen. Speziell benötigen Sie Lesezugriff auf Views wie I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase und I_DunningHistory.
- Datenextraktions-Tool aufrufen: Melden Sie sich in Ihrem SAP S/4HANA-System an. Sie können verschiedene Tools verwenden, um SQL-Abfragen gegen CDS-Views auszuführen, wie z. B. SAP HANA Studio, DBeaver (verbunden über den SAP HANA Client) oder das SAP Analysis for Microsoft Excel-Plugin. Für diesen Leitfaden gehen wir von einem Standard-SQL-Client aus.
- Systemparameter identifizieren: Bevor Sie die Abfrage ausführen, identifizieren Sie die spezifischen Buchungskreise und den relevanten Datumsbereich für Ihre Analyse. Es wird empfohlen, mit einem begrenzten Umfang zu beginnen, z. B. den Daten der letzten 3 bis 6 Monate, um überschaubare Abfrageausführungszeiten zu gewährleisten.
- SQL-Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt 'query' dieses Dokuments in Ihren ausgewählten SQL-Client.
- Platzhalter anpassen: Ändern Sie die Platzhalterwerte in der Abfrage. Ersetzen Sie
'JJJJ-MM-TT'durch Ihre gewünschten Start- und Enddaten. Ersetzen Sie'XXXX'durch Ihre Ziel-Buchungskreise. Möglicherweise müssen Sie auch den Platzhalter für Gutschriftsbelegarten, z. B.'G2', basierend auf Ihrer Systemkonfiguration anpassen. - Abfrage ausführen: Führen Sie die geänderte SQL-Abfrage gegen die SAP S/4HANA-Datenbank aus. Die Ausführungszeit variiert je nach Datenvolumen innerhalb Ihres ausgewählten Datumsbereichs.
- Ergebnisse überprüfen: Sobald die Abfrage abgeschlossen ist, überprüfen Sie die Ausgabe. Das Ergebnis sollte eine flache Tabelle sein, wobei jede Zeile eine einzelne Aktivität im Fakturierungsprozess darstellt. Dies ist Ihr Event Log.
- Datentransformation (falls erforderlich): Die Abfrage ist so konzipiert, dass sie ein sauberes Event-Log-Format erzeugt. Überprüfen Sie jedoch das Timestamp-Format, um sicherzustellen, dass es mit Ihrem Process-Mining-Tool kompatibel ist. Die Abfrage verwendet
ABAP_SYSTEM_UTCL_TO_TIMESTAMP, um in einen Standard-UTC-Timestamp zu konvertieren, der weitgehend kompatibel sein sollte. - Event Log exportieren: Exportieren Sie das gesamte Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Stellen Sie sicher, dass die Datei UTF-8-kodiert ist, um Zeichenprobleme zu vermeiden.
- In ProcessMind hochladen: Laden Sie die generierte CSV-Datei auf die ProcessMind-Plattform hoch und mappen Sie die Spalten aus der Datei, wie Rechnungsnummer, Aktivitätsname und Event-Zeit, auf die entsprechenden Felder im Tool.
Konfiguration
- Datumsbereich: Legen Sie die Start- und Enddaten in der
WHERE-Klausel der initialen Common Table Expression (CTE) fest. Ein Zeitraum von 3 bis 6 Monaten wird für eine erste Analyse empfohlen, um Datenvolumen und Performance auszugleichen. Der Filter bezieht sich aufBillingDocumentDate. - Buchungskreis: Filtern Sie nach einem oder mehreren
CompanyCode-Werten, um die Extraktion auf relevante juristische Einheiten zu beschränken. Dies ist ein entscheidender Filter zur Verwaltung des Datenumfangs. - Belegarten: Die Abfrage enthält Logik zur Identifizierung von Gutschriften basierend auf der
BillingDocumentType. Sie müssen den Platzhalter, z. B.('G2', 'CR'), mit den spezifischen Belegarten konfigurieren, die in Ihrer Organisation für Gutschriften verwendet werden. - Voraussetzungen: Der Zugriff auf die zugrunde liegenden CDS-Views ist zwingend erforderlich. Dies erfordert spezifische Rollen und Berechtigungen, die von Ihrem SAP-Sicherheitsteam zugewiesen werden. Darüber hinaus müssen für Aktivitäten wie 'Kundenreklamation eröffnet' oder 'Zahlungserinnerung gesendet' die jeweiligen SAP-Module, SAP Dispute Management und SAP Financials Dunning, in Ihrem System aktiv genutzt werden.
- Performance: Die Abfrage verwendet mehrere Joins und Unions. Für sehr große Datensätze, beispielsweise Daten mehrerer Jahre, sollten Sie die Ausführung außerhalb der Spitzenzeiten in Betracht ziehen oder restriktivere Filter anwenden, um die initiale Datenabfrage zu begrenzen.
a Beispielabfrage sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime;