> Continue verbetering > Record to Report Journaalboeking > Oracle Fusion Financials > datatemplate

Uw Record to Report - Journaalboeking Data Template

Oracle Fusion Financials

Record to Report - Journaalboeking attributes (22) Record to Report - Activiteiten van Journaalboekingen (12) Extractie Guides (4)

Uw Record to Report - Journaalboeking Data Template

Deze data template biedt een uitgebreide gids voor het extraheren en structureren van uw Oracle Fusion Financials Journaalboeking data. Het schetst de essentiële attributes die u moet verzamelen en de belangrijkste activiteiten die u moet volgen, wat garandeert dat u alle noodzakelijke informatie vastlegt voor robuuste procesanalyse. U vindt ook praktische begeleiding over hoe u deze data direct uit uw systeem kunt extraheren.

Aanbevolen attributen om vast te leggen
Belangrijkste activiteiten om te volgen
Richtlijnen voor data‑extractie uit Oracle Fusion Financials

Nieuw met event logs? Leer hoe je een process mining event log creëert.

Template downloaden

Record to Report - Journaalboeking attributes

Dit zijn de aanbevolen data fields om op te nemen in uw event log voor een uitgebreide analyse van uw Record to Report - Journaalboeking proces.

5 Verplicht 6 Aanbevolen 11 Optioneel

	Naam	Omschrijving
	Activiteit ActivityName	De naam van de specifieke bedrijfsgebeurtenis of taak die op een bepaald moment in het journaalboekingsproces heeft plaatsgevonden.
Omschrijving De Activiteitsnaam beschrijft een enkele stap binnen de levenscyclus van de journaalboeking, zoals 'Journal Entry Created' of 'Journal Entry Approved'. Deze data is cruciaal voor het bouwen van de proceskaart en het begrijpen van de opeenvolging van gebeurtenissen. Het analyseren van activiteiten maakt de identificatie van de processtroom mogelijk, inclusief standaardpaden, afwijkingen en herbewerkingslussen. Door verschillende activiteiten te volgen, kunnen we de tijd meten die in specifieke fasen wordt besteed, zoals goedkeuring, en identificeren welke stappen het meest tijdrovend of foutgevoelig zijn. Het belang Het definieert de stappen van het proces, vormt de ruggengraat van de proceskaart en maakt analyse van flow, knelpunten en variaties mogelijk. Vindplaats Dit attribute wordt doorgaans afgeleid van statuswijzigingen, event logs, of audit trail tabellen geassocieerd met journaalboekingsobjecten in de Grootboekmodule. Voorbeelden Journaalpost aangemaaktJournaalpost ingediend ter goedkeuringJournaalpost goedgekeurdJournaalpost geboekt
	Journaalpost ID JournalEntryId	De unieke identifier voor een enkele journaalboeking, die alle gerelateerde financiële transactieactiviteiten koppelt.
Omschrijving De Journaalboeking ID dient als de primaire case-identifier, die alle activiteiten gerelateerd aan een specifieke set financiële transacties uniek koppelt. Dit maakt het volgen van de complete levenscyclus van een enkele journaalboeking mogelijk, van initiatie tot definitieve boeking, wat garandeert dat alle debet- en creditposten zijn verwerkt. In process mining is deze ID essentieel voor het reconstrueren van het end-to-end traject van elke journaalboeking. Het verbindt uiteenlopende gebeurtenissen zoals 'Journal Entry Created', 'Journal Submitted For Approval' en 'Journal Entry Posted' tot een coherente processtroom, waardoor analyse van doorlooptijden, knelpunten en procesvariaties mogelijk is. Het belang Dit is de fundamentele sleutel voor het volgen van een journaalboeking van begin tot eind, waardoor het mogelijk wordt om de gehele processtroom voor elke unieke case te analyseren. Vindplaats Dit is een primaire sleutel die te vinden is in kern Grootboektabellen zoals GL_JE_HEADERS en GL_JE_LINES. Voorbeelden JE100523JE202311001882019
	Starttijd EventTime	De tijdstempel die aangeeft wanneer een specifieke activiteit of gebeurtenis heeft plaatsgevonden.
Omschrijving Deze timestamp markeert de exacte datum en tijd dat een activiteit werd uitgevoerd. Het is het primaire tijdelijke element dat in process mining wordt gebruikt om de opeenvolging van gebeurtenissen te bepalen en de duren ertussen te berekenen. De nauwkeurigheid van de Event Time is cruciaal voor alle tijdgebaseerde analyses, inclusief het berekenen van doorlooptijden, het identificeren van knelpunten en het monitoren van prestaties tegen service level agreements. Het biedt de chronologische volgorde die nodig is om de processtroom te reconstrueren zoals deze heeft plaatsgevonden. Het belang Deze timestamp is essentieel voor het ordenen van gebeurtenissen, het berekenen van alle procesduren en het uitvoeren van elke tijdgebaseerde analyse. Vindplaats Deze informatie wordt doorgaans opgeslagen in audit trail tabellen of als een 'Last Update Date' of 'Creation Date' op transactietabellen zoals GL_JE_HEADERS en GL_JE_LINES voor specifieke gebeurtenissen. Voorbeelden 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
	Bronsysteem SourceSystem	Het systeem of de module waar de data is ontstaan.
Omschrijving Dit attribute identificeert het bronsysteem waaruit de procesdata is geëxtraheerd. In een complex IT-landschap kan data afkomstig zijn van meerdere geïntegreerde systemen, en dit veld helpt deze te onderscheiden. Bij procesanalyse is het kennen van het bronsysteem cruciaal voor het begrijpen van procesvariaties die kunnen worden veroorzaakt door verschillend systeemgedrag. Het helpt ook bij data-validatie en probleemoplossing door data terug te leiden naar de oorsprong. Het belang Identificeert de herkomst van de data, wat cruciaal is voor datagovernance, validatie en het begrijpen van procesvariaties tussen verschillende systemen. Vindplaats Dit is vaak een statische waarde die is geconfigureerd tijdens data-extractie, of het kan een veld zijn in de brontabellen dat het systeem van invoer identificeert. Voorbeelden Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Laatste data-update LastDataUpdate	De tijdstempel van de meest recente verversing of extractie van gegevens uit het bronsysteem.
Omschrijving Dit attribute registreert wanneer de dataset voor het laatst is bijgewerkt. Het biedt context over de versheid van de geanalyseerde data, wat belangrijk is voor het begrijpen van de relevantie van de afgeleide inzichten. In elke analyse, vooral in operationele dashboards, is het kennen van de Last Data Update tijd cruciaal voor gebruikers om de data te vertrouwen en geïnformeerde beslissingen te nemen. Het communiceert duidelijk het afsnijpunt voor de data die in het process mining model is opgenomen. Het belang Geeft de actualiteit van de data aan, waardoor gebruikers begrijpen hoe recent de procesanalyse is en de inzichten kunnen vertrouwen. Vindplaats Deze waarde wordt gegenereerd en opgeslagen tijdens het data-extractie- en transformatieproces. Het is doorgaans de timestamp wanneer de ETL/ELT job is voltooid. Voorbeelden 2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
	`Gebruikersafdeling` UserDepartment	De afdeling of het team waartoe de gebruiker die de activiteit heeft uitgevoerd, behoort.
Omschrijving Dit attribute biedt organisatorische context door een activiteit te koppelen aan een specifieke afdeling, zoals 'Financiën', 'Accounting Operations' of 'Interne Audit'. Het wordt doorgaans afgeleid van gebruikersstamdata. Analyseren per Gebruikersafdeling helpt bij het identificeren van cross-departmentale knelpunten, team prestaties te vergelijken, en te begrijpen hoe de procesuitvoering binnen de organisatie verschilt. Het is waardevol voor resource-allocatie en gerichte procesverbeteringsinitiatieven. Het belang Biedt organisatorische context, waardoor prestatieanalyse per team of afdeling mogelijk is en cross-functionele inefficiënties worden benadrukt. Vindplaats Dit bevindt zich doorgaans niet in de transactietabellen. Het moet worden verkregen door de UserName te koppelen met een gebruikersstamdatatable of HR-systeemdata. Voorbeelden Algemene boekhoudingFinanciële rapportageCrediteuren
	Gebruiker UserName	De gebruiker die de activiteit heeft uitgevoerd, zoals het creëren, goedkeuren of boeken van de journaalboeking.
Omschrijving Dit attribute identificeert de specifieke medewerker of systeemgebruiker verantwoordelijk voor het uitvoeren van een activiteit. Het is cruciaal voor het begrijpen van de werkdrukverdeling, prestaties en het identificeren van individuele knelpunten. In analyse maakt UserName het mogelijk om processen te filteren op gebruiker, gebruikers efficiëntie te vergelijken, en de redenen voor vertragingen of fouten te onderzoeken. Het ondersteunt direct dashboards zoals 'Gebruikerswerkdruk & Efficiëntie over Teams heen' en KPI's zoals de 'Gebruiker Journaal Knelpunt Index'. Het belang Wijs verantwoordelijkheid toe voor processtappen, wat de analyse van gebruikerswerkdruk, individuele prestaties en trainingsbehoeften mogelijk maakt. Vindplaats Te vinden in transactietabellen zoals GL_JE_HEADERS (bijv. CREATED_BY, LAST_UPDATED_BY) en gerelateerde audit trail tabellen. Voorbeelden john.doesusan.smithautoprocess_user
	Journaalpostbedrag JournalAmount	De totale monetaire waarde van de journaalboeking, doorgaans de som van debetposten.
Omschrijving Dit attribute vertegenwoordigt de totale financiële waarde die wordt verhandeld in de journaalboeking. Het bedrag kan een belangrijke factor zijn die het proces beïnvloedt. Boekingen met een hoge waarde vereisen bijvoorbeeld mogelijk aanvullende goedkeuringsstappen of grondigere beoordelingen. Het analyseren van het Journaalbedrag maakt de segmentatie van cases op basis van financiële impact mogelijk. Het helpt vragen te beantwoorden zoals 'Duren goedkeuringen van hoogwaardige boekingen langer?' of 'Komen afwijzingen vaker voor bij boekingen boven een bepaalde drempel?'. Dit biedt cruciale zakelijke context voor de processtroom. Het belang Biedt cruciale zakelijke context, waardoor analyse op basis van financiële impact mogelijk is en helpt te identificeren of boekingen met een hoge waarde een afwijkend proces volgen. Vindplaats Deze waarde wordt doorgaans berekend als de som van debet- of creditposten uit de GL_JE_LINES tabel voor een gegeven journaalboeking. Voorbeelden 5000.00125000.75750.50
	Journaalpostbron JournalSource	Het subgrootboek of de bron die de journaalboeking heeft gegenereerd, zoals 'Crediteuren', 'Debiteuren' of 'Handmatig'.
Omschrijving Dit attribute geeft de herkomst van de journaalboeking binnen het ERP-systeem aan. Boekingen kunnen handmatig worden gecreëerd in het Grootboek of automatisch worden gegenereerd vanuit subgrootboeken zoals Crediteuren, Debiteuren of Vaste Activa. Journal Source is een belangrijk attribute voor automatiseringsanalyse. Het helpt handmatige en door het systeem gegenereerde boekingen te onderscheiden, en ondersteunt de KPI 'Geautomatiseerde Journaalboekingspercentage'. Processen voor boekingen uit verschillende bronnen variëren vaak aanzienlijk in termen van complexiteit en efficiëntie. Het belang Onderscheidt tussen handmatige en geautomatiseerde posten, wat cruciaal is voor het meten van automatiseringsgraden en het analyseren van procesverschillen. Vindplaats Beschikbaar in de GL_JE_HEADERS tabel, doorgaans in een veld genaamd JE_SOURCE. Voorbeelden HandmatigCrediteurenActivaDebiteuren
	Journaalpostcategorie JournalCategory	De categorie van de journaalboeking, zoals 'Periodisering', 'Correctie' of 'Herclassificatie'.
Omschrijving Journaalpostcategorie classificeert posten op basis van hun bedrijfsdoel. Deze classificatie maakt een meer gedetailleerde analyse van het proces mogelijk, aangezien verschillende categorieën afzonderlijke processtromen, goedkeuringsregels of cyclusduren kunnen hebben. Maandafsluitingsjournaalposten voor aanpassingen kunnen bijvoorbeeld een complexer en urgenter proces kennen dan routinematige transitorische posten. Het analyseren van het proces per categorie helpt om deze variaties bloot te leggen en verbeteringen af te stemmen op specifieke typen journaalposten. Het belang Maakt het mogelijk om het proces te segmenteren op basis van het bedrijfsdoel van de journaalpost, wat verschillende gedragingen en prestaties voor verschillende posttypen onthult. Vindplaats Beschikbaar in de GL_JE_HEADERS tabel, doorgaans in een veld genaamd JE_CATEGORY. Voorbeelden Transitorische postHandmatigAanpassingHerwaardering
	Reden van afwijzing RejectionReason	Een tekstuele beschrijving of code die verklaart waarom een journaalpost werd afgekeurd.
Omschrijving Wanneer een journaalboeking wordt afgewezen tijdens het goedkeuringsproces, legt dit attribute de reden voor de afwijzing vast. Dit kan een vooraf gedefinieerde code zijn of een vrije-tekst opmerking van de goedkeurder. Dit is een van de belangrijkste attributes voor root cause analyse van procesinefficiënties. Door de meest voorkomende afwijzingsredenen te analyseren, kunnen organisaties gebieden voor verbetering identificeren, zoals betere training voor opstellers, duidelijkere richtlijnen of systeemcontroleverbeteringen. Het ondersteunt direct het 'Journaalboeking Afwijzingspercentage Analyse' dashboard. Het belang Biedt direct inzicht in de grondoorzaken van herbewerking en procesvertragingen, wat gerichte verbeteringen mogelijk maakt om afwijzingspercentages te verlagen. Vindplaats Deze informatie kan worden opgeslagen in workflow of audit trail tabellen geassocieerd met het goedkeuringsproces, of in een notitieveld op de journaalkop. Voorbeelden Onjuiste rekeningcombinatieOnvoldoende ondersteunende documentatieOverschrijdt budget
	Boekhoudperiode AccountingPeriod	De fiscale periode waarnaar de journaalboeking wordt geboekt, zoals 'Jan-24'.
Omschrijving De Boekhoudperiode specificeert de financiële periode waarin de transactie wordt erkend. Dit is fundamenteel voor alle financiële rapportage en analyse. In process mining is dit attribute cruciaal voor trendanalyse. Het maakt het mogelijk om procesprestaties, zoals doorlooptijden of afwijzingspercentages, over verschillende maanden of kwartalen te vergelijken. Dit helpt bij het identificeren van seizoensgebonden effecten, zoals verhoogde werkdruk tijdens de maandafsluiting, en het meten van de impact van procesverbeteringen over tijd. Het belang Maakt trendanalyse van KPI's over tijd mogelijk, wat helpt om procesverbetering te meten en seizoenspatronen zoals maandafsluitingsdruk te identificeren. Vindplaats Beschikbaar in de GL_JE_HEADERS tabel, doorgaans in een veld genaamd PERIOD_NAME. Voorbeelden Jan-24Feb-24Mar-24
	Boekingsstatus PostingStatus	De huidige boekingsstatus van de journaalboeking, bijvoorbeeld 'Niet geboekt' of 'Geboekt'.
Omschrijving Dit attribute weerspiegelt de huidige staat van de journaalboeking met betrekking tot de boeking in het grootboek. Het is een belangrijke indicator van waar een journaalboeking zich bevindt in zijn levenscyclus, vooral voor 'in-flight' cases. Posting Status is cruciaal voor het 'Real-Time Journal Entry Status Tracker' dashboard, en biedt een momentopname van alle actieve boekingen. Het helpt bij het monitoren van achterstanden van onverwerkte journaals en het identificeren van vertragingen in de laatste fasen van het proces. Het belang Geeft de huidige status van een journaalpost aan, wat essentieel is voor het monitoren van achterstanden en het volgen van de status van lopende posten. Vindplaats Beschikbaar in de GL_JE_HEADERS tabel, doorgaans in een kolom zoals STATUS of POSTING_STATUS. Voorbeelden GeboektNiet geboektFout
	Doelboekingsdatum TargetPostingDate	De vooraf bepaalde datum waarop de journaalboeking naar verwachting wordt geboekt.
Omschrijving De Doelboekingsdatum vertegenwoordigt de deadline voor het boeken van een journaalboeking naar het grootboek, vaak bepaald door service level agreements (SLA's) of maandafsluitingsschema's. Het dient als een benchmark voor het meten van prestaties. Dit attribute is essentieel voor het berekenen van de KPI 'On-Time Journal Posting Rate'. Door de werkelijke boekingsdatum met dit doel te vergelijken, kan het systeem boekingen automatisch markeren als tijdig of te laat, wat een duidelijke maatstaf biedt voor procesnaleving van planningen. Het belang Definieert de service level agreement of deadline voor het boeken, wat de berekening van on-time prestatie-KPI's mogelijk maakt. Vindplaats Dit is mogelijk geen standaardveld. Het kan worden afgeleid uit bedrijfsregels op basis van de creatiedatum, boekhoudperiode of journaalcategorie. Voorbeelden 2023-10-312023-11-302024-01-05
	Eindtijd EndTime	De timestamp die aangeeft wanneer een specifieke activiteit is voltooid.
Omschrijving De Eindtijd markeert de voltooiing van een activiteit. Terwijl de Starttijd het begin registreert, biedt de Eindtijd het sluitingspunt, wat een precieze berekening van de verwerkingstijd voor die specifieke stap mogelijk maakt. Dit is essentieel voor het berekenen van de verwerkingstijden van activiteiten, wat een kernmetric is voor het identificeren van knelpunten en het meten van resource-efficiëntie. Het verschil tussen de Eindtijd en Starttijd van de activiteit 'Journal Entry Reviewed' geeft bijvoorbeeld de werkelijke tijd die een beoordelaar aan de taak heeft besteed. Het belang Het maakt de berekening mogelijk van de werkelijke duur of verwerkingstijd van individuele activiteiten, wat cruciaal is voor het identificeren van efficiëntieproblemen. Vindplaats Vergelijkbaar met Start Time, wordt dit vaak gevonden in audit trail tabellen of kan het worden afgeleid van de Start Time van de daaropvolgende activiteit in het proces. Voorbeelden 2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
	End-to-End Cyclustijd EndToEndCycleTime	De totaal berekende duur vanaf de creatie van een journaalboeking tot de definitieve reconciliatie.
Omschrijving Deze metric vertegenwoordigt de totale tijd die een journaalboeking in het gehele proces doorbrengt, vanaf de allereerste 'Journal Entry Created' gebeurtenis tot de definitieve 'Journal Entry Reconciled' gebeurtenis. Het biedt een holistisch beeld van de procesprestaties. Dit is een primaire KPI voor het meten van de algehele procesefficiëntie. Het wordt gebruikt in trend dashboards om de impact van verbeteringsinitiatieven over tijd te volgen en biedt een basislijn waartegen alle proceswijzigingen kunnen worden gemeten. Het belang Biedt een overkoepelende maatstaf voor de gezondheid en efficiëntie van het gehele proces, waardoor het een belangrijke KPI is voor managementrapportages. Vindplaats Deze metric wordt berekend door het process mining platform als het tijdsverschil tussen de eerste en laatste event timestamps voor elke case. Voorbeelden P10DT5HP4DT12HP22D
	Goedkeuringstijd journaalpost JournalApprovalTime	De berekende duur tussen indiening van het journaal en de definitieve goedkeurings- of afwijzingsbeslissing.
Omschrijving Deze metric meet de verstreken tijd vanaf het moment dat een journaal ter goedkeuring wordt ingediend totdat het wordt goedgekeurd of afgewezen. Het is een kritieke maatstaf voor de efficiëntie van de goedkeuringsworkflow. Journaal Goedkeuringstijd is een directe input voor de KPI 'Gemiddelde Journaal Goedkeuringstijd' en het 'Journaalboeking Goedkeuringsknelpunten' dashboard. Het analyseren van deze duur helpt bij het opsporen van vertragingen in de goedkeuringsketen, ongeacht of deze worden veroorzaakt door specifieke goedkeurders, afdelingen of journaaltypes. Het belang Meet direct de efficiëntie van de goedkeuringsworkflow, wat vaak een belangrijke bron van procesvertragingen is. Vindplaats Dit is een berekende metric binnen de process mining tool. Het is het tijdsverschil tussen de gebeurtenissen 'Journal Submitted For Approval' en 'Journal Entry Approved' of 'Journal Entry Rejected'. Voorbeelden P2DT4H30MPT8HP5D
	Grootboeknaam LedgerName	De naam van het grootboek waarin de journaalboeking wordt vastgelegd.
Omschrijving De Grootboeknaam identificeert het specifieke grootboek waartoe de journaalboeking behoort. In organisaties met meerdere juridische entiteiten of rapportagevereisten kunnen er meerdere grootboeken zijn, zoals een primair grootboek voor bedrijfsboekhouding en secundaire grootboeken voor lokale wettelijke rapportage. Dit attribute is essentieel voor het filteren en vergelijken van processen over verschillende juridische entiteiten of bedrijfseenheden. Het zorgt ervoor dat analyses worden uitgevoerd binnen de juiste organisatorische context, wat bijzonder belangrijk is voor financiële compliance en rapportage. Het belang Maakt procesanalyse mogelijk die gefilterd en vergeleken kan worden tussen verschillende juridische entiteiten of boekhoudkundige kaders, wat essentieel is voor grote organisaties. Vindplaats Te vinden in de GL_JE_HEADERS tabel, doorgaans gekoppeld via een LEDGER_ID die kan worden gejoind met GL_LEDGERS om de naam te verkrijgen. Voorbeelden US Primary LedgerUK Statutory LedgerGrootboek voor wereldwijde consolidatie
	Is herstelwerk IsRework	Een berekende vlag die waar is als de journaalpost een afwijzings- en correctiecyclus heeft doorlopen.
Omschrijving Dit Booleaanse attribute wordt berekend om cases te identificeren die herbewerking hebben ondergaan. Het wordt doorgaans als 'waar' gemarkeerd voor elke activiteit die volgt op een 'Journal Entry Rejected' gebeurtenis, zoals 'Journaal gecorrigeerd en opnieuw ingediend'. Is Rework is een krachtig attribute voor analyse, aangezien het een eenvoudige kwantificering van het volume en de impact van herbewerkingslussen mogelijk maakt. Het ondersteunt direct de KPI 'Gemiddelde Journaal Herbewerkingspercentage' en helpt bij het vergelijken van de processtroom en duur van herbewerkte cases versus die welke de eerste keer correct zijn verwerkt. Het belang Vlaggen direct gevallen die inefficiënte herwerkingslussen hebben doorlopen, waardoor het gemakkelijk wordt om de frequentie en impact van procesfouten te kwantificeren. Vindplaats Dit is niet beschikbaar in het bronsysteem. Het wordt berekend binnen de process mining tool door de sequentie van activiteiten voor elke case te analyseren. Voorbeelden truefalse
	Is tijdige boeking IsOnTimePosting	Een berekende vlag die waar is als de journaalpost op of voor de streefdatum is geboekt.
Omschrijving Dit Booleaanse attribute wordt afgeleid door de timestamp van de 'Journal Entry Posted' activiteit te vergelijken met de 'Doelboekingsdatum'. Als de boeking plaatsvindt op of vóór de deadline, is de waarde 'waar'; anders is deze 'onwaar'. Dit attribute ondersteunt direct de KPI 'On-Time Journal Posting Rate' door de berekening te vereenvoudigen. Het maakt eenvoudig filteren en analyseren van te late boekingen mogelijk om veelvoorkomende oorzaken voor vertragingen te identificeren, zoals specifieke journaalcategorieën of goedkeurders. Het belang Biedt een helder, binair resultaat voor boekingsprestaties, wat de analyse van tijdige verwerkingspercentages en de grondoorzaken van vertragingen vereenvoudigt. Vindplaats Dit attribute wordt berekend door de process mining tool. Het vereist het 'TargetPostingDate' attribute en de timestamp van de 'Journal Entry Posted' activiteit. Voorbeelden truefalse
	Omkeringsindicator ReversalIndicator	Een vlag die aangeeft of de journaalpost een omkering is van een andere boeking.
Omschrijving Dit Booleaanse attribute identificeert journaalboekingen die zijn gecreëerd om een eerder geboekte boeking om te keren. Omkeringen zijn een specifiek type journaalboeking dat vaak een onderscheidend, en soms problematisch, proces volgt. Het analyseren van deze indicator is cruciaal ter ondersteuning van het 'Prestaties Journaalomkeringsproces' dashboard. Het maakt het mogelijk om omkeringsprocessen te isoleren om hun frequentie, oorzaken en doorlooptijden te meten, en helpt onderliggende problemen in de originele boekingen te identificeren die een omkering noodzakelijk maken. Het belang Helpt het omkeerproces te isoleren en analyseren, wat vaak een indicator is van fouten of problemen in de oorspronkelijke transactie. Vindplaats Dit kan een specifieke flag zijn op de GL_JE_HEADERS tabel, zoals ACCRUAL_REV_FLAG, of worden geïdentificeerd via links naar het originele journaal dat wordt omgekeerd. Voorbeelden truefalse
	Valuta CurrencyCode	De valutacode voor het bedrag van de journaalboeking, zoals USD, EUR of GBP.
Omschrijving De Valutacode specificeert de valuta van de financiële bedragen in de journaalboeking. Dit is essentieel voor multinationale organisaties die in meerdere valuta's transacties uitvoeren. Dit attribute zorgt ervoor dat financiële waarden correct worden geïnterpreteerd. Het maakt filtering op valuta mogelijk en is een noodzakelijk veld bij het uitvoeren van analyses die het vergelijken of aggregeren van monetaire bedragen over verschillende regio's omvatten. Het belang Biedt noodzakelijke context voor alle financiële bedragen, zorgt voor accurate interpretatie en maakt analyses mogelijk die specifiek zijn voor verschillende valuta's. Vindplaats Beschikbaar in de GL_JE_HEADERS tabel, doorgaans in een veld genaamd CURRENCY_CODE. Voorbeelden USDEURGBPJPY

Verplicht Aanbevolen Optioneel

Record to Report - Activiteiten van Journaalboekingen

Dit zijn de belangrijkste processtappen en mijlpalen die u in uw event log moet vastleggen voor accurate procesontdekking in Journaalboeking.

5 Aanbevolen 7 Optioneel

	Activiteit	Omschrijving
	Journaalpost aangemaakt	Deze activiteit markeert de initiatie van het journaalboekingsproces. Het vertegenwoordigt het moment dat een gebruiker een nieuwe journaalkop creëert en begint met het invoeren van data, maar voordat deze ter beoordeling of goedkeuring wordt ingediend.
Het belang Dit is de primaire startgebeurtenis voor het proces. Het analyseren van de tijd vanaf deze activiteit tot de daaropvolgende stappen helpt bij het meten van de initiële data-invoer efficiëntie en de totale procesdoorlooptijd. Vindplaats Deze gebeurtenis wordt doorgaans afgeleid van de creation date timestamp in de GL_JE_HEADERS tabel voor een specifieke Journaalboeking ID. De gebruiker die de record heeft gecreëerd is ook beschikbaar in deze tabel. Vastleggen Gebruik de CREATION_DATE uit de GL_JE_HEADERS tabel. Gebeurtenistype inferred
	Journaalpost afgestemd	De journaalboeking is afgestemd en gezuiverd tijdens een periodieke rekeningafstemmingsproces. Dit bevestigt dat de transactie overeenkomt met andere financiële data, zoals bankafschriften.
Het belang Deze activiteit dient als een echt eindpunt voor de levenscyclus van het journaal. Het meten van de tijd van boeking tot reconciliatie is een belangrijke KPI voor het beoordelen van de efficiëntie van het financiële afsluitingsproces. Vindplaats Deze gebeurtenis wordt doorgaans vastgelegd in de Oracle Financial Consolidation and Close Cloud Service (FCCS) of Account Reconciliation Cloud Service (ARCS), niet in het Grootboek zelf. Het wordt afgeleid uit een statuswijziging op de reconciliatierecord die is gekoppeld aan het journaal. Vastleggen Koppel journaalpostdata aan statusupdates voor afstemming uit ARCS- of FCCS-tabellen. Gebeurtenistype inferred
	Journaalpost geboekt	De financiële data van de journaalboeking is succesvol vastgelegd in het Grootboek. De debet- en creditposten worden nu weergegeven in de rekeningsaldi.
Het belang Dit is een kritieke mijlpaal die de opname van het journaal in de officiële financiële administratie vertegenwoordigt. Het is essentieel voor het meten van het tijdige boekingspercentage en de totale tijd van creatie tot boeking. Vindplaats Dit wordt afgeleid uit een statuswijziging in de GL_JE_HEADERS tabel, waarbij het STATUS veld verandert naar 'P' (Posted). De GL_JE_BATCHES tabel heeft ook een posting status. Vastleggen Volg de timestamp wanneer STATUS in GL_JE_HEADERS verandert naar 'P'. Gebeurtenistype inferred
	Journaalpost goedgekeurd	De aangewezen goedkeurder heeft de journaalboeking formeel goedgekeurd, waarmee de nauwkeurigheid en geldigheid ervan worden bevestigd. Dit is de laatste stap in de goedkeuringsworkflow, die de weg vrijmaakt voor boeking.
Het belang Deze mijlpaal markeert het einde van het goedkeuringsproces. De tijd tussen indiening en goedkeuring is een belangrijke KPI voor het meten van workflow-efficiëntie en het identificeren van goedkeuringsknelpunten. Vindplaats Deze gebeurtenis wordt afgeleid uit een statuswijziging in de GL_JE_HEADERS tabel, waarbij de APPROVAL_STATUS_CODE wordt bijgewerkt naar 'APPROVED'. Workflow tabellen bevatten de identiteit en timestamp van de goedkeurder. Vastleggen Volg de timestamp wanneer APPROVAL_STATUS_CODE in GL_JE_HEADERS verandert naar 'APPROVED'. Gebeurtenistype inferred
	Journaalpost ingediend ter goedkeuring	Deze activiteit vindt plaats wanneer de gebruiker de voltooide journaalboeking formeel indient in de goedkeuringsworkflow. Het transformeert het journaal van een concept- of onvolledige staat naar een status van 'in afwachting van goedkeuring'.
Het belang Dit is een kritieke mijlpaal die de klok start voor het meten van goedkeuringsdoorlooptijden en het identificeren van knelpunten. Het scheidt de data-invoerfase van de beoordelings- en goedkeuringsfase. Vindplaats Deze gebeurtenis wordt afgeleid uit een statuswijziging in de GL_JE_HEADERS tabel, specifiek wanneer de APPROVAL_STATUS_CODE verandert naar een waarde zoals 'REQUIRED' of 'INITIATED'. De timestamp van de indieningsdatum kan ook worden vastgelegd. Vastleggen Volg de timestamp wanneer APPROVAL_STATUS_CODE in GL_JE_HEADERS verandert om indiening aan te geven. Gebeurtenistype inferred
	Boeking geverifieerd	Een verificatiestap na het boeken waarbij een gebruiker of systeem bevestigt dat de journaalpost correct is geboekt en de saldi conform verwachting zijn. Dit is vaak een handmatige controle.
Het belang Het analyseren van deze activiteit helpt inzicht te krijgen in de tijd besteed aan handmatige controles en kwaliteitsborging na het boeken. Het kan kansen benadrukken voor het automatiseren van verificatieprocessen. Vindplaats Dit is waarschijnlijk geen expliciete gebeurtenis in Oracle Fusion. Het zou moeten worden afgeleid uit andere acties, zoals een gebruiker die een specifiek rapport uitvoert of een aangepast statusveld dat wordt bijgewerkt, wat niet standaard is. Vastleggen Vereist maatwerklogica, zoals het volgen van de looptijd van verificatierapporten of updates van een descriptieve flexfield. Gebeurtenistype inferred
	Boeking journaalpost geïnitieerd	Het proces van het boeken van het goedgekeurde journaal naar het Grootboek is gestart. Dit kan een geautomatiseerde of handmatige stap zijn die het journaal in de wachtrij plaatst voor verwerking door het boekingsprogramma.
Het belang Deze activiteit scheidt de goedkeuring van het technische boekingsproces. Vertragingen tussen goedkeuring en initiatie van de boeking kunnen duiden op planningsproblemen of resourcebeperkingen in de boekingsengine. Vindplaats Dit kan worden afgeleid uit statuswijzigingen in de GL_JE_BATCHES tabel, of door de indieningstijd van de posting concurrent request geassocieerd met de journaalbatch. Vastleggen Identificeer de indieningstijd van de aanvraag voor het General Ledger Boekingsprogramma voor de specifieke journaalbatch. Gebeurtenistype inferred
	Journaalpost afgekeurd	Een goedkeurder heeft de journaalpost beoordeeld en afgekeurd wegens fouten, gebrek aan documentatie of beleidsschendingen. Deze actie stuurt de journaalpost terug naar de aanmaker voor correctie.
Het belang Deze activiteit is cruciaal voor het analyseren van herbewerkingslussen, afwijzingspercentages en 'first-time-right' metrics. Een hoge frequentie van afwijzingen wijst op problemen met datakwaliteit of training. Vindplaats Dit wordt afgeleid uit een statuswijziging in de GL_JE_HEADERS tabel wanneer de APPROVAL_STATUS_CODE wordt bijgewerkt naar 'REJECTED'. De workflow historie zal de gebruiker en timestamp voor deze actie loggen. Vastleggen Volg de timestamp wanneer APPROVAL_STATUS_CODE in GL_JE_HEADERS is ingesteld op 'REJECTED'. Gebeurtenistype inferred
	Journaalpost beoordeeld	Een beoordelingsstap die kan plaatsvinden voor of als onderdeel van het formele goedkeuringsproces. Dit betreft een controle door een collega of manager om de nauwkeurigheid en naleving te waarborgen voordat de journaalpost naar de uiteindelijke goedkeurder gaat.
Het belang Het isoleren van deze activiteit helpt om te differentiëren tussen voorlopige beoordelingstijden en definitieve goedkeuringstijden. Het kan verborgen knelpunten onthullen als de beoordelingsfase informeel maar tijdrovend is. Vindplaats Dit kan een expliciete stap zijn in een meerfasen goedkeuringsworkflow, vastgelegd in workflow historie tabellen. Indien informeel, wordt het niet vastgelegd. Het kan worden afgeleid als een specifieke gebruikersactie wordt gelogd vóór de definitieve goedkeuringsbeslissing. Vastleggen Analyseer workflow-geschiedenistabellen voor tussentijdse goedkeurings- of beoordelingsstappen vóór de definitieve 'Goedgekeurd'-status. Gebeurtenistype inferred
	Journaalpost gecorrigeerd en opnieuw ingediend	Nadat een journaalpost is afgekeurd, voert de aanmaker de nodige correcties uit en dient deze opnieuw in ter goedkeuring. Deze activiteit vertegenwoordigt het begin van een nieuwe goedkeuringscyclus voor dezelfde journaalpost.
Het belang Het volgen van herbewerking is essentieel voor het begrijpen van procesinefficiëntie. Deze activiteit, gecombineerd met 'Journal Entry Rejected', maakt het mogelijk om de herbewerkingstijd en -frequentie te meten. Vindplaats Dit is een daaropvolgende 'Journal Submitted For Approval' gebeurtenis voor een journaal dat eerder in een 'REJECTED' staat verkeerde. Het wordt geïdentificeerd door de sequentie van statuswijzigingen voor een enkele Journaalboeking ID te analyseren. Vastleggen Identificeer een indienings-event timestamp die optreedt na een afwijzings-event voor dezelfde case ID. Gebeurtenistype inferred
	Journaalpost omkering verwerkt	Een omkeerjournaalpost is aangemaakt en geboekt om de financiële impact van de oorspronkelijke journaalpost in een volgende periode ongedaan te maken. Dit is een veelvoorkomende actie voor transitorische posten.
Het belang Het volgen van omkeringen helpt bij het identificeren van soorten boekingen die frequent worden omgekeerd en het analyseren van de efficiëntie van het omkeringsproces zelf. Dit kan duiden op problemen met periodiseringsbeheer. Vindplaats Dit wordt afgeleid door een nieuwe journaalboeking te identificeren die expliciet is gekoppeld aan het origineel als diens omkering. De GL_JE_HEADERS tabel heeft velden zoals REVERSAL_PERIOD en REVERSAL_FLAG om deze boekingen te identificeren en te koppelen. Vastleggen Identificeer de aanmaak- en boekingsdatum van de nieuwe journaalpost waarvan de header verwijst naar de oorspronkelijke journaalpost als zijnde omgekeerd. Gebeurtenistype inferred
	Ondersteunende documentatie bijgevoegd	Vertegenwoordigt de actie van het bijvoegen van ondersteunende documenten, zoals facturen of spreadsheets, aan de journaalboeking. Dit wordt vaak gedaan om context en bewijsmateriaal te leveren voor auditors en goedkeurders.
Het belang Het volgen van deze activiteit helpt te begrijpen of vertragingen worden veroorzaakt door ontbrekende documentatie. Het biedt ook inzichten in compliance en de volledigheid van journaalboekingen voordat ze de goedkeuringsworkflow ingaan. Vindplaats Dit kan moeilijk zijn om als een discrete gebeurtenis te volgen. Het kan worden afgeleid uit timestamps in bijlagentabellen zoals FND_ATTACHED_DOCUMENTS, gekoppeld aan de journaalboekingsrecord in GL_JE_HEADERS. Vastleggen Afleiden uit de aanmaakdatum van records in FND_ATTACHED_DOCUMENTS gekoppeld aan de journaalpost. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractie Guides

Zo haal je je data uit Oracle Fusion Financials

Stappen

Navigeer naar de Reports and Analytics Work Area: Log in bij Oracle Fusion Financials. Gebruik het Navigator-menu om naar Tools te gaan en selecteer vervolgens Reports and Analytics. Dit is de centrale hub voor het aanmaken en beheren van alle analyses en rapporten.
Maak een BI Publisher Data Model: In plaats van te beginnen met een OTBI Analysis, is het voor dit type event log extractie effectiever om direct een BI Publisher Data Model aan te maken. Dit stelt u in staat om een aangepaste SQL query met UNION ALL statements te gebruiken. Klik op de knop 'Browse Catalog', navigeer naar een geschikte map en kies Create > Data Model.
Definieer de SQL Query Dataset: Klik in de Data Model editor op het '+'-icoon om een nieuwe Data Set toe te voegen en selecteer 'SQL Query'. Geef de dataset een omschrijvende naam, bijvoorbeeld 'JournalEventLog'.
Voer de SQL Query in: Selecteer 'Oracle BI EE' als de Data Source. Kopieer het complete SQL-script uit het gedeelte Query hieronder en plak het in het SQL Query tekstgebied. De query is ontworpen om alle vereiste activities en attributes in één uniforme structuur op te halen.
Definieer Parameters: De meegeleverde query gebruikt parameters zoals :start_date, :end_date en :ledger_name. De data model interface detecteert deze automatisch. U moet ze configureren als parameters, waarbij u de juiste datatypes (Date of Text) en, indien nodig, standaardwaarden instelt. Dit maakt een flexibele rapportuitvoering mogelijk.
Creëer een Rapport vanuit het Data Model: Nadat u het data model heeft opgeslagen, navigeert u terug naar de catalogus. Klik op Create > Report. Selecteer in de rapportcreatie-wizard 'Use Existing Data Model' en zoek het data model dat u zojuist heeft aangemaakt.
Configureer de Rapportlay-out: Kies in de lay-outeditor de 'Table' lay-out. Het is cruciaal om alle kolommen van het data model naar de tabel te slepen om ervoor te zorgen dat ze in de export worden opgenomen. Er is geen behoefte aan complexe opmaak.
Stel Standaard Uitvoer in op CSV: Ga naar de link 'View a List' in de rapporteditor. Zorg ervoor dat in de sectie 'Output Formats' 'CSV' is geselecteerd. Het wordt aanbevolen om alle andere formaten uit te vinken om de planning te vereenvoudigen. Sla het rapport op.
Plan het Rapport voor Geautomatiseerde Extractie: Zoek uw opgeslagen rapport in de catalogus en klik op 'More', vervolgens 'Schedule'. Creëer een nieuwe planningsbaan. Configureer de frequentie, bijvoorbeeld dagelijks of wekelijks.
Configureer Export en Levering: Geef in het 'Output'-tabblad van de planningsbaan de uitvoerdetails op. Selecteer uw rapport en kies 'CSV' als formaat. In het 'Destination'-tabblad kunt u de levering van het bestand configureren naar een content server locatie (UCM) of een externe SFTP-server voor geautomatiseerde retrieval.
Haal de Data op en Bereid deze voor: Zodra de geplande taak is uitgevoerd, haalt u het gegenereerde CSV-bestand op van uw geconfigureerde bestemming. Zorg ervoor dat de kolomheaders overeenkomen met de vereisten voor ProcessMind ingestie: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc. Het bestand is nu klaar voor upload.

Configuratie

Data Source: De query moet worden uitgevoerd op de 'Oracle BI EE' data source binnen BI Publisher, die verbinding maakt met de onderliggende transactionele database views die OTBI ondersteunen.
Key Subject Areas (ter referentie): De querylogica is gebaseerd op data die voornamelijk te vinden is in het 'General Ledger - Journals Real Time' subject area. Het koppelt ook logisch data die te vinden zou zijn in 'HCM - Workforce Management - Worker Assignment Real Time' voor gebruikersdetails en mogelijk workflow subject areas voor goedkeuringshistorie.
Date Range Filtering: Het is cruciaal om de data te filteren tot een beheersbare periode. De query bevat :start_date en :end_date parameters. We raden aan om 3 tot 6 maanden aan data te extraheren voor een initiële analyse. De filter wordt toegepast op de aanmaakdatum van de journaalpost.
Ledger Filtering: Gebruik de :ledger_name parameter om de extractie te beperken tot een specifiek primair grootboek. Het extraheren van alle grootboeken tegelijk kan resulteren in extreem grote bestanden en performance issues.
Prerequisites: De gebruiker die het rapport aanmaakt en plant, moet de juiste BI-rollen hebben, zoals 'BI Administrator' of 'BI Author'. Bovendien moet het data security profile van de gebruiker toegang verlenen tot de specifieke grootboeken en business units die worden opgevraagd.
Scheduling: Voor optimale performance en om impact op systeemgebruikers te voorkomen, plant u de extractietaak in tijdens daluren, zoals 's nachts.

a Voorbeeldquery 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

Stappen

Navigeer naar BI Publisher: Log in bij Oracle Fusion Financials. Gebruik het Navigator-menu om naar Tools te gaan en selecteer vervolgens Reports and Analytics. Dit opent de Business Intelligence catalogus.
Maak een nieuw Data Model: Klik in de BI catalogus op de knop Create en selecteer Data Model. Dit opent de data model editor.
Definieer de SQL Query Dataset: Klik in de data model editor op het plus-icoon op het Diagram-tabblad en selecteer SQL Query. Geef in het nieuwe dialoogvenster de dataset een naam, bijvoorbeeld ProcessMind_JE_EventLog. Selecteer de juiste Data Source, wat doorgaans FUSIONDB is. Plak de complete meegeleverde SQL query in het SQL Query tekstgebied.
Definieer Parameters: De query gebruikt parameters voor het datumbereik (p_start_date en p_end_date). Oracle BI Publisher detecteert deze automatisch. U dient ze te configureren als Teksttype parameters en gebruiksvriendelijke labels in te stellen zoals 'Start Date (YYYY-MM-DD)' en 'End Date (YYYY-MM-DD)'.
Sla het Data Model op: Nadat u de query heeft geplakt en parameters heeft gedefinieerd, klikt u op OK en slaat u het data model op in een geschikte map, bijvoorbeeld Shared Folders/Custom/ProcessMining.
Creëer het Rapport: Klik op de knop Create Report in de rechterbovenhoek van de data model editor. De rapportcreatie-wizard wordt gestart.
Configureer de Rapportlay-out: Selecteer in de wizard de optie om het huidige data model te gebruiken. Kies de 'Table' lay-out. Sleep alle kolommen van de data source naar het tabel lay-outgebied. Schakel de optie 'Show Grand Totals Row' uit.
Sla het Rapport op: Sla het rapport op in dezelfde map als het data model. Geef het een omschrijvende naam zoals 'Journal Entry Event Log Report'.
Stel Standaard Uitvoerformaat in: Bewerk het rapport en navigeer naar het 'Viewing'-tabblad. Zorg er onder 'Output Formats' voor dat CSV is geselecteerd en stel dit bij voorkeur in als het standaardformaat. Dit waarborgt dat de uitvoer compatibel is voor direct gebruik.
Uitvoeren en Exporteren: Open het rapport en u wordt gevraagd om de start- en einddatumparameters in te voeren. Voer het gewenste datumbereik in en klik op Apply. Zodra het rapport wordt uitgevoerd, klikt u op de knop Export en kiest u het CSV-formaat om het event log bestand te downloaden.
Voorbereiden voor Upload: Open het gedownloade CSV-bestand. Controleer of de kolomheaders overeenkomen met de verwachte attribuutnamen (JournalEntryId, ActivityName, EventTime, etc.) en of de data correct is geformatteerd voordat u uploadt naar het ProcessMind platform.

Configuratie

Prerequisites: De gebruiker die het rapport uitvoert, moet een rol hebben met de nodige data security privileges om General Ledger data te benaderen, zoals General Accountant of een aangepaste BI-rol. Toegang tot de BI Publisher tool is ook vereist.
Data Source: Het BI Publisher Data Model moet worden geconfigureerd om de FUSIONDB applicatiedatabaseverbinding te gebruiken.
Date Range Parameters: De query is ontworpen met p_start_date en p_end_date parameters om het data-extractievenster te beheren. Het wordt aanbevolen om te beginnen met een periode van 3 tot 6 maanden aan data om de performance te waarborgen.
Report Filters: Voor grote organisaties wordt sterk aanbevolen om filters direct toe te voegen aan de WHERE clause van de JournalHeaders common table expression van de query. Filteren op LEDGER_ID of LEGAL_ENTITY_ID is essentieel om datavolume te beheren.
Performance Considerations: Het uitvoeren van deze query op een grote productiedatabase kan aanzienlijke resources verbruiken. Plan het rapport in tijdens daluren om de impact op de systeemprestaties te minimaliseren.
Output Format: Het rapport moet worden geconfigureerd om uit te voeren als een CSV-bestand. Dit biedt een schoon, gestructureerd formaat voor ingestie in process mining tools.

a Voorbeeldquery 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"

Stappen

Prerequisites: Zorg ervoor dat Python 3 is geïnstalleerd, samen met de requests en pandas libraries. U hebt een gebruikersaccount nodig voor Oracle Fusion Financials met de nodige permissies om de General Ledger Journals REST API te benaderen. Verkrijg uw Oracle Fusion instance URL, gebruikersnaam en wachtwoord.
Script Setup: Creëer een nieuw Python-scriptbestand. Begin met het importeren van de benodigde libraries: requests, json, pandas en datetime.
Configuration: Definieer in het script variabelen voor uw Oracle Fusion credentials en de basis URL. Stel ook parameters in voor de data-extractie, zoals de start- en einddatums voor de query.
Authentication: Het script gebruikt Basic Authentication. De requests library handelt de encoding van de gebruikersnaam en het wachtwoord in de request headers af.
Define API Call Function: Creëer een functie om de API requests af te handelen. Deze functie moet paginatie beheren door gebruik te maken van de offset en limit parameters. Het zal loopen en opeenvolgende API calls uitvoeren totdat alle journaalpostrecords binnen het opgegeven datumbereik zijn opgehaald.
Construct API Query: Gebruik de q parameter in de API request om journaalposten te filteren op basis van de LastUpdateDate. Dit maakt gerichte data-extractie binnen een specifiek tijdsbestek mogelijk, bijvoorbeeld LastUpdateDate between '2023-01-01' and '2023-03-31'.
Initiate Data Retrieval: Roep de functie aan om data op te halen van het .../fscmRestApi/resources/11.13.18.05/journals endpoint. De functie retourneert een complete lijst met journaalposten.
Process and Transform Data: Itereer door elke journaalpost die door de API wordt geretourneerd. Genereer voor elke journaalpost meerdere event-rijen die overeenkomen met de verschillende business activities (Journaalpost aangemaakt, Journaalpost goedgekeurd, etc.). Gebruik de datumvelden en statuscodes uit de API response (CreationDate, PostedDate, ApprovalStatus, etc.) om deze afzonderlijke events te creëren.
Structure Event Log: Telkens wanneer een event-rij wordt gegenereerd, slaat u deze op als een dictionary in een lijst. Deze lijst wordt de ruwe data voor uw event log.
Create DataFrame: Zodra alle journaalposten zijn verwerkt, converteert u de lijst met event-dictionaries naar een Pandas DataFrame voor eenvoudigere manipulatie.
Finalize Columns: Selecteer en hernoem de DataFrame-kolommen om te voldoen aan het vereiste schema voor ProcessMind: JournalEntryId, ActivityName, EventTime, UserName, etc.
Export to CSV: Sla de uiteindelijke DataFrame op naar een CSV-bestand. Dit bestand kan vervolgens direct naar ProcessMind worden geüpload voor analyse.

Configuratie

Credentials: Een geldige Oracle Fusion gebruikersnaam en wachtwoord zijn vereist voor Basic Authentication.
Instance URL: De basis URL van uw Oracle Fusion Financials instance is nodig om het API endpoint samen te stellen (bijv. https://[your-instance].fa.us2.oraclecloud.com).
API Endpoint: Het script richt zich op het fscmRestApi/resources/11.13.18.05/journals endpoint voor het ophalen van General Ledger data.
Date Range Filter: Het script moet worden geconfigureerd met een start_date en end_date om de omvang van de extractie te beperken. Voor een initiële analyse wordt een periode van 3 tot 6 maanden aanbevolen. Voor continu gebruik configureert u het voor dagelijkse of wekelijkse incrementele loads.
Pagination Limit: De limit parameter regelt hoeveel records per API call worden opgehaald. Een waarde tussen 200 en 500 is doorgaans efficiënt, wat het aantal API calls balanceert met de grootte van elke response.
Required Oracle Roles: De gebruikersaccount moet een rol hebben met de nodige privileges om journaalpostdata te lezen via de REST API, zoals General Accountant of een aangepaste rol met gelijkwaardige permissies.

a Voorbeeldquery 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.")

Stappen

Navigeer naar de Reports and Analytics Work Area: Log in bij Oracle Fusion Financials. Gebruik het Navigator-menu om naar Tools te gaan en selecteer vervolgens Reports and Analytics. Dit is de centrale hub voor het aanmaken en beheren van alle analyses en rapporten.
Maak een BI Publisher Data Model: In plaats van te beginnen met een OTBI Analysis, is het voor dit type event log extractie effectiever om direct een BI Publisher Data Model aan te maken. Dit stelt u in staat om een aangepaste SQL query met UNION ALL statements te gebruiken. Klik op de knop 'Browse Catalog', navigeer naar een geschikte map en kies Create > Data Model.
Definieer de SQL Query Dataset: Klik in de Data Model editor op het '+'-icoon om een nieuwe Data Set toe te voegen en selecteer 'SQL Query'. Geef de dataset een omschrijvende naam, bijvoorbeeld 'JournalEventLog'.
Voer de SQL Query in: Selecteer 'Oracle BI EE' als de Data Source. Kopieer het complete SQL-script uit het gedeelte Query hieronder en plak het in het SQL Query tekstgebied. De query is ontworpen om alle vereiste activities en attributes in één uniforme structuur op te halen.
Definieer Parameters: De meegeleverde query gebruikt parameters zoals :start_date, :end_date en :ledger_name. De data model interface detecteert deze automatisch. U moet ze configureren als parameters, waarbij u de juiste datatypes (Date of Text) en, indien nodig, standaardwaarden instelt. Dit maakt een flexibele rapportuitvoering mogelijk.
Creëer een Rapport vanuit het Data Model: Nadat u het data model heeft opgeslagen, navigeert u terug naar de catalogus. Klik op Create > Report. Selecteer in de rapportcreatie-wizard 'Use Existing Data Model' en zoek het data model dat u zojuist heeft aangemaakt.
Configureer de Rapportlay-out: Kies in de lay-outeditor de 'Table' lay-out. Het is cruciaal om alle kolommen van het data model naar de tabel te slepen om ervoor te zorgen dat ze in de export worden opgenomen. Er is geen behoefte aan complexe opmaak.
Stel Standaard Uitvoer in op CSV: Ga naar de link 'View a List' in de rapporteditor. Zorg ervoor dat in de sectie 'Output Formats' 'CSV' is geselecteerd. Het wordt aanbevolen om alle andere formaten uit te vinken om de planning te vereenvoudigen. Sla het rapport op.
Plan het Rapport voor Geautomatiseerde Extractie: Zoek uw opgeslagen rapport in de catalogus en klik op 'More', vervolgens 'Schedule'. Creëer een nieuwe planningsbaan. Configureer de frequentie, bijvoorbeeld dagelijks of wekelijks.
Configureer Export en Levering: Geef in het 'Output'-tabblad van de planningsbaan de uitvoerdetails op. Selecteer uw rapport en kies 'CSV' als formaat. In het 'Destination'-tabblad kunt u de levering van het bestand configureren naar een content server locatie (UCM) of een externe SFTP-server voor geautomatiseerde retrieval.
Haal de Data op en Bereid deze voor: Zodra de geplande taak is uitgevoerd, haalt u het gegenereerde CSV-bestand op van uw geconfigureerde bestemming. Zorg ervoor dat de kolomheaders overeenkomen met de vereisten voor ProcessMind ingestie: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc. Het bestand is nu klaar voor upload.

Configuratie

Data Source: De query moet worden uitgevoerd op de 'Oracle BI EE' data source binnen BI Publisher, die verbinding maakt met de onderliggende transactionele database views die OTBI ondersteunen.
Key Subject Areas (ter referentie): De querylogica is gebaseerd op data die voornamelijk te vinden is in het 'General Ledger - Journals Real Time' subject area. Het koppelt ook logisch data die te vinden zou zijn in 'HCM - Workforce Management - Worker Assignment Real Time' voor gebruikersdetails en mogelijk workflow subject areas voor goedkeuringshistorie.
Date Range Filtering: Het is cruciaal om de data te filteren tot een beheersbare periode. De query bevat :start_date en :end_date parameters. We raden aan om 3 tot 6 maanden aan data te extraheren voor een initiële analyse. De filter wordt toegepast op de aanmaakdatum van de journaalpost.
Ledger Filtering: Gebruik de :ledger_name parameter om de extractie te beperken tot een specifiek primair grootboek. Het extraheren van alle grootboeken tegelijk kan resulteren in extreem grote bestanden en performance issues.
Prerequisites: De gebruiker die het rapport aanmaakt en plant, moet de juiste BI-rollen hebben, zoals 'BI Administrator' of 'BI Author'. Bovendien moet het data security profile van de gebruiker toegang verlenen tot de specifieke grootboeken en business units die worden opgevraagd.
Scheduling: Voor optimale performance en om impact op systeemgebruikers te voorkomen, plant u de extractietaak in tijdens daluren, zoals 's nachts.

a Voorbeeldquery 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

Uw Record to Report - Journaalboeking Data Template

Uw Record to Report - Journaalboeking Data Template

Record to Report - Journaalboeking attributes

Record to Report - Activiteiten van Journaalboekingen

Extractie Guides

Oracle OTBI en BI Publisher Rapport Export

Stappen

Configuratie

a Voorbeeldquery config

BI Publisher Rapport met Directe SQL Data Model Query

Stappen

Configuratie

a Voorbeeldquery sql

Python-script met Oracle Fusion Financials REST API

Stappen

Configuratie

a Voorbeeldquery python

Bulkdata-extractie met BI Cloud Connector (BICC)

Stappen

Configuratie

a Voorbeeldquery config

Klaar om te starten?

Versnel uw Record to Report - Journaalpostenproces vandaag nog

Uw Record to Report - Journaalboeking Data Template

Uw Record to Report - Journaalboeking Data Template

Record to Report - Journaalboeking attributes

Record to Report - Activiteiten van Journaalboekingen

Extractie Guides

Oracle OTBI en BI Publisher Rapport Export

Stappen

Configuratie

a Voorbeeldquery config

BI Publisher Rapport met Directe SQL Data Model Query

Stappen

Configuratie

a Voorbeeldquery sql

Python-script met Oracle Fusion Financials REST API

Stappen

Configuratie

a Voorbeeldquery python

Bulkdata-extractie met BI Cloud Connector (BICC)

Stappen

Configuratie

a Voorbeeldquery config

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Versnel uw Record to Report - Journaalpostenproces vandaag nog