> Kontinuierliche Prozessverbesserung > Record to Report Journal Entry > Oracle Fusion Financials > Daten Template

Ihr Datentemplate für Record to Report, Journalbuchung

Oracle Fusion Financials

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Record to Report, Journalbuchung (21) Aktivitäten für Record to Report, Journalbuchung (12) Anleitungen zur Datenextraktion (4)

Ihr Datentemplate für Record to Report, Journalbuchung

Dieses Datentemplate erläutert, wie Sie Ihre Journalbuchungsdaten aus Oracle Fusion Financials extrahieren und strukturieren. Es beschreibt die erforderlichen Attribute und wichtigen Aktivitäten, die Sie erfassen sollten, damit alle nötigen Informationen für eine aussagekräftige Prozessanalyse vorliegen. Außerdem finden Sie praktische Hinweise zum direkten Datenexport aus Ihrem System.

Empfohlene Attribute für die Datenerfassung
Wichtige Aktivitäten für die Analyse
Anleitung zur Datenextraktion aus Oracle Fusion Financials

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute für Record to Report, Journalbuchung

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren Record-to-Report-Prozess für Journalbuchungen umfassend zu analysieren.

5 Erforderlich 6 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivität ActivityName	Die Bezeichnung des konkreten Geschäftsereignisses oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Journaleintragsprozess stattgefunden hat.
Beschreibung Der Aktivitätsname beschreibt einen einzelnen Schritt im Lebenszyklus eines Journaleintrags, etwa „Journaleintrag erstellt“ oder „Journaleintrag genehmigt“. Diese Daten sind entscheidend, um die Prozesslandkarte zu erstellen und die Abfolge der Ereignisse nachzuvollziehen. Durch die Analyse der Aktivitäten lassen sich der Prozessablauf, einschließlich Standardpfaden, Abweichungen und Nacharbeitsschleifen, erkennen. Die Erfassung verschiedener Aktivitäten zeigt, wie viel Zeit einzelne Phasen wie die Genehmigung in Anspruch nehmen und welche Schritte besonders zeitaufwendig oder fehleranfällig sind. Warum das wichtig ist Das Attribut legt die Prozessschritte fest. Es bildet die Grundlage der Prozesslandkarte und ermöglicht die Analyse des Ablaufs, von Engpässen und Abweichungen. Woher beziehen Dieses Attribut wird üblicherweise aus Statusänderungen, Event Logs oder Audit-Trail-Tabellen zu Journaleintragsobjekten im Hauptbuch abgeleitet. Beispiele Journalbuchung erstelltJournalbuchung zur Genehmigung eingereichtJournaleintrag genehmigtJournaleintrag gebucht
	Journal Entry ID JournalEntryId	Der eindeutige Bezeichner eines einzelnen Journaleintrags, der alle zugehörigen Finanztransaktionen miteinander verknüpft.
Beschreibung Die Journal Entry ID dient als primärer Case-Bezeichner und verknüpft eindeutig alle Aktivitäten zu einer bestimmten Gruppe von Finanztransaktionen. So lässt sich der gesamte Lebenszyklus eines einzelnen Journaleintrags von der Initiierung bis zur endgültigen Buchung verfolgen und sicherstellen, dass Soll und Haben vollständig erfasst sind. Im Process Mining ist diese ID entscheidend, um den durchgängigen Ablauf jedes Journaleintrags zu rekonstruieren. Sie verknüpft einzelne Ereignisse wie „Journaleintrag erstellt“, „Journal zur Genehmigung eingereicht“ und „Journaleintrag gebucht“ zu einem zusammenhängenden Prozessablauf. Dadurch lassen sich Zykluszeiten, Engpässe und Prozessabweichungen analysieren. Warum das wichtig ist Dieser zentrale Schlüssel ermöglicht es, einen Journaleintrag von Anfang bis Ende zu verfolgen und den gesamten Prozessablauf für jeden einzelnen Case zu analysieren. Woher beziehen Dieser Primärschlüssel ist in zentralen Hauptbuchtabellen wie GL_JE_HEADERS und GL_JE_LINES enthalten. Beispiele JE100523JE202311001882019
	Startzeit EventTime	Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Dieser Timestamp gibt das genaue Datum und die Uhrzeit an, zu der eine Aktivität ausgeführt wurde. Im Process Mining dient er als zentrale Zeitangabe, um die Abfolge der Ereignisse zu bestimmen und Zeitspannen zwischen ihnen zu berechnen. Die Genauigkeit der Ereigniszeit ist für alle zeitbasierten Analysen entscheidend. Dazu gehören die Berechnung von Zykluszeiten, das Erkennen von Engpässen und die Überwachung der Leistung anhand von Service Level Agreements. Der Timestamp liefert die chronologische Reihenfolge, die benötigt wird, um den tatsächlichen Prozessablauf zu rekonstruieren. Warum das wichtig ist Dieser Timestamp ist entscheidend, um Ereignisse zu ordnen, Prozessdauern zu berechnen und zeitbasierte Analysen durchzuführen. Woher beziehen Diese Information wird üblicherweise in Audit-Trail-Tabellen gespeichert oder bei bestimmten Ereignissen als „Last Update Date“ oder „Creation Date“ in Transaktionstabellen wie GL_JE_HEADERS und GL_JE_LINES erfasst. Beispiele 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der letzten Aktualisierung oder Extraktion der Daten aus dem Quellsystem.
Beschreibung Dieses Attribut erfasst, wann der Datensatz zuletzt aktualisiert wurde. Es gibt Aufschluss über die Aktualität der analysierten Daten und hilft dabei, die Relevanz der daraus gewonnenen Erkenntnisse einzuschätzen. Bei jeder Analyse, insbesondere in operativen Dashboards, ist der Zeitpunkt der letzten Datenaktualisierung entscheidend, damit Benutzer den Daten vertrauen und fundierte Entscheidungen treffen können. Er zeigt klar, bis zu welchem Zeitpunkt Daten in das Process-Mining-Modell eingeflossen sind. Warum das wichtig ist Gibt an, wie aktuell die Daten sind. So können Benutzer einschätzen, wie aktuell die Prozessanalyse ist, und den Erkenntnissen vertrauen. Woher beziehen Dieser Wert wird während der Datenextraktion und -transformation erzeugt und gespeichert. In der Regel entspricht er dem Timestamp, zu dem der ETL-/ELT-Auftrag abgeschlossen wurde. Beispiele 2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
	Quellsystem SourceSystem	Das System oder Modul, aus dem die Daten stammen.
Beschreibung Dieses Attribut gibt an, aus welchem Quellsystem die Prozessdaten extrahiert wurden. In einer komplexen IT-Landschaft können die Daten aus mehreren integrierten Systemen stammen. Dieses Feld hilft, sie voneinander zu unterscheiden. Bei der Prozessanalyse ist das Quellsystem wichtig, um Prozessabweichungen zu verstehen, die durch unterschiedliches Systemverhalten entstehen können. Außerdem unterstützt es die Datenvalidierung und Fehlerbehebung, da sich die Daten bis zu ihrem Ursprung zurückverfolgen lassen. Warum das wichtig ist Gibt die Herkunft der Daten an. Das ist wichtig für Data Governance, die Validierung und das Verständnis von Prozessabweichungen zwischen verschiedenen Systemen. Woher beziehen Häufig handelt es sich um einen statischen Wert, der bei der Datenextraktion festgelegt wird. Alternativ kann es ein Feld in den Quelltabellen sein, das das Erfassungssystem angibt. Beispiele Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Ablehnungsgrund RejectionReason	Eine Beschreibung oder ein Code, der erklärt, warum ein Journaleintrag abgelehnt wurde.
Beschreibung Wird ein Journaleintrag während des Genehmigungsprozesses abgelehnt, erfasst dieses Attribut den Ablehnungsgrund. Dabei kann es sich um einen vordefinierten Code oder einen Freitextkommentar des Genehmigers handeln. Dieses Attribut ist besonders wichtig, um die Ursachen von Ineffizienzen im Prozess zu analysieren. Anhand der häufigsten Ablehnungsgründe können Organisationen Verbesserungsmöglichkeiten erkennen, etwa bei der Schulung der Ersteller, der Verständlichkeit von Richtlinien oder den Systemkontrollen. Das Attribut unterstützt direkt das Dashboard „Analyse der Ablehnungsquote von Journaleinträgen“. Warum das wichtig ist Zeigt direkt die Ursachen von Nacharbeit und Prozessverzögerungen auf und ermöglicht gezielte Verbesserungen zur Senkung der Ablehnungsquote. Woher beziehen Diese Information kann in Workflow- oder Audit-Trail-Tabellen zum Genehmigungsprozess oder in einem Notizfeld der Journal-Kopfzeile gespeichert sein. Beispiele Ungültige KontenkombinationUnzureichende BelegdokumentationBudget überschritten
	Abteilung des Benutzers UserDepartment	Die Abteilung oder das Team, dem der Benutzer angehört, der die Aktivität ausgeführt hat.
Beschreibung Dieses Attribut ordnet eine Aktivität einer bestimmten Abteilung zu, etwa „Finanzen“, „Buchhaltung“ oder „Interne Revision“, und liefert so den organisatorischen Kontext. In der Regel wird es aus den Benutzerdaten abgeleitet. Die Analyse nach Abteilung des Benutzers hilft, abteilungsübergreifende Engpässe zu erkennen, die Leistung von Teams zu vergleichen und Unterschiede bei der Prozessausführung in der Organisation zu verstehen. Sie unterstützt die Ressourcenplanung und gezielte Prozessverbesserungen. Warum das wichtig ist Liefert den organisatorischen Kontext für Leistungsvergleiche nach Team oder Abteilung und macht Ineffizienzen an Schnittstellen sichtbar. Woher beziehen Diese Information ist üblicherweise nicht in den Transaktionstabellen enthalten. Sie muss über den UserName mit einer Benutzerdatentabelle oder den Daten eines HR-Systems verknüpft werden. Beispiele FinanzbuchhaltungFinanzberichterstattungKreditorenbuchhaltung
	Benutzer UserName	Der Benutzer, der die Aktivität ausgeführt hat, etwa beim Erstellen, Genehmigen oder Buchen des Journaleintrags.
Beschreibung Dieses Attribut gibt an, welcher Mitarbeitende oder Systembenutzer für die Ausführung einer Aktivität verantwortlich war. Es ist wichtig, um die Arbeitslastverteilung und Leistung zu verstehen und individuelle Engpässe zu erkennen. Mit UserName lassen sich Prozesse nach Benutzern filtern, deren Effizienz vergleichen und Ursachen für Verzögerungen oder Fehler untersuchen. Das Attribut unterstützt direkt Dashboards wie „Arbeitslast und Effizienz der Benutzer in den Teams“ sowie KPIs wie den „Engpassindex für Journaleinträge je Benutzer“. Warum das wichtig ist Ordnet Prozessschritte den Verantwortlichen zu und ermöglicht so die Analyse der Arbeitslast, der individuellen Leistung und des Schulungsbedarfs. Woher beziehen Zu finden in Transaktionstabellen wie GL_JE_HEADERS (z. B. CREATED_BY, LAST_UPDATED_BY) und in zugehörigen Audit-Trail-Tabellen. Beispiele john.doesusan.smithautoprocess_user
	Betrag des Journaleintrags JournalAmount	Der Gesamtbetrag des Journaleintrags, üblicherweise die Summe der Sollbuchungen.
Beschreibung Dieses Attribut gibt den Gesamtwert der im Journaleintrag erfassten Finanztransaktion an. Der Betrag kann den Prozess maßgeblich beeinflussen. Für hohe Beträge können beispielsweise zusätzliche Genehmigungsschritte oder gründlichere Prüfungen erforderlich sein. Die Analyse des Betrags ermöglicht es, Cases nach finanzieller Auswirkung zu segmentieren. Sie hilft bei Fragen wie: „Dauert die Genehmigung hoher Beträge länger?“ oder „Werden Einträge oberhalb eines bestimmten Schwellenwerts häufiger abgelehnt?“ So erhält der Prozessablauf den nötigen Geschäftskontext. Warum das wichtig ist Liefert wichtigen Geschäftskontext für Analysen nach finanzieller Auswirkung und hilft zu erkennen, ob Einträge mit hohen Beträgen einem anderen Prozess folgen. Woher beziehen Dieser Wert wird üblicherweise als Summe der Soll- oder Habenbuchungen in der Tabelle GL_JE_LINES für einen bestimmten Journaleintrag berechnet. Beispiele 5000.00125000.75750.50
	Journal-Kategorie JournalCategory	Die Kategorie des Journaleintrags, etwa „Rückstellung“, „Korrektur“ oder „Umbuchung“.
Beschreibung Die Journal-Kategorie ordnet Einträge nach ihrem Geschäftszweck ein. Dadurch lässt sich der Prozess detaillierter analysieren, denn je nach Kategorie können sich Prozessabläufe, Genehmigungsregeln und Zykluszeiten unterscheiden. Monatsabschlussbuchungen können beispielsweise komplexer und dringlicher sein als routinemäßige Rückstellungen. Die Analyse nach Kategorie macht solche Abweichungen sichtbar und hilft, Verbesserungen auf bestimmte Arten von Journaleinträgen auszurichten. Warum das wichtig ist Ermöglicht die Segmentierung des Prozesses nach Geschäftszweck des Journaleintrags und zeigt Unterschiede im Ablauf und in der Leistung zwischen den Eintragsarten. Woher beziehen In der Tabelle GL_JE_HEADERS verfügbar, üblicherweise im Feld JE_CATEGORY. Beispiele RückstellungManuellKorrekturNeubewertung
	Journalquelle JournalSource	Das Nebenbuch oder die Quelle, aus der der Journaleintrag stammt, etwa „Kreditoren“, „Debitoren“ oder „Manuell“.
Beschreibung Dieses Attribut gibt an, woher der Journaleintrag im ERP-System stammt. Einträge können manuell im Hauptbuch erstellt oder automatisch aus Nebenbüchern wie Kreditorenbuchhaltung, Debitorenbuchhaltung oder Anlagenbuchhaltung übernommen werden. Die Journalquelle ist ein wichtiges Attribut für die Automatisierungsanalyse. Sie unterscheidet manuelle von systemgenerierten Einträgen und unterstützt die KPI „Automatisierungsquote bei Journaleinträgen“. Die Prozesse für Einträge aus verschiedenen Quellen unterscheiden sich häufig deutlich in Komplexität und Effizienz. Warum das wichtig ist Unterscheidet manuelle von automatisierten Einträgen. Das ist entscheidend, um Automatisierungsquoten zu messen und Prozessunterschiede zu analysieren. Woher beziehen In der Tabelle GL_JE_HEADERS verfügbar, üblicherweise im Feld JE_SOURCE. Beispiele ManuellKreditorenbuchhaltungAnlagenDebitorenbuchhaltung
	Buchungsperiode AccountingPeriod	Die Geschäftsjahresperiode, in der der Journaleintrag gebucht wird, etwa „Jan-24“.
Beschreibung Die Buchungsperiode gibt an, in welcher Finanzperiode die Transaktion erfasst wird. Sie ist eine grundlegende Angabe für die Finanzberichterstattung und -analyse. Im Process Mining ist dieses Attribut für die Trendanalyse wichtig. Es ermöglicht den Vergleich der Prozessleistung, etwa von Zykluszeiten oder Ablehnungsquoten, über verschiedene Monate oder Quartale hinweg. So lassen sich saisonale Effekte wie eine höhere Arbeitslast zum Monatsabschluss erkennen und die Wirkung von Prozessverbesserungen im Zeitverlauf messen. Warum das wichtig ist Ermöglicht die Trendanalyse von KPIs im Zeitverlauf. So lassen sich Prozessverbesserungen messen und saisonale Muster wie die Belastung zum Monatsabschluss erkennen. Woher beziehen In der Tabelle GL_JE_HEADERS verfügbar, üblicherweise im Feld PERIOD_NAME. Beispiele Jan-24Feb-24Mär-24
	Buchungsstatus PostingStatus	Der aktuelle Buchungsstatus des Journaleintrags, zum Beispiel „Nicht gebucht“ oder „Gebucht“.
Beschreibung Dieses Attribut zeigt den aktuellen Buchungsstatus des Journaleintrags im Hauptbuch. Es gibt an, an welcher Stelle im Lebenszyklus sich ein Journaleintrag befindet, insbesondere bei laufenden Cases. Der Buchungsstatus ist entscheidend für das Dashboard „Echtzeit-Statusübersicht für Journaleinträge“, das einen Überblick über alle aktiven Einträge bietet. Damit lassen sich Rückstände nicht gebuchter Journaleinträge überwachen und Verzögerungen in den letzten Prozessphasen erkennen. Warum das wichtig ist Zeigt den aktuellen Status eines Journaleintrags an. Das ist wichtig, um Rückstände zu überwachen und den Fortschritt laufender Einträge nachzuverfolgen. Woher beziehen In der Tabelle GL_JE_HEADERS verfügbar, üblicherweise in einer Spalte wie STATUS oder POSTING_STATUS. Beispiele GebuchtNicht gebuchtFehler
	Durchgängige Zykluszeit EndToEndCycleTime	Die berechnete Gesamtdauer von der Erstellung eines Journaleintrags bis zu seiner abschließenden Abstimmung.
Beschreibung Diese Kennzahl gibt an, wie viel Zeit ein Journaleintrag im gesamten Prozess verbringt, vom ersten Ereignis „Journaleintrag erstellt“ bis zum abschließenden Ereignis „Journaleintrag abgestimmt“. Sie bietet einen umfassenden Überblick über die Prozessleistung. Die Kennzahl ist eine zentrale KPI zur Messung der Gesamteffizienz des Prozesses. In Trend-Dashboards zeigt sie die Wirkung von Verbesserungsmaßnahmen im Zeitverlauf und dient als Ausgangswert, mit dem sich Prozessänderungen vergleichen lassen. Warum das wichtig ist Liefert einen übergreifenden Messwert für Zustand und Effizienz des gesamten Prozesses und ist damit eine wichtige Kennzahl für die Berichterstattung an die Geschäftsleitung. Woher beziehen Die Process-Mining-Plattform berechnet diese Kennzahl als Zeitdifferenz zwischen dem Timestamp des ersten und des letzten Ereignisses für jeden Case. Beispiele P10DT5HP4DT12HP22D
	Endzeit EndTime	Der Timestamp, der angibt, wann eine bestimmte Aktivität abgeschlossen wurde.
Beschreibung Die Endzeit markiert den Abschluss einer Aktivität. Während die Startzeit den Beginn erfasst, gibt die Endzeit den Abschlusszeitpunkt an. So lässt sich die Verarbeitungszeit des jeweiligen Schritts genau berechnen. Diese Angabe ist entscheidend, um die Verarbeitungszeiten von Aktivitäten zu berechnen. Sie ist eine zentrale Kennzahl, um Engpässe zu erkennen und die Ressourceneffizienz zu messen. Die Differenz zwischen Endzeit und Startzeit der Aktivität „Journaleintrag geprüft“ zeigt beispielsweise, wie viel Zeit die prüfende Person tatsächlich für die Aufgabe aufgewendet hat. Warum das wichtig ist Damit lässt sich die tatsächliche Dauer beziehungsweise Verarbeitungszeit einzelner Aktivitäten berechnen. Das ist entscheidend, um Effizienzprobleme zu erkennen. Woher beziehen Wie die Startzeit ist auch dieser Wert häufig in Audit-Trail-Tabellen zu finden. Alternativ lässt er sich aus der Startzeit der nachfolgenden Aktivität im Prozess ableiten. Beispiele 2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
	Fristgerecht gebucht IsOnTimePosting	Ein berechnetes Kennzeichen, das angibt, ob der Journaleintrag am oder vor dem Zieltermin gebucht wurde.
Beschreibung Dieses boolesche Attribut wird berechnet, indem der Timestamp der Aktivität „Journaleintrag gebucht“ mit dem geplanten Buchungstermin verglichen wird. Erfolgt die Buchung am oder vor dem Zieltermin, lautet der Wert „true“, andernfalls „false“. Das Attribut unterstützt direkt die KPI „Fristgerechte Buchungsquote von Journaleinträgen“ und vereinfacht deren Berechnung. Verspätete Einträge lassen sich einfach filtern und analysieren, um häufige Verzögerungsursachen zu erkennen, etwa bestimmte Journal-Kategorien oder Genehmiger. Warum das wichtig ist Liefert ein eindeutiges Ergebnis zur Buchungsleistung und vereinfacht die Analyse der fristgerechten Buchungen und der Ursachen für Verzögerungen. Woher beziehen Dieses Attribut wird vom Process-Mining-Tool berechnet. Dafür sind das Attribut „TargetPostingDate“ und der Timestamp der Aktivität „Journaleintrag gebucht“ erforderlich. Beispiele truefalse
	Geplanter Buchungstermin TargetPostingDate	Das festgelegte Datum, bis zu dem der Journaleintrag voraussichtlich gebucht werden soll.
Beschreibung Der geplante Buchungstermin ist die Frist für die Buchung eines Journaleintrags im Hauptbuch. Er wird häufig durch Service Level Agreements (SLAs) oder Zeitpläne für den Monatsabschluss festgelegt und dient als Maßstab für die Leistung. Dieses Attribut ist erforderlich, um die KPI „Fristgerechte Buchungsquote von Journaleinträgen“ zu berechnen. Durch den Vergleich des tatsächlichen Buchungsdatums mit dem Zieltermin kann das System Einträge automatisch als fristgerecht oder verspätet kennzeichnen. So lässt sich die Einhaltung der Zeitpläne klar messen. Warum das wichtig ist Legt das Service Level Agreement oder die Buchungsfrist fest und ermöglicht so die Berechnung von KPIs zur fristgerechten Leistung. Woher beziehen Möglicherweise gibt es dafür kein Standardfeld. Der Wert kann anhand von Geschäftsregeln aus dem Erstellungsdatum, der Buchungsperiode oder der Journal-Kategorie abgeleitet werden. Beispiele 2023-10-312023-11-302024-01-05
	Hauptbuchname LedgerName	Der Name des Hauptbuchs, in dem der Journaleintrag erfasst wird.
Beschreibung Der Hauptbuchname gibt an, zu welchem Hauptbuch der Journaleintrag gehört. In Organisationen mit mehreren Rechtseinheiten oder Berichtsanforderungen kann es mehrere Hauptbücher geben, etwa ein primäres Hauptbuch für die Konzernbuchhaltung und sekundäre Hauptbücher für die lokale gesetzliche Berichterstattung. Dieses Attribut ist wichtig, um Prozesse verschiedener Rechtseinheiten oder Geschäftseinheiten zu filtern und zu vergleichen. Es stellt sicher, dass Analysen im richtigen organisatorischen Kontext erfolgen, was besonders für die Compliance und Finanzberichterstattung wichtig ist. Warum das wichtig ist Ermöglicht es, Prozessanalysen nach Rechtseinheit oder Rechnungslegungsrahmen zu filtern und zu vergleichen. Das ist für große Organisationen besonders wichtig. Woher beziehen Zu finden in der Tabelle GL_JE_HEADERS, üblicherweise über LEDGER_ID verknüpft, das sich mit GL_LEDGERS verbinden lässt, um den Namen abzurufen. Beispiele Primäres US-HauptbuchGesetzliches Hauptbuch für GroßbritannienGlobales Konsolidierungshauptbuch
	Nacharbeit erfolgt IsRework	Ein berechnetes Kennzeichen, das angibt, ob der Journaleintrag einen Ablehnungs- und Korrekturzyklus durchlaufen hat.
Beschreibung Dieses boolesche Attribut wird berechnet, um Cases mit Nacharbeit zu kennzeichnen. Es wird üblicherweise für alle Aktivitäten auf „true“ gesetzt, die auf ein Ereignis „Journaleintrag abgelehnt“ folgen, etwa „Journaleintrag korrigiert und erneut eingereicht“. Das Attribut „Nacharbeit erfolgt“ erleichtert die Analyse, da sich Umfang und Auswirkungen von Nacharbeitsschleifen damit einfach quantifizieren lassen. Es unterstützt direkt die KPI „Durchschnittliche Nacharbeitsquote bei Journaleinträgen“ und hilft, Ablauf und Dauer nachbearbeiteter Cases mit korrekt im ersten Durchlauf verarbeiteten Cases zu vergleichen. Warum das wichtig ist Kennzeichnet direkt Cases mit ineffizienten Nacharbeitsschleifen und erleichtert so die Messung der Häufigkeit und Auswirkungen von Prozessfehlern. Woher beziehen Dieses Attribut ist im Quellsystem nicht verfügbar. Es wird im Process-Mining-Tool berechnet, indem die Abfolge der Aktivitäten für jeden Case analysiert wird. Beispiele truefalse
	Stornierungskennzeichen ReversalIndicator	Ein Kennzeichen, das angibt, ob der Journaleintrag eine Stornierung eines anderen Eintrags ist.
Beschreibung Dieses boolesche Attribut kennzeichnet Journaleinträge, die erstellt wurden, um einen zuvor gebuchten Eintrag zu stornieren. Stornierungen sind eine besondere Art von Journaleinträgen, die häufig einem eigenen und mitunter problematischen Prozess folgen. Die Analyse dieses Kennzeichens ist wichtig für das Dashboard „Leistung des Stornierungsprozesses für Journaleinträge“. Damit lassen sich Stornierungsprozesse isoliert betrachten und ihre Häufigkeit, Ursachen und Zykluszeiten messen. So können zugrunde liegende Probleme in den ursprünglichen Einträgen erkannt werden, die eine Stornierung erforderlich machen. Warum das wichtig ist Ermöglicht die gezielte Analyse des Stornierungsprozesses, der häufig auf Fehler oder Probleme in der ursprünglichen Transaktion hindeutet. Woher beziehen Hierfür kann ein eigenes Kennzeichen in GL_JE_HEADERS verwendet werden, etwa ACCRUAL_REV_FLAG. Alternativ lässt sich das Kennzeichen anhand der Verknüpfung mit dem stornierten ursprünglichen Journaleintrag ermitteln. Beispiele truefalse
	Währung CurrencyCode	Der Währungscode des Journaleintrags, etwa USD, EUR oder GBP.
Beschreibung Der Währungscode gibt an, in welcher Währung die Beträge des Journaleintrags angegeben sind. Das ist für international tätige Organisationen mit Transaktionen in mehreren Währungen unerlässlich. Dieses Attribut stellt sicher, dass Finanzwerte korrekt interpretiert werden. Es ermöglicht das Filtern nach Währung und ist erforderlich, wenn Geldbeträge aus verschiedenen Regionen verglichen oder zusammengefasst werden. Warum das wichtig ist Liefert den nötigen Kontext für Finanzbeträge, stellt ihre korrekte Interpretation sicher und ermöglicht Analysen nach Währung. Woher beziehen In der Tabelle GL_JE_HEADERS verfügbar, üblicherweise im Feld CURRENCY_CODE. Beispiele USDEURGBPJPY

Erforderlich Empfohlen Optional

Aktivitäten für Record to Report, Journalbuchung

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um Journalbuchungen präzise zu analysieren.

5 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Journalbuchung erstellt	Diese Aktivität markiert den Beginn des Prozesses für Journalbuchungen. Sie bezeichnet den Zeitpunkt, an dem ein Benutzer einen neuen Buchungskopf erstellt und mit der Dateneingabe beginnt, bevor die Buchung zur Prüfung oder Genehmigung eingereicht wird.
Warum das wichtig ist Dies ist das primäre Start-Event des Prozesses. Die Zeit von dieser Aktivität bis zu den folgenden Schritten zeigt, wie effizient die anfängliche Dateneingabe ist und wie lange der Prozess insgesamt dauert. Woher beziehen Dieses Event wird üblicherweise anhand des Erstellungsdatums in der Tabelle GL_JE_HEADERS für eine bestimmte Journal Entry ID ermittelt. Auch der Benutzer, der den Datensatz erstellt hat, ist in dieser Tabelle vermerkt. Erfassung Verwenden Sie CREATION_DATE aus der Tabelle GL_JE_HEADERS. Ereignistyp inferred
	Journalbuchung zur Genehmigung eingereicht	Diese Aktivität tritt ein, wenn der Benutzer die fertiggestellte Journalbuchung offiziell in den Genehmigungsworkflow einreicht. Damit wechselt die Buchung vom Entwurf oder einem unvollständigen Status in den Status „Genehmigung ausstehend“.
Warum das wichtig ist Dieser wichtige Meilenstein markiert den Beginn der Messung von Genehmigungszeiten und der Erkennung von Engpässen. Er trennt die Dateneingabe von der Prüfungs- und Genehmigungsphase. Woher beziehen Dieses Event wird anhand einer Statusänderung in der Tabelle GL_JE_HEADERS ermittelt, insbesondere wenn APPROVAL_STATUS_CODE auf einen Wert wie 'REQUIRED' oder 'INITIATED' wechselt. Möglicherweise ist auch der Timestamp der Einreichung gespeichert. Erfassung Erfassen Sie den Timestamp, an dem sich APPROVAL_STATUS_CODE in GL_JE_HEADERS ändert und die Einreichung anzeigt. Ereignistyp inferred
	Journaleintrag abgestimmt	Der Journaleintrag wurde im Rahmen der Kontenabstimmung zum Periodenende abgeglichen und ausgeglichen. Damit wird bestätigt, dass die Transaktion mit anderen Finanzdaten, etwa Kontoauszügen, übereinstimmt.
Warum das wichtig ist Diese Aktivität bildet den tatsächlichen Endpunkt im Lebenszyklus des Journaleintrags. Die Zeit von der Buchung bis zur Abstimmung ist eine wichtige KPI, um die Effizienz des Finanzabschlusses zu bewerten. Woher beziehen Dieses Ereignis wird üblicherweise im Oracle Financial Consolidation and Close Cloud Service (FCCS) oder im Account Reconciliation Cloud Service (ARCS) erfasst, nicht im Hauptbuch selbst. Es wird aus einer Statusänderung des mit dem Journaleintrag verknüpften Abstimmungsdatensatzes abgeleitet. Erfassung Verknüpfen Sie die Journaldaten mit Statusaktualisierungen der Abstimmung aus ARCS- oder FCCS-Tabellen. Ereignistyp inferred
	Journaleintrag gebucht	Die Finanzdaten des Journaleintrags wurden erfolgreich im Hauptbuch erfasst. Soll und Haben sind nun in den Kontensalden berücksichtigt.
Warum das wichtig ist Dieser wichtige Meilenstein kennzeichnet die Aufnahme des Journaleintrags in die offiziellen Finanzunterlagen. Er ist entscheidend, um die fristgerechte Buchungsquote und die Gesamtzeit von der Erstellung bis zur Buchung zu messen. Woher beziehen Dieses Ereignis wird aus einer Statusänderung in der Tabelle GL_JE_HEADERS abgeleitet, bei der das Feld STATUS auf „P“ (Posted) wechselt. Auch die Tabelle GL_JE_BATCHES enthält einen Buchungsstatus. Erfassung Erfassen Sie den Timestamp, zu dem STATUS in GL_JE_HEADERS auf „P“ wechselt. Ereignistyp inferred
	Journaleintrag genehmigt	Der zuständige Genehmiger hat den Journaleintrag formell genehmigt und damit dessen Richtigkeit und Gültigkeit bestätigt. Dies ist der letzte Schritt im Genehmigungs-Workflow und gibt den Eintrag zur Buchung frei.
Warum das wichtig ist Dieser Meilenstein markiert das Ende des Genehmigungsprozesses. Die Zeit zwischen Einreichung und Genehmigung ist eine wichtige KPI, um die Effizienz des Workflows zu messen und Engpässe bei Genehmigungen zu erkennen. Woher beziehen Dieses Ereignis wird aus einer Statusänderung in der Tabelle GL_JE_HEADERS abgeleitet, bei der APPROVAL_STATUS_CODE auf „APPROVED“ gesetzt wird. Die Workflow-Tabellen enthalten die Identität des Genehmigers und den Timestamp. Erfassung Erfassen Sie den Timestamp, zu dem sich APPROVAL_STATUS_CODE in GL_JE_HEADERS in „APPROVED“ ändert. Ereignistyp inferred
	Belege angehängt	Diese Aktivität bezeichnet das Anhängen von Belegen wie Rechnungen oder Tabellen an die Journalbuchung. Damit werden häufig Kontext und Nachweise für Prüfende und Genehmigende bereitgestellt.
Warum das wichtig ist Die Erfassung dieser Aktivität hilft zu erkennen, ob fehlende Belege Verzögerungen verursachen. Außerdem liefert sie Erkenntnisse zur Compliance und zur Vollständigkeit der Journalbuchungen, bevor diese in den Genehmigungsworkflow gelangen. Woher beziehen Diese Aktivität lässt sich als einzelnes Event nur schwer erfassen. Sie kann anhand der Timestamps in Anlagentabellen wie FND_ATTACHED_DOCUMENTS ermittelt werden, die mit dem Datensatz der Journalbuchung in GL_JE_HEADERS verknüpft sind. Erfassung Ermitteln Sie die Aktivität anhand des Erstellungsdatums der mit der Journalbuchung verknüpften Datensätze in FND_ATTACHED_DOCUMENTS. Ereignistyp inferred
	Buchung des Journaleintrags gestartet	Die Buchung des genehmigten Journaleintrags im Hauptbuch wurde gestartet. Dieser Schritt kann automatisiert oder manuell erfolgen und stellt den Journaleintrag zur Verarbeitung durch das Buchungsprogramm in die Warteschlange.
Warum das wichtig ist Diese Aktivität trennt die Genehmigung vom technischen Buchungsprozess. Verzögerungen zwischen Genehmigung und Buchungsstart können auf Probleme bei der Planung oder auf begrenzte Ressourcen im Buchungssystem hindeuten. Woher beziehen Dieses Ereignis lässt sich aus Statusänderungen in der Tabelle GL_JE_BATCHES oder anhand des Einreichungszeitpunkts des mit dem Journalbatch verknüpften gleichzeitigen Buchungsauftrags ableiten. Erfassung Ermitteln Sie den Einreichungszeitpunkt des General-Ledger-Buchungsprogramms für den jeweiligen Journalbatch. Ereignistyp inferred
	Buchung geprüft	Bei diesem Prüfschritt nach der Buchung bestätigt ein Benutzer oder System, dass der Journaleintrag korrekt gebucht wurde und die Salden den Erwartungen entsprechen. Häufig handelt es sich um eine manuelle Kontrollmaßnahme.
Warum das wichtig ist Die Analyse dieser Aktivität zeigt, wie viel Zeit nach der Buchung für manuelle Kontrollen und Qualitätssicherung aufgewendet wird. Sie kann Möglichkeiten zur Automatisierung der Prüfprozesse aufzeigen. Woher beziehen In Oracle Fusion gibt es wahrscheinlich kein explizites Ereignis dafür. Es müsste aus anderen Aktionen abgeleitet werden, etwa daraus, dass ein Benutzer einen bestimmten Bericht ausführt oder ein benutzerdefiniertes Statusfeld aktualisiert wird. Letzteres ist nicht standardmäßig vorgesehen. Erfassung Erfordert benutzerdefinierte Logik, etwa die Erfassung der Ausführungszeit von Prüfberichten oder von Aktualisierungen eines beschreibenden Flexfields. Ereignistyp inferred
	Journalbuchung abgelehnt	Eine genehmigende Person hat die Journalbuchung geprüft und wegen Fehlern, fehlender Belege oder Richtlinienverstößen abgelehnt. Dadurch wird die Buchung zur Korrektur an den Ersteller zurückgesendet.
Warum das wichtig ist Diese Aktivität ist entscheidend, um Nacharbeitsschleifen, Ablehnungsquoten und die Kennzahl „Beim ersten Mal korrekt“ zu analysieren. Häufige Ablehnungen weisen auf Probleme mit der Datenqualität oder dem Schulungsbedarf hin. Woher beziehen Dieses Event wird anhand einer Statusänderung in der Tabelle GL_JE_HEADERS ermittelt, wenn APPROVAL_STATUS_CODE auf 'REJECTED' gesetzt wird. Im Workflow-Verlauf werden der Benutzer und der Timestamp dieser Aktion protokolliert. Erfassung Erfassen Sie den Timestamp, an dem APPROVAL_STATUS_CODE in GL_JE_HEADERS auf 'REJECTED' gesetzt wird. Ereignistyp inferred
	Journalbuchung geprüft	Dieser Prüfschritt kann vor oder als Teil des formellen Genehmigungsprozesses stattfinden. Dabei prüft ein Kollege oder eine Führungskraft die Buchung auf Genauigkeit und Compliance, bevor sie an die endgültig genehmigende Person weitergeleitet wird.
Warum das wichtig ist Wenn Sie diese Aktivität gesondert betrachten, lassen sich die Zeiten für die Vorprüfung von den endgültigen Genehmigungszeiten unterscheiden. So werden verborgene Engpässe sichtbar, wenn die Prüfung informell, aber zeitaufwendig ist. Woher beziehen Bei einem mehrstufigen Genehmigungsworkflow kann dieser Schritt ausdrücklich vorgesehen und in Workflow-Verlaufstabellen erfasst sein. Eine informelle Prüfung wird nicht protokolliert. Sie lässt sich möglicherweise ableiten, wenn vor der endgültigen Genehmigung eine Aktion eines bestimmten Benutzers erfasst ist. Erfassung Analysieren Sie Workflow-Verlaufstabellen auf Zwischenschritte zur Genehmigung oder Prüfung vor dem endgültigen Status 'Approved'. Ereignistyp inferred
	Journalbuchung korrigiert und erneut eingereicht	Nach der Ablehnung korrigiert der Ersteller die Journalbuchung und reicht sie erneut zur Genehmigung ein. Damit beginnt für dieselbe Buchung ein neuer Genehmigungszyklus.
Warum das wichtig ist Die Erfassung von Nacharbeit ist entscheidend, um Ineffizienzen im Prozess zu verstehen. Zusammen mit der Aktivität 'Journal Entry Rejected' ermöglicht diese Aktivität, Dauer und Häufigkeit der Nacharbeit zu messen. Woher beziehen Dies ist ein nachfolgendes Ereignis „Journal zur Genehmigung eingereicht“ für einen Journaleintrag, der zuvor den Status „REJECTED“ hatte. Es wird ermittelt, indem die Abfolge der Statusänderungen für eine einzelne Journal Entry ID analysiert wird. Erfassung Ermitteln Sie den Timestamp eines Einreichungsereignisses, das nach einem Ablehnungsereignis für dieselbe Case-ID auftritt. Ereignistyp inferred
	Stornierung des Journaleintrags verarbeitet	Ein Stornierungsjournaleintrag wurde erstellt und in einer späteren Periode gebucht, um die finanzielle Auswirkung des ursprünglichen Journaleintrags aufzuheben. Dies ist bei Rückstellungen üblich.
Warum das wichtig ist Die Erfassung von Stornierungen hilft dabei, häufig stornierte Eintragsarten zu erkennen und die Effizienz des Stornierungsprozesses zu analysieren. Häufige Stornierungen können auf Probleme bei der Rückstellungsverwaltung hindeuten. Woher beziehen Dieses Ereignis wird ermittelt, indem ein neuer Journaleintrag identifiziert wird, der ausdrücklich als Stornierung mit dem ursprünglichen Eintrag verknüpft ist. Die Tabelle GL_JE_HEADERS enthält Felder wie REVERSAL_PERIOD und REVERSAL_FLAG, anhand derer sich diese Einträge erkennen und verknüpfen lassen. Erfassung Ermitteln Sie das Erstellungs- und Buchungsdatum des neuen Journaleintrags, dessen Kopfzeile auf den stornierten ursprünglichen Eintrag verweist. Ereignistyp inferred

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Oracle Fusion Financials

Schritte

Öffnen Sie den Arbeitsbereich „Berichte und Analysen“: Melden Sie sich bei Oracle Fusion Financials an. Öffnen Sie über das Navigator-Menü den Bereich Tools und wählen Sie anschließend Berichte und Analysen. Hier erstellen und verwalten Sie Analysen und Berichte.
Erstellen Sie ein BI-Publisher-Datenmodell: Für diese Art der Event-Log-Extraktion empfiehlt es sich, direkt ein BI-Publisher-Datenmodell zu erstellen, statt mit einer OTBI-Analyse zu beginnen. So können Sie eine benutzerdefinierte SQL-Abfrage mit UNION ALL-Anweisungen verwenden. Klicken Sie auf „Katalog durchsuchen“, öffnen Sie einen geeigneten Ordner und wählen Sie Erstellen > Datenmodell.
Legen Sie das SQL-Abfragedataset fest: Klicken Sie im Datenmodell-Editor auf das Symbol „+“, um ein neues Dataset hinzuzufügen, und wählen Sie „SQL-Abfrage“. Geben Sie dem Dataset einen aussagekräftigen Namen, zum Beispiel „JournalEventLog“.
Geben Sie die SQL-Abfrage ein: Wählen Sie „Oracle BI EE“ als Datenquelle. Kopieren Sie das vollständige SQL-Skript aus dem Abschnitt „Abfrage“ weiter unten und fügen Sie es in das SQL-Abfragefeld ein. Die Abfrage führt alle erforderlichen Aktivitäten und Attribute in einer einheitlichen Struktur zusammen.
Legen Sie die Parameter fest: Die Abfrage verwendet Parameter wie :start_date, :end_date und :ledger_name. Die Datenmodelloberfläche erkennt diese automatisch. Richten Sie sie als Parameter ein und legen Sie bei Bedarf passende Datentypen (Datum oder Text) sowie Standardwerte fest. So können Sie den Bericht flexibel ausführen.
Erstellen Sie einen Bericht aus dem Datenmodell: Speichern Sie das Datenmodell und kehren Sie zum Katalog zurück. Klicken Sie auf Erstellen > Bericht. Wählen Sie im Berichtsassistenten „Vorhandenes Datenmodell verwenden“ und anschließend das soeben erstellte Datenmodell.
Richten Sie das Berichtslayout ein: Wählen Sie im Layout-Editor das Tabellenlayout. Ziehen Sie alle Spalten aus dem Datenmodell in die Tabelle, damit sie beim Export enthalten sind. Eine aufwendige Formatierung ist nicht erforderlich.
Legen Sie CSV als Standardausgabe fest: Öffnen Sie im Berichts-Editor den Link „Liste anzeigen“. Vergewissern Sie sich im Abschnitt „Ausgabeformate“, dass CSV ausgewählt ist. Deaktivieren Sie am besten alle anderen Formate, um die Planung zu vereinfachen. Speichern Sie den Bericht.
Planen Sie den Bericht für die automatische Extraktion: Suchen Sie den gespeicherten Bericht im Katalog und klicken Sie auf „Mehr“ und anschließend auf „Planen“. Erstellen Sie einen neuen Zeitplan und legen Sie die Häufigkeit fest, zum Beispiel täglich oder wöchentlich.
Richten Sie Export und Bereitstellung ein: Legen Sie im Tab „Ausgabe“ des geplanten Jobs die Ausgabedetails fest. Wählen Sie den Bericht und als Format CSV. Im Tab „Ziel“ können Sie die Datei automatisch an einen Speicherort auf dem Content Server (UCM) oder an einen externen SFTP-Server übertragen lassen.
Rufen Sie die Daten ab und bereiten Sie sie vor: Rufen Sie nach Ausführung des geplanten Jobs die erzeugte CSV-Datei am konfigurierten Ziel ab. Prüfen Sie, ob die Spaltenüberschriften den Anforderungen für den Import in ProcessMind entsprechen, zum Beispiel JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate und UserName. Die Datei kann jetzt hochgeladen werden.

Konfiguration

Datenquelle: Führen Sie die Abfrage in BI Publisher mit der Datenquelle „Oracle BI EE“ aus. Sie stellt eine Verbindung zu den zugrunde liegenden Datenbankansichten her, die OTBI unterstützen.
Wichtige Themenbereiche zur Orientierung: Die Abfragelogik basiert hauptsächlich auf Daten aus dem Themenbereich „General Ledger - Journals Real Time“. Außerdem werden logisch Daten aus „HCM - Workforce Management - Worker Assignment Real Time“ für Benutzerangaben und gegebenenfalls aus Workflow-Themenbereichen für den Freigabeverlauf verknüpft.
Datumsbereich filtern: Begrenzen Sie den Zeitraum unbedingt auf eine überschaubare Größe. Die Abfrage enthält die Parameter :start_date und :end_date. Für eine erste Analyse empfehlen wir, Daten aus drei bis sechs Monaten zu extrahieren. Der Filter wird auf das Erstellungsdatum der Journalbuchung angewendet.
Hauptbuch filtern: Verwenden Sie den Parameter :ledger_name, um die Extraktion auf ein bestimmtes primäres Hauptbuch zu begrenzen. Werden alle Hauptbücher gleichzeitig extrahiert, können sehr große Dateien entstehen und Leistungsprobleme auftreten.
Voraussetzungen: Die Person, die den Bericht erstellt und plant, benötigt passende BI-Rollen, zum Beispiel „BI Administrator“ oder „BI Author“. Außerdem muss das Datensicherheitsprofil den Zugriff auf die abgefragten Hauptbücher und Geschäftseinheiten erlauben.
Zeitplanung: Planen Sie die Extraktion außerhalb der Spitzenzeiten, zum Beispiel über Nacht. So vermeiden Sie Leistungseinbußen für die Systembenutzer.

a Beispielabfrage sql

WITH JournalHeaders AS (
    SELECT
        gjh.je_header_id,
        gjh.ledger_id,
        gl.name AS ledger_name,
        gjb.je_batch_id,
        gjh.doc_sequence_value,
        gjh.name AS journal_name,
        gjc.user_je_category_name AS journal_category,
        gjs.user_je_source_name AS journal_source,
        gjh.default_effective_date,
        gjh.creation_date,
        gjh.created_by,
        gjh.last_update_date,
        gjh.last_updated_by,
        gjh.posted_date,
        gjb.approval_status_code AS batch_approval_status,
        gjh.accrual_rev_period_name,
        gjh.accrual_rev_je_header_id,
        (SELECT SUM(accounted_dr) FROM gl_je_lines WHERE je_header_id = gjh.je_header_id) AS journal_amount
    FROM
        gl_je_headers gjh
    JOIN
        gl_je_batches gjb ON gjh.je_batch_id = gjb.je_batch_id
    JOIN
        gl_ledgers gl ON gjh.ledger_id = gl.ledger_id
    JOIN
        gl_je_categories_tl gjc ON gjh.je_category = gjc.je_category_name AND gjc.language = USERENV('LANG')
    JOIN
        gl_je_sources_tl gjs ON gjh.je_source = gjs.je_source_name AND gjs.language = USERENV('LANG')
    WHERE
        gjh.creation_date BETWEEN TO_DATE(:start_date, 'YYYY-MM-DD') AND TO_DATE(:end_date, 'YYYY-MM-DD')
        AND gl.name = :ledger_name
)
-- 1. Journal Entry Created
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Created' AS "ActivityName",
    jh.creation_date AS "EventTime",
    u.username AS "UserName",
    papf.person_number AS "UserDepartment", -- Placeholder: Configure based on your department tracking
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
LEFT JOIN
    per_users u ON jh.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(SYSDATE) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 2. Supporting Documentation Attached
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Supporting Documentation Attached' AS "ActivityName",
    fad.creation_date AS "EventTime",
    u.username AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    fnd_attached_documents fad
JOIN
    JournalHeaders jh ON fad.pk1_value = TO_CHAR(jh.je_header_id) AND fad.entity_name = 'GL_JE_HEADERS'
LEFT JOIN
    per_users u ON fad.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(fad.creation_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 3. Journal Submitted For Approval
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Submitted For Approval' AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_transactions wft ON wft.transaction_id = jh.je_batch_id AND wft.application_id = 101 AND wft.transaction_class = 'Journal Batch'
JOIN
    fun_all_wf_approvals wfa ON wft.transaction_id = wfa.transaction_id AND wfa.response = 'SUBMITTED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 4. Journal Entry Reviewed & 7. Journal Entry Approved
SELECT
    jh.je_header_id AS "JournalEntryId",
    CASE
        WHEN wfa.approval_level < (SELECT MAX(approval_level) FROM fun_all_wf_approvals WHERE transaction_id = wfa.transaction_id) THEN 'Journal Entry Reviewed'
        ELSE 'Journal Entry Approved'
    END AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_approvals wfa ON wfa.transaction_id = jh.je_batch_id AND wfa.response = 'APPROVED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 5. Journal Entry Rejected
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Rejected' AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    wfa.reason AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_approvals wfa ON wfa.transaction_id = jh.je_batch_id AND wfa.response = 'REJECTED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 6. Journal Corrected and Resubmitted
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Corrected and Resubmitted' AS "ActivityName",
    resubmit_events.created_date AS "EventTime",
    resubmit_events.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN (
    SELECT wfa.transaction_id, wfa.created_date, wfa.updated_by
    FROM fun_all_wf_approvals wfa
    WHERE wfa.response = 'SUBMITTED'
    AND EXISTS (
        SELECT 1
        FROM fun_all_wf_approvals prev_wfa
        WHERE prev_wfa.transaction_id = wfa.transaction_id
        AND prev_wfa.response = 'REJECTED'
        AND prev_wfa.created_date < wfa.created_date
    )
) resubmit_events ON jh.je_batch_id = resubmit_events.transaction_id
LEFT JOIN
    per_users u ON resubmit_events.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(resubmit_events.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 8. Journal Posting Initiated
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Posting Initiated' AS "ActivityName",
    gjb.last_update_date AS "EventTime",
    gjb.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_batches gjb ON jh.je_batch_id = gjb.je_batch_id
WHERE
    gjb.status = 'I' -- 'I' typically means Selected for Posting
    AND jh.posted_date IS NOT NULL
LEFT JOIN
    per_users u ON gjb.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(gjb.last_update_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 9. Journal Entry Posted
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Posted' AS "ActivityName",
    jh.posted_date AS "EventTime",
    jh.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
LEFT JOIN
    per_users u ON jh.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(jh.posted_date) BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
    jh.posted_date IS NOT NULL

UNION ALL

-- 10. Posting Verified - This is a placeholder as it is typically a manual control step not logged in a standard table.
-- This part of the query will return no rows unless you have a custom solution, such as a Descriptive Flexfield (DFF), to track this.
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Posting Verified' AS "ActivityName",
    jh.last_update_date AS "EventTime", -- Placeholder timestamp
    jh.last_updated_by AS "UserName", -- Placeholder user
    NULL AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
WHERE
    1 = 2 -- This condition ensures no rows are returned. Replace with logic for your custom DFF or tracking field.

UNION ALL

-- 11. Journal Entry Reconciled - This depends on integration with Oracle Account Reconciliation (ARCS).
-- This query assumes reconciliation status is written back to GL_RECONCILIATION_REFERENCES.
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Reconciled' AS "ActivityName",
    grr.last_update_date AS "EventTime",
    grr.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_lines gjl ON jh.je_header_id = gjl.je_header_id
JOIN
    gl_reconciliation_references grr ON gjl.je_header_id = grr.je_header_id AND gjl.je_line_num = grr.je_line_num
WHERE
    grr.status = 'R' -- Assuming 'R' means Reconciled. Verify based on your ARCS configuration.
LEFT JOIN
    per_users u ON grr.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(grr.last_update_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 12. Journal Reversal Processed
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Reversal Processed' AS "ActivityName",
    rev_jh.creation_date AS "EventTime",
    rev_jh.created_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_headers rev_jh ON jh.je_header_id = rev_jh.accrual_rev_je_header_id
LEFT JOIN
    per_users u ON rev_jh.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(rev_jh.creation_date) BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
    jh.accrual_rev_je_header_id IS NOT NULL

Schritte

Öffnen Sie BI Publisher: Melden Sie sich bei Oracle Fusion Financials an. Öffnen Sie über das Navigator-Menü den Bereich Tools und wählen Sie Berichte und Analysen. Dadurch wird der Business-Intelligence-Katalog geöffnet.
Erstellen Sie ein Datenmodell: Klicken Sie im BI-Katalog auf Erstellen und wählen Sie Datenmodell. Der Datenmodell-Editor wird geöffnet.
Legen Sie das SQL-Abfragedataset fest: Klicken Sie im Datenmodell-Editor im Tab „Diagramm“ auf das Pluszeichen und wählen Sie „SQL-Abfrage“. Geben Sie dem Dataset im neuen Dialogfeld einen Namen, zum Beispiel ProcessMind_JE_EventLog. Wählen Sie die passende Datenquelle, üblicherweise FUSIONDB. Fügen Sie die vollständige bereitgestellte SQL-Abfrage in das SQL-Abfragefeld ein.
Legen Sie die Parameter fest: Die Abfrage verwendet die Parameter für den Datumsbereich (p_start_date und p_end_date). Oracle BI Publisher erkennt diese automatisch. Richten Sie sie als Parameter vom Typ Text ein und vergeben Sie verständliche Bezeichnungen wie „Startdatum (JJJJ-MM-TT)“ und „Enddatum (JJJJ-MM-TT)“.
Speichern Sie das Datenmodell: Klicken Sie nach dem Einfügen der Abfrage und dem Festlegen der Parameter auf OK. Speichern Sie das Datenmodell in einem geeigneten Ordner, zum Beispiel Shared Folders/Custom/ProcessMining.
Erstellen Sie den Bericht: Klicken Sie oben rechts im Datenmodell-Editor auf „Bericht erstellen“. Der Berichtsassistent wird geöffnet.
Richten Sie das Berichtslayout ein: Wählen Sie im Assistenten das aktuelle Datenmodell und anschließend das Tabellenlayout. Ziehen Sie alle Spalten aus der Datenquelle in den Tabellenbereich. Deaktivieren Sie die Option „Zeile mit Gesamtsummen anzeigen“.
Speichern Sie den Bericht: Speichern Sie den Bericht im selben Ordner wie das Datenmodell. Wählen Sie einen aussagekräftigen Namen, zum Beispiel „Bericht zum Event Log für Journalbuchungen“.
Legen Sie das Standardausgabeformat fest: Bearbeiten Sie den Bericht und öffnen Sie den Tab „Anzeige“. Vergewissern Sie sich unter „Ausgabeformate“, dass CSV ausgewählt ist, und legen Sie es möglichst als Standardformat fest. So ist die Ausgabe direkt verwendbar.
Führen Sie den Bericht aus und exportieren Sie die Daten: Öffnen Sie den Bericht und geben Sie die Parameter für Start- und Enddatum ein. Tragen Sie den gewünschten Zeitraum ein und klicken Sie auf Anwenden. Klicken Sie nach der Ausführung auf Exportieren und wählen Sie CSV, um die Event-Log-Datei herunterzuladen.
Bereiten Sie den Upload vor: Öffnen Sie die heruntergeladene CSV-Datei. Prüfen Sie, ob die Spaltenüberschriften den erwarteten Attributnamen entsprechen (JournalEntryId, ActivityName, EventTime usw.) und die Daten korrekt formatiert sind, bevor Sie sie auf die ProcessMind-Plattform hochladen.

Konfiguration

Voraussetzungen: Für den Bericht ist eine Rolle mit den erforderlichen Datensicherheitsberechtigungen für den Zugriff auf Hauptbuchdaten erforderlich, zum Beispiel General Accountant oder eine benutzerdefinierte BI-Rolle. Außerdem benötigen Sie Zugriff auf BI Publisher.
Datenquelle: Richten Sie das BI-Publisher-Datenmodell für die Verbindung zur Anwendungsdatenbank FUSIONDB ein.
Parameter für den Datumsbereich: Die Abfrage verwendet die Parameter p_start_date und p_end_date, um den Extraktionszeitraum festzulegen. Für eine gute Leistung empfiehlt es sich, zunächst Daten aus drei bis sechs Monaten zu verwenden.
Berichtsfilter: Bei großen Organisationen sollten Sie unbedingt Filter direkt in die WHERE-Klausel des allgemeinen Tabellenausdrucks JournalHeaders einfügen. Filtern Sie nach LEDGER_ID oder LEGAL_ENTITY_ID, um das Datenvolumen zu begrenzen.
Leistung: Die Ausführung dieser Abfrage auf einer großen Produktionsdatenbank kann erhebliche Ressourcen beanspruchen. Planen Sie den Bericht außerhalb der Spitzenzeiten, um die Systemleistung möglichst wenig zu beeinträchtigen.
Ausgabeformat: Der Bericht muss als CSV-Datei ausgegeben werden. Dieses strukturierte Format eignet sich für den Import in Process-Mining-Tools.

a Beispielabfrage sql

WITH JournalHeaders AS (
    SELECT
        gjh.JE_HEADER_ID,
        gjh.NAME AS JOURNAL_NAME,
        gjh.LEDGER_ID,
        gjh.JE_CATEGORY,
        gjh.JE_SOURCE,
        gjh.STATUS,
        gjh.APPROVAL_STATUS_CODE,
        gjh.CREATED_BY,
        gjh.CREATION_DATE,
        gjh.LAST_UPDATED_BY,
        gjh.LAST_UPDATE_DATE,
        gjh.POSTED_DATE,
        gjh.ACCRUAL_REV_JE_HEADER_ID,
        gjh.ACCRUAL_REV_PERIOD_NAME,
        gjs.USER_JE_SOURCE_NAME,
        gjc.USER_JE_CATEGORY_NAME,
        (SELECT SUM(NVL(gjl.ACCOUNTED_DR, 0)) FROM GL_JE_LINES gjl WHERE gjl.JE_HEADER_ID = gjh.JE_HEADER_ID) AS JOURNAL_AMOUNT
    FROM
        GL_JE_HEADERS gjh
    JOIN
        GL_JE_SOURCES_TL gjs ON gjh.JE_SOURCE = gjs.JE_SOURCE_NAME AND gjs.LANGUAGE = USERENV('LANG')
    JOIN
        GL_JE_CATEGORIES_TL gjc ON gjh.JE_CATEGORY = gjc.JE_CATEGORY_NAME AND gjc.LANGUAGE = USERENV('LANG')
    WHERE
        gjh.CREATION_DATE BETWEEN TO_TIMESTAMP(:p_start_date || ' 00:00:00.000', 'YYYY-MM-DD HH24:MI:SS.FF') AND TO_TIMESTAMP(:p_end_date || ' 23:59:59.999', 'YYYY-MM-DD HH24:MI:SS.FF')
        AND gjh.ACTUAL_FLAG = 'A'
        -- Recommended: Add a filter for your specific ledger(s) to improve performance
        -- AND gjh.LEDGER_ID IN ([Your Ledger ID])
),
UserDepartment AS (
    -- This subquery is an example. The join logic to find a user's department may need to be adjusted
    -- based on your specific Oracle HCM configuration (e.g., using different assignment types or tables).
    SELECT 
        pu.USERNAME, 
        org.NAME as Department
    FROM PER_USERS pu
    LEFT JOIN PER_ALL_ASSIGNMENTS_F asg ON pu.PERSON_ID = asg.PERSON_ID 
        AND asg.ASSIGNMENT_TYPE IN ('E', 'C') 
        AND asg.PRIMARY_FLAG = 'Y'
        AND SYSDATE BETWEEN asg.EFFECTIVE_START_DATE AND asg.EFFECTIVE_END_DATE
    LEFT JOIN HR_ALL_ORGANIZATION_UNITS_F_VL org ON asg.ORGANIZATION_ID = org.ORGANIZATION_ID
        AND SYSDATE BETWEEN org.EFFECTIVE_START_DATE AND org.EFFECTIVE_END_DATE
    WHERE pu.USERNAME IS NOT NULL
)
-- 1. Journal Entry Created
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Created' AS "ActivityName",
    jh.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.CREATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.CREATED_BY = ud.USERNAME

UNION ALL

-- 2. Supporting Documentation Attached
SELECT
    TO_NUMBER(fad.PK1_VALUE) AS "JournalEntryId",
    'Supporting Documentation Attached' AS "ActivityName",
    fad.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    fad.CREATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    FND_ATTACHED_DOCUMENTS fad
JOIN
    JournalHeaders jh ON fad.PK1_VALUE = TO_CHAR(jh.JE_HEADER_ID)
LEFT JOIN UserDepartment ud ON fad.CREATED_BY = ud.USERNAME
WHERE
    fad.ENTITY_NAME = 'GL_JE_HEADERS'

UNION ALL

-- 3. Journal Submitted For Approval
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Submitted For Approval' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE IN ('REQUIRED', 'INITIATED')

UNION ALL

-- 4. Journal Entry Reviewed (Placeholder)
-- This activity requires custom logic based on your approval workflow configuration.
-- The query below is a placeholder and may not return any data without customization.
-- It assumes a review happens if the approval status is updated but not yet approved or rejected.
SELECT
    NULL AS "JournalEntryId",
    NULL AS "ActivityName",
    NULL AS "EventTime",
    NULL AS "SourceSystem",
    NULL AS "LastDataUpdate",
    NULL AS "UserName",
    NULL AS "UserDepartment",
    NULL AS "JournalCategory",
    NULL AS "JournalSource",
    NULL AS "JournalAmount",
    NULL AS "RejectionReason"
FROM DUAL WHERE 1=0

UNION ALL

-- 5. Journal Entry Rejected
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Rejected' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    -- Rejection Reason is not a standard field. This might be found in workflow tables.
    '[Configure based on your system]' AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE = 'REJECTED'

UNION ALL

-- 6. Journal Corrected and Resubmitted
-- This logic assumes a resubmission is an update that occurs after a rejection.
-- A more precise method would involve analyzing workflow history, which is complex.
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Corrected and Resubmitted' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE IN ('REQUIRED', 'INITIATED')
    AND jh.JE_HEADER_ID IN (SELECT h.JE_HEADER_ID FROM GL_JE_HEADERS h WHERE h.APPROVAL_STATUS_CODE = 'REJECTED')

UNION ALL

-- 7. Journal Entry Approved
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Approved' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE = 'APPROVED'

UNION ALL

-- 8. Journal Posting Initiated
-- The exact initiation time is not stored. We infer it as 5 minutes before the final posted date.
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Posting Initiated' AS "ActivityName",
    (jh.POSTED_DATE - INTERVAL '5' MINUTE) AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    -- Posting is often a system process, so user might not be available.
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.STATUS = 'P' AND jh.POSTED_DATE IS NOT NULL

UNION ALL

-- 9. Journal Entry Posted
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Posted' AS "ActivityName",
    jh.POSTED_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.STATUS = 'P' AND jh.POSTED_DATE IS NOT NULL

UNION ALL

-- 10. Posting Verified (Placeholder)
-- This is a manual control activity not tracked by default. This query must be customized.
-- It assumes a descriptive flexfield named 'POSTING_VERIFIED_DATE' on GL_JE_HEADERS exists.
SELECT
    NULL AS "JournalEntryId",
    NULL AS "ActivityName",
    NULL AS "EventTime",
    NULL AS "SourceSystem",
    NULL AS "LastDataUpdate",
    NULL AS "UserName",
    NULL AS "UserDepartment",
    NULL AS "JournalCategory",
    NULL AS "JournalSource",
    NULL AS "JournalAmount",
    NULL AS "RejectionReason"
FROM DUAL WHERE 1=0

UNION ALL

-- 11. Journal Entry Reconciled (Placeholder)
-- Reconciliation is typically done in other modules. This query must be customized.
-- It assumes a custom table or field indicates when a journal is reconciled.
SELECT
    NULL AS "JournalEntryId",
    NULL AS "ActivityName",
    NULL AS "EventTime",
    NULL AS "SourceSystem",
    NULL AS "LastDataUpdate",
    NULL AS "UserName",
    NULL AS "UserDepartment",
    NULL AS "JournalCategory",
    NULL AS "JournalSource",
    NULL AS "JournalAmount",
    NULL AS "RejectionReason"
FROM DUAL WHERE 1=0

UNION ALL

-- 12. Journal Reversal Processed
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Reversal Processed' AS "ActivityName",
    rev_jh.POSTED_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    rev_jh.CREATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
JOIN
    GL_JE_HEADERS rev_jh ON jh.ACCRUAL_REV_JE_HEADER_ID = rev_jh.JE_HEADER_ID
LEFT JOIN UserDepartment ud ON rev_jh.CREATED_BY = ud.USERNAME
WHERE
    jh.ACCRUAL_REV_JE_HEADER_ID IS NOT NULL
    AND rev_jh.STATUS = 'P'
ORDER BY
    "JournalEntryId", "EventTime"

Schritte

Voraussetzungen: Installieren Sie Python 3 sowie die Bibliotheken requests und pandas. Sie benötigen ein Benutzerkonto für Oracle Fusion Financials mit den erforderlichen Berechtigungen für den Zugriff auf die REST API für Hauptbuchjournalbuchungen. Halten Sie die URL Ihrer Oracle-Fusion-Instanz sowie Ihren Benutzernamen und Ihr Passwort bereit.
Skript einrichten: Erstellen Sie eine neue Python-Skriptdatei. Importieren Sie zunächst die benötigten Bibliotheken: requests, json, pandas und datetime.
Konfiguration: Definieren Sie im Skript Variablen für Ihre Oracle-Fusion-Zugangsdaten und die Basis-URL. Legen Sie außerdem Parameter für die Datenextraktion fest, zum Beispiel Start- und Enddatum der Abfrage.
Authentifizierung: Das Skript verwendet die Basisauthentifizierung. Die Bibliothek requests kodiert Benutzername und Passwort in den Request-Headern.
Funktion für API-Aufrufe definieren: Erstellen Sie eine Funktion für die API-Anfragen. Sie sollte die Seitennavigation über die Parameter offset und limit verwalten. Die Funktion führt wiederholt API-Aufrufe aus, bis alle Journalbuchungen im angegebenen Zeitraum abgerufen wurden.
API-Abfrage erstellen: Verwenden Sie den Parameter q in der API-Anfrage, um Journalbuchungen anhand von LastUpdateDate zu filtern. So können Sie Daten gezielt für einen bestimmten Zeitraum extrahieren, zum Beispiel LastUpdateDate between '2023-01-01' and '2023-03-31'.
Datenabruf starten: Rufen Sie die Funktion auf, um Daten vom Endpunkt .../fscmRestApi/resources/11.13.18.05/journals abzurufen. Die Funktion gibt eine vollständige Liste der Journalbuchungen zurück.
Daten verarbeiten und umwandeln: Durchlaufen Sie alle von der API zurückgegebenen Journalbuchungen. Erzeugen Sie für jede Buchung mehrere Ereigniszeilen, die den verschiedenen Geschäftsaktivitäten entsprechen, zum Beispiel „Journalbuchung erstellt“ und „Journalbuchung freigegeben“. Verwenden Sie Datumsfelder und Statuscodes aus der API-Antwort (CreationDate, PostedDate, ApprovalStatus usw.), um diese Ereignisse abzubilden.
Event Log strukturieren: Speichern Sie jede erzeugte Ereigniszeile als Dictionary in einer Liste. Diese Liste bildet die Rohdaten für Ihr Event Log.
DataFrame erstellen: Wandeln Sie die Liste der Ereignis-Dictionaries nach der Verarbeitung aller Journalbuchungen in einen Pandas DataFrame um. So lassen sich die Daten leichter bearbeiten.
Spalten festlegen: Wählen Sie die Spalten des DataFrame aus und benennen Sie sie so um, dass sie dem erforderlichen Schema für ProcessMind entsprechen: JournalEntryId, ActivityName, EventTime, UserName usw.
Als CSV exportieren: Speichern Sie den fertigen DataFrame in einer CSV-Datei. Anschließend können Sie diese Datei zur Analyse direkt in ProcessMind hochladen.

Konfiguration

Zugangsdaten: Für die Basisauthentifizierung benötigen Sie einen gültigen Oracle-Fusion-Benutzernamen und das zugehörige Passwort.
Instanz-URL: Die Basis-URL Ihrer Oracle-Fusion-Financials-Instanz wird benötigt, um den API-Endpunkt zu erstellen, zum Beispiel https://[your-instance].fa.us2.oraclecloud.com.
API-Endpunkt: Das Skript ruft Hauptbuchdaten über den Endpunkt fscmRestApi/resources/11.13.18.05/journals ab.
Datumsbereichsfilter: Legen Sie im Skript start_date und end_date fest, um den Extraktionszeitraum zu begrenzen. Für eine erste Analyse empfehlen wir einen Zeitraum von drei bis sechs Monaten. Für den laufenden Betrieb richten Sie tägliche oder wöchentliche inkrementelle Ladevorgänge ein.
Seitengröße: Der Parameter limit bestimmt, wie viele Datensätze pro API-Aufruf abgerufen werden. Ein Wert zwischen 200 und 500 ist in der Regel effizient und bietet einen guten Ausgleich zwischen der Anzahl der API-Aufrufe und dem Umfang der einzelnen Antworten.
Erforderliche Oracle-Rollen: Das Benutzerkonto benötigt eine Rolle mit den erforderlichen Berechtigungen zum Lesen von Journalbuchungsdaten über die REST API, zum Beispiel General Accountant oder eine benutzerdefinierte Rolle mit gleichwertigen Berechtigungen.

a Beispielabfrage python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance details
FUSION_URL = class="hl-string">"https://[your-instance].fa.us2.oraclecloud.com"
USERNAME = class="hl-string">"[your-username]"
PASSWORD = class="hl-string">"[your-password]"

class=class="hl-string">"hl-comment"># --- Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"
PAGE_LIMIT = 500 class=class="hl-string">"hl-comment"># Number of records per API call

def get_all_journals(base_url, user, password, start_date, end_date):
    class="hl-string">"""Fetches all journals from the Oracle Fusion REST API within a date range, handling pagination."""
    all_journals = []
    offset = 0
    has_more = True
    
    api_url = fclass="hl-string">"{base_url}/fscmRestApi/resources/11.13.18.05/journals"
    
    headers = {
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourcecollection+json'
    }
    
    query_filter = fclass="hl-string">"LastUpdateDate between '{start_date}' and '{end_date}'"
    
    while has_more:
        params = {
            class="hl-string">'q': query_filter,
            class="hl-string">'onlyData': class="hl-string">'true',
            class="hl-string">'limit': PAGE_LIMIT,
            class="hl-string">'offset': offset,
            class="hl-string">'fields': class="hl-string">'JeHeaderId,CreatedBy,CreationDate,LastUpdatedBy,LastUpdateDate,PostedDate,ApprovalStatus,ActualFlag,DefaultEffectiveDate,Description,JeCategory,JeSource,PeriodName,TotalDebit,ReversalDate,ReversalPeriodName,ExternalReference,attachments'
        }
        
        print(fclass="hl-string">"Fetching records from offset {offset}...")
        try:
            response = requests.get(api_url, auth=(user, password), headers=headers, params=params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            
            journals = data.get(class="hl-string">'items', [])
            all_journals.extend(journals)
            
            has_more = data.get(class="hl-string">'hasMore', False)
            offset += PAGE_LIMIT

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"An error occurred: {e}")
            has_more = False

    return all_journals

def transform_to_event_log(journals):
    class="hl-string">"""Transforms the raw journal data into a structured event log."""
    event_log = []
    extraction_timestamp = datetime.now(timezone.utc).isoformat()

    for jrnl in journals:
        journal_id = jrnl.get(class="hl-string">'JeHeaderId')
        created_by = jrnl.get(class="hl-string">'CreatedBy')
        last_updated_by = jrnl.get(class="hl-string">'LastUpdatedBy')
        approval_status = jrnl.get(class="hl-string">'ApprovalStatus')
        rejection_reason_text = class="hl-string">"Rejected per workflow comments" if approval_status == class="hl-string">'REJECTED' else None

        class=class="hl-string">"hl-comment"># 1. Journal Entry Created
        if jrnl.get(class="hl-string">'CreationDate'):
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Entry Created',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'CreationDate'),
                class="hl-string">'UserName': created_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]',
                class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'),
                class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'),
                class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># 2. Supporting Documentation Attached (Approximation)
        if jrnl.get(class="hl-string">'attachments') and len(jrnl[class="hl-string">'attachments']) > 0:
             event_log.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Supporting Documentation Attached',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class=class="hl-string">"hl-comment"># Approximation: uses last update date
                class="hl-string">'UserName': last_updated_by, 
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]',
                class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'),
                class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'),
                class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># 3, 4, 5, 6, 7: Approval Workflow Events (Inferred from final status)
        class=class="hl-string">"hl-comment"># Note: This block infers events. For a more detailed history, workflow-specific APIs would be needed.
        if approval_status in [class="hl-string">'IN_PROCESS', class="hl-string">'REQUIRED']:
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Submitted For Approval',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
        elif approval_status == class="hl-string">'REJECTED':
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Rejected',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by, class=class="hl-string">"hl-comment"># Approver is often the last updater
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': rejection_reason_text,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
            class=class="hl-string">"hl-comment"># A resubmission is assumed if a rejected journal is updated again
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Corrected and Resubmitted',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': created_by, class=class="hl-string">"hl-comment"># Typically the creator corrects it
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
        elif approval_status == class="hl-string">'APPROVED':
            class=class="hl-string">"hl-comment"># class="hl-string">'Journal Entry Reviewed' is often an implicit part of approval
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Reviewed',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Approved',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># 8, 9: Posting Events
        if jrnl.get(class="hl-string">'PostedDate'):
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Posting Initiated',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'PostedDate'), class=class="hl-string">"hl-comment"># Assuming initiation is same as posted time
                class="hl-string">'UserName': class="hl-string">'System', class=class="hl-string">"hl-comment"># Posting is often a system process
                class="hl-string">'UserDepartment': class="hl-string">'Finance Operations', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Posted',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'PostedDate'),
                class="hl-string">'UserName': class="hl-string">'System',
                class="hl-string">'UserDepartment': class="hl-string">'Finance Operations', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
        
        class=class="hl-string">"hl-comment"># 12. Journal Reversal Processed
        if jrnl.get(class="hl-string">'ReversalDate'):
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Reversal Processed',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'ReversalDate'),
                class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]',
                class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'),
                class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'),
                class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># Activities not directly available from this API, added as placeholders for potential enrichment
        class=class="hl-string">"hl-comment"># Posting Verified, Journal Entry Reconciled

    return pd.DataFrame(event_log)

class=class="hl-string">"hl-comment"># --- Main Execution ---
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Oracle Fusion Journal Entry extraction...")
    raw_journals = get_all_journals(FUSION_URL, USERNAME, PASSWORD, START_DATE, END_DATE)
    
    if raw_journals:
        print(fclass="hl-string">"Successfully extracted {len(raw_journals)} journal records.")
        event_log_df = transform_to_event_log(raw_journals)
        
        if not event_log_df.empty:
            class=class="hl-string">"hl-comment"># Save to CSV
            output_filename = fclass="hl-string">"oracle_fusion_journal_events_{START_DATE}_to_{END_DATE}.csv"
            event_log_df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"Event log saved to {output_filename}")
        else:
            print(class="hl-string">"No events were generated from the extracted data.")
    else:
        print(class="hl-string">"No data extracted. Please check configuration and API availability.")

Schritte

Prüfen Sie, ob BI Cloud Connector, die erforderlichen Oracle-Fusion-Financials-Themenbereiche für das Hauptbuch oder Public View Objects sowie die nötigen Berechtigungen für das Quellsystem in Ihrer Umgebung verfügbar sind. Klären Sie mit Ihrer Oracle-Administration, welches BICC-Ziel für die Datenübertragung eingerichtet ist und welche Zugangsdaten dafür gelten.
Ermitteln Sie in der BI-Cloud-Connector-Konsole die Public View Objects mit Daten zu Journalüberschriften, Journalzeilen, Freigabeverlauf, Anhängen, Buchungsstatus, Abstimmungsstatus und Stornierungen. Notieren Sie die genauen Objekt- und Attributnamen Ihrer Umgebung. Ersetzen Sie vor der Ausführung die Platzhalter im Extraktionsskript durch diese Namen.
Richten Sie einen BICC-Job für die ausgewählten Public View Objects des Hauptbuchs ein. Verwenden Sie eine inkrementelle Extraktion, sofern ein zuverlässiges Attribut für die letzte Aktualisierung verfügbar ist. Begrenzen Sie den ersten Ladevorgang auf einen Zeitraum von drei bis sechs Monaten oder einen anderen freigegebenen Buchungszeitraum.
Konfigurieren Sie BICC so, dass die Extraktionsdateien an den vorgesehenen Cloud-Speicherort übertragen werden. Prüfen Sie Dateiformat, Trennzeichen, Zeichenkodierung, Komprimierung, Partitionierung, Namenskonvention und Übertragungszeitplan. Speichern Sie den Extraktions-Wasserstand oder den Timestamp der letzten erfolgreichen Extraktion.
Rufen Sie die übertragenen Dateien im freigegebenen Staging-Bereich ab. Laden Sie jede Quelldatei in die zugehörige Staging-Tabelle oder -Ansicht. Verwenden Sie die für Ihre Umgebung dokumentierten Zuordnungen der Quellobjekte und Attribute. Gehen Sie nicht davon aus, dass ein Public View Object dieselbe Struktur wie die zugrunde liegende Datenbanktabelle hat.
Vereinheitlichen Sie die Timestamps auf eine Zeitzone und wandeln Sie die Quell-Timestamps in einen einheitlichen Timestamp-Datentyp um. Bewahren Sie den Timestamp der Quellaktualisierung als LastDataUpdate auf. Benennen Sie Quellkennungen und Aktivitätsattribute entsprechend den Ausgabefeldern von ProcessMind um.
Führen Sie die folgende Abfrage aus, nachdem Sie alle Platzhalter durch die tatsächlichen Namen der Staging-Objekte und -Attribute ersetzt haben. Die Abfrage erstellt ausdrücklich eine Event-Log-Zeile für jede der zwölf erforderlichen Aktivitäten. Sie leitet keine Aktivitäten ab, die in den Quelldaten fehlen.
Prüfen Sie, ob JournalEntryId, ActivityName, EventTime, SourceSystem und LastDataUpdate für jede Ausgabezeile vorhanden sind. Kontrollieren Sie doppelte Ereignisse, die Reihenfolge der Timestamps, abgelehnte und erneut eingereichte Journalbuchungen, Stornierungsbeziehungen sowie Datensätze mit fehlenden optionalen Attributen.
Exportieren Sie das Ergebnis als Datei mit Trennzeichen oder in einem anderen von ProcessMind unterstützten Format. Verwenden Sie exakt die Spaltennamen JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount und RejectionReason. Laden Sie die Datei hoch und legen Sie JournalEntryId als Case-Kennung, ActivityName als Aktivität und EventTime als Ereignis-Timestamp fest.

Konfiguration

Richten Sie BICC für die Public View Objects des Hauptbuchs ein, die Journalüberschriften, Journalzeilen, Freigabe- oder Workflow-Verlauf, Anhänge, Buchungen, Abstimmungen und Stornierungsdaten enthalten. Prüfen Sie die genauen Objektnamen und Attribute im BICC-Katalog Ihrer Umgebung.
Beginnen Sie mit einer Extraktion über einen Zeitraum von drei bis sechs Monaten. Verlängern Sie den Zeitraum erst, wenn Sie Datenvolumen, Speicherkapazität, Extraktionsdauer und nachgelagerte Verarbeitungszeit geprüft haben.
Wenden Sie freigegebene Filter für Buchungsdatum oder Datum der letzten Aktualisierung, Hauptbuch, juristische Person, Geschäftseinheit, Buchungskreis (sofern verfügbar), Journal-Kategorie, Journalquelle, Belegart (sofern verfügbar) und Journalstatus an. Verwenden Sie nur Filter, die von den ausgewählten Public View Objects unterstützt werden.
Richten Sie die inkrementelle Extraktion anhand des Quellattributs für die letzte Aktualisierung und eines gespeicherten Wasserstands ein. Verwenden Sie bei Bedarf ein kurzes Überlappungsfenster, um verspätete Aktualisierungen zu berücksichtigen. Entfernen Sie anschließend Duplikate anhand von JournalEntryId, ActivityName, EventTime und der relevanten Quellereigniskennung.
Stellen Sie sicher, dass alle Quellobjekte kompatible Extraktionsschlüssel und Aktualisierungszeitpläne verwenden. Daten zu Freigaben, Anhängen, Buchungen, Abstimmungen und Stornierungen werden möglicherweise zu unterschiedlichen Zeitpunkten aktualisiert.
Teilen Sie große Datensätze nach Buchungszeitraum, Hauptbuch, juristischer Person oder einem anderen von BICC unterstützten Partitionsattribut auf. Vermeiden Sie uneingeschränkte Extraktionen historischer Daten während der Geschäftszeiten.
Bewahren Sie Quell-Timestamps und Timestamps der Quellaktualisierungen vor der Umwandlung auf. Dokumentieren Sie die für EventTime und LastDataUpdate verwendete Zeitzone.
Zu den Voraussetzungen gehören der Zugriff auf die BI-Cloud-Connector-Konsole, die Berechtigung zum Konfigurieren und Ausführen der ausgewählten Extraktionen, der Zugriff auf das eingerichtete Cloud-Speicherziel und die Staging-Umgebung sowie die Berechtigung, die erforderlichen Hauptbuch- und Workflow-Daten einzusehen.
Prüfen Sie, ob die erforderlichen Oracle-Fusion-Financials-Module, die Workflow-Konfiguration, der Anhangsspeicher, die Buchungsprozesse und die Datenquellen für Abstimmungen aktiviert sind, sofern diese Aktivitäten erfasst werden sollen.
Werten Sie einen fehlenden Quelldatensatz nicht als Beleg dafür, dass eine Aktivität nicht stattgefunden hat. Die BICC-Ausgabe hängt von den ausgewählten Public View Objects, Filtern, Aktualisierungszeitpunkten, Aufbewahrungsfristen und verfügbaren Verlaufsdaten ab.

a Beispielabfrage sql

WITH
journal_created AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Created' AS ActivityName,
        CAST([Journal Created Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Created By attribute] AS VARCHAR(255)) AS UserName,
        CAST([Created By Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal header staging object]
    WHERE [Journal Created Timestamp attribute] IS NOT NULL
),
supporting_documentation_attached AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Supporting Documentation Attached' AS ActivityName,
        CAST([Attachment Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Attachment User attribute] AS VARCHAR(255)) AS UserName,
        CAST([Attachment User Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal attachment staging object]
    WHERE [Attachment Timestamp attribute] IS NOT NULL
),
journal_submitted_for_approval AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Submitted For Approval' AS ActivityName,
        CAST([Submission Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Submitter attribute] AS VARCHAR(255)) AS UserName,
        CAST([Submitter Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal approval staging object]
    WHERE [Submission Timestamp attribute] IS NOT NULL
),
journal_entry_reviewed AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Reviewed' AS ActivityName,
        CAST([Review Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Reviewer attribute] AS VARCHAR(255)) AS UserName,
        CAST([Reviewer Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal review staging object]
    WHERE [Review Timestamp attribute] IS NOT NULL
),
journal_entry_rejected AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Rejected' AS ActivityName,
        CAST([Rejection Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Rejector attribute] AS VARCHAR(255)) AS UserName,
        CAST([Rejector Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST([Rejection Reason attribute] AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal rejection staging object]
    WHERE [Rejection Timestamp attribute] IS NOT NULL
),
journal_corrected_and_resubmitted AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Corrected and Resubmitted' AS ActivityName,
        CAST([Correction Resubmission Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Resubmitter attribute] AS VARCHAR(255)) AS UserName,
        CAST([Resubmitter Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST([Rejection Reason attribute] AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal resubmission staging object]
    WHERE [Correction Resubmission Timestamp attribute] IS NOT NULL
),
journal_entry_approved AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Approved' AS ActivityName,
        CAST([Approval Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Approver attribute] AS VARCHAR(255)) AS UserName,
        CAST([Approver Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal approval staging object]
    WHERE [Approval Timestamp attribute] IS NOT NULL
),
journal_posting_initiated AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Posting Initiated' AS ActivityName,
        CAST([Posting Initiated Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Posting Initiated By attribute] AS VARCHAR(255)) AS UserName,
        CAST([Posting Initiated By Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal posting staging object]
    WHERE [Posting Initiated Timestamp attribute] IS NOT NULL
),
journal_entry_posted AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Posted' AS ActivityName,
        CAST([Posted Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Posted By attribute] AS VARCHAR(255)) AS UserName,
        CAST([Posted By Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal posting staging object]
    WHERE [Posted Timestamp attribute] IS NOT NULL
),
posting_verified AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Posting Verified' AS ActivityName,
        CAST([Posting Verification Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Verifier attribute] AS VARCHAR(255)) AS UserName,
        CAST([Verifier Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Posting verification staging object]
    WHERE [Posting Verification Timestamp attribute] IS NOT NULL
),
journal_entry_reconciled AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Reconciled' AS ActivityName,
        CAST([Reconciliation Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Reconciled By attribute] AS VARCHAR(255)) AS UserName,
        CAST([Reconciled By Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal reconciliation staging object]
    WHERE [Reconciliation Timestamp attribute] IS NOT NULL
),
journal_reversal_processed AS (
    SELECT
        CAST([Original Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Reversal Processed' AS ActivityName,
        CAST([Reversal Posted Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Reversal User attribute] AS VARCHAR(255)) AS UserName,
        CAST([Reversal User Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Reversal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal reversal staging object]
    WHERE [Reversal Posted Timestamp attribute] IS NOT NULL
)
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_created
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM supporting_documentation_attached
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_submitted_for_approval
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_reviewed
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_rejected
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_corrected_and_resubmitted
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_approved
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_posting_initiated
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_posted
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM posting_verified
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_reconciled
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_reversal_processed
ORDER BY JournalEntryId, EventTime, ActivityName;

Möchten Sie loslegen?

Mit diesem Template wandeln Sie Ihre Oracle-Fusion-Daten zu Journalbuchungen in konkrete Erkenntnisse um und beschleunigen Ihren Record-to-Report-Zyklus. Beginnen Sie noch heute damit, Ihre Finanzabläufe zu optimieren.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Beschleunigen Sie noch heute Ihren Record-to-Report-Prozess für Journalbuchungen

Verkürzen Sie die Durchlaufzeit von Journalbuchungen um 30 % und vereinfachen Sie Ihre Finanzabläufe.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Aktivieren Sie jetzt Ihre Testphase.

Ihr Datentemplate für Record to Report, Journalbuchung

Ihr Datentemplate für Record to Report, Journalbuchung

Attribute für Record to Report, Journalbuchung

Aktivitäten für Record to Report, Journalbuchung

Anleitungen zur Datenextraktion

Oracle OTBI- und BI-Publisher-Berichtsexport

Schritte

Konfiguration

a Beispielabfrage sql

BI-Publisher-Bericht mit direkter SQL-Abfrage im Datenmodell

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der Oracle Fusion Financials REST API

Schritte

Konfiguration

a Beispielabfrage python

Massendatenextraktion mit dem BI Cloud Connector (BICC)

Schritte

Konfiguration

a Beispielabfrage sql

Möchten Sie loslegen?

Beschleunigen Sie noch heute Ihren Record-to-Report-Prozess für Journalbuchungen

Ihr Datentemplate für Record to Report, Journalbuchung

Ihr Datentemplate für Record to Report, Journalbuchung

Attribute für Record to Report, Journalbuchung

Aktivitäten für Record to Report, Journalbuchung

Anleitungen zur Datenextraktion

Oracle OTBI- und BI-Publisher-Berichtsexport

Schritte

Konfiguration

a Beispielabfrage sql

BI-Publisher-Bericht mit direkter SQL-Abfrage im Datenmodell

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript mit der Oracle Fusion Financials REST API

Schritte

Konfiguration

a Beispielabfrage python

Massendatenextraktion mit dem BI Cloud Connector (BICC)

Schritte

Konfiguration

a Beispielabfrage sql

Möchten Sie loslegen?

Beschleunigen Sie noch heute Ihren Record-to-Report-Prozess für Journalbuchungen

Der Schutz Ihrer Daten ist uns wichtig