Ihre Record-to-Report - Journalbuchungs-Datentemplate
Ihre Record-to-Report - Journalbuchungs-Datentemplate
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Praktische Extraktionsanleitung
Record-to-Report - Journalbuchungsattribute
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivität ActivityName | Der Name der Geschäftsaktivität, die zu einem spezifischen Zeitpunkt im Journalbuchungsprozess stattfand. | ||
| Beschreibung Die Aktivität stellt einen spezifischen Schritt oder ein Ereignis im Lebenszyklus einer Journalbuchung dar, wie z.B. „Journalbuchung erstellt“, „Journal zur Überprüfung eingereicht“ oder „Journalbuchung gebucht“. Diese Aktivitäten werden typischerweise aus Änderungsbelegen, Statusaktualisierungen oder im System erfassten Transaktionscodes abgeleitet. Die Analyse von Aktivitäten ermöglicht die Visualisierung des Prozessflusses, die Identifizierung gängiger Pfade und die Aufdeckung von Abweichungen vom Standardverfahren. Sie ist grundlegend für die Berechnung von Metriken wie Aktivitätshäufigkeit, Wartezeiten zwischen Schritten und Konformitätsraten. Bedeutung Es definiert die Schritte im Prozess und ermöglicht die Visualisierung von Prozesslandkarten und die Analyse von Workflow-Mustern. Datenquelle Abgeleitet aus verschiedenen Quellen, einschließlich Statusfeldern in Kopf-/Positions-Tabellen (z. B. BKPF-BSTAT), Änderungsbelegprotokollen (CDHDR/CDPOS) und Workflow-Protokollen. Beispiele Buchungsjournaleintrag erstelltJournalbuchung geparktJournal zur Überprüfung eingereichtJournaleintrag genehmigtJournalbuchung gebucht | |||
| Ereigniszeit EventTime | Der Zeitstempel, der angibt, wann eine spezifische Aktivität für die Journalbuchung stattgefunden hat. | ||
| Beschreibung Die Ereigniszeit ist das präzise Datum und die Uhrzeit, zu der eine Geschäftsaktivität im System ausgeführt und aufgezeichnet wurde. Jede Aktivität in einem Fall hat ihren eigenen Dieses Attribut ist entscheidend für jede zeitbasierte Prozessanalyse. Es wird verwendet, um Zykluszeiten, Dauern zwischen Aktivitäten, Wartezeiten zu berechnen und die zeitliche Verteilung der Arbeit zu verstehen. Genaue Bedeutung Es liefert die chronologische Reihenfolge der Ereignisse, die für die Berechnung aller dauerbasierten Metriken und das Verständnis der Prozesszeitleiste unerlässlich ist. Datenquelle Abgeleitet aus Änderungsbelegprotokollen (CDHDR-UDATE, CDHDR-UTIME), Workflow-Protokollen oder Erstellungs-/Eingabe-Zeitstempeln aus Tabellen wie BKPF (CPUDT, CPUTM). Beispiele 2023-10-26T10:05:00Z2023-11-15T14:30:15Z2024-01-20T09:00:45Z | |||
| Journalbuchungs-ID JournalEntryId | Der eindeutige Identifikator für eine finanzielle Journalbuchung, der als primärer Case-Identifier für den Prozess dient. | ||
| Beschreibung Die Journalbuchungs-ID ist eine eindeutige Nummer, die jedem Buchhaltungsbeleg bei seiner Erstellung in SAP S/4HANA zugewiesen wird. Dieser Identifikator ist wesentlich, um den gesamten Lebenszyklus einer Journalbuchung zu verfolgen, von ihrer ersten Erstellung oder Parkung, über Genehmigungs-Workflows bis hin zu ihrer finalen Buchung und potenziellen Stornierung oder Ausgleichung. In der Process Mining Analyse wird diese ID verwendet, um alle zusammengehörigen Aktivitäten zu einem einzigen Case zu verknüpfen. Durch die Gruppierung von Events unter einer gemeinsamen Journalbuchungs-ID können Analysten den End-to-End-Prozessfluss rekonstruieren, Zykluszeiten messen und Variationen oder Engpässe für jede spezifische Finanztransaktion identifizieren. Es ist das grundlegende Attribut für den Aufbau der gesamten Prozessansicht. Bedeutung Dieser Identifikator verbindet alle zugehörigen Prozessschritte und ermöglicht so die End-to-End-Analyse jeder Journalbuchung. Datenquelle Dies ist ein zusammengesetzter Schlüssel, der typischerweise durch die Verkettung von Buchungskreis (BKPF-BUKRS), Belegnummer (BKPF-BELNR) und Geschäftsjahr (BKPF-GJAHR) gebildet wird. Beispiele 1000-1000000001-20231710-1900000055-20242000-2100003412-2023 | |||
| Betrag in lokaler Währung AmountInLocalCurrency | Der Gesamtwert der Journalbuchung, ausgedrückt in der lokalen Währung des Buchungskreises. | ||
| Beschreibung Dieses Attribut repräsentiert die finanzielle Größenordnung der Journalbuchung. Es ist typischerweise die Summe der absoluten Werte aller Soll- oder Haben-Einzelposten im Dokument, umgerechnet in die lokale Währung des Buchungskreises. Die Analyse nach Betrag ermöglicht die Segmentierung des Prozesses basierend auf dem finanziellen Einfluss. Zum Beispiel könnten hochwertige Buchungen einen strengeren Genehmigungsprozess durchlaufen als geringwertige. Es hilft bei der Priorisierung von Prozessverbesserungsmaßnahmen für Transaktionen, die das höchste finanzielle Risiko darstellen. Bedeutung Gibt den finanziellen Wert der Buchung an und ermöglicht die Analyse, wie sich das Prozessverhalten in Abhängigkeit vom monetären Wert ändert. Datenquelle Berechnet durch Summieren der Beträge aus der Einzelpostentabelle BSEG (Feld DMBTR) für einen gegebenen Journaleintrag (BELNR) und Umwandlung in einen positiven Wert. Beispiele 1500.75125000.0050.20 | |||
| Buchungsdatum PostingDate | Das Datum, an dem die Journalbuchung im Hauptbuch erfasst wird und die Finanzperiode beeinflusst. | ||
| Beschreibung Das Buchungsdatum bestimmt die Finanzperiode, in der die Transaktion in den Finanzberichten erscheint. Es ist ein kritisches Datum für die Buchhaltung und kann von dem Datum abweichen, an dem das Dokument erstellt oder ins System eingegeben wurde. Im Process Mining wird das Buchungsdatum für die zeitbasierte Kohortenanalyse verwendet, z.B. zum Vergleich von Monatsabschlussprozessen oder zur Analyse von Performance-Trends über verschiedene Finanzperioden hinweg. Es wird auch verwendet, um Verzögerungen zwischen der Buchungserstellung und der tatsächlichen Finanzbuchung zu messen. Bedeutung Entscheidend für den finanziellen Kontext, ermöglicht es die Analyse der Prozessleistung innerhalb spezifischer Rechnungsperioden, wie Monats- oder Jahresende. Datenquelle SAP S/4HANA Tabelle BKPF, Feld BUDAT (Buchungsdatum im Beleg). Beispiele 2023-10-312023-11-012024-02-29 | |||
| Buchungskreis CompanyCode | Der eindeutige Identifikator für das Unternehmen oder die juristische Einheit, für die die Journalbuchung gebucht wird. | ||
| Beschreibung Der Buchungskreis ist eine grundlegende Organisationseinheit in SAP Financials, die eine unabhängige juristische Einheit darstellt, für die Finanzberichte erstellt werden. Jede Journalbuchung wird einem spezifischen Buchungskreis zugeordnet. Dieses Attribut ist entscheidend für die Segmentierung und den Vergleich der Prozessperformance über verschiedene Teile der Organisation hinweg. Analysten können es nutzen, um die Prozessansicht für eine spezifische juristische Einheit zu filtern, Ablehnungsraten zwischen Buchungskreisen zu vergleichen oder regionsspezifische Prozessvariationen zu identifizieren. Bedeutung Ermöglicht das Filtern und Vergleichen des Journaleintragsprozesses über verschiedene rechtliche Einheiten oder Geschäftsbereiche innerhalb der Organisation hinweg. Datenquelle SAP S/4HANA Tabelle BKPF, Feld BUKRS (Buchungskreis). Beispiele 10001710US01 | |||
| Erstellt von Benutzer CreatedByUser | Die Benutzer-ID der Person, die die Journalbuchung erstellt hat. | ||
| Beschreibung Dieses Attribut speichert den eindeutigen Identifikator des Benutzers, der den Journalbuchungsprozess durch die Erstellung des initialen Dokuments initiiert hat. Dies könnte ein Buchhalter, ein Business User oder eine System-ID für automatisierte Buchungen sein. Die Analyse des Prozesses durch den Ersteller hilft, Muster im Zusammenhang mit spezifischen Benutzern oder Teams zu identifizieren. Es kann Schulungsbedarfe aufzeigen, wenn bestimmte Benutzer höhere Ablehnungsraten haben, oder hochperformante Individuen hervorheben. Es ist wesentlich für das 'User Activity and Throughput' Dashboard. Bedeutung Ordnet Prozessaktivitäten spezifischen Benutzern zu und ermöglicht so Leistungsanalysen, Workload-Balancing und die Identifizierung von Schulungsmöglichkeiten. Datenquelle SAP S/4HANA Tabelle BKPF, Feld USNAM (Benutzername). Beispiele ABROWNCJONESBATCH_USER | |||
| Journalbuchungsart JournalEntryType | Klassifiziert den Journaleintrag basierend auf seinem Geschäftszweck, z. B. eine Anlagenbuchung, Kreditorenrechnung oder Hauptbucheintrag. | ||
| Beschreibung Die Journalbuchungsart, oder Belegart in der SAP-Terminologie, ist ein Schlüssel, der Buchhaltungsbelege kategorisiert. Sie steuert Aspekte wie den dem Dokument zugewiesenen Nummernkreis und welche Kontenarten für die Buchung zulässig sind. Die Analyse des Prozesses nach Journalbuchungsart ist entscheidend für das Verständnis kontextspezifischer Verhaltensweisen. Zum Beispiel kann der Genehmigungsprozess für eine einfache Abgrenzung (Typ SA) viel einfacher sein als für eine komplexe Anlagenbeschaffung (Typ AA). Diese Dimension ist entscheidend für das 'Compliance by Entry Type' Dashboard. Bedeutung Kategorisiert Einträge nach Geschäftskontext und ermöglicht die Analyse von Prozessvariationen und Leistung für verschiedene Arten von Finanztransaktionen. Datenquelle SAP S/4HANA Tabelle BKPF, Feld BLART (Belegart). Beispiele SAKRAA | |||
| Belegstatus DocumentStatus | Der aktuelle Verarbeitungsstatus der Journalbuchung, z.B. geparkt, gebucht oder ausgeglichen. | ||
| Beschreibung Der Belegstatus gibt den Zustand der Journalbuchung innerhalb ihres Lebenszyklus an. Zum Beispiel ist ein „geparktes“ Dokument gespeichert, aber noch nicht im Hauptbuch gebucht, während ein „gebuchtes“ Dokument finalisiert ist. Die Analyse des Status hilft, den Arbeitsfluss zu verstehen und Engpässe zu identifizieren. Ein hohes Volumen von Dokumenten, die lange Zeit im Status „geparkt“ oder „Genehmigung ausstehend“ verbleiben, kann auf Ineffizienzen im Prozess hindeuten. Es ist auch eine Schlüsselquelle zur Ableitung von Prozessaktivitäten. Bedeutung Bietet einen Überblick darüber, wo sich eine Journalbuchung in ihrem Lebenszyklus befindet, und hilft dabei, Warteschlangen und Engpässe zu identifizieren. Datenquelle SAP S/4HANA Tabelle BKPF, Feld BSTAT (Belegstatus). Beispiele VAB | |||
| Endzeit EndTime | Der `Zeitstempel`, der anzeigt, wann die `Aktivität` abgeschlossen wurde. | ||
| Beschreibung Die Endzeit markiert den Abschluss einer Aktivität. In vielen Event Logs sind die Startzeit und die Endzeit einer Aktivität identisch und repräsentieren ein sofortiges Ereignis. Bei Aktivitäten mit einer messbaren Dauer, wie z.B. der aktiven Überprüfung eines Dokuments durch einen Benutzer, kann dieses Attribut diese Dauer erfassen. Eine separate Endzeit ermöglicht eine präzisere Berechnung der Bearbeitungszeiten von Aktivitäten im Vergleich zu Wartezeiten. Sie hilft, die aktive Arbeitszeit von der Leerlaufzeit in einer Warteschlange zu unterscheiden. Bedeutung Ermöglicht die Berechnung präziser Bearbeitungszeiten für Aktivitäten, wobei die aktive Arbeitszeit von der Leerlaufwartezeit getrennt wird. Datenquelle Typischerweise identisch mit der Startzeit für atomare Events. Für dauerhafte Aktivitäten kann sie aus Workflow-Logs bezogen oder basierend auf nachfolgenden Events berechnet werden. Beispiele 2023-10-26T10:05:00Z2023-11-15T14:45:20Z2024-01-20T09:10:30Z | |||
| Freigabe-Durchlaufzeit ApprovalCycleTime | Die verstrichene Zeit von der Einreichung einer Journalbuchung zur Genehmigung bis zu ihrer Genehmigung oder Ablehnung. | ||
| Beschreibung Diese berechnete Metrik konzentriert sich spezifisch auf die Dauer der Genehmigungsphase. Sie misst die Zeit zwischen der Aktivität „Journal zur Überprüfung eingereicht“ und der nachfolgenden Aktivität „Journalbuchung genehmigt“ oder „Journalbuchung abgelehnt“. Dieser KPI ist entscheidend für die Identifizierung von Engpässen innerhalb des Genehmigungs-Workflows. Hohe Genehmigungszykluszeiten können den Gesamtprozess erheblich verzögern. Die Analyse dieser Metrik nach Genehmiger, Buchungskreis oder Journalbuchungsart kann spezifische Verbesserungsbereiche aufzeigen. Bedeutung Isoliert die Dauer des Genehmigungsschritts und hilft so, Engpässe im Prüfungs- und Genehmigungs-Workflow zu identifizieren und zu beheben. Datenquelle Berechnet durch Ermittlung der Zeitdifferenz zwischen dem Ereignis 'Journaleintrag zur Prüfung eingereicht' und dem Ereignis 'Journaleintrag genehmigt' oder 'Journaleintrag abgelehnt'. Beispiele 1 Tag 2 Stunden4 Stunden 25 Minuten5 Tage 0 Stunden | |||
| Genehmigender Benutzer ApproverUser | Die Benutzer-ID der Person, die die Journalbuchung genehmigt oder abgelehnt hat. | ||
| Beschreibung Dieses Attribut identifiziert den Benutzer, der für die Überprüfung und Entscheidung über eine eingereichte Journalbuchung verantwortlich ist. In einem mehrstufigen Genehmigungs-Workflow kann es mehrere Genehmiger für eine einzelne Journalbuchung geben. Diese Informationen sind wesentlich für eine detaillierte Analyse des Genehmigungsprozesses. Es hilft, die Arbeitslast verschiedener Genehmiger zu messen, individuelle Genehmigungszeiten zu berechnen und Engpässe in der Genehmigungskette zu identifizieren. Es unterstützt direkt das 'User Activity and Throughput' Dashboard. Bedeutung Identifiziert die für die Genehmigung verantwortliche Person und ermöglicht so die Analyse von Genehmigungsworkloads, Performance und Engpässen. Datenquelle Abgeleitet aus Workflow-Protokollen (z.B. SWW_WI2OBJ, SWWLOG) oder Änderungsbelegtabellen (CDHDR/CDPOS) durch die Verfolgung, wer den Genehmigungsschritt ausgeführt hat. Beispiele DMILLERFWHITEKCHEN | |||
| Gesamtdurchlaufzeit TotalCycleTime | Die Gesamtdauer von der Erstellung der ersten Aktivität bis zum Abschluss der letzten Aktivität für eine Journalbuchung. | ||
| Beschreibung Diese berechnete Metrik misst die End-to-End-Dauer des Journalbuchungsprozesses für jeden Case. Es ist die Differenz zwischen dem Zeitstempel der allerletzten beobachteten Aktivität und dem Zeitstempel der allerersten. Die Gesamtzykluszeit ist ein primärer KPI zur Messung der gesamten Prozesseffizienz. Sie bietet eine übergeordnete Ansicht der Prozessperformance und wird in Dashboards verwendet, um Trends im Zeitverlauf zu verfolgen. Die Analyse der Ursachen langer Zykluszeiten ist ein häufiger Ausgangspunkt für Prozessverbesserungen. Bedeutung Misst die End-to-End-Prozessdauer und liefert einen Schlüssel-Performance-Indikator (KPI) für die gesamte Prozesseffizienz und -geschwindigkeit. Datenquelle Berechnet durch Subtraktion der minimalen EventTime von der maximalen EventTime für jede eindeutige JournalEntryId. Beispiele 2 Tage 4 Stunden 30 Minuten8 Stunden 15 Minuten15 Tage 2 Stunden | |||
| Geschäftsjahr FiscalYear | Das Geschäftsjahr, zu dem die Journalbuchung gehört. | ||
| Beschreibung Das Geschäftsjahr ist Teil des eindeutigen Schlüssels für eine Journalbuchung, zusammen mit dem Buchungskreis und der Belegnummer. Es repräsentiert das Geschäftsjahr, in dem das Dokument relevant ist. In der Analyse wird das Geschäftsjahr für die langfristige Trendanalyse und zur Sicherstellung der Eindeutigkeit des Case-Identifiers verwendet. Der Vergleich von Prozessmetriken über verschiedene Geschäftsjahre hinweg kann Verbesserungen oder Verschlechterungen der Performance im Laufe der Zeit aufzeigen. Bedeutung Bietet eine kritische Komponente zur eindeutigen Identifizierung von Dokumenten und ermöglicht eine Performance-Analyse des Prozesses im Jahresvergleich. Datenquelle SAP S/4HANA Tabelle BKPF, Feld GJAHR (Geschäftsjahr). Beispiele 202320242022 | |||
| Ist manuelle Buchung IsManualPosting | Ein boolesches Flag, das anzeigt, ob der Journaleintrag manuell von einem Benutzer gebucht wurde. | ||
| Beschreibung Dieses Attribut identifiziert Journalbuchungen, die durch manuelle Benutzereingriffe gebucht wurden, im Gegensatz zu automatischen Buchungen durch einen System-Job oder eine Schnittstelle. Es wird typischerweise vom Transaktionscode abgeleitet, der zum Buchen des Dokuments verwendet wurde. Dieses Flag wird verwendet, um den KPI der manuellen Buchungsrate zu berechnen und Organisationen dabei zu unterstützen, ihren Fortschritt bei der Automatisierung des Record-to-Report-Prozesses zu verfolgen. Durch das Filtern nach manuell gebuchten Einträgen können Analysten die spezifischen Szenarien identifizieren, die noch menschliche Eingriffe erfordern, und diese auf Automatisierungspotenzial bewerten. Bedeutung Unterscheidet zwischen menschlich und systemgesteuerten Buchungen, was entscheidend ist für die Messung des Automatisierungsgrads und die Identifizierung von Automatisierungsmöglichkeiten. Datenquelle Dies ist ein berechnetes Attribut, das vom Transaktionscode abgeleitet wird. Eine vordefinierte Liste manueller Transaktionscodes (z.B. 'FB01', 'F-02') wird verwendet, um das Flag auf 'true' zu setzen. Beispiele truefalsch | |||
| Ist Nacharbeit IsRework | Ein boolesches Flag, das anzeigt, ob der Journaleintrag überarbeitet wurde, z. B. nach einer Ablehnung korrigiert wurde. | ||
| Beschreibung Dieses berechnete Attribut kennzeichnet Journalbuchungen, die vom idealen „Happy Path“-Prozess abgewichen sind. Es wird typischerweise auf „true“ gesetzt, wenn eine Aktivität wie „Journalbuchung abgelehnt“ oder „Journalbuchung korrigiert“ innerhalb des Case auftritt. Dieses Flag vereinfacht die Analyse der Prozesseffizienz. Es ermöglicht eine schnelle Berechnung des KPIs der Nacharbeitsrate und einen direkten Vergleich von Zykluszeiten und Kosten zwischen Cases mit und ohne Nacharbeit. Die Identifizierung der Ursachen von Nacharbeit ist ein primäres Ziel vieler Prozessverbesserungsinitiativen. Bedeutung Kennzeichnet Fälle, die Korrekturen oder zusätzliche Schleifen erforderten, was eine einfache Quantifizierung und Ursachenanalyse von Prozesseffizienz ermöglicht. Datenquelle Dies ist ein berechnetes Attribut, das aus der Abfolge von Aktivitäten in einem Case abgeleitet wird. Es wird auf 'true' gesetzt, wenn eine Aktivität wie 'Journalbuchung abgelehnt' vorhanden ist. Beispiele truefalsch | |||
| Letzte Datenaktualisierung LastDataUpdate | Timestamp, der den letzten Zeitpunkt angibt, zu dem die Daten für diesen Datensatz aus dem Quellsystem aktualisiert wurden. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion oder Aktualisierung aus dem Quellsystem. Es bietet Transparenz über die Aktualität der analysierten Daten. Die Kenntnis des letzten Update-Zeitpunkts ist wichtig, um die Aktualität der Prozessanalyse zu verstehen. Sie hilft Benutzern, die Dashboards und KPIs korrekt zu interpretieren, da sie wissen, ob sie nahezu Echtzeitdaten oder eine Momentaufnahme aus einer früheren Periode betrachten. Bedeutung Zeigt die Aktualität der Daten an und stellt sicher, dass die Benutzer wissen, wie aktuell die Prozessanalyse ist. Datenquelle Dies ist ein Metadaten-Attribut, das typischerweise während der Datenaufnahme-Pipeline generiert und auf jeden Datensatz gestempelt wird. Beispiele 2024-03-10T02:00:00Z2024-03-11T02:00:00Z2024-03-12T02:00:00Z | |||
| Quellsystem SourceSystem | Identifiziert das Quellsystem, aus dem die Journaleintragdaten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt das führende System an, in dem die Journalbuchungsdaten ihren Ursprung haben. Für Unternehmen mit mehreren ERP-Instanzen oder einer Mischung aus Altsystemen und modernen Systemen hilft dies, Datenquellen zu unterscheiden. In der Analyse kann es verwendet werden, um die Prozessperformance über verschiedene Systeme hinweg zu vergleichen oder Daten für eine spezifische Quelle zu filtern. Es ist wichtig für die Data Governance und um sicherzustellen, dass der Kontext der Daten verstanden wird. Bedeutung Liefert Kontext zur Datenherkunft, was in Multi-Systemlandschaften für eine präzise Prozessanalyse und den Vergleich von Prozessen unerlässlich ist. Datenquelle Dies ist typischerweise ein statischer Wert, der während der Datenextraktion hinzugefügt wird und die spezifische SAP S/4HANA-Instanz (z.B. SID oder logischen Systemnamen) identifiziert. Beispiele S4H_PROD_100ECC_FIN_200S4C_US_EAST | |||
| Stornogrund ReversalReason | Ein Code, der den Grund angibt, warum ein gebuchter Journaleintrag storniert wurde. | ||
| Beschreibung Wenn eine gebuchte Journalbuchung fehlerhaft ist, kann sie nicht gelöscht, sondern muss mit einem neuen Dokument storniert werden. Der Stornierungsgrund-Code erklärt, warum diese Aktion vorgenommen wurde, z.B. aufgrund eines falschen Buchungsdatums oder Betrags. Die Analyse von Stornierungsgründen hilft, die Ursachen von Fehlern im Record-to-Report-Prozess zu identifizieren. Eine hohe Häufigkeit eines bestimmten Grundes kann auf systemische Probleme hinweisen, wie unzureichende Schulung oder Kontrollversagen, die behoben werden müssen, um die Erst-Durchgangs-Qualität zu verbessern. Bedeutung Hilft, die Grundursache von Fehlern zu diagnostizieren, die zu Stornierungen führen, und liefert die notwendigen Erkenntnisse zur Reduzierung von Nacharbeit und zur Verbesserung der Prozessqualität. Datenquelle SAP S/4HANA Tabelle BKPF, Feld STGRD (Stornierungsgrund). Beispiele 010205 | |||
| Transaktionscode TransactionCode | Der SAP-Transaktionscode, der zur Erstellung oder Änderung der Journalbuchung verwendet wurde. | ||
| Beschreibung Der Transaktionscode (T-Code) ist eine Abkürzung, die eine spezifische Funktion oder ein Programm in SAP identifiziert. Für Journalbuchungen können unterschiedliche T-Codes angeben, wie die Buchung erstellt wurde, zum Beispiel FB01 für manuelle Hauptbuchbuchungen, FV50 für das Parken oder ein automatischer Code für systemgenerierte Buchungen. Dieses Attribut ist ein starker Indikator dafür, ob eine Aktivität manuell von einem Benutzer oder automatisch vom System durchgeführt wurde. Es ist entscheidend für die Berechnung des KPIs der manuellen Buchungsrate und zur Identifizierung von Automatisierungsmöglichkeiten. Bedeutung Gibt an, wie ein Eintrag verarbeitet wurde (z. B. manuell vs. automatisch), was entscheidend für die Automatisierungsanalyse und das Verständnis von Prozessvariationen ist. Datenquelle SAP S/4HANA Tabelle BKPF, Feld TCODE (Transaktionscode). Beispiele FB01FV50F-02 | |||
Record-to-Report - Journalbuchungsaktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Buchungsjournaleintrag erstellt | Diese Aktivität markiert die erstmalige Erstellung eines Journalbuchungsbelegs im System. Der Datensatz wird in der Kopftabelle (BKPF) erstellt, aber noch nicht im Hauptbuch gebucht. Dies ist der Ausgangspunkt für den Lebenszyklus der Journalbuchung. | ||
| Bedeutung Dies ist das primäre Start-Event für den Prozess. Die Analyse der Zeit von diesem Event bis zur Buchung ist entscheidend für die Messung der Gesamtzykluszeit und die Identifizierung anfänglicher Dateneingabeverzögerungen. Datenquelle Dieses Event kann explizit aus der SAP-Tabelle BKPF mittels der Felder Erstellungsdatum (CPUDT) und Erstellungszeit (CPUTM) für eine gegebene Belegnummer (BELNR) erfasst werden. Erfassen Verwenden Sie BKPF-CPUDT und BKPF-CPUTM für den Event-Zeitstempel. Ereignistyp explicit | |||
| Journal zur Überprüfung eingereicht | Der Ersteller der Journalbuchung reicht das Dokument formell zur Überprüfung und für den Genehmigungs-Workflow ein. Diese Aktivität stellt die Übergabe von der Dateneingabe an den formellen Kontrollprozess dar und initiiert den Genehmigungszyklus. | ||
| Bedeutung Dies markiert den Beginn der Genehmigungszykluszeit. Die Messung von diesem Zeitpunkt bis zur finalen Genehmigung oder Ablehnung hilft, Engpässe spezifisch innerhalb der Überprüfungs- und Genehmigungsphasen zu isolieren. Datenquelle Dies wird oft aus Workflow-Logs (Tabellen SWW_WIHEAD, SWWLOG), die mit dem Business-Objekt verknüpft sind, erfasst. Es kann auch aus einer Statusänderung in einem benutzerdefinierten Feld im Belegkopf (BKPF) abgeleitet werden. Erfassen Zeitstempel der Workflow-Element-Erstellung oder einer Statusfeldänderung auf 'Eingereicht' oder 'In Überprüfung'. Ereignistyp inferred | |||
| Journalbuchung ausgeglichen | Ein offener Posten innerhalb eines Journaleintrags wird durch eine andere Buchung, wie z. B. eine Zahlung, die eine Rechnung ausgleicht, verrechnet. Diese Aktivität kennzeichnet die Abstimmung spezifischer Einzelposten und schließt diese damit effektiv ab. | ||
| Bedeutung Diese Aktivität stellt den finalen Abstimmungsschritt für viele Journalbuchungen dar, insbesondere für solche, die Abgrenzungs- oder Offene-Posten-verwaltete Konten betreffen. Die Analyse der Zeit von der Buchung bis zum Ausgleich hilft, die Abstimmungseffizienz zu messen. Datenquelle Dieses Event wird aus der Einzelpostentabelle (BSEG oder der ACDOCA-Sicht) abgeleitet. Wenn ein Posten ausgeglichen wird, werden die Felder Ausgleichsdatum (AUGDT) und Ausgleichsbeleg (AUGBL) für diese Zeile gefüllt. Erfassen Verwenden Sie das Ausgleichsdatum (BSEG-AUGDT) für den Einzelposten als Zeitstempel für das Event. Ereignistyp inferred | |||
| Journalbuchung gebucht | Die Journalbuchung wird offiziell im Hauptbuch erfasst und beeinflusst die Finanzberichte des Unternehmens. Dies ist der Zeitpunkt, an dem das Dokument zu einem dauerhaften Finanzdatensatz wird. | ||
| Bedeutung Dies ist der primäre Erfolgsmeilenstein, der das Ende des Kernverarbeitungszyklus markiert. Die Analyse des Durchsatzes gebuchter Einträge und der Zeit, die bis zum Erreichen dieser Phase benötigt wird, sind grundlegende Process Mining Metriken. Datenquelle Dies ist ein explizites Ereignis, das durch das Buchungsdatum (BUDAT) in der BKPF-Tabelle gekennzeichnet ist. Ein gebuchtes Dokument hat einen leeren Belegstatus (BSTAT), der es von geparkten ('V') oder gehaltenen ('D') Dokumenten unterscheidet. Erfassen Verwenden Sie das Buchungsdatum (BKPF-BUDAT) und das Erfassungsdatum (BKPF-CPUDT) als Zeitstempel für das Event. Ein leerer BKPF-BSTAT-Wert kennzeichnet ein gebuchtes Dokument. Ereignistyp explicit | |||
| Journaleintrag genehmigt | Die Journalbuchung erhält die finale Genehmigung von einem autorisierten Manager, der ihre Gültigkeit und Genauigkeit bestätigt. Diese Aktivität ist die letzte Hürde, bevor das Dokument im Hauptbuch gebucht werden kann. | ||
| Bedeutung Dies ist ein kritischer Meilenstein, der den Genehmigungszyklus abschließt. Die Zeit, die benötigt wird, um diesen Schritt zu erreichen, ist ein Hauptbestandteil der gesamten Prozessdauer und ein Schlüsselindikator für die Effizienz des Genehmigers. Datenquelle Dieses Event wird aus einem Workflow-Log, der den finalen Genehmigungsschritt zeigt, oder einer Statusänderung am Dokument abgeleitet. Die Benutzer-ID und der Zeitstempel des Genehmigers können aus Workflow-Daten oder Änderungsbelegen bezogen werden. Erfassen Identifizieren Sie den Timestamp des finalen Genehmigungsschritts in Workflow-Protokollen oder die Statusänderung auf 'Genehmigt' in Änderungsbelegen. Ereignistyp inferred | |||
| Stornierung der Journalbuchung verarbeitet | Ein zuvor gebuchter Journaleintrag wird durch die Erstellung eines neuen Belegs mit umgekehrten Buchungen storniert. Diese Maßnahme dient der Korrektur von Fehlern in gebuchten Belegen und ist eine explizite, prüfbare Transaktion. | ||
| Bedeutung Stornierungen weisen darauf hin, dass in einem gebuchten Dokument ein Fehler vorlag. Eine hohe Stornierungsrate deutet auf zugrunde liegende Probleme im Genehmigungsprozess oder in der Datenqualität hin. Deren Verfolgung hilft, die Genauigkeit beim ersten Versuch zu verbessern. Datenquelle Die Stornierung ist ein explizites Ereignis. Der Kopf des neuen Stornobelegs (BKPF) enthält einen Verweis auf das Originaldokument im Feld Stornierter Beleg Nr. (STBLG). Das Buchungsdatum des neuen Dokuments ist der Event-Zeitstempel. Erfassen Identifizieren Sie Belege, bei denen BKPF-STBLG gefüllt ist. Der Ereignis-Timestamp ist das Buchungsdatum des Stornobelegs. Ereignistyp explicit | |||
| Begleitdokumentation angehängt | Ein Benutzer fügt dem Journaleintrag ein oder mehrere unterstützende Dokumente, wie Rechnungen oder Tabellen, hinzu. Dies geschieht typischerweise, um Beweise und Kontext für die Finanztransaktion während des Prüfungs- und Auditprozesses bereitzustellen. | ||
| Bedeutung Die Sicherstellung, dass Dokumente vor der Prüfung angehängt werden, ist entscheidend für Compliance und Genehmigungseffizienz. Diese Aktivität hilft, die Einhaltung der Dokumentationsrichtlinien und deren Auswirkungen auf die Genehmigungsdurchlaufzeiten zu messen. Datenquelle Dies wird typischerweise durch Überprüfung des Erstellungs-Zeitstempels von Anhängen abgeleitet, die über Generic Object Services (GOS) verknüpft sind. Die Tabelle SRGBTBREL verknüpft das Business-Objekt (z.B. BKPF-Dokument) mit dem Anhang. Erfassen Fragen Sie GOS-Anlagentabellen (z.B. SRGBTBREL) nach Verknüpfungen zum BKPF-Objekt ab und verwenden Sie den Erstellungs-Zeitstempel der Anlage. Ereignistyp inferred | |||
| Journalbuchung abgelehnt | Ein Prüfer oder Genehmiger lehnt den Journaleintrag ab, wodurch dessen Buchung verhindert wird. Der Beleg wird typischerweise zur Korrektur an den Ersteller zurückgesendet, was eine Nacharbeitsschleife initiiert. | ||
| Bedeutung Die Verfolgung von Ablehnungen ist entscheidend, um die Prozessqualität zu verstehen und häufige Fehler zu identifizieren. Hohe Ablehnungsraten deuten auf Probleme mit der Datenkonsistenz, dem Richtlinienverständnis oder unzureichender Begleitdokumentation hin. Datenquelle Dieses Event wird aus einer Statusänderung in einem Workflow-Log oder einem benutzerdefinierten Statusfeld im Journalbuchungsbeleg abgeleitet. Änderungsbelegprotokolle (CDHDR/CDPOS) auf dem relevanten Statusfeld können den Zeitstempel liefern. Erfassen Identifizieren Sie die Statusfeldänderung auf 'Abgelehnt' über Änderungsbelege (CDHDR/CDPOS) oder Workflow-Protokolle. Ereignistyp inferred | |||
| Journalbuchung geparkt | Ein Benutzer speichert einen unvollständigen Journaleintrag, ohne ihn zu buchen, um ihn später zu vervollständigen oder zu überprüfen. Dies ist eine explizite Aktion, die einen Belegkopfdatensatz mit dem Status 'geparkt' erstellt und ihn in einem nicht gebuchten Zustand hält. | ||
| Bedeutung Das Parken ist ein gängiger Schritt vor der Einreichung. Die Verfolgung der Dauer des geparkten Zustands hilft, Verzögerungen bei der Datenvervollständigung und -vorbereitung zu identifizieren, noch bevor der formelle Überprüfungs- und Genehmigungsprozess beginnt. Datenquelle In der Tabelle BKPF wird ein geparkter Beleg durch das Belegstatusfeld (BSTAT) mit dem Wert 'V' identifiziert. Der Ereignis-Timestamp ist das Erstellungsdatum (CPUDT). Erfassen Filtern Sie nach Belegen, bei denen BKPF-BSTAT = 'V' zum Zeitpunkt der Erstellung ist. Ereignistyp explicit | |||
| Journalbuchung korrigiert | Der Benutzer ändert eine Journalbuchung, nachdem diese abgelehnt oder zur Änderung zurückgeschickt wurde. Dies stellt den Nacharbeitsaufwand dar, der erforderlich ist, um während des Überprüfungsprozesses identifizierte Probleme vor der erneuten Einreichung zu beheben. | ||
| Bedeutung Diese Aktivität quantifiziert Nacharbeitsschleifen. Die Analyse der Häufigkeit und Dauer von Korrekturen hilft, Ineffizienzquellen zu identifizieren und zeigt Möglichkeiten für Schulungen und Prozessklarstellungen auf. Datenquelle Dies kann durch Verfolgung des Datums 'Zuletzt geändert am' (AEDAT) in der BKPF-Tabelle für ein Dokument abgeleitet werden, das zuvor im Status 'Abgelehnt' war. Änderungsbelege liefern spezifischere Details zu den vorgenommenen Änderungen. Erfassen Verwenden Sie den Zeitstempel aus Änderungsbelegköpfen (CDHDR-UDATE) für Änderungen, die nach einem Ablehnungsereignis vorgenommen wurden. Ereignistyp inferred | |||
| Journaleintrag nach Buchung geändert | Ein Benutzer ändert eine begrenzte Anzahl von Feldern in einem Journaleintrag, nachdem dieser bereits im Hauptbuch gebucht wurde. Während die meisten Finanzdaten nach der Buchung unveränderlich sind, können einige Felder wie Text oder Zuordnungen geändert werden. | ||
| Bedeutung Diese Aktivität ist ein kritisches Compliance-Merkmal. Änderungen nach der Buchung können auf Manipulationsversuche an Aufzeichnungen hindeuten und sollten genau überwacht werden, um Betrug zu verhindern und die Datenintegrität zu gewährleisten. Datenquelle Dies kann zuverlässig aus Änderungsbelegtabellen (CDHDR und CDPOS) abgeleitet werden. Ein Eintrag in CDHDR für die Belegnummer mit einem Änderungsdatum nach dem Buchungsdatum kennzeichnet eine Änderung nach der Buchung. Erfassen Finden Sie Datensätze in CDHDR, bei denen der Änderungs-Timestamp (UDATE/UTIME) nach dem Buchungsdatum des Belegs (BKPF-BUDAT) liegt. Ereignistyp inferred | |||
| Manuelle Buchung identifiziert | Die Journalbuchung wurde mittels eines manuellen Transaktionscodes gebucht, anstatt über eine automatisierte Schnittstelle oder einen Batch-Job. Dies ist kein zeitliches Ereignis, sondern eine Klassifizierung der Buchungsaktivität. | ||
| Bedeutung Die Identifizierung manueller Buchungen ist entscheidend für Automatisierungsinitiativen. Eine hohe Rate manueller Buchungen deutet auf Möglichkeiten zur Prozessoptimierung durch die Integration von Subsystemen oder die Verwendung automatisierter Buchungsprogramme hin. Datenquelle Dies wird durch die Analyse des Transaktionscode-Feldes (TCODE) in der Belegkopftabelle (BKPF) berechnet. Eine Liste bekannter manueller T-Codes (z.B. FB01, F-02, FB50) wird verwendet, um die Buchung zu klassifizieren. Erfassen Klassifizieren Sie das Ereignis basierend auf BKPF-TCODE anhand einer vordefinierten Liste manueller Transaktionscodes zum Zeitpunkt der Buchung. Ereignistyp calculated | |||
Extraktionsleitfäden
Schritte
- Voraussetzungen und Zugang: Stellen Sie sicher, dass Sie über einen Benutzer mit den erforderlichen Berechtigungen verfügen, um die zugrunde liegende Datenbank von SAP S/4HANA abzufragen oder ABAP-Berichte auszuführen. Sie benötigen Lesezugriff auf die CDS-Views I_JournalEntry, I_JournalEntryItem und die Tabellen CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ und SWWLOGHIST. Der Zugriff erfolgt typischerweise über einen Datenbank-Client wie SAP HANA Studio, DBeaver oder die ABAP Development Tools (ADT) für Eclipse von SAP.
- Systemspezifische Konfigurationen identifizieren: Bevor Sie die Abfrage ausführen, müssen Sie die spezifischen Aufgaben-Codes identifizieren, die in Ihrem Genehmigungs-Workflow für Journaleinträge verwendet werden. Konsultieren Sie Ihren SAP Workflow-Administrator, um die Aufgaben-IDs (z. B. TS12345678) zu finden, die den Einreichungs-, Ablehnungs- und Genehmigungsereignissen entsprechen. Diese sind für die Platzhalter in der finalen Abfrage erforderlich.
- SQL-Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage, die im Abschnitt
querybereitgestellt wird, in Ihren ausgewählten SQL-Client oder Ihr Entwicklungstool. - Abfrageparameter festlegen: Suchen Sie die Platzhalter in der Abfrage und ersetzen Sie diese durch Ihre spezifischen Werte. Dies beinhaltet das Festlegen der Parameter
[YourCompanyCode],[StartDate]und[EndDate]. Sie müssen auch die Platzhalter der Workflow-Aufgaben-IDs ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) durch die im vorherigen Schritt identifizierten Werte ersetzen. - Extraktionsabfrage ausführen: Führen Sie die modifizierte SQL-Abfrage gegen die SAP S/4HANA-Datenbank aus. Abhängig vom Datumsbereich und Datenvolumen kann die Abfrage eine beträchtliche Zeit in Anspruch nehmen. Es wird empfohlen, dies außerhalb der Stoßzeiten durchzuführen.
- Erste Ergebnisse überprüfen: Sobald die Abfrage abgeschlossen ist, überprüfen Sie die ersten Zeilen der Ausgabe, um sicherzustellen, dass alle Spalten, wie JournalEntryId, ActivityName und EventTime, wie erwartet gefüllt sind. Das Ergebnisset sollte eine Zeile für jedes eindeutige Geschäftsereignis im Lebenszyklus des Journaleintrags enthalten.
- Daten als CSV exportieren: Exportieren Sie das gesamte Ergebnisset aus Ihrem SQL-Tool in eine einzige CSV-Datei. Stellen Sie sicher, dass die Datei UTF-8-Kodierung verwendet, um Probleme mit Sonderzeichen zu vermeiden.
- Für den Upload vorbereiten: Bestätigen Sie vor dem Upload in ein Process Mining Tool, dass die CSV-Datei die erforderlichen Kopfzeilen enthält. Die Daten sind bereits als Event Log strukturiert, sodass keine weitere Transformation oder Pivotierung erforderlich sein sollte.
Konfiguration
- Core Data Services (CDS) Views: Die Extraktion verwendet primär
I_JournalEntryfür Kopfdaten undI_JournalEntryItemfür Positions- und Betragsdetails. Diese Views bieten eine vereinfachte und semantisch reichhaltige Schnittstelle zum Universal Journal (ACDOCA). - Unterstützende Tabellen: Um eine vollständige Prozessansicht zu erfassen, verknüpft die Abfrage auch mehrere Standard-SAP-Tabellen:
CDHDRundCDPOSzur Nachverfolgung von Änderungen an Belegen.SRGBRELundSOODzur Identifizierung, wann Anlagen über Generic Object Services (GOS) verknüpft werden.SWW_WI2OBJundSWWLOGHISTzur Extraktion wichtiger Ereignisse aus dem Genehmigungs-Workflow.
- Datumsbereichsfilterung: Es ist entscheidend, die Daten nach einem bestimmten Datumsbereich zu filtern, um die Performance zu steuern. Verwenden Sie das Feld
I_JournalEntry.CreationDateTimein derWHERE-Klausel. Ein Bereich von 3 bis 6 Monaten wird für eine erste Analyse empfohlen. - Organisatorische Filterung: Filtern Sie immer nach
CompanyCode, um die Extraktion auf relevante rechtliche Einheiten zu beschränken. Das Abfragen aller Buchungskreise gleichzeitig in einem großen System kann zu extrem langen Ausführungszeiten führen. - Workflow-Aufgaben-IDs: Die Abfrage enthält Platzhalter für Workflow-Aufgaben-IDs (z. B.
[Workflow Approved Task ID]). Diese sind für jede SAP-Installation einzigartig und müssen korrekt konfiguriert werden, damit Workflow-Aktivitäten extrahiert werden können. Ohne sie werden keine Übermittlungs-, Genehmigungs- oder Ablehnungsereignisse erfasst. - Voraussetzungen: Der ausführende Benutzer benötigt umfassende Leseberechtigungen für Finanz-, System- und Workflow-Tabellen. Diese Berechtigungen sind nicht Standard und müssen spezifisch 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
- Voraussetzungen und Zugang: Stellen Sie sicher, dass Sie über einen Benutzer mit den erforderlichen Berechtigungen verfügen, um die zugrunde liegende Datenbank von SAP S/4HANA abzufragen oder ABAP-Berichte auszuführen. Sie benötigen Lesezugriff auf die CDS-Views I_JournalEntry, I_JournalEntryItem und die Tabellen CDHDR, CDPOS, SRGBREL, SOOD, SWW_WI2OBJ und SWWLOGHIST. Der Zugriff erfolgt typischerweise über einen Datenbank-Client wie SAP HANA Studio, DBeaver oder die ABAP Development Tools (ADT) für Eclipse von SAP.
- Systemspezifische Konfigurationen identifizieren: Bevor Sie die Abfrage ausführen, müssen Sie die spezifischen Aufgaben-Codes identifizieren, die in Ihrem Genehmigungs-Workflow für Journaleinträge verwendet werden. Konsultieren Sie Ihren SAP Workflow-Administrator, um die Aufgaben-IDs (z. B. TS12345678) zu finden, die den Einreichungs-, Ablehnungs- und Genehmigungsereignissen entsprechen. Diese sind für die Platzhalter in der finalen Abfrage erforderlich.
- SQL-Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage, die im Abschnitt
querybereitgestellt wird, in Ihren ausgewählten SQL-Client oder Ihr Entwicklungstool. - Abfrageparameter festlegen: Suchen Sie die Platzhalter in der Abfrage und ersetzen Sie diese durch Ihre spezifischen Werte. Dies beinhaltet das Festlegen der Parameter
[YourCompanyCode],[StartDate]und[EndDate]. Sie müssen auch die Platzhalter der Workflow-Aufgaben-IDs ([Workflow Submitted Task ID],[Workflow Rejected Task ID],[Workflow Approved Task ID]) durch die im vorherigen Schritt identifizierten Werte ersetzen. - Extraktionsabfrage ausführen: Führen Sie die modifizierte SQL-Abfrage gegen die SAP S/4HANA-Datenbank aus. Abhängig vom Datumsbereich und Datenvolumen kann die Abfrage eine beträchtliche Zeit in Anspruch nehmen. Es wird empfohlen, dies außerhalb der Stoßzeiten durchzuführen.
- Erste Ergebnisse überprüfen: Sobald die Abfrage abgeschlossen ist, überprüfen Sie die ersten Zeilen der Ausgabe, um sicherzustellen, dass alle Spalten, wie JournalEntryId, ActivityName und EventTime, wie erwartet gefüllt sind. Das Ergebnisset sollte eine Zeile für jedes eindeutige Geschäftsereignis im Lebenszyklus des Journaleintrags enthalten.
- Daten als CSV exportieren: Exportieren Sie das gesamte Ergebnisset aus Ihrem SQL-Tool in eine einzige CSV-Datei. Stellen Sie sicher, dass die Datei UTF-8-Kodierung verwendet, um Probleme mit Sonderzeichen zu vermeiden.
- Für den Upload vorbereiten: Bestätigen Sie vor dem Upload in ein Process Mining Tool, dass die CSV-Datei die erforderlichen Kopfzeilen enthält. Die Daten sind bereits als Event Log strukturiert, sodass keine weitere Transformation oder Pivotierung erforderlich sein sollte.
Konfiguration
- Core Data Services (CDS) Views: Die Extraktion verwendet primär
I_JournalEntryfür Kopfdaten undI_JournalEntryItemfür Positions- und Betragsdetails. Diese Views bieten eine vereinfachte und semantisch reichhaltige Schnittstelle zum Universal Journal (ACDOCA). - Unterstützende Tabellen: Um eine vollständige Prozessansicht zu erfassen, verknüpft die Abfrage auch mehrere Standard-SAP-Tabellen:
CDHDRundCDPOSzur Nachverfolgung von Änderungen an Belegen.SRGBRELundSOODzur Identifizierung, wann Anlagen über Generic Object Services (GOS) verknüpft werden.SWW_WI2OBJundSWWLOGHISTzur Extraktion wichtiger Ereignisse aus dem Genehmigungs-Workflow.
- Datumsbereichsfilterung: Es ist entscheidend, die Daten nach einem bestimmten Datumsbereich zu filtern, um die Performance zu steuern. Verwenden Sie das Feld
I_JournalEntry.CreationDateTimein derWHERE-Klausel. Ein Bereich von 3 bis 6 Monaten wird für eine erste Analyse empfohlen. - Organisatorische Filterung: Filtern Sie immer nach
CompanyCode, um die Extraktion auf relevante rechtliche Einheiten zu beschränken. Das Abfragen aller Buchungskreise gleichzeitig in einem großen System kann zu extrem langen Ausführungszeiten führen. - Workflow-Aufgaben-IDs: Die Abfrage enthält Platzhalter für Workflow-Aufgaben-IDs (z. B.
[Workflow Approved Task ID]). Diese sind für jede SAP-Installation einzigartig und müssen korrekt konfiguriert werden, damit Workflow-Aktivitäten extrahiert werden können. Ohne sie werden keine Übermittlungs-, Genehmigungs- oder Ablehnungsereignisse erfasst. - Voraussetzungen: Der ausführende Benutzer benötigt umfassende Leseberechtigungen für Finanz-, System- und Workflow-Tabellen. Diese Berechtigungen sind nicht Standard und müssen spezifisch 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
- ABAP-Programm erstellen: Greifen Sie über den Transaktionscode
SE38auf den ABAP Editor zu. Geben Sie einen Namen für das neue Programm ein, z. B.Z_PM_JE_EXTRACT, und klicken Sie auf 'Anlegen'. Geben Sie einen passenden Titel ein, setzen Sie den 'Typ' auf 'Ausführbares Programm' und speichern Sie es als lokales Objekt oder in einem Paket. - Selektionsbildschirm definieren: Definieren Sie im Programm Parameter und Selektionsoptionen, die es Benutzern ermöglichen, die Daten zu filtern. Dies sollte einen Datumsbereich für das Erstellungsdatum des Journaleintrags (
P_CPUDT_FR,P_CPUDT_TO), eine Selektionsoption für den Buchungskreis (SO_BUKRS) und einen Dateipfad für die Ausgabe auf dem Anwendungsserver (P_FPATH) umfassen. - Datenstrukturen deklarieren: Definieren Sie eine interne Tabellenstruktur, die dem erforderlichen Event Log Format entspricht. Diese Struktur enthält die endgültige Ausgabe. Deklarieren Sie außerdem interne Tabellen und Arbeitsbereiche für die SAP-Tabellen, aus denen Sie auswählen werden, wie BKPF, ACDOCA, CDHDR, CDPOS und verschiedene Workflow-Tabellen.
- Datenlogik implementieren: Schreiben Sie die zentrale ABAP-Logik, um Daten für jede der 12 benötigten Aktivitäten abzurufen. Erstellen Sie separate Unterprogramme (FORMs) für jede Aktivität, um den Code übersichtlich zu halten. Erstellen Sie beispielsweise ein FORM für
get_created_events,get_parked_events,get_workflow_eventsusw. - 'Erstellt' und 'Gebucht' Ereignisse auswählen: Lesen Sie aus der Tabelle BKPF basierend auf den Kriterien des Selektionsbildschirms des Benutzers. Ein Eintrag in BKPF bedeutet Erstellung. Ein Beleg mit dem Status
BSTAT = ' 'gilt als gebucht. Verwenden Sie den Erstellungs-Timestamp (CPUDT,CPUTM) als Ereigniszeitpunkt. - 'Geparkt' Ereignisse auswählen: Lesen Sie aus der Tabelle VBKPF, die die Kopfdaten geparkter Belege speichert. Der Erstellungs-Timestamp in dieser Tabelle stellt das Parkereignis dar.
- 'Workflow' Ereignisse auswählen (Eingereicht, Genehmigt, Abgelehnt): Fragen Sie Workflow-Tabellen wie SWW_WI2OBJ (um ein Journaleintragsobjekt mit einer Workflow-Instanz zu verknüpfen) und SWWLOGHIST oder SWWIHEAD (um die Details und Zeitpunkte spezifischer Schritte zu erhalten) ab. Sie müssen die spezifischen Workflow-Aufgaben-IDs für die Einreichung, Genehmigung und Ablehnung in Ihrem System identifizieren.
- 'Änderungs'- und 'Korrektur'-Ereignisse auswählen: Fragen Sie die Änderungsbelegtabellen CDHDR (Kopf) und CDPOS (Position) nach
OBJECTCLAS = 'BELEG'ab. Filtern Sie für 'Nach Buchung geändert' nach Änderungen, bei denen der Änderungs-Timestamp nach dem Buchungsdatum des Belegs liegt. Filtern Sie für 'Korrigiert' nach Änderungen an geparkten oder abgelehnten Belegen. - 'Storno'- und 'Ausgleichs'-Ereignisse auswählen: Identifizieren Sie Stornierungen, indem Sie Belege finden, bei denen das Feld
STBLG(Stornobelegnummer) in BKPF gefüllt ist. Der Storno-Ereigniszeitpunkt ist die Erstellungszeit des Stornobelegs. Identifizieren Sie Ausgleichsereignisse, indem Sie das neueste Ausgleichsdatum (AUGDT) aus der Tabelle ACDOCA für die Einzelposten eines gegebenen Journaleintrags auswählen. - Daten kombinieren und sortieren: Wenn die Daten jeder Aktivität ausgewählt werden, fügen Sie die Ergebnisse in die finale Haupt-Innentabelle ein. Nachdem alle Selektionen abgeschlossen sind, sortieren Sie die Haupttabelle nach
JournalEntryIdundEventTime, um die chronologische Reihenfolge für jeden Fall zu gewährleisten. - Ausgabedatei generieren: Verwenden Sie die Anweisungen
OPEN DATASET,LOOP AT... TRANSFERundCLOSE DATASET, um den Inhalt der sortierten finalen Innentabelle in den angegebenen Dateipfad auf dem SAP-Anwendungsserver zu schreiben. Die Datei sollte im CSV-Format mit einer Kopfzeile vorliegen. - Ausführung planen: Für regelmäßige Extraktionen verwenden Sie den Transaktionscode
SM36, um einen Hintergrund-Job zu erstellen, der das ProgrammZ_PM_JE_EXTRACTnach einem definierten Zeitplan, z. B. wöchentlich oder monatlich, ausführt. Dies automatisiert den Datenexportprozess.
Konfiguration
- Zeitraum: Der Selektionsbildschirm sollte einen obligatorischen Datumsbereich für das Erstellungsdatum des Journaleintrags (
CPUDT) enthalten. Es wird empfohlen, Daten in überschaubaren Blöcken, z. B. 3-6 Monate auf einmal, zu extrahieren, um eine gute Performance zu gewährleisten. - Buchungskreis (
BUKRS): Dies ist ein kritischer Filter, um die Extraktion auf die spezifischen rechtlichen Einheiten zu beschränken, die für die Process Mining Analyse relevant sind. Eine gleichzeitige Extraktion für alle Buchungskreise wird nicht empfohlen. - Belegart (
BLART): Sie können diesen optionalen Filter hinzufügen, um sich auf spezifische Arten von Journaleinträgen zu konzentrieren, wie 'SA' für Hauptbuchkontenbuchungen oder 'KR' für Kreditorenrechnungen. Dies kann dazu beitragen, das Datenvolumen zu reduzieren und die Relevanz des Datasets zu erhöhen. - Dateipfad: Das Programm benötigt einen logischen Dateipfad auf dem SAP-Anwendungsserver, auf dem die Ausgabedatei geschrieben wird. Stellen Sie sicher, dass der Pfad gültig ist und der SAP-Systembenutzer über die erforderlichen Schreibberechtigungen für dieses Verzeichnis verfügt. Verwenden Sie die Transaktion
AL11, um Serververzeichnisse zu verwalten und anzuzeigen. - Workflow-Aufgaben-IDs: Die Logik zur Extraktion von Workflow-Ereignissen (Eingereicht, Genehmigt, Abgelehnt) muss mit den spezifischen Aufgaben-IDs konfiguriert werden, die im Genehmigungs-Workflow für Journaleinträge Ihrer Organisation verwendet werden. Diese sind oft kundenspezifisch und müssen von einem Workflow-Berater oder Entwickler identifiziert werden.
- Voraussetzungen: Das Benutzer- oder Systemkonto, das das Programm ausführt, benötigt Entwicklerberechtigungen zum Erstellen und Ausführen von ABAP-Programmen (
S_DEVELOP) sowie umfassenden Lesezugriff auf Finanztabellen (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.