Ihr Daten-Template für Record to Report – Journalbuchung
Ihr Daten-Template für Record to Report – Journalbuchung
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für die Analyse
- Praktische Hinweise zur Datenextraktion
Attribute für Record to Report – Journalbuchung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivität ActivityName | Der Name der Geschäftsaktivität, die zu einem bestimmten Zeitpunkt im Buchungsprozess stattgefunden hat. | ||
| Beschreibung Die Aktivität bezeichnet einen bestimmten Schritt oder ein Ereignis im Lebenszyklus einer Buchung, etwa „Buchung erstellt“, „Buchung zur Prüfung eingereicht“ oder „Buchung im Hauptbuch erfasst“. Diese Aktivitäten werden in der Regel aus Änderungsprotokollen, Statusaktualisierungen oder im System gespeicherten Transaktionscodes abgeleitet. Durch die Analyse der Aktivitäten lässt sich der Prozessablauf visualisieren, lassen sich häufige Pfade erkennen und Abweichungen von der Standardvorgehensweise aufdecken. Sie ist grundlegend für die Berechnung von Kennzahlen wie der Aktivitätshäufigkeit, Wartezeiten zwischen Schritten und Konformitätsraten. Warum das wichtig ist Das Attribut definiert die Prozessschritte und ermöglicht die Visualisierung von Prozesslandkarten sowie die Analyse von Workflow-Mustern. Woher beziehen Abgeleitet aus verschiedenen Quellen, darunter Statusfelder in Kopf- und Einzelpostentabellen, zum Beispiel BKPF-BSTAT, Änderungsbelegprotokolle (CDHDR/CDPOS) und Workflow-Protokolle. Beispiele Buchung erstelltBuchung geparktBuchung zur Prüfung eingereichtBuchung freigegebenBuchung im Hauptbuch erfasst | |||
| Buchungs-ID JournalEntryId | Der eindeutige Identifikator einer Finanzbuchung, der als primäre Case-ID des Prozesses dient. | ||
| Beschreibung Die Buchungs-ID ist eine eindeutige Nummer, die jedem Buchhaltungsbeleg bei seiner Erstellung in SAP S/4HANA zugewiesen wird. Mit dieser Kennung lässt sich der gesamte Lebenszyklus einer Buchung verfolgen, von der Erstellung oder dem Parken über Freigabe-Workflows bis hin zur endgültigen Buchung und einer möglichen Stornierung oder einem Ausgleich. In der Process-Mining-Analyse dient diese ID dazu, alle zugehörigen Aktivitäten zu einem Case zusammenzuführen. Wenn Analysten Ereignisse unter einer gemeinsamen Buchungs-ID gruppieren, können sie den durchgängigen Prozessablauf rekonstruieren, Zykluszeiten messen und Abweichungen oder Engpässe für jede einzelne Finanztransaktion erkennen. Dieses grundlegende Attribut bildet die Basis für die gesamte Prozessansicht. Warum das wichtig ist Diese Kennung verknüpft alle zugehörigen Prozessschritte. So lässt sich der durchgängige Ablauf jeder Buchung analysieren. Woher beziehen Dies ist ein zusammengesetzter Schlüssel, der üblicherweise aus Buchungskreis (BKPF-BUKRS), Belegnummer (BKPF-BELNR) und Geschäftsjahr (BKPF-GJAHR) gebildet wird. Beispiele 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Ereigniszeit EventTime | Der Timestamp, der angibt, wann eine bestimmte Aktivität für die Buchung stattgefunden hat. | ||
| Beschreibung Die Ereigniszeit ist das genaue Datum und die genaue Uhrzeit, zu der eine Geschäftsaktivität ausgeführt und im System erfasst wurde. Jede Aktivität in einem Case hat einen eigenen Timestamp. Zusammen bilden sie eine chronologische Abfolge von Ereignissen. Dieses Attribut ist für alle zeitbasierten Prozessanalysen entscheidend. Es dient zur Berechnung von Zykluszeiten, Zeitspannen zwischen Aktivitäten und Wartezeiten sowie zur Analyse der zeitlichen Verteilung der Arbeit. Genaue Timestamps sind unverzichtbar, um ein zuverlässiges Prozessmodell zu erstellen und wichtige Leistungskennzahlen wie die Freigabezykluszeit zu berechnen. Warum das wichtig ist Das Attribut gibt die chronologische Reihenfolge der Ereignisse an. Diese ist entscheidend für die Berechnung aller zeitbasierten Kennzahlen und das Verständnis des Prozessverlaufs. Woher beziehen Aus Änderungsbelegprotokollen (CDHDR-UDATE, CDHDR-UTIME), Workflow-Protokollen oder Erstellungs- und Erfassungs-Timestamps in Tabellen wie BKPF (CPUDT, CPUTM). Beispiele 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| Belegart JournalEntryType | Ordnet den Buchungsbeleg nach seinem Geschäftszweck ein, zum Beispiel als Anlagenbuchung, Lieferantenrechnung oder Hauptbuchbuchung. | ||
| Beschreibung Die Belegart, in SAP auch Dokumentart genannt, klassifiziert Buchhaltungsbelege. Sie legt unter anderem den Nummernkreis des Belegs und die zulässigen Kontenarten für die Buchung fest. Die Analyse nach Belegart ist wichtig, um Unterschiede im Prozesskontext zu verstehen. So kann die Freigabe einer einfachen Abgrenzung (Typ SA) deutlich weniger aufwendig sein als die einer komplexen Anlagenbeschaffung (Typ AA). Diese Dimension ist zentral für das Dashboard „Compliance nach Belegart“. Warum das wichtig ist Ordnet Buchungen nach ihrem Geschäftskontext und ermöglicht den Vergleich von Prozessabläufen und Leistung bei unterschiedlichen Finanztransaktionen. Woher beziehen SAP-S/4HANA-Tabelle BKPF, Feld BLART (Belegart). Beispiele SAKRAA | |||
| Betrag in Hauswährung AmountInLocalCurrency | Der Gesamtwert des Buchungsbelegs, ausgedrückt in der Hauswährung des Buchungskreises. | ||
| Beschreibung Dieses Attribut gibt den finanziellen Umfang des Buchungsbelegs an. In der Regel entspricht es der Summe der absoluten Werte aller Soll- oder Habenpositionen des Belegs, umgerechnet in die Hauswährung des Buchungskreises. Die Analyse nach Betrag ermöglicht es, den Prozess nach finanzieller Auswirkung aufzuschlüsseln. Für Buchungen mit hohen Beträgen kann beispielsweise ein strengeres Freigabeverfahren gelten als für kleinere Beträge. So können Verbesserungsmaßnahmen auf Transaktionen mit dem höchsten finanziellen Risiko ausgerichtet werden. Warum das wichtig ist Gibt den finanziellen Wert der Buchung an und ermöglicht zu analysieren, wie sich das Prozessverhalten je nach betroffenem Geldbetrag verändert. Woher beziehen Wird berechnet, indem die Beträge aus der Positionstabelle BSEG (Feld DMBTR) für einen Buchungsbeleg (BELNR) summiert und als positiver Wert ausgegeben werden. Beispiele 1500.75125000.0050.20 | |||
| Buchungsdatum PostingDate | Das Datum, an dem der Buchungsbeleg im Hauptbuch erfasst wird und das damit die Finanzperiode bestimmt. | ||
| Beschreibung Das Buchungsdatum bestimmt, in welcher Geschäftsjahresperiode die Transaktion im Abschluss erscheint. Es ist für die Buchhaltung entscheidend und kann vom Erstellungsdatum oder dem Zeitpunkt der Eingabe ins System abweichen. Beim Process Mining dient das Buchungsdatum der zeitbezogenen Kohortenanalyse, etwa zum Vergleich von Monatsabschlussprozessen oder zur Untersuchung von Leistungstrends über verschiedene Finanzperioden hinweg. Außerdem lässt sich damit die Verzögerung zwischen der Erstellung des Belegs und seiner tatsächlichen Buchung messen. Warum das wichtig ist Das Buchungsdatum liefert den nötigen Finanzkontext für die Analyse der Prozessleistung in bestimmten Buchhaltungsperioden, etwa zum Monats- oder Jahresabschluss. Woher beziehen SAP-S/4HANA-Tabelle BKPF, Feld BUDAT (Buchungsdatum im Beleg). Beispiele 2023-10-312023-11-012024-02-29 | |||
| Buchungskreis CompanyCode | Die eindeutige Kennung des Unternehmens oder der juristischen Person, für die der Buchungsbeleg gebucht wird. | ||
| Beschreibung Der Buchungskreis ist eine zentrale Organisationseinheit in SAP Financials. Er steht für eine eigenständige juristische Person, für die Abschlüsse erstellt werden. Jeder Buchungsbeleg wird einem bestimmten Buchungskreis zugeordnet. Dieses Attribut ist entscheidend, um die Prozessleistung in verschiedenen Bereichen der Organisation aufzuschlüsseln und zu vergleichen. Analysten können die Prozessansicht nach einer bestimmten juristischen Person filtern, Ablehnungsquoten zwischen Buchungskreisen vergleichen oder regionale Prozessunterschiede erkennen. Warum das wichtig ist Ermöglicht es, den Buchungsprozess für verschiedene juristische Personen oder Geschäftseinheiten innerhalb der Organisation zu filtern und zu vergleichen. Woher beziehen SAP-S/4HANA-Tabelle BKPF, Feld BUKRS (Buchungskreis). Beispiele 10001710US01 | |||
| Erstellt von Benutzer CreatedByUser | Die Benutzer-ID der Person, die den Buchungsbeleg erstellt hat. | ||
| Beschreibung Dieses Attribut speichert die eindeutige Kennung des Benutzers, der den Buchungsprozess mit dem Erstellen des ersten Belegs gestartet hat. Dabei kann es sich um einen Buchhalter, einen Fachanwender oder bei automatisierten Buchungen um eine System-ID handeln. Die Analyse nach Ersteller zeigt Muster bei bestimmten Benutzern oder Teams. Sie kann auf Schulungsbedarf hinweisen, wenn einzelne Benutzer häufiger Ablehnungen erhalten, oder besonders leistungsstarke Mitarbeitende sichtbar machen. Das Attribut ist eine wichtige Grundlage für das Dashboard „Benutzeraktivität und Durchsatz“. Warum das wichtig ist Ordnet Prozessaktivitäten bestimmten Benutzern zu. So lassen sich Leistung und Arbeitslast analysieren und Schulungsbedarf erkennen. Woher beziehen SAP-S/4HANA-Tabelle BKPF, Feld USNAM (Benutzername). Beispiele ABROWNCJONESBATCH_USER | |||
| Belegstatus DocumentStatus | Der aktuelle Verarbeitungsstatus des Buchungsbelegs, zum Beispiel vorläufig erfasst, gebucht oder ausgeglichen. | ||
| Beschreibung Der Belegstatus zeigt, an welcher Stelle im Lebenszyklus sich ein Buchungsbeleg befindet. Ein vorläufig erfasster Beleg ist beispielsweise gespeichert, aber noch nicht ins Hauptbuch gebucht. Ein gebuchter Beleg hingegen ist abgeschlossen. Die Statusanalyse hilft, den Arbeitsablauf zu verstehen und Engpässe zu erkennen. Bleiben viele Belege lange im Status „vorläufig erfasst“ oder „Freigabe ausstehend“, kann das auf Ineffizienzen im Prozess hinweisen. Der Status ist außerdem eine wichtige Grundlage, um Prozessaktivitäten abzuleiten. Warum das wichtig ist Zeigt den aktuellen Stand eines Buchungsbelegs im Lebenszyklus und hilft, Warteschlangen und Engpässe zu erkennen. Woher beziehen SAP-S/4HANA-Tabelle BKPF, Feld BSTAT (Belegstatus). Beispiele VAB | |||
| Endzeit EndTime | Der Timestamp, der angibt, wann die Aktivität abgeschlossen wurde. | ||
| Beschreibung Die Endzeit markiert den Abschluss einer Aktivität. In vielen Event Logs sind Startzeit und Endzeit einer Aktivität identisch, weil es sich um ein punktuelles Ereignis handelt. Bei Aktivitäten mit messbarer Dauer, etwa der aktiven Prüfung eines Dokuments durch einen Benutzer, kann dieses Attribut die Dauer erfassen. Eine separate Endzeit ermöglicht eine genauere Berechnung der Verarbeitungszeit und der Wartezeit einer Aktivität. So lässt sich unterscheiden, wie lange aktiv an einer Aufgabe gearbeitet wurde und wie lange sie unbearbeitet in einer Warteschlange lag. Warum das wichtig ist Ermöglicht die genaue Berechnung der Verarbeitungszeit einer Aktivität und trennt aktive Arbeitszeit von Wartezeit. Woher beziehen Bei punktuellen Ereignissen entspricht die Endzeit in der Regel der StartTime. Bei Aktivitäten mit einer Dauer kann sie aus Workflow-Protokollen stammen oder anhand nachfolgender Ereignisse berechnet werden. Beispiele 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Freigabezykluszeit ApprovalCycleTime | Die Zeitspanne zwischen der Einreichung eines Buchungsbelegs zur Freigabe und seiner Freigabe oder Ablehnung. | ||
| Beschreibung Diese berechnete Kennzahl erfasst gezielt die Dauer der Freigabephase. Sie misst die Zeit zwischen der Aktivität „Buchungsbeleg zur Prüfung eingereicht“ und der anschließenden Aktivität „Buchungsbeleg freigegeben“ oder „Buchungsbeleg abgelehnt“. Die Kennzahl ist entscheidend, um Engpässe im Freigabe-Workflow zu erkennen. Lange Freigabezykluszeiten können den gesamten Prozess erheblich verzögern. Eine Auswertung nach freigebendem Benutzer, Buchungskreis oder Belegart kann konkrete Verbesserungsmöglichkeiten aufzeigen. Warum das wichtig ist Erfasst gezielt die Dauer des Freigabeschritts und hilft, Engpässe im Prüf- und Freigabe-Workflow zu erkennen und zu beheben. Woher beziehen Wird berechnet, indem die Zeit zwischen dem Ereignis „Buchungsbeleg zur Prüfung eingereicht“ und dem Ereignis „Buchungsbeleg freigegeben“ oder „Buchungsbeleg abgelehnt“ ermittelt wird. Beispiele 1 Tag 2 Stunden4 Stunden 25 Minuten5 Tage 0 Stunden | |||
| Freigebender Benutzer ApproverUser | Die Benutzer-ID der Person, die den Buchungsbeleg freigegeben oder abgelehnt hat. | ||
| Beschreibung Dieses Attribut bezeichnet den Benutzer, der einen eingereichten Buchungsbeleg prüft und darüber entscheidet. Bei einem mehrstufigen Freigabe-Workflow können mehrere Benutzer für einen Beleg zuständig sein. Diese Information ist wichtig für die detaillierte Analyse des Freigabeprozesses. Sie hilft, die Arbeitslast der einzelnen Freigebenden zu messen, individuelle Freigabezeiten zu berechnen und Engpässe in der Freigabekette zu erkennen. Das Attribut unterstützt direkt das Dashboard „Benutzeraktivität und Durchsatz“. Warum das wichtig ist Zeigt, wer für die Freigabe zuständig ist. So lassen sich Arbeitslast, Leistung und Engpässe im Freigabeprozess analysieren. Woher beziehen Wird aus Workflow-Protokollen (z. B. SWW_WI2OBJ, SWWLOG) oder Änderungsbelegtabellen (CDHDR/CDPOS) ermittelt, indem nachverfolgt wird, wer den Freigabeschritt ausgeführt hat. Beispiele DMILLERFWHITEKCHEN | |||
| Geschäftsjahr FiscalYear | Das Geschäftsjahr, zu dem der Buchungsbeleg gehört. | ||
| Beschreibung Das Geschäftsjahr ist neben dem Buchungskreis und der Belegnummer Teil des eindeutigen Schlüssels eines Buchungsbelegs. Es bezeichnet das Geschäftsjahr, für das der Beleg relevant ist. In Analysen dient das Geschäftsjahr der langfristigen Trendanalyse und hilft, die Eindeutigkeit der Case-ID sicherzustellen. Der Vergleich von Prozesskennzahlen über mehrere Geschäftsjahre hinweg zeigt, wie sich die Leistung im Zeitverlauf verbessert oder verschlechtert hat. Warum das wichtig ist Ist ein wichtiger Bestandteil zur eindeutigen Identifizierung von Belegen und ermöglicht den Vergleich der Prozessleistung über mehrere Geschäftsjahre hinweg. Woher beziehen SAP-S/4HANA-Tabelle BKPF, Feld GJAHR (Geschäftsjahr). Beispiele 202320242022 | |||
| Letzte Datenaktualisierung LastDataUpdate | Timestamp der letzten Aktualisierung der Daten dieses Datensatzes aus dem Quellsystem. | ||
| Beschreibung Dieses Attribut enthält Datum und Uhrzeit der letzten Datenextraktion oder Aktualisierung aus dem Quellsystem. So ist nachvollziehbar, wie aktuell die analysierten Daten sind. Der Zeitpunkt der letzten Aktualisierung hilft dabei, die Aktualität der Prozessanalyse einzuschätzen. Benutzer können Dashboards und Kennzahlen richtig einordnen und erkennen, ob sie nahezu Echtzeitdaten oder einen Datenstand aus einem früheren Zeitraum betrachten. Warum das wichtig ist Zeigt, wie aktuell die Daten sind, damit Benutzer den zeitlichen Stand der Prozessanalyse einschätzen können. Woher beziehen Dieses Metadatenattribut wird üblicherweise während der Datenübernahme erzeugt und jedem Datensatz hinzugefügt. Beispiele 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Manuelle Buchung IsManualPosting | Ein boolesches Kennzeichen dafür, ob ein Benutzer den Buchungsbeleg manuell gebucht hat. | ||
| Beschreibung Dieses Attribut kennzeichnet Buchungsbelege, die ein Benutzer manuell gebucht hat, statt sie automatisch über einen Systemauftrag oder eine Schnittstelle zu verarbeiten. In der Regel wird es anhand des Transaktionscodes abgeleitet, mit dem der Beleg gebucht wurde. Das Kennzeichen dient zur Berechnung der Kennzahl „Anteil manueller Buchungen“ und hilft Unternehmen, Fortschritte bei der Automatisierung des Record-to-Report-Prozesses zu verfolgen. Durch das Filtern manueller Buchungen können Analysten erkennen, in welchen Fällen noch ein manueller Eingriff erforderlich ist und ob sich diese Abläufe automatisieren lassen. Warum das wichtig ist Unterscheidet zwischen manuellen und systemgesteuerten Buchungen. Das ist entscheidend, um den Automatisierungsgrad zu messen und Automatisierungspotenziale zu erkennen. Woher beziehen Dieses berechnete Attribut wird aus dem TransactionCode abgeleitet. Eine vordefinierte Liste manueller Transaktionscodes, zum Beispiel „FB01“ und „F-02“, setzt das Kennzeichen auf „true“. Beispiele truefalse | |||
| Nacharbeit erforderlich IsRework | Ein boolesches Kennzeichen dafür, ob der Buchungsbeleg nachbearbeitet wurde, zum Beispiel nach einer Ablehnung. | ||
| Beschreibung Dieses berechnete Attribut kennzeichnet Buchungsbelege, deren Ablauf vom idealen Happy Path abweicht. Es wird in der Regel auf „true“ gesetzt, wenn im Case eine Aktivität wie „Buchungsbeleg abgelehnt“ oder „Buchungsbeleg korrigiert“ vorkommt. Das Kennzeichen vereinfacht die Analyse der Prozesseffizienz. Damit lässt sich die Kennzahl „Nacharbeitsquote“ schnell berechnen und Zykluszeiten sowie Kosten von Cases mit und ohne Nacharbeit direkt vergleichen. Die Ursachen für Nacharbeit zu ermitteln, ist ein zentrales Ziel vieler Prozessverbesserungsinitiativen. Warum das wichtig ist Kennzeichnet Cases, bei denen Korrekturen oder zusätzliche Schleifen erforderlich waren. So lassen sich Ineffizienzen einfach quantifizieren und ihre Ursachen analysieren. Woher beziehen Dieses berechnete Attribut wird aus der Aktivitätsfolge eines Cases abgeleitet. Es wird auf „true“ gesetzt, wenn eine Aktivität wie „Buchungsbeleg abgelehnt“ vorkommt. Beispiele truefalse | |||
| Quellsystem SourceSystem | Gibt an, aus welchem Quellsystem die Buchungsdaten exportiert wurden. | ||
| Beschreibung Dieses Attribut gibt das führende System an, aus dem die Buchungsdaten stammen. Bei Unternehmen mit mehreren ERP-Instanzen oder einer Mischung aus älteren und modernen Systemen lassen sich damit die Datenquellen unterscheiden. In Analysen können Sie die Prozessleistung systemübergreifend vergleichen oder die Daten nach einer bestimmten Quelle filtern. Das Attribut ist wichtig für die Data Governance und hilft, den Kontext der Daten richtig einzuordnen. Warum das wichtig ist Gibt Aufschluss über die Herkunft der Daten. Das ist in Systemlandschaften mit mehreren Systemen entscheidend für präzise Prozessanalysen und aussagekräftige Vergleiche. Woher beziehen Dieser statische Wert wird in der Regel beim Extrahieren der Daten ergänzt. Er bezeichnet die jeweilige SAP-S/4HANA-Instanz, zum Beispiel anhand der SID oder des logischen Systemnamens. Beispiele S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Stornogrund ReversalReason | Ein Code, der den Grund für die Stornierung eines gebuchten Buchungsbelegs angibt. | ||
| Beschreibung Ist ein gebuchter Buchungsbeleg fehlerhaft, kann er nicht gelöscht werden. Stattdessen muss er mit einem neuen Beleg storniert werden. Der Stornogrund gibt an, warum dies erforderlich war, zum Beispiel wegen eines falschen Buchungsdatums oder Betrags. Die Analyse der Stornogründe hilft, die Ursachen von Fehlern im Record-to-Report-Prozess zu ermitteln. Häuft sich ein bestimmter Grund, kann das auf systemische Probleme wie unzureichende Schulungen oder fehlende Kontrollen hinweisen. Diese sollten behoben werden, um die Qualität beim ersten Durchlauf zu verbessern. Warum das wichtig ist Hilft, die Ursachen von Fehlern zu ermitteln, die zu Stornierungen führen. Die Erkenntnisse daraus können Nacharbeit verringern und die Prozessqualität verbessern. Woher beziehen SAP-S/4HANA-Tabelle BKPF, Feld STGRD (Stornogrund). Beispiele 010205 | |||
| Transaktionscode TransactionCode | Der SAP-Transaktionscode, mit dem der Buchungsbeleg erstellt oder geändert wurde. | ||
| Beschreibung Der Transaktionscode (T-Code) ist eine Abkürzung für eine bestimmte Funktion oder ein Programm in SAP. Bei Buchungsbelegen geben unterschiedliche T-Codes Aufschluss darüber, wie ein Beleg erstellt wurde, zum Beispiel FB01 für eine manuelle Hauptbuchbuchung, FV50 für das Vorläufigstellen oder ein automatisierter Code für systemgenerierte Buchungen. Dieses Attribut zeigt deutlich, ob eine Aktivität manuell von einem Benutzer oder automatisch vom System ausgeführt wurde. Es ist wichtig für die Berechnung der Kennzahl „Anteil manueller Buchungen“ und hilft, Automatisierungspotenziale zu erkennen. Warum das wichtig ist Zeigt, wie eine Buchung verarbeitet wurde, etwa manuell oder automatisch. Das ist wichtig für die Automatisierungsanalyse und zum Verständnis von Prozessunterschieden. Woher beziehen SAP-S/4HANA-Tabelle BKPF, Feld TCODE (Transaktionscode). Beispiele FB01FV50F-02 | |||
Aktivitäten für Record to Report – Journalbuchung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Buchung ausgeglichen | Ein offener Einzelposten einer Buchung wird durch eine andere Buchung ausgeglichen, zum Beispiel wenn eine Zahlung eine Rechnung ausgleicht. Diese Aktivität kennzeichnet den Abgleich bestimmter Einzelposten und schließt sie damit ab. | ||
| Warum das wichtig ist Bei vielen Buchungen, insbesondere auf Verrechnungs- oder offenen Posten verwalteten Konten, ist dies der letzte Schritt des Abgleichs. Wenn Sie die Zeit zwischen Buchung und Ausgleich analysieren, können Sie die Effizienz des Abgleichs messen. Woher beziehen Dieses Ereignis wird aus der Einzelpostentabelle (BSEG oder der ACDOCA-Ansicht) abgeleitet. Beim Ausgleich eines Postens werden die Felder für Ausgleichsdatum (AUGDT) und Ausgleichsbeleg (AUGBL) für diesen Posten ausgefüllt. Erfassung Verwenden Sie das Ausgleichsdatum (BSEG-AUGDT) des Einzelpostens als Timestamp des Ereignisses. Ereignistyp inferred | |||
| Buchung erstellt | Diese Aktivität kennzeichnet die erstmalige Erstellung eines Buchungsbelegs im System. Der Beleg wird in der Kopftabelle (BKPF) angelegt, aber noch nicht im Hauptbuch gebucht. Damit beginnt der Lebenszyklus der Buchung. | ||
| Warum das wichtig ist Dies ist das primäre Start-Event des Prozesses. Die Zeit zwischen diesem Ereignis und der Buchung ist entscheidend, um die gesamte Zykluszeit zu messen und Verzögerungen bei der anfänglichen Dateneingabe zu erkennen. Woher beziehen Dieses Ereignis lässt sich direkt anhand der Felder für Erstellungsdatum (CPUDT) und Erstellungszeit (CPUTM) in der SAP-Tabelle BKPF für eine bestimmte Belegnummer (BELNR) erfassen. Erfassung Verwenden Sie BKPF-CPUDT und BKPF-CPUTM als Timestamp des Ereignisses. Ereignistyp explicit | |||
| Buchung freigegeben | Ein autorisierter Manager erteilt die endgültige Freigabe für die Buchung und bestätigt damit ihre Gültigkeit und Richtigkeit. Dies ist die letzte Kontrollstufe, bevor der Beleg im Hauptbuch gebucht werden kann. | ||
| Warum das wichtig ist Dies ist ein wichtiger Meilenstein, der den Freigabezyklus abschließt. Die Zeit bis zu diesem Schritt macht einen wesentlichen Teil der gesamten Prozessdauer aus und ist ein wichtiger Indikator für die Effizienz der Freigebenden. Woher beziehen Dieses Ereignis wird aus einem Workflow-Protokoll abgeleitet, das den letzten Freigabeschritt zeigt, oder aus einer Statusänderung des Belegs. Benutzer-ID und Timestamp des Freigebenden lassen sich den Workflow-Daten oder Änderungsprotokollen entnehmen. Erfassung Ermitteln Sie den Timestamp des letzten Freigabeschritts in den Workflow-Protokollen oder die Statusänderung zu „Genehmigt“ in den Änderungsbelegen. Ereignistyp inferred | |||
| Buchung im Hauptbuch erfasst | Die Buchung wird offiziell im Hauptbuch erfasst und wirkt sich auf den Jahresabschluss des Unternehmens aus. Ab diesem Zeitpunkt ist der Beleg ein dauerhafter Finanzdatensatz. | ||
| Warum das wichtig ist Dies ist der zentrale Erfolgsmeilenstein und markiert das Ende des eigentlichen Verarbeitungszyklus. Der Durchsatz gebuchter Belege und die Zeit bis zu diesem Schritt sind grundlegende Kennzahlen im Process Mining. Woher beziehen Dieses Ereignis wird explizit durch das Buchungsdatum (BUDAT) in der Tabelle BKPF gekennzeichnet. Bei einem gebuchten Beleg ist der Belegstatus (BSTAT) leer. So lässt er sich von geparkten ('V') oder vorgemerkten ('D') Belegen unterscheiden. Erfassung Verwenden Sie das Buchungsdatum (BKPF-BUDAT) und das Erfassungsdatum (BKPF-CPUDT) als Timestamp des Ereignisses. Ein leeres BKPF-BSTAT kennzeichnet einen gebuchten Beleg. Ereignistyp explicit | |||
| Buchung zur Prüfung eingereicht | Der Ersteller der Buchung reicht den Beleg formell für den Prüfungs- und Freigabe-Workflow ein. Damit wird die Übergabe von der Dateneingabe an den formellen Kontrollprozess markiert und der Freigabezyklus gestartet. | ||
| Warum das wichtig ist Damit beginnt die Zykluszeit der Freigabe. Wenn Sie die Zeit bis zur endgültigen Freigabe oder Ablehnung messen, können Sie Engpässe gezielt in den Prüfungs- und Freigabeschritten erkennen. Woher beziehen Dieses Ereignis wird häufig in Workflow-Protokollen (Tabellen SWW_WIHEAD, SWWLOG) erfasst, die mit dem Geschäftsobjekt verknüpft sind. Es lässt sich auch aus einer Statusänderung in einem benutzerdefinierten Feld im Belegkopf (BKPF) ableiten. Erfassung Timestamp der Erstellung des Workflow-Elements oder Zeitpunkt, zu dem sich ein Statusfeld in „Eingereicht“ oder „In Prüfung“ ändert. Ereignistyp inferred | |||
| Buchungsstornierung verarbeitet | Eine zuvor gebuchte Buchung wird durch einen neuen Beleg mit umgekehrten Buchungen storniert. Diese explizite, auditfähige Transaktion dient dazu, Fehler in gebuchten Belegen zu korrigieren. | ||
| Warum das wichtig ist Stornierungen weisen auf einen Fehler in einem gebuchten Beleg hin. Eine hohe Stornierungsquote deutet auf grundlegende Probleme im Freigabeprozess oder bei der Qualität der Dateneingabe hin. Wenn Sie Stornierungen erfassen, können Sie die Genauigkeit beim ersten Durchlauf verbessern. Woher beziehen Die Stornierung ist ein explizites Ereignis. Der Kopf des neuen Stornobelegs (BKPF) verweist im Feld für die stornierte Belegnummer (STBLG) auf den ursprünglichen Beleg. Das Buchungsdatum des neuen Belegs ist der Zeitpunkt des Ereignisses. Erfassung Ermitteln Sie Belege, bei denen BKPF-STBLG ausgefüllt ist. Als Timestamp des Ereignisses dient das Buchungsdatum des Stornobelegs. Ereignistyp explicit | |||
| Belege angehängt | Ein Benutzer hängt einen oder mehrere Belege, etwa Rechnungen oder Tabellen, an die Buchung an. Diese dienen als Nachweis und liefern Kontext zur Finanztransaktion während der Prüfung und des Audits. | ||
| Warum das wichtig ist Belege vor der Prüfung anzuhängen, ist entscheidend für Compliance und effiziente Freigaben. Anhand dieser Aktivität lässt sich messen, ob die Dokumentationsvorgaben eingehalten werden und wie sich dies auf die Freigabezeiten auswirkt. Woher beziehen Dieses Ereignis wird üblicherweise anhand des Erstellungs-Timestamps von Anhängen ermittelt, die über Generic Object Services (GOS) verknüpft sind. Die Tabelle SRGBTBREL verknüpft das Geschäftsobjekt, zum Beispiel einen BKPF-Beleg, mit dem Anhang. Erfassung Fragen Sie die GOS-Anhangtabellen, zum Beispiel SRGBTBREL, nach Verknüpfungen zum BKPF-Objekt ab und verwenden Sie den Erstellungs-Timestamp des Anhangs. Ereignistyp inferred | |||
| Buchung abgelehnt | Ein Prüfer oder Freigebender lehnt die Buchung ab und verhindert damit ihre Buchung. In der Regel wird der Beleg zur Korrektur an den Ersteller zurückgesendet. Dadurch beginnt eine Nacharbeitsschleife. | ||
| Warum das wichtig ist Ablehnungen zu erfassen, ist entscheidend, um die Prozessqualität zu verstehen und häufige Fehler zu erkennen. Eine hohe Ablehnungsquote weist auf Probleme mit der Datengenauigkeit, dem Verständnis von Richtlinien oder fehlenden Belegen hin. Woher beziehen Dieses Ereignis wird aus einer Statusänderung im Workflow-Protokoll oder einem benutzerdefinierten Statusfeld des Buchungsbelegs abgeleitet. Änderungsbelege (CDHDR/CDPOS) zum betreffenden Statusfeld können den Timestamp liefern. Erfassung Ermitteln Sie über Änderungsbelege (CDHDR/CDPOS) oder Workflow-Protokolle eine Statusänderung zu „Abgelehnt“. Ereignistyp inferred | |||
| Buchung geparkt | Ein Benutzer speichert eine unvollständige Buchung, ohne sie zu buchen. Sie kann später vervollständigt oder geprüft werden. Durch diese explizite Aktion wird ein Belegkopf mit dem Status „geparkt“ angelegt, der Beleg bleibt dabei ungebucht. | ||
| Warum das wichtig ist Das Parken ist ein üblicher Schritt vor der Einreichung. Wenn Sie die Dauer des geparkten Status erfassen, erkennen Sie Verzögerungen bei der Vervollständigung und Vorbereitung der Daten, bevor die formelle Prüfung und Freigabe beginnt. Woher beziehen In der Tabelle BKPF erkennen Sie einen geparkten Beleg am Belegstatusfeld (BSTAT) mit dem Wert 'V'. Als Timestamp des Ereignisses dient das Erstellungsdatum (CPUDT). Erfassung Filtern Sie zum Erstellungszeitpunkt nach Belegen mit BKPF-BSTAT = 'V'. Ereignistyp explicit | |||
| Buchung korrigiert | Ein Benutzer ändert eine Buchung, nachdem sie abgelehnt oder zur Überarbeitung zurückgesendet wurde. Damit wird der Nacharbeitsaufwand erfasst, der erforderlich ist, um die bei der Prüfung festgestellten Probleme vor der erneuten Einreichung zu beheben. | ||
| Warum das wichtig ist Mit dieser Aktivität werden Nacharbeitsschleifen quantifiziert. Wenn Sie Häufigkeit und Dauer von Korrekturen analysieren, erkennen Sie Ineffizienzursachen und Möglichkeiten für Schulungen und klarere Prozesse. Woher beziehen Dieses Ereignis lässt sich anhand des Felds „Zuletzt geändert am“ (AEDAT) in der Tabelle BKPF ableiten, wenn sich der Beleg zuvor im Status „Abgelehnt“ befand. Änderungsbelege liefern genauere Angaben zu den vorgenommenen Änderungen. Erfassung Verwenden Sie für Änderungen nach einer Ablehnung den Timestamp aus den Änderungsbelegköpfen (CDHDR-UDATE). Ereignistyp inferred | |||
| Buchung nach der Buchung geändert | Ein Benutzer ändert bestimmte Felder einer Buchung, nachdem sie bereits im Hauptbuch erfasst wurde. Die meisten Finanzdaten sind nach der Buchung unveränderlich, einige Felder wie Texte oder Zuordnungen lassen sich jedoch ändern. | ||
| Warum das wichtig ist Diese Aktivität ist ein wichtiges Compliance-Signal. Änderungen nach der Buchung können auf Versuche hindeuten, Datensätze zu manipulieren. Sie sollten daher genau überwacht werden, um Betrug zu verhindern und die Datenintegrität zu sichern. Woher beziehen Dieses Ereignis lässt sich zuverlässig aus den Änderungsbelegtabellen (CDHDR und CDPOS) ableiten. Ein Eintrag in CDHDR zur Belegnummer mit einem Änderungsdatum nach dem Buchungsdatum weist auf eine Änderung nach der Buchung hin. Erfassung Suchen Sie in CDHDR nach Datensätzen, bei denen der Änderungs-Timestamp (UDATE/UTIME) nach dem Buchungsdatum des Belegs (BKPF-BUDAT) liegt. Ereignistyp inferred | |||
| Manuelle Buchung erkannt | Die Buchung wurde mit einem manuellen Transaktionscode statt über eine automatisierte Schnittstelle oder einen Batch-Job gebucht. Dies ist kein zeitliches Ereignis, sondern eine Klassifizierung der Buchungsaktivität. | ||
| Warum das wichtig ist Manuelle Buchungen zu erkennen, ist für Automatisierungsinitiativen entscheidend. Ein hoher Anteil manueller Buchungen weist auf Möglichkeiten hin, Prozesse durch die Integration von Subsystemen oder den Einsatz automatisierter Buchungsprogramme zu vereinfachen. Woher beziehen Diese Klassifizierung erfolgt anhand des Transaktionscodefelds (TCODE) in der Belegkopftabelle (BKPF). Eine Liste bekannter manueller Transaktionscodes, zum Beispiel FB01, F-02 und FB50, dient zur Einordnung der Buchung. Erfassung Klassifizieren Sie das Ereignis anhand von BKPF-TCODE und einer vordefinierten Liste manueller Transaktionscodes zum Buchungszeitpunkt. Ereignistyp calculated | |||
Anleitungen zur Datenextraktion
Schritte
- Voraussetzungen und Zugriff: Stellen Sie sicher, dass Ihnen ein Benutzerkonto mit den erforderlichen Berechtigungen zum Abfragen der zugrunde liegenden SAP-S/4HANA-Datenbank oder zum Ausführen von ABAP-Berichten zur Verfügung steht. Sie benötigen Lesezugriff auf die CDS-Views I_JournalEntry und I_JournalEntryItem sowie auf die Tabellen CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ und SWWLOGHIST. Der Zugriff erfolgt üblicherweise über einen Datenbank-Client wie SAP HANA Studio oder DBeaver oder über SAP ABAP Development Tools (ADT) für Eclipse.
- Systemspezifische Konfiguration ermitteln: Ermitteln Sie vor der Abfrage die Task-Codes, die in Ihrem Freigabe-Workflow für Journalbuchungen verwendet werden. Fragen Sie Ihre SAP-Workflow-Administration nach den Task-IDs (z. B. TS12345678) für Einreichungs-, Ablehnungs- und Freigabeereignisse. Diese IDs werden für die Platzhalter in der abschließenden Abfrage benötigt.
- SQL-Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt
queryin den gewünschten SQL-Client oder das Entwicklungstool. - Abfrageparameter festlegen: Suchen Sie die Platzhalter in der Abfrage und ersetzen Sie sie durch Ihre konkreten Werte. Dazu gehören
[YourCompanyCode],[StartDate]und[EndDate]. Ersetzen Sie außerdem die Platzhalter für die Workflow-Task-IDs ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) durch die Werte aus dem vorherigen Schritt. - Extraktionsabfrage ausführen: Führen Sie die angepasste SQL-Abfrage für die SAP-S/4HANA-Datenbank aus. Je nach Zeitraum und Datenvolumen kann die Ausführung längere Zeit in Anspruch nehmen. Wir empfehlen, die Abfrage außerhalb der Spitzenzeiten auszuführen.
- Ergebnisse zunächst prüfen: Prüfen Sie nach Abschluss der Abfrage die ersten Zeilen der Ausgabe. Stellen Sie sicher, dass alle Spalten, etwa JournalEntryId, ActivityName und EventTime, wie erwartet befüllt sind. Das Ergebnis sollte für jedes einzelne Geschäftsereignis im Lebenszyklus der Journalbuchung eine Zeile enthalten.
- Daten als CSV exportieren: Exportieren Sie das gesamte Ergebnis aus Ihrem SQL-Tool in eine einzelne CSV-Datei. Verwenden Sie UTF-8, damit Sonderzeichen korrekt dargestellt werden.
- Upload vorbereiten: Prüfen Sie vor dem Upload in ein Process-Mining-Tool, ob die CSV-Datei die erforderlichen Spaltenüberschriften enthält. Die Daten liegen bereits als Event Log vor. Eine weitere Umwandlung oder Pivotierung sollte daher nicht erforderlich sein.
Konfiguration
- Core Data Services (CDS)-Views: Für die Extraktion werden hauptsächlich
I_JournalEntryfür Kopfdaten undI_JournalEntryItemfür Einzelposten und Beträge verwendet. Diese Views bieten eine vereinfachte, semantisch aussagekräftige Schnittstelle zum Universal Journal (ACDOCA). - Ergänzende Tabellen: Für eine vollständige Prozesssicht verknüpft die Abfrage außerdem mehrere SAP-Standardtabellen:
CDHDRundCDPOSzur Nachverfolgung von Dokumentänderungen.SRGBRELundSOOD, um zu ermitteln, wann Anhänge über Generic Object Services (GOS) verknüpft werden.SWW_WI2OBJundSWWLOGHISTzum Extrahieren wichtiger Ereignisse aus dem Freigabe-Workflow.
- Filter für den Zeitraum: Ein festgelegter Zeitraum ist entscheidend für die Abfrageleistung. Verwenden Sie im
WHERE-Abschnitt das FeldI_JournalEntry.CreationDateTime. Für eine erste Analyse empfehlen wir einen Zeitraum von 3 bis 6 Monaten. - Filter für die Organisation: Filtern Sie immer nach
CompanyCode, damit nur relevante Rechtseinheiten extrahiert werden. Eine Abfrage aller Buchungskreise auf einmal kann in großen Systemen sehr lange dauern. - Workflow-Task-IDs: Die Abfrage enthält Platzhalter für Workflow-Task-IDs (z. B.
[Workflow Approved Task ID]). Diese IDs sind in jeder SAP-Installation unterschiedlich und müssen korrekt konfiguriert sein, damit Workflow-Aktivitäten extrahiert werden. Ohne sie werden keine Einreichungs-, Freigabe- oder Ablehnungsereignisse erfasst. - Voraussetzungen: Der ausführende Benutzer benötigt umfangreiche Leseberechtigungen für Finanz-, System- und Workflow-Tabellen. Diese Berechtigungen sind nicht standardmäßig vorhanden und müssen gezielt zugewiesen werden.
a Beispielabfrage sql
WITH JournalEntryAmountCTE AS (
SELECT
CompanyCode,
AccountingDocument,
FiscalYear,
SUM(AmountInCompanyCodeCurrency) AS AmountInLocalCurrency
FROM I_JournalEntryItem
GROUP BY CompanyCode, AccountingDocument, FiscalYear
),
JournalEntryBaseCTE AS (
SELECT
JE.CompanyCode,
JE.AccountingDocument,
JE.FiscalYear,
JE.CreatedByUser,
JE.CreationDateTime,
JE.PostingDateTime,
JE.PostingDate,
JE.AccountingDocumentType,
JE.DocumentIsParked,
JE.ReversedJournalEntry,
JE.TransactionCode,
JEA.AmountInLocalCurrency
FROM I_JournalEntry AS JE
LEFT JOIN JournalEntryAmountCTE AS JEA
ON JE.CompanyCode = JEA.CompanyCode
AND JE.AccountingDocument = JEA.AccountingDocument
AND JE.FiscalYear = JEA.FiscalYear
WHERE JE.CompanyCode IN ('[YourCompanyCode]')
AND JE.CreationDateTime BETWEEN '[StartDate]' AND '[EndDate]'
)
-- 1. Journal Entry Created
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
UNION ALL
-- 2. Journal Entry Parked
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
BJE.CreationDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 3. Supporting Documentation Attached
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Supporting Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(SOOD.CREDAT || ' ' || SOOD.CRETIM, 'YYYYMMDD HH24MISS') AS "EventTime",
SOOD.OWNER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SRGBREL ON SRGBREL.INSTID_A = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND SRGBREL.TYPEID_A = 'BKPF'
AND SRGBREL.CATID_A = 'BO'
JOIN SOOD ON SOOD.OBJTP = SRGBREL.TYPEID_B
AND SOOD.OBJYR = SRGBREL.INSTID_B(3)
AND SOOD.OBJNO = SRGBREL.INSTID_B(5)
UNION ALL
-- 4. Journal Submitted For Review
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Submitted For Review' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Submitted Task ID]'
UNION ALL
-- 5. Journal Entry Rejected
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Rejected' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Rejected Task ID]'
UNION ALL
-- 6. Journal Entry Corrected (changed while parked)
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.DocumentIsParked = 'X'
UNION ALL
-- 7. Journal Entry Approved
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Approved' AS "ActivityName",
LOG.END_TS AS "EventTime",
LOG.EXEC_USER AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN SWW_WI2OBJ AS WF_LINK ON WF_LINK.INSTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND WF_LINK.TYPEID = 'BKPF'
JOIN SWWLOGHIST AS LOG ON LOG.WI_ID = WF_LINK.WI_ID
WHERE LOG.METHOD = '[Workflow Approved Task ID]'
UNION ALL
-- 8. Manual Posting Identified
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Manual Posting Identified' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL AND BJE.TransactionCode IN ('FB01', 'F-02', 'FB50', 'FV50', 'FBB1', 'FBV1')
UNION ALL
-- 9. Journal Entry Posted
SELECT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
BJE.PostingDateTime AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
WHERE BJE.PostingDateTime IS NOT NULL
UNION ALL
-- 10. Journal Entry Changed After Posting
SELECT DISTINCT
BJE.AccountingDocument AS "JournalEntryId",
'Journal Entry Changed After Posting' AS "ActivityName",
TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') AS "EventTime",
CH.USERNAME AS "CreatedByUser",
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS BJE
JOIN CDHDR AS CH ON CH.OBJECTID = CONCAT(BJE.CompanyCode, BJE.AccountingDocument, BJE.FiscalYear)
AND CH.OBJECTCLASS = 'BELEG'
WHERE BJE.PostingDateTime IS NOT NULL AND TO_TIMESTAMP(CH.UDATE || ' ' || CH.UTIME, 'YYYYMMDD HH24MISS') > BJE.PostingDateTime
UNION ALL
-- 11. Journal Entry Cleared
SELECT
JEI.AccountingDocument AS "JournalEntryId",
'Journal Entry Cleared' AS "ActivityName",
MIN(JEI.ClearingDateTime) AS "EventTime",
BJE.CreatedByUser AS "CreatedByUser", -- Note: Clearing user is not directly available here
BJE.CompanyCode AS "CompanyCode",
BJE.AccountingDocumentType AS "JournalEntryType",
BJE.PostingDate AS "PostingDate",
BJE.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM I_JournalEntryItem AS JEI
JOIN JournalEntryBaseCTE AS BJE ON JEI.AccountingDocument = BJE.AccountingDocument
AND JEI.CompanyCode = BJE.CompanyCode
AND JEI.FiscalYear = BJE.FiscalYear
WHERE JEI.ClearingDateTime IS NOT NULL
GROUP BY JEI.AccountingDocument, BJE.CreatedByUser, BJE.CompanyCode, BJE.AccountingDocumentType, BJE.PostingDate, BJE.AmountInLocalCurrency
UNION ALL
-- 12. Journal Entry Reversal Processed
SELECT
OriginalDoc.AccountingDocument AS "JournalEntryId",
'Journal Entry Reversal Processed' AS "ActivityName",
ReversalDoc.PostingDateTime AS "EventTime",
ReversalDoc.CreatedByUser AS "CreatedByUser",
OriginalDoc.CompanyCode AS "CompanyCode",
OriginalDoc.AccountingDocumentType AS "JournalEntryType",
OriginalDoc.PostingDate AS "PostingDate",
OriginalDoc.AmountInLocalCurrency AS "AmountInLocalCurrency"
FROM JournalEntryBaseCTE AS ReversalDoc
JOIN JournalEntryBaseCTE AS OriginalDoc
ON ReversalDoc.ReversedJournalEntry = OriginalDoc.AccountingDocument
AND ReversalDoc.CompanyCode = OriginalDoc.CompanyCode
AND ReversalDoc.ReversalFiscalYear = OriginalDoc.FiscalYear
WHERE ReversalDoc.ReversedJournalEntry IS NOT NULL; Schritte
- Bestätigen Sie, dass der direkte SQL-Zugriff auf die SAP-HANA-Datenbank freigegeben ist und der Extraktionsbenutzer Leseberechtigungen für BKPF und ACDOCA besitzt. Prüfen Sie außerdem den Zugriff auf alle in Ihrem System konfigurierten Quellen für Workflow-, Anhangs-, Änderungshistorien-, Ausgleichs- oder Stornierungsereignisse. Der direkte Datenbankzugriff erfolgt üblicherweise über SAP HANA Database Explorer, SAP HANA Studio oder einen freigegebenen SQL-Client. Führen Sie Extraktionsabfragen nicht in einer SAP-Anwendungstransaktion aus, sofern Ihr System diesen Zugriff nicht ausdrücklich unterstützt.
- Prüfen Sie das physische Schema von BKPF und ACDOCA, einschließlich Mandantenfeld, Buchungskreisfeld, Geschäftsjahresfeld, Belegnummernfeld, Belegartfeld, Buchungsdatumsfeld, Erstellungsdatumsfeld, Erstellungszeitfeld, Benutzerfeld, Feld für den Betrag in Hauswährung sowie etwaiger Storno- oder Ausgleichsfelder. SAP-S/4HANA-Installationen können sich hinsichtlich Schema und verfügbaren Feldern unterscheiden. Ersetzen Sie daher die Platzhalter in eckigen Klammern durch Felder, die Sie in Ihrem System überprüft haben.
- Ermitteln Sie die maßgeblichen Quellen für Workflow- und Anhangsereignisse. BKPF und ACDOCA enthalten Daten zu Buchhaltungsbelegen und Einzelposten, bilden aber nicht zuverlässig alle geparkten, eingereichten, abgelehnten, korrigierten, freigegebenen oder mit Anhängen versehenen Vorgänge ab. Ersetzen Sie die Platzhalter für Workflow- und Anhangsquellen durch freigegebene Views oder Tabellen Ihrer Implementierung. Ist eine Quelle nicht verfügbar, erfinden Sie keine Ereignisse. Konfigurieren Sie die entsprechende Quelle oder schließen Sie die Aktivität mit dokumentierter Freigabe aus.
- Legen Sie die Extraktionsparameter für den gewünschten Zeitraum, die Buchungskreise, Belegarten und den Mandanten fest. Für die erste Validierung empfehlen wir einen Zeitraum von drei bis sechs Monaten. Verwenden Sie für operative Ereignisse den Ereigniszeitraum und für Buchhaltungsereignisse den Buchungszeitraum, entsprechend dem vereinbarten Prozessumfang.
- Führen Sie die vollständige SQL-Abfrage im freigegebenen HANA-SQL-Client aus. Die Abfrage erstellt für jede ausdrücklich extrahierte Aktivität eine Ereigniszeile. Für Buchhaltungsereignisse verwendet sie BKPF und ACDOCA, für Workflow-, Anhangs-, Änderungs-, Ausgleichs- und Stornierungsereignisse die konfigurierten Quell-Views. Sie leitet keine Aktivitäten allein daraus ab, dass ein Beleg vorhanden ist.
- Prüfen Sie das Ausgabeschema. JournalEntryId ist die Case-ID, ActivityName die Aktivitätsbezeichnung und EventTime der Ereigniszeitpunkt. Die empfohlenen Geschäftsattribute werden zurückgegeben, sofern sie verfügbar sind. Vergewissern Sie sich, dass EventTime ein Timestamp ist und alle Zeilen eine nicht leere JournalEntryId und ActivityName enthalten.
- Stimmen Sie den Umfang der Buchhaltungsdaten ab, indem Sie die unterschiedlichen JournalEntryId-Werte mit dem erwarteten BKPF-Datenbestand für den ausgewählten Mandanten, die Buchungskreise, Geschäftsjahre und den Zeitraum vergleichen. Gleichen Sie Workflow- und Anhangsdaten separat ab, da Aufbewahrungsfristen und Regeln für Zeitstempel von den Buchhaltungsdaten abweichen können.
- Prüfen Sie die Ereignisreihenfolge und den Umgang mit Duplikaten. Mehrere Einzelposten in ACDOCA dürfen keine doppelten Buchhaltungsereignisse erzeugen, sofern das Prozessdesign keine Ereignisse auf Einzelpostenebene vorsieht. Verwenden Sie die Aggregationslogik der Abfrage, um je Journalbuchung und Ereignistyp ein Buchhaltungsereignis zu erzeugen. Behalten Sie dabei, sofern verfügbar, die konfigurierten Quellereignis-IDs bei.
- Exportieren Sie das Ergebnis als UTF-8-kodierte CSV-Datei oder in einem anderen von ProcessMind unterstützten Tabellenformat. Behalten Sie die Spaltennamen JournalEntryId, ActivityName und EventTime exakt bei. Sortieren Sie die Datei nach JournalEntryId und EventTime und führen Sie weitere Attribute als Spalten. Laden Sie die Datei in ProcessMind hoch und konfigurieren Sie JournalEntryId als Case-ID, ActivityName als Aktivität und EventTime als Ereigniszeitpunkt.
Konfiguration
- Zeitraum: Beginnen Sie mit drei bis sechs Monaten. Verwenden Sie für Leistungstests einen kürzeren Zeitraum und erweitern Sie ihn erst, wenn Zeilenanzahl und Ereignisabdeckung geprüft sind.
- Mandanten- und Buchungskreisbeschränkung: Legen Sie [Client parameter] fest und beschränken Sie CompanyCode auf die erforderlichen Rechtseinheiten. Lassen Sie in einem System mit mehreren Mandanten die Mandantenbedingung nicht weg.
- Buchhaltungsumfang: Konfigurieren Sie [Document type filter] und gegebenenfalls Filter für Geschäftsjahr und Buchungsdatum. Nehmen Sie gebuchte und nicht gebuchte Belege nur dann auf, wenn die ausgewählte Quelle beide zuverlässig abbildet.
- Workflow-Umfang: Konfigurieren Sie [Workflow event source] und die Zuordnung der Ereignistypen zu den Aktivitäten „Eingereicht“, „Abgelehnt“, „Korrigiert“ und „Freigegeben“. Prüfen Sie, ob die Zeitstempel die Erstellung, Ausführung oder den Abschluss der Workflow-Aktion angeben.
- Umfang der Anhänge: Konfigurieren Sie [Attachment event source] und das Beziehungsfeld, über das ein Anhang mit der Journalbuchung verknüpft ist. Prüfen Sie, ob die Quelle das Erstellen, Ersetzen oder Löschen von Anhängen erfasst.
- Änderungsumfang: Konfigurieren Sie [Change history source] für Änderungen nach der Buchung. Prüfen Sie, ob die Quelle die Journalbuchung identifiziert und einen zuverlässigen Änderungszeitpunkt bereitstellt.
- Umfang der Ausgleiche: Konfigurieren Sie [Clearing source] und die Beziehung zwischen dem ausgeglichenen Buchhaltungsbeleg und dem Ausgleichsbeleg. Legen Sie fest, ob das Ereignis der ursprünglichen Journalbuchung, dem Ausgleichsbeleg oder beiden zugeordnet werden soll.
- Umfang der Stornierungen: Konfigurieren Sie [Reversal source] und die Beziehung zwischen Original- und Stornobeleg. Wenn diese Beziehung verfügbar ist, ordnet die Abfrage die Stornierungsaktivität der ursprünglichen JournalEntryId zu.
- Klassifizierung manueller Buchungen: Konfigurieren Sie [Manual posting source] oder ein geprüftes Feld zur Buchungsherkunft. „Manuelle Buchung erkannt“ ist ein Klassifizierungsereignis. Verwenden Sie dafür durchgängig den Buchungszeitpunkt oder einen anderen freigegebenen Zeitstempel.
- Währungsbetrag: ACDOCA enthält Daten auf Einzelpostenebene. Die Abfrage aggregiert Beträge in Hauswährung je Journalbuchung. Prüfen Sie das Vorzeichen und legen Sie fest, ob statistische, ledger-spezifische oder Erweiterungsledger-Zeilen einbezogen werden sollen.
- Leistung: Wählen Sie nur erforderliche Spalten aus, filtern Sie früh, vermeiden Sie uneingeschränkte Scans von ACDOCA und führen Sie die Abfrage in einem freigegebenen Berichtszeitfenster aus. Verwenden Sie, sofern unterstützt, die Partitionseinschränkung über Mandant, Geschäftsjahr, Buchungskreis und Buchungsdatum.
- Umgang mit Duplikaten: Verwenden Sie verfügbare Quellereignis-IDs. Enthält eine Quelle wiederholte technische Datensätze, wenden Sie die dokumentierte Deduplizierungsregel an, ohne tatsächlich getrennte Workflow-Aktionen zusammenzufassen.
- Voraussetzungen: Erforderliche Datenbankberechtigungen, freigegebene SAP-HANA-Verbindung, Zugriff auf die konfigurierten Workflow- und Anhangsquellen, passende Konfiguration für SAP Financial Accounting und Workflow sowie ein von ProcessMind unterstütztes Exportformat.
a Beispielabfrage sql
WITH
accounting_base AS (
SELECT
b.[Client field] AS ClientId,
b.[Company code field] AS CompanyCode,
b.[Fiscal year field] AS FiscalYear,
b.[Document number field] AS AccountingDocumentNumber,
b.[Document type field] AS JournalEntryType,
b.[Created by field] AS CreatedByUser,
b.[Document date field] AS DocumentDate,
b.[Posting date field] AS PostingDate,
b.[Creation date field] AS CreationDate,
b.[Creation time field] AS CreationTime,
b.[Reversal document field] AS ReversalDocumentNumber,
b.[Reversed document field] AS ReversedDocumentNumber,
b.[Reversal fiscal year field] AS ReversalFiscalYear,
SUM(a.[Local currency amount field]) AS AmountInLocalCurrency,
MAX(a.[Local currency field]) AS LocalCurrency
FROM [Your schema].[BKPF] b
INNER JOIN [Your schema].[ACDOCA] a
ON a.[Client field] = b.[Client field]
AND a.[Company code field] = b.[Company code field]
AND a.[Fiscal year field] = b.[Fiscal year field]
AND a.[Document number field] = b.[Document number field]
WHERE b.[Client field] = '[Client parameter]'
AND b.[Company code field] IN ([Company code filter])
AND b.[Posting date field] BETWEEN '[Start date parameter]' AND '[End date parameter]'
AND b.[Document type field] IN ([Document type filter])
GROUP BY
b.[Client field],
b.[Company code field],
b.[Fiscal year field],
b.[Document number field],
b.[Document type field],
b.[Created by field],
b.[Document date field],
b.[Posting date field],
b.[Creation date field],
b.[Creation time field],
b.[Reversal document field],
b.[Reversed document field],
b.[Reversal fiscal year field]
),
base_cases AS (
SELECT
ClientId,
CompanyCode,
FiscalYear,
AccountingDocumentNumber,
CAST(CompanyCode || '/' || FiscalYear || '/' || AccountingDocumentNumber AS NVARCHAR(100)) AS JournalEntryId,
JournalEntryType,
CreatedByUser,
PostingDate,
AmountInLocalCurrency,
LocalCurrency,
CreationDate,
CreationTime,
ReversalDocumentNumber,
ReversedDocumentNumber,
ReversalFiscalYear
FROM accounting_base
),
created_events AS (
SELECT
JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CreationDate || ' ' || CreationTime AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
),
parked_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Parked event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
attachment_events AS (
SELECT
CAST(x.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Supporting Documentation Attached' AS ActivityName,
CAST(x.[Event timestamp field] AS TIMESTAMP) AS EventTime,
x.[User field] AS CreatedByUser,
x.[Company code field] AS CompanyCode,
x.[Journal entry type field] AS JournalEntryType,
x.[Posting date field] AS PostingDate,
x.[Amount in local currency field] AS AmountInLocalCurrency,
x.[Local currency field] AS LocalCurrency
FROM [Your schema].[Attachment event source] x
WHERE x.[Client field] = '[Client parameter]'
AND x.[Event type field] = '[Attachment created event type]'
AND CAST(x.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
submitted_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Submitted For Review' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Submitted event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
rejected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Rejected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Rejected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
corrected_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Corrected event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
approved_events AS (
SELECT
CAST(w.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Approved' AS ActivityName,
CAST(w.[Event timestamp field] AS TIMESTAMP) AS EventTime,
w.[User field] AS CreatedByUser,
w.[Company code field] AS CompanyCode,
w.[Journal entry type field] AS JournalEntryType,
w.[Posting date field] AS PostingDate,
w.[Amount in local currency field] AS AmountInLocalCurrency,
w.[Local currency field] AS LocalCurrency
FROM [Your schema].[Workflow event source] w
WHERE w.[Client field] = '[Client parameter]'
AND w.[Event type field] = '[Approved event type]'
AND CAST(w.[Event timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
manual_events AS (
SELECT
JournalEntryId,
'Manual Posting Identified' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Manual posting condition verified for this system]
),
posted_events AS (
SELECT
JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(PostingDate AS TIMESTAMP) AS EventTime,
CreatedByUser,
CompanyCode,
JournalEntryType,
PostingDate,
AmountInLocalCurrency,
LocalCurrency
FROM base_cases
WHERE [Posted document condition verified for this system]
),
changed_events AS (
SELECT
CAST(c.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Changed After Posting' AS ActivityName,
CAST(c.[Change timestamp field] AS TIMESTAMP) AS EventTime,
c.[User field] AS CreatedByUser,
c.[Company code field] AS CompanyCode,
c.[Journal entry type field] AS JournalEntryType,
c.[Posting date field] AS PostingDate,
c.[Amount in local currency field] AS AmountInLocalCurrency,
c.[Local currency field] AS LocalCurrency
FROM [Your schema].[Change history source] c
WHERE c.[Client field] = '[Client parameter]'
AND c.[Post posting change indicator field] = '[Post posting change value]'
AND CAST(c.[Change timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
cleared_events AS (
SELECT
CAST(cl.[Journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Cleared' AS ActivityName,
CAST(cl.[Clearing timestamp field] AS TIMESTAMP) AS EventTime,
cl.[User field] AS CreatedByUser,
cl.[Company code field] AS CompanyCode,
cl.[Journal entry type field] AS JournalEntryType,
cl.[Posting date field] AS PostingDate,
cl.[Amount in local currency field] AS AmountInLocalCurrency,
cl.[Local currency field] AS LocalCurrency
FROM [Your schema].[Clearing source] cl
WHERE cl.[Client field] = '[Client parameter]'
AND CAST(cl.[Clearing timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
),
reversal_events AS (
SELECT
CAST(r.[Original journal entry ID field] AS NVARCHAR(100)) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(r.[Reversal timestamp field] AS TIMESTAMP) AS EventTime,
r.[User field] AS CreatedByUser,
r.[Company code field] AS CompanyCode,
r.[Journal entry type field] AS JournalEntryType,
r.[Posting date field] AS PostingDate,
r.[Amount in local currency field] AS AmountInLocalCurrency,
r.[Local currency field] AS LocalCurrency
FROM [Your schema].[Reversal source] r
WHERE r.[Client field] = '[Client parameter]'
AND CAST(r.[Reversal timestamp field] AS DATE) BETWEEN '[Start date parameter]' AND '[End date parameter]'
)
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM created_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM parked_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM attachment_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM submitted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM rejected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM corrected_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM approved_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM manual_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM posted_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM changed_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM cleared_events
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, CreatedByUser, CompanyCode, JournalEntryType, PostingDate, AmountInLocalCurrency, LocalCurrency FROM reversal_events
ORDER BY JournalEntryId, EventTime, ActivityName; Schritte
- ABAP-Programm erstellen: Öffnen Sie den ABAP Editor mit dem Transaktionscode
SE38. Geben Sie einen Namen für das neue Programm ein, zum BeispielZ_PM_JE_EXTRACT, und wählen Sie „Erstellen“. Vergeben Sie einen passenden Titel, setzen Sie „Typ“ auf „Ausführbares Programm“ und speichern Sie das Programm als lokales Objekt oder in einem Paket. - Selektionsbild definieren: Legen Sie im Programm Parameter und Select-Options fest, mit denen Benutzer die Daten filtern können. Dazu gehören ein Zeitraum für das Erstellungsdatum der Journalbuchung (
P_CPUDT_FR,P_CPUDT_TO), eine Select-Option für den Buchungskreis (SO_BUKRS) und ein Dateipfad für die Ausgabe auf dem Anwendungsserver (P_FPATH). - Datenstrukturen deklarieren: Definieren Sie eine interne Tabellenstruktur, die dem erforderlichen Event-Log-Format entspricht und die endgültige Ausgabe enthält. Deklarieren Sie außerdem interne Tabellen und Arbeitsbereiche für die auszulesenden SAP-Tabellen, etwa BKPF, ACDOCA, CDHDR, CDPOS und verschiedene Workflow-Tabellen.
- Logik für die Datenauswahl implementieren: Schreiben Sie die ABAP-Kernlogik, um Daten für jede der 12 erforderlichen Aktivitäten abzurufen. Legen Sie für jede Aktivität eine eigene Unterroutine (FORM) an, damit der Code übersichtlich bleibt. Erstellen Sie beispielsweise FORM-Routinen für
get_created_events,get_parked_eventsundget_workflow_events. - Ereignisse „Erstellt“ und „Gebucht“ auswählen: Lesen Sie die Tabelle BKPF anhand der Kriterien aus, die im Selektionsbild eingegeben wurden. Ein Eintrag in BKPF steht für die Erstellung. Ein Beleg mit dem Status
BSTAT = ' 'gilt als gebucht. Verwenden Sie den Erstellungszeitstempel (CPUDT,CPUTM) als Ereigniszeitpunkt. - Ereignisse „Geparkt“ auswählen: Lesen Sie die Tabelle VBKPF aus, in der die Kopfdaten geparkter Belege gespeichert sind. Der Erstellungszeitstempel dieser Tabelle gibt den Zeitpunkt des Parkens an.
- Workflow-Ereignisse auswählen (eingereicht, freigegeben, abgelehnt): Fragen Sie Workflow-Tabellen wie SWW_WI2OBJ ab, um ein Journalbuchungsobjekt mit einer Workflow-Instanz zu verknüpfen, und SWWLOGHIST oder SWWIHEAD, um Details und Zeitpunkte bestimmter Schritte abzurufen. Ermitteln Sie die Task-IDs für Einreichung, Freigabe und Ablehnung, die in Ihrem System verwendet werden.
- Ereignisse „Geändert“ und „Korrigiert“ auswählen: Fragen Sie die Änderungsbelegtabellen CDHDR (Kopf) und CDPOS (Position) für
OBJECTCLAS = 'BELEG'ab. Filtern Sie für „Nach der Buchung geändert“ nach Änderungen, deren Zeitstempel nach dem Buchungsdatum des Belegs liegt. Filtern Sie für „Korrigiert“ nach Änderungen an geparkten oder abgelehnten Belegen. - Ereignisse „Storniert“ und „Ausgeglichen“ auswählen: Ermitteln Sie Stornierungen anhand von Belegen, bei denen das Feld
STBLG(Nummer des stornierten Belegs) in BKPF befüllt ist. Als Ereigniszeitpunkt verwenden Sie den Erstellungszeitpunkt des Stornobelegs. Ermitteln Sie Ausgleichsereignisse, indem Sie aus ACDOCA das jüngste Ausgleichsdatum (AUGDT) für die Einzelposten einer Journalbuchung auswählen. - Daten zusammenführen und sortieren: Fügen Sie die ausgewählten Daten jeder Aktivität in die interne Mastertabelle ein. Sortieren Sie die Mastertabelle nach Abschluss aller Abfragen nach
JournalEntryIdundEventTime, damit die Ereignisse jedes Case chronologisch geordnet sind. - Ausgabedatei erstellen: Schreiben Sie den Inhalt der sortierten internen Mastertabelle mit den Anweisungen
OPEN DATASET,LOOP AT... TRANSFERundCLOSE DATASETin den angegebenen Dateipfad auf dem SAP-Anwendungsserver. Die Datei muss im CSV-Format vorliegen und eine Kopfzeile enthalten. - Ausführung einplanen: Richten Sie für regelmäßige Extraktionen mit dem Transaktionscode
SM36einen Hintergrundjob ein, der das ProgrammZ_PM_JE_EXTRACTnach einem festgelegten Zeitplan ausführt, zum Beispiel wöchentlich oder monatlich. So wird der Datenexport automatisiert.
Konfiguration
- Zeitraum: Das Selektionsbild muss einen verpflichtenden Zeitraum für das Erstellungsdatum der Journalbuchung (
CPUDT) enthalten. Für eine gute Leistung empfiehlt es sich, die Daten in überschaubaren Abschnitten von jeweils 3 bis 6 Monaten zu extrahieren. - Buchungskreis (
BUKRS): Dieser wichtige Filter beschränkt die Extraktion auf die Rechtseinheiten, die für die Process-Mining-Analyse relevant sind. Es wird nicht empfohlen, alle Buchungskreise auf einmal zu extrahieren. - Belegart (
BLART): Mit diesem optionalen Filter können Sie bestimmte Arten von Journalbuchungen auswählen, etwa „SA“ für Sachkontenbuchungen oder „KR“ für Kreditorenrechnungen. So lässt sich das Datenvolumen reduzieren und die Relevanz des Datensatzes erhöhen. - Dateipfad: Das Programm benötigt einen logischen Dateipfad auf dem SAP-Anwendungsserver, in den die Ausgabedatei geschrieben wird. Prüfen Sie, ob der Pfad gültig ist und der SAP-Systembenutzer über die erforderlichen Schreibberechtigungen für das Verzeichnis verfügt. Mit der Transaktion
AL11können Sie Serververzeichnisse verwalten und anzeigen. - Workflow-Task-IDs: Für die Extraktion von Workflow-Ereignissen (eingereicht, freigegeben, abgelehnt) müssen die Task-IDs konfiguriert sein, die in Ihrem Freigabe-Workflow für Journalbuchungen verwendet werden. Diese IDs sind häufig kundenspezifisch und müssen von einer Workflow-Beratung oder Entwicklung ermittelt werden.
- Voraussetzungen: Der Benutzer oder das Systemkonto, das das Programm ausführt, benötigt Entwicklungsberechtigungen zum Erstellen und Ausführen von ABAP-Programmen (
S_DEVELOP) sowie umfassende Leseberechtigungen für Finanzbuchhaltungstabellen (BKPF, ACDOCA), Änderungsprotokolltabellen (CDHDR, CDPOS) und Workflow-Tabellen (SWW*).
a Beispielabfrage abap
REPORT Z_PM_JE_EXTRACT.
*&---------------------------------------------------------------------*
*&-- Data Structures for Event Log --*
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE string,
createdbyuser TYPE uname,
companycode TYPE bukrs,
journalentrytype TYPE blart,
postingdate TYPE budat,
amountinlocalcurrency TYPE wrbtr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Selection Screen Definition --*
*&---------------------------------------------------------------------*
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
PARAMETERS: p_erdat_fr TYPE dats OBLIGATORY DEFAULT sy-datum-30,
p_erdat_to TYPE dats OBLIGATORY DEFAULT sy-datum.
SELECT-OPTIONS: so_bukrs FOR bkpf-bukrs OBLIGATORY.
PARAMETERS: p_fpath TYPE string OBLIGATORY DEFAULT '/usr/sap/trans/tmp/je_event_log.csv'.
SELECTION-SCREEN END OF BLOCK b1.
*&---------------------------------------------------------------------*
*&-- Internal Tables --*
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log.
*&---------------------------------------------------------------------*
*&-- Main Processing Block --*
*&---------------------------------------------------------------------*
START-OF-SELECTION.
PERFORM get_created_posted_events.
PERFORM get_parked_events.
PERFORM get_attachment_events.
PERFORM get_workflow_events.
PERFORM get_change_events.
PERFORM get_cleared_events.
PERFORM get_reversal_events.
SORT gt_event_log BY journalentryid eventtime.
PERFORM write_output_file.
*&---------------------------------------------------------------------*
*&-- Subroutines for Extracting Individual Activities --*
*&---------------------------------------------------------------------*
FORM get_created_posted_events.
DATA: lt_bkpf TYPE TABLE OF bkpf,
ls_event_log TYPE ty_event_log,
lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_bkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_bkpf ASSIGNING FIELD-SYMBOL(<fs_bkpf>).
CLEAR ls_event_log.
CONCATENATE <fs_bkpf>-bukrs <fs_bkpf>-belnr <fs_bkpf>-gjahr INTO ls_event_log-journalentryid.
ls_event_log-companycode = <fs_bkpf>-bukrs.
ls_event_log-journalentrytype = <fs_bkpf>-blart.
ls_event_log-postingdate = <fs_bkpf>-budat.
ls_event_log-createdbyuser = <fs_bkpf>-usnam.
" Timestamp format YYYY-MM-DDTHH:MI:SS
CONCATENATE <fs_bkpf>-cpudt(4) '-' <fs_bkpf>-cpudt+4(2) '-' <fs_bkpf>-cpudt+6(2) 'T' <fs_bkpf>-cputm(2) ':' <fs_bkpf>-cputm+2(2) ':' <fs_bkpf>-cputm+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
" Activity: Journal Entry Created
ls_event_log-activityname = 'Journal Entry Created'.
SELECT SUM( hsl ) INTO ls_event_log-amountinlocalcurrency FROM acdoca WHERE belnr = <fs_bkpf>-belnr AND gjahr = <fs_bkpf>-gjahr AND bukrs = <fs_bkpf>-bukrs.
APPEND ls_event_log TO gt_event_log.
" Activity: Journal Entry Posted (if not parked)
IF <fs_bkpf>-bstat = ' '.
ls_event_log-activityname = 'Journal Entry Posted'.
APPEND ls_event_log TO gt_event_log.
" Activity: Manual Posting Identified (based on T-Code)
CASE <fs_bkpf>-tcode.
WHEN 'FB01' OR 'F-02' OR 'FB50' OR 'F-22' OR 'F-43'.
ls_event_log-activityname = 'Manual Posting Identified'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_parked_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM vbkpf
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE vbkpf-bukrs vbkpf-belnr vbkpf-gjahr INTO ls_event_log-journalentryid.
CONCATENATE vbkpf-cpudt(4) '-' vbkpf-cpudt+4(2) '-' vbkpf-cpudt+6(2) 'T' vbkpf-cputm(2) ':' vbkpf-cputm+2(2) ':' vbkpf-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Parked'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = vbkpf-usnam.
ls_event_log-companycode = vbkpf-bukrs.
ls_event_log-journalentrytype = vbkpf-blart.
ls_event_log-postingdate = vbkpf-budat.
APPEND ls_event_log TO gt_event_log.
ENDSELECT.
ENDFORM.
FORM get_attachment_events.
DATA: lt_bdocs TYPE TABLE OF srgbtbrel, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM srgbtbrel INTO TABLE lt_bdocs
WHERE typeid_a = 'BUS2081' " Object type for Accounting Document
AND catid_a = 'BO'.
LOOP AT lt_bdocs ASSIGNING FIELD-SYMBOL(<fs_bdocs>).
CHECK <fs_bdocs>-instid_a(4) IN so_bukrs.
DATA(lv_bukrs) = <fs_bdocs>-instid_a(4).
DATA(lv_belnr) = <fs_bdocs>-instid_a+4(10).
DATA(lv_gjahr) = <fs_bdocs>-instid_a+14(4).
SELECT SINGLE cpudt, cputm, usnam, blart, budat FROM bkpf
INTO (DATA(lv_cpudt), DATA(lv_cputm), DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0 AND lv_cpudt BETWEEN p_erdat_fr AND p_erdat_to.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
" Note: Using document creation time as a proxy for attachment time.
CONCATENATE lv_cpudt(4) '-' lv_cpudt+4(2) '-' lv_cpudt+6(2) 'T' lv_cputm(2) ':' lv_cputm+2(2) ':' lv_cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Supporting Documentation Attached'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_workflow_events.
" This is a simplified example. Real workflow logic can be complex.
" You must identify your specific Task IDs for these events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_wi, wi_id TYPE sww_wiid, cr_date TYPE sww_cd, cr_time TYPE sww_ct, task TYPE sww_task, instid TYPE swo_typeid, END OF ls_wi.
SELECT h~wi_id h~cr_date h~cr_time h~wi_rh_task o~instid
FROM swwwihead AS h
JOIN sww_wi2obj AS o ON h~wi_id = o~wi_id
INTO @ls_wi
WHERE o~typeid = 'BUS2081' AND o~catid = 'BO'
AND h~cr_date BETWEEN @p_erdat_fr AND @p_erdat_to.
DATA(lv_bukrs) = ls_wi-instid(4).
DATA(lv_belnr) = ls_wi-instid+4(10).
DATA(lv_gjahr) = ls_wi-instid+14(4).
IF lv_bukrs IN so_bukrs.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_wi-cr_date(4) '-' ls_wi-cr_date+4(2) '-' ls_wi-cr_date+6(2) 'T' ls_wi-cr_time(2) ':' ls_wi-cr_time+2(2) ':' ls_wi-cr_time+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-companycode = lv_bukrs.
CASE ls_wi-task.
WHEN '[Your Submit Task ID]'. " e.g., TS20000139
ls_event_log-activityname = 'Journal Submitted For Review'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Approve Task ID]'. " e.g., TS20000142
ls_event_log-activityname = 'Journal Entry Approved'.
APPEND ls_event_log TO gt_event_log.
WHEN '[Your Reject Task ID]'. " e.g., TS20000141
ls_event_log-activityname = 'Journal Entry Rejected'.
APPEND ls_event_log TO gt_event_log.
ENDCASE.
ENDIF.
ENDSELECT.
ENDFORM.
FORM get_change_events.
DATA: lt_cdhdr TYPE TABLE OF cdhdr, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM cdhdr INTO TABLE lt_cdhdr
WHERE objectclas = 'BELEG'
AND udate BETWEEN p_erdat_fr AND p_erdat_to.
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
DATA(lv_bukrs) = <fs_cdhdr>-objectid(4).
DATA(lv_belnr) = <fs_cdhdr>-objectid+4(10).
DATA(lv_gjahr) = <fs_cdhdr>-objectid+14(4).
IF lv_bukrs IN so_bukrs.
SELECT SINGLE bstat, budat, blart FROM bkpf
INTO (DATA(lv_bstat), DATA(lv_budat), DATA(lv_blart))
WHERE bukrs = lv_bukrs AND belnr = lv_belnr AND gjahr = lv_gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE lv_bukrs lv_belnr lv_gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_cdhdr>-udate(4) '-' <fs_cdhdr>-udate+4(2) '-' <fs_cdhdr>-udate+6(2) 'T' <fs_cdhdr>-utime(2) ':' <fs_cdhdr>-utime+2(2) ':' <fs_cdhdr>-utime+4(2) INTO lv_timestamp.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = <fs_cdhdr>-username.
ls_event_log-companycode = lv_bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
IF lv_bstat = ' ' AND <fs_cdhdr>-udate > lv_budat.
ls_event_log-activityname = 'Journal Entry Changed After Posting'.
APPEND ls_event_log TO gt_event_log.
ELSEIF lv_bstat <> ' '.
ls_event_log-activityname = 'Journal Entry Corrected'.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_cleared_events.
DATA: ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
DATA: BEGIN OF ls_clear, belnr TYPE belnr_d, gjahr TYPE gjahr, bukrs TYPE bukrs, augdt TYPE augdt, END OF ls_clear, lt_clear LIKE TABLE OF ls_clear.
SELECT belnr, gjahr, bukrs, MAX( augdt ) AS augdt FROM acdoca
INTO TABLE @lt_clear
WHERE bukrs IN @so_bukrs
AND augdt NE '00000000'
AND augdt BETWEEN @p_erdat_fr AND @p_erdat_to
GROUP BY belnr, gjahr, bukrs.
LOOP AT lt_clear INTO ls_clear.
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = ls_clear-bukrs AND belnr = ls_clear-belnr AND gjahr = ls_clear-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE ls_clear-bukrs ls_clear-belnr ls_clear-gjahr INTO ls_event_log-journalentryid.
CONCATENATE ls_clear-augdt(4) '-' ls_clear-augdt+4(2) '-' ls_clear-augdt+6(2) 'T12:00:00' INTO lv_timestamp. " Clearing date has no time, use midday
ls_event_log-activityname = 'Journal Entry Cleared'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = ls_clear-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM get_reversal_events.
DATA: lt_reversals TYPE TABLE OF bkpf, ls_event_log TYPE ty_event_log, lv_timestamp TYPE string.
SELECT * FROM bkpf INTO TABLE lt_reversals
WHERE bukrs IN so_bukrs
AND cpudt BETWEEN p_erdat_fr AND p_erdat_to
AND stblg IS NOT NULL.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
SELECT SINGLE usnam, blart, budat FROM bkpf
INTO (DATA(lv_usnam), DATA(lv_blart), DATA(lv_budat))
WHERE bukrs = <fs_rev>-bukrs AND belnr = <fs_rev>-stblg AND gjahr = <fs_rev>-gjahr.
IF sy-subrc = 0.
CLEAR ls_event_log.
CONCATENATE <fs_rev>-bukrs <fs_rev>-stblg <fs_rev>-gjahr INTO ls_event_log-journalentryid.
CONCATENATE <fs_rev>-cpudt(4) '-' <fs_rev>-cpudt+4(2) '-' <fs_rev>-cpudt+6(2) 'T' <fs_rev>-cputm(2) ':' <fs_rev>-cputm+2(2) ':' <fs_rev>-cputm+4(2) INTO lv_timestamp.
ls_event_log-activityname = 'Journal Entry Reversal Processed'.
ls_event_log-eventtime = lv_timestamp.
ls_event_log-createdbyuser = lv_usnam.
ls_event_log-companycode = <fs_rev>-bukrs.
ls_event_log-journalentrytype = lv_blart.
ls_event_log-postingdate = lv_budat.
APPEND ls_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
ENDFORM.
FORM write_output_file.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_event_log> TYPE ty_event_log.
OPEN DATASET p_fpath FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc NE 0.
MESSAGE 'Error opening file.' TYPE 'E'.
RETURN.
ENDIF.
" Write Header
lv_line = 'JournalEntryId,ActivityName,EventTime,CreatedByUser,CompanyCode,JournalEntryType,PostingDate,AmountInLocalCurrency'.
TRANSFER lv_line TO p_fpath.
LOOP AT gt_event_log ASSIGNING <fs_event_log>.
CONCATENATE <fs_event_log>-journalentryid <fs_event_log>-activityname <fs_event_log>-eventtime <fs_event_log>-createdbyuser <fs_event_log>-companycode <fs_event_log>-journalentrytype <fs_event_log>-postingdate <fs_event_log>-amountinlocalcurrency
INTO lv_line SEPARATED BY ','.
TRANSFER lv_line TO p_fpath.
ENDLOOP.
CLOSE DATASET p_fpath.
WRITE: / 'File successfully written to', p_fpath.
ENDFORM. Möchten Sie loslegen?
Mit diesem Template bereiten Sie Ihre Daten fundiert vor und gewinnen wichtige Erkenntnisse zu Ihrem Record-to-Report-Prozess für Journalbuchungen. Beginnen Sie noch heute damit, Ihre Prozesse zu verbessern.
Journalbuchungen im Record-to-Report-Prozess effizienter bearbeiten
Verbessern Sie Ihren Prozess und verkürzen Sie die Durchlaufzeit von Journalbuchungen im Record-to-Report-Prozess um 30 %.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.