Ihr Daten-Template für die Kreditorenzahlungsabwicklung
Ihr Daten-Template für die Kreditorenzahlungsabwicklung
- Wichtige Attribute für die Lieferanten- und Zahlungsanalyse
- Zentrale Prozessmeilensteine des Zahlungszyklus
- Spezielle Extraktionslogik für SAP-S/4HANA-Systeme
Attribute der Kreditorenzahlungsabwicklung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivität Activity | Die konkrete Aufgabe oder Statusänderung des Rechnungsereignisses. | ||
| Beschreibung Dieses Attribut bildet die einzelnen Prozessschritte im Lebenszyklus der Rechnung ab. Es erfasst Ereignisse wie Rechnungserstellung, Buchung, Sperrung, Freigabe und Zahlungsausgleich. Die Aktivitätsnamen werden aus Transaktionscodes, Änderungsprotokolleinträgen oder Workflow-Statusänderungen im Quellsystem abgeleitet. Für die Analyse ist dieses Feld entscheidend, um Prozessvarianten abzubilden. Die Process-Mining-Engine visualisiert damit die Abfolge der Schritte, erkennt Nacharbeitsschleifen und zeigt, an welchen Stellen der Prozess vom üblichen Ablauf abweicht. Das Feld ist ein zentraler Bestandteil des Event Logs. Warum das wichtig ist Es legt die Knoten in der Prozessdarstellung fest und ermöglicht, Workflow und Engpässe sichtbar zu machen. Woher beziehen Abgeleitet aus Transaktionscodes (TCODE) oder Änderungsbelegkopf (CDHDR) und -position (CDPOS) Beispiele Rechnung gebuchtZahlungssperre gesetztZahlungslauf ausgeführtRechnung ausgeglichen | |||
| Ereigniszeit EventTime | Der genaue Timestamp, zu dem die Aktivität stattgefunden hat. | ||
| Beschreibung Die Ereigniszeit erfasst Datum und Uhrzeit, zu denen eine Aktivität in der SAP-Datenbank verbucht wurde. Sie liefert die zeitliche Grundlage, um Ereignisse innerhalb eines Case chronologisch zu ordnen. Dieser Timestamp wird üblicherweise aus den Feldern CPU-Datum und CPU-Uhrzeit in den Systemprotokollen oder Belegköpfen gebildet. Für die Analyse ist dieses Attribut unverzichtbar, um Zykluszeiten, Dauer und Durchsatz zu berechnen. Es ermöglicht die Messung der Zeitabstände zwischen Prozessschritten, etwa zwischen Rechnungseingang und abschließender Freigabe. Das ist entscheidend, um Engpässe zu erkennen und die KPI-Leistung, beispielsweise die durchschnittliche Rechnungsfreigabezeit, zu bewerten. Warum das wichtig ist Es gibt die chronologische Reihenfolge der Ereignisse vor und bildet die Grundlage für alle zeitbezogenen Leistungsberechnungen. Woher beziehen SAP-Tabelle BKPF, Felder CPUDT (Erfassungsdatum) und CPUTM (Erfassungszeit), oder CDHDR-Felder UDATE und UTIME Beispiele 2023-10-12T08:30:00.000Z2023-10-12T14:15:22.000Z2023-10-15T09:00:00.000Z | |||
| Rechnungsnummer InvoiceNumber | Die eindeutige Kennung der bearbeiteten Lieferantenrechnung. | ||
| Beschreibung Die Rechnungsnummer ist der primäre Schlüssel zur Nachverfolgung des Lebenszyklus eines Kreditorenpostens im SAP-S/4HANA-System. Gemeint ist die Nummer des Buchhaltungsbelegs, die beim Buchen der Rechnung ins Hauptbuch vergeben wird. In der SAP-Standardterminologie entspricht sie der Belegnummer (BELNR) innerhalb eines bestimmten Buchungskreises und Geschäftsjahres. In der Prozessanalyse dient dieses Attribut als Case-ID. Es verknüpft alle einzelnen Aktivitäten, vom ersten Rechnungseingang und der Vorerfassung über verschiedene Freigabesperren und Änderungen bis zum abschließenden Zahlungsausgleich. Werden Ereignisse nach dieser Kennung gruppiert, lässt sich der vollständige Ablauf jeder Zahlungsverpflichtung rekonstruieren. Warum das wichtig ist Sie dient als eindeutige Case-ID und ermöglicht die durchgängige Rekonstruktion des Zahlungsprozesses. Woher beziehen SAP-Tabelle BKPF (Buchhaltungsbelegkopf), Feld BELNR, oder Feld BELNR in ACDOCA Beispiele 1900000523510000289119000006015100003002 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp der letzten Extraktion oder Aktualisierung des Datensatzes. | ||
| Beschreibung Die letzte Datenaktualisierung gibt an, wann die Daten erfolgreich in die Process-Mining-Plattform geladen wurden. Sie zeigt nicht den Zeitpunkt des Geschäftsereignisses, sondern wie aktuell der Datensatz ist. Das ist wichtig, damit Sie den Analyse-Dashboards vertrauen können. In der Analyse hilft dieses Attribut den Benutzern, die Aktualität der angezeigten Informationen einzuschätzen. Besonders wichtig ist es bei der Überwachung von Dashboards mit nahezu Echtzeitdaten, etwa der Analyse von Zahlungssperren. So können Entscheidungen auf Grundlage des aktuellen Stands des SAP-S/4HANA-Systems getroffen werden. Warum das wichtig ist Es informiert über die Aktualität der Daten, was für operative Dashboards entscheidend ist. Woher beziehen Wird durch den ETL- bzw. Extraktionsprozess erzeugt Beispiele 2023-10-27T23:59:59.000Z2023-11-01T06:00:00.000Z | |||
| Quellsystem SourceSystem | Die Kennung der SAP-S/4HANA-Instanz, aus der die Daten stammen. | ||
| Beschreibung Dieses Attribut kennzeichnet die ERP-Installation oder den Mandanten, aus dem die Prozessdaten extrahiert wurden. In Systemlandschaften mit mehreren SAP-Instanzen oder parallel betriebenen Altsystemen gewährleistet das Feld die Nachverfolgbarkeit der Daten und ermöglicht systemübergreifende Vergleiche. In der Analyse dient das Feld als übergeordneter Filter. Es hilft, Daten für Leistungsvergleiche zwischen regionalen Systeminstallationen zu trennen oder die Datenkonsistenz bei Systemmigrationen zu prüfen. So lassen sich Prozessabweichungen, die auf die Systemkonfiguration zurückzuführen sind, richtig einordnen. Warum das wichtig ist Es unterscheidet Datenquellen in Umgebungen mit mehreren Systemen und ermöglicht eine präzise Segmentierung. Woher beziehen System-ID (SY-SYSID) aus dem SAP-Installationskontext Beispiele SAP_PROD_01S4H_NA_100ERP_EU_200 | |||
| Ausgleichsdatum ClearingDate | Das Datum, an dem die Rechnung durch Zahlung ausgeglichen wurde. | ||
| Beschreibung Das Ausgleichsdatum gibt an, wann der offene Posten im Kreditorenbuch ausgeglichen wurde, üblicherweise durch einen Zahlungslauf oder eine manuelle Zahlungsbuchung. Damit endet die Verbindlichkeit. In der Analyse dient dieses Attribut zur Berechnung der abschließenden Zykluszeit des Prozesses. Es ist der Timestamp für die Aktivität „Zahlung ausgeglichen“ und wird mit dem Nettofälligkeitsdatum verglichen, um die Pünktlichkeit der Zahlung zu bestimmen. Die Daten fließen direkt in das Dashboard zur Effizienz des Zahlungsausgleichs ein. Warum das wichtig ist Es kennzeichnet den Abschluss des Zahlungsprozesses und dient zur Bewertung der Zahlungspünktlichkeit. Woher beziehen SAP-Tabelle BSEG oder Feld AUGDT, Feld AUGDT Beispiele 2023-11-012023-11-15 | |||
| Belegart DocumentType | Klassifiziert den Buchhaltungsbeleg, zum Beispiel als Lieferantenrechnung, Zahlung oder Gutschrift. | ||
| Beschreibung Die Belegart ist ein zweistelliger SAP-Code, der den Buchungsvorgang klassifiziert. Gängige Belegarten sind „KR“ für Lieferantenrechnungen, „KZ“ für Lieferantenzahlungen und „RE“ für Rechnungseingänge mit Bruttobetrag. Sie legt den Nummernkreis und den Feldstatus des Belegs fest. In der Analyse dient dieses Attribut dazu, den Prozessumfang zu filtern. So kann ein Business-Analyst beispielsweise Gutschriften ausschließen, um ausschließlich die Effizienz ausgehender Zahlungen zu untersuchen. Außerdem zeigt es die Zusammensetzung der verarbeiteten Vorgangsarten und unterstützt das Dashboard zur Komplexität von Prozessvarianten. Warum das wichtig ist Es kategorisiert den Case, etwa als Rechnung oder Gutschrift, und ermöglicht so eine gezielte Analyse. Woher beziehen SAP-Tabelle BKPF, Feld BLART Beispiele KRREKZKG | |||
| Benutzername UserName | Die ID des Benutzers, der die jeweilige Aktivität ausgeführt hat. | ||
| Beschreibung Der Benutzername enthält die Anmelde-ID der Person oder des Systemkontos, das für einen Prozessschritt verantwortlich ist. Dabei kann es sich um einen Benutzer handeln, der Daten manuell erfasst, oder um eine Hintergrundverarbeitung (z. B. „BATCH_USER“), die automatisierte Aufgaben ausführt. In der Analyse ermöglicht dieses Attribut die Berechnung der Automatisierungsrate von Aktivitäten. Durch die Unterscheidung zwischen menschlichen Benutzern und Systemkonten lässt sich der Automatisierungsgrad des Prozesses messen. Außerdem dient es im Dashboard zur Verteilung manueller Bearbeitungspunkte dazu, die Arbeitslast der Teams zu bewerten. Warum das wichtig ist Es unterscheidet manuelle von automatisierten Tätigkeiten und ermöglicht so die Berechnung der Automatisierungsrate. Woher beziehen SAP-Tabelle BKPF, Feld USNAM, oder CDHDR, Feld USERNAME Beispiele BSMITHWF-BATCHRJONES | |||
| Buchungskreis CompanyCode | Die Organisationseinheit, für die Bilanz und Gewinn-und-Verlust-Rechnung erstellt werden. | ||
| Beschreibung Der Buchungskreis ist die eigenständige Rechnungslegungseinheit innerhalb des Unternehmens. Als zentrale Organisationseinheit des externen Rechnungswesens strukturiert er die Finanzdaten. Jede Rechnung wird genau einem Buchungskreis zugeordnet. In der Analyse ermöglicht dieses Attribut, KPIs nach Rechtseinheit oder Region aufzuschlüsseln. Dashboards vergleichen damit die Effizienz der Kreditorenteams verschiedener Tochtergesellschaften. So lässt sich beispielsweise feststellen, ob eine bestimmte Niederlassung häufiger manuelle Zahlungssperren setzt als im Unternehmensstandard vorgesehen. Warum das wichtig ist Es gliedert den Prozess nach Rechtseinheit und erleichtert interne Leistungsvergleiche. Woher beziehen SAP-Tabelle BKPF, Feld BUKRS Beispiele US01DE1010002000 | |||
| Grund der Zahlungssperre PaymentBlockReason | Der Code für den Grund, aus dem eine Rechnung für die Zahlung gesperrt ist. | ||
| Beschreibung Dieses Attribut enthält den konkreten Grundcode für eine Rechnungssperre, durch die der automatische Zahlungslauf die Rechnung nicht berücksichtigt. Beispiele sind „A“ für Zahlungssperre, „R“ für Rechnungsprüfung oder manuelle Sperren durch Benutzer. In der Analyse ist dieses Feld die wichtigste Grundlage für das Dashboard zur Analyse manueller Zahlungssperren. Durch die Auswertung der Häufigkeit verschiedener Sperrgründe kann das Unternehmen systemische Probleme erkennen, etwa häufige Preisabweichungen oder fehlende Wareneingänge, die den Zahlungsprozess verzögern. Warum das wichtig ist Es zeigt die konkrete Ursache für Prozessunterbrechungen und ermöglicht eine gezielte Ursachenanalyse. Woher beziehen SAP-Tabelle BSEG, Feld ZLSPR Beispiele ABR* | |||
| Lieferantennummer VendorNumber | Die eindeutige Kennung des Lieferanten, der mit der Rechnung verknüpft ist. | ||
| Beschreibung Die Lieferantennummer entspricht dem Kreditorenkonto im SAP-Nebenbuch. Sie verknüpft die Rechnung mit den Stammdaten, in denen Zahlungsbedingungen, Bankverbindungen und Kontaktdaten hinterlegt sind. In S/4HANA ist sie häufig mit dem Geschäftspartnerkonzept verknüpft, wird in vielen Tabellen jedoch weiterhin unter dem alten Feldnamen LIFNR geführt. In der Analyse ist dieses Attribut eine wichtige Grundlage für das Dashboard zur Einhaltung der Zahlungsbedingungen von Lieferanten. Damit können Business-Analysten die Prozessleistung nach Lieferant auswerten und feststellen, welche Lieferanten wiederholt Sperren, Preisabweichungen oder Verzögerungen verursachen. Die Erkenntnisse unterstützen strategische Beschaffungsentscheidungen und das Lieferantenmanagement. Warum das wichtig ist Es ermöglicht die Auswertung der Leistung nach Lieferant und hilft, die Ursachen von Verzögerungen zu ermitteln. Woher beziehen SAP-Tabelle BKPF, Feld LIFNR, oder ACDOCA, Feld LIFNR Beispiele 100050VEND-US-99200400 | |||
| Nettofälligkeitsdatum NetDueDate | Das berechnete Datum, bis zu dem die Rechnung bezahlt werden muss, um Strafkosten zu vermeiden. | ||
| Beschreibung Das Nettofälligkeitsdatum ist die endgültige Zahlungsfrist. Es wird berechnet, indem die maximale Zahlungsfrist zum Basisdatum addiert wird. Es ist mitunter direkt gespeichert, wird in Analyseansichten jedoch häufig berechnet. In der Analyse dient es als wichtigste Vergleichsgröße für die Nachverfolgung verspäteter Zahlungen und möglicher Strafkosten. Der Vergleich des tatsächlichen Ausgleichsdatums mit dem Nettofälligkeitsdatum ergibt die Kennzahl „Tage verspätet bezahlt“. Damit lassen sich die Effizienz des Kreditorenteams und das Risiko von Spannungen mit Lieferanten bewerten. Warum das wichtig ist Es ist der angestrebte Endtermin des Prozesses. Wird er verpasst, kann das die Bonität beeinträchtigen und zusätzliche Kosten verursachen. Woher beziehen Berechnet: Basisdatum + maximale Zahlungsfrist in Tagen (ZBD1T/ZBD2T/ZBD3T) Beispiele 2023-11-302023-12-01 | |||
| Ohne manuelle Bearbeitung IsTouchless | Ein boolesches Kennzeichen, das angibt, ob die Rechnung ohne manuelle Eingriffe verarbeitet wurde. | ||
| Beschreibung Dieses Attribut wird berechnet, indem der Ereignisverlauf eines Falls analysiert wird. Enthält der Fall ausschließlich automatisierte Aktivitäten, etwa durch den Benutzer „system“ oder bestimmte Hintergrund-TCODES, und keine manuellen Änderungen oder Sperren, wird er als ohne manuelle Bearbeitung gekennzeichnet. In der Analyse ist dieses Attribut die zentrale Kennzahl für die KPI „Anteil der Rechnungen ohne manuelle Bearbeitung“. Damit kann Ihr Unternehmen den Erfolg von Automatisierungsinitiativen verfolgen und feststellen, welche Falltypen, etwa nach Lieferant oder Region, ohne menschliche Eingriffe durch das System laufen. Warum das wichtig ist Es ist die wichtigste Kennzahl für Prozessautomatisierung und Effizienz. Woher beziehen Berechnet anhand der Abfolge der Aktivitäten und der Benutzertypen Beispiele truefalse | |||
| Rechnungsbetrag InvoiceAmount | Der Bruttogesamtbetrag der Rechnung in Belegwährung. | ||
| Beschreibung Dieses Attribut gibt den finanziellen Wert der Rechnung gemäß dem Quelldokument wieder. Es entspricht der Verbindlichkeit, die gegenüber dem Lieferanten beglichen werden muss. In SAP S/4HANA wird dieser Wert üblicherweise im Feld „Betrag in Belegwährung“ gespeichert. In der Analyse dient der Rechnungsbetrag dazu, die Arbeit zu priorisieren. Dashboards wie die Verteilung manueller Bearbeitungspunkte zeigen damit, ob aufwendige manuelle Tätigkeiten für Rechnungen mit geringem Wert anfallen. So kann das Unternehmen Optimierungsmaßnahmen auf Transaktionen mit hohem Wert konzentrieren, bei denen Prozessfehler ein größeres finanzielles Risiko bergen. Warum das wichtig ist Er zeigt den finanziellen Stellenwert des Case und hilft, Ineffizienzen bei Prozessen mit hohem Rechnungswert zu priorisieren. Woher beziehen SAP-Tabelle BKPF oder BSEG, Feld WRBTR Beispiele 1500.00250.5010000.00 | |||
| Zahlung verspätet IsLatePayment | Ein boolesches Kennzeichen, das angibt, ob die Zahlung nach dem Nettofälligkeitsdatum erfolgt ist. | ||
| Beschreibung Dieses berechnete Attribut ist wahr, wenn das Ausgleichsdatum nach dem Nettofälligkeitsdatum liegt. Es dient als binärer Indikator für die Prozessleistung. In der Analyse wird dieses Kennzeichen verwendet, um für die KPI „Häufigkeit verspäteter Zahlungen“ die Anzahl der nicht konformen Fälle zu ermitteln. Es vereinfacht die Erstellung von Dashboards, da Sie dafür lediglich die „Wahr“-Werte zählen müssen, statt in der Visualisierung komplexe Datumsberechnungen vorzunehmen. Warum das wichtig ist So lassen sich KPIs zur Pünktlichkeit einfacher berechnen. Woher beziehen Berechnet: Ausgleichsdatum > Nettofälligkeitsdatum Beispiele truefalse | |||
| Zahlungsbedingungen PaymentTerms | Der Schlüssel für die vereinbarten Zahlungs- und Skontobedingungen. | ||
| Beschreibung Die Zahlungsbedingungen legen fest, wann eine Rechnung fällig ist und ob bei frühzeitiger Zahlung Skonto gewährt wird. Der Code (z. B. „Z001“) steht für Regeln wie „Netto 30“ oder „2 % innerhalb von 10 Tagen, netto 30 Tage“. Er wird aus den Lieferantenstammdaten in die Rechnung übernommen, kann aber manuell geändert werden. In der Analyse ist dieses Attribut zentral für Dashboards zur Optimierung von Skonti bei frühzeitiger Zahlung und zur Einhaltung der Zahlungsbedingungen von Lieferanten. Das System berechnet damit das Basisfälligkeitsdatum und ermittelt, ob die Zahlung innerhalb des optimalen Zeitfensters erfolgte, um Skonto zu erhalten. Warum das wichtig ist Es bestimmt den erwarteten Zeitrahmen und die finanziellen Anreize und ist damit entscheidend für die Skontoanalyse. Woher beziehen SAP-Tabelle BSEG, Feld ZTERM Beispiele Z001NT300001 | |||
| Basisdatum BaselineDate | Das Datum, ab dem die Zahlungsbedingungen gelten und Fälligkeitstermine berechnet werden. | ||
| Beschreibung Das Basisdatum ist der Ausgangspunkt für die Berechnung des Nettofälligkeitsdatums und der Skontofristen. Je nach Konfiguration und Lieferantenstammdaten entspricht es üblicherweise dem Rechnungs- oder Buchungsdatum. In der Analyse ist dieses Datum eine technische Voraussetzung für die Berechnung des Status „Verspätet“. Fehler beim Basisdatum führen häufig zu verfrühten Zahlungen mit Auswirkungen auf den Cashflow oder zu verspäteten Zahlungen mit möglichen Strafkosten. Die Prüfung der Datumsgenauigkeit gehört zur Analyse der Einhaltung von Zahlungsbedingungen durch Lieferanten. Warum das wichtig ist Es ist der Ausgangspunkt für alle Fälligkeitsberechnungen. Woher beziehen SAP-Tabelle BSEG, Feld ZFBDT Beispiele 2023-10-012023-10-15 | |||
| Einkaufsbeleg PurchasingDocument | Die zur Rechnung gehörende Bestellnummer. | ||
| Beschreibung Dieses Attribut verknüpft die Rechnung mit dem vorgelagerten Beschaffungsprozess. Es enthält die Bestellnummer, mit der die Rechnung abgeglichen wird. Nicht alle Rechnungen, etwa für sonstige Aufwendungen, haben einen Bestellbezug. In der Analyse ist dieses Feld wichtig für die Analyse der Drei-Wege-Abgleichsquote. Business-Analysten können damit Rechnungen mit und ohne Bestellbezug getrennt auswerten, da für diese in der Regel unterschiedliche Freigabe-Workflows gelten. Außerdem ermöglicht es Process Mining über den gesamten Ablauf hinweg, indem es Kreditorendaten mit Beschaffungsdaten verknüpft. Warum das wichtig ist Es verknüpft die Kreditorenbuchhaltung mit der Beschaffung und ermöglicht die Analyse des Drei-Wege-Abgleichs sowie eine durchgängige Prozessanalyse. Woher beziehen SAP-Tabelle BSEG, Feld EBELN Beispiele 45000012344500009876 | |||
| Entgangener Skontobetrag DiscountLostAmount | Der Geldwert verfügbarer Skonti, die nicht in Anspruch genommen wurden. | ||
| Beschreibung Dieses berechnete Attribut beziffert den entgangenen finanziellen Vorteil. Es wird ermittelt, indem geprüft wird, ob die Zahlung nach Ablauf der Skontofrist erfolgte. Ist dies der Fall, wird der Wert des entgangenen Skontos auf Grundlage des Rechnungsbetrags berechnet. In der Analyse ist diese Kennzahl für den Optimierer für Skonto bei frühzeitiger Zahlung von zentraler Bedeutung. Sie beziffert die Kosten ineffizienter Abläufe in konkreten Geldbeträgen und liefert damit eine überzeugende Grundlage für Prozessverbesserungen. Warum das wichtig ist Damit lässt sich der direkte finanzielle Verlust durch Prozessverzögerungen beziffern. Woher beziehen Berechnet: Wenn Ausgleichsdatum > Skontodatum, dann Rechnungsbetrag * Skonto % Beispiele 30.000.00150.00 | |||
| Geschäftsjahr FiscalYear | Das Geschäftsjahr, dem die Rechnung zugeordnet ist. | ||
| Beschreibung Das Geschäftsjahr ist ein Zeitraum für die Finanzberichterstattung. Zusammen mit Buchungskreis und Belegnummer bildet es den zusammengesetzten Primärschlüssel eines Finanzbelegs in SAP. In der Analyse ist es technisch erforderlich, um Cases eindeutig zu identifizieren, und unterstützt zugleich Jahresvergleiche. So bleibt die Case-ID „Rechnungsnummer“ auch über Jahrzehnte an Daten eindeutig. Warum das wichtig ist Technische Voraussetzung für die eindeutige Identifizierung von Cases in SAP FI. Woher beziehen SAP-Tabelle BKPF, Feld GJAHR Beispiele 20232024 | |||
| Skontoprozentsatz 1 CashDiscountPercentage1 | Der Skontosatz, der bei Zahlung innerhalb der ersten Skontofrist gilt. | ||
| Beschreibung Dieses Attribut gibt den finanziellen Anreiz an, den der Lieferant für eine frühzeitige Zahlung gewährt, zum Beispiel „2“ bei „2 % innerhalb von 10 Tagen“. In der Analyse dient es zur Berechnung des möglichen Skontobetrags. Wird dieser Prozentsatz mit dem Rechnungsbetrag multipliziert, können Dashboards die Summe der Einsparungen ausweisen, die durch Prozessineffizienzen entgangen sind. Das unterstützt die Wirtschaftlichkeitsbetrachtung einer Automatisierung. Warum das wichtig ist Es beziffert die möglichen Einsparungen und ist damit eine wichtige Grundlage für die Berechnung des ROI. Woher beziehen SAP-Tabelle BSEG, Feld ZBD1P Beispiele 2.03.00.0 | |||
| Skontotage 1 CashDiscountDays1 | Die Anzahl der Tage ab dem Basisdatum, innerhalb derer der erste Skonto verfügbar ist. | ||
| Beschreibung Dieses Attribut legt das Zeitfenster für die günstigsten Zahlungsbedingungen fest, zum Beispiel „10“ bei „2 % innerhalb von 10 Tagen, netto 30 Tage“. Der Wert stammt aus den Bedingungen, die in der Rechnungsposition hinterlegt sind. In der Analyse hilft dieses Feld, das „Zieldatum“ für die Optimierung von Skonti bei frühzeitiger Zahlung zu bestimmen. Wird die Rechnung innerhalb dieses Zeitfensters ausgeglichen, wird der Skonto realisiert. Anhand des Feldes lassen sich die entgangenen Einsparungen durch lange Bearbeitungszeiten ermitteln. Warum das wichtig ist Es legt das Zeitfenster fest, in dem finanzielle Einsparungen möglich sind. Woher beziehen SAP-Tabelle BSEG, Feld ZBD1T Beispiele 10140 | |||
| Währung Currency | Der Währungscode des Rechnungsbetrags. | ||
| Beschreibung Das Währungsattribut gibt an, in welcher Währung der Rechnungsbetrag ausgewiesen ist, zum Beispiel USD, EUR oder GBP. Es ermöglicht die korrekte Interpretation der Finanzwerte und ist unverzichtbar, wenn Daten aus internationalen Buchungskreisen zusammengeführt werden. In der Analyse stellt dieses Feld sicher, dass Finanz-KPIs korrekt berechnet werden. Häufig dient es dazu, Werte für globale Dashboards in eine Berichtswährung umzurechnen. Ohne dieses Attribut wären Kennzahlen wie Gesamtausgaben oder durchschnittlicher Rechnungswert in einer Umgebung mit mehreren Währungen nicht aussagekräftig. Warum das wichtig ist Es ordnet Finanzbeträge ein und ist für eine korrekte globale Berichterstattung unverzichtbar. Woher beziehen SAP-Tabelle BKPF, Feld WAERS Beispiele USDEURGBPJPY | |||
Aktivitäten der Kreditorenzahlungsabwicklung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Rechnung gebucht | Bezeichnet die offizielle Erfassung der Verbindlichkeit im Hauptbuch. Diese Aktivität wird anhand des Erstellungs-Timestamps in der Tabelle BKPF oder des Erfassungsdatums in der Tabelle ACDOCA ermittelt. | ||
| Warum das wichtig ist Dies ist der zentrale Ausgangspunkt für den Finanzzeitplan und bildet die Grundlage für Fälligkeitstermine und die Altersstrukturanalyse. Woher beziehen Tabelle BKPF mit CPUDT (Erfassungsdatum) und CPUTM (Erfassungszeit). Erfassung Wird erfasst, wenn ein BKPF-Datensatz erstellt wird Ereignistyp explicit | |||
| Zahlung ausgeglichen | Kennzeichnet den abschließenden Ausgleich, bei dem der offene Posten auf dem Lieferantenkonto mit der Zahlung verrechnet wird. Erfasst über das Feld AUGDT (Ausgleichsdatum) in der Tabelle BSEG. | ||
| Warum das wichtig ist Der Endzustand des Prozesses zeigt an, dass der Lebenszyklus abgeschlossen und die Buchhaltung ausgeglichen ist. Ein hoher Anteil manueller Ausgleiche weist auf Ineffizienzen beim Abgleich hin. Woher beziehen Tabelle BSEG, Feld AUGDT (Ausgleichsdatum). Erfassung Erfasst, wenn das Feld AUGDT befüllt wird Ereignistyp explicit | |||
| Zahlungsbeleg erstellt | Erstellung des Buchhaltungsbelegs, der die Bank im Haben und den Lieferanten im Soll bucht. Der Beleg ist in BKPF mit einem Zahlungsbelegtyp (z. B. ZP, KZ) zu finden. | ||
| Warum das wichtig ist Die finanzielle Abwicklung der Zahlung, die zur Berechnung der Kreditorenlaufzeit (Days Payable Outstanding, DPO) herangezogen wird. Woher beziehen Tabelle BKPF, gefiltert nach dem für Zahlungen relevanten Belegtyp (BLART). Erfassung Erfasst, wenn der Zahlungsbeleg in BKPF erstellt wird Ereignistyp explicit | |||
| Zahlungslauf ausgeführt | Kennzeichnet die Ausführung des Zahlungslaufs, bei dem Zahlungsanweisungen erstellt werden. Erfasst wird dies anhand der Statusänderung in den Tabellen REGUH oder REGUP. | ||
| Warum das wichtig ist Die operative Zahlungsverpflichtung, entscheidend für die Analyse der Effizienz der Zahlungsbündelung. Woher beziehen Tabelle REGUH, üblicherweise in Verbindung mit Laufdatum und Kennung. Erfassung Erfasst, wenn sich der Status des Zahlungslaufs ändert Ereignistyp explicit | |||
| Zahlungssperre aufgehoben | Zeigt an, dass eine zuvor gesetzte Zahlungssperre aufgehoben und die Rechnung damit zur Zahlung freigegeben wurde. Dies wird erkannt, wenn sich das Feld ZLSPR in BSEG von einem Wert zu null oder einem leeren Wert ändert. | ||
| Warum das wichtig ist Dient häufig als Ersatz für „Rechnung freigegeben“ in Systemen ohne explizite Workflow-Protokolle und markiert das Ende des Engpasses. Woher beziehen Tabellen CDPOS und CDHDR, um Änderungen zu erkennen, bei denen BSEG-ZLSPR geleert wird. Erfassung Wird erfasst, wenn CDPOS die Entfernung von ZLSPR aufzeichnet Ereignistyp explicit | |||
| Zahlungssperre gesetzt | Zeigt an, dass der Rechnungsposition eine Zahlungssperre zugewiesen wurde. Dadurch wird sie nicht in den Zahlungslauf aufgenommen. Die Sperre wird anhand von Änderungen am Feld ZLSPR in der Tabelle BSEG über Änderungsbelege erfasst. | ||
| Warum das wichtig ist Zahlungssperren sind eine der Hauptursachen für verspätete Zahlungen und Prozessverzögerungen. Sie wirken sich direkt auf das Dashboard zur Analyse manueller Zahlungssperren aus. Woher beziehen Tabellen CDPOS und CDHDR (Änderungsbelege), um Aktualisierungen des Felds BSEG-ZLSPR zu ermitteln. Erfassung Wird erfasst, wenn sich der Wert von ZLSPR in CDPOS ändert Ereignistyp explicit | |||
| Mengenabweichung erkannt | Abgeleitete Aktivität, die auf eine Abweichung zwischen der Rechnungsmenge und der Wareneingangsmenge hinweist. Sie wird anhand eines bestimmten Zahlungssperrschlüssels erkannt, der der Position zugewiesen wird, in der Regel „M“ für eine Mengenabweichung. | ||
| Warum das wichtig ist Entscheidend für die Analyse der Zuordnungseffizienz und der Datenqualität in der Lieferkette. Woher beziehen Abgeleitet aus dem Wert „M“ in BSEG-ZLSPR (oder einer systemspezifischen Konfiguration für Mengensperren). Erfassung ZLSPR-Wert mit „M“ vergleichen Ereignistyp inferred | |||
| Preisabweichung erkannt | Abgeleitete Aktivität, die auf eine Abweichung zwischen Rechnungs- und Bestellpreis hinweist. Sie wird anhand eines bestimmten Zahlungssperrschlüssels erkannt, der beim Buchen automatisch gesetzt wird, in der Regel „R“ für die Rechnungsprüfung. | ||
| Warum das wichtig ist Ermittelt die Ursachen manueller Nachbearbeitung und unterstützt die Analyse der Quote erfolgreicher 3-Wege-Prüfungen. Woher beziehen Abgeleitet aus dem Wert „R“ in BSEG-ZLSPR (oder einer systemspezifischen Konfiguration für Preissperren) zum Buchungszeitpunkt. Erfassung ZLSPR-Wert mit „R“ vergleichen Ereignistyp inferred | |||
| Rechnung fällig | Ein berechneter Timestamp für den Zeitpunkt, an dem die Nettofälligkeit der Rechnung erreicht wurde. Er wird ermittelt, indem die Zahlungsfrist in Tagen zum Basisdatum aus der Tabelle BSEG addiert wird. | ||
| Warum das wichtig ist Dient als Referenz für die pünktliche Zahlungsleistung und den Tracker für Verzugsgebühren. Woher beziehen Berechnet aus BSEG-ZFBDT (Basisdatum) + BSEG-ZBD1T/ZBD2T/ZBD3T (Tage). Erfassung Durch Vergleich des aktuellen Datums mit dem Nettofälligkeitstermin ermitteln Ereignistyp calculated | |||
| Rechnung geparkt | Zeigt an, dass eine Rechnung in SAP erfasst, aber noch nicht im Hauptbuch gebucht wurde. Dieser Status wird häufig für die vorläufige Dateneingabe verwendet. Er wird direkt aus der Tabelle VBKPF ermittelt oder anhand von Belegen in BKPF mit einem Parkstatus erkannt, bevor diese gebucht werden. | ||
| Warum das wichtig ist Das Parken markiert den Beginn der Dateneingabe und hilft, die Verzögerung zwischen Rechnungseingang und Entstehung der Zahlungsverpflichtung zu messen. Woher beziehen Tabelle VBKPF mit Kopfdaten geparkter Belege oder BKPF mit einem bestimmten Belegstatus (BSTAT = V). Erfassung Wird erfasst, wenn ein Eintrag in VBKPF erstellt wird Ereignistyp explicit | |||
| Rechnung storniert | Zeigt an, dass der Rechnungsbeleg storniert oder annulliert wurde. Erfasst durch Prüfung, ob das Feld STBLG (Stornobeleg) in der Tabelle BKPF befüllt ist. | ||
| Warum das wichtig ist Kennzeichnet Nacharbeit und Prozessfehler und macht Verschwendung sowie mögliche Doppelarbeit sichtbar. Woher beziehen Tabelle BKPF, Feld STBLG ist nicht leer. Erfassung Erfasst, wenn das Feld STBLG befüllt wird Ereignistyp explicit | |||
| Skonto verfallen | Ein berechnetes Ereignis, das den Tag markiert, an dem die Berechtigung für einen Skonto abgelaufen ist. Es wird ermittelt, indem der Skontofälligkeitstermin mit dem aktuellen Datum oder dem Zahlungsdatum verglichen wird. | ||
| Warum das wichtig ist Wichtig für den Optimierer für Skonti bei frühzeitiger Zahlung, um entgangene Einsparmöglichkeiten sichtbar zu machen. Woher beziehen Berechnet aus BSEG-ZFBDT + BSEG-ZBD1T (Skontofrist 1 in Tagen). Erfassung Durch Vergleich des Datums mit dem Skontofälligkeitstermin ermitteln Ereignistyp calculated | |||
| Zahlungsbedingungen geändert | Erfasst eine Änderung der Zahlungsbedingungen für eine offene Rechnung, durch die sich der Fälligkeitstermin oder die Skontoberechtigung ändert. Die Änderung wird über Änderungsprotokolle zum Feld ZTERM in der Tabelle BSEG nachverfolgt. | ||
| Warum das wichtig ist Häufige Änderungen deuten auf Fehler in den Stammdaten oder manuelle Überschreibungen hin, die sich auf die Cashflow-Prognose und die Einhaltung der Zahlungsbedingungen von Lieferanten auswirken. Woher beziehen Tabellen CDPOS und CDHDR, um Aktualisierungen des Felds BSEG-ZTERM zu ermitteln. Erfassung Wird erfasst, wenn sich der Wert von ZTERM in CDPOS ändert Ereignistyp explicit | |||
| Zahlungsvorschlag erstellt | Zeigt an, dass die Rechnung in einen Zahlungsvorschlagslauf (F110) aufgenommen wurde, den ersten Schritt des automatischen Zahlungsprogramms. Die Daten werden aus der Tabelle REGUH ermittelt, in der Abrechnungsdaten gespeichert sind. | ||
| Warum das wichtig ist Zeigt an, dass die Rechnung zur Zahlung ausgewählt wurde und die Validierungsprüfungen im Zahlungsprogramm bestanden hat. Woher beziehen Zeitstempel der Erstellung des REGUH-Tabelleneintrags (Schlüssel LAUFD und LAUFI). Erfassung Erfasst, wenn der REGUH-Datensatz erstellt wird Ereignistyp explicit | |||
Extraktionsanleitungen
Schritte
Erforderliche CDS-Views ermitteln: Prüfen Sie, ob die Standard-CDS-Views von SAP S/4HANA verfügbar sind. Benötigt werden vor allem I_JournalEntry (Kopf), I_OperationalAcctgDocItem (Positionen, Entsprechung zu BSEG), I_SupplierInvoice (Logistik), I_PaymentProposalItem (F110) und I_ChangeDocument (für Protokolle).
Benutzerberechtigungen konfigurieren: Stellen Sie sicher, dass der Datenbankbenutzer oder technische Servicebenutzer über SELECT-Berechtigungen für die DDL-SQL-Views der CDS-Entitäten verfügt. Dies wird üblicherweise über SAP HANA Studio oder die ABAP Development Tools für Eclipse (ADT) eingerichtet.
SQL-Umgebung vorbereiten: Öffnen Sie Ihre SQL-Schnittstelle, zum Beispiel SAP HANA Studio, DBeaver mit Verbindung zu HANA oder einen Process-Mining-Konnektor mit SQL-Unterstützung. Diese Methode setzt direkten SQL-Zugriff auf die HANA-Ebene voraus, auf der die CDS-Views bereitgestellt werden.
Umfang festlegen: Bestimmen Sie den Buchungskreis (CompanyCode) und den Geschäftsjahreszeitraum, um das Datenvolumen zu begrenzen. Das ist wichtig für die Leistung bei Abfragen der View für operative Buchhaltungsbelegpositionen.
Aktivitätslogik implementieren: Kopieren Sie die unten bereitgestellte SQL-Abfrage. Sie verwendet UNION ALL, um 14 separate Logikblöcke in einer einzigen Event-Log-Struktur zusammenzuführen. Jeder Block bezieht sich auf eine bestimmte Aktivität, zum Beispiel „Rechnung gebucht“ oder „Zahlung ausgeglichen“.
Änderungsbelege berücksichtigen: Die Abfrage enthält Abschnitte für Änderungen der Zahlungsbedingungen und Änderungen an Zahlungssperren. Diese greifen auf die View I_ChangeDocument zu. Ist diese View in Ihrer S/4-Version nicht aktiv, müssen Sie die zugrunde liegenden Tabellen CDHDR/CDPOS möglicherweise in einer benutzerdefinierten CDS-View zusammenfassen.
Berechnete Ereignisse berücksichtigen: Prüfen Sie die Logik für „Rechnung fällig“ und „Skonto verfallen“. Diese berechneten Ereignisse entstehen, indem Tage zum Basisdatum aus der View für operative Positionen addiert werden.
Extraktion ausführen: Führen Sie die Abfrage aus. Bei großen Datenmengen empfiehlt es sich dringend, die Extraktion nach Geschäftsjahr oder Buchungskreis aufzuteilen, um Speicherüberläufe zu vermeiden.
Datumsformate prüfen: Stellen Sie sicher, dass die Spalte EventTime das Format YYYY-MM-DD HH:MM:SS hat. SAP HANA SQL gibt Timestamps zurück, die je nach Zielanwendung möglicherweise umgewandelt werden müssen.
Daten exportieren: Speichern Sie das Ergebnis als CSV- oder Parquet-Datei. Achten Sie darauf, dass die Spaltenüberschriften den Spalten der abschließenden SELECT-Anweisung entsprechen.
Daten für den Upload umwandeln: Wenn Ihr Process-Mining-Tool ein bestimmtes CSV-Format erfordert, zum Beispiel ein bestimmtes Datumsformat, nehmen Sie die Umwandlungen in einem Skript zur Nachverarbeitung oder mit TO_VARCHAR-Funktionen direkt in SQL vor.
Abschließende Prüfung: Laden Sie eine Stichprobe in ProcessMind und prüfen Sie, ob die Case-ID (Rechnungsnummer) alle Aktivitäten von der Buchung bis zum Ausgleich korrekt gruppiert.
Konfiguration
- Buchungskreisfilter: Begrenzen Sie die Abfrage auf bestimmte Organisationseinheiten (CompanyCode = '1000'), um Kontext und Leistung zu wahren.
- Datumsbereich: Filtern Sie nach PostingDate oder CreationDate, zum Beispiel auf die letzten 12 Monate, um das Datenvolumen zu steuern.
- Kontenart: Filtern Sie I_OperationalAcctgDocItem nach FinancialAccountType = 'K' (Lieferant), um Hauptbuch- und Debitorenpositionen auszuschließen.
- CDS-View-Aktivierung: Stellen Sie sicher, dass die Views I_JournalEntry, I_OperationalAcctgDocItem und I_PaymentProposalItem aktiv und für den SQL-Zugriff freigegeben sind.
- Leistung des Änderungsprotokolls: Abfragen der I_ChangeDocument können ressourcenintensiv sein. Begrenzen Sie diese Unterabfragen auf die Objektklasse 'BELEG' und bestimmte Feldnamen wie ZLSPR und ZTERM.
a Beispielabfrage sql
/* SAP S/4HANA CDS View Extraction for Accounts Payable */
/* Combined Event Log Query */
/* 1. Invoice Parked */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Parked' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JE.CreationDateTime > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
'False' AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K' -- Vendor
AND JE.AccountingDocumentCategory = 'V' -- Parked Document
UNION ALL
/* 2. Invoice Posted */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Posted' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
JE.CreatedByUser AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
'False' AS IsLatePayment,
CASE WHEN JE.CreatedByUser = 'BATCH_USER' THEN 'True' ELSE 'False' END AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.AccountingDocumentCategory <> 'V' -- Exclude Parked
UNION ALL
/* 3. Price Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Price Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'R' -- Standard SAP Price Variance Block Key
UNION ALL
/* 4. Quantity Variance Detected (Inferred at Posting) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Quantity Variance Detected' AS Activity,
JE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
JEItem.PaymentBlockingReason AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.PaymentBlockingReason = 'M' -- Standard SAP Quantity Variance Block Key
UNION ALL
/* 5. Payment Block Applied (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Applied' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
CD.NewValue AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NULL AND CD.NewValue IS NOT NULL
UNION ALL
/* 6. Payment Block Removed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Block Removed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZLSPR'
AND CD.OldValue IS NOT NULL AND (CD.NewValue IS NULL OR CD.NewValue = '')
UNION ALL
/* 7. Payment Terms Changed (via Change Document) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Terms Changed' AS Activity,
CD.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
CD.NewValue AS PaymentTerms,
NULL AS PaymentBlockReason,
CD.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_ChangeDocument AS CD
JOIN I_JournalEntry AS JE ON CD.ObjectValue = CONCAT(JE.CompanyCode, JE.AccountingDocument)
JOIN I_OperationalAcctgDocItem AS JEItem ON JE.AccountingDocument = JEItem.AccountingDocument AND JE.CompanyCode = JEItem.CompanyCode
WHERE CD.ObjectClass = 'BELEG'
AND CD.TableName = 'BSEG'
AND CD.FieldName = 'ZTERM'
UNION ALL
/* 8. Invoice Due (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Due' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) < CURRENT_DATE
UNION ALL
/* 9. Cash Discount Lost (Calculated) */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Cash Discount Lost' AS Activity,
TO_TIMESTAMP(ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days))) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.CashDiscount1Days > 0
AND (JEItem.ClearingDate IS NULL OR JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.CashDiscount1Days)))
UNION ALL
/* 10. Payment Proposal Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Proposal Created' AS Activity,
PPI.ProposalRunDate AS EventTime, -- Often just a date, cast to timestamp if needed
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
AND PPI.FiscalYear = JE.FiscalYear
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JEItem.FinancialAccountType = 'K'
UNION ALL
/* 11. Payment Run Executed */
/* Derived from existence in payment tables with a run ID */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Run Executed' AS Activity,
PPI.PaymentRunDate AS EventTime,
JE.CompanyCode,
PPI.Supplier AS VendorNumber,
PPI.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PPI.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_PaymentProposalItem AS PPI
JOIN I_JournalEntry AS JE
ON PPI.CompanyCode = JE.CompanyCode
AND PPI.AccountingDocument = JE.AccountingDocument
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
WHERE PPI.PaymentRunID IS NOT NULL
UNION ALL
/* 12. Payment Document Created */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Document Created' AS Activity,
PayJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
PayJE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
PayJE.CreatedByUser AS UserName,
PayJE.PostingDate AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS PayJE
ON JEItem.ClearingJournalEntry = PayJE.AccountingDocument
AND JEItem.ClearingJournalEntryFiscalYear = PayJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingJournalEntry IS NOT NULL
UNION ALL
/* 13. Payment Cleared */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Payment Cleared' AS Activity,
TO_TIMESTAMP(JEItem.ClearingDate) AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
'System' AS UserName,
JEItem.ClearingDate,
ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) AS NetDueDate,
CASE WHEN JEItem.ClearingDate > ADD_DAYS(JEItem.DocumentItemDate, TO_INTEGER(JEItem.NetPaymentDays)) THEN 'True' ELSE 'False' END AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JEItem.ClearingDate IS NOT NULL
UNION ALL
/* 14. Invoice Reversed */
SELECT
JE.OriginalReferenceDocument AS InvoiceNumber,
'Invoice Reversed' AS Activity,
RevJE.CreationDateTime AS EventTime,
JE.CompanyCode,
JEItem.Supplier AS VendorNumber,
JEItem.AmountInTransactionCurrency AS InvoiceAmount,
JE.AccountingDocumentType AS DocumentType,
JEItem.PaymentTerms,
NULL AS PaymentBlockReason,
RevJE.CreatedByUser AS UserName,
NULL AS ClearingDate,
NULL AS NetDueDate,
NULL AS IsLatePayment,
NULL AS IsTouchless,
'S4HANA' AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate
FROM I_JournalEntry AS JE
JOIN I_OperationalAcctgDocItem AS JEItem
ON JE.CompanyCode = JEItem.CompanyCode
AND JE.AccountingDocument = JEItem.AccountingDocument
AND JE.FiscalYear = JEItem.FiscalYear
JOIN I_JournalEntry AS RevJE
ON JE.ReverseDocument = RevJE.AccountingDocument
AND JE.ReverseDocumentFiscalYear = RevJE.FiscalYear
WHERE JEItem.FinancialAccountType = 'K'
AND JE.ReverseDocument IS NOT NULL Schritte
- Prüfen Sie, ob direkter SQL-Zugriff auf das SAP-HANA-Schema mit ACDOCA, BKPF, BSEG, VBKPF, REGUH, REGUP und den einschlägigen Änderungsbelegtabellen verfügbar ist. Ersetzen Sie [Your SAP HANA schema] und die Verbindungsdaten durch die für Ihr System freigegebenen Werte.
- Legen Sie den Rechnungsbestand und den Berichtszeitraum fest. Geben Sie [Start date] und [End date] im Format YYYYMMDD an und konfigurieren Sie [Company code filter] als gültige SQL-Bedingung, zum Beispiel BUKRS IN ('1000','2000').
- Prüfen Sie die SAP-Version und die lokale Konfiguration für geparkte Belege, Statusfelder des Zahlungsprogramms, Zahlungsbelegarten und die Speicherung von Änderungsbelegen. Die Abfrage verwendet dokumentierte Quellobjekte und vorsichtige Feldzuordnungen. Lokale Erweiterungen und Versionsunterschiede müssen jedoch vor dem produktiven Einsatz geprüft werden.
- Führen Sie die Abfrage mit einem freigegebenen SQL-Client oder Extraktionsdienst auf SAP HANA aus. Die Abfrage erstellt für jede ausdrücklich extrahierte Aktivität eine Ereigniszeile. ProcessMind leitet keine Aktivitäten ab, die im Ergebnis fehlen.
- Prüfen Sie die Quelldaten und passen Sie die gekennzeichneten Konfigurationsbedingungen für den Parkstatus, Zahlungsbelegarten, Status des Zahlungsvorschlags und Zahlungslaufs sowie Änderungsbeleg-Objektklassen an. Erweitern Sie diese Bedingungen nicht, ohne doppelte oder nicht zugehörige Buchhaltungsbelege abzugleichen.
- Prüfen Sie die Verknüpfungen anhand von InvoiceNumber, CompanyCode, Geschäftsjahr, Buchhaltungsbelegnummer, Lieferantennummer und gegebenenfalls Positionsnummer. Stellen Sie sicher, dass Rechnungsbelegnummern in BKPF, BSEG, ACDOCA, REGUH und REGUP im Zielsystem einheitlich dargestellt werden.
- Gleichen Sie berechnete Ereignisse ab. „Rechnung fällig“ wird am berechneten Nettofälligkeitsdatum erzeugt. „Skonto verfallen“ wird zum frühesten zutreffenden Skontotermin erzeugt, sofern bis dahin keine Zahlung erfolgt ist. Diese abgeleiteten Zeilen sollten klar von Ereignissen aus Quelldatensätzen unterschieden werden.
- Exportieren Sie das Ergebnis als flache UTF-8-CSV-Datei oder in einem anderen von ProcessMind unterstützten Tabellenformat. Behalten Sie die Spaltennamen InvoiceNumber, Activity, EventTime, SourceSystem und LastDataUpdate exakt bei. Verwenden Sie eine Zeile pro Ereignis und fassen Sie Aktivitäten nicht nach Rechnung zusammen.
- Laden Sie das Event Log in ProcessMind hoch und ordnen Sie InvoiceNumber als Case-ID, Activity als Aktivitätsnamen und EventTime als Ereignis-Timestamp zu. Ordnen Sie die übrigen Spalten gemäß der ProcessMind-Importkonfiguration als Ereignis- oder Fallattribute zu.
Konfiguration
- Datumsbereich: Verwenden Sie für die erste Extraktion einen rollierenden Zeitraum von 3 bis 6 Monaten. Wenden Sie Bedingungen für Buchungsdatum, Änderungsdatum und Datum des Zahlungsprogramms einheitlich an. Erweitern Sie den Zeitraum, wenn Sie längere Zahlungsziele prüfen.
- Schema: Ersetzen Sie [Your SAP HANA schema] durch das Schema, dem die SAP-Objekte zugeordnet sind. Prüfen Sie, ob die Umgebung mandantenabhängige Objekte über das ausgewählte Schema bereitstellt oder eine explizite Mandantenbedingung erfordert.
- Buchungskreisfilter: Konfigurieren Sie [Company code filter], um BUKRS auf die erforderlichen Buchungskreise zu begrenzen. Wenden Sie denselben Umfang auf BKPF, BSEG, ACDOCA, REGUH, REGUP und Änderungsbelegquellen an, sofern die entsprechenden Felder verfügbar sind.
- Belegfilter: Prüfen Sie die Bedingungen für Rechnungsbelegarten und Zahlungsbelegarten. Die Abfrage enthält gängige Beispiele. Belegarten sind jedoch konfigurierbar und müssen auf das Zielsystem abgestimmt werden.
- Geparkte Rechnungen: Prüfen Sie, wie der Status geparkter Belege in VBKPF oder BKPF dargestellt wird. Da die Statuscodierung je nach Version und Implementierung variieren kann, verwendet die Abfrage eine konfigurierbare Bedingung für den Parkstatus.
- Zahlungsänderungen: Prüfen Sie Objektklasse, Tabellenname, Feldnamen und Wertedarstellung für BSEG-ZLSPR und BSEG-ZTERM in den Änderungsbelegen. Speicherung und Feldbenennung müssen im Zielsystem verifiziert werden.
- Zahlungsprogramm: Prüfen Sie die REGUH- und REGUP-Felder für Status von Vorschlag und Ausführung, Laufdatum, Laufkennung und Verknüpfung zum Buchhaltungsbeleg. Die lokale Konfiguration des Zahlungsprogramms kann sich auf die verfügbaren Statuswerte auswirken.
- Leistung: Begrenzen Sie Datumsbereich und Buchungskreise, wählen Sie nur erforderliche Spalten aus und wenden Sie quellenspezifische Filter vor den Verknüpfungen an. Bei großen Datenmengen können Sie gefilterte Quellmengen materialisieren oder eine freigegebene HANA Calculation View beziehungsweise ein Extraktionsschema verwenden.
- Berechtigungen: Erforderlich sind Leseberechtigungen für die relevanten SAP-HANA-Schemaobjekte und alle Views, die Buchhaltungs-, Zahlungsprogramm- und Änderungsbelegdaten bereitstellen. Stimmen Sie sich mit den SAP-Sicherheits- und Data-Governance-Teams ab.
- Fachliche Voraussetzungen: Die relevanten Funktionen für Finanzbuchhaltung, Kreditorenbuchhaltung, Zahlungsprogramm und Änderungsbelege müssen aktiv und mit Daten befüllt sein. Wird eine Quelltabelle in der Implementierung nicht verwendet, konfigurieren Sie einen freigegebenen Ersatz auf Grundlage des Systemdesigns.
- Umgang mit Timestamps: BKPF und BSEG enthalten Datum und Uhrzeit üblicherweise in getrennten Feldern. Die Abfrage führt diese zu einem Timestamp zusammen. Prüfen Sie die Zeitzone des Quellsystems und nehmen Sie vor dem Upload in ProcessMind die erforderliche Umrechnung vor.
- Datenschutz: Begrenzen Sie Lieferanten- und Buchhaltungsdaten auf den freigegebenen Umfang und wenden Sie die Aufbewahrungs-, Maskierungs- und Zugriffsrichtlinien Ihres Unternehmens an.
a Beispielabfrage sql
WITH
params AS (
SELECT
TO_DATE('[Start date]', 'YYYYMMDD') AS start_date,
TO_DATE('[End date]', 'YYYYMMDD') AS end_date,
'[Source system identifier]' AS source_system
FROM DUMMY
),
base_bkpf AS (
SELECT
b.MANDT,
b.BUKRS,
b.BELNR,
b.GJAHR,
b.BLART,
b.BLDAT,
b.BUDAT,
b.CPUDT,
b.CPUTM,
b.USNAM,
b.STBLG,
b.STJAH,
b.XBLNR,
b.WAERS,
b.BKTXT,
p.source_system,
p.start_date,
p.end_date
FROM [Your SAP HANA schema].BKPF b
CROSS JOIN params p
WHERE b.BUDAT BETWEEN TO_VARCHAR(p.start_date, 'YYYYMMDD') AND TO_VARCHAR(p.end_date, 'YYYYMMDD')
AND [Company code filter]
),
invoice_bseg AS (
SELECT
k.MANDT,
k.BUKRS,
k.BELNR,
k.GJAHR,
k.BLART,
k.BLDAT,
k.BUDAT,
k.CPUDT,
k.CPUTM,
k.USNAM,
k.STBLG,
k.STJAH,
k.XBLNR,
k.WAERS,
k.BKTXT,
k.source_system,
s.BUZEI,
s.LIFNR,
s.WRBTR,
s.DMBTR,
s.ZTERM,
s.ZLSPR,
s.ZFBDT,
s.ZBD1T,
s.ZBD2T,
s.ZBD3T,
s.AUGDT,
s.AUGBL,
s.SHKZG,
s.SGTXT,
s.XREF1,
s.XREF2,
s.XREF3
FROM base_bkpf k
INNER JOIN [Your SAP HANA schema].BSEG s
ON s.MANDT = k.MANDT
AND s.BUKRS = k.BUKRS
AND s.BELNR = k.BELNR
AND s.GJAHR = k.GJAHR
WHERE s.LIFNR IS NOT NULL
AND s.LIFNR <> ''
),
acdoca_invoice AS (
SELECT
a.RCLNT AS MANDT,
a.RBUKRS AS BUKRS,
a.BELNR,
a.GJAHR,
a.BUZEI,
a.RACCT,
a.HSL,
a.WSL,
a.RWCUR,
a.BUDAT,
a.BLDAT,
a.AUGDT,
a.AUGBL
FROM [Your SAP HANA schema].ACDOCA a
WHERE a.BUDAT BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [ACDOCA company code filter]
),
invoice_cases AS (
SELECT DISTINCT
i.MANDT,
i.BUKRS,
i.BELNR,
i.GJAHR,
i.BUZEI,
i.LIFNR,
i.WRBTR,
i.ZTERM,
i.ZLSPR,
i.ZFBDT,
i.ZBD1T,
i.ZBD2T,
i.ZBD3T,
i.AUGDT,
i.AUGBL,
i.BLART,
i.BLDAT,
i.BUDAT,
i.CPUDT,
i.CPUTM,
i.USNAM,
i.STBLG,
i.STJAH,
i.XBLNR,
i.WAERS,
i.source_system,
COALESCE(NULLIF(i.XBLNR, ''), i.BELNR) AS InvoiceNumber,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD3T, '')), 0)) AS NetDueDate,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD1T, '')), 0)) AS DiscountDueDate1,
ADD_DAYS(TO_DATE(COALESCE(NULLIF(i.ZFBDT, ''), i.BLDAT), 'YYYYMMDD'), COALESCE(TO_INTEGER(NULLIF(i.ZBD2T, '')), 0)) AS DiscountDueDate2
FROM invoice_bseg i
LEFT JOIN acdoca_invoice a
ON a.MANDT = i.MANDT
AND a.BUKRS = i.BUKRS
AND a.BELNR = i.BELNR
AND a.GJAHR = i.GJAHR
AND a.BUZEI = i.BUZEI
),
change_events AS (
SELECT
c.MANDT,
c.OBJECTID,
c.TABKEY,
c.FNAME,
c.VALUE_OLD,
c.VALUE_NEW,
c.UDATE,
c.UTIME,
c.USERNAME
FROM [Your SAP HANA schema].[Your change document item table name] c
WHERE c.TABNAME = 'BSEG'
AND c.FNAME IN ('ZLSPR', 'ZTERM')
AND c.UDATE BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
AND [Change document object class filter]
),
reguh_events AS (
SELECT
r.MANDT,
r.LAUFD,
r.LAUFI,
r.XVORL,
r.ZBUKR,
r.LIFNR,
r.VBLNR,
r.AUSFD,
r.AUSDT,
r.LAUFD AS RunDate,
r.ZALDT,
r.RZAWE,
r.XEINZ,
r.XPGRO,
r.XAVIS,
r.XVORL AS ProposalIndicator
FROM [Your SAP HANA schema].REGUH r
WHERE r.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
regup_events AS (
SELECT
u.MANDT,
u.LAUFD,
u.LAUFI,
u.ZBUKR,
u.LIFNR,
u.VBLNR,
u.BUKRS,
u.BELNR,
u.GJAHR,
u.BUZEI,
u.XVORL,
u.AUGBL,
u.AUGDT
FROM [Your SAP HANA schema].REGUP u
WHERE u.LAUFD BETWEEN TO_VARCHAR((SELECT start_date FROM params), 'YYYYMMDD')
AND TO_VARCHAR((SELECT end_date FROM params), 'YYYYMMDD')
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Parked' AS Activity,
TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
i.source_system AS SourceSystem,
CURRENT_TIMESTAMP AS LastDataUpdate,
i.LIFNR AS VendorNumber,
i.BUKRS AS CompanyCode,
i.WRBTR AS InvoiceAmount,
i.BLART AS DocumentType,
i.ZTERM AS PaymentTerms,
i.ZLSPR AS PaymentBlockReason,
i.USNAM AS UserName,
i.AUGDT AS ClearingDate,
i.NetDueDate,
CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END AS IsLatePayment,
FALSE AS IsTouchless
FROM invoice_cases i
INNER JOIN [Your SAP HANA schema].VBKPF v
ON v.MANDT = i.MANDT
AND v.BUKRS = i.BUKRS
AND v.BELNR = i.BELNR
AND v.GJAHR = i.GJAHR
WHERE [VBKPF parked status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Posted', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Applied', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_NEW, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') = '' AND COALESCE(c.VALUE_NEW, '') <> ''
UNION ALL
SELECT i.InvoiceNumber, 'Price Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'R'
UNION ALL
SELECT i.InvoiceNumber, 'Quantity Variance Detected', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.ZLSPR = 'M'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Terms Changed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, c.VALUE_NEW, i.ZLSPR, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZTERM'
UNION ALL
SELECT i.InvoiceNumber, 'Payment Block Removed', TO_TIMESTAMP(c.UDATE || LPAD(COALESCE(c.UTIME, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, c.VALUE_OLD, c.USERNAME, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN change_events c ON c.OBJECTID = i.BELNR AND c.FNAME = 'ZLSPR' AND COALESCE(c.VALUE_OLD, '') <> '' AND COALESCE(c.VALUE_NEW, '') = ''
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Due', TO_TIMESTAMP(TO_VARCHAR(i.NetDueDate, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.NetDueDate IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Cash Discount Lost', TO_TIMESTAMP(TO_VARCHAR(CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END, 'YYYYMMDD') || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NULL OR i.AUGDT > CASE WHEN i.DiscountDueDate1 <= i.DiscountDueDate2 THEN i.DiscountDueDate1 ELSE i.DiscountDueDate2 END
UNION ALL
SELECT i.InvoiceNumber, 'Payment Proposal Created', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment proposal status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Run Executed', TO_TIMESTAMP(r.RunDate || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN regup_events u ON u.BUKRS = i.BUKRS AND u.BELNR = i.BELNR AND u.GJAHR = i.GJAHR AND u.BUZEI = i.BUZEI INNER JOIN reguh_events r ON r.MANDT = u.MANDT AND r.LAUFD = u.LAUFD AND r.LAUFI = u.LAUFI AND r.LIFNR = u.LIFNR WHERE [Payment run executed status predicate]
UNION ALL
SELECT i.InvoiceNumber, 'Payment Document Created', TO_TIMESTAMP(p.CPUDT || LPAD(COALESCE(p.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, p.BLART, i.ZTERM, i.ZLSPR, p.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i INNER JOIN [Your SAP HANA schema].BKPF p ON p.MANDT = i.MANDT AND p.BUKRS = i.BUKRS AND p.BELNR = i.AUGBL AND p.GJAHR = i.GJAHR WHERE p.BLART IN ('ZP', 'KZ')
UNION ALL
SELECT i.InvoiceNumber, 'Payment Cleared', TO_TIMESTAMP(i.AUGDT || '000000', 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.AUGDT IS NOT NULL
UNION ALL
SELECT i.InvoiceNumber, 'Invoice Reversed', TO_TIMESTAMP(i.CPUDT || LPAD(COALESCE(i.CPUTM, '000000'), 6, '0'), 'YYYYMMDDHH24MISS'), i.source_system, CURRENT_TIMESTAMP, i.LIFNR, i.BUKRS, i.WRBTR, i.BLART, i.ZTERM, i.ZLSPR, i.USNAM, i.AUGDT, i.NetDueDate, CASE WHEN i.AUGDT IS NOT NULL AND i.AUGDT > i.NetDueDate THEN TRUE ELSE FALSE END, FALSE
FROM invoice_cases i WHERE i.STBLG IS NOT NULL AND i.STBLG <> ''
)
SELECT
InvoiceNumber,
Activity,
EventTime,
SourceSystem,
LastDataUpdate,
VendorNumber,
CompanyCode,
InvoiceAmount,
DocumentType,
PaymentTerms,
PaymentBlockReason,
UserName,
ClearingDate,
NetDueDate,
IsLatePayment,
IsTouchless
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, Activity; Möchten Sie loslegen?
Wandeln Sie Ihre Finanzdaten in konkrete Erkenntnisse um und optimieren Sie noch heute Ihre Zahlungszyklen. Unser Team unterstützt Sie bei jedem Schritt Ihrer Process-Mining-Reise.
Kreditorenzahlungsabwicklung in SAP S/4HANA optimieren
Beseitigen Sie Engpässe und verkürzen Sie Ihre Durchlaufzeit um 30 %.
Keine Kreditkarte erforderlich. In 5 Minuten eingerichtet.