Ihre Datenvorlage für die Kreditorenbuchhaltung
Ihre Datenvorlage für die Kreditorenbuchhaltung
- Kernattribute für Lieferanten- und Zahlungsanalysen
- Wesentliche Prozessmeilensteine für den Zahlungszyklus
- Spezialisierte Extraktionslogik für SAP S/4HANA-Systeme
Attribute der Kreditorenbuchhaltung Zahlungsabwicklung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivität Activity | Die spezifische Aufgabe oder Event-Statusänderung, die für die Rechnung erfasst wurde. | ||
| Beschreibung Dieses Attribut repräsentiert die einzelnen Prozessschritte, die während des Lebenszyklus der Rechnung auftreten. Es erfasst Events wie Rechnungserstellung, Buchung, Sperrung, Genehmigung und Zahlungsausgleich. Die Aktivitätsnamen werden von Transaktionscodes, Änderungsbelegeinträgen oder Workflow-Statusaktualisierungen im Quellsystem abgeleitet. Für die Analyse ist dieses Feld entscheidend für die Abbildung der Prozessvarianten. Es ermöglicht der Process Mining Engine, die Abfolge der Schritte zu visualisieren, Nacharbeitsschleifen zu identifizieren und festzustellen, wo der Prozess vom Standardpfad abweicht. Es ist die Kernkomponente des Event Logs. Bedeutung Es definiert die Knoten in der Prozesslandkarte und ermöglicht die Visualisierung von Workflow und Engpässen. Datenquelle Abgeleitet aus Transaktionscodes (TCODE) oder Änderungsbelegkopf (CDHDR) und -position (CDPOS) Beispiele Rechnung gebuchtZahlungssperre angewendetZahlungslauf ausgeführtRechnung ausgeglichen | |||
| Ereigniszeit EventTime | Der genaue Timestamp, wann die Aktivität stattfand. | ||
| Beschreibung Die Event Time erfasst das spezifische Datum und die Uhrzeit, wann eine Aktivität in die SAP-Datenbank übertragen wurde. Sie liefert die temporale Dimension, die notwendig ist, um Events innerhalb eines Case sequenziell zu ordnen. Dieser Timestamp wird üblicherweise durch die Kombination der Felder CPU Date und CPU Time aus den Systemprotokollen oder Belegköpfen gebildet. In der Analyse ist dieses Attribut essenziell für die Berechnung von Zykluszeiten, Dauer und Durchsatz. Es ermöglicht die Messung von Zeitlücken zwischen Schritten, wie der Zeit zwischen Rechnungseingang und finaler Freigabe, was entscheidend für die Identifizierung von Bottlenecks und die Bewertung der KPI-Leistung wie der durchschnittlichen Rechnungsfreigabezeit ist. Bedeutung Es liefert die chronologische Reihenfolge der Events und ist die Grundlage für alle zeitbasierten Performance-Berechnungen. Datenquelle SAP-Tabelle BKPF Feld 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 für die in Bearbeitung befindliche Lieferantenrechnung. | ||
| Beschreibung Die Rechnungsnummer ist der Primärschlüssel zur Verfolgung des Lebenszyklus eines Verbindlichkeitenpostens im SAP S/4HANA System. Sie bezieht sich speziell auf die Buchungsbelegnummer, die bei der Buchung der Rechnung im Hauptbuch generiert wird. In der Standard-SAP-Terminologie entspricht dies der Belegnummer (BELNR), die innerhalb eines spezifischen Buchungskreises und Geschäftsjahres zu finden ist. In der Prozessanalyse dient dieses Attribut als Case ID. Es verknüpft alle unterschiedlichen Aktivitäten – vom ersten Eingang und Parken der Rechnung über verschiedene Genehmigungssperren und Modifikationen bis zur endgültigen Ausgleichszahlung. Das Gruppieren von Events nach diesem Identifier ermöglicht es Analysten, die vollständige End-to-End-Historie jeder Zahlungsverpflichtung zu rekonstruieren. Bedeutung Es dient als definitive Case ID und ermöglicht die End-to-End-Rekonstruktion des Zahlungsprozessflusses. Datenquelle SAP-Tabelle BKPF (Belegkopf) Feld BELNR oder ACDOCA Feld BELNR Beispiele 1900000523510000289119000006015100003002 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann der Datensatz zuletzt extrahiert oder aktualisiert wurde. | ||
| Beschreibung Die letzte Datenaktualisierung markiert den Zeitpunkt, zu dem die Daten erfolgreich in die Process Mining Plattform geladen wurden. Sie spiegelt nicht den Zeitpunkt des Geschäftsereignisses wider, sondern die Aktualität des Datensatzes selbst. Dies ist entscheidend, um das Vertrauen in die Analytics-Dashboards zu erhalten. In der Analyse hilft dieses Attribut den Benutzern, die Aktualität der angezeigten Informationen zu verstehen. Dies ist besonders wichtig bei der Überwachung von nahezu Echtzeit-Dashboards wie der Zahlungssperrenanalyse, um sicherzustellen, dass Entscheidungen auf dem aktuellsten Stand des SAP S/4HANA-Systems getroffen werden. Bedeutung Es informiert Benutzer über die Datenaktualität, entscheidend für operative Dashboards. Datenquelle Generiert durch den ETL-/Extraktionsprozess Beispiele 2023-10-27T23:59:59.000Z2023-11-01T06:00:00.000Z | |||
| Quellsystem SourceSystem | Der Identifier der SAP S/4HANA Instanz, aus der die Daten stammen. | ||
| Beschreibung Dieses Attribut identifiziert die spezifische ERP-Installation oder den Client, aus dem die Prozessdaten extrahiert wurden. In Systemlandschaften mit mehreren SAP-Instanzen oder parallellaufenden Altsystemen stellt dieses Feld sicher, dass die Datenherkunft gewahrt bleibt und ermöglicht systemübergreifende Vergleiche. Für die Analyse dient dieses Feld als übergeordneter Filter. Es hilft Analysten, Daten bei der Leistungsbewertung verschiedener regionaler Systeminstallationen oder bei der Validierung der Datenkonsistenz während Systemmigrationsprojekten zu trennen. Es stellt sicher, dass alle Prozessabweichungen, die auf die Systemkonfiguration zurückzuführen sind, korrekt kontextualisiert werden. Bedeutung Es unterscheidet Datenquellen in Multi-System-Umgebungen und gewährleistet eine genaue Segmentierung. Datenquelle 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 Clearing-Datum erfasst, wann der offene Posten im Kreditorenbuchhaltungskonto ausgeglichen wurde, typischerweise durch einen Zahlungslauf oder eine manuelle Zahlungsbuchung. Dies markiert effektiv das Ende der Verbindlichkeit. In der Analyse wird dieses Attribut verwendet, um die endgültige Zykluszeit des Prozesses zu berechnen. Es ist der Timestamp, der für die Aktivität 'Zahlung ausgeglichen' verwendet und mit dem Netto-Fälligkeitsdatum verglichen wird, um die Pünktlichkeit der Zahlungen zu bestimmen. Es fließt direkt in das Dashboard zur Effizienz der Zahlungsverbuchung ein. Bedeutung Es markiert den Abschluss des Zahlungsprozesses und wird verwendet, um die Pünktlichkeit der Zahlung zu bestimmen. Datenquelle SAP-Tabelle BSEG oder AUGDT Feld AUGDT Beispiele 2023-11-012023-11-15 | |||
| Benutzername UserName | Die ID des Benutzers, der die spezifische Aktivität ausgeführt hat. | ||
| Beschreibung Der Benutzername erfasst die Login-ID der Person oder des Systemagenten, die für die Ausführung eines Prozessschritts verantwortlich ist. Dies könnte ein manueller Benutzer sein, der Daten eingibt, oder eine Hintergrundjob-ID (z.B. 'BATCH_USER'), die automatisierte Aufgaben ausführt. In der Analyse ermöglicht dieses Attribut die Berechnung der Aktivitätsautomatisierungsrate. Indem zwischen menschlichen Benutzern und Systemkonten unterschieden wird, können Analysten den Automatisierungsgrad im Prozess messen. Es wird auch im Dashboard 'Manuelle Kontaktpunktverteilung' verwendet, um die Arbeitslast über Teams hinweg zu bewerten. Bedeutung Es unterscheidet zwischen manueller und automatisierter Arbeit und ermöglicht die Berechnung von Automatisierungsraten. Datenquelle SAP-Tabelle BKPF Feld USNAM oder CDHDR Feld USERNAME Beispiele BSMITHWF-BATCHRJONES | |||
| Buchungskreis CompanyCode | Die Organisationseinheit, für die die Bilanz und die Gewinn- und Verlustrechnung erstellt werden. | ||
| Beschreibung Der Buchungskreis repräsentiert die unabhängige Rechnungswesen-Einheit innerhalb des Unternehmens. Er ist die zentrale Organisationseinheit in der externen Rechnungslegung und dient zur Strukturierung der Finanzdaten. Jede Rechnung wird genau einem Buchungskreis zugeordnet. In der Analyse ermöglicht dieses Attribut die Segmentierung von KPIs nach juristischer Einheit oder Region. Es wird in Dashboards verwendet, um die Effizienz von Kreditorenbuchhaltungsteams in verschiedenen Tochtergesellschaften zu vergleichen. Zum Beispiel hilft es zu identifizieren, ob eine bestimmte Niederlassung eine höhere Rate an manuellen Zahlungssperren im Vergleich zum Unternehmensstandard aufweist. Bedeutung Es segmentiert den Prozess nach juristischer Einheit und erleichtert so das interne Benchmarking. Datenquelle SAP-Tabelle BKPF Feld BUKRS Beispiele US01DE1010002000 | |||
| Dokumententyp DocumentType | Klassifiziert den Buchhaltungsbeleg (z.B. Lieferantenrechnung, Zahlung, Gutschrift). | ||
| Beschreibung Die Belegart ist ein zweistelliger Code in SAP, der die Buchungstransaktion klassifiziert. Gängige Typen sind 'KR' für Kreditorenrechnungen, 'KZ' für Kreditorenzahlungen und 'RE' für Rechnungszugang Brutto. Sie bestimmt den Nummernkreis und den Feldstatus des Belegs. In der Analyse wird dieses Attribut verwendet, um den Prozessumfang zu filtern. Zum Beispiel möchte ein Analyst möglicherweise Gutschriften ausschließen, um sich ausschließlich auf die Effizienz ausgehender Zahlungen zu konzentrieren. Es hilft auch, die Mischung der verarbeiteten Transaktionstypen zu identifizieren und unterstützt das Dashboard zur Prozessvariantenkomplexität. Bedeutung Es kategorisiert den Case (Rechnung vs. Gutschrift) und ermöglicht eine gefilterte Analyse. Datenquelle SAP-Tabelle BKPF Feld BLART Beispiele KRREKZKG | |||
| Grund der Zahlungssperre PaymentBlockReason | Der Code, der angibt, warum eine Rechnung für die Zahlung gesperrt ist. | ||
| Beschreibung Dieses Attribut enthält den spezifischen Grundcode, der einer Rechnung zugewiesen wird und verhindert, dass der automatische Zahlungslauf sie aufgreift. Beispiele sind 'A' für zur Zahlung gesperrt, 'R' für Rechnungsprüfung oder manuelle Sperren, die von Benutzern gesetzt wurden. In der Analyse ist dieses Feld der primäre Treiber für das Dashboard 'Analyse manueller Zahlungssperren'. Durch die Aggregation der Häufigkeit verschiedener Sperrgründe kann das Unternehmen systemische Probleme diagnostizieren, wie häufige Preisabweichungen oder fehlende Wareneingänge, die den Zahlungsprozess verzögern. Bedeutung Es identifiziert die spezifische Ursache von Prozessstopps und ermöglicht eine gezielte Ursachenanalyse. Datenquelle SAP-Tabelle BSEG Feld ZLSPR Beispiele ABR* | |||
| Ist Touchless IsTouchless | Ein boolesches Flag, das anzeigt, ob die Rechnung ohne manuelle Intervention verarbeitet wurde. | ||
| Beschreibung Dieses Attribut wird durch die Analyse des Event Stream für einen Case berechnet. Wenn der Case nur automatisierte Aktivitäten (z.B. 'System'-Benutzer, spezifische Hintergrund-TCODES) und keine manuellen Änderungen oder Sperren enthält, wird er als 'Touchless' gekennzeichnet. In der Analyse ist dies die Kernmetrik für den KPI 'Touchless Invoice Rate'. Es ermöglicht dem Unternehmen, den Erfolg von Automatisierungsinitiativen zu verfolgen und zu identifizieren, welche Case-Typen (z.B. nach Lieferant oder Region) erfolgreich und ohne menschliche Eingriffe durch das System laufen. Bedeutung Es ist das primäre Maß für Prozessautomatisierung und -effizienz. Datenquelle Berechnet basierend auf der Abfolge von Aktivitäten und Benutzertypen Beispiele truefalsch | |||
| Ist verspätete Zahlung IsLatePayment | Ein boolesches Flag, das anzeigt, ob die Zahlung nach dem Nettofälligkeitsdatum erfolgte. | ||
| Beschreibung Dieses berechnete Attribut ist 'wahr', wenn das Clearing-Datum streng nach dem Netto-Fälligkeitsdatum liegt. Es dient als binärer Klassifikator für die Prozessleistung. In der Analyse wird dieses Flag verwendet, um die Anzahl der nicht konformen Cases für den KPI 'Häufigkeit der Verzugsstrafe' zu zählen. Es vereinfacht die Dashboard-Erstellung, indem es eine einfache Zählung von 'Wahr'-Werten ermöglicht, anstatt komplexe Datumsberechnungen in der Visualisierungsschicht zu erfordern. Bedeutung Es vereinfacht die Berechnung von KPIs für die pünktliche Leistung. Datenquelle Berechnet: Ausgleichsdatum > Nettofälligkeitsdatum Beispiele truefalsch | |||
| Lieferantennummer VendorNumber | Die eindeutige Kennung für den Lieferanten, der mit der Rechnung verknüpft ist. | ||
| Beschreibung Die Lieferantennummer entspricht dem spezifischen Kreditorenkonto im SAP-Nebenbuch. Sie verknüpft die Rechnung mit den Stammdaten, die Zahlungsbedingungen, Bankverbindungen und Kontaktinformationen enthalten. In S/4HANA ist dies oft mit dem Business Partner Konzept verknüpft, behält aber in vielen Tabellen den ursprünglichen Feldnamen LIFNR bei. In der Analyse ist dieses Attribut grundlegend für das Dashboard zur Einhaltung der Lieferantenzahlungsbedingungen (Vendor Payment Term Compliance). Es ermöglicht Analysten, die Prozessleistung nach Lieferant zu aggregieren und spezifische Lieferanten zu identifizieren, die konsistent Sperren, Preisabweichungen oder Verzögerungen verursachen. Es unterstützt strategische Beschaffungsentscheidungen und das Lieferantenbeziehungsmanagement. Bedeutung Es ermöglicht die Leistungsaggregation nach Lieferanten, entscheidend für die Identifizierung von Ursachen für Verzögerungen. Datenquelle 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 Strafen zu vermeiden. | ||
| Beschreibung Das Netto-Fälligkeitsdatum ist die endgültige Frist für die Zahlung. Es wird berechnet, indem die maximalen Zahlungsziele zum Basisdatum addiert werden. Obwohl es manchmal explizit gespeichert ist, ist es in Analyseansichten oft ein berechnetes Feld. In der Analyse ist dies der primäre Maßstab für den Tracker für verspätete Zahlungen und Strafen. Der Vergleich des tatsächlichen Clearing-Datums mit dem Netto-Fälligkeitsdatum generiert die Metrik 'Tage zu spät bezahlt', die hilft, die Effizienz des AP-Teams und das Risiko von Lieferantenkonflikten zu quantifizieren. Bedeutung Es ist die Zieldaten für den Prozess; deren Verpassen wirkt sich auf die Kreditwürdigkeit aus und verursacht Kosten. Datenquelle Berechnet: Basisdatum + Max. Zahlungszieltage (ZBD1T/ZBD2T/ZBD3T) Beispiele 2023-11-302023-12-01 | |||
| Rechnungsbetrag InvoiceAmount | Der gesamte Bruttobetrag der Rechnung in der Belegwährung. | ||
| Beschreibung Dieses Attribut spiegelt den finanziellen Wert der Rechnung wider, wie er im Quelldokument erfasst ist. Es stellt die Verbindlichkeit dar, die gegenüber dem Lieferanten beglichen werden muss. In SAP S/4HANA wird dies typischerweise im Feld 'Betrag in Belegwährung' gespeichert. In der Analyse wird der Rechnungsbetrag verwendet, um die Arbeit zu priorisieren. Dashboards wie die 'Manuelle Kontaktpunktverteilung' nutzen dieses Feld, um hervorzuheben, ob manuelle Aktivitäten mit hohem Aufwand für Rechnungen mit geringem Wert verschwendet werden. Es ermöglicht dem Unternehmen, Optimierungsbemühungen auf Transaktionen mit hohem Wert zu konzentrieren, bei denen Prozessfehler ein größeres finanzielles Risiko bergen. Bedeutung Es liefert das finanzielle Gewicht des Cases, unerlässlich für die Priorisierung hochwertiger Prozesseffizienzdefizite. Datenquelle SAP-Tabelle BKPF oder BSEG Feld WRBTR Beispiele 1500.00250.5010000.00 | |||
| Zahlungsbedingungen PaymentTerms | Der Schlüssel, der die vereinbarten Zahlungs- und Skontobedingungen darstellt. | ||
| Beschreibung Zahlungsbedingungen legen fest, wann eine Rechnung fällig ist und ob Skonti für eine vorzeitige Zahlung gewährt werden. Dieser Code (z.B. 'Z001') entspricht Regeln wie 'Netto 30' oder '2% 10, Netto 30'. Er wird aus den Lieferantenstammdaten in die Rechnung kopiert, kann aber manuell geändert werden. In der Analyse ist dieses Attribut zentral für den Early Payment Discount Optimizer und die Dashboards zur Einhaltung der Lieferantenzahlungsbedingungen (Vendor Payment Term Compliance). Es ermöglicht dem System, das grundlegende Fälligkeitsdatum zu berechnen und festzustellen, ob die Zahlung innerhalb des optimalen Zeitfensters erfolgte, um Einsparungen zu erzielen. Bedeutung Es diktiert den erwarteten Zeitplan und die finanziellen Anreize, entscheidend für die Skontoanalyse. Datenquelle SAP-Tabelle BSEG Feld ZTERM Beispiele Z001NT300001 | |||
| Basisdatum BaselineDate | Das Datum, ab dem Zahlungsbedingungen gelten und Fälligkeitsdaten berechnet werden. | ||
| Beschreibung Das Basisdatum ist der Ausgangspunkt für die Berechnung des Netto-Fälligkeitsdatums und der Skontofristen. Es ist in der Regel das Rechnungsdatum oder das Buchungsdatum, abhängig von der Konfiguration und den Lieferantenstammdaten. In der Analyse ist dieses Datum eine technische Voraussetzung für die Berechnung des Status 'Zu spät'. Fehler im Basisdatum führen oft zu vorzeitigen Zahlungen (Cashflow-Auswirkungen) oder verspäteten Zahlungen (Strafzahlungen). Die Überprüfung der Richtigkeit dieses Datums ist Teil der Analyse zur Einhaltung der Lieferantenzahlungsbedingungen (Vendor Payment Term Compliance). Bedeutung Es ist der Ankerpunkt für alle Fälligkeitsberechnungen. Datenquelle SAP-Tabelle BSEG Feld ZFBDT Beispiele 2023-10-012023-10-15 | |||
| Einkaufsdokument PurchasingDocument | Die Bestellnummer, die mit der Rechnung verknüpft ist. | ||
| Beschreibung Dieses Attribut verknüpft die Rechnung mit dem vorgelagerten Beschaffungsprozess. Es enthält die Bestellnummer (PO), gegen die die Rechnung abgeglichen wird. Nicht alle Rechnungen (z.B. sonstige Ausgaben) werden eine PO-Referenz haben. In der Analyse ist dieses Feld entscheidend für die Drei-Wege-Abgleichratenanalyse. Es ermöglicht Analysten, PO-gestützte Rechnungen von Nicht-PO-Rechnungen zu trennen, die typischerweise sehr unterschiedliche Genehmigungs-Workflows haben. Es erleichtert auch das End-to-End Process Mining durch die Verknüpfung von Kreditorenbuchhaltungsdaten mit Beschaffungsdaten. Bedeutung Es verbindet die Kreditorenbuchhaltung mit dem Einkauf und ermöglicht eine 3-Wege-Abgleichsanalyse und Prozesserweiterung. Datenquelle SAP-Tabelle BSEG Feld EBELN Beispiele 45000012344500009876 | |||
| Geschäftsjahr FiscalYear | Das Geschäftsjahr, zu dem die Rechnung gehört. | ||
| Beschreibung Das Geschäftsjahr ist ein Zeitraum, der für die Finanzberichterstattung verwendet wird. Zusammen mit dem Buchungskreis und der Belegnummer bildet es den zusammengesetzten Primärschlüssel für ein Finanzdokument in SAP. In der Analyse ist dies eine technische Notwendigkeit zur eindeutigen Identifizierung von Cases, unterstützt aber auch die Jahresvergleichsberichterstattung. Es stellt sicher, dass die 'Rechnungsnummer' als Case ID über Jahrzehnte der Datenhistorie hinweg eindeutig bleibt. Bedeutung Technische Anforderung für die eindeutige Case-Identifikation in SAP FI. Datenquelle SAP-Tabelle BKPF Feld GJAHR Beispiele 20232024 | |||
| Skontoprozentsatz 1 CashDiscountPercentage1 | Der Skontoprozentsatz, der bei Zahlung innerhalb der ersten Skontofrist verfügbar ist. | ||
| Beschreibung Dieses Attribut repräsentiert den finanziellen Anreizsatz, den der Lieferant für eine frühzeitige Zahlung anbietet (z.B. '2' in '2% 10'). In der Analyse wird dies verwendet, um den Wert des 'Potenziellen Skontos' zu berechnen. Indem dieser Prozentsatz mit dem Rechnungsbetrag multipliziert wird, können die Dashboards den Gesamtbetrag visualisieren, der aufgrund von Prozessineffizienzen ungenutzt bleibt, und somit den Business Case für die Automatisierung unterstützen. Bedeutung Es quantifiziert die potenzielle Einsparungsrate, entscheidend für ROI-Berechnungen. Datenquelle 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 definiert das Zeitfenster für die günstigsten Zahlungsbedingungen (z.B. '10' in '2% 10, Netto 30'). Es stammt aus den in der Rechnungszeile gespeicherten Konditionen. In der Analyse hilft dies, das 'Zieldatum' für den Early Payment Discount Optimizer zu bestimmen. Wenn die Rechnung innerhalb dieses Zeitfensters ausgeglichen wird, wird der Skonto realisiert. Dieses Feld hilft, die Opportunitätskosten langsamer Bearbeitungszyklen zu messen. Bedeutung Es definiert das Zeitfenster für finanzielle Einsparungen. Datenquelle SAP-Tabelle BSEG Feld ZBD1T Beispiele 10140 | |||
| Verlorener Skontobetrag DiscountLostAmount | Der Geldwert der verfügbaren, aber nicht genutzten Skonti. | ||
| Beschreibung Dieses berechnete Attribut repräsentiert das 'ungenutzte Sparpotenzial'. Es wird abgeleitet, indem geprüft wird, ob die Zahlung nach der Skontofrist erfolgte, und, falls ja, der Wert des entgangenen Skontos, bezogen auf den Rechnungsbetrag, berechnet wird. In der Analyse ist dies eine kritische Finanzmetrik für den Early Payment Discount Optimizer. Es quantifiziert die Kosten der Ineffizienz in harter Währung und liefert einen überzeugenden Business Case für Prozessverbesserungen. Bedeutung Es quantifiziert den direkten finanziellen Verlust aufgrund von Prozessverzögerungen. Datenquelle Berechnet: Wenn Ausgleichsdatum > Skontodatum, dann Rechnungsbetrag * Skontoprozentsatz Beispiele 30.000.00150.00 | |||
| Währung Currency | Der Währungscode, der mit dem Rechnungsbetrag verknüpft ist. | ||
| Beschreibung Das Attribut Währung gibt die Denomination des Rechnungsbetrags an, wie USD, EUR oder GBP. Es ermöglicht die korrekte Interpretation finanzieller Werte und ist unerlässlich beim Aggregieren von Daten über internationale Buchungskreise hinweg. In der Analyse stellt dieses Feld sicher, dass finanzielle KPIs korrekt berechnet werden. Es wird oft verwendet, um Werte für globale Dashboards in eine Berichtswährung zu normalisieren. Ohne dieses Attribut wären aggregierte Metriken wie Gesamtausgaben oder durchschnittlicher Rechnungsbetrag in einem Multi-Währungs-Umfeld bedeutungslos. Bedeutung Es bietet Kontext für Finanzbeträge, unerlässlich für eine genaue globale Berichterstattung. Datenquelle SAP-Tabelle BKPF Feld WAERS Beispiele USDEURGBPJPY | |||
Aktivitäten der Kreditorenbuchhaltung Zahlungsabwicklung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Rechnung gebucht | Stellt die offizielle Erfassung der Verbindlichkeit im Hauptbuch dar. Diese Aktivität wird vom Erstellungs-Timestamp in der BKPF-Tabelle oder dem Erfassungsdatum in der ACDOCA-Tabelle abgeleitet. | ||
| Bedeutung Dies ist der primäre Startpunkt für die finanzielle Zeitlinie, der die Basis für Fälligkeitsdaten und die Altersstrukturanalyse bildet. Datenquelle Tabelle BKPF, unter Verwendung von CPUDT (Erfassungsdatum) und CPUTM (Erfassungszeit). Erfassen Protokolliert, wenn der BKPF-Datensatz erstellt wird Ereignistyp explicit | |||
| Zahlung freigegeben | Markiert die finale Abstimmung, bei der der offene Posten im Kreditorenkonto gegen die Zahlung ausgeglichen wird. Erfasst aus dem Feld AUGDT (Ausgleichsdatum) in der Tabelle BSEG. | ||
| Bedeutung Der Endzustand des Prozesses, der anzeigt, dass der Lebenszyklus abgeschlossen und die Bücher ausgeglichen sind. Hohe manuelle Verbuchungsraten weisen auf Ineffizienzen bei der Abstimmung hin. Datenquelle Tabelle BSEG, Feld AUGDT (Ausgleichsdatum). Erfassen Protokolliert, wenn das Feld AUGDT gefüllt wird Ereignistyp explicit | |||
| Zahlungsbeleg erstellt | Die Generierung des Buchhaltungsbelegs, der die Bank gutschreibt und den Lieferanten belastet. Dies ist in der BKPF mit einer Zahlungsbelegart (z.B. ZP, KZ) zu finden. | ||
| Bedeutung Die finanzielle Realisierung der Zahlung, verwendet zur Berechnung der Days Payable Outstanding (DPO). Datenquelle Tabelle BKPF, gefiltert nach Belegart (BLART) spezifisch für Zahlungen. Erfassen Protokolliert, wenn der BKPF-Zahlungsbeleg erstellt wird Ereignistyp explicit | |||
| Zahlungslauf ausgeführt | Stellt die Ausführung des Zahlungslaufs dar, bei dem Überweisungsanweisungen generiert werden. Dies wird über die Statusaktualisierung in den Tabellen REGUH oder REGUP verfolgt. | ||
| Bedeutung Die operative Verpflichtung zur Zahlung, entscheidend für die Analyse der Effizienz des Zahlungsbündelungsprozesses. Datenquelle REGUH-Tabelle, typischerweise korreliert mit dem Ausführungsdatum und der Identifikation. Erfassen Protokolliert, wenn sich der Status des Zahlungslaufs aktualisiert Ereignistyp explicit | |||
| Zahlungssperre angewendet | Zeigt an, dass eine Zahlungssperre für die Rechnungszeile gesetzt wurde, die verhindert, dass sie vom Zahlungslauf erfasst wird. Dies wird durch die Überwachung von Änderungen im Feld ZLSPR der Tabelle BSEG über Änderungsbelege erfasst. | ||
| Bedeutung Sperren sind die Hauptursache für verspätete Zahlungen und Prozessreibung, die sich direkt auf das Dashboard für die manuelle Zahlungssperrenanalyse auswirken. Datenquelle Tabellen CDPOS und CDHDR (Änderungsbelege), Suche nach Aktualisierungen des Feldes BSEG-ZLSPR. Erfassen Protokolliert, wenn sich CDPOS-Datensätze in ZLSPR ändern Ereignistyp explicit | |||
| Zahlungssperre aufgehoben | Zeigt an, dass eine zuvor angewendete Zahlungssperre aufgehoben wurde, wodurch die Rechnung effektiv zur Zahlung freigegeben wird. Dies wird identifiziert, wenn sich das Feld ZLSPR in BSEG von einem Wert zu null oder leer ändert. | ||
| Bedeutung Dient oft als Proxy für 'Rechnung genehmigt' in Systemen ohne explizite Workflow-Protokolle und markiert das Ende der Engpassperiode. Datenquelle Tabellen CDPOS und CDHDR, Suche nach Änderungen von BSEG-ZLSPR zu leer. Erfassen Protokolliert, wenn ZLSPR-Einträge in CDPOS entfernt werden Ereignistyp explicit | |||
| Mengenabweichung erkannt | Abgeleitete Aktivität, die eine Diskrepanz zwischen der fakturierten Menge und der Wareneingangsmenge anzeigt. Dies wird durch Beobachtung eines spezifischen Zahlungssperrschlüssels (typischerweise 'M' für Mengenabweichung), der auf die Position angewendet wird, abgeleitet. | ||
| Bedeutung Entscheidend für die Analyse der Abgleichseffizienz und der Datenqualität in der Lieferkette. Datenquelle Abgeleitet vom BSEG-ZLSPR-Wert 'M' (oder systemspezifischer Konfiguration für Mengenblockaden). Erfassen Vergleiche ZLSPR-Wert mit 'M' Ereignistyp inferred | |||
| Preisabweichung erkannt | Abgeleitete Aktivität, die eine Diskrepanz zwischen dem Rechnungspreis und dem Bestellpreis anzeigt. Dies wird durch Beobachtung eines spezifischen Zahlungssperrschlüssels (typischerweise 'R' für Rechnungsprüfung), der automatisch bei der Buchung angewendet wird, abgeleitet. | ||
| Bedeutung Identifiziert Ursachen für manuelle Nacharbeit und unterstützt die Analyse der Drei-Wege-Abgleichsrate. Datenquelle Abgeleitet vom BSEG-ZLSPR-Wert 'R' (oder systemspezifischer Konfiguration für Preissperren) zum Zeitpunkt der Buchung. Erfassen Vergleiche ZLSPR-Wert mit 'R' Ereignistyp inferred | |||
| Rechnung fällig | Ein berechneter Timestamp, der den Zeitpunkt darstellt, an dem die Rechnung ihr Nettofälligkeitsdatum erreichte. Dieser wird durch Hinzufügen der Zahlungszieltage zum Basisdatum in der Tabelle BSEG abgeleitet. | ||
| Bedeutung Dient als Referenzpunkt für die pünktliche Zahlungsleistung und den Verzugsgebühren-Tracker. Datenquelle Berechnet: BSEG-ZFBDT (Basisdatum) + BSEG-ZBD1T/ZBD2T/ZBD3T (Tage). Erfassen Ableiten durch Vergleich des aktuellen Datums mit dem Nettofälligkeitsdatum Ereignistyp calculated | |||
| Rechnung geparkt | Zeigt an, dass eine Rechnung in SAP erfasst, aber noch nicht ins Hauptbuch gebucht wurde, oft für die vorläufige Datenerfassung verwendet. Dies wird explizit aus der Tabelle VBKPF erfasst oder durch die Identifizierung von Belegen in BKPF mit einem geparkten Statuscode, bevor sie in den gebuchten Status übergehen. | ||
| Bedeutung Das Parken markiert den Beginn der Datenerfassungsphase und hilft, die Zeitverzögerung zwischen Rechnungseingang und finanzieller Verbindlichkeit zu messen. Datenquelle VBKPF-Tabelle für Kopfdaten geparkter Belege oder BKPF mit spezifischem Belegstatus (BSTAT = V). Erfassen Protokolliert, wenn der VBKPF-Eintrag erstellt wird Ereignistyp explicit | |||
| Rechnung storniert | Zeigt an, dass der Rechnungsbeleg storniert oder annulliert wurde. Erfasst durch Überprüfung des Feldes STBLG (Stornobeleg) in der Tabelle BKPF. | ||
| Bedeutung Stellt Nacharbeit und Prozessfehler dar, identifiziert Verschwendung und potenziellen doppelten Aufwand. Datenquelle Tabelle BKPF, Feld STBLG ist nicht leer. Erfassen Protokolliert, wenn das Feld STBLG gefüllt wird Ereignistyp explicit | |||
| Verlorener Skonto | Ein berechnetes Event, das das Datum markiert, an dem die Berechtigung für einen Skonto ablief. Abgeleitet durch den Vergleich des Skontofälligkeitsdatums mit dem aktuellen Datum oder Zahlungsdatum. | ||
| Bedeutung Unerlässlich für den Skonto-Optimierer, um verlorene finanzielle Möglichkeiten zu visualisieren. Datenquelle Berechnet: BSEG-ZFBDT + BSEG-ZBD1T (Skontotage 1). Erfassen Ableiten durch Vergleich des Datums mit dem Skontofälligkeitsdatum Ereignistyp calculated | |||
| Zahlungsbedingungen geändert | Erfasst eine Aktualisierung der Zahlungsbedingungen einer offenen Rechnung, wodurch das Fälligkeitsdatum oder die Skontoberechtigung geändert wird. Dies wird über Änderungsbelege zum Feld ZTERM in der Tabelle BSEG verfolgt. | ||
| Bedeutung Häufige Änderungen deuten auf Stammdatenfehler oder manuelle Überschreibungen hin, die die Liquiditätsprognose und die Einhaltung der Lieferanten-Zahlungsbedingungen beeinträchtigen. Datenquelle Tabellen CDPOS und CDHDR, Suche nach Aktualisierungen des Feldes BSEG-ZTERM. Erfassen Protokolliert, wenn sich CDPOS-Datensätze in ZTERM ändern Ereignistyp explicit | |||
| Zahlungsvorschlag erstellt | Zeigt an, dass die Rechnung in einen Zahlungsvorschlagslauf (F110) aufgenommen wurde, dem ersten Schritt des automatisierten Zahlprogramms. Erfasst aus der REGUH-Tabelle, die Abwicklungsdaten speichert. | ||
| Bedeutung Zeigt an, dass die Rechnung zur Zahlung ausgewählt wurde und die Validierungsprüfungen innerhalb des Zahlungsprogramms bestanden hat. Datenquelle REGUH-Tabelle Erstellungs-Timestamp (Schlüssel LAUFD und LAUFI). Erfassen Protokolliert, wenn der REGUH-Datensatz erstellt wird Ereignistyp explicit | |||
Extraktionsleitfäden
Schritte
Erforderliche CDS Views identifizieren: Bestätigen Sie die Verfügbarkeit der Standard SAP S/4HANA CDS Views. Die primär benötigten Views sind I_JournalEntry (Kopf), I_OperationalAcctgDocItem (Positionen/BSEG-Äquivalent), I_SupplierInvoice (Logistik), I_PaymentProposalItem (F110) und I_ChangeDocument (für Protokolle).
Benutzerberechtigungen konfigurieren: Stellen Sie sicher, dass der Datenbankbenutzer oder der technische Servicebenutzer SELECT-Berechtigungen für die DDL-SQL-Views besitzt, die den CDS-Entitäten zugeordnet sind. Dies wird typischerweise über SAP HANA Studio oder die ABAP Eclipse Development Tools (ADT) verwaltet.
SQL-Umgebung vorbereiten: Öffnen Sie Ihre SQL-Schnittstelle (z.B. SAP HANA Studio, DBeaver verbunden mit HANA oder einen Process Mining Konnektor, der SQL akzeptiert). Diese Methode setzt direkten SQL-Zugriff auf die HANA-Schicht voraus, wo CDS Views als Views exponiert sind.
Umfang definieren: Bestimmen Sie den Buchungskreis (CompanyCode) und den Geschäftsjahresbereich, um das Datenvolumen zu begrenzen. Dies ist entscheidend für die Performance beim Abfragen der Operational Accounting Document Item View.
Aktivitätslogik implementieren: Kopieren Sie die untenstehende SQL-Abfrage. Diese Abfrage verwendet UNION ALL, um 14 verschiedene Logikblöcke in eine einzige Event Log-Struktur zu kombinieren. Jeder Block zielt auf eine spezifische Aktivität ab (z.B. Rechnung gebucht, Zahlung ausgeglichen).
Änderungsbelege handhaben: Die Abfrage enthält Abschnitte für Änderungen der Zahlungsbedingungen und Sperrbearbeitung. Diese basieren auf der I_ChangeDocument View. Wenn diese View in Ihrer spezifischen S/4-Version nicht aktiv ist, müssen Sie möglicherweise die zugrunde liegenden Tabellen (CDHDR/CDPOS) in einer benutzerdefinierten CDS View kapseln.
Berechnete Events adressieren: Überprüfen Sie die Logik für Fällige Rechnung und Verlorener Skonto. Dies sind berechnete Events, die durch das Hinzufügen von Tagen zum Basisdatum in der operativen Positionsansicht generiert werden.
Extraktion ausführen: Führen Sie die Abfrage aus. Für große Datenmengen wird dringend empfohlen, die Extraktion nach Geschäftsjahr oder Buchungskreis zu partitionieren, um Speicherüberläufe zu vermeiden.
Datumsformate überprüfen: Stellen Sie sicher, dass die Spalte EventTime als YYYY-MM-DD HH:MM:SS formatiert ist. 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. Stellen Sie sicher, dass die Header den in der finalen SELECT-Anweisung definierten Spalten entsprechen.
Transformation für Upload: Wenn Ihr Process Mining Tool ein spezifisches CSV-Format erfordert (z.B. spezifische Datumsmaskierung), wenden Sie diese Transformationen in einem Nachbearbeitungsskript oder innerhalb des SQLs mithilfe von TO_VARCHAR-Funktionen an.
Finale Validierung: Laden Sie ein Beispiel in ProcessMind und verifizieren Sie, dass die Case ID (Rechnungsnummer) alle Aktivitäten von der Buchung bis zum Ausgleich korrekt gruppiert.
Konfiguration
- Buchungskreisfilter: Beschränken Sie die Abfrage auf spezifische Organisationseinheiten (CompanyCode = '1000'), um Kontext und Performance zu wahren.
- Datumsbereich: Wenden Sie einen Filter auf Buchungsdatum oder Erstellungsdatum an (z.B. letzte 12 Monate), um das Datenvolumen zu steuern.
- Kontentyp: Filtern Sie I_OperationalAcctgDocItem nach FinancialAccountType = 'K' (Kreditor), um Sachkonten- und Kundenpositionen 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.
- Performance des Änderungsbelegprotokolls: Das Abfragen von I_ChangeDocument kann ressourcenintensiv sein. Begrenzen Sie diese Unterabfragen nach ObjectClass 'BELEG' und spezifischen 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 NULLSchritte
Erforderliche CDS Views identifizieren: Bestätigen Sie die Verfügbarkeit der Standard SAP S/4HANA CDS Views. Die primär benötigten Views sind I_JournalEntry (Kopf), I_OperationalAcctgDocItem (Positionen/BSEG-Äquivalent), I_SupplierInvoice (Logistik), I_PaymentProposalItem (F110) und I_ChangeDocument (für Protokolle).
Benutzerberechtigungen konfigurieren: Stellen Sie sicher, dass der Datenbankbenutzer oder der technische Servicebenutzer SELECT-Berechtigungen für die DDL-SQL-Views besitzt, die den CDS-Entitäten zugeordnet sind. Dies wird typischerweise über SAP HANA Studio oder die ABAP Eclipse Development Tools (ADT) verwaltet.
SQL-Umgebung vorbereiten: Öffnen Sie Ihre SQL-Schnittstelle (z.B. SAP HANA Studio, DBeaver verbunden mit HANA oder einen Process Mining Konnektor, der SQL akzeptiert). Diese Methode setzt direkten SQL-Zugriff auf die HANA-Schicht voraus, wo CDS Views als Views exponiert sind.
Umfang definieren: Bestimmen Sie den Buchungskreis (CompanyCode) und den Geschäftsjahresbereich, um das Datenvolumen zu begrenzen. Dies ist entscheidend für die Performance beim Abfragen der Operational Accounting Document Item View.
Aktivitätslogik implementieren: Kopieren Sie die untenstehende SQL-Abfrage. Diese Abfrage verwendet UNION ALL, um 14 verschiedene Logikblöcke in eine einzige Event Log-Struktur zu kombinieren. Jeder Block zielt auf eine spezifische Aktivität ab (z.B. Rechnung gebucht, Zahlung ausgeglichen).
Änderungsbelege handhaben: Die Abfrage enthält Abschnitte für Änderungen der Zahlungsbedingungen und Sperrbearbeitung. Diese basieren auf der I_ChangeDocument View. Wenn diese View in Ihrer spezifischen S/4-Version nicht aktiv ist, müssen Sie möglicherweise die zugrunde liegenden Tabellen (CDHDR/CDPOS) in einer benutzerdefinierten CDS View kapseln.
Berechnete Events adressieren: Überprüfen Sie die Logik für Fällige Rechnung und Verlorener Skonto. Dies sind berechnete Events, die durch das Hinzufügen von Tagen zum Basisdatum in der operativen Positionsansicht generiert werden.
Extraktion ausführen: Führen Sie die Abfrage aus. Für große Datenmengen wird dringend empfohlen, die Extraktion nach Geschäftsjahr oder Buchungskreis zu partitionieren, um Speicherüberläufe zu vermeiden.
Datumsformate überprüfen: Stellen Sie sicher, dass die Spalte EventTime als YYYY-MM-DD HH:MM:SS formatiert ist. 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. Stellen Sie sicher, dass die Header den in der finalen SELECT-Anweisung definierten Spalten entsprechen.
Transformation für Upload: Wenn Ihr Process Mining Tool ein spezifisches CSV-Format erfordert (z.B. spezifische Datumsmaskierung), wenden Sie diese Transformationen in einem Nachbearbeitungsskript oder innerhalb des SQLs mithilfe von TO_VARCHAR-Funktionen an.
Finale Validierung: Laden Sie ein Beispiel in ProcessMind und verifizieren Sie, dass die Case ID (Rechnungsnummer) alle Aktivitäten von der Buchung bis zum Ausgleich korrekt gruppiert.
Konfiguration
- Buchungskreisfilter: Beschränken Sie die Abfrage auf spezifische Organisationseinheiten (CompanyCode = '1000'), um Kontext und Performance zu wahren.
- Datumsbereich: Wenden Sie einen Filter auf Buchungsdatum oder Erstellungsdatum an (z.B. letzte 12 Monate), um das Datenvolumen zu steuern.
- Kontentyp: Filtern Sie I_OperationalAcctgDocItem nach FinancialAccountType = 'K' (Kreditor), um Sachkonten- und Kundenpositionen 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.
- Performance des Änderungsbelegprotokolls: Das Abfragen von I_ChangeDocument kann ressourcenintensiv sein. Begrenzen Sie diese Unterabfragen nach ObjectClass 'BELEG' und spezifischen 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