> Kontinuierliche Prozessoptimierung > Datensatz to Report: Journaleintrag. > Oracle Fusion Financials > Datenvorlage

Ihre Datensatz-to-Report: Journaleintrag Daten-Vorlage.

Oracle Fusion Financials

Datensatz-to-Report: Journaleintrags-Attribute. (21) Datensatz-to-Report: Journaleintrags-Aktivitäten. (12) Extraktionsanleitungen (4)

Ihre Datensatz-to-Report: Journaleintrag Daten-Vorlage.

Dieses Daten-Template bietet einen vollständigen Leitfaden zur Extraktion und Strukturierung Ihrer Oracle Fusion Financials Journaleintragsdaten. Es skizziert die wesentlichen Attribute, die zu sammeln sind, und die Schlüsselaktivitäten, die zu verfolgen sind, um sicherzustellen, dass Sie alle notwendigen Informationen für eine leistungsstarke Prozessanalyse erfassen. Sie finden auch praktische Hinweise, wie Sie diese Daten direkt aus Ihrem System extrahieren können.

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten für das Tracking
Extraktionsanleitung für Oracle Fusion Financials

Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Vorlage herunterladen

Datensatz-to-Report: Journaleintrags-Attribute.

Dies sind die empfohlenen Datenfelder, die Sie in Ihrem Event Log für eine vollständige Analyse Ihres Datensatz-to-Report – Buchungserfassungsprozesses aufnehmen sollten.

5 Erforderlich 6 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivität ActivityName	Der Name des spezifischen Geschäfts-Ereignisse oder den Antrag bearbeitet.er Aufgabe, die zu einem bestimmten Zeitpunkt im Hauptbuch & Journalprozess stattfand.
Beschreibung Der Aktivitätenname beschreibt einen einzelnen Schritt innerhalb des Lebenszyklus eines Buchungseintrags, wie z. B. „Journal Entry Created“ oder „Journal Entry Approved“. Diese Daten sind wichtig für den Aufbau der Prozessablauf und das Verständnis der Ereignissequenz. Die Analyse von Aktivitäten ermöglicht die Identifizierung des Prozessflusses, einschließlich Standardpfade, Abweichungen und Nacharbeitszyklen. Durch die Verfolgung verschiedener Aktivitäten können wir die in bestimmten Phasen, z. B. der Genehmigung, verbrachte Zeit messen und identifizieren, welche Schritte am zeitaufwendigsten oder fehleranfälligsten sind. Bedeutung Es definiert die Schritte des Prozesses, ist die Basis der Prozessablauf und ermöglicht die Analyse von Fluss, Engpässen und Variationen. Datenquelle Dieses Attribut wird in der Regel aus Statusänderungen, Event-Logs oder Audit-Trail Tabellen abgeleitet, die mit Journal Entry Objekten im Hauptbuch-Modul verbunden sind. Beispiele Buchungsjournaleintrag erstelltHauptbuch & Journal zur Genehmigung eingereichtJournalbuchung genehmigtJournalbuchung gebucht
	Journalbuchungs-ID JournalEntryId	Die eindeutige Kennung für einen einzelnen Buchungseintrag, die alle zugehörigen Finanztransaktionsaktivitäten miteinander verknüpft.
Beschreibung Die Journaleintrags-ID dient als primärer Case-ID, der alle Aktivitäten, die mit einem spezifischen Satz von Finanztransaktionen zusammenhängen, eindeutig miteinander verknüpft. Dies ermöglicht die Verfolgung des vollständigen Lebenszyklus eines einzelnen Buchungseintrags, von der Initiierung bis zur endgültigen Buchung, wodurch sichergestellt wird, dass alle Soll- und Habenbuchungen erfasst werden. Im Process Mining ist diese ID unerlässlich, um den End-to-End-Verlauf jedes Buchungseintrags zu rekonstruieren. Sie verbindet disparate Ereignisse wie „Journal Entry Created“, „Journal Submitted For Approval“ und „Journal Entry Posted“ zu einem kohärenten Prozessfluss und ermöglicht die Analyse von Durchlaufzeiten, Engpässen und Prozessvariationen. Bedeutung Dies ist der grundlegende Schlüssel zur Verfolgung eines Buchungseintrags von Anfang bis Ende, der es ermöglicht, den gesamten Prozessfluss für jeden einzigartigen Case zu analysierenn. Datenquelle Dies ist ein Primärschlüssel, der in den Kern-Hauptbuchtabelle wie GL_JE_HEADERS und GL_JE_LINES zu finden ist. Beispiele JE100523JE202311001882019
	Startzeit EventTime	Der Zeitstempel, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung Dieser Zeitstempel markiert das genaue Datum und die Uhrzeit, zu der eine Aktivität ausgeführt wurde. Er ist das primäre zeitliche Element, das im Process Mining verwendet wird, um die Reihenfolge der Ereignisse zu bestimmen und Dauern zwischen ihnen zu berechnen. Die Genauigkeit der Event Time ist maßgeblich für alle zeitbasierten Analysen, einschließlich der Berechnung von Durchlaufzeiten, der Identifizierung von Engpässen und der Überwachung der Leistung im Vergleich zu Service Level Agreements. Sie liefert die chronologische Reihenfolge, die zur Rekonstruktion des tatsächlichen Prozessflusses erforderlich ist. Bedeutung Dieser Zeitstempel ist unerlässlich für die Anordnung von Ereignisse, die Berechnung aller Prozessdauern und die Durchführung jeder zeitbasierten Analyse. Datenquelle Diese Informationen werden in der Regel in Audit-Trail Tabellen oder als „Last Update Date“ oder „Creation Date“ in Transaktionstabellen wie GL_JE_HEADERS und GL_JE_LINES für spezifische Ereignisse gespeichert. Beispiele 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
	Letzte Datenaktualisierung LastDataUpdate	Der Zeitstempel der jüngsten Datenaktualisierung bzw. der letzten Extraktion aus dem Quellsystem.
Beschreibung Dieses Attribut erfasst, wann der Datensatz zuletzt aktualisiert wurde. Es bietet Kontext zur Aktualität der analysierten Daten, was wichtig ist, um die Relevanz der gewonnenen Erkenntnisse zu verstehen. In jeder Analyse, insbesondere in operativen Dashboards, ist die Kenntnis der Last Daten Update Zeit wichtig für Benutzer, um den Daten zu vertrauen und fundierte Entscheidungen zu treffen. Es kommuniziert klar den Stichtag für die im Process Mining Modell enthaltenen Daten. Bedeutung Zeigt die Aktualität der Daten an, was sicherstellt, dass Benutzer verstehen, wie aktuell die Prozessanalyse ist und den Erkenntnissen vertrauen können. Datenquelle Dieser Wert wird während des Datenextraktions- und Transformationsprozesses generiert und gespeichert. Es ist in der Regel der Zeitstempel, wann der ETL/ELT Job 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 identifiziert das Quellsystem, aus dem die ProzessDaten extrahiert wurden. In einer komplexen IT-Infrastruktur können Daten aus mehreren integrierten Systemen stammen, und dieses Feld hilft, sie zu unterscheiden. In der Prozessanalyse ist die Kenntnis des Quellsystems wichtig, um Prozessvariationen zu verstehen, die durch unterschiedliche Systemverhaltensweisen bedingt sein können. Es hilft auch bei der Datenvalidierung und Fehlerbehebung, indem Daten zu ihrem Ursprung zurückverfolgt werden können. Bedeutung Identifiziert den Ursprung der Daten, was wichtig ist für Daten-Governance, Validierung und das Verständnis von Prozessvariationen über verschiedene Systeme hinweg. Datenquelle Dies ist oft ein statischer Wert, der während der Datenextraktion konfiguriert wird, oder es könnte ein Feld in den Quelltabellen sein, das das Eingangssystem identifiziert. Beispiele Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Ablehnungsgrund RejectionReason	Eine textuelle Beschreibung oder ein Code, der erklärt, warum ein Journaleintrag abgelehnt wurde.
Beschreibung Wenn ein Buchungseintrag während des Genehmigungsprozesses abgelehnt wird, erfasst dieses Attribut den Grund für die Ablehnung. Dies kann ein vordefinierter Code oder ein Freitextkommentar des Genehmigers sein. Dies ist eines der wichtigsten Attribute für die Ursachenanalyse von Prozessineffizienzen. Durch die Analyse der häufigsten Ablehnungsgründe können Organisationen Verbesserungsbereiche identifizieren, wie z. B. bessere Schulungen für Ersteller, klarere Richtlinien oder Systemkontrollverbesserungen. Es unterstützt direkt das Dashboard „Journal Entry Rejection Rate Analysis“. Bedeutung Bietet direkten Einblick in die Ursachen von Nacharbeit und Prozessverzögerungen und ermöglicht gezielte Verbesserungen zur Reduzierung von Ablehnungsraten. Datenquelle Diese Informationen können in Workflow- oder Audit-Trail Tabellen, die mit dem Genehmigungsprozess verbunden sind, oder in einem Notizfeld im Journal-Header gespeichert werden. Beispiele Falsche KontenkombinationUnzureichende BelegdokumentationBudgetüberschreitung
	Benutzer UserName	Der Benutzer, der den Antrag bearbeitet.ie Aktivität ausgeführt hat, wie z. B. das Erstellen, Genehmigen oder Buchen des Buchungseintrags.
Beschreibung Dieses Attribut identifiziert den spezifischen Mitarbeiter oder Systembenutzer, der für die Ausführung einer Aktivität verantwortlich ist. Es ist maßgeblich für das Verständnis der Arbeitslastverteilung, der Leistung und der Identifizierung individueller Engpässe. In der Analyse ermöglicht BenutzerName das Filtern von Prozessen nach Benutzer, den Vergleich der Benutzereffizienz und die Untersuchung von Gründen für Verzögerungen oder Fehler. Es unterstützt direkt Dashboards wie „Benutzer Workload & Efficiency Across Teams“ und KPIs wie den „Benutzer Journal Bottleneck Index“. Bedeutung Zuweisung der Verantwortlichkeit für Prozessschritte, ermöglicht die Analyse der Benutzerarbeitslast, individuellen Leistung und des Schulungsbedarfs. Datenquelle Gefunden in Transaktionstabellen wie GL_JE_HEADERS (z.B. CREATED_BY, LAST_UPDATED_BY) und verwandten Audit-Trail-Tabellen. Beispiele john.doesusan.smithautoprocess_user
	Benutzerabteilung UserDepartment	Die Abteilung oder den Antrag bearbeitet.as Team, zu dem der Benutzer gehört, der den Antrag bearbeitet.ie Aktivität ausgeführt hat.
Beschreibung Dieses Attribut bietet organisatorischen Kontext, indem es eine Aktivität mit einer bestimmten Abteilung verknüpft, z. B. „Finanzen“, „Rechnungslegungsvorgänge“ oder „Interne Revision“. Es wird in der Regel aus BenutzerstammDaten abgeleitet. Die Analyse nach Benutzerabteilung hilft, abteilungsübergreifende Engpässe zu identifizieren, die Teamleistung zu vergleichen und zu verstehen, wie sich die Prozessausführung innerhalb der Organisation unterscheidet. Sie ist wertvoll für die Ressourcenallokation und gezielte Prozessoptimierungsinitiativen. Bedeutung Bietet organisatorischen Kontext, ermöglicht Leistungsanalysen nach Teams oder Abteilungen und deckt abteilungsübergreifende Ineffizienzen auf. Datenquelle Dies ist in der Regel nicht in den Transaktionstabellen enthalten. Es muss durch das Verknüpfen des BenutzerName mit einer BenutzerstammDatentabelle oder HR-SystemDaten bezogen werden. Beispiele HauptbuchhaltungFinanzberichterstattungKreditorenbuchhaltung
	Buchungskategorie JournalCategory	Die Kategorie des Buchungseintrags, z. B. „Abgrenzung“, „Anpassung“ oder „Umbuchung“.
Beschreibung Die Journal-Kategorie klassifiziert Einträge basierend auf ihrem Geschäftszweck. Diese Klassifizierung ermöglicht eine detailliertere Analyse des Prozesses, da verschiedene Kategorien unterschiedliche Prozessabläufe, Genehmigungsregeln oder Durchlaufzeiten haben können. Zum Beispiel könnten Monatsabschluss-Anpassungsjournale einen komplexeren und dringenderen Prozess haben als routinemäßige Abgrenzungen. Die Analyse des Prozesses nach Kategorie hilft, diese Variationen aufzudecken und Verbesserungen an spezifische Arten von Journaleinträgen anzupassen. Bedeutung Ermöglicht die Segmentierung des Prozesses nach dem Geschäftszweck des Journals, wodurch unterschiedliche Verhaltensweisen und Leistungen für verschiedene Eintragstypen aufgedeckt werden. Datenquelle Verfügbar in der Tabelle GL_JE_HEADERS, in der Regel in einem Feld namens JE_CATEGORY. Beispiele AbgrenzungManuellAnpassungNeubewertung
	Buchungsquelle JournalSource	Das Nebenbuch oder den Antrag bearbeitet.ie Quelle, die den Buchungseintrag generiert hat, z. B. „Kreditoren“, „Forderungen“ oder „Manuell“.
Beschreibung Dieses Attribut gibt den Ursprung des Buchungseintrags innerhalb des ERP-Systems an. Einträge können manuell im Hauptbuch erstellt oder automatisch aus Nebenbüchern wie Kreditoren, Forderungen oder Anlagevermögen generiert werden. Journal Source ist ein Schlüsselattribut für die Automatisierungsanalyse. Es hilft, zwischen manuellen und systemgenerierten Einträgen zu unterscheiden und unterstützt die KPI „Automated Journal Entry Rate“. Prozesse für Einträge aus verschiedenen Quellen variieren oft erheblich in Bezug auf Komplexität und Effizienz. Bedeutung Unterscheidet zwischen manuellen und automatisierten Einträgen, was wichtig ist für die Messung von Automatisierungsraten und die Analyse von Prozessunterschieden. Datenquelle Verfügbar in der Tabelle GL_JE_HEADERS, in der Regel in einem Feld namens JE_SOURCE. Beispiele ManuellVerbindlichkeitenAnlagenForderungen
	Journalbetrag JournalAmount	Der gesamte Geldwert des Journaleintrags, in der Regel die Summe der Sollbeträge.
Beschreibung Dieses Attribut repräsentiert den gesamten finanziellen Wert, der im Buchungseintrag transaktiert wird. Der Betrag kann ein signifikanter Faktor sein, der den Antrag bearbeitet.en Prozess beeinflusst. Zum Beispiel könnten hochvolumige Einträge zusätzliche Genehmigungsschritte oder gründlichere Überprüfungen erfordern. Die Analyse des Journal Amount ermöglicht die Segmentierung von Fällen nach finanziellen Auswirkungen. Sie hilft, Fragen zu beantworten wie: „Dauert die Genehmigung von hochvolumigen Einträgen länger?“ oder „Sind Ablehnungen bei Einträgen über einem bestimmten Schwellenwert häufiger?“. Dies liefert wichtigen Geschäftskontext für den Prozessfluss. Bedeutung Bietet kritischen Geschäftskontext, ermöglicht eine Analyse basierend auf finanziellen Auswirkungen und hilft zu erkennen, ob hochvolumige Buchungseinträge einem anderen Prozess folgen. Datenquelle Dieser Wert wird in der Regel als Summe der Soll- oder Habenbuchungen aus der GL_JE_LINES Tabelle für einen gegebenen Buchungseintrag berechnet. Beispiele 5000.00125000.75750.50
	Buchhaltungsperiode AccountingPeriod	Die Fiskalperiode, in der den Antrag bearbeitet.er Buchungseintrag gebucht wird, z. B. „Jan-24“.
Beschreibung Die Rechnungsperiode gibt den Finanzzeitraum an, in dem die Transaktion erfasst wird. Dies ist die Basis für die gesamte Finanzberichterstattung und -analyse. Im Process Mining ist dieses Attribut wichtig für die Trendanalyse. Es ermöglicht den Vergleich der Prozessleistung, wie z. B. Durchlaufzeiten oder Ablehnungsraten, über verschiedene Monate oder Quartale hinweg. Dies hilft bei der Identifizierung von Saisonalitätseffekten, wie z. B. erhöhter Arbeitslast beim Monatsabschluss, und bei der Messung der Auswirkungen von Prozessoptimierungen im Laufe der Zeit. Bedeutung Ermöglicht die Trendanalyse von KPIs im Zeitverlauf, hilft, Prozessoptimierungen zu messen und saisonale Muster wie Monatsenddruck zu identifizieren. Datenquelle Verfügbar in der Tabelle GL_JE_HEADERS, in der Regel in einem Feld namens PERIOD_NAME. Beispiele Jan-24Feb-24Mrz-24
	Buchungsstatus PostingStatus	Der aktuelle Buchungsstatus des Buchungseintrags, z. B. „Ungepostet“ oder „Gebucht“.
Beschreibung Dieses Attribut spiegelt den aktuellen Zustand des Buchungseintrags bezüglich seiner Buchung im Hauptbuch wider. Es ist ein Schlüsselindikator dafür, wo sich ein Buchungseintrag in seinem Lebenszyklus befindet, insbesondere für laufende Fälle. Der Buchungsstatus (Posting Status) ist maßgeblich für das Dashboard „Real-Time Journal Entry Status Tracker“, das eine Momentaufnahme aller aktiven Einträge liefert. Er hilft bei der Überwachung von Rückständen ungeposteter Journale und der Identifizierung von Verzögerungen in den letzten Phasen des Prozesses. Bedeutung Gibt den aktuellen Status eines Journals an, was für die Überwachung von Rückständen und die Verfolgung des Status laufender Einträge notwendig ist. Datenquelle Verfügbar in der Tabelle GL_JE_HEADERS, in der Regel in einer Spalte wie STATUS oder POSTING_STATUS. Beispiele GebuchtUngepostetFehler
	End-to-End Zykluszeit EndToEndCycleTime	Die gesamte berechnete Dauer von der Erstellung eines Buchungseintrags bis zu seiner endgültigen Abstimmung.
Beschreibung Diese Metrik repräsentiert die Gesamtzeit, die ein Buchungseintrag im gesamten Prozess verbringt, vom allerersten Event „Journal Entry Created“ bis zum letzten Event „Journal Entry Reconciled“. Sie bietet eine vollständige Sicht auf die Prozessleistung. Dies ist eine primäre KPI zur Messung der Gesamtprozesseffizienz. Sie wird in Trend-Dashboards verwendet, um die Auswirkungen von Verbesserungsinitiativen im Laufe der Zeit zu verfolgen und eine Basislinie zu liefern, anhand derer alle Prozessänderungen gemessen werden können. Bedeutung Liefert ein übergeordnetes Maß für die Gesundheit und Effizienz des gesamten Prozesses und ist somit eine Schlüsselkennzahl für das Management-Reporting. Datenquelle Diese Metrik wird von der Process-Mining-Plattform als Zeitdifferenz zwischen dem ersten und letzten Event Zeitstempel für jeden Case berechnet. Beispiele P10DT5HP4DT12HP22D
	Endzeit EndTime	Der Zeitstempel, der angibt, wann eine bestimmte Aktivität abgeschlossen wurde.
Beschreibung Die End Time markiert den Abschluss einer Aktivität. Während die Start Time den Beginn protokolliert, liefert die End Time den Endpunkt, was eine präzise Berechnung der Bearbeitungszeit für diesen spezifischen Schritt ermöglicht. Dies ist unerlässlich für die Berechnung von Aktivitätsbearbeitungszeiten, die eine zentrale Kennzahl zur Identifizierung von Engpässen und zur Messung der Ressourceneffizienz ist. Zum Beispiel ergibt die Differenz zwischen der End Time und der Start Time der Aktivität „Journal Entry Reviewed“ die tatsächliche Zeit, die ein Prüfer für die Aufgabe aufgewendet hat. Bedeutung Es ermöglicht die Berechnung der tatsächlichen Dauer oder Bearbeitungszeit einzelner Aktivitäten, was wichtig ist für die Identifizierung von Effizienzproblemen. Datenquelle Ähnlich wie die Start Time findet sich dies oft in Audit-Trail-Tabellen oder kann aus der Start Time der nachfolgenden Aktivität im Prozess abgeleitet werden. Beispiele 2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
	Hauptbuchname LedgerName	Der Name des Hauptbuchs, in dem der Buchungseintrag erfasst wird.
Beschreibung Der Ledger Name identifiziert das spezifische Ledger, zu dem der Buchungseintrag gehört. In Organisationen mit mehreren Rechtseinheiten oder Berichtsanforderungen kann es mehrere Ledger geben, z. B. ein Primär-Ledger für die Konzernbuchhaltung und Sekundär-Ledger für die lokale gesetzliche Berichterstattung. Dieses Attribut ist unerlässlich für das Filtern und Vergleichen von Prozessen über verschiedene Rechtseinheiten oder Geschäftsbereiche hinweg. Es stellt sicher, dass Analysen im richtigen organisatorischen Kontext durchgeführt werden, was besonders wichtig für die Finanz-Compliance und Berichterstattung ist. Bedeutung Ermöglicht die Filterung und den Vergleich der Prozessanalyse über verschiedene juristische Einheiten oder Rechnungslegungsrahmen hinweg, was für große Unternehmen wichtig ist. Datenquelle Gefunden in der Tabelle GL_JE_HEADERS, in der Regel verknüpft über eine LEDGER_ID, die mit GL_LEDGERS verbunden werden kann, um den Namen zu erhalten. Beispiele US Primär-LedgerUK Gesetzliches LedgerGlobal Consolidation Ledger
	Ist Nacharbeit IsRework	Ein berechnetes Flag, das zutrifft, wenn der Journaleintrag einen Ablehnungs- und Korrekturzyklus durchlaufen hat.
Beschreibung Dieses boolesche Attribut wird berechnet, um Fälle zu identifizieren, die Nacharbeit erfahren haben. Es wird in der Regel als „Ja“ markiert für jede Aktivität, die einem „Journal Entry Rejected“-Event folgt, wie z. B. „Journal Corrected and Resubmitted“. „Is Rework“ ist ein leistungsstarkes Attribut für die Analyse, da es eine einfache Quantifizierung des Volumens und der Auswirkungen von Nacharbeitsschleifen ermöglicht. Es unterstützt direkt die KPI „Average Journal Rework Rate“ und hilft beim Vergleich des Prozessflusses und der Dauer von überarbeiteten Fällen im Vergleich zu jenen, die beim ersten Mal korrekt verarbeitet werden. Bedeutung Kennzeichnet direkt Fälle, die ineffiziente Nachbearbeitungsschleifen durchlaufen haben, wodurch die Häufigkeit und Auswirkungen von Prozessfehlern leicht quantifiziert werden können. Datenquelle Dies ist im Quellsystem nicht verfügbar. Es wird innerhalb des Process-Mining-Tools berechnet, indem die Abfolge der Aktivitäten für jeden Case analysiert wird. Beispiele JaNein
	Ist pünktliche Buchung IsOnTimePosting	Ein berechnetes Flag, das zutrifft, wenn das Journal am oder vor seinem Zieldatum gebucht wurde.
Beschreibung Dieses boolesche Attribut wird abgeleitet, indem der Zeitstempel der Aktivität „Journal Entry Posted“ mit dem „Target Posting Date“ verglichen wird. Erfolgt die Buchung am oder vor dem Zieltermin, ist der Wert „Ja“; anderthalb ist er „false“. Dieses Attribut unterstützt direkt die KPI „On-Time Journal Posting Rate“, indem es die Berechnung vereinfacht. Es ermöglicht ein einfaches Filtern und Analysieren verspäteter Einträge, um häufige Ursachen für Verzögerungen zu identifizieren, wie z. B. spezifische Journal-Kategorien oder Genehmiger. Bedeutung Bietet ein klares, binäres Ergebnis für die Buchungsleistung, was die Analyse von pünktlichen Raten und den Ursachen von Verzögerungen vereinfacht. Datenquelle Dieses Attribut wird vom Process-Mining-Tool berechnet. Es erfordert das Attribut „TargetPostingDate“ und den Zeitstempel der Aktivität „Journal Entry Posted“. Beispiele JaNein
	Stornierungsindikator ReversalIndicator	Ein Flag, das anzeigt, ob der Journaleintrag eine Stornierung eines anderen Eintrags ist.
Beschreibung Dieses boolesche Attribut identifiziert Buchungseinträge, die zur Stornierung eines zuvor gebuchten Eintrags erstellt wurden. Stornierungen sind eine spezifische Art von Buchungseinträgen, die oft einem eigenen, manchmal problematischen Prozess folgen. Die Analyse dieses Indikators ist maßgeblich für die Unterstützung des Dashboards „Journal Reversal Process Leistungsfähigkeit“. Sie ermöglicht es, Stornierungsprozesse zu isolieren, um deren Häufigkeit, Ursachen und Durchlaufzeiten zu messen und so zugrunde liegende Probleme in den ursprünglichen Einträgen zu identifizieren, die eine Stornierung erforderlich machen. Bedeutung Hilft, den Stornierungsprozess zu isolieren und zu analysierenn, der oft ein Indikator für Fehler oder Probleme in der ursprünglichen Transaktion ist. Datenquelle Dies kann ein spezifisches Flag in der GL_JE_HEADERS Tabelle sein, wie ACCRUAL_REV_FLAG, oder den Antrag bearbeitet.urch Verknüpfungen mit dem ursprünglich stornierten Journal identifiziert werden. Beispiele JaNein
	Währung CurrencyCode	Der Währungscode für den Betrag des Buchungseintrags, wie USD, EUR oder GBP.
Beschreibung Der Währungscode gibt die Währung der Finanzbeträge im Buchungseintrag an. Dies ist unerlässlich für multinationale Organisationen, die in mehreren Währungen Transaktionen durchführen. Dieses Attribut stellt sicher, dass Finanzwerte korrekt interpretiert werden. Es ermöglicht das Filtern nach Währung und ist ein notwendiges Feld bei der Durchführung jeder Analyse, die den Vergleich oder den Antrag bearbeitet.ie Aggregation von Geldbeträgen über verschiedene Regionen hinweg beinhaltet. Bedeutung Liefert den notwendigen Kontext für alle Finanzbeträge, um eine genaue Interpretation zu sicherstellen und Analysen spezifisch für verschiedene Währungen zu ermöglichen. Datenquelle Verfügbar in der Tabelle GL_JE_HEADERS, in der Regel in einem Feld namens CURRENCY_CODE. Beispiele USDEURGBPJPY
	Zielbuchungsdatum TargetPostingDate	Das vorab festgelegte Datum, bis zu dem der Buchungseintrag gebucht werden soll.
Beschreibung Das Zielbuchungsdatum (Target Posting Date) stellt die Frist für die Buchung eines Journal Entrys im Hauptbuch dar, die oft durch Service Level Agreements (SLAs) oder Monatsabschlusspläne festgelegt wird. Es dient als Benchmark zur Leistungsmessung. Dieses Attribut ist unerlässlich für die Berechnung der KPI „On-Time Journal Posting Rate“. Durch den Vergleich des tatsächlichen Buchungsdatums mit diesem Ziel kann das System Einträge automatisch als pünktlich oder verspätet kennzeichnen und somit ein klares Maß für die Prozesseinhaltung von Zeitplänen liefern. Bedeutung Definiert das Service Level Agreement oder den Antrag bearbeitet.ie Frist für die Buchung, was die Berechnung von KPIs zur pünktlichen Leistung ermöglicht. Datenquelle Dies ist möglicherweise kein Standardfeld. Es könnte aus Geschäftsregeln abgeleitet werden, basierend auf dem Erstellungsdatum, der Rechnungsperiode oder den Antrag bearbeitet.er Journal-Kategorie. Beispiele 2023-10-312023-11-302024-01-05

Erforderlich Empfohlen Optional

Datensatz-to-Report: Journaleintrags-Aktivitäten.

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie in Ihrem Event Log für eine genaue Prozesserkennung in der Buchungserfassung erfassen sollten.

5 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Buchungsjournaleintrag erstellt	Diese Aktivität markiert die Initiierung des Buchungserfassungsprozesses. Sie repräsentiert den Moment, in dem ein Benutzer einen neuen Journal-Header erstellt und mit der Dateneingabe beginnt, jedoch bevor er zur Überprüfung oder Genehmigung eingereicht wird.
Bedeutung Dies ist das primäre Start-Event für den Prozess. Die Analyse der Zeit von dieser Aktivität bis zu nachfolgenden Schritten hilft, die anfängliche Dateneingabeeffizienz und die gesamte Prozess-Durchlaufzeit zu messen. Datenquelle Dieses Event wird in der Regel aus dem Erstellungsdatum-Zeitstempel in der GL_JE_HEADERS Tabelle für eine spezifische Journaleintrags-ID abgeleitet. Der Benutzer, der den Antrag bearbeitet.en Datensatz erstellt hat, ist ebenfalls in dieser Tabelle verfügbar. Erfassen Verwenden Sie das CREATION_DATE aus der GL_JE_HEADERS Tabelle. Ereignistyp inferred
	Hauptbuch & Journal zur Genehmigung eingereicht	Diese Aktivität tritt auf, wenn der Benutzer den vollständigen Buchungseintrag formell in den Genehmigungs-Workflow einreicht. Sie überführt das Journal von einem Entwurfs- oder unvollständigen Status in den Status „zur Genehmigung ausstehende Zahlungen identifizieren.end“.
Bedeutung Dies ist ein kritischer Meilenstein, der den Antrag bearbeitet.en Startpunkt für die Messung von Genehmigungs-Durchlaufzeiten und die Identifizierung von Engpässen darstellt. Er trennt die Datenerfassungsphase von der Überprüfungs- und Genehmigungsphase. Datenquelle Dieses Event wird aus einer Statusänderung in der GL_JE_HEADERS Tabelle abgeleitet, insbesondere wenn der APPROVAL_STATUS_CODE zu einem Wert wie „REQUIRED“ oder „INITIATED“ wechselt. Der Einreichungsdatum-Zeitstempel kann ebenfalls erfasst werden. Erfassen Verfolgen Sie den Zeitstempel, wenn der APPROVAL_STATUS_CODE in GL_JE_HEADERS eine Einreichung anzeigt. Ereignistyp inferred
	Journalbuchung abgestimmt	Der Buchungseintrag wurde im Rahmen eines Periodenabschluss-Abstimmungsprozesses abgeglichen und geklärt. Dies bestätigt, dass die Transaktion mit anderen FinanzDaten, wie z. B. Kontoauszügen, übereinstimmt.
Bedeutung Diese Aktivität dient als echter Endpunkt für den Lebenszyklus des Journals. Die Messung der Zeit von der Buchung bis zur Abstimmung ist eine Schlüssel-KPI zur Bewertung der Effizienz des Finanzabschlussprozesses. Datenquelle Dieses Event wird in der Regel im Oracle Financial Consolidation and Close Cloud Service (FCCS) oder Account Reconciliation Cloud Service (ARCS) erfasst, nicht im Hauptbuch selbst. Es wird aus einer Statusänderung im AbstimmungsDatensatz abgeleitet, der mit dem Journal verknüpft ist. Erfassen JournalDaten mit Abgleichsstatus-Updates aus ARCS- oder FCCS-Tabellen korrelieren. Ereignistyp inferred
	Journalbuchung gebucht	Die FinanzDaten des Buchungseintrags wurden erfolgreich im Hauptbuch erfasst. Die Soll- und Habenbuchungen spiegeln sich nun in den Kontensalden wider.
Bedeutung Dies ist ein kritischer Meilenstein, der den Antrag bearbeitet.en Eintrag des Journals in die offizielle Finanzbuchhaltung darstellt. Es ist unerlässlich für die Messung der pünktlichen Buchungsrate und der Gesamtzeit von der Erstellung bis zur Buchung. Datenquelle Dies wird aus einer Statusänderung in der GL_JE_HEADERS Tabelle abgeleitet, wobei das STATUS-Feld auf „P“ (Posted) wechselt. Die GL_JE_BATCHES Tabelle hat ebenfalls einen Buchungsstatus. Erfassen Verfolgen Sie den Zeitstempel, wenn der STATUS in GL_JE_HEADERS auf „P“ wechselt. Ereignistyp inferred
	Journalbuchung genehmigt	Der designierte Genehmiger hat den Buchungseintrag formell genehmigt und dessen Richtigkeit und Gültigkeit bestätigt. Dies ist der letzte Schritt im Genehmigungs-Workflow, der den Antrag bearbeitet.en Weg für die Buchung freimacht.
Bedeutung Dieser Meilenstein markiert das Ende des Genehmigungsprozesses. Die Zeit zwischen Einreichung und Genehmigung ist eine Schlüssel-KPI zur Messung der Workflow-Effizienz und zur Identifizierung von Genehmigungsengpässen. Datenquelle Dieses Event wird aus einer Statusänderung in der GL_JE_HEADERS Tabelle abgeleitet, wobei der APPROVAL_STATUS_CODE auf „APPROVED“ aktualisiert wird. Workflow-Tabellen enthalten die Identität des Genehmigers und den Zeitstempel. Erfassen Verfolgen Sie den Zeitstempel, wenn der APPROVAL_STATUS_CODE in GL_JE_HEADERS auf „APPROVED“ wechselt. Ereignistyp inferred
	Begleitdokumentation angehängt.	Stellt die Aktion dar, unterstützende Dokumente wie Rechnungen oder Tabellenkalkulationen an den Buchungseintrag anzuhängen. Dies wird oft getan, um Prüfern und Genehmigern Kontext und Belege zu liefern.
Bedeutung Die Verfolgung dieser Aktivität hilft zu verstehen, ob Verzögerungen durch fehlende Dokumentation verursacht werden. Sie liefert auch Einblicke in die Compliance und die Vollständigkeit von Buchungseinträgen, bevor sie in den Genehmigungs-Workflow eintreten. Datenquelle Dies kann als diskretes Event schwer nachzuverfolgen sein. Es könnte aus Zeitstempels in Anhangstabellen wie FND_ATTACHED_DOCUMENTS abgeleitet werden, die mit dem Buchungseintrag in GL_JE_HEADERS verknüpft sind. Erfassen Ableiten aus dem Erstellungsdatum von Datensätzen in FND_ATTACHED_DOCUMENTS, die mit dem Journal verknüpft sind. Ereignistyp inferred
	Buchung verifiziert.	Ein Verifizierungsschritt nach der Buchung, bei dem ein Benutzer oder System bestätigt, dass das Journal korrekt gebucht wurde und die Salden wie erwartet sind. Dies ist oft ein manueller Kontrollschritt.
Bedeutung Die Analyse dieser Aktivität hilft, die aufgewendete Zeit für manuelle Kontrollen und Qualitätssicherung nach der Buchung zu verstehen. Sie kann Möglichkeiten zur Automatisierung von Verifizierungsprozessen hervorheben. Datenquelle Es ist unwahrscheinlich, dass dies ein explizites Event in Oracle Fusion ist. Es müsste aus anderen Aktionen abgeleitet werden, z. B. wenn ein Benutzer einen spezifischen Bericht ausführt oder ein benutzerdefiniertes Statusfeld aktualisiert wird, was nicht Standard ist. Erfassen Erfordert benutzerdefinierte Logik, wie z. B. die Verfolgung der Laufzeit von Verifizierungsberichten oder Aktualisierungen eines beschreibenden Flexfields. Ereignistyp inferred
	Journal korrigiert und erneut eingereicht	Nachdem ein Journaleintrag abgelehnt wurde, nimmt der Ersteller die notwendigen Korrekturen vor und reicht ihn zur Genehmigung erneut ein. Diese Aktivität stellt den Beginn eines neuen Genehmigungszyklus für dasselbe Journal dar.
Bedeutung Die Verfolgung von Nacharbeit ist unerlässlich, um Prozesseffizienz zu verstehen. Diese Aktivität, kombiniert mit „Journal Entry Rejected“, ermöglicht die Messung von Nacharbeitszeit und -häufigkeit. Datenquelle Dies ist ein nachfolgendes „Journal Submitted For Approval“-Event für ein Journal, das zuvor im Status „REJECTED“ war. Es wird durch die Analyse der Abfolge von Statusänderungen für eine einzelne Journaleintrags-ID identifiziert. Erfassen Identifizieren Sie einen Übermittlungsereignis-Zeitstempel, der nach einem Ablehnungsereignis für dieselbe Fall-ID auftritt. Ereignistyp inferred
	Journalbuchung abgelehnt	Ein Genehmiger hat den Journaleintrag geprüft und ihn aufgrund von Fehlern, fehlender Dokumentation oder Richtlinienverstößen abgelehnt. Diese Aktion sendet das Journal zur Korrektur an den Ersteller zurück.
Bedeutung Diese Aktivität ist maßgeblich für die Analyse von Nacharbeitsschleifen, Ablehnungsraten und „First-Time-Right“-Metriken. Eine hohe Häufigkeit von Ablehnungen weist auf Probleme mit der Datenqualität oder Schulung hin. Datenquelle Dies wird aus einer Statusänderung in der GL_JE_HEADERS Tabelle abgeleitet, wenn der APPROVAL_STATUS_CODE auf „REJECTED“ aktualisiert wird. Der Workflow-Verlauf protokolliert den Benutzer und den Zeitstempel für diese Aktion. Erfassen Verfolgen Sie den Zeitstempel, wenn der APPROVAL_STATUS_CODE in GL_JE_HEADERS auf „REJECTED“ gesetzt wird. Ereignistyp inferred
	Journalbuchung initiiert	Der Prozess der Buchung des genehmigten Journals im Hauptbuch wurde gestartet. Dies kann ein automatischer oder manueller Schritt sein, der den Antrag bearbeitet.as Journal zur Verarbeitung durch das Buchungsprogramm in die Warteschlange stellt.
Bedeutung Diese Aktivität trennt die Genehmigung vom technischen Buchungsprozess. Verzögerungen zwischen Genehmigung und Buchungsinitiierung können auf Terminierungsprobleme oder Ressourcenengpässe in der Buchungs-Engine hinweisen. Datenquelle Dies kann aus Statusänderungen in der GL_JE_BATCHES Tabelle oder anhand der Einreichungszeit des mit dem Journal-Batch verbundenen Posting Concurrent Requests abgeleitet werden. Erfassen Identifizieren Sie die Anforderungsübermittlungszeit für das Hauptbuchbuchungsprogramm für den spezifischen Journalstapel. Ereignistyp inferred
	Journalbuchung überprüft	Ein Prüfschritt, der vor oder als Teil des formellen Genehmigungsprozesses erfolgen kann. Dies stellt eine Überprüfung durch einen Kollegen oder Vorgesetzten dar, um die Genauigkeit und Compliance sicherzustellen, bevor der Eintrag an den endgültigen Genehmiger weitergeleitet wird.
Bedeutung Die Isolierung dieser Aktivität hilft, zwischen vorläufigen Überprüfungszeiten und endgültigen Genehmigungszeiten zu unterscheiden. Es kann verborgene Engpässe aufdecken, wenn die Überprüfungsphase Hinweisrmell, aber zeitaufwändig ist. Datenquelle Dies kann ein expliziter Schritt in einem mehrstufigen Genehmigungs-Workflow sein, der in Workflow-Verlaufntabellen erfasst wird. Wenn Hinweisrmell, wird er nicht erfasst. Er kann abgeleitet werden, wenn eine spezifische Benutzeraktion vor der endgültigen Genehmigungsentscheidung protokolliert wird. Erfassen Workflow-Verlaufntabellen nach internen Genehmigungs- oder Überprüfungsschritten vor dem endgültigen Status 'Genehmigt' analysierenn. Ereignistyp inferred
	Journalstornierung verarbeitet	Ein Stornierungs-Journaleintrag wurde erstellt und gebucht, um die finanziellen Auswirkungen des Originaljournals in einer nachfolgenden Periode aufzuheben. Dies ist eine häufige Maßnahme bei Abgrenzungen.
Bedeutung Die Verfolgung von Stornierungen hilft, Arten von Einträgen zu identifizieren, die häufig storniert werden, und die Effizienz des Stornierungsprozesses selbst zu analysierenn. Dies kann auf Probleme im Abgrenzungsmanagement hinweisen. Datenquelle Dies wird durch die Identifizierung eines neuen Buchungseintrags abgeleitet, der explizit mit dem Original als dessen Stornierung verknüpft ist. Die GL_JE_HEADERS Tabelle enthält Felder wie REVERSAL_PERIOD und REVERSAL_FLAG, um diese Einträge zu identifizieren und zu verknüpfen. Erfassen Identifizieren Sie das Erstellungs- und Buchungsdatum des neuen Journals, dessen Header den Antrag bearbeitet.as Originaljournal als storniert referenziert. Ereignistyp inferred

Extraktionsanleitungen

So erhalten Sie Ihre Daten aus Oracle Fusion Financials

Schritte

Zum Arbeitsbereich Berichte und Analysen bewältigen: Melden Sie sich bei Oracle Fusion Financials an. Verwenden Sie das Navigator-Menü, um zu Tools zu gehen, und wählen Sie dann Reports and Analysen. Dies ist die zentrale Anlaufstelle für die Erstellung und Verwaltung aller Analysen und Berichte.
Ein BI Publisher-Datenmodell erstellen: Anstatt mit einer OTBI-Analyse zu beginnen, ist es für diese Art der Event Log-Extraktion effektiver, direkt ein BI Publisher-Datenmodell zu erstellen. Dies ermöglicht die Verwendung einer benutzerdefinierten SQL-Abfrage mit UNION ALL-Anweisungen. Klicken Sie auf die Schaltfläche 'Katalog durchsuchen', bewältigen Sie zu einem geeigneten Ordner und wählen Sie Erstellen > Datenmodell.
Den SQL-Abfrage-Datensatz definieren: Klicken Sie im Datenmodell-Editor auf das '+' Symbol, um einen neuen Datensatz hinzuzufügen, und wählen Sie 'SQL Query'. Geben Sie dem Datensatz einen beschreibenden Namen, z.B. 'JournalEventLog'.
Die SQL-Abfrage eingeben: Wählen Sie 'Oracle BI EE' als Datenquelle. Kopieren Sie das vollständige SQL-Skript aus dem Abschnitt 'Query' unten und fügen Sie es in den SQL Query-Textbereich ein. Die Abfrage ist so konzipiert, dass sie alle erforderlichen Aktivitäten und Attribute in einer einzigen, einheitlichen Struktur zusammenführt.
Parameter definieren: Die bereitgestellte Abfrage verwendet Parameter wie :start_date, :end_date und :ledger_name. Die Datenmodell-Oberfläche erkennt diese automatisch. Sie müssen sie als Parameter konfigurieren und entsprechende Datentypen (Datum oder Text) sowie bei Bedarf Standardwerte festlegen. Dies ermöglicht eine flexible Berichtsausführung.
Einen Bericht aus dem Datenmodell erstellen: Nachdem Sie das Datenmodell gespeichert haben, bewältigen Sie zurück zum Katalog. Klicken Sie auf Erstellen > Bericht. Wählen Sie im Berichtserstellungsassistenten 'Bestehendes Datenmodell verwenden' und suchen Sie das soeben erstellte Datenmodell.
Das Berichtslayout konfigurieren: Wählen Sie im Layout-Editor das 'Tabellen'-Layout. Es ist maßgeblich, alle Spalten aus dem Datenmodell in die Tabelle zu ziehen und abzulegen, um sicherzustellen, dass sie im Export enthalten sind. Es ist keine komplexe Formatierung erforderlich.
Standardausgabe auf CSV festlegen: Gehen Sie zum Link 'Listee anzeigen' im Berichts-Editor. Stellen Sie im Abschnitt 'Ausgabeformate' sicher, dass 'CSV' ausgewählt ist. Es wird empfohlen, alle anderen Formate zu deaktivieren, um die Planung zu vereinfachen. Speichern Sie den Bericht.
Den Bericht für die automatisierte Extraktion planen: Suchen Sie Ihren gespeicherten Bericht im Katalog und klicken Sie auf 'Mehr' und dann auf 'Planen'. Erstellen Sie einen neuen Planungsauftrag. Konfigurieren Sie die Häufigkeit, z.B. täglich oder wöchentlich.
Export und Zustellung konfigurieren: Geben Sie auf der Registerkarte 'Output' des Planungsauftrags die Ausgabedetails an. Wählen Sie Ihren Bericht und 'CSV' als Format. Auf der Registerkarte 'Destination' können Sie die Zustellung der Datei an einen Content-Server-Speicherort (UCM) oder einen externen SFTP-Server für den automatisierten Abruf konfigurieren.
Daten abrufen und vorbereiten: Sobald der geplante Auftrag ausgeführt wurde, rufen Sie die generierte CSV-Datei von Ihrem konfigurierten Ziel ab. Stellen Sie sicher, dass die Spaltenüberschriften den Anforderungen für die ProcessMind-Aufnahme entsprechen: JournalEntryId, ActivityName, Ereigniszeitpunkt (Event Time), (SourceSystem), LastDatenUpdate, BenutzerName, usw. Die Datei ist nun bereit für den Upload.

Konfiguration

Datenquelle: Die Abfrage sollte gegen die Datenquelle 'Oracle BI EE' innerhalb von BI Publisher ausgeführt werden, die sich mit den zugrunde liegenden transaktionalen Datenbankansichten verbindet, welche OTBI unterstützen.
Schlüsselthemenbereiche (als Referenz): Die Abfragelogik basiert auf Daten, die hauptsächlich im Themenbereich 'General Ledger – Journals Real Time' zu finden sind. Sie verknüpft auch logisch Daten, die in 'HCM – Workforce Management – Worker Assignment Real Time' für Benutzerdetails und potenziell Workflow-Themenbereiche für die Genehmigungshistorie zu finden wären.
Datumsbereichsfilterung: Es ist maßgeblich, die Daten auf einen überschaubaren Zeitraum zu filtern. Die Abfrage enthält die Parameter :start_date und :end_date. Wir empfehlen, für eine erste Analyse 3 bis 6 Monate Daten zu extrahieren. Der Filter wird auf das Erstellungsdatum des Journals angewendet.
Ledger-Filterung: Verwenden Sie den Parameter :ledger_name, um die Extraktion auf ein bestimmtes primäres Hauptbuch zu beschränken. Das Extrahieren aller Hauptbücher gleichzeitig kann zu extrem großen Dateien und Leistungsproblemen führen.
Voraussetzungen: Der Benutzer, der den Antrag bearbeitet.en Bericht erstellt und plant, muss über entsprechende BI-Rollen verfügen, wie 'BI Administrator' oder 'BI Author'. Zusätzlich muss das Datensicherheitsprofil des Benutzers den Zugriff auf die spezifischen Hauptbücher und Geschäftseinheiten gewähren, die abgefragt werden.
Planung: Für optimale Leistung und um Systembenutzer nicht zu beeinträchtigen, planen Sie den Extraktionsauftrag so, dass er außerhalb der Spitzenzeiten, z.B. über Nacht, ausgeführt wird.

a Beispielabfrage config

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

Zu BI Publisher bewältigen: Melden Sie sich bei Oracle Fusion Financials an. Verwenden Sie das Navigator-Menü, um zu Tools zu gehen, und wählen Sie dann Reports and Analysen. Dadurch wird der Business Intelligence-Katalog geöffnet.
Neues Datenmodell erstellen: Klicken Sie im BI-Katalog auf die Schaltfläche Erstellen und wählen Sie Datenmodell. Dadurch wird der Datenmodell-Editor geöffnet.
SQL-Abfrage-Datensatz definieren: Klicken Sie im Datenmodell-Editor auf das Plus-Symbol auf der Registerkarte Diagramm und wählen Sie SQL-Abfrage. Geben Sie im neuen Dialogfeld dem Datensatz einen Namen, z.B. ProcessMind_JE_EventLog. Wählen Sie die entsprechende Datenquelle, die in der Regel FUSIONDB ist. Fügen Sie die vollständige bereitgestellte SQL-Abfrage in den SQL Query-Textbereich ein.
Parameter definieren: Die Abfrage verwendet Parameter für den Datumsbereich (p_start_date und p_end_date). Oracle BI Publisher erkennt diese automatisch. Sie sollten diese als Texttyp-Parameter konfigurieren und benutzerfreundliche Bezeichnungen wie 'Startdatum (JJJJ-MM-TT)' und 'Enddatum (JJJJ-MM-TT)' festlegen.
Datenmodell speichern: Nachdem Sie die Abfrage eingefügt und Parameter definiert haben, klicken Sie auf OK und speichern Sie das Datenmodell in einem geeigneten Ordner, z.B. Shared Folders/Custom/ProcessMining.
Bericht erstellen: Klicken Sie auf die Schaltfläche Bericht erstellen in der oberen rechten Ecke des Datenmodell-Editors. Der Berichtserstellungsassistent wird gestartet.
Berichtslayout konfigurieren: Wählen Sie im Assistenten die Option, das aktuelle Datenmodell zu verwenden. Wählen Sie das 'Tabellen'-Layout. Ziehen Sie alle Spalten aus der Datenquelle in den Tabellenlayoutbereich. Deaktivieren Sie die Option 'Gesamtsummenzeile anzeigen'.
Bericht speichern: Speichern Sie den Bericht im selben Ordner wie das Datenmodell. Geben Sie ihm einen aussagekräftigen Namen wie 'Journaleintrag Event Log Bericht'.
Standard-Ausgabeformat festlegen: Bearbeiten Sie den Bericht und bewältigen Sie zur Registerkarte 'Anzeige'. Stellen Sie unter 'Ausgabeformate' sicher, dass CSV ausgewählt und vorzugsweise als Standardformat festgelegt ist. Dies stellt ... sicher, dass die Ausgabe für die direkte Verwendung kompatibel ist.
Ausführen und exportieren: Öffnen Sie den Bericht, und Sie werden aufgefordert, die Start- und Enddatumsparameter einzugeben. Geben Sie den gewünschten Datumsbereich ein und klicken Sie auf Anwenden. Sobald der Bericht ausgeführt wurde, klicken Sie auf die Schaltfläche Exportieren und wählen Sie das CSV-Format, um die Event Logdatei herunterzuladen.
Für den Upload vorbereiten: Öffnen Sie die heruntergeladene CSV-Datei. Überprüfen Sie, ob die Spaltenüberschriften mit den erwarteten Attributnamen (JournalEntryId, ActivityName, Ereigniszeitpunkt (Event Time) usw.) übereinstimmen und die Daten korrekt formatiert sind, bevor Sie sie auf die ProcessMind-Plattform hochladen.

Konfiguration

Voraussetzungen: Der Benutzer, der den Antrag bearbeitet.en Bericht ausführt, muss über eine Rolle mit den erforderlichen Datensicherheitsberechtigungen für den Zugriff auf HauptbuchDaten verfügen, z.B. General Accountant oder eine benutzerdefinierte BI-Rolle. Der Zugriff auf das BI Publisher-Tool ist ebenfalls erforderlich.
Datenquelle: Das BI Publisher Daten Model sollte so konfiguriert werden, dass es die AnwendungsDatenbankverbindung FUSIONDB verwendet.
Datumsbereichsparameter: Die Abfrage ist mit den Parametern p_start_date und p_end_date konzipiert, um das Datenextraktionsfenster zu steuern. Es wird empfohlen, mit einem Zeitraum von 3 bis 6 Monaten Daten zu beginnen, um die Leistung sicherzustellen.
Berichtsfilter: Für große Unternehmen wird dringend empfohlen, Filter direkt in die WHERE-Klausel des JournalHeaders-Common Table Expression der Abfrage einzufügen. Das Filtern nach LEDGER_ID oder LEGAL_ENTITY_ID ist unerlässlich, um das Datenvolumen zu steuern.
Leistungsaspekte: Die Ausführung dieser Abfrage gegen eine große ProduktionsDatenbank kann erhebliche Ressourcen verbrauchen. Planen Sie den Bericht so, dass er außerhalb der Spitzenzeiten ausgeführt wird, um die Auswirkungen auf die Systemleistung zu minimieren.
Ausgabeformat: Der Bericht muss so konfiguriert werden, dass er als CSV-Datei ausgegeben wird. Dies bietet ein sauberes, strukturiertes Format für die Aufnahme 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: Stellen Sie sicher, dass Python 3 zusammen mit den requests- und pandas-Bibliotheken installiert ist. Sie benötigen ein Benutzerkonto für Oracle Fusion Financials mit den erforderlichen Berechtigungen für den Zugriff auf die General Ledger Journals REST API. Besorgen Sie sich die URL Ihrer Oracle Fusion-Instanz, den Benutzernamen und das Passwort.
Skript-Setup: Erstellen Sie eine neue Python-Skriptdatei. Beginnen Sie mit dem Import der notwendigen Bibliotheken: requests, json, pandas und datetime.
Konfiguration: Definieren Sie im Skript Variablen für Ihre Oracle Fusion-AnmeldeHinweisrmationen und die Basis-URL. Legen Sie außerdem Parameter für die Datenextraktion fest, wie z.B. die Start- und EndDaten für die Abfrage.
Authentifizierung: Das Skript verwendet die Basis-Authentifizierung. Die requests-Bibliothek übernimmt die Kodierung des Benutzernamens und Passworts in den Anforderungsheadern.
API-Aufruffunktion definieren: Erstellen Sie eine Funktion zur Bearbeitung der API-Anfragen. Diese Funktion sollte die Paginierung mithilfe der Parameter offset und limit verwalten. Sie wird Schleifen durchlaufen und aufeinanderfolgende API-Aufrufe tätigen, bis alle Journaleinträge innerhalb des angegebenen Datumsbereichs abgerufen wurden.
API-Abfrage konstruieren: Verwenden Sie den q-Parameter in der API-Anfrage, um Journale nach dem LastUpdateDate zu filtern. Dies ermöglicht eine gezielte Datenextraktion innerhalb eines bestimmten Zeitrahmens, z.B. LastUpdateDate between '2023-01-01' and '2023-03-31'.
Datenabruf initiieren: Rufen Sie die Funktion auf, um Daten vom .../fscmRestApi/resources/11.13.18.05/journals-Endpunkt abzurufen. Die Funktion gibt eine vollständige Listee der Journaleinträge zurück.
Daten verarbeiten und modernisieren: Iterieren Sie durch jeden Journaleintrag, der von der API zurückgegeben wird. Generieren Sie für jedes Journal mehrere Ereigniszeilen, die den verschiedenen Geschäftsaktivitäten (Journal Entry Created, Journal Entry Approved usw.) entsprechen. Verwenden Sie die Datumsfelder und Statuscodes aus der API-Antwort (CreationDate, PostedDate, ApprovalStatus usw.), um diese unterschiedlichen Ereignisse zu erstellen.
Event Log strukturieren: Wenn jede Ereigniszeile generiert wird, speichern Sie sie als Wörterbuch in einer Listee. Diese Listee wird die RohDaten für Ihr Event Log bilden.
DatenFrame erstellen: Sobald alle Journale verarbeitet wurden, konvertieren Sie die Listee der Ereigniswörterbücher in ein Pandas DatenFrame für eine einfachere Manipulation.
Spalten finalisieren: Wählen und benennen Sie die DatenFrame-Spalten um, damit sie dem erforderlichen Schema für ProcessMind entsprechen: JournalEntryId, ActivityName, Ereigniszeitpunkt (Event Time), BenutzerName usw.
Nach CSV exportieren: Speichern Sie das finale DatenFrame in einer CSV-Datei. Diese Datei kann dann direkt in ProcessMind zur Analyse hochgeladen werden.

Konfiguration

AnmeldeHinweisrmationen: Ein gültiger Oracle Fusion Benutzername und Passwort sind für die Basis-Authentifizierung erforderlich.
Instanz-URL: Die Basis-URL Ihrer Oracle Fusion Financials-Instanz wird benötigt, um den API-Endpunkt zu konstruieren (z.B. https://[your-instance].fa.us2.oraclecloud.com).
API-Endpunkt: Das Skript zielt auf den fscmRestApi/resources/11.13.18.05/journals-Endpunkt ab, um HauptbuchDaten abzurufen.
Datumsbereichsfilter: Das Skript sollte mit einem start_date und end_date konfiguriert werden, um den Umfang der Extraktion zu begrenzen. Für eine erste Analyse wird ein Zeitraum von 3 bis 6 Monaten empfohlen. Für den fortlaufenden Einsatz konfigurieren Sie es für tägliche oder wöchentliche inkrementelle Ladevorgänge.
Paginierungslimit: Der Parameter limit steuert, wie viele Datensätze pro API-Aufruf abgerufen werden. Ein Wert zwischen 200 und 500 ist in der Regel effizient, da er die Anzahl der API-Aufrufe mit der Größe jeder Antwort in Einklang bringt.
Erforderliche Oracle-Rollen: Das Benutzerkonto muss eine Rolle mit den notwendigen Berechtigungen besitzen, um JournaleintragsDaten über die REST-API zu lesen, z.B. 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

Zum Arbeitsbereich Berichte und Analysen bewältigen: Melden Sie sich bei Oracle Fusion Financials an. Verwenden Sie das Navigator-Menü, um zu Tools zu gehen, und wählen Sie dann Reports and Analysen. Dies ist die zentrale Anlaufstelle für die Erstellung und Verwaltung aller Analysen und Berichte.
Ein BI Publisher-Datenmodell erstellen: Anstatt mit einer OTBI-Analyse zu beginnen, ist es für diese Art der Event Log-Extraktion effektiver, direkt ein BI Publisher-Datenmodell zu erstellen. Dies ermöglicht die Verwendung einer benutzerdefinierten SQL-Abfrage mit UNION ALL-Anweisungen. Klicken Sie auf die Schaltfläche 'Katalog durchsuchen', bewältigen Sie zu einem geeigneten Ordner und wählen Sie Erstellen > Datenmodell.
Den SQL-Abfrage-Datensatz definieren: Klicken Sie im Datenmodell-Editor auf das '+' Symbol, um einen neuen Datensatz hinzuzufügen, und wählen Sie 'SQL Query'. Geben Sie dem Datensatz einen beschreibenden Namen, z.B. 'JournalEventLog'.
Die SQL-Abfrage eingeben: Wählen Sie 'Oracle BI EE' als Datenquelle. Kopieren Sie das vollständige SQL-Skript aus dem Abschnitt 'Query' unten und fügen Sie es in den SQL Query-Textbereich ein. Die Abfrage ist so konzipiert, dass sie alle erforderlichen Aktivitäten und Attribute in einer einzigen, einheitlichen Struktur zusammenführt.
Parameter definieren: Die bereitgestellte Abfrage verwendet Parameter wie :start_date, :end_date und :ledger_name. Die Datenmodell-Oberfläche erkennt diese automatisch. Sie müssen sie als Parameter konfigurieren und entsprechende Datentypen (Datum oder Text) sowie bei Bedarf Standardwerte festlegen. Dies ermöglicht eine flexible Berichtsausführung.
Einen Bericht aus dem Datenmodell erstellen: Nachdem Sie das Datenmodell gespeichert haben, bewältigen Sie zurück zum Katalog. Klicken Sie auf Erstellen > Bericht. Wählen Sie im Berichtserstellungsassistenten 'Bestehendes Datenmodell verwenden' und suchen Sie das soeben erstellte Datenmodell.
Das Berichtslayout konfigurieren: Wählen Sie im Layout-Editor das 'Tabellen'-Layout. Es ist maßgeblich, alle Spalten aus dem Datenmodell in die Tabelle zu ziehen und abzulegen, um sicherzustellen, dass sie im Export enthalten sind. Es ist keine komplexe Formatierung erforderlich.
Standardausgabe auf CSV festlegen: Gehen Sie zum Link 'Listee anzeigen' im Berichts-Editor. Stellen Sie im Abschnitt 'Ausgabeformate' sicher, dass 'CSV' ausgewählt ist. Es wird empfohlen, alle anderen Formate zu deaktivieren, um die Planung zu vereinfachen. Speichern Sie den Bericht.
Den Bericht für die automatisierte Extraktion planen: Suchen Sie Ihren gespeicherten Bericht im Katalog und klicken Sie auf 'Mehr' und dann auf 'Planen'. Erstellen Sie einen neuen Planungsauftrag. Konfigurieren Sie die Häufigkeit, z.B. täglich oder wöchentlich.
Export und Zustellung konfigurieren: Geben Sie auf der Registerkarte 'Output' des Planungsauftrags die Ausgabedetails an. Wählen Sie Ihren Bericht und 'CSV' als Format. Auf der Registerkarte 'Destination' können Sie die Zustellung der Datei an einen Content-Server-Speicherort (UCM) oder einen externen SFTP-Server für den automatisierten Abruf konfigurieren.
Daten abrufen und vorbereiten: Sobald der geplante Auftrag ausgeführt wurde, rufen Sie die generierte CSV-Datei von Ihrem konfigurierten Ziel ab. Stellen Sie sicher, dass die Spaltenüberschriften den Anforderungen für die ProcessMind-Aufnahme entsprechen: JournalEntryId, ActivityName, Ereigniszeitpunkt (Event Time), (SourceSystem), LastDatenUpdate, BenutzerName, usw. Die Datei ist nun bereit für den Upload.

Konfiguration

Datenquelle: Die Abfrage sollte gegen die Datenquelle 'Oracle BI EE' innerhalb von BI Publisher ausgeführt werden, die sich mit den zugrunde liegenden transaktionalen Datenbankansichten verbindet, welche OTBI unterstützen.
Schlüsselthemenbereiche (als Referenz): Die Abfragelogik basiert auf Daten, die hauptsächlich im Themenbereich 'General Ledger – Journals Real Time' zu finden sind. Sie verknüpft auch logisch Daten, die in 'HCM – Workforce Management – Worker Assignment Real Time' für Benutzerdetails und potenziell Workflow-Themenbereiche für die Genehmigungshistorie zu finden wären.
Datumsbereichsfilterung: Es ist maßgeblich, die Daten auf einen überschaubaren Zeitraum zu filtern. Die Abfrage enthält die Parameter :start_date und :end_date. Wir empfehlen, für eine erste Analyse 3 bis 6 Monate Daten zu extrahieren. Der Filter wird auf das Erstellungsdatum des Journals angewendet.
Ledger-Filterung: Verwenden Sie den Parameter :ledger_name, um die Extraktion auf ein bestimmtes primäres Hauptbuch zu beschränken. Das Extrahieren aller Hauptbücher gleichzeitig kann zu extrem großen Dateien und Leistungsproblemen führen.
Voraussetzungen: Der Benutzer, der den Antrag bearbeitet.en Bericht erstellt und plant, muss über entsprechende BI-Rollen verfügen, wie 'BI Administrator' oder 'BI Author'. Zusätzlich muss das Datensicherheitsprofil des Benutzers den Zugriff auf die spezifischen Hauptbücher und Geschäftseinheiten gewähren, die abgefragt werden.
Planung: Für optimale Leistung und um Systembenutzer nicht zu beeinträchtigen, planen Sie den Extraktionsauftrag so, dass er außerhalb der Spitzenzeiten, z.B. über Nacht, ausgeführt wird.

a Beispielabfrage config

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

Ihre Datensatz-to-Report: Journaleintrag Daten-Vorlage.

Ihre Datensatz-to-Report: Journaleintrag Daten-Vorlage.

Datensatz-to-Report: Journaleintrags-Attribute.

Datensatz-to-Report: Journaleintrags-Aktivitäten.

Extraktionsanleitungen

Oracle OTBI und BI Publisher Bericht Export

Schritte

Konfiguration

a Beispielabfrage config

BI Publisher Bericht mit direkter SQL-Datenmodellabfrage

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript unter Verwendung der Oracle Fusion Financials REST API

Schritte

Konfiguration

a Beispielabfrage python

Massen-Datenextraktion mit BI Cloud Connector (BICC)

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

Beschleunigen Sie Ihren Datensatz-to-Report: Journaleintrag noch heute

Ihre Datensatz-to-Report: Journaleintrag Daten-Vorlage.

Ihre Datensatz-to-Report: Journaleintrag Daten-Vorlage.

Datensatz-to-Report: Journaleintrags-Attribute.

Datensatz-to-Report: Journaleintrags-Aktivitäten.

Extraktionsanleitungen

Oracle OTBI und BI Publisher Bericht Export

Schritte

Konfiguration

a Beispielabfrage config

BI Publisher Bericht mit direkter SQL-Datenmodellabfrage

Schritte

Konfiguration

a Beispielabfrage sql

Python-Skript unter Verwendung der Oracle Fusion Financials REST API

Schritte

Konfiguration

a Beispielabfrage python

Massen-Datenextraktion mit BI Cloud Connector (BICC)

Schritte

Konfiguration

a Beispielabfrage config

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Beschleunigen Sie Ihren Datensatz-to-Report: Journaleintrag noch heute