Ihr Daten-Template für die Kreditoren-Rechnungsverarbeitung
Ihr Daten-Template für die Kreditoren-Rechnungsverarbeitung
- Empfohlene Attribute für eine umfassende Analyse
- Wichtige Prozessaktivitäten für eine gezielte Nachverfolgung
- Schritt-für-Schritt-Anleitung zur Datenextraktion
Attribute der Kreditoren-Rechnungsverarbeitung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivität ActivityName | Der Name eines bestimmten Geschäftsereignisses oder Prozessschritts im Lebenszyklus der Rechnungsverarbeitung. | ||
| Beschreibung Die Aktivität bezeichnet eine bestimmte Phase oder Handlung im Kreditorenprozess, etwa „Rechnung eingegangen“, „Rechnung gebucht“ oder „Zahlung ausgeführt“. Diese Aktivitäten bilden die Bausteine der Prozessübersicht. Die Analyse von Aktivitäten ist ein zentraler Bestandteil von Process Mining. Sie macht den Prozessfluss sichtbar, zeigt häufige Abläufe und Abweichungen vom Standardprozess und misst Häufigkeit und Dauer der einzelnen Schritte. Die Abfolge der Aktivitäten einer Rechnung bildet ihren Prozessverlauf. Warum das wichtig ist Sie definiert die Prozessschritte und ermöglicht es, den Prozessfluss sichtbar zu machen, Engpässe zu erkennen und Nacharbeitsschleifen aufzudecken. Woher beziehen Abgeleitet aus verschiedenen Quellen, darunter Änderungen des Belegstatus (zum Beispiel BKPF-BSTAT), Änderungsbelege (Tabellen CDHDR/CDPOS) oder Workflow-Protokolle. Dafür ist in der Regel eine individuelle Extraktionslogik erforderlich. Beispiele Rechnung eingegangenRechnung freigegebenZahlung ausgeführtRechnung für Zahlung gesperrt | |||
| Ereigniszeit EventTime | Das genaue Datum und die Uhrzeit, zu denen die Aktivität stattgefunden hat. | ||
| Beschreibung Die Ereigniszeit ist der Timestamp jeder Aktivität und bildet die chronologische Abfolge der Ereignisse für eine Rechnung ab. Diese Daten sind entscheidend, um den Prozessfluss zu verstehen und zeitbezogene Analysen durchzuführen. In der Analyse dient die Ereigniszeit dazu, Aktivitäten korrekt zu ordnen, Durchlaufzeiten zwischen Prozessschritten zu berechnen, Wartezeiten zu ermitteln und die Prozessleistung über verschiedene Zeiträume hinweg zu untersuchen, zum Beispiel im Monatsvergleich. Sie bildet die Grundlage für alle zeitbezogenen KPIs. Warum das wichtig ist Dieser Timestamp ist entscheidend, um Ereignisse chronologisch zu ordnen und alle zeitbezogenen Kennzahlen wie Durchlaufzeiten und Zeitspannen zu berechnen. Diese sind grundlegend für Process Mining. Woher beziehen Stammt aus verschiedenen Datums- und Zeitfeldern in SAP-Tabellen, zum Beispiel Erfassungsdatum (BKPF-CPUDT), Buchungsdatum (BKPF-BUDAT), Ausgleichsdatum (BSAK-AUGDT) oder Zeitstempel aus Änderungsprotokollen (CDHDR-UDATE/UTIME). Beispiele 2023-10-01T09:00:00Z2023-10-05T14:30:15Z2023-10-15T11:21:05Z | |||
| Rechnung Invoice | Der eindeutige Bezeichner eines Rechnungsbelegs. Er dient als primäre Case-ID für den Kreditorenprozess. | ||
| Beschreibung Die Rechnung ist das zentrale Objekt, das alle zugehörigen Aktivitäten vom Eingang bis zur Zahlung miteinander verknüpft. In SAP S/4HANA besteht der zusammengesetzte Schlüssel in der Regel aus Buchungskreis (BUKRS), eindeutiger Belegnummer (BELNR) und Geschäftsjahr (GJAHR). Die Analyse nach Rechnung ermöglicht einen vollständigen Überblick über den gesamten Rechnungslebenszyklus. Sie bildet die Grundlage für die Berechnung wichtiger Kennzahlen wie der gesamten Durchlaufzeit, die Ermittlung von Engpässen bei einzelnen Rechnungen und das Verständnis der verschiedenen Prozesspfade einer Rechnung. Warum das wichtig ist Der eindeutige Bezeichner bildet den Weg jeder Rechnung ab. So lässt sich ihr gesamter Lebenszyklus nachvollziehen und die Prozessleistung für jeden Case einzeln analysieren. Woher beziehen Dies ist ein zusammengesetzter Schlüssel aus den Tabellen BKPF (Buchhaltungsbelegkopf) oder RBKP (Belegkopf: Rechnungseingang) und den Feldern BUKRS, BELNR und GJAHR. Beispiele 1000-1900000001-20231710-1900000002-20232000-5100000003-2024 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, der angibt, wann die Daten dieses Datensatzes zuletzt aus dem Quellsystem aktualisiert wurden. | ||
| Beschreibung Dieses Attribut enthält Datum und Uhrzeit der letzten Datenextraktion oder Aktualisierung aus SAP S/4HANA. Als Metadatenfeld ist es wichtig, um die Aktualität der analysierten Daten einzuschätzen. So können Benutzer beurteilen, wie aktuell die Prozessanalyse ist. Die Information hilft, Erwartungen an die Datenlatenz zu steuern, Datenaktualisierungen zu planen und die Datenintegrität zu wahren. Warum das wichtig ist Zeigt an, wie aktuell die Daten sind, damit Benutzer den Aktualitätsstand ihrer Prozessanalyse einschätzen können. Woher beziehen Dieser Wert wird bei der Datenextraktion aus dem Quellsystem generiert und jedem Datensatz hinzugefügt. Beispiele 2024-05-20T04:00:00Z2024-05-21T04:00:00Z | |||
| Quellsystem SourceSystem | Das System, aus dem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt die Herkunft der Prozessdaten an. In dieser Ansicht lautet der Wert in der Regel „SAP S/4HANA“. In Umgebungen mit mehreren ERP- oder integrierten Systemen ist dieses Feld wichtig für die Datenherkunft und die Trennung von Daten. Es stellt sicher, dass die Analyse den richtigen Datensatz verwendet, und hilft, Probleme mit der Datenqualität bis zu ihrer Quelle zurückzuverfolgen. Warum das wichtig ist Gibt die Herkunft der Daten an. Das ist wichtig für Data Governance, die Fehlerbehebung und Umgebungen mit mehreren Systemen. Woher beziehen In der Regel ein statischer Wert, der während der Datenextraktion hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele SAP S/4HANASAP ECC 6.0S4H_PROD_100 | |||
| Benutzername UserName | Die Benutzer-ID der Person, die die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die SAP-Benutzer-ID der Person, die für eine bestimmte Aktivität verantwortlich ist, etwa das Buchen, Freigeben oder Ausgleichen einer Rechnung. Es ordnet Prozessschritte einzelnen Benutzern zu. Die Analyse nach Benutzername ist wichtig, um die Arbeitsverteilung zu verstehen, besonders leistungsstarke Mitarbeitende zu erkennen und festzustellen, wer zusätzliche Schulungen benötigt. Auch für die Analyse von Engpässen bei Freigaben ist dieses Attribut relevant, denn es zeigt, welche freigabeberechtigten Personen Verzögerungen im Prozess verursachen. Warum das wichtig ist Ordnet Aktivitäten bestimmten Personen zu und ermöglicht so die Analyse von Benutzerleistung, Arbeitsbelastung und der Einhaltung von Funktionstrennungsrichtlinien. Woher beziehen In der Regel in Kopftabellen wie BKPF-USNAM (Erfasst von) oder in Änderungsbelegtabelle CDHDR-USERNAME (Geändert von) zu finden. Beispiele ABROWNJSMITHAP_AUTOMATION | |||
| Bestellnummer PurchaseOrderNumber | Der eindeutige Bezeichner der Bestellung, die gegebenenfalls mit der Rechnung verknüpft ist. | ||
| Beschreibung Dieses Attribut verknüpft eine Rechnung mit einer vorab genehmigten Bestellung (PO). Das Vorhandensein einer Bestellnummer bildet die Grundlage für den 3-Wege-Abgleich (Bestellung, Rechnung und Wareneingang). Das Attribut ist wichtig für die Analyse von Compliance und Effizienz. Es dient zur Berechnung der KPI „Anteil der Rechnungen ohne Bestellung“, die die Einhaltung der Beschaffungsrichtlinien misst. Außerdem bildet es die Grundlage für das Dashboard „Leistung des 3-Wege-Abgleichs“, mit dem sich der Abgleich bei Rechnungen mit Bestellung analysieren lässt. Warum das wichtig ist Wichtig für die Analyse der Effizienz des 3-Wege-Abgleichs und die Messung der Einhaltung von Beschaffungsrichtlinien, indem Rechnungen ohne Bestellung erkannt werden. Woher beziehen Zu finden in den Rechnungspositionstabellen, zum Beispiel RSEG-EBELN für MM-Rechnungen oder BSEG-EBELN für FI-Rechnungen. Beispiele 45000012344500005678 | |||
| Buchungskreis CompanyCode | Die Organisationseinheit, für die die Rechnung verarbeitet wird. | ||
| Beschreibung Ein Buchungskreis ist die kleinste Organisationseinheit, für die ein vollständiger, in sich geschlossener Kontensatz für die externe Berichterstattung erstellt werden kann. Im Kreditorenprozess bezeichnet er die juristische Person, die dem Lieferanten Geld schuldet. Die Analyse nach Buchungskreis ermöglicht den Vergleich der Prozessleistung verschiedener juristischer Personen innerhalb des Unternehmens. So lässt sich erkennen, welche Unternehmensteile Standardprozesse einhalten und wo die Effizienz geringer, die Durchlaufzeiten länger oder die Nacharbeitsquoten höher sind. Warum das wichtig ist Ermöglicht den Vergleich der Prozessleistung verschiedener juristischer Personen und hilft, regionale oder geschäftsbereichsspezifische Probleme sowie bewährte Vorgehensweisen zu erkennen. Woher beziehen Zu finden in Belegkopftabellen, vor allem in BKPF-BUKRS für FI-Rechnungen und RBKP-BUKRS für MM-Rechnungen. Beispiele 10001710US01DE01 | |||
| Fälligkeitstermin der Rechnung InvoiceDueDate | Das Datum, bis zu dem die Rechnung an den Lieferanten bezahlt werden muss. | ||
| Beschreibung Der Fälligkeitstermin der Rechnung ist die Frist für die Zahlung an den Lieferanten. Wird sie eingehalten, lassen sich Verzugsgebühren vermeiden und gute Lieferantenbeziehungen pflegen. Das Datum wird anhand des Basisdatums der Rechnung und der mit dem Lieferanten vereinbarten Zahlungsbedingungen berechnet. Der Fälligkeitstermin ist entscheidend für das Dashboard „Zahlungskonformität und Fälligkeiten“ und die KPI „Pünktliche Zahlungen“. Durch den Vergleich mit dem tatsächlichen Zahlungsdatum zeigt die Analyse, ob Zahlungen pünktlich, vorzeitig oder verspätet erfolgen. Das hat unmittelbare finanzielle Auswirkungen und beeinflusst die Lieferantenbeziehungen. Warum das wichtig ist Dies ist die wichtigste Grundlage für die Analyse pünktlicher Zahlungen. Sie ermöglicht es, die Zahlungsleistung und ihre Auswirkungen auf Lieferantenbeziehungen und Verzugsgebühren zu messen. Woher beziehen Dieses Datum wird häufig berechnet. Der Nettofälligkeitstermin steht im Feld BSEG-NETDT. Er lässt sich auch aus dem Basisdatum für die Zahlung (BSEG-ZFBDT) und den Zahlungsbedingungen (BSEG-ZTERM) ableiten. Beispiele 2023-10-312023-11-152024-01-10 | |||
| Lieferantenname VendorName | Der Name des Lieferanten, der die Rechnung eingereicht hat. | ||
| Beschreibung Dieses Attribut enthält den offiziellen Namen des Lieferanten. Die Verknüpfung erfolgt über die im Rechnungsbeleg gespeicherte Lieferantennummer. Die Lieferantenanalyse ist wichtig, um Lieferantenbeziehungen zu verwalten und prozessbezogene Probleme bei bestimmten Lieferanten zu erkennen. Sie hilft bei Fragen wie: „Welche Lieferanten reichen die meisten Rechnungen mit Abweichungen ein?“ oder „Bezahlen wir bestimmte strategische Lieferanten durchgehend pünktlich?“ Zusammen mit Rechnungsnummer und -betrag ist der Lieferantenname auch wichtig, um mögliche Doppelzahlungen zu erkennen. Warum das wichtig ist Ermöglicht die Analyse der Prozessleistung nach Lieferant. So können Sie problematische Lieferanten erkennen und strategische Lieferantenbeziehungen gezielt verwalten. Woher beziehen Aus der Lieferantenstammdatentabelle LFA1 (Feld NAME1), verknüpft über die Lieferantennummer (LIFNR) in BKPF oder RBKP. Beispiele Office Supplies GmbH.Global Consulting GroupMachine Parts GmbH | |||
| Rechnungsbetrag InvoiceAmount | Der Bruttogesamtbetrag der Rechnung in der ursprünglichen Belegwährung. | ||
| Beschreibung Dies ist der Gesamtbetrag der vom Lieferanten eingereichten Rechnung. Er umfasst die Kosten für Waren oder Dienstleistungen, Steuern und sonstige Gebühren vor Abzügen oder Rabatten. Der Rechnungsbetrag ist ein wichtiges Finanzattribut für zahlreiche Analysen. Er hilft dabei, Rechnungen mit hohen Beträgen zu priorisieren, die finanziellen Auswirkungen von Prozessverzögerungen zu verstehen, etwa Verzugsgebühren bei hohen Rechnungsbeträgen, und den Prozess zu segmentieren. So lässt sich zum Beispiel untersuchen, ob Rechnungen mit hohen Beträgen einen anderen Freigabeweg durchlaufen. Das Attribut ist außerdem wichtig, um mögliche Doppelzahlungen zu erkennen. Warum das wichtig ist Liefert den finanziellen Kontext zum Prozess und ermöglicht wertbezogene Analysen, die Priorisierung hoher Rechnungsbeträge und die Quantifizierung finanzieller Auswirkungen. Woher beziehen Zu finden in Tabellen wie RBKP-RMWWR (Bruttorechnungsbetrag) für MM-Rechnungen oder berechnet aus Rechnungspositionen in BSEG (Feld WRBTR) für FI-Rechnungen. Beispiele 1500.00250.7512345.50 | |||
| Ausgleichsdatum ClearingDate | Das Datum, an dem die Zahlung erfolgt und die Rechnung aus den offenen Posten ausgeglichen wurde. | ||
| Beschreibung Das Ausgleichsdatum gibt an, wann die Rechnung finanziell beglichen wurde. An diesem Datum findet die Aktivität „Zahlung ausgeglichen“ statt. Für die meisten erfolgreich bearbeiteten Rechnungen ist damit der letzte Prozessschritt erreicht. Anhand dieses Datums lässt sich das tatsächliche Zahlungsdatum ermitteln und mit dem Fälligkeitsdatum der Rechnung vergleichen. Es ist daher entscheidend für die Berechnung der KPI „Pünktliche Zahlungsquote“ und für Analysen zur Zahlungsleistung. Außerdem markiert es den Endpunkt für die Berechnung der durchgängigen Rechnungsdurchlaufzeit. Warum das wichtig ist Das Datum markiert den endgültigen Ausgleich einer Rechnung. Es bildet den Endpunkt für die Berechnung der Durchlaufzeit und die Grundlage für Analysen zur Pünktlichkeit von Zahlungen. Woher beziehen Zu finden in den Tabellen für ausgeglichene Posten, bei Lieferanten beispielsweise in BSAK-AUGDT. Beispiele 2023-10-282023-11-142024-01-09 | |||
| Automatisiert IsAutomated | Ein Kennzeichen dafür, ob das System die Aktivität automatisch statt durch einen menschlichen Benutzer ausgeführt hat. | ||
| Beschreibung Dieses boolesche Attribut unterscheidet zwischen von Menschen angestoßenen Aktivitäten und solchen, die durch Systemjobs, Workflows oder Bots ausgeführt werden. Ein automatisierter Zahlungslauf oder eine vom System erzeugte Rechnungsbuchung wird beispielsweise als automatisiert gekennzeichnet. Die Analyse dieses Attributs zeigt den Automatisierungsgrad im Kreditorenprozess. Damit lässt sich der Erfolg von Automatisierungsvorhaben messen, die Effizienz automatisierter und manueller Schritte vergleichen und weiteres Automatisierungspotenzial erkennen. Warum das wichtig ist Hilft, den Automatisierungsgrad des Prozesses zu messen, die Wirksamkeit der Automatisierung zu analysieren und weitere Verbesserungsmöglichkeiten zu erkennen. Woher beziehen Abgeleitet anhand des Benutzernamens, zum Beispiel anhand von Systembenutzer-IDs wie 'SAP_SYSTEM' oder 'BATCHUSER', oder anhand spezifischer Transaktionscodes für automatisierte Jobs. Beispiele truefalse | |||
| Lieferanten-Rechnungsnummer VendorInvoiceNumber | Die Rechnungsnummer, die der Lieferant auf seinem Beleg angibt. | ||
| Beschreibung Dies ist die Referenznummer aus dem Buchhaltungssystem des Lieferanten, wie sie auf der Papier- oder elektronischen Rechnung steht. Sie wird bei Rechnungseingang manuell erfasst oder per OCR ausgelesen. Dieses Feld ist für den operativen Ablauf und für Analysen besonders wichtig, insbesondere für das Dashboard „Mögliche doppelte Rechnungszahlungen“. Eine gängige Methode zur Erkennung von Duplikaten ist die Suche nach mehreren internen Rechnungsbelegen mit demselben Lieferantennamen, derselben Lieferanten-Rechnungsnummer und demselben Rechnungsbetrag. Die Nummer ist die wichtigste externe Referenz einer Rechnung. Warum das wichtig ist Das Feld ist entscheidend, um mögliche doppelte Zahlungen zu erkennen, und dient als wichtigste externe Referenz für die Kommunikation mit Lieferanten. Woher beziehen Gespeichert im Feld „Referenz“ im Belegkopf, üblicherweise BKPF-XBLNR. Beispiele INV-2023-9876733401120231015-001 | |||
| Rechnungsbelegart InvoiceDocumentType | Eine Klassifizierung des Rechnungsbelegs, die steuert, wie er in SAP verarbeitet wird. | ||
| Beschreibung Die Belegart ist ein wichtiges Konfigurationselement in SAP und ordnet Buchhaltungsbelege Kategorien zu. Beispielsweise wird „KR“ üblicherweise für Lieferantenrechnungen, „RE“ für MM-Rechnungen und „KG“ für Lieferantengutschriften verwendet. Die Belegart bestimmt unter anderem den Nummernkreis und die erforderlichen Felder. In der Prozessanalyse ermöglicht die Filterung nach Belegart den Vergleich der Abläufe verschiedener Rechnungstypen. So kann sich der Freigabeprozess einer Gutschrift von dem einer Standardrechnung unterscheiden. Das ist hilfreich für das Dashboard „Varianten der Rechnungsfreigabe“. Warum das wichtig ist Ermöglicht die Segmentierung des Prozesses nach der Bearbeitung verschiedener Rechnungstypen und macht Unterschiede bei Prozesspfaden und Durchlaufzeiten sichtbar. Woher beziehen Direkt aus dem Belegkopf, Feld BKPF-BLART. Beispiele KRREKG | |||
| Rechnungswährung InvoiceCurrency | Der Währungscode des Rechnungsbetrags (z. B. USD, EUR). | ||
| Beschreibung Dieses Attribut gibt an, in welcher Währung der Rechnungsbetrag ausgewiesen ist. Es liefert den notwendigen Kontext für alle Finanzwerte. In international tätigen Unternehmen können Analysen von Rechnungen ohne Berücksichtigung der Währung irreführend sein. Mit diesem Feld lassen sich Finanzdaten korrekt auswerten, indem alle Beträge in eine gemeinsame Berichtswährung umgerechnet oder Analysen nach Währung aufgeschlüsselt werden, um die Finanzaktivitäten in den einzelnen Regionen zu verstehen. Warum das wichtig ist Das Attribut liefert den nötigen Kontext zum Rechnungsbetrag und ermöglicht präzise Finanzanalysen und Berichte, insbesondere in international tätigen Unternehmen. Woher beziehen Zu finden in den Belegkopftabellen, vor allem in BKPF-WAERS oder RBKP-WAERS. Beispiele USDEURGBPJPY | |||
| Skonto in Anspruch genommen DiscountTaken | Ein boolesches Kennzeichen dafür, ob ein Skonto bei vorzeitiger Zahlung erfolgreich in Anspruch genommen wurde. | ||
| Beschreibung Dieses Attribut gibt an, ob beim Bezahlen der Rechnung tatsächlich Skonto abgezogen wurde. Es ist entscheidend, um die finanzielle Effizienz des Kreditorenprozesses zu messen. Das Kennzeichen bildet die Grundlage für die KPI „Skontoausnutzungsquote“. Filtern Sie zunächst nach Rechnungen, für die laut Zahlungsbedingungen ein Skonto möglich war, und analysieren Sie anschließend dieses Kennzeichen. So lässt sich genau berechnen, wie viel Geld eingespart wurde und wie viele Einsparmöglichkeiten ungenutzt blieben. Das Ergebnis ist ein klarer, messbarer Wert für die Leistung der Kreditorenbuchhaltung. Warum das wichtig ist Das Attribut misst direkt, wie erfolgreich verfügbare Skonti bei vorzeitiger Zahlung in Anspruch genommen werden. Das wirkt sich unmittelbar auf das Unternehmensergebnis aus. Woher beziehen Abgeleitet aus dem Skontobetrag im Zahlungsbeleg: Das Feld BSEG-SKNTO muss größer als null sein. Beispiele truefalse | |||
| Sperrgrund BlockingReason | Der Grund, aus dem eine Rechnung für die Zahlung gesperrt ist, meist aufgrund einer Abweichung. | ||
| Beschreibung Besteht eine Rechnung die Prüfung beim 3-Wege-Abgleich oder bei einem anderen Verifizierungsschritt nicht, wird sie für die Zahlung gesperrt. Der Sperrgrund beschreibt das Problem, etwa eine Mengenabweichung, eine Preisabweichung oder einen fehlenden Wareneingang. Dieses Attribut ist entscheidend für das Dashboard „Analyse der Nacharbeit bei Rechnungsabweichungen“. Die Häufigkeit der verschiedenen Sperrgründe zeigt, wo die Ursachen für ineffiziente Abläufe liegen. Ist beispielsweise „Preisabweichung“ ein häufiger Grund, kann dies auf Probleme mit den Stammdaten im Einkaufssystem hindeuten. Warum das wichtig ist Das Attribut zeigt direkt die Ursachen für Rechnungsabweichungen und Nacharbeit auf und ermöglicht gezielte Prozessverbesserungen. Woher beziehen Gespeichert in Rechnungspositions-Tabellen wie RSEG, in Feldern mit der Bezeichnung SPGR* (z. B. SPGRP, SPGRQ, SPGRT). Auch in RBKP_BLOCKED zu finden. Beispiele PreisabweichungMengenabweichungFehlender Wareneingang | |||
| Zahlung verspätet IsLatePayment | Ein boolesches Kennzeichen dafür, ob die Rechnung nach dem Fälligkeitsdatum bezahlt wurde. | ||
| Beschreibung Dieses berechnete Attribut gibt mit einem einfachen Wahr/Falsch-Kennzeichen an, ob die Rechnung nach dem offiziellen Fälligkeitsdatum bezahlt wurde. Es wird durch den Vergleich von „Ausgleichsdatum“ und „Rechnungsfälligkeitsdatum“ ermittelt. Das Kennzeichen vereinfacht die Analyse im Dashboard „Zahlungskonformität und Fälligkeiten“ sowie die Berechnung der KPI „Pünktliche Zahlungsquote“. Sie können damit verspätete Zahlungen zählen, den Anteil pünktlicher Zahlungen berechnen und Lieferanten oder Buchungskreise mit einem hohen Anteil verspäteter Zahlungen ermitteln. Warum das wichtig ist Das Attribut misst direkt, ob die Zahlungsbedingungen eingehalten werden, vereinfacht die Berechnung der KPI für pünktliche Zahlungen und hilft, Bereiche mit schlechter Zahlungsleistung zu erkennen. Woher beziehen Berechnetes Attribut. Die Logik lautet: IF ClearingDate > InvoiceDueDate THEN true ELSE false. Beispiele truefalse | |||
| Zahlungsbedingungen PaymentTerms | Die mit dem Lieferanten vereinbarten Bedingungen für die Bezahlung einer Rechnung, häufig einschließlich möglicher Skonti. | ||
| Beschreibung Die Zahlungsbedingungen legen fest, wann Zahlungen fällig sind und ob Skonto bei vorzeitiger Zahlung gewährt wird. So kann die Bedingung „Z001“ beispielsweise bedeuten: „Zahlbar innerhalb von 30 Tagen, 2 % Skonto bei Zahlung innerhalb von 10 Tagen“. Dieses Attribut bildet die Grundlage für das Dashboard „Skontoausnutzungsquote“. Anhand der Zahlungsbedingungen lassen sich alle Rechnungen ermitteln, für die ein Skonto möglich war. Der Vergleich mit den tatsächlich gewährten Skonti zeigt, wo Einsparungen verpasst wurden, und gibt Aufschluss über die Effizienz des Zahlungsprozesses. Warum das wichtig ist Das Attribut ist unverzichtbar, um Skontomöglichkeiten zu analysieren, die finanzielle Leistung des Zahlungsprozesses zu messen und entgangene Einsparungen zu ermitteln. Woher beziehen Zu finden in den Lieferanten-Einzelposten, in der Tabelle BSEG-ZTERM oder im Rechnungskopf unter RBKP-ZTERM. Beispiele Z0010001NT30 | |||
Aktivitäten der Kreditoren-Rechnungsverarbeitung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Rechnung eingegangen | Diese Aktivität kennzeichnet die Anlage eines Rechnungsbelegs in SAP, entweder manuell oder über eine automatisierte Schnittstelle wie OCR/VIM. Das Ereignis wird in der Regel anhand von Datum und Uhrzeit der Belegerfassung im Buchhaltungsbelegkopf ermittelt. | ||
| Warum das wichtig ist Als Startpunkt des Prozesses ist diese Aktivität entscheidend, um die durchgängige Rechnungsdurchlaufzeit zu berechnen und den Durchsatz des gesamten Kreditorenprozesses zu messen. Woher beziehen Dieses Ereignis wird aus der Buchhaltungsbelegkopftabelle (BKPF) anhand des Belegerfassungsdatums (CPUDT) und der Erfassungszeit (CPUTM) ermittelt. Erfassung Verwenden Sie den Erstellungs-Timestamp (BKPF-CPUDT, BKPF-CPUTM) des Rechnungsbelegs. Ereignistyp explicit | |||
| Rechnung freigegeben | Die Rechnung hat alle erforderlichen Freigaben im Workflow-System erhalten. Dies ist häufig der letzte Schritt, bevor die Rechnung gebucht oder für die Zahlung entsperrt werden kann. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein markiert das Ende des Freigabezyklus. Die Zeit zwischen Weiterleitung und Freigabe ist eine entscheidende Effizienzkennzahl. Woher beziehen Wird in SAP-Business-Workflow-Protokollen als Abschluss oder endgültige Freigabe erfasst. Alternativ lässt sich das Ereignis aus der Aufhebung einer Zahlungssperre nach der Weiterleitung ableiten. Erfassung Extrahieren Sie Workflow-Abschlussereignisse aus SAP-Workflow-Protokollen oder ermitteln Sie das abschließende „Freigabe“-Ereignis. Ereignistyp explicit | |||
| Rechnung für Zahlung gesperrt | Das System hat die Rechnung automatisch oder manuell für die Zahlung gesperrt. Gründe dafür sind häufig Abweichungen bei Preis oder Menge sowie fehlende Freigaben. | ||
| Warum das wichtig ist Eine Zahlungssperre ist ein wichtiger Hinweis auf Probleme und Nacharbeit. Die Analyse der Sperrgründe und -dauer hilft, die Ursachen für Zahlungsverzögerungen und Prozessineffizienzen zu ermitteln. Woher beziehen Dieser Status wird ausdrücklich im Feld für den Zahlungssperrschlüssel (ZLSPR) der Lieferantenposition im Buchhaltungsbeleg erfasst (Tabelle BSEG). Erfassung Wird über Änderungsbelege protokolliert, wenn das Feld BSEG-ZLSPR mit einem Sperrgrund befüllt wird. Ereignistyp explicit | |||
| Rechnung gebucht | Die Rechnung wird offiziell im Hauptbuch erfasst und begründet eine finanzielle Verbindlichkeit. Ein vorerfasster Beleg wird gebucht oder die Rechnung wird direkt gebucht. | ||
| Warum das wichtig ist Dies ist ein wichtiger finanzieller Meilenstein. Er bestätigt die Zahlungsverpflichtung des Unternehmens und ist häufig Voraussetzung für die Zahlungsplanung. Woher beziehen Dieses Ereignis wird anhand des Buchungsdatums (BUDAT) im Belegkopf (BKPF) ermittelt. Bei einem gebuchten Beleg ist der Belegstatus (BKPF-BSTAT) leer. Erfassung Verwenden Sie für nicht vorerfasste Belege (BKPF-BSTAT ist leer) den Buchungs-Timestamp (BKPF-BUDAT). Ereignistyp explicit | |||
| Rechnung storniert | Der Rechnungsbeleg wurde storniert, wodurch seine finanzielle Wirkung aufgehoben wurde. Dies ist ein alternativer Endzustand des Prozesses, häufig aufgrund fehlerhafter Einträge oder Streitigkeiten mit Lieferanten. | ||
| Warum das wichtig ist Die Erfassung von Stornierungen hilft, Ursachen für Prozessfehler wie doppelte Einreichungen oder fehlerhafte Rechnungsdaten zu erkennen. Solche Fälle können auf vorgelagerte Probleme hinweisen. Woher beziehen Wird ausdrücklich erfasst, wenn ein Stornobeleg erstellt wird. Im ursprünglichen Belegkopf (BKPF) sind dann die Nummer des Stornobelegs (STBLG) und der Stornogrund hinterlegt. Erfassung Ermitteln Sie das Buchungsdatum des Stornobelegs, auf den im Kopf des ursprünglichen Belegs (BKPF-STBLG) verwiesen wird. Ereignistyp explicit | |||
| Zahlung ausgeführt | Die Rechnung wurde bezahlt. Das Ereignis wird erfasst, wenn der Zahlungslauf abgeschlossen und ein Zahlungsbeleg erstellt und gebucht wurde. | ||
| Warum das wichtig ist Diese Aktivität ist wichtig für die Cashflow-Analyse und die Messung der KPI „Pünktliche Zahlungen“. Dazu wird dieses Datum mit dem Fälligkeitstermin der Rechnung verglichen. Woher beziehen Wird anhand des Buchungsdatums des Zahlungsbelegs erfasst, mit dem die Rechnung ausgeglichen wird. Die Nummer des Zahlungsbelegs ist im Ausgleichsbelegfeld (AUGBL) der Rechnungsposition (BSEG) hinterlegt. Erfassung Ermitteln Sie das Buchungsdatum (BUDAT) des Zahlungsbelegs, mit dem die Rechnungsposition ausgeglichen wird. Ereignistyp explicit | |||
| Zahlung ausgeglichen | Diese Aktivität markiert den endgültigen Abschluss der Rechnung. Dabei werden Zahlung und Rechnung im Nebenbuch miteinander abgeglichen. Damit ist der Prozess abgeschlossen. | ||
| Warum das wichtig ist Als endgültiger Endpunkt des Prozesses ist diese Aktivität für die genaue Berechnung der durchgängigen Durchlaufzeit unerlässlich. Sie bestätigt, dass die Verbindlichkeit beglichen wurde. Woher beziehen Dieses Ereignis wird ausdrücklich erfasst, wenn das Feld für das Ausgleichsdatum (AUGDT) in der Lieferantenposition des Rechnungsbelegs (Tabelle BSEG) befüllt ist. Erfassung Verwenden Sie das Ausgleichsdatum (BSEG-AUGDT) aus der Rechnungsposition. Ereignistyp explicit | |||
| Abweichung geklärt | Diese Aktivität zeigt an, dass ein zuvor festgestelltes Problem, das wahrscheinlich eine Zahlungssperre ausgelöst hat, untersucht und behoben wurde. Das Ereignis wird erfasst, wenn die Zahlungssperre für eine Rechnung aufgehoben wird. | ||
| Warum das wichtig ist Die Erfassung dieser Nacharbeitsschleife ist entscheidend für das Dashboard „Analyse der Nacharbeit bei Rechnungsabweichungen“. Sie zeigt, wie viel Zeit und Aufwand für die Fehlerbehebung anfallen. Woher beziehen Wird aus Änderungsbelegen abgeleitet, die die Aufhebung einer Zahlungssperre zeigen. Das Änderungsprotokoll für das Feld BSEG-ZLSPR ist die wichtigste Quelle. Erfassung Ermitteln Sie Änderungsbelege für die Tabelle BSEG, bei denen das Feld ZLSPR von einem Wert auf leer geändert wurde. Ereignistyp inferred | |||
| Bestellung abgeglichen | Diese Aktivität zeigt an, dass die Rechnung erfolgreich einer Bestellung zugeordnet wurde. Sie ist ein wichtiger Schritt beim 3-Wege-Abgleich für Rechnungen aus dem Beschaffungsprozess. | ||
| Warum das wichtig ist Die Analyse dieser Aktivität zeigt, wie effizient der Abgleich abläuft. Sie ist außerdem eine wichtige Grundlage für die KPIs „Leistung des 3-Wege-Abgleichs“ und „Anteil der Rechnungen ohne Bestellung“. Woher beziehen Dieses Ereignis wird abgeleitet, wenn eine Rechnungsposition in der Tabelle BSEG oder ACDOCA eine gültige Bestellnummer (EBELN) und Positionsnummer (EBELP) enthält. Erfassung Abgeleitet aus einer Bestellreferenz (BSEG-EBELN) im Rechnungsbeleg bei dessen Anlage. Ereignistyp inferred | |||
| Fälligkeitstermin der Rechnung überschritten | Ein berechnetes Ereignis, das anzeigt, dass der Nettofälligkeitstermin der Rechnung verstrichen ist, ohne dass eine Zahlung ausgeglichen wurde. Dies weist auf eine verspätete oder überfällige Zahlung hin. | ||
| Warum das wichtig ist Diese Aktivität ist wichtig für das Dashboard „Zahlungskonformität und Fälligkeiten“. Sie hilft, überfällige Rechnungen frühzeitig zu erkennen und zu bearbeiten sowie die Ursachen verspäteter Zahlungen zu analysieren. Woher beziehen Dieses Ereignis ist in SAP nicht ausdrücklich erfasst. Es wird berechnet, indem das aktuelle Systemdatum mit dem Nettofälligkeitstermin verglichen wird, der sich aus BSEG-ZFBDT oder dem Basisdatum und den Zahlungsbedingungen ergibt. Erfassung Berechnetes Ereignis, das ausgelöst wird, wenn der Ereignis-Timestamp nach dem Nettofälligkeitstermin der Rechnung liegt. Ereignistyp calculated | |||
| Rechnung abgelehnt | Eine freigabeberechtigte Person hat die Rechnung während des Freigabe-Workflows abgelehnt. In der Regel wird sie zur Korrektur oder Klärung an die bearbeitende Person zurückgegeben. | ||
| Warum das wichtig ist Die Erfassung von Ablehnungen macht Nacharbeitsschleifen im Freigabeprozess sichtbar und kann auf Verstöße gegen Richtlinien oder eine fehlerhafte Kontierung hinweisen. Woher beziehen Wird als spezifisches Ergebnisereignis in den SAP-Business-Workflow-Protokollen zur Rechnung erfasst. Erfassung Extrahieren Sie Ereignisse mit dem Workflow-Status „abgelehnt“ aus den SAP-Workflow-Protokollen. Ereignistyp explicit | |||
| Rechnung vorerfasst | Die Rechnung wurde im System erfasst, aber noch nicht im Hauptbuch gebucht. Dieser Schritt dient häufig dazu, einen unvollständigen Beleg für die spätere Bearbeitung oder Freigabe zu speichern. | ||
| Warum das wichtig ist Die Erfassung vorerfasster Rechnungen hilft, Verzögerungen vor der formellen Buchung zu erkennen und Probleme mit unvollständigen Daten oder der ersten Prüfung aufzudecken. Woher beziehen Dieser Status wird aus dem Belegstatusfeld im Buchhaltungsbelegkopf abgeleitet (BKPF-BSTAT = 'V' für vorerfasst). Das Ereignis tritt ein, sobald der Status gesetzt wird. Erfassung Ermitteln Sie Änderungsbelege für die Tabelle BKPF, bei denen das Feld BSTAT auf 'V' (vorerfasst) gesetzt ist. Ereignistyp inferred | |||
| Rechnung zur Freigabe weitergeleitet | Die Rechnung wurde anhand von Geschäftsregeln zur erforderlichen Freigabe an einen Workflow übergeben. Damit beginnt der Freigabeprozess. | ||
| Warum das wichtig ist Diese Aktivität bildet den Ausgangspunkt für die Messung der KPI „Durchschnittliche Freigabezeit von Rechnungen“ und die Analyse von Engpässen im Freigabeprozess. Woher beziehen Das Ereignis lässt sich aus SAP-Business-Workflow-Protokollen (SWW*-Tabellen) ermitteln. Diese protokollieren den Start einer Workflow-Instanz, die mit dem Rechnungsobjekt verknüpft ist, zum Beispiel BUS2081. Erfassung Extrahieren Sie Workflow-Start-Ereignisse aus SAP-Workflow-Protokollen, zum Beispiel aus der Tabelle SWW_WIHEAD, die mit dem Rechnungsbeleg verknüpft ist. Ereignistyp explicit | |||
| Wareneingang abgeglichen | Diese Aktivität zeigt an, dass die Mengen und Werte der Rechnung erfolgreich mit einem Wareneingangsbeleg abgeglichen wurden. Damit ist der 3-Wege-Abgleich abschließend geprüft. | ||
| Warum das wichtig ist Die Erfassung dieses Schritts hilft, Ineffizienzen beim 3-Wege-Abgleich aufzudecken und Abweichungen zwischen dem Wareneingang und den vom Lieferanten berechneten Mengen zu erkennen. Woher beziehen Dieses Ereignis wird aus einer Referenz auf einen Materialbeleg (Wareneingang) in der Rechnungsposition abgeleitet, die häufig über die Bestellhistorie verknüpft ist. Erfassung Abgeleitet aus einer Referenz auf einen Wareneingangsbeleg in der Rechnungsposition, zum Beispiel in RSEG bei MIRO-Rechnungen. Ereignistyp inferred | |||
| Zahlungsvorschlag erstellt | Die Rechnung wurde in einen Zahlungsvorschlag eines Zahlungslaufs aufgenommen, zum Beispiel F110. Sie ist nun für die Zahlung vorgesehen, sobald der Lauf endgültig ausgeführt wird. | ||
| Warum das wichtig ist Diese Aktivität zeigt den Übergang von einer offenen Verbindlichkeit zu einem Posten, der aktiv für die Zahlung vorbereitet wird. So lässt sich die Effizienz der Zahlungsabwicklung analysieren. Woher beziehen Dieses Ereignis wird ausdrücklich in den Tabellen der Zahlungslaufdaten protokolliert, insbesondere in REGUP (bearbeitete Posten des Zahlungsprogramms) und REGUH (Kopf). Erfassung Ermitteln Sie, wann eine Rechnung in der Tabelle REGUP für einen in REGUH erfassten Zahlungslauf erscheint. Ereignistyp explicit | |||
Extraktionsanleitungen
Schritte
- Voraussetzungen und Zugriff: Stellen Sie sicher, dass Sie über einen Benutzer mit Lesezugriff auf das SAP-S/4HANA-Datenbankschema verfügen, in dem sich die CDS-Views befinden (in der Regel SAPABAP1 oder ein ähnliches Schema). Sie benötigen ein SQL-Client-Tool, das eine Verbindung zur SAP-HANA-Datenbank herstellen kann, zum Beispiel SAP HANA Studio, DBeaver oder ein vergleichbares Datenbankabfragetool.
- Zentrale CDS-Views ermitteln: Für diese Extraktion sind vor allem die CDS-Views I_JournalEntry, I_JournalEntryItem, I_SupplierInvoiceAPI01, I_ChangeDocument, I_WorkflowStatusDetails und I_PaymentProposalItem relevant. Machen Sie sich mit den wichtigsten Feldern vertraut.
- Abfrageumfang festlegen: Öffnen Sie Ihren SQL-Client und stellen Sie eine Verbindung zur SAP-HANA-Datenbank her. Legen Sie vor der vollständigen Abfrage den Umfang der Extraktion fest. Dazu gehören die richtige Quellsystemkennung, der Rechnungszeitraum (CreationDateTime) und die relevanten Buchungskreise.
- Hauptabfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus dem Abfrageabschnitt in Ihren SQL-Client. Die Abfrage verwendet Common Table Expressions (CTEs), um zunächst eine Grundgesamtheit von Rechnungen auszuwählen und anschließend ein Event Log mit Daten zu 15 verschiedenen Aktivitäten zu erstellen.
- Abfrageparameter festlegen: Suchen Sie in der kopierten SQL-Abfrage nach den Platzhaltern. Ersetzen Sie '[YYYY-MM-DD]' durch Anfangs- und Enddatum des Analysezeitraums. Ersetzen Sie '[Your Company Code 1]' und '[Your Company Code 2]' durch die SAP-Buchungskreise, die Sie analysieren möchten.
- Extraktionsabfrage ausführen: Führen Sie die vollständige SQL-Abfrage aus. Je nach Datenvolumen und ausgewähltem Zeitraum kann dies einige Minuten bis mehrere Stunden dauern.
- Erste Ergebnisse prüfen: Prüfen Sie nach Abschluss der Abfrage die ersten Hundert Zeilen der Ausgabe. Achten Sie auf konsistente Daten, erwartungsgemäß befüllte Spalten und verschiedene Werte in ActivityName.
- Event Log exportieren: Exportieren Sie das gesamte Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie UTF-8-Codierung, um Zeichenfehler zu vermeiden. Wählen Sie einen aussagekräftigen Dateinamen, zum Beispiel sap_s4hana_ap_event_log.csv.
- Upload vorbereiten: Prüfen Sie vor dem Upload in ein Process-Mining-Tool, ob die Spaltenüberschriften in der CSV-Datei genau den erforderlichen Attributnamen entsprechen: Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName usw.
- Upload in ein Process-Mining-Tool: Laden Sie die erstellte CSV-Datei auf Ihre Process-Mining-Plattform hoch und ordnen Sie die Spalten den entsprechenden Feldern für Case-ID, Aktivität und Timestamp zu.
Konfiguration
- Zentrale CDS-Views: Die Extraktion basiert auf einer Kombination standardmäßiger S/4HANA-CDS-Views. Dazu gehören vor allem:
- I_JournalEntry und I_JournalEntryItem: für zentrale Finanzbelegköpfe und -positionen, Buchungsdetails und Ausgleichsinformationen.
- I_SupplierInvoiceAPI01: für spezifische Details zu MM-Rechnungen (Logistik), einschließlich Bestellreferenzen und Zahlungssperren.
- I_ChangeDocument: zur Ermittlung des genauen Timestamps von Änderungen, etwa beim Setzen oder Aufheben einer Zahlungssperre.
- I_WorkflowStatusDetails: zur Extraktion von Ereignissen aus dem Rechnungsfreigabe-Workflow.
- I_PaymentProposalItem: zur Ermittlung, wann eine Rechnung in einen Zahlungslaufvorschlag aufgenommen wird.
- I_Supplier: zur Ergänzung der Daten um Kreditorenstammdaten wie VendorName.
- Filter für den Zeitraum: Begrenzen Sie das Datenvolumen unbedingt mit einem Datumsfilter. Die bereitgestellte Abfrage filtert in der CTE Invoices_Base nach CreationDateTime. Für eine erste Analyse empfiehlt sich ein Zeitraum von drei bis sechs Monaten, damit die Abfrageleistung handhabbar bleibt.
- Erforderliche Filter: Filtern Sie immer nach CompanyCode. Eine gleichzeitige Analyse aller Buchungskreise kann sehr langsam sein und muss fachlich nicht sinnvoll sein. Filtern Sie außerdem nach JournalEntryType, um nur kreditorenbezogene Belege auszuwählen, zum Beispiel 'KR' oder 'RE'.
- Voraussetzungen: Der ausführende Datenbankbenutzer benötigt SELECT-Berechtigungen für alle in der Abfrage verwendeten CDS-Views und das zugrunde liegende HANA-Schema. Ein Zugriff auf Anwendungsebene über die SAP GUI reicht nicht aus.
- Leistungsaspekte: Direkte Abfragen von I_ChangeDocument können viele Ressourcen beanspruchen. Die bereitgestellte Abfrage versucht, dies durch eine Vorfilterung der Rechnungen zu begrenzen. Bei sehr großen Datenmengen empfiehlt es sich, die Extraktion außerhalb der Spitzenzeiten oder in kleineren Zeitabschnitten auszuführen.
Beispielabfrage sql
-- Common Table Expression (CTE) to select the base set of AP Invoices
WITH Invoices_Base AS (
SELECT
I_JournalEntry.CompanyCode,
I_JournalEntry.AccountingDocument,
I_JournalEntry.FiscalYear,
CONCAT(I_JournalEntry.CompanyCode, CONCAT(I_JournalEntry.AccountingDocument, I_JournalEntry.FiscalYear)) AS InvoiceId,
I_JournalEntry.CreationDateTime,
I_JournalEntry.CreatedByUser,
I_JournalEntry.DocumentStatus,
I_JournalEntry.JournalEntryType,
I_JournalEntry.ReversalReferenceJournalEntry,
I_JournalEntry.IsReversed,
I_JournalEntry.ReversalDate,
IJE_ITEM.NetDueDate,
IJE_ITEM.Supplier,
SUP.SupplierName AS VendorName,
IJE_ITEM.AmountInCompanyCodeCurrency AS InvoiceAmount,
MM.PurchaseOrder AS PurchaseOrderNumber,
MM.PaymentBlockingReason
FROM I_JournalEntry
-- Join to get item details like due date and supplier
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON I_JournalEntry.CompanyCode = IJE_ITEM.CompanyCode
AND I_JournalEntry.AccountingDocument = IJE_ITEM.AccountingDocument
AND I_JournalEntry.FiscalYear = IJE_ITEM.FiscalYear
AND IJE_ITEM.IsSupplier = 'X'
-- Join to get vendor name from master data
LEFT JOIN I_Supplier AS SUP
ON IJE_ITEM.Supplier = SUP.Supplier
-- Join to get MM Invoice specific data like PO Number and Payment Block
LEFT JOIN I_SupplierInvoiceAPI01 AS MM
ON I_JournalEntry.AccountingDocument = MM.AccountingDocument
AND I_JournalEntry.CompanyCode = MM.CompanyCode
AND I_JournalEntry.FiscalYear = MM.FiscalYear
WHERE
I_JournalEntry.JournalEntryType IN ('KR', 'RE') -- Standard Vendor Invoice Types
AND I_JournalEntry.CompanyCode IN ('[Your Company Code 1]', '[Your Company Code 2]')
AND I_JournalEntry.CreationDateTime BETWEEN '[YYYY-MM-DD]T00:00:00Z' AND '[YYYY-MM-DD]T23:59:59Z'
)
-- Event: 1. Invoice Received
SELECT
B.InvoiceId AS "Invoice",
'Invoice Received' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
UNION ALL
-- Event: 2. Invoice Parked
SELECT
B.InvoiceId AS "Invoice",
'Invoice Parked' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.DocumentStatus = 'V' -- 'V' stands for Parked
UNION ALL
-- Event: 3. Purchase Order Matched
SELECT
B.InvoiceId AS "Invoice",
'Purchase Order Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PurchaseOrderNumber IS NOT NULL AND B.PurchaseOrderNumber <> ''
UNION ALL
-- Event: 4. Goods Receipt Matched
SELECT
B.InvoiceId AS "Invoice",
'Goods Receipt Matched' AS "ActivityName",
B.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_SupplierInvoiceItemAPI01 AS MM_ITEM
ON B.AccountingDocument = MM_ITEM.AccountingDocument
AND B.FiscalYear = MM_ITEM.FiscalYear
WHERE MM_ITEM.GoodsReceipt IS NOT NULL AND MM_ITEM.GoodsReceipt <> ''
UNION ALL
-- Event: 5. Invoice Blocked For Payment
SELECT
B.InvoiceId AS "Invoice",
'Invoice Blocked For Payment' AS "ActivityName",
B.CreationDateTime AS "EventTime", -- Approximates block time as creation time if blocked on entry
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.PaymentBlockingReason IS NOT NULL AND B.PaymentBlockingReason <> ''
UNION ALL
-- Event: 6. Discrepancy Resolved (Payment Block Removed)
SELECT
B.InvoiceId AS "Invoice",
'Discrepancy Resolved' AS "ActivityName",
CD.ChangeTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CD.UserName AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_ChangeDocument AS CD
ON CONCAT(B.CompanyCode, B.AccountingDocument, B.FiscalYear) = CD.ObjectValue
WHERE CD.ChangeDocumentObject = 'INVOICE'
AND CD.TableName = 'RBKP'
AND CD.FieldName = 'ZLSPR' -- Field for Payment Block
AND CD.NewFieldValue = '' -- Block was removed
UNION ALL
-- Event: 7, 8, 9. Workflow Events (Routed, Approved, Rejected)
SELECT
B.InvoiceId AS "Invoice",
CASE WF.WorkflowStatus
WHEN 'READY' THEN 'Invoice Routed For Approval'
WHEN 'APPROVED' THEN 'Invoice Approved'
WHEN 'REJECTED' THEN 'Invoice Rejected'
END AS "ActivityName",
WF.WorkflowStatusChangedDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
WF.WorkflowStatusChangedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_WorkflowStatusDetails AS WF
ON B.InvoiceId = WF.WorkflowScenarioInstance
WHERE WF.WorkflowStatus IN ('READY', 'APPROVED', 'REJECTED')
UNION ALL
-- Event: 10. Invoice Posted
SELECT
B.InvoiceId AS "Invoice",
'Invoice Posted' AS "ActivityName",
JE.PostingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntry AS JE
ON B.AccountingDocument = JE.AccountingDocument
AND B.CompanyCode = JE.CompanyCode
AND B.FiscalYear = JE.FiscalYear
WHERE B.DocumentStatus <> 'V' -- Any status other than Parked is considered Posted for AP
UNION ALL
-- Event: 11. Payment Proposal Created
SELECT
B.InvoiceId AS "Invoice",
'Payment Proposal Created' AS "ActivityName",
PPI.PaymentProposalRunDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
PPI.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_PaymentProposalItem AS PPI
ON B.CompanyCode = PPI.CompanyCode
AND B.AccountingDocument = PPI.AccountingDocument
AND B.FiscalYear = PPI.FiscalYear
UNION ALL
-- Event: 12. Payment Executed
-- This links the invoice to its clearing document, which is the payment document
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Executed' AS "ActivityName",
CLEAR_JE.CreationDateTime AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
CLEAR_JE.CreatedByUser AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
INNER JOIN I_JournalEntry AS CLEAR_JE
ON IJE_ITEM.ClearingJournalEntry = CLEAR_JE.AccountingDocument
AND IJE_ITEM.CompanyCode = CLEAR_JE.CompanyCode
WHERE IJE_ITEM.ClearingJournalEntry IS NOT NULL AND IJE_ITEM.ClearingJournalEntry <> ''
AND CLEAR_JE.JournalEntryType = 'KZ' -- Vendor Payment Document Type
UNION ALL
-- Event: 13. Invoice Due Date Passed
SELECT
B.InvoiceId AS "Invoice",
'Invoice Due Date Passed' AS "ActivityName",
ADD_DAYS(B.NetDueDate, 1) AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
'SYSTEM' AS "UserName",
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
LEFT JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE B.NetDueDate < CURRENT_DATE
AND IJE_ITEM.ClearingDate IS NULL -- Invoice is not yet cleared
UNION ALL
-- Event: 14. Payment Cleared
SELECT DISTINCT
B.InvoiceId AS "Invoice",
'Payment Cleared' AS "ActivityName",
IJE_ITEM.ClearingDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
IJE_ITEM.ChangedByUser AS "UserName", -- User who cleared it
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
INNER JOIN I_JournalEntryItem AS IJE_ITEM
ON B.CompanyCode = IJE_ITEM.CompanyCode
AND B.AccountingDocument = IJE_ITEM.AccountingDocument
AND B.FiscalYear = IJE_ITEM.FiscalYear
WHERE IJE_ITEM.ClearingDate IS NOT NULL
UNION ALL
-- Event: 15. Invoice Cancelled
SELECT
B.InvoiceId AS "Invoice",
'Invoice Cancelled' AS "ActivityName",
B.ReversalDate AS "EventTime",
'SAP_S4HANA' AS "SourceSystem",
CURRENT_UTCTIMESTAMP AS "LastDataUpdate",
B.CreatedByUser AS "UserName", -- User who created the original document
B.CompanyCode AS "CompanyCode",
B.VendorName AS "VendorName",
B.InvoiceAmount AS "InvoiceAmount",
B.PurchaseOrderNumber AS "PurchaseOrderNumber",
B.NetDueDate AS "InvoiceDueDate"
FROM Invoices_Base B
WHERE B.IsReversed = 'X'; Schritte
- Prüfen Sie, ob direkter Lesezugriff auf das SAP-HANA-Schema mit den relevanten SAP-S/4HANA-Tabellen verfügbar ist. Beschaffen Sie die Verbindungszeichenfolge, Zugangsdaten, den Schemanamen und die erforderlichen Berechtigungen zum Lesen von BKPF, ACDOCA sowie weiteren Tabellen für geparkte Belege, Workflow, Einkauf, Wareneingang, Zahlungsvorschläge, Ausgleich und Stornierungsdaten.
- Prüfen Sie vor der Ausführung das technische Datenmodell im Zielsystem. Validieren Sie die physischen Namen, Schlüsselfelder, Timestamp-Felder, Stornierungsbeziehungen, Zahlungsbeziehungen und die im System verwendete Workflow-Persistenz. Ersetzen Sie jeden Platzhalter in eckigen Klammern in der Abfrage durch das entsprechende Objekt oder Feld aus dem System. Gehen Sie nicht davon aus, dass Workflow- oder Daten zu geparkten Belegen in einer einzigen universellen Tabelle gespeichert sind.
- Konfigurieren Sie die Extraktionsparameter. Legen Sie [Start date], [End date], [Company code filter], [Document type filter] und [Schema name] fest. Beginnen Sie mit einem Zeitraum von drei bis sechs Monaten und erweitern Sie ihn erst, nachdem Leistung und Vollständigkeit geprüft wurden.
- Führen Sie die SQL-Abfrage in einem zugelassenen SAP-HANA-SQL-Client aus, zum Beispiel SAP HANA Database Explorer oder einem anderen autorisierten SQL-Ausführungstool. Die Abfrage gibt für jede ausdrücklich extrahierte Aktivität eine Zeile aus. ProcessMind leitet keine Ereignisse ab.
- Validieren Sie das Ergebnis. Prüfen Sie, ob Invoice als Case-Kennung dient, ActivityName alle 15 erforderlichen Aktivitätsnamen enthält, EventTime befüllt und chronologisch plausibel ist, SourceSystem SAP S/4HANA angibt und LastDataUpdate den Timestamp der Extraktionsaktualisierung enthält. Prüfen Sie doppelte Ereignisse, Stornierungsbeziehungen und Belegverknüpfungen, bevor Sie die Daten laden.
- Nehmen Sie erforderliche systembezogene Zuordnungen vor. Ordnen Sie beispielsweise die konfigurierte Quelle geparkter Belege Invoice Parked zu, die konfigurierte Workflow-Quelle Invoice Routed For Approval, Invoice Approved und Invoice Rejected sowie die konfigurierte Zahlungsquelle Payment Proposal Created und Payment Executed. Bewahren Sie die Quellkennungen in zusätzlichen Spalten auf, wenn Auditierbarkeit erforderlich ist.
- Exportieren Sie das Ergebnis als Datei mit Trennzeichen oder als Datenbankergebnismenge mit einem Ereignis pro Zeile. Verwenden Sie UTF-8-Codierung, einheitliche Zeitzonen für Timestamps und exakt die Spaltennamen Invoice, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, CompanyCode, VendorName, InvoiceAmount, PurchaseOrderNumber und InvoiceDueDate. Fassen Sie Aktivitäten nicht je Rechnung zusammen.
- Laden Sie das Event Log in ProcessMind hoch und legen Sie Invoice als Case-Kennung, ActivityName als Aktivitätsspalte und EventTime als Ereigniszeitspalte fest. Prüfen Sie, ob optionale Attribute den entsprechenden Feldern zugeordnet sind. Da ProcessMind das Event Log unverändert einliest, muss jede zu visualisierende Aktivität bereits vor dem Upload als eigene Zeile enthalten sein.
Konfiguration
- Zeitraum: Beginnen Sie mit drei bis sechs Monaten. Verwenden Sie je nach extrahierter Aktivität das Buchungsdatum, Erstellungsdatum des Belegs oder das relevante Quelldatum des Ereignisses. Erweitern Sie den Zeitraum erst, nachdem Sie Abfragelaufzeit und Aufbewahrungsdauer der Quelldaten geprüft haben.
- Buchungskreisfilter: Konfigurieren Sie [Company code filter], um die Extraktion auf die erforderlichen Buchungskreise zu beschränken. Wenn keine Einschränkung erforderlich ist, verwenden Sie eine kontrollierte Auswahl aller Buchungskreise statt einer uneingeschränkten Abfrage in der Produktionsumgebung.
- Belegfilter: Konfigurieren Sie [Document type filter] erst, nachdem Sie die im Zielsystem verwendeten Belegarten für Kreditorenrechnungen, Gutschriften, geparkte Belege, Zahlungsbelege und Stornierungen geprüft haben.
- Schema- und Objektzuordnung: Ersetzen Sie [Schema name] und alle Platzhalter in eckigen Klammern für Quellobjekte oder -felder durch Werte, die im SAP-S/4HANA-Zielsystem überprüft wurden. Eine direkte HANA-Abfrage muss an die aktivierten Anwendungen, Erweiterungen, das Workflow-Design und das Datenmodell des Systems angepasst werden.
- Umgang mit Timestamps: Vereinheitlichen Sie alle Quell-Timestamps auf eine Zeitzone. Wenn nur ein Datum vorliegt, verwenden Sie eine dokumentierte Standarduhrzeit und halten Sie diese Einschränkung im Datenwörterbuch fest.
- Ereignissemantik: Extrahieren Sie jede Aktivität als eigene Zeile. Fassen Sie nicht mehrere Aktivitäten in einem Rechnungssatz zusammen und erwarten Sie nicht, dass ProcessMind Zuordnungs-, Freigabe-, Fälligkeits- oder Ausgleichsereignisse ableitet.
- Fälligkeitsereignis: Erzeugen Sie Invoice Due Date Passed nur für Rechnungen, deren Fälligkeitsdatum vor dem festgelegten Auswertungs-Timestamp liegt und für die bis zu diesem Timestamp kein Ausgleichsereignis vorliegt. Die Abfrage verwendet hierfür [Evaluation timestamp].
- Leistung: Begrenzen Sie zunächst Zeitraum und Buchungskreise, filtern Sie nach indizierten oder für die Partitionierung relevanten Feldern, vermeiden Sie unnötig breite Projektionen und führen Sie die Abfrage in einem genehmigten Berichtszeitfenster aus. Wenn die Abfrage in der Produktionsumgebung die vereinbarte Laufzeit überschreitet, sollten Sie Teilmengen der Quelldaten in einer Staging-Umgebung bereitstellen.
- Aktualisierungsstrategie: Setzen Sie LastDataUpdate auf den Timestamp der Extraktionsausführung. Verwenden Sie bei inkrementellen Ladevorgängen einen Watermark auf Basis des relevanten Änderungs-Timestamps der Quelle und berücksichtigen Sie einen Rückblickzeitraum, damit verspätete Aktualisierungen und Stornierungen erfasst werden.
- Voraussetzungen: Erforderliche Datenbankberechtigungen, genehmigter Zugriff auf die Produktionsumgebung, Kenntnisse der Universal-Journal-Konfiguration des Systems, Zugriff auf die konfigurierten Quellen für geparkte Belege, Einkauf, Wareneingang, Workflow, Zahlung, Ausgleich und Stornierung sowie gegebenenfalls erforderliche SAP-Lizenz- oder Governance-Freigaben.
Beispielabfrage sql
WITH
params AS (
SELECT
TO_DATE('[Start date]') AS start_date,
TO_DATE('[End date]') AS end_date,
TO_TIMESTAMP('[Evaluation timestamp]') AS evaluation_ts,
TO_TIMESTAMP('[Extraction timestamp]') AS extraction_ts
FROM DUMMY
),
base_invoice AS (
SELECT
b.mandt,
b.bukrs,
b.belnr,
b.gjahr,
b.bldat,
b.budat,
b.cpudt,
b.cputm,
b.usnam,
b.blart,
b.xblnr,
b.stblg,
b.stjah,
a.lifnr,
a.wrbtr,
a.waers,
a.zfbdt,
a.zbd1t,
a.zbd2t,
a.zbd3t,
a.ebeln,
a.ebelp,
a.augbl,
a.augdt,
a.buzei,
v.name1 AS vendor_name,
CASE
WHEN a.zfbdt IS NOT NULL THEN ADD_DAYS(a.zfbdt, COALESCE(a.zbd1t, 0))
ELSE NULL
END AS invoice_due_date
FROM [Schema name].BKPF b
INNER JOIN [Schema name].ACDOCA a
ON a.mandt = b.mandt
AND a.rbukrs = b.bukrs
AND a.belnr = b.belnr
AND a.gjahr = b.gjahr
LEFT JOIN [Schema name].[Vendor master table] v
ON v.[Vendor key field] = a.lifnr
CROSS JOIN params p
WHERE b.bukrs IN ([Company code filter])
AND b.blart IN ([Document type filter])
AND b.cpudt BETWEEN p.start_date AND p.end_date
),
invoice_received AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Received' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(cputm), '00:00:00')) AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
),
invoice_parked AS (
SELECT
CAST([Parked invoice key field] AS NVARCHAR(40)) AS invoice,
'Invoice Parked' AS activity_name,
[Parked event timestamp field] AS event_time,
CAST([Parked user field] AS NVARCHAR(80)) AS user_name,
[Parked company code field] AS company_code,
[Parked vendor name field] AS vendor_name,
[Parked amount field] AS invoice_amount,
[Parked currency field] AS document_currency,
CAST([Parked purchase order field] AS NVARCHAR(40)) AS purchase_order_number,
[Parked due date field] AS invoice_due_date
FROM [Schema name].[Parked document source]
WHERE [Parked event date field] BETWEEN (SELECT start_date FROM params) AND (SELECT end_date FROM params)
AND [Parked company code field] IN ([Company code filter])
),
purchase_order_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Purchase Order Matched' AS activity_name,
COALESCE([Purchase order match timestamp field], TO_TIMESTAMP(TO_VARCHAR(i.cpudt, 'YYYY-MM-DD') || ' ' || COALESCE(TO_VARCHAR(i.cputm), '00:00:00'))) AS event_time,
CAST(COALESCE([Purchase order match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrBtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Purchase order match source] m
ON m.[Invoice document key field] = i.belnr
AND m.[Invoice company code field] = i.bukrs
AND m.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
goods_receipt_matched AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Goods Receipt Matched' AS activity_name,
[Goods receipt match timestamp field] AS event_time,
CAST(COALESCE([Goods receipt match user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Goods receipt match source] g
ON g.[Invoice document key field] = i.belnr
AND g.[Invoice company code field] = i.bukrs
AND g.[Invoice fiscal year field] = i.gjahr
WHERE i.ebeln IS NOT NULL
),
invoice_blocked AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Blocked For Payment' AS activity_name,
[Payment block timestamp field] AS event_time,
CAST(COALESCE([Payment block user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block source] b
ON b.[Invoice document key field] = i.belnr
AND b.[Invoice company code field] = i.bukrs
AND b.[Invoice fiscal year field] = i.gjahr
WHERE [Payment block value field] IS NOT NULL
),
discrepancy_resolved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Discrepancy Resolved' AS activity_name,
[Payment block removal timestamp field] AS event_time,
CAST(COALESCE([Payment block removal user field], i.usnam) AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment block history source] h
ON h.[Invoice document key field] = i.belnr
AND h.[Invoice company code field] = i.bukrs
AND h.[Invoice fiscal year field] = i.gjahr
WHERE [Previous payment block value field] IS NOT NULL
AND [New payment block value field] IS NULL
),
invoice_routed_for_approval AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Routed For Approval' AS activity_name,
[Workflow routed timestamp field] AS event_time,
CAST([Workflow initiator field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow routed event value]'
),
invoice_approved AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Approved' AS activity_name,
[Workflow approval timestamp field] AS event_time,
CAST([Workflow approver field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow approved event value]'
),
invoice_rejected AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Rejected' AS activity_name,
[Workflow rejection timestamp field] AS event_time,
CAST([Workflow rejector field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Workflow event source] w
ON w.[Invoice document key field] = i.belnr
AND w.[Invoice company code field] = i.bukrs
AND w.[Invoice fiscal year field] = i.gjahr
WHERE [Workflow event type field] = '[Workflow rejected event value]'
),
invoice_posted AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Posted' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(budat, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(usnam AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NULL
),
payment_proposal_created AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Proposal Created' AS activity_name,
[Payment proposal timestamp field] AS event_time,
CAST([Payment proposal user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment proposal source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
payment_executed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Executed' AS activity_name,
[Payment execution timestamp field] AS event_time,
CAST([Payment execution user field] AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
INNER JOIN [Schema name].[Payment execution source] p
ON p.[Invoice document key field] = i.belnr
AND p.[Invoice company code field] = i.bukrs
AND p.[Invoice fiscal year field] = i.gjahr
),
invoice_due_date_passed AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Invoice Due Date Passed' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.invoice_due_date IS NOT NULL
AND TO_TIMESTAMP(TO_VARCHAR(i.invoice_due_date, 'YYYY-MM-DD') || ' 23:59:59') < (SELECT evaluation_ts FROM params)
AND i.augbl IS NULL
),
payment_cleared AS (
SELECT DISTINCT
CAST(i.belnr AS NVARCHAR(40)) AS invoice,
'Payment Cleared' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR(i.augdt, 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(i.usnam AS NVARCHAR(80)) AS user_name,
i.bukrs AS company_code,
i.vendor_name,
i.wrbtr AS invoice_amount,
i.waers AS document_currency,
CAST(i.ebeln AS NVARCHAR(40)) AS purchase_order_number,
i.invoice_due_date
FROM base_invoice i
WHERE i.augbl IS NOT NULL
AND i.augdt IS NOT NULL
),
invoice_cancelled AS (
SELECT DISTINCT
CAST(belnr AS NVARCHAR(40)) AS invoice,
'Invoice Cancelled' AS activity_name,
TO_TIMESTAMP(TO_VARCHAR([Reversal posting date field], 'YYYY-MM-DD') || ' 00:00:00') AS event_time,
CAST(COALESCE([Reversal user field], usnam) AS NVARCHAR(80)) AS user_name,
bukrs AS company_code,
vendor_name,
wrbtr AS invoice_amount,
waers AS document_currency,
CAST(ebeln AS NVARCHAR(40)) AS purchase_order_number,
invoice_due_date
FROM base_invoice
WHERE stblg IS NOT NULL
),
all_events AS (
SELECT * FROM invoice_received
UNION ALL SELECT * FROM invoice_parked
UNION ALL SELECT * FROM purchase_order_matched
UNION ALL SELECT * FROM goods_receipt_matched
UNION ALL SELECT * FROM invoice_blocked
UNION ALL SELECT * FROM discrepancy_resolved
UNION ALL SELECT * FROM invoice_routed_for_approval
UNION ALL SELECT * FROM invoice_approved
UNION ALL SELECT * FROM invoice_rejected
UNION ALL SELECT * FROM invoice_posted
UNION ALL SELECT * FROM payment_proposal_created
UNION ALL SELECT * FROM payment_executed
UNION ALL SELECT * FROM invoice_due_date_passed
UNION ALL SELECT * FROM payment_cleared
UNION ALL SELECT * FROM invoice_cancelled
)
SELECT
invoice AS "Invoice",
activity_name AS "ActivityName",
event_time AS "EventTime",
'SAP S/4HANA' AS "SourceSystem",
(SELECT extraction_ts FROM params) AS "LastDataUpdate",
user_name AS "UserName",
company_code AS "CompanyCode",
vendor_name AS "VendorName",
invoice_amount AS "InvoiceAmount",
purchase_order_number AS "PurchaseOrderNumber",
invoice_due_date AS "InvoiceDueDate"
FROM all_events
WHERE invoice IS NOT NULL
AND event_time IS NOT NULL
ORDER BY "Invoice", "EventTime", "ActivityName"; Schritte
- Spezifikation und Design: Klären Sie vor der Programmierung gemeinsam mit Business-Analysten die genauen Auslösebedingungen und Datenfelder für jede der 15 erforderlichen Aktivitäten. Ermitteln Sie die relevanten SAP-Tabellen, Belegarten (z. B. 'KR', 'RE') und Buchungskreise, die in den Umfang aufgenommen werden sollen.
- ABAP-Programm erstellen: Öffnen Sie den ABAP Editor über den Transaktionscode SE38. Erstellen Sie ein neues ausführbares Programm, zum Beispiel Z_PM_AP_INVOICE_EXTRACT. Geben Sie einen aussagekräftigen Titel ein und legen Sie als Anwendung 'Financial Accounting' fest.
- Selektionsbild definieren: Definieren Sie im Programm ein Selektionsbild (mit den Schlüsselwörtern PARAMETERS und SELECT-OPTIONS), über das Benutzer den Extraktionszeitraum für das Rechnungsdatum, die Zielbuchungskreise (BUKRS) und die relevanten Rechnungsbelegarten (BLART) angeben können. Fügen Sie außerdem einen Parameter für den Ausgabedateipfad auf dem Applikationsserver hinzu.
- Datendeklarationen: Definieren Sie eine interne Tabellenstruktur, die dem endgültigen Event-Log-Format entspricht (z. B. TY_EVENT_LOG) und alle erforderlichen sowie empfohlenen Attribute enthält. Deklarieren Sie interne Tabellen für Daten aus verschiedenen SAP-Quelltabellen wie BKPF, BSEG, RBKP, RSEG, CDHDR, CDPOS und REGUH.
- Hauptdatenauswahl: Beginnen Sie die Extraktionslogik mit der Auswahl der Rechnungen aus RBKP (Logistikrechnungen) und BKPF (Finanzrechnungen) anhand der Kriterien des Selektionsbilds. Speichern Sie die Schlüssel dieser Rechnungen in einer internen Tabelle, um damit die nachfolgenden Datenabfragen zu steuern.
- Aktivitäten nacheinander extrahieren: Führen Sie für jede Rechnung der Hauptmenge mehrere Abfragen aus, um Timestamps und Details zu den einzelnen Geschäftsaktivitäten zu ermitteln. Fragen Sie beispielsweise CDHDR und CDPOS nach Änderungen an Zahlungssperren, REGUH und REGUP nach Daten zu Zahlungsläufen sowie BKPF nach Stornierungsbelegen ab. Fügen Sie für jede gefundene Aktivität einen neuen Datensatz in die endgültige Event-Log-Tabelle ein.
- Logik für berechnete Ereignisse: Implementieren Sie ABAP-Logik für Aktivitäten, die nicht direkt in einem Tabellenfeld gespeichert sind. Verwenden Sie für das Ereignis 'Invoice Due Date Passed' das Rechnungsfälligkeitsdatum (BSEG-ZFBDT + Zahlungsbedingungen) und das Ausgleichsdatum (BSEG-AUGDT). Liegt das Ausgleichsdatum nach dem Fälligkeitsdatum, erstellen Sie einen neuen Ereignisdatensatz mit dem Fälligkeitsdatum als Timestamp.
- Daten umwandeln und ergänzen: Befüllen Sie beim Erfassen der Daten für jede Aktivität alle erforderlichen Attribute. Dazu gehören das Nachschlagen von Kreditorennamen in LFA1, das Zusammenführen von Datum und Uhrzeit zu einem Timestamp-String (CONCATENATE...INTO...) und das Setzen des Werts für SourceSystem.
- Ausgabedatei erstellen: Schreiben Sie nach der Verarbeitung aller Rechnungen und zugehörigen Aktivitäten die Daten aus der endgültigen internen Tabelle mit den Anweisungen OPEN DATASET, LOOP AT ... TRANSFER und CLOSE DATASET in eine Datei am im Selektionsbild angegebenen Pfad auf dem Applikationsserver.
- Datei herunterladen und für den Upload vorbereiten: Laden Sie die erstellte Datei mit dem Transaktionscode CG3Y vom Applikationsserver auf Ihren lokalen Rechner herunter. Speichern Sie sie als UTF-8-codierte CSV-Datei. Prüfen Sie vor dem Upload in das Process-Mining-Tool, ob die Spaltenüberschriften den erforderlichen Attributen entsprechen (Invoice, ActivityName, EventTime usw.).
Konfiguration
- Zeitraum: Legen Sie die Selektionsoption P_CPUDT für das Erstellungsdatum der Rechnung fest (BKPF-CPUDT oder RBKP-CPUDT). Für eine erste Analyse empfiehlt sich ein Datenzeitraum von sechs bis zwölf Monaten.
- Buchungskreis (P_BUKRS): Ein obligatorischer SELECT-OPTIONS-Parameter zur Filterung nach bestimmten Buchungskreisen. Die Verarbeitung aller Buchungskreise auf einmal wird nur empfohlen, wenn sie unbedingt erforderlich ist.
- Rechnungsbelegart (P_BLART): Ein SELECT-OPTIONS-Parameter zur Filterung nach relevanten Rechnungsbelegarten. Übliche Arten sind 'KR' (Kreditorenrechnung), 'KG' (Kreditorengutschrift) und 'RE' (Logistik-Rechnungsprüfung).
- Ausführungsmodus: Bei großen Datenmengen sollte das Programm als Hintergrundjob (SM36/SM37) ausgeführt werden, um Zeitüberschreitungen im Dialogbetrieb zu vermeiden. Planen Sie die Ausführung außerhalb der Spitzenzeiten.
- Ausgabedateipfad: Ein PARAMETER zur Angabe des Pfads und Dateinamens auf dem SAP-Applikationsserver (z. B. im Verzeichnis /tmp/). Die Datei wird dort vor dem Download gespeichert.
- Voraussetzungen: Der Benutzer, der den Bericht ausführt, benötigt Leseberechtigungen für FI-, CO- und MM-Tabellen (BKPF, BSEG, RBKP, RSEG, LFA1), Änderungsbelegtabellen (CDHDR, CDPOS) und Workflow-Tabellen. Zum Schreiben von Dateien auf dem Applikationsserver ist außerdem das Berechtigungsobjekt S_DATASET erforderlich.
Beispielabfrage abap
*&---------------------------------------------------------------------*
*& Report Z_PM_AP_INVOICE_EXTRACT
*&---------------------------------------------------------------------*
*& This report extracts Accounts Payable invoice lifecycle events for
*& process mining analysis.
*&---------------------------------------------------------------------*
REPORT z_pm_ap_invoice_extract.
*&---------------------------------------------------------------------*
*& Data Structures
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoice TYPE belnr_d,
activityname TYPE string,
eventtime TYPE string,
sourcesystem TYPE logsys,
lastdataupdate TYPE string,
username TYPE uname,
companycode TYPE bukrs,
vendorname TYPE name1_gp,
invoiceamount TYPE wrbtr,
purchaseordernumber TYPE ebeln,
invoiceduedate TYPE d,
END OF ty_event_log.
DATA: gt_event_log TYPE TABLE OF ty_event_log.
DATA: gv_system_id TYPE logsys.
DATA: gv_last_update TYPE string.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_cpudt FOR bkpf-cpudt OBLIGATORY DEFAULT sy-datum,
s_blart FOR bkpf-blart.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/tmp/ap_extract.csv'.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" Get System ID and Update Timestamp
CALL FUNCTION 'OWN_LOGICAL_SYSTEM_GET'
IMPORTING
own_logical_system = gv_system_id
EXCEPTIONS
own_logical_system_not_defined = 1
OTHERS = 2.
CONCATENATE sy-datum sy-uzeit INTO gv_last_update.
" Internal tables for SAP data
DATA: lt_bkpf TYPE TABLE OF bkpf,
lt_rbkp TYPE TABLE OF rbkp.
" Select base documents
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND ( blart = 'KR' OR blart = 'KG' ). " Example FI Invoice Types
SELECT * FROM rbkp INTO TABLE lt_rbkp
WHERE bukrs IN s_bukrs
AND cpudt IN s_cpudt
AND blart IN s_blart
AND blart = 'RE'. " Example MM Invoice Type
" --- Process each invoice document ---
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
PERFORM process_invoice USING <fs_bkpf>.
ENDLOOP.
LOOP AT lt_rbkp ASSIGNING FIELD-SYMBOL(<fs_rbkp>).
PERFORM process_mm_invoice USING <fs_rbkp>.
ENDLOOP.
" Write output to file
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*& Form PROCESS_INVOICE (Handles FI Invoices)
*&---------------------------------------------------------------------*
FORM process_invoice USING iv_bkpf TYPE bkpf.
DATA: ls_bseg TYPE bseg,
ls_lfa1 TYPE lfa1,
ld_due_date TYPE d.
DATA: ls_event TYPE ty_event_log.
" Get Vendor and other details from first line item
SELECT SINGLE * FROM bseg INTO ls_bseg
WHERE bukrs = iv_bkpf-bukrs
AND belnr = iv_bkpf-belnr
AND gjahr = iv_bkpf-gjahr
AND koart = 'K'.
IF sy-subrc = 0.
SELECT SINGLE name1 FROM lfa1 INTO ls_lfa1-name1 WHERE lifnr = ls_bseg-lifnr.
CALL FUNCTION 'DETERMINE_DUE_DATE'
EXPORTING
i_zfbdt = ls_bseg-zfbdt
i_zbd1t = ls_bseg-zbd1t
i_zbd2t = ls_bseg-zbd2t
i_zbd3t = ls_bseg-zbd3t
i_zbd1p = ls_bseg-zbd1p
i_zbd2p = ls_bseg-zbd2p
i_zterm = ls_bseg-zterm
IMPORTING
e_faedt = ld_due_date.
ENDIF.
" Helper function to populate common fields
MACRO set_common_fields.
ls_event-invoice = iv_bkpf-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_bkpf-bukrs.
ls_event-vendorname = ls_lfa1-name1.
ls_event-invoiceduedate = ld_due_date.
SELECT SINGLE wrbtr FROM bseg INTO ls_event-invoiceamount WHERE belnr = iv_bkpf-belnr AND gjahr = iv_bkpf-gjahr AND koart = 'K'.
ENDMACRO.
" 1. Invoice Received
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
" 2. Invoice Parked (if document was created as parked)
IF iv_bkpf-bstat = 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Parked'.
CONCATENATE iv_bkpf-cpudt iv_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 10. Invoice Posted (For non-parked, same as received. For parked, this needs CDHDR/CDPOS logic not shown for brevity)
IF iv_bkpf-bstat <> 'V'.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Posted'.
CONCATENATE iv_bkpf-budat iv_bkpf-cputm INTO ls_event-eventtime. " Using posting date
ls_event-username = iv_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
" 5. & 7. Invoice Blocked / Discrepancy Resolved from Change Docs
DATA: lt_cdhdr TYPE TABLE OF cdhdr, lt_cdpos TYPE TABLE OF cdpos.
DATA(ld_objectkey) = |{ iv_bkpf-bukrs }{ iv_bkpf-belnr }{ iv_bkpf-gjahr }|.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr WHERE objectclas = 'BELEG' AND objectid = ld_objectkey.
IF sy-subrc = 0.
SELECT * FROM cdpos INTO TABLE lt_cdpos FOR ALL ENTRIES IN lt_cdhdr
WHERE changenr = lt_cdhdr-changenr AND tabname = 'BSEG' AND fname = 'ZLSPR'.
LOOP AT lt_cdpos ASSIGNING FIELD-SYMBOL(<fs_cdpos>).
READ TABLE lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>) WITH KEY changenr = <fs_cdpos>-changenr.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
IF <fs_cdpos>-value_new IS NOT INITIAL AND <fs_cdpos>-value_old IS INITIAL.
ls_event-activityname = 'Invoice Blocked For Payment'.
ELSEIF <fs_cdpos>-value_new IS INITIAL AND <fs_cdpos>-value_old IS NOT INITIAL.
ls_event-activityname = 'Discrepancy Resolved'.
ELSE.
CONTINUE.
ENDIF.
CONCATENATE <fs_cdhdr>-udate <fs_cdhdr>-utime INTO ls_event-eventtime.
ls_event-username = <fs_cdhdr>-username.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDLOOP.
ENDIF.
" 6. 8. 9. Workflow Events (Routed, Approved, Rejected) - Simplified Example
" This requires knowledge of specific workflow templates. Placeholder logic:
" SELECT ... FROM SWW_WI2OBJ ... WHERE INSTID = [Invoice Object]
" SELECT ... FROM SWWWIHEAD ... to get status and times
" 11. & 12. & 14. Payment Proposal, Executed, Cleared
IF ls_bseg-augbl IS NOT INITIAL.
DATA: ls_regup TYPE regup.
SELECT SINGLE * FROM regup INTO ls_regup WHERE vblnr = ls_bseg-belnr.
IF sy-subrc = 0.
DATA(ld_rundate) = ls_regup-laufd.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Proposal Created'.
CONCATENATE ld_rundate '000000' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Executed'.
CONCATENATE ls_bseg-augdt '120000' INTO ls_event-eventtime. " Using clearing date as proxy
APPEND ls_event TO gt_event_log.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Payment Cleared'.
CONCATENATE ls_bseg-augdt '120001' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
" 13. Invoice Due Date Passed (Calculated)
IF ls_bseg-augdt IS NOT INITIAL AND ld_due_date IS NOT INITIAL.
IF ls_bseg-augdt > ld_due_date.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Due Date Passed'.
CONCATENATE ld_due_date '235959' INTO ls_event-eventtime.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
" 15. Invoice Cancelled
IF iv_bkpf-stblg IS NOT INITIAL.
DATA: ls_rev_bkpf TYPE bkpf.
SELECT SINGLE * FROM bkpf INTO ls_rev_bkpf WHERE belnr = iv_bkpf-stblg.
IF sy-subrc = 0.
CLEAR ls_event.
set_common_fields.
ls_event-activityname = 'Invoice Cancelled'.
CONCATENATE ls_rev_bkpf-cpudt ls_rev_bkpf-cputm INTO ls_event-eventtime.
ls_event-username = ls_rev_bkpf-usnam.
APPEND ls_event TO gt_event_log.
ENDIF.
ENDIF.
ENDFORM.
*&---------------------------------------------------------------------*
*& Form PROCESS_MM_INVOICE (Handles MM/Logistics Invoices)
*&---------------------------------------------------------------------*
FORM process_mm_invoice USING iv_rbkp TYPE rbkp.
" This form would be similar to PROCESS_INVOICE, but starts with RBKP.
" It needs to find the corresponding FI document in BKPF via AWKEY.
" The logic for PO/GR Matched would be included here.
" For demonstration, creating placeholder events for MM-specific activities.
DATA: ls_event TYPE ty_event_log.
ls_event-invoice = iv_rbkp-belnr.
ls_event-sourcesystem = gv_system_id.
ls_event-lastdataupdate = gv_last_update.
ls_event-companycode = iv_rbkp-bukrs.
" 1. Invoice Received (MM)
ls_event-activityname = 'Invoice Received'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 3. Purchase Order Matched (Implicit)
ls_event-activityname = 'Purchase Order Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" 4. Goods Receipt Matched (Implicit)
ls_event-activityname = 'Goods Receipt Matched'.
CONCATENATE iv_rbkp-cpudt iv_rbkp-cputm INTO ls_event-eventtime.
ls_event-username = iv_rbkp-usnam.
APPEND ls_event TO gt_event_log.
" NOTE: The rest of the events (Block, Pay, etc.) would be found by linking
" RBKP to BKPF and then reusing the logic from PROCESS_INVOICE.
" Link: BKPF-AWKEY = CONCATENATE( RBKP-BELNR, RBKP-GJAHR ).
ENDFORM.
*&---------------------------------------------------------------------*
*& Form WRITE_OUTPUT_FILE
*&---------------------------------------------------------------------*
FORM write_output_file.
DATA: lv_string TYPE string.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_string = 'Invoice,ActivityName,EventTime,SourceSystem,LastDataUpdate,UserName,CompanyCode,VendorName,InvoiceAmount,PurchaseOrderNumber,InvoiceDueDate'.
TRANSFER lv_string TO p_fpath.
" Write Data
LOOP AT gt_event_log ASSIGNING FIELD-SYMBOL(<fs_event>).
" Create a comma-separated string, handling potential commas in data
CONCATENATE <fs_event>-invoice
<fs_event>-activityname
<fs_event>-eventtime
<fs_event>-sourcesystem
<fs_event>-lastdataupdate
<fs_event>-username
<fs_event>-companycode
<fs_event>-vendorname
<fs_event>-invoiceamount
<fs_event>-purchaseordernumber
<fs_event>-invoiceduedate
INTO lv_string SEPARATED BY ','.
TRANSFER lv_string TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'Extraction complete. File written to:', p_fpath.
ENDFORM. Bereit für den Einstieg?
Nutzen Sie dieses Template als Ausgangspunkt für Ihre Process-Mining-Initiative und erschließen Sie Effizienzpotenziale in der Kreditorenbuchhaltung. Starten Sie noch heute mit einem optimierten und schlankeren Prozess.
Vermeiden Sie Mahngebühren: Optimieren Sie noch heute Ihre Rechnungsverarbeitung in der Kreditorenbuchhaltung
Senken Sie die Verarbeitungskosten um 60 % und vermeiden Sie doppelte Zahlungen.
Keine Kreditkarte erforderlich. In wenigen Minuten können Sie loslegen.