Ihr Daten-Template für den Record-to-Report-Prozess: Buchungen
Ihr Daten-Template für den Record-to-Report-Prozess: Buchungen
- Empfohlene Attribute für eine umfassende Analyse
- Wichtige Aktivitäten bei Buchungen, die Sie erfassen sollten
- Praktische Hinweise zum Datenexport aus SAP ECC
Attribute für den Record-to-Report-Prozess: Buchungen
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der Name der geschäftlichen Aktivität oder des Events, das zu einem bestimmten Zeitpunkt im Journal-Entry-Prozess stattgefunden hat. | ||
| Beschreibung Der Aktivitätsname bezeichnet einen bestimmten Schritt im Lebenszyklus einer Journalbuchung, etwa „Journalbuchung erstellt“, „Journalbuchung genehmigt“ oder „Journalbuchung verbucht“. Dieses Attribut wird üblicherweise aus mehreren SAP-Quellen abgeleitet, darunter Transaktionscodes (TCODE), Änderungsbelegprotokolle (Tabellen CDHDR und CDPOS) und Dokumentstatusfelder. Die Analyse von Aktivitäten bildet den Kern des Process Mining. Sie ermöglicht die Visualisierung von Prozesslandkarten, die Berechnung der Übergangszeiten zwischen Schritten und die Erkennung von Nacharbeitsschleifen, etwa wenn auf „Journalbuchung abgelehnt“ die Aktivität „Journalbuchung korrigiert“ folgt. Diese Daten sind eine wichtige Grundlage für Dashboards zu Durchlaufzeiten, Nacharbeitsquoten und Prozessvarianten. Warum das wichtig ist Das Attribut legt die Schritte in der Prozesslandkarte fest. So lässt sich der Journal-Entry-Workflow visualisieren, analysieren und optimieren. Woher beziehen Abgeleitet aus verschiedenen Quellen, darunter Transaktionscodes in BKPF (TCODE), Dokumentstatus und Workflow-Protokolle in Tabellen wie SWW_WI2OBJ sowie Änderungsbelege in CDHDR und CDPOS. Beispiele Journalbuchung erstelltJournalbuchung genehmigtJournalbuchung abgelehntJournalbuchung verbucht | |||
| Event-Zeitpunkt EventTime | Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Event für die Journalbuchung stattgefunden hat. | ||
| Beschreibung Der Event-Zeitpunkt enthält Datum und Uhrzeit jeder Aktivität im Journal-Entry-Prozess. Diese Daten sind entscheidend für die Berechnung zeitbezogener Kennzahlen wie Durchlaufzeiten, Bearbeitungsdauern und Verzögerungen zwischen Schritten. Die Quelle des Timestamps hängt von der Aktivität ab. Er kann aus dem Erstellungsdatum und der Erstellungsuhrzeit des Dokuments (CPUDT/CPUTM) oder aus Änderungs-Timestamps in Protokollen (CDHDR-UDATE/UTIME) stammen. In der Analyse dient der Event-Zeitpunkt dazu, Events chronologisch zu ordnen. Damit bildet er die Grundlage der Prozesslandkarte. Er ist unverzichtbar für alle zeitbezogenen KPIs, etwa die durchschnittliche Durchlaufzeit einer Journalbuchung, die durchschnittliche Genehmigungszeit und die Zeit von der Genehmigung bis zur Verbuchung. Warum das wichtig ist Dieser Timestamp bildet die Grundlage aller zeitbezogenen Analysen. Mit ihm lassen sich Durchlaufzeiten, Dauern und Engpässe berechnen. Woher beziehen Je nach Aktivität stammt der Wert aus verschiedenen Feldern, vor allem aus dem Erstellungs-Timestamp (CPUDT, CPUTM) in BKPF oder den Änderungsbeleg-Timestamps (UDATE, UTIME) in CDHDR. Beispiele 2023-10-26T09:00:00Z2023-10-26T14:30:15Z2023-10-27T11:05:00Z | |||
| Journal Entry ID JournalEntryId | Der eindeutige Bezeichner eines Finanzbuchhaltungsbelegs. Er setzt sich aus Buchungskreis, Belegnummer und Geschäftsjahr zusammen. | ||
| Beschreibung Die Journal Entry ID ist die primäre Case-ID, mit der der Lebenszyklus einer Journalbuchung verfolgt wird. Sie ist ein zusammengesetzter Schlüssel, der üblicherweise aus Buchungskreis (BUKRS), Belegnummer (BELNR) und Geschäftsjahr (GJAHR) gebildet wird. So ist die ID im gesamten SAP-System eindeutig. In der Prozessanalyse verknüpft diese ID alle zugehörigen Aktivitäten, etwa Erstellung, Parken, Einreichung, Genehmigung, Ablehnung und Verbuchung. Anhand der ID lässt sich der gesamte Ablauf jeder Journalbuchung nachvollziehen, die Durchlaufzeit messen und nach Prozessabweichungen oder Engpässen bei einzelnen Buchungen suchen. Warum das wichtig ist Dieser Schlüssel ist unverzichtbar, um eine Journalbuchung von der Erstellung bis zur endgültigen Verbuchung zu verfolgen. Er ermöglicht die Prozessanalyse von Anfang bis Ende und den Vergleich von Varianten. Woher beziehen Dieses abgeleitete Attribut setzt sich üblicherweise aus Feldern der Tabelle BKPF zusammen: Buchungskreis (BUKRS), Belegnummer (BELNR) und Geschäftsjahr (GJAHR). Beispiele 1000-1000000123-20232000-1900000456-20231000-1800000789-2024 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp der letzten Extraktion oder Aktualisierung der Daten aus dem Quellsystem. | ||
| Beschreibung Dieses Attribut erfasst Datum und Uhrzeit des letzten Datenabrufs aus SAP ECC. Es handelt sich um ein Metadatenfeld, das wichtig ist, um die Aktualität der analysierten Daten einzuschätzen. In jedem Process-Mining-Dashboard und jeder Analyse ist der Zeitpunkt der letzten Aktualisierung entscheidend, damit Benutzer den Daten vertrauen und fundierte Entscheidungen treffen können. Er beantwortet die Frage: „Wie aktuell sind diese Informationen?“ Warum das wichtig ist Informiert Benutzer über die Aktualität der Daten. So können sie den Analysezeitraum einordnen und den Ergebnissen vertrauen. Woher beziehen Dieses Metadatenfeld wird vom Datenextraktionstool oder ETL-Prozess bei der Datenaktualisierung erstellt und gespeichert. Beispiele 2024-05-20T04:00:00Z2024-05-21T04:00:00Z2024-05-22T04:00:00Z | |||
| Quellsystem SourceSystem | Das System, aus dem die Prozessdaten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt die Herkunft der Daten an, in diesem Fall die konkrete SAP-ECC-Instanz. Es handelt sich üblicherweise um einen statischen Wert, der bei der Datenextraktion hinzugefügt wird. Auch wenn das Attribut einfach ist, spielt es in Umgebungen mit mehreren ERP-Systemen oder Datenquellen eine wichtige Rolle. Es macht die Datenherkunft nachvollziehbar und ermöglicht es, Analysen nach dem Ursprungssystem zu filtern oder aufzuschlüsseln. Warum das wichtig ist Macht die Datenherkunft nachvollziehbar und ist wichtig, um die Datenqualität zu verfolgen, insbesondere bei mehreren Quellsystemen. Woher beziehen Üblicherweise ein statischer Wert, der bei der Datentransformation hinzugefügt wird und die konkrete SAP-ECC-Instanz angibt, zum Beispiel 'ECC_PROD_100'. Beispiele SAP ECC EHP8ECC_FIN_PRODSAP_ERP_60 | |||
| Belegart DocumentType | Eine Klassifizierung für Buchhaltungsbelege, die deren Verarbeitung und Speicherung steuert. | ||
| Beschreibung Die Belegart unterscheidet verschiedene Arten von Geschäftsvorfällen, etwa eine Hauptbuchbuchung (SA), eine Lieferantenrechnung (KR) oder eine Anlagenbuchung (AA). Sie wird bei der Systemkonfiguration festgelegt und jeder Journalbuchung zugewiesen. Dieses wichtige Attribut ermöglicht es, Prozesse nach der Art des Geschäftsvorfalls aufzuschlüsseln. Das Dashboard „Journalbuchungsvolumen nach Belegart“ und der KPI „Durchschnittliche Durchlaufzeit nach Journalbuchungsart“ hängen direkt von diesem Feld ab. So lässt sich feststellen, ob bestimmte Buchungsarten häufiger zu Verzögerungen, Nacharbeit oder Stornierungen führen. Warum das wichtig ist Ermöglicht die Aufschlüsselung der Analyse nach Transaktionsart. So lässt sich erkennen, ob Prozessprobleme nur bestimmte Arten von Journalbuchungen betreffen. Woher beziehen In der Belegkopftabelle BKPF, Feld BLART. Beispiele SAKRREAA | |||
| Benutzer User | Die SAP-Benutzer-ID der Person, die die Journalbuchung erstellt oder geändert hat. | ||
| Beschreibung Dieses Attribut erfasst den SAP-Benutzernamen der Person, die für eine bestimmte Aktivität verantwortlich ist, etwa das Erstellen, Parken oder Verbuchen eines Dokuments. Die Daten stammen direkt aus der Belegkopf- oder Änderungsprotokolltabelle. Die Analyse des Attributs „Benutzer“ ist wichtig, um die Leistung von Teams und einzelnen Personen zu verstehen. Das Dashboard zur Benutzerproduktivität erfasst damit Aktivitätsvolumen und Bearbeitungszeiten pro Benutzer. Außerdem lässt sich erkennen, wer an Nacharbeitsschleifen, Stornierungen oder Compliance-Abweichungen beteiligt ist. So können Schulungen und Prozessverbesserungen gezielt angesetzt werden. Warum das wichtig ist Gibt an, welcher Benutzer für die jeweilige Aktivität verantwortlich ist. So lassen sich Benutzerleistung, Arbeitsverteilung und Nacharbeitsmuster analysieren. Woher beziehen Üblicherweise aus der Tabelle BKPF (Feld USNAM für den Ersteller) oder der Tabelle CDHDR (Feld USERNAME für die Person, die die Änderung vorgenommen hat). Beispiele ABROWNCJONESDSMITH | |||
| Buchungsdatum PostingDate | Das Datum, an dem die Transaktion im Hauptbuch erfasst wird und damit die Finanzperiode beeinflusst. | ||
| Beschreibung Das Buchungsdatum bestimmt die Finanzperiode, der die Journalbuchung zugeordnet wird. Aus finanzieller und Compliance-Sicht ist dieses Datumsfeld entscheidend, da es mit den Zeitplänen für den Abschluss der Buchungsperiode und den geltenden Vorschriften übereinstimmen muss. Beim Process Mining dient das Buchungsdatum zur Überwachung der Compliance. Das Dashboard zur Überwachung der Compliance-Einhaltung und der KPI zur Compliance-Konformitätsquote verwenden dieses Attribut, um zu prüfen, ob Buchungen in der richtigen Periode erfolgen. Außerdem lassen sich damit Trends beim Volumen von Journalbuchungen im Zeitverlauf analysieren. Warum das wichtig ist Wichtig für Finanzberichte und Compliance-Analysen. Das Attribut stellt sicher, dass Buchungen der richtigen Buchungsperiode zugeordnet werden. Woher beziehen In der Belegkopftabelle BKPF, Feld BUDAT. Beispiele 2023-10-312023-11-302024-01-15 | |||
| Buchungskreis CompanyCode | Die Organisationseinheit, die eine eigenständige juristische Person repräsentiert, für die ein Jahresabschluss erstellt wird. | ||
| Beschreibung Der Buchungskreis ist eine grundlegende Organisationseinheit in SAP Financials. Er steht für ein rechtlich selbstständiges Unternehmen und ist ein wichtiges Feld im Belegkopf einer Journalbuchung. Dieses Attribut ist unverzichtbar, um Prozessanalysen nach juristischen Personen aufzuschlüsseln. Damit lassen sich Prozessleistung, Compliance-Quoten und KPI-Ergebnisse in verschiedenen Unternehmensbereichen vergleichen. So können Sie beispielsweise erkennen, ob Genehmigungsverzögerungen oder hohe Stornoquoten nur bestimmte Buchungskreise betreffen. Warum das wichtig ist Ermöglicht es, die Prozessleistung verschiedener juristischer Personen oder Geschäftseinheiten innerhalb der Organisation zu filtern und zu vergleichen. Woher beziehen In der Belegkopftabelle BKPF, Feld BUKRS. Beispiele 10002000US01DE01 | |||
| Storniert IsReversed | Ein boolesches Kennzeichen, das angibt, ob die Journalbuchung storniert wurde. | ||
| Beschreibung Dieses Kennzeichen weist Buchungen aus, die nachträglich durch einen anderen Buchhaltungsbeleg storniert wurden. In SAP ist der stornierte Beleg mit dem Stornobeleg verknüpft. So entsteht ein nachvollziehbarer Prüfpfad. Dieses Attribut ist eine wichtige Grundlage für das Dashboard „Analyse stornierter Buchungen“ und die KPI „Stornoquote bei Buchungen“. Damit lassen sich stornierte Buchungen gezielt untersuchen und Ursachen wie Eingabefehler oder falsche Buchungen ermitteln. Ziel ist es, die Zahl der Stornierungen zu senken. Warum das wichtig ist Unterstützt die Stornoanalyse direkt: Das Kennzeichen weist nachträglich stornierte Buchungen aus und hilft, Fehlerursachen zu ermitteln und die Datenintegrität zu verbessern. Woher beziehen Abgeleitet aus dem Feld für die Stornobelegnummer (STBLG) in der Tabelle BKPF. Ist STBLG nicht leer, ist das Kennzeichen auf „true“ gesetzt. Beispiele truefalse | |||
| Transaktionscode TransactionCode | Der SAP-Transaktionscode, mit dem die Journalbuchung erstellt oder verarbeitet wurde. | ||
| Beschreibung Der Transaktionscode (T-Code) ist ein eindeutiger Bezeichner für eine bestimmte Funktion oder ein Programm in SAP. Bei Journalbuchungen gibt er an, wie die Buchung erstellt wurde, zum Beispiel manuell (FB01, F-02), durch Parken (FV50) oder über eine automatisierte Schnittstelle. Dieses Attribut ist für das Dashboard zur Optimierung manueller Aktivitäten besonders wertvoll. Anhand des T-Codes lassen sich manuelle und automatisierte Aktivitäten unterscheiden, besonders zeitaufwendige manuelle Prozesse ermitteln und Automatisierungsmöglichkeiten erkennen. So sinkt der manuelle Aufwand und die Effizienz steigt. Warum das wichtig ist Hilft, manuelle und automatisierte Prozesse zu unterscheiden und Möglichkeiten für Automatisierung und Prozessstandardisierung zu erkennen. Woher beziehen In der Belegkopftabelle BKPF, Feld TCODE. Beispiele FB01F-02FV50FBD1 | |||
| Genehmigungsdauer ApprovalTime | Die Zeitspanne zwischen der Einreichung einer Buchung zur Genehmigung und ihrer Genehmigung oder Ablehnung. | ||
| Beschreibung Diese Kennzahl misst die Dauer des Genehmigungsteilprozesses, der häufig einen erheblichen Anteil an der gesamten Zykluszeit hat. Sie wird als Zeitdifferenz zwischen der Aktivität „Buchung eingereicht“ und der entsprechenden Aktivität „Buchung genehmigt“ oder „Buchung abgelehnt“ berechnet. Die Genehmigungsdauer ist die zentrale Kennzahl für das Dashboard „Leistung bei der Genehmigung von Buchungen“ und die KPI „Durchschnittliche Genehmigungsdauer von Buchungen“. Ihre Analyse hilft, Engpässe im Genehmigungs-Workflow aufzudecken, die Leistung der Genehmigenden zu messen und Prozessänderungen wie angepasste Genehmigungsschwellen zu begründen. Warum das wichtig ist Beziffert die Dauer der Genehmigungsphase und hilft, Verzögerungen im Prüf- und Genehmigungs-Workflow aufzudecken und zu beheben. Woher beziehen Berechnet durch Subtraktion des Timestamp des Ereignisses „Buchung eingereicht“ vom Timestamp des Ereignisses „Buchung genehmigt“ oder „Buchung abgelehnt“. Beispiele P1DT2HPT4H15MP3D | |||
| Gesamtbelegbetrag TotalDocumentAmount | Der Gesamtwert der Journalbuchung in der Belegwährung. | ||
| Beschreibung Dieses Attribut gibt den Gesamtwert der Journalbuchung an. Üblicherweise wird er berechnet, indem die Absolutwerte aller Soll- oder Haben-Einzelposten des Dokuments addiert werden. Die Analyse des Prozesses nach Finanzwerten kann wichtige Muster aufdecken. Für Buchungen mit hohen Beträgen kann beispielsweise ein anderer, strengerer Genehmigungsweg gelten. Mit diesem Attribut lässt sich die Analyse filtern oder aufschlüsseln, um zu prüfen, ob Durchlaufzeiten, Ablehnungsquoten oder Genehmigungsverzögerungen mit dem Buchungsbetrag zusammenhängen. Warum das wichtig ist Ermöglicht Analysen der finanziellen Auswirkungen, etwa den Zusammenhang zwischen Bearbeitungszeiten oder Ablehnungsquoten und dem Geldwert von Journalbuchungen. Woher beziehen Dieses berechnete Feld wird ermittelt, indem die Beträge (WRBTR oder DMBTR) aller Einzelposten einer Journalbuchung in der Tabelle BSEG addiert werden. Beispiele 1500.0025000.75125.50 | |||
| Ist geparkt IsParked | Ein boolesches Kennzeichen dafür, ob die Buchung vor dem Buchen als geparkter Beleg gespeichert wurde. | ||
| Beschreibung Durch das Parken kann ein Benutzer eine unvollständige Buchung speichern, ohne dass sie sich auf die Finanzsalden auswirkt. Ein anderer Benutzer kann sie anschließend vervollständigen oder prüfen, bevor sie gebucht wird. Dieses Kennzeichen weist Buchungen aus, die einen Parkschritt durchlaufen haben. Die Analyse dieses Attributs zeigt, wie die Parkfunktion eingesetzt wird. Sie kann aufdecken, ob das Parken als informeller Prüfschritt dient und dadurch Verzögerungen entstehen. Außerdem unterstützt sie die Analyse der Zykluszeit von Anfang bis Ende und unterscheidet zwischen direkt gebuchten und zunächst geparkten Buchungen. Warum das wichtig ist Weist Buchungen aus, bei denen die Parkfunktion verwendet wurde. Das kann auf Verzögerungen oder einen informellen Prüfprozess hindeuten. Woher beziehen Abgeleitet aus dem Belegstatusfeld (BSTAT) in der Tabelle BKPF. „V“ kennzeichnet einen geparkten Beleg. Beispiele truefalse | |||
| Ist Nacharbeit IsRework | Ein boolesches Kennzeichen dafür, ob eine Buchung eine Nacharbeitsschleife durchlaufen hat, etwa weil sie abgelehnt und anschließend korrigiert wurde. | ||
| Beschreibung Dieses Kennzeichen weist Cases aus, die vom Happy Path abgewichen sind und eine Korrektur erforderten. Es wird in der Regel auf „true“ gesetzt, wenn bei einer Buchung eine Abfolge von Aktivitäten wie „Buchung abgelehnt“ und anschließend „Buchung korrigiert“ festgestellt wird. Dieses Attribut ist für die Berechnung der KPI „Nacharbeitsquote bei Buchungen“ und die Analyse im Dashboard „Nacharbeits- und Ablehnungsquote“ erforderlich. Es quantifiziert die Ineffizienz im Prozess und bildet die Grundlage, um Ursachen für Nacharbeit zu untersuchen, etwa unklare Anforderungen oder unzureichende Dokumentation. Warum das wichtig ist Kennzeichnet Buchungen, die korrigiert werden mussten. So lassen sich Nacharbeit quantifizieren und ihre Ursachen untersuchen, um die Quote korrekt erledigter Vorgänge beim ersten Versuch zu verbessern. Woher beziehen Dieses berechnete Attribut wird aus der Abfolge der Aktivitäten eines Cases abgeleitet. Eine Nacharbeitsschleife liegt vor, wenn eine Ablehnungs- oder Korrekturaktivität auftritt. Beispiele truefalse | |||
| Kostenstelle CostCenter | Eine Organisationseinheit innerhalb eines Controlling-Kreises, der ein Ort zugeordnet ist, an dem Kosten anfallen. | ||
| Beschreibung Die Kostenstelle ist ein zentrales Stammdatenobjekt des Controllings (CO) und wird häufig auf Positionsebene einer Buchung zugeordnet. Sie dient dazu, Kosten einer bestimmten Abteilung, Funktion oder einem Standort zuzuordnen. Mit der Kostenstelle lässt sich der Buchungsprozess detaillierter analysieren. So können Sie feststellen, ob bestimmte Abteilungen mehr Nacharbeit verursachen, längere Zykluszeiten haben oder häufiger manuelle Buchungen vornehmen. Dadurch wird die Prozesseffizienz nach Abteilung sichtbar. Warum das wichtig ist Ermöglicht die Analyse der Prozessleistung nach Abteilung oder Funktionsbereich und hilft, lokale Ineffizienzen aufzudecken. Woher beziehen In der Belegpositionstabelle BSEG, Feld KOSTL. Beispiele 4100CC_FINANCE_US10010101 | |||
| Stornogrund ReversalReason | Ein Code, der den Grund für die Stornierung einer Buchung angibt. | ||
| Beschreibung Beim Stornieren eines Belegs kann der Benutzer in SAP einen Grundcode angeben. Dieser Code erfasst strukturiert, warum die Stornierung erforderlich war, zum Beispiel wegen eines falschen Buchungsdatums oder eines Eingabefehlers. Dieses Attribut ist eine wichtige Eingabegröße für das Dashboard „Analyse stornierter Buchungen“. Die häufigsten Stornogründe zeigen, wo es systematische Probleme in den Prozessen oder Schulungslücken gibt. Unternehmen können daraufhin gezielte Maßnahmen ergreifen, um künftige Fehler und die Stornoquote zu senken. Warum das wichtig ist Zeigt direkt, warum Stornierungen erfolgen, und ermöglicht gezielte Ursachenanalysen, um künftige Fehler zu vermeiden. Woher beziehen In der Belegkopftabelle BKPF, Feld STGRD. Beispiele 010205 | |||
| Währungsschlüssel CurrencyKey | Der Währungscode für die Beträge in der Buchung. | ||
| Beschreibung Dieses Attribut gibt die Währung der Buchung an, zum Beispiel USD, EUR oder JPY. Es ordnet die mit dem Beleg verbundenen Finanzbeträge ein. Auch wenn die Währung nicht immer eine zentrale Analysedimension ist, muss sie für die korrekte Interpretation der Geldbeträge berücksichtigt werden. In global tätigen Organisationen lässt sich die Analyse außerdem nach Währungen aufteilen, um Prozesse bei Buchungen in Fremdwährungen mit denen bei Buchungen in der lokalen Währung zu vergleichen. Warum das wichtig ist Ordnet alle Geldbeträge ein und ermöglicht so eine korrekte Finanzanalyse und Interpretation. Woher beziehen In der Belegkopftabelle BKPF, Feld WAERS. Beispiele USDEURGBPJPY | |||
Aktivitäten im Record-to-Report-Prozess: Buchungen
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Journalbuchung eingereicht | Diese Aktivität zeigt an, dass der Ersteller eine geparkte Journalbuchung abgeschlossen hat und sie nun zur Prüfung und Genehmigung bereit ist. Erfasst wird sie üblicherweise, wenn eine SAP-Business-Workflow-Aufgabe für das geparkte Dokument gestartet wird. | ||
| Warum das wichtig ist Damit wird die Übergabe vom Ersteller an den Genehmigenden markiert. Zugleich beginnt die Messung der Zykluszeit für Genehmigungs-KPIs. Dieser Meilenstein ist wichtig, um die Effizienz des Genehmigungsworkflows zu messen. Woher beziehen Abgeleitet aus der Startzeit der Genehmigungsworkflow-Instanz, die mit dem Finanzdokumentobjekt verknüpft ist. Dafür müssen Workflow-Protokolltabellen wie SWW_WI2OBJ analysiert werden, um den Workflow für den jeweiligen Buchungskreis, die Belegnummer und das Geschäftsjahr zu ermitteln. Erfassung Ermitteln Sie das Workflow-Start-Event für das geparkte Dokumentobjekt. Ereignistyp inferred | |||
| Journalbuchung genehmigt | Diese Aktivität kennzeichnet die endgültige Genehmigung einer Journalbuchung im Workflow. Damit ist sie zur Verbuchung bereit. Erfasst wird das Event im Workflow-Protokoll, wenn der letzte Schritt „Freigabe“ oder „Genehmigung“ abgeschlossen ist. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein schließt den Genehmigungsprozess ab. Die Dauer bis zu dieser Aktivität ist ein entscheidender KPI für die Genehmigungseffizienz. Die Zeit von diesem Event bis zur Verbuchung zeigt die Verzögerung nach der Genehmigung. Woher beziehen Abgeleitet aus dem Abschluss-Timestamp des letzten Genehmigungsschritts im SAP-Business-Workflow-Protokoll. Dies ist die letzte Genehmigungsaktion, bevor das Dokument verbucht oder zur Verbuchung freigegeben wird. Erfassung Ermitteln Sie den Abschluss des letzten Schritts „Freigabe“ oder „Genehmigung“ in den Workflow-Protokollen. Ereignistyp inferred | |||
| Journalbuchung geparkt | Diese Aktivität kennzeichnet die erstmalige Erstellung einer Journalbuchung in einem vorläufigen Status, bevor sie offiziell im Hauptbuch verbucht wird. In SAP wird sie ausdrücklich erfasst, wenn ein Benutzer ein Dokument über eine Parktransaktion speichert und damit den Dokumentstatus auf „geparkt“ setzt. | ||
| Warum das wichtig ist Dies ist ein wichtiges Start-Event für Prozesse mit Prüfung und Genehmigung. Die Analyse der Zeit zwischen dem Parken und der Verbuchung macht Verzögerungen vor der Verbuchung und in der Genehmigungsphase sichtbar. Woher beziehen Dieses Event wird anhand der Belegkopftabelle BKPF ermittelt. Ein Dokument gilt als geparkt, wenn es mit dem Status BKPF-BSTAT = 'V' angelegt wird. Als Timestamp des Events dienen Erstellungsdatum und -uhrzeit, BKPF-CPUDT und BKPF-CPUTM. Erfassung Ermitteln Sie die Dokumenterstellung in BKPF, wenn BKPF-BSTAT den Wert 'V' hat. Ereignistyp explicit | |||
| Journalbuchung storniert | Diese Aktivität kennzeichnet die Stornierung einer zuvor verbuchten Journalbuchung. Eine Stornierung ist ein neuer Buchungsbeleg, der die ursprüngliche Buchung aufhebt. | ||
| Warum das wichtig ist Dieses Event ist entscheidend, um Datenqualität und Prozessgenauigkeit zu messen. Eine hohe Stornoquote weist auf systematische Probleme bei der ursprünglichen Dateneingabe oder in den Genehmigungsphasen hin. Jede Stornierung bedeutet zusätzliche Nacharbeit. Woher beziehen Dieses Event wird im Belegkopf des ursprünglichen Dokuments (Tabelle BKPF) ermittelt. Bei einer Stornierung trägt SAP die Stornobelegnummer (BKPF-STBLG) und den Stornogrund (BKPF-STGRD) ein. Als Timestamp des Events dient das Buchungsdatum des neuen Stornobelegs. Erfassung Ermitteln Sie, wann BKPF-STBLG im ursprünglichen Dokument befüllt wird. Als Timestamp dient das Buchungsdatum des Stornobelegs. Ereignistyp explicit | |||
| Journalbuchung verbucht | Bei dieser zentralen Aktivität wird die Journalbuchung offiziell im Hauptbuch erfasst und wirkt sich auf den Jahresabschluss aus. Das Event wird ausdrücklich erfasst, wenn der Dokumentstatus auf „verbucht“ gesetzt und ein Buchungsdatum zugewiesen wird. | ||
| Warum das wichtig ist Dies ist der wichtigste Meilenstein und kennzeichnet die erfolgreiche Verarbeitung einer Journalbuchung. Die Durchlaufzeit des gesamten Prozesses wird häufig bis zu diesem Punkt gemessen. Das Event ist außerdem für die Analyse des Finanzabschlusses wichtig. Woher beziehen Das Event wird erkannt, wenn ein Dokument in der Tabelle BKPF ein Buchungsdatum (BKPF-BUDAT) hat. Bei geparkten Dokumenten entspricht dies dem Zeitpunkt, an dem sich BKPF-BSTAT von 'V' in einen leeren Wert ändert. Als Timestamp der Verbuchung dient das Erfassungsdatum BKPF-CPUDT. Erfassung Ermitteln Sie, wann sich BKPF-BSTAT von 'V' in einen leeren Wert ändert. Bei direkten Buchungen verwenden Sie das Erstellungs-Event. Ereignistyp explicit | |||
| Änderungen an der Journalbuchung angefordert | Dieses Event kennzeichnet den Punkt im Workflow, an dem ein Genehmigender die Journalbuchung geprüft und zur Korrektur an den Ersteller zurückgesendet hat. Es wird anhand von Workflow-Protokollen erfasst, die eine Benutzerentscheidung wie „abgelehnt“ oder „zurückgesendet“ ausweisen. | ||
| Warum das wichtig ist Diese Aktivität ist wichtig, um Nacharbeitsschleifen zu erkennen, die eine wesentliche Ursache für Ineffizienz und Prozessabweichungen sind. Tritt das Event häufig auf, deutet dies auf Probleme mit der Qualität der Buchungen oder unklare Anforderungen hin. Woher beziehen Dieses Event wird anhand des Timestamps eines bestimmten Entscheidungsschritts im SAP-Business-Workflow-Protokoll abgeleitet, der einer Aktion wie „ablehnen“ oder „zur Korrektur senden“ entspricht. Erfassung Ermitteln Sie den Timestamp der Entscheidung „Ablehnung“ oder „Nacharbeit“ in den Workflow-Protokollen. Ereignistyp inferred | |||
| Buchung über mehrere Buchungskreise erkannt | Diese berechnete Aktivität kennzeichnet eine Journalbuchung, die mehr als einen Buchungskreis betrifft. Sie wird anhand der Einzelposten eines Finanzbelegs ermittelt. | ||
| Warum das wichtig ist Transaktionen über mehrere Buchungskreise können komplexere Verarbeitungs- und Genehmigungsanforderungen haben. Durch ihre Erkennung lassen sich Durchlaufzeiten und Prozesspfade separat analysieren und spezifische Engpässe ermitteln. Woher beziehen Die Berechnung erfolgt anhand der Einzelpostentabelle BSEG für eine bestimmte Belegnummer (BELNR). Enthalten die Einzelposten mehr als einen unterschiedlichen Buchungskreis (BSEG-BUKRS), handelt es sich um eine Buchung über mehrere Buchungskreise. Erfassung Prüfen Sie, ob für eine einzelne BKPF-BELNR mehrere unterschiedliche Werte für BSEG-BUKRS vorhanden sind. Ereignistyp calculated | |||
| Dokumentation angehängt | Diese Aktivität steht dafür, dass ein Benutzer Belege wie Rechnungen oder Tabellen an die Journalbuchung anhängt. Sie wird nicht als standardmäßiges Buchungs-Event ausdrücklich protokolliert. In der Regel lässt sie sich ableiten, indem geprüft wird, ob Anhänge zum Buchungsbelegobjekt erstellt wurden. | ||
| Warum das wichtig ist Die Erfassung dieser Aktivität hilft zu prüfen, ob die Dokumentationspflichten eingehalten werden. Verzögerungen beim Anhängen von Dokumenten können zu längeren Genehmigungszyklen führen. Woher beziehen Dieses Event lässt sich nur schwer zuverlässig mit einem Timestamp erfassen. Es kann möglicherweise aus den Anhangtabellen der Generic Object Services (GOS), etwa SOOD, abgeleitet werden. Dazu wird der Erstellungs-Timestamp des Anhangs mit dem Objektschlüssel der Journalbuchung verknüpft. Erfassung Leiten Sie das Event aus dem Erstellungs-Timestamp verknüpfter Objekte in GOS-Tabellen ab, zum Beispiel SOOD. Ereignistyp inferred | |||
| Einzelposten der Journalbuchung ausgeglichen | Diese Aktivität steht für den Ausgleich eines offenen Einzelpostens auf einem abstimmungsrelevanten Sachkonto, etwa einem Bankverrechnungskonto. Sie tritt auf, wenn ein Einzelposten einem anderen zugeordnet und damit ausgeglichen wird. | ||
| Warum das wichtig ist Bei Prozessen wie dem Bankabgleich ist die Zeit bis zum Ausgleich der Posten ein wichtiger KPI. Diese Aktivität hilft, die Effizienz des Abgleichs und des Monatsabschlusses zu analysieren. Woher beziehen Dieses Event wird anhand der Einzelpostentabelle BSEG erfasst. Beim Ausgleich eines Einzelpostens werden die Felder für das Ausgleichsdatum (BSEG-AUGDT) und den Ausgleichsbeleg (BSEG-AUGBL) befüllt. Als Timestamp des Events dient das Ausgleichsdatum. Erfassung Ermitteln Sie, wann das Ausgleichsdatum (BSEG-AUGDT) für einen Einzelposten eingetragen wird. Ereignistyp explicit | |||
| Geparkte Journalbuchung gelöscht | Kennzeichnet die Löschung einer geparkten Journalbuchung, die nie verbucht wurde. Dies kann nach einer Ablehnung geschehen oder wenn die Buchung versehentlich erstellt wurde. | ||
| Warum das wichtig ist Diese Aktivität kennzeichnet ein erfolgloses Prozessende. Die Analyse der Gründe für die Löschung geparkter Dokumente kann Probleme wie doppelte Buchungen oder Missverständnisse im Prozess aufdecken. Woher beziehen Dieses Event wird erfasst, wenn sich der Status eines geparkten Dokuments in der Tabelle BKPF ändert. Das Statusfeld BKPF-BSTAT wird auf 'Z' (geparktes Dokument gelöscht) gesetzt. Der Timestamp der Änderung ist in den Dokumentänderungsprotokollen (CDHDR) zu finden. Erfassung Ermitteln Sie, wann BKPF-BSTAT auf 'Z' gesetzt wird. Ereignistyp explicit | |||
| Journalbuchung abgelehnt | Diese Aktivität kennzeichnet die endgültige Ablehnung einer Journalbuchung, die danach nicht verbucht wird. In einem Genehmigungsworkflow ist dies üblicherweise ein Endstatus, auf den die Löschung des geparkten Dokuments folgt. | ||
| Warum das wichtig ist Die Erfassung von Ablehnungen ist für das Qualitätsmanagement entscheidend. Die Analyse der Gründe und Häufigkeit von Ablehnungen hilft, den Anteil der Journalbuchungen zu erhöhen, die gleich beim ersten Mal richtig sind. Woher beziehen Dieses Ergebnis wird im SAP-Business-Workflow-Protokoll erfasst. Es steht für eine endgültige Benutzerentscheidung „Ablehnen“, die den Prozess beendet. Das geparkte Dokument kann anschließend gelöscht werden. Erfassung Ermitteln Sie den endgültigen Status „Abgelehnt“ des Dokuments im Workflow-Protokoll. Ereignistyp inferred | |||
| Journalbuchung erstellt | Kennzeichnet die Erstellung einer Journalbuchung, die ohne vorherigen Parkschritt direkt verbucht wird. Erfasst wird dies, wenn ein Dokument in SAP über eine direkte Buchungstransaktion angelegt wird. | ||
| Warum das wichtig ist Diese Aktivität dient als alternativer Startpunkt für einfachere Journal-Entry-Prozesse ohne Genehmigungsworkflow. Sie unterscheidet direkte Buchungen von komplexeren, geparkten Buchungen. Woher beziehen Dieses Event entspricht der Dokumenterstellung in der Tabelle BKPF, wenn der Dokumentstatus BKPF-BSTAT leer ist (verbucht). Als Timestamp des Events dient das Erstellungsdatum BKPF-CPUDT. Bei diesen Dokumenten treten die Events „Erstellt“ und „Verbucht“ gleichzeitig auf. Erfassung Ermitteln Sie die Dokumenterstellung in BKPF, wenn BKPF-BSTAT leer ist. Ereignistyp explicit | |||
| Journalbuchung korrigiert | Diese Aktivität zeigt an, dass der ursprüngliche Ersteller eine geparkte Journalbuchung geändert hat, nachdem sie zur Korrektur zurückgesendet wurde. Sie wird abgeleitet, indem Änderungen am Dokument nach dem Event „Änderungen angefordert“ erkannt werden. | ||
| Warum das wichtig ist Die Erfassung von Korrekturen hilft, den Aufwand für Nacharbeit zu beziffern. Die Zeit zwischen einer Änderungsanforderung und der Korrektur zeigt, wie lange die Behebung von Problemen mit eingereichten Buchungen dauert. Woher beziehen Abgeleitet aus der Analyse der Änderungsbelegprotokolle (Tabellen CDHDR und CDPOS) für das geparkte Dokument. Eine nach einer Ablehnung im Workflow erfasste Änderung kennzeichnet eine Korrektur. Der Timestamp stammt aus der Tabelle CDHDR. Erfassung Ermitteln Sie einen Eintrag im Änderungsprotokoll CDHDR/CDPOS nach einem Ablehnungs-Event. Ereignistyp inferred | |||
| Manuelle Eingabe erkannt | Diese Aktivität zeigt an, ob eine Journalbuchung über eine manuelle Online-Transaktion oder über eine automatisierte Schnittstelle beziehungsweise einen Stapelverarbeitungsprozess erstellt wurde. Es handelt sich nicht um eine Benutzeraktion, sondern um ein berechnetes Attribut des Eintrags, das aus Systemdaten abgeleitet wird. | ||
| Warum das wichtig ist Die Unterscheidung zwischen manuellen und automatisierten Buchungen ist wichtig, um Prozessverbesserungen gezielt anzugehen. Manuelle Prozesse stehen häufig im Mittelpunkt von Standardisierungs- und Automatisierungsmaßnahmen. Woher beziehen Die Berechnung erfolgt anhand von Feldern in der Belegkopftabelle BKPF. Transaktionscodes (BKPF-TCODE) wie 'FB01', 'FB50' oder 'FV50' weisen auf eine manuelle Eingabe hin. Andere T-Codes oder bestimmte Namen für Batch-Inputs (BKPF-AWKEY) sprechen für eine Automatisierung. Erfassung Leiten Sie das Attribut aus BKPF-TCODE oder anderen Indikatoren des Quellsystems in der Belegkopfzeile ab. Ereignistyp calculated | |||
Anleitungen zum Datenexport
Schritte
- ABAP-Programm erstellen: Öffnen Sie im SAP-System die Transaktion SE38 (ABAP Editor). Geben Sie einen Namen für das neue Programm ein, zum Beispiel Z_PM_JE_EXTRACTION, und klicken Sie auf „Erstellen“. Vergeben Sie einen passenden Titel und wählen Sie als Programmtyp „Ausführbares Programm“.
- Selektionsbild definieren: Definieren Sie im Quellcode des Programms das Selektionsbild. Damit können Benutzer Parameter wie einen Zeitraum für die Belegerstellung, Buchungskreise und Belegarten angeben, um das Datenvolumen beim Export zu begrenzen.
- Datenstrukturen deklarieren: Definieren Sie eine interne Tabellenstruktur für die endgültigen Event-Log-Daten. Sie muss alle erforderlichen Felder enthalten: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate sowie empfohlene Attribute wie User, CompanyCode und PostingDate.
- Logik zur Datenauswahl implementieren: Schreiben Sie die zentralen ABAP-SQL-Abfragen, um Daten für jede der 14 erforderlichen Aktivitäten zu extrahieren. Dazu gehören Abfragen der Primärtabellen BKPF (Kopf) und BSEG (Position), der Änderungsbelegtabellen CDHDR und CDPOS, der Workflow-Tabellen wie SWWLOGHIST sowie der Ausgleichstabellen BSAS und BSAK.
- Geparkte und gebuchte Belege extrahieren: Wählen Sie für Ereignisse vom Typ „Buchung geparkt“ die Einträge aus BKPF aus, bei denen der Belegstatus (BSTAT) „V“ ist. Wählen Sie für die Ereignisse „Buchung erstellt“ und „Buchung gebucht“ die Einträge aus BKPF aus, bei denen der Status leer ist. Das kennzeichnet einen normalen, gebuchten Beleg.
- Änderungs- und Löschereignisse extrahieren: Fragen Sie die Änderungsbelegtabellen CDHDR und CDPOS für die Objektklasse „BELEG“ ab. Filtern Sie nach dem Belegschlüssel, um Änderungen zu finden, die den Aktivitäten „Buchung korrigiert“ oder „Geparkte Buchung gelöscht“ entsprechen.
- Workflow-Ereignisse extrahieren: Fragen Sie die Workflow-Tabellen ab, um Aktivitäten wie „Buchung eingereicht“, „Genehmigt“, „Abgelehnt“ und „Änderungen angefordert“ zu erfassen. Verknüpfen Sie den Buchhaltungsbeleg über die Tabelle SWW_WI2OBJ mit einer Workflow-Instanz und lesen Sie anschließend in SWWLOGHIST die Entscheidungen der Benutzer oder Statusänderungen aus.
- Berechnete Ereignisse ermitteln: Prüfen Sie für „Manuelle Buchung erkannt“ den Transaktionscode (BKPF-TCODE) anhand einer Liste bekannter Transaktionscodes für manuelle Buchungen. Analysieren Sie für „Buchung über mehrere Buchungskreise erkannt“ die BSEG-Positionen eines Belegs, um festzustellen, ob mehrere Buchungskreise beteiligt sind.
- Daten zusammenführen und umwandeln: Überführen Sie die Daten jeder Aktivität nach der Auswahl in die endgültige Event-Log-Struktur. Verketten Sie Buchungskreis, Belegnummer und Geschäftsjahr zur JournalEntryId. Wandeln Sie SAP-Datums- und Zeitangaben in einen einzelnen EventTime-Timestamp um. Fügen Sie die Ergebnisse jeder Abfrage an die endgültige interne Tabelle an.
- Dateiexport implementieren: Verwenden Sie ABAP-Anweisungen zur Dateiverarbeitung, zum Beispiel OPEN DATASET, LOOP AT, TRANSFER und CLOSE DATASET, um die zusammengeführte interne Tabelle als CSV- oder Textdatei im Verzeichnis des SAP-Applikationsservers zu speichern. Die Datei lässt sich über die Transaktion AL11 anzeigen.
- Hintergrundjob einplanen: Öffnen Sie die Transaktion SM36 (Hintergrundjob definieren). Erstellen Sie einen Job, legen Sie einen Schritt zur Ausführung Ihres ABAP-Programms fest und planen Sie die Ausführung, zum Beispiel nachts oder wöchentlich außerhalb der Hauptgeschäftszeiten.
- Datei abrufen und formatieren: Verwenden Sie die Transaktion CG3Y oder wenden Sie sich an Ihre Systemadministration, um die erzeugte Datei vom Applikationsserver auf Ihren lokalen Rechner herunterzuladen. Achten Sie darauf, dass Codierung und Format für den Upload in Ihr Process-Mining-Tool geeignet sind.
Konfiguration
- Zeitraum: Legen Sie unbedingt einen Zeitraum fest, um die Systemleistung zu schützen. Verwenden Sie als primären Filter das Erstellungsdatum des Belegs (BKPF-CPUDT). Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten. Testen Sie die Abfrage mit einem Zeitraum von wenigen Tagen, für den Daten vorliegen.
- Filter für Buchungskreis: Filtern Sie immer nach Buchungskreis (BKPF-BUKRS). Der Export aller Buchungskreise auf einmal kann erhebliche Systemressourcen beanspruchen. Beginnen Sie mit einem oder wenigen relevanten Buchungskreisen.
- Filter für Belegart: Grenzen Sie den Umfang mit dem Filter für die Belegart (BKPF-BLART) auf bestimmte Buchungsarten ein, zum Beispiel „SA“ für Sachkontenbelege, wenn Sie nicht alle Belegarten analysieren müssen.
- Workflow-Aufgaben-IDs: Die Logik zum Export von Workflow-Ereignissen hängt von den in Ihrem System verwendeten Aufgaben-IDs für Genehmigung, Ablehnung und Einreichung ab. Tragen Sie diese IDs entsprechend den Workflow-Definitionen Ihres Unternehmens im Quellcode des Programms ein.
- Leistungsaspekte: Das Programm verknüpft mehrere große Tabellen, insbesondere CDPOS und die Workflow-Verlaufstabellen. Eine Ausführung während der Hauptgeschäftszeiten kann die Systemleistung beeinträchtigen. Planen Sie den Hintergrundjob daher außerhalb der Hauptgeschäftszeiten ein. Falls die Leistung wiederholt zum Problem wird, sollten Sie sekundäre Datenbankindizes anlegen.
- Voraussetzungen: Für diese Methode benötigen Sie einen Benutzer mit ABAP-Entwicklungsberechtigungen für SE38 sowie Berechtigungen zum Anlegen und Verwalten von Hintergrundjobs über SM36. Der Benutzer oder Job benötigt außerdem Lesezugriff auf alle relevanten Finanz-, Workflow- und Systemtabellen, darunter BKPF, BSEG, CDHDR, CDPOS und SWWLOGHIST.
a Beispielabfrage abap
REPORT Z_PM_JE_EXTRACTION.
*&---------------------------------------------------------------------*
*& Data Structures for Final Event Log
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
journalentryid TYPE string,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
username TYPE uname,
companycode TYPE bukrs,
documenttype TYPE blart,
postingdate TYPE budat,
transactioncode TYPE tcode,
isreversed TYPE abap_bool,
END OF ty_event_log.
DATA: lt_final_log TYPE STANDARD TABLE OF ty_event_log.
DATA: ls_event TYPE ty_event_log.
*&---------------------------------------------------------------------*
*& Selection Screen Parameters
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR bkpf-bukrs OBLIGATORY,
s_blart FOR bkpf-blart,
s_cpudt FOR bkpf-cpudt OBLIGATORY.
PARAMETERS: p_sysid TYPE sy-sysid DEFAULT sy-sysid.
*&---------------------------------------------------------------------*
*& Main Logic
*&---------------------------------------------------------------------*
START-OF-SELECTION.
DATA(lv_last_update) = cl_abap_context_info=>get_system_timestamp( ).
" 1. Journal Entry Parked
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
'Journal Entry Parked' AS activityname,
a~cpudt, a~cputm,
a~usnam AS username,
a~bukrs AS companycode,
a~blart AS documenttype,
a~bldat AS postingdate,
a~tcode AS transactioncode
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~bstat = 'V' " Parked Document
INTO TABLE @DATA(lt_parked).
IF sy-subrc = 0.
LOOP AT lt_parked ASSIGNING FIELD-SYMBOL(<fs_parked>).
ls_event-journalentryid = <fs_parked>-journalentryid.
ls_event-activityname = <fs_parked>-activityname.
CONVERT DATE <fs_parked>-cpudt TIME <fs_parked>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_parked>-username.
ls_event-companycode = <fs_parked>-companycode.
ls_event-documenttype = <fs_parked>-documenttype.
ls_event-postingdate = <fs_parked>-postingdate.
ls_event-transactioncode = <fs_parked>-transactioncode.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 2. Journal Entry Created (directly posted, not parked first)
" 9. Journal Entry Posted
" These two events happen at the same time for a direct posting.
SELECT CONCAT( bukrs, belnr, gjahr ) AS journalentryid,
cpudt, cputm, usnam, bukrs, blart, budat, tcode, stblg
FROM bkpf
WHERE bukrs IN s_bukrs
AND blart IN s_blart
AND cpudt IN s_cpudt
AND bstat = '' " Normal, posted document
INTO TABLE @DATA(lt_posted).
IF sy-subrc = 0.
LOOP AT lt_posted ASSIGNING FIELD-SYMBOL(<fs_posted>).
" Activity: Journal Entry Created
ls_event-journalentryid = <fs_posted>-journalentryid.
ls_event-activityname = 'Journal Entry Created'.
CONVERT DATE <fs_posted>-cpudt TIME <fs_posted>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-sourcesystem = p_sysid.
ls_event-lastdataupdate = lv_last_update.
ls_event-username = <fs_posted>-usnam.
ls_event-companycode = <fs_posted>-bukrs.
ls_event-documenttype = <fs_posted>-blart.
ls_event-postingdate = <fs_posted>-budat.
ls_event-transactioncode = <fs_posted>-tcode.
ls_event-isreversed = COND #( WHEN <fs_posted>-stblg IS NOT INITIAL THEN abap_true ELSE abap_false ).
APPEND ls_event TO lt_final_log.
" Activity: Journal Entry Posted
ls_event-activityname = 'Journal Entry Posted'.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 3. Documentation Attached (via GOS)
SELECT a~instid_a, c~cr_timestamp
FROM srgbtbrel AS a
INNER JOIN sood AS b ON a~instid_b = b~objid
INNER JOIN socf AS c ON b~filid = c~filid
WHERE a~typeid_a = 'BKPF'
AND a~bukrs IN s_bukrs
INTO TABLE @DATA(lt_attachments).
IF sy-subrc = 0.
LOOP AT lt_attachments ASSIGNING FIELD-SYMBOL(<fs_attach>).
ls_event-journalentryid = |{ <fs_attach>-instid_a(4) }{ <fs_attach>-instid_a+4(10) }{ <fs_attach>-instid_a+14(4) }|.
ls_event-activityname = 'Documentation Attached'.
ls_event-eventtime = <fs_attach>-cr_timestamp.
" Other attributes may need to be looked up from BKPF if needed.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 4, 5, 6, 7, 8: Workflow events (Submitted, Changes Requested, Corrected, Approved, Rejected)
" This is a simplified example. Real logic depends on specific workflow templates.
SELECT a~instid, b~wi_cd, b~wi_ct, b~wi_aagent, b~wi_text
FROM sww_wi2obj AS a
INNER JOIN swwloghist AS b ON a~wi_id = b~wi_id
WHERE a~typeid = 'BKPF'
AND a~catid = 'BO'
AND a~bukrs IN s_bukrs
AND b~wi_cd BETWEEN s_cpudt-low AND s_cpudt-high
INTO TABLE @DATA(lt_workflow).
IF sy-subrc = 0.
LOOP AT lt_workflow ASSIGNING FIELD-SYMBOL(<fs_wf>).
ls_event-journalentryid = |{ <fs_wf>-instid(4) }{ <fs_wf>-instid+4(10) }{ <fs_wf>-instid+14(4) }|.
ls_event-activityname = CASE <fs_wf>-wi_text. " Simplified logic based on work item text
WHEN '[Placeholder for Submit Text]' THEN 'Journal Entry Submitted'
WHEN '[Placeholder for Approve Text]' THEN 'Journal Entry Approved'
WHEN '[Placeholder for Reject Text]' THEN 'Journal Entry Rejected'
WHEN '[Placeholder for Rework Text]' THEN 'Journal Entry Changes Requested'
ELSE ''
ENDCASE.
IF ls_event-activityname IS NOT INITIAL.
CONVERT DATE <fs_wf>-wi_cd TIME <fs_wf>-wi_ct INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_wf>-wi_aagent.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
ENDIF.
" 10. Manual Entry Identified & 11. Cross-Company Posting Identified
SELECT bukrs, belnr, gjahr, tcode FROM bkpf
WHERE bukrs IN s_bukrs AND blart IN s_blart AND cpudt IN s_cpudt
INTO TABLE @DATA(lt_calc_base).
LOOP AT lt_calc_base ASSIGNING FIELD-SYMBOL(<fs_calc>).
ls_event-journalentryid = |{ <fs_calc>-bukrs }{ <fs_calc>-belnr }{ <fs_calc>-gjahr }|.
" Check for manual entry T-Codes
IF <fs_calc>-tcode = 'FB01' OR <fs_calc>-tcode = 'F-02' OR <fs_calc>-tcode = 'FB50'.
ls_event-activityname = 'Manual Entry Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
" Check for cross-company posting
SELECT SINGLE bukrs FROM bseg WHERE belnr = <fs_calc>-belnr AND gjahr = <fs_calc>-gjahr AND bukrs <> <fs_calc>-bukrs INTO @DATA(lv_cross_bukrs).
IF sy-subrc = 0.
ls_event-activityname = 'Cross-Company Posting Identified'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 12. Journal Entry Line Item Cleared
SELECT a~bukrs, a~belnr, a~gjahr, a~augdt, a~augbl
FROM bsas AS a " G/L Cleared Items
WHERE a~bukrs IN s_bukrs
AND a~budat IN s_cpudt
INTO TABLE @DATA(lt_cleared_gl).
IF sy-subrc = 0.
LOOP AT lt_cleared_gl ASSIGNING FIELD-SYMBOL(<fs_clr>).
ls_event-journalentryid = |{ <fs_clr>-bukrs }{ <fs_clr>-belnr }{ <fs_clr>-gjahr }|.
ls_event-activityname = 'Journal Entry Line Item Cleared'.
CONVERT DATE <fs_clr>-augdt INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
" User is often not directly available for clearing events
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" 13. Parked Journal Entry Deleted & 6. Journal Entry Corrected
SELECT objectid, changenr, username, udate, utime FROM cdhdr
WHERE objectclas = 'BELEG'
AND udate IN s_cpudt
INTO TABLE @DATA(lt_cdhdr).
LOOP AT lt_cdhdr ASSIGNING FIELD-SYMBOL(<fs_cdhdr>).
SELECT SINGLE tcode FROM cdpos WHERE changenr = <fs_cdhdr>-changenr AND fname = 'BSTAT' AND value_new = 'Z' INTO @DATA(lv_deleted_tcode).
ls_event-journalentryid = |{ <fs_cdhdr>-objectid(4) }{ <fs_cdhdr>-objectid+4(10) }{ <fs_cdhdr>-objectid+14(4) }|.
CONVERT DATE <fs_cdhdr>-udate TIME <fs_cdhdr>-utime INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_cdhdr>-username.
IF sy-subrc = 0.
ls_event-activityname = 'Parked Journal Entry Deleted'.
APPEND ls_event TO lt_final_log.
ELSE.
ls_event-activityname = 'Journal Entry Corrected'.
APPEND ls_event TO lt_final_log.
ENDIF.
ENDLOOP.
" 14. Journal Entry Reversal Processed
SELECT CONCAT( a~bukrs, a~belnr, a~gjahr ) AS journalentryid,
a~cpudt, a~cputm, a~usnam
FROM bkpf AS a
WHERE a~bukrs IN s_bukrs
AND a~blart IN s_blart
AND a~cpudt IN s_cpudt
AND a~stblg IS NOT NULL " Document is a reversal
INTO TABLE @DATA(lt_reversals).
IF sy-subrc = 0.
LOOP AT lt_reversals ASSIGNING FIELD-SYMBOL(<fs_rev>).
ls_event-journalentryid = <fs_rev>-journalentryid.
ls_event-activityname = 'Journal Entry Reversal Processed'.
CONVERT DATE <fs_rev>-cpudt TIME <fs_rev>-cputm INTO TIME STAMP ls_event-eventtime TIME ZONE sy-zonlo.
ls_event-username = <fs_rev>-usnam.
APPEND ls_event TO lt_final_log.
ENDLOOP.
ENDIF.
" Final step: Output to file
DATA(lv_filename) = |/tmp/je_extraction_{ sy-datum }_{ sy-uzeit }.csv|.
OPEN DATASET lv_filename FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc = 0.
" Write header
DATA(lv_header) = 'JournalEntryId,ActivityName,EventTime,SourceSystem,LastDataUpdate,User,CompanyCode,DocumentType,PostingDate,TransactionCode,IsReversed'.
TRANSFER lv_header TO lv_filename.
LOOP AT lt_final_log INTO ls_event.
DATA(lv_line) = |"{ ls_event-journalentryid }","|
|{ ls_event-activityname }","|
|{ ls_event-eventtime }","|
|{ ls_event-sourcesystem }","|
|{ ls_event-lastdataupdate }","|
|{ ls_event-username }","|
|{ ls_event-companycode }","|
|{ ls_event-documenttype }","|
|{ ls_event-postingdate }","|
|{ ls_event-transactioncode }","|
|{ ls_event-isreversed }"|.
TRANSFER lv_line TO lv_filename.
ENDLOOP.
CLOSE DATASET lv_filename.
ENDIF. Schritte
- Datenbankverbindung herstellen: Beschaffen Sie schreibgeschützte Zugangsdaten für die SAP-ECC-Datenbank. Stellen Sie mit einem gängigen SQL-Client wie DBeaver, SAP HANA Studio oder SQL Server Management Studio eine Verbindung zur Datenbank her.
- SQL-Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt „query“ dieses Dokuments in Ihren SQL-Client.
- Exportparameter festlegen: Ersetzen Sie vor der Ausführung die Platzhalter in der Abfrage. Tragen Sie für „[START_DATE]“ und „[END_DATE]“ den gewünschten Zeitraum im Format „YYYYMMDD“ ein. Ersetzen Sie „[COMPANY_CODE_1]“ und „[COMPANY_CODE_2]“ durch die SAP-Buchungskreise, die Sie analysieren möchten.
- Quellsystem festlegen: Ersetzen Sie in der Hauptanweisung
SELECTden Platzhalter „[Your SAP System ID]“ durch die tatsächliche SAP-System-ID (SID), damit die Datenquelle korrekt gekennzeichnet wird. - Abfrage ausführen: Führen Sie die konfigurierte SQL-Abfrage für die SAP-Datenbank aus. Die Ausführungszeit hängt vom gewählten Zeitraum und der Größe Ihrer Datenbanktabellen ab.
- Ergebnisse prüfen: Überfliegen Sie nach Abschluss der Abfrage die zurückgegebenen Zeilen, um sicherzustellen, dass die Daten wie erwartet vorliegen. Prüfen Sie, ob verschiedene Aktivitäten enthalten sind und wichtige Felder wie
JournalEntryIdundEventTimeausgefüllt sind. - Timestamps verarbeiten: Die Abfrage verkettet Datums- und Zeitfelder zu einer Zeichenfolge im Format
YYYYMMDDHHMMSS. Stellen Sie sicher, dass Ihre Nachverarbeitung oder Ihr Zielsystem dieses Format lesen kann. Unterstützt Ihre Datenbank es, können Sie die SQL-FunktionCONCATauch so anpassen, dass ein ISO-8601-Format wieYYYY-MM-DDTHH:MI:SSausgegeben wird. - Daten exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie UTF-8-Codierung, damit Sonderzeichen korrekt dargestellt werden.
- Upload vorbereiten: Prüfen Sie vor dem Upload in ein Process-Mining-Tool, ob die Spaltenüberschriften dem erforderlichen Datenschema entsprechen.
JournalEntryId,ActivityNameundEventTimesind unverzichtbar. Ergänzen Sie die SpalteLastDataUpdateund tragen Sie den Timestamp des Datenexports ein. - Abschließende Validierung: Führen Sie die im Abschnitt „validationSteps“ beschriebenen Schritte aus, um die Vollständigkeit und Korrektheit der exportierten Daten zu prüfen, bevor Sie mit der Analyse beginnen.
Konfiguration
- Datenbankberechtigungen: Der Datenbankbenutzer benötigt Lesezugriff auf die folgenden SAP-Tabellen: BKPF, BSEG, CDHDR, CDPOS, T001 und V_USERNAME. Für Workflow-Aktivitäten ist außerdem Zugriff auf SWW_WI2OBJ und SWWLOGHIST erforderlich. Diese Berechtigungen erhalten in der Regel nur spezialisierte technische Teams.
- Zeitraumfilter: Filtern Sie unbedingt nach einem bestimmten Zeitraum, damit die Abfrageleistung gewährleistet bleibt. Die bereitgestellte Abfrage verwendet Platzhalter für Start- und Enddatum, die auf das Erstellungsdatum des Belegs (
BKPF.CPUDT) angewendet werden. Für eine erste Analyse empfiehlt sich ein Zeitraum von 3 bis 6 Monaten. - Filter für Organisationseinheiten: Begrenzen Sie das Datenvolumen und den Analyseumfang, indem Sie immer nach Buchungskreis (
BKPF.BUKRS) filtern. Sie können zusätzlich nach Belegart (BKPF.BLART) filtern, um nur relevante Buchungsarten einzubeziehen, zum Beispiel „SA“ für Sachkontenbelege. So lassen sich nicht relevante operative Belege wie Rechnungen oder Zahlungen ausschließen. - Leistungsaspekte: Direkte Abfragen großer Kerntabellen wie BSEG und CDPOS können viele Ressourcen beanspruchen. Führen Sie den Export möglichst außerhalb der Hauptgeschäftszeiten aus, damit die Systemleistung für Endbenutzer nicht beeinträchtigt wird. Exportieren Sie nicht mehr als ein Jahr Daten in einem einzigen Durchlauf.
- Workflow-Aufgaben-IDs: Die Abfrage enthält Platzhalter wie „[WF_TASK_ID_SUBMIT]“ und „[WF_TASK_ID_APPROVE]“. Ersetzen Sie diese durch die tatsächlichen Aufgaben-IDs aus der Workflow-Konfiguration für Buchungen in Ihrem System. Ermitteln Sie die IDs gemeinsam mit einem SAP-Workflow-Spezialisten oder anhand der technischen Workflow-Definition in der Transaktion PFTC.
a Beispielabfrage sql
WITH DOC_HEADERS AS (
SELECT
BUKRS,
BELNR,
GJAHR,
BLART,
BLDAT,
BUDAT,
CPUDT,
CPUTM,
USNAM,
TCODE,
BSTAT,
STBLG,
XRECH
FROM BKPF
WHERE CPUDT BETWEEN '[START_DATE]' AND '[END_DATE]'
AND BUKRS IN ('[COMPANY_CODE_1]', '[COMPANY_CODE_2]')
)
-- Event 1: Journal Entry Created (Directly Posted)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Created' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = '' OR H.BSTAT = 'U'
UNION ALL
-- Event 2: Journal Entry Parked
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Parked' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.BSTAT = 'V'
UNION ALL
-- Event 3: Journal Entry Posted (from Parked state)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Posted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT <> 'V'
AND P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW <> 'V'
UNION ALL
-- Event 4: Parked Journal Entry Deleted
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Parked Journal Entry Deleted' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND C.TCODE = 'FBV0'
JOIN CDPOS P ON C.CHANGENR = P.CHANGENR AND P.OBJECTCLAS = 'BELEG' AND P.OBJECTID = C.OBJECTID
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE P.TABNAME = 'BKPF'
AND P.FNAME = 'BSTAT'
AND P.VALUE_OLD = 'V'
AND P.VALUE_NEW = 'Z'
UNION ALL
-- Event 5: Journal Entry Reversal Processed
SELECT
CONCAT(H.BUKRS, H.STBLG, H.GJAHR) AS "JournalEntryId", -- Linking to the original document
'Journal Entry Reversal Processed' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
TRUE AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.STBLG IS NOT NULL AND H.STBLG <> ''
UNION ALL
-- Event 6: Journal Entry Line Item Cleared
SELECT
CONCAT(B.BUKRS, B.BELNR, B.GJAHR) AS "JournalEntryId",
'Journal Entry Line Item Cleared' AS "ActivityName",
TO_TIMESTAMP(B.AUGDT, 'YYYYMMDD') AS "EventTime", -- Clearing date used as event time
U.NAME_TEXT AS "User",
B.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode", -- Clearing transaction is in the clearing document header, complex to retrieve here
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM BSEG B
JOIN DOC_HEADERS H ON B.BUKRS = H.BUKRS AND B.BELNR = H.BELNR AND B.GJAHR = H.GJAHR
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE B.AUGBL IS NOT NULL AND B.AUGBL <> '' AND B.AUGDT <> '00000000'
UNION ALL
-- Event 7: Journal Entry Corrected (changes to a parked document)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Journal Entry Corrected' AS "ActivityName",
TO_TIMESTAMP(CONCAT(C.UDATE, C.UTIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
C.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN CDHDR C ON C.OBJECTCLAS = 'BELEG' AND C.OBJECTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR)
LEFT JOIN V_USERNAME U ON C.USERNAME = U.BNAME
WHERE H.BSTAT = 'V' AND C.TCODE IN ('FBV2', 'FBV4') -- FBV2 is change parked doc, FBV4 is change parked doc header
UNION ALL
-- Event 8: Documentation Attached (inferred from GOS attachment creation, requires configuration)
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Documentation Attached' AS "ActivityName",
TO_TIMESTAMP(CONCAT(REL.RECDATE, '000000'), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SRGBTBREL REL ON REL.INSTID_A = CONCAT('BUS2081', H.BUKRS, H.BELNR, H.GJAHR) -- BUS2081 is object type for BKPF
LEFT JOIN V_USERNAME U ON REL.RECUNAM = U.BNAME
WHERE REL.TYPEID_A = 'BUS2081' AND REL.RELTYPE = 'ATTA'
UNION ALL
-- Events 9-13 from Workflow (Submitted, Changes Requested, Approved, Rejected) requires specific workflow config
-- This is a generic template. The WI_RH_TASK must be adapted to your system.
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
CASE
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_SUBMIT]' THEN 'Journal Entry Submitted'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_APPROVE]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Approved'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_REJECT]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Rejected'
WHEN LOG.WI_RH_TASK = '[WF_TASK_ID_CHANGES_REQ]' AND LOG.METHOD = 'DECISION' AND LOG.EVT_ID = 'COMPLETED' THEN 'Journal Entry Changes Requested'
ELSE NULL
END AS "ActivityName",
TO_TIMESTAMP(CONCAT(LOG.EVT_DATE, LOG.EVT_TIME), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
NULL AS "TransactionCode",
FALSE AS "IsReversed"
FROM DOC_HEADERS H
JOIN SWW_WI2OBJ WIOBJ ON WIOBJ.INSTID = CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AND WIOBJ.TYPEID = 'BKPF'
JOIN SWWLOGHIST LOG ON WIOBJ.WI_ID = LOG.WI_ID
LEFT JOIN V_USERNAME U ON LOG.EXEC_USER = U.BNAME
WHERE LOG.WI_RH_TASK IN ('[WF_TASK_ID_SUBMIT]', '[WF_TASK_ID_APPROVE]', '[WF_TASK_ID_REJECT]', '[WF_TASK_ID_CHANGES_REQ]')
UNION ALL
-- Event 14: Manual Entry Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Manual Entry Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.TCODE IN ('FB01', 'F-02', 'FB50', 'F-04', 'F-22', 'F-43', 'FB60', 'FB70', 'FV50', 'FV60', 'FV70')
UNION ALL
-- Event 15: Cross-Company Posting Identified
SELECT
CONCAT(H.BUKRS, H.BELNR, H.GJAHR) AS "JournalEntryId",
'Cross-Company Posting Identified' AS "ActivityName",
TO_TIMESTAMP(CONCAT(H.CPUDT, H.CPUTM), 'YYYYMMDDHH24MISS') AS "EventTime",
U.NAME_TEXT AS "User",
H.BUKRS AS "CompanyCode",
H.BLART AS "DocumentType",
H.BUDAT AS "PostingDate",
H.TCODE AS "TransactionCode",
CASE WHEN H.STBLG IS NOT NULL AND H.STBLG <> '' THEN TRUE ELSE FALSE END AS "IsReversed"
FROM DOC_HEADERS H
LEFT JOIN V_USERNAME U ON H.USNAM = U.BNAME
WHERE H.XRECH = 'X' Schritte
- SAP-Verbindung einrichten: Richten Sie in Ihrem ETL-Tool eines Drittanbieters eine neue Quellverbindung zu Ihrem SAP-ECC-System ein. Dafür benötigen Sie in der Regel die Angaben zum Anwendungsserver, Mandanten, zur Systemnummer sowie einen dedizierten SAP-Benutzer mit den erforderlichen RFC-Berechtigungen.
- Datenquellen festlegen: Fügen Sie Ihrem Extraktionsprojekt die benötigten SAP-Tabellen als Datenquellen hinzu. Dazu gehören vor allem BKPF (Belegkopf), BSEG (Belegsegment), VBSEGK (Kopf geparkter Belege), CDHDR (Änderungsbelegkopf), CDPOS (Änderungsbelegpositionen), SWW_WI2OBJ (Workflow-Objektverknüpfungen), SWWLOGHIST (Workflow-Protokoll) und SRGBTBREL (Beziehungen für GOS-Anhänge).
- Basisereignisse extrahieren (erstellt und geparkt): Erstellen Sie zunächst einen Datenfluss für die Extraktion der ersten Ereignisse. Verwenden Sie für „Journalbuchung geparkt“ VBSEGK als Quelle. Für „Journalbuchung erstellt“ verwenden Sie BKPF und filtern Belege heraus, bei denen es sich um Stornierungen handelt oder die ursprünglich geparkt wurden. Letzteres lässt sich durch einen Anti-Join mit VBSEGK erreichen.
- Workflow-Ereignisse extrahieren: Erstellen Sie einen Datenfluss, der BKPF über den Objektschlüssel (Buchungskreis + Belegnummer + Geschäftsjahr) mit SWW_WI2OBJ verknüpft, um die Workflow-Instanz-ID zu ermitteln. Verknüpfen Sie das Ergebnis mit SWWLOGHIST, um Ereignisse wie „Eingereicht“, „Genehmigt“, „Abgelehnt“ und „Änderungen angefordert“ anhand der Workflow-Aufgabenergebnisse und der im Protokoll erfassten Benutzerentscheidungen zu extrahieren.
- Änderungs- und Löschereignisse extrahieren: Ermitteln Sie Änderungen mithilfe der Tabellen CDHDR und CDPOS. Filtern Sie für „Journalbuchung korrigiert“ nach Änderungen an geparkten Belegen (Objektklasse „FIPP“). Suchen Sie für „Geparkte Journalbuchung gelöscht“ in den Änderungsprotokollen nach Löschmarkierungen für geparkte Belege.
- Anhangsereignisse extrahieren: Verknüpfen Sie für „Dokumentation angehängt“ BKPF mit SRGBTBREL. Verwenden Sie dabei den Objekttyp „BKPF“ und die Beziehung „[Your attachment relationship type]“. Das Erstellungsdatum der Verknüpfung dient als Ereigniszeitpunkt.
- Ausgleichs- und Stornierungsereignisse extrahieren: Fragen Sie für „Journalbuchungsposition ausgeglichen“ die Tabelle BSEG ab und filtern Sie nach einem gefüllten Ausgleichsbelegfeld (AUGBL). Als Ereigniszeitpunkt gilt das Buchungsdatum des Ausgleichsbelegs (AUGDT). Fragen Sie für „Stornierung der Journalbuchung verarbeitet“ BKPF nach Stornierungsbelegen ab. Diese erkennen Sie am Eintrag im Feld für den stornierten Beleg (STBLG).
- Berechnete Ereignisse ableiten: Erstellen Sie für berechnete Ereignisse separate Logikblöcke. Filtern Sie für „Manuelle Buchung erkannt“ BKPF anhand einer Liste manueller Transaktionscodes (z. B. FB01, FB50, F-02). Gruppieren Sie für „Buchungskreisübergreifende Buchung erkannt“ die Tabelle BSEG nach Beleg-ID und ermitteln Sie Belege mit mehr als einem unterschiedlichen Buchungskreis.
- Alle Ereignisflüsse zusammenführen: Führen Sie die Ergebnisse der einzelnen Ereignisflüsse (erstellt, geparkt, genehmigt usw.) mit einer UNION-Transformation in Ihrem ETL-Tool zu einer einzigen Event-Log-Tabelle zusammen. Achten Sie darauf, dass Spaltennamen und Datentypen in allen Flüssen übereinstimmen.
- Auf das Zielschema abbilden: Überführen Sie die zusammengeführten Daten in die erforderliche Event-Log-Struktur. Erstellen Sie dabei die Attribute
JournalEntryId,ActivityName,EventTime,Benutzersowie weitere erforderliche und empfohlene Attribute. Fügen Sie statische Spalten wieSourceSystemhinzu und verwenden Sie fürLastDataUpdateden Ausführungszeitpunkt des ETL-Auftrags. - Inkrementelles Laden einrichten: Richten Sie für laufende Extraktionen eine Strategie zum inkrementellen Laden ein. Verwenden Sie das letzte Erstellungs- oder Änderungsdatum (z. B. BKPF.CPUDT, CDHDR.UDATE) als Wasserzeichen, damit nur Datensätze abgerufen werden, die seit dem letzten Lauf neu hinzugekommen oder geändert worden sind.
- Für ProcessMind exportieren: Planen Sie den Extraktionsauftrag und konfigurieren Sie den letzten Ausgabeschritt so, dass das Event Log als CSV- oder Parquet-Datei an einem Speicherort abgelegt wird, auf den ProcessMind für den Upload zugreifen kann.
Konfiguration
- Voraussetzungen: Eine lizenzierte ETL-Lösung eines Drittanbieters (z. B. Theobald Xtract Universal, Informatica, Talend) mit einem dedizierten SAP-Konnektor. Außerdem benötigen Sie ein SAP-Benutzerkonto mit RFC-Zugriff und Berechtigungen zum Lesen von Finanzdaten (z. B. S_TABU_DIS für die Tabellengruppen F_00 und F_WF), Workflow-Daten und Änderungsprotokollen.
- Verbindungsparameter: Sie benötigen die IP-Adresse oder den Hostnamen des SAP-Anwendungsservers, die Systemnummer und die Mandanten-ID. Verwalten Sie den SAP-Benutzernamen und das Passwort sicher.
- Wichtige Filter: Filtern Sie die Daten bereits an der Quelle nach Buchungskreis (BKPF.BUKRS) und Geschäftsjahr (BKPF.GJAHR), um das Datenvolumen zu begrenzen. Wir empfehlen dringend, auch nach dem Belegerstellungsdatum (BKPF.CPUDT) zu filtern und so einen bestimmten Extraktionszeitraum festzulegen, zum Beispiel die letzten 6 Monate.
- Datumsbereich auswählen: Wählen Sie für den initialen Ladevorgang einen repräsentativen Zeitraum von 3 bis 6 Monaten. Verwenden Sie für nachfolgende Delta-Ladevorgänge ein Wasserzeichen auf einem Timestamp-Feld wie
CPUDT, um nur neue Datensätze abzurufen. - Leistung berücksichtigen: Verknüpfungen mit BSEG, CDPOS und Workflow-Tabellen können sehr langsam sein. Stellen Sie sicher, dass Ihr ETL-Tool Filter nach Möglichkeit an die SAP-Quelle weitergibt. Extrahieren Sie die Daten in kleineren Blöcken oder Paketen, sofern das Tool dies unterstützt. Das ist besonders bei großen historischen Datenbeständen wichtig.
- Workflow-Anpassungen: Welche Workflow-Aktivitäten wie „Genehmigt“ oder „Abgelehnt“ erkannt werden, hängt stark von Ihren konkreten Workflow-Templates ab. Ermitteln Sie in Ihrem System die passenden Workflow-Aufgaben-IDs und Benutzerentscheidungsschlüssel, um sie in den Filtern zu verwenden.
a Beispielabfrage sql
/*
This is a logical representation of the extraction configuration in a third-party ETL tool.
It is not executable SQL but defines the sources, joins, and transformations for each activity.
Placeholders like [Your SAP Source], [Date Filter], and [Company Code Filter] must be configured in the tool.
*/
-- Extraction block for 'Journal Entry Parked'
SELECT
CONCAT(v.BUKRS, v.VBELN, v.GJAHR) AS JournalEntryId,
'Journal Entry Parked' AS ActivityName,
CAST(CONCAT(v.CPUDT, v.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
v.USNAM AS User,
v.BUKRS AS CompanyCode,
v.BLART AS DocumentType,
v.BUDAT AS PostingDate,
v.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].VBSEGK v
WHERE [Date Filter on v.CPUDT] AND [Company Code Filter on v.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Created'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Created' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
LEFT JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE h.BSTAT = '' AND v.VBELN IS NULL AND h.STBLG IS NULL
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Posted' (from parked)
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Posted' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Or a more precise posting time from change logs if available
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
JOIN [Your SAP Source].VBSEGK v ON h.AWKEY = CONCAT(v.BUKRS, v.VBELN, v.GJAHR)
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Submitted', 'Approved', 'Rejected', 'Changes Requested'
SELECT
CONCAT(SUBSTRING(o.INSTID, 3, 4), SUBSTRING(o.INSTID, 7, 10), SUBSTRING(o.INSTID, 17, 4)) AS JournalEntryId,
CASE
WHEN wl.WI_TEXT LIKE '%Submit%' THEN 'Journal Entry Submitted'
WHEN wl.WI_TEXT LIKE '%Approve%' THEN 'Journal Entry Approved'
WHEN wl.WI_TEXT LIKE '%Reject%' THEN 'Journal Entry Rejected'
WHEN wl.WI_TEXT LIKE '%Request Changes%' THEN 'Journal Entry Changes Requested'
END AS ActivityName,
CAST(CONCAT(wl.WI_CD, wl.WI_CT) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
wl.EXEC_USER AS User,
SUBSTRING(o.INSTID, 3, 4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SWW_WI2OBJ o
JOIN [Your SAP Source].SWWLOGHIST wl ON o.WI_ID = wl.WI_ID
WHERE o.TYPEID = 'BKPF' AND o.CATID = 'BO'
AND wl.WI_TEXT IN ('[Your Submit Task Name]', '[Your Approve Task Name]', '[Your Reject Task Name]', '[Your Changes Request Task Name]')
AND [Date Filter on wl.WI_CD]
UNION ALL
-- Extraction block for 'Journal Entry Corrected'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Journal Entry Corrected' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'U'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Parked Journal Entry Deleted'
SELECT
CONCAT(cd.OBJECTID_LONG_CHAR(3,4), cd.OBJECTID_LONG_CHAR(7,10), cd.OBJECTID_LONG_CHAR(17,4)) AS JournalEntryId,
'Parked Journal Entry Deleted' AS ActivityName,
CAST(CONCAT(cd.UDATE, cd.UTIME) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
cd.USERNAME AS User,
cd.OBJECTID_LONG_CHAR(3,4) AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
cd.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].CDHDR cd
WHERE cd.OBJECTCLAS = 'FIPP' AND cd.CHANGE_IND = 'D'
AND [Date Filter on cd.UDATE]
UNION ALL
-- Extraction block for 'Documentation Attached'
SELECT
CONCAT(SUBSTRING(r.INSTID_A, 3, 4), SUBSTRING(r.INSTID_A, 7, 10), SUBSTRING(r.INSTID_A, 17, 4)) AS JournalEntryId,
'Documentation Attached' AS ActivityName,
-- Note: A precise timestamp is often unavailable. Using document creation time as a proxy.
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].SRGBTBREL r
JOIN [Your SAP Source].BKPF h ON h.BUKRS = SUBSTRING(r.INSTID_A, 3, 4) AND h.BELNR = SUBSTRING(r.INSTID_A, 7, 10) AND h.GJAHR = SUBSTRING(r.INSTID_A, 17, 4)
WHERE r.TYPEID_A = 'BKPF' AND r.RELTYPE = '[Configure based on your system]'
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Reversal Processed'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Journal Entry Reversal Processed' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.STBLG IS NOT NULL AND h.STBLG <> ''
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Is Reversed' flag on original document
SELECT
CONCAT(h_orig.BUKRS, h_orig.BELNR, h_orig.GJAHR) AS JournalEntryId,
'Is Reversed' AS ActivityName, -- This is an attribute update, modeled as an event
CAST(CONCAT(h_rev.CPUDT, h_rev.CPUTM) AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h_rev.USNAM AS User,
h_orig.BUKRS AS CompanyCode,
h_orig.BLART AS DocumentType,
h_orig.BUDAT AS PostingDate,
h_orig.TCODE AS TransactionCode,
TRUE AS IsReversed
FROM [Your SAP Source].BKPF h_rev
JOIN [Your SAP Source].BKPF h_orig ON h_rev.STBLG = h_orig.BELNR AND h_rev.BUKRS = h_orig.BUKRS AND h_rev.GJAHR_S = h_orig.GJAHR
WHERE h_rev.STBLG IS NOT NULL AND h_rev.STBLG <> ''
AND [Date Filter on h_rev.CPUDT] AND [Company Code Filter on h_rev.BUKRS]
UNION ALL
-- Extraction block for 'Journal Entry Line Item Cleared'
SELECT
CONCAT(i.BUKRS, i.BELNR, i.GJAHR) AS JournalEntryId,
'Journal Entry Line Item Cleared' AS ActivityName,
CAST(i.AUGDT AS TIMESTAMP) AS EventTime,
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
NULL AS User, -- User who performed clearing is on the clearing document header
i.BUKRS AS CompanyCode,
NULL AS DocumentType,
NULL AS PostingDate,
NULL AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BSEG i
WHERE i.AUGBL IS NOT NULL AND i.AUGBL <> ''
AND [Date Filter on i.AUGDT] AND [Company Code Filter on i.BUKRS]
UNION ALL
-- Extraction block for 'Manual Entry Identified'
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
'Manual Entry Identified' AS ActivityName,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed
FROM [Your SAP Source].BKPF h
WHERE h.TCODE IN ('FB01', 'F-02', 'FB50', 'FV50', '[Add other manual T-Codes]')
AND [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
UNION ALL
-- Extraction block for 'Cross-Company Posting Identified'
SELECT
JournalEntryId,
'Cross-Company Posting Identified' AS ActivityName,
EventTime, -- Same time as creation
'SAP ECC' AS SourceSystem,
NOW() AS LastDataUpdate,
User,
CompanyCode,
DocumentType,
PostingDate,
TransactionCode,
IsReversed
FROM (
SELECT
CONCAT(h.BUKRS, h.BELNR, h.GJAHR) AS JournalEntryId,
CAST(CONCAT(h.CPUDT, h.CPUTM) AS TIMESTAMP) AS EventTime,
h.USNAM AS User,
h.BUKRS AS CompanyCode,
h.BLART AS DocumentType,
h.BUDAT AS PostingDate,
h.TCODE AS TransactionCode,
FALSE AS IsReversed,
(SELECT COUNT(DISTINCT i.BUKRS) FROM [Your SAP Source].BSEG i WHERE i.BELNR = h.BELNR AND i.BUKRS = h.BUKRS AND i.GJAHR = h.GJAHR) as CompanyCodeCount
FROM [Your SAP Source].BKPF h
WHERE [Date Filter on h.CPUDT] AND [Company Code Filter on h.BUKRS]
) AS CrossCompanyCheck
WHERE CompanyCodeCount > 1 Möchten Sie loslegen?
Verwenden Sie dieses Daten-Template als Ausgangspunkt für Ihr Process Mining im Record-to-Report-Prozess für Buchungen. Gewinnen Sie detailliertere Erkenntnisse und steigern Sie die Effizienz Ihrer Finanzprozesse.
Optimieren Sie jetzt Ihren Record-to-Report-Prozess für Buchungen
Verkürzen Sie die Zykluszeit für Buchungen um 30 % und sorgen Sie für eine korrekte Berichterstattung.
Keine Kreditkarte erforderlich. Beginnen Sie noch heute mit der Optimierung.