> Continu verbeteren van processen > Van vastlegging tot rapportage: journaalposten > Oracle Fusion Financials > Datatemplate

Datatemplate voor Record to Report - journaalposten

Oracle Fusion Financials

← Terug naar de verbetergids

Attributen voor Record to Report - journaalposten(21) Activiteiten voor Record to Report - journaalposten(12) Extractiegidsen(4)

Datatemplate voor Record to Report - journaalposten

Deze datatemplate helpt je bij het extraheren en structureren van data over journaalposten in Oracle Fusion Financials. Je vindt hierin de attributen die je verzamelt en de activiteiten die je volgt, zodat je de nodige informatie hebt voor een goede procesanalyse. Ook lees je hoe je deze data rechtstreeks uit het systeem haalt.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om te volgen
Instructies voor data-extractie uit Oracle Fusion Financials

Nieuw met event logs? Lees hoe je een event log voor process mining maakt.

Template downloaden

Attributen voor Record to Report - journaalposten

Dit zijn de aanbevolen datavelden voor je event log, zodat je het proces voor Record to Report - journaalposten volledig kunt analyseren.

5 Verplicht 6 Aanbevolen 10 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De naam van de bedrijfsgebeurtenis of taak die op een bepaald moment in het proces van de journaalpost plaatsvond.
Beschrijving De activiteitsnaam beschrijft één stap in de levenscyclus van een journaalpost, zoals 'Journal Entry Created' of 'Journal Entry Approved'. Deze data is nodig om de proceskaart op te bouwen en de volgorde van gebeurtenissen te begrijpen. Door activiteiten te analyseren, kun je het procesverloop in kaart brengen, inclusief standaardroutes, afwijkingen en herstelwerk. Door verschillende activiteiten bij te houden, meet je hoeveel tijd specifieke fasen kosten, zoals goedkeuring, en zie je welke stappen de meeste tijd kosten of vaak fouten opleveren. Waarom dit belangrijk is De activiteit bepaalt de processtappen en vormt de basis van de proceskaart. Hiermee kun je het procesverloop, bottlenecks en variaties analyseren. Waar vind je dit? Dit attribuut wordt meestal afgeleid uit statuswijzigingen, event logs of auditsporen van journaalposten in de grootboekmodule. Voorbeelden Journaalpost aangemaaktJournaalpost ter goedkeuring ingediendJournaalpost goedgekeurdJournaalpost geboekt
	Journal Entry ID JournalEntryId	De unieke identificatiecode van één journaalpost, die alle bijbehorende financiële transacties met elkaar verbindt.
Beschrijving De Journal Entry ID is de primaire case-identificatie en koppelt alle activiteiten aan een specifieke reeks financiële transacties. Zo kun je de volledige levenscyclus van één journaalpost volgen, van de start tot de definitieve boeking, en controleren of alle debet- en creditbedragen zijn verantwoord. In process mining is deze ID essentieel om het volledige verloop van elke journaalpost te reconstrueren. De ID verbindt afzonderlijke gebeurtenissen, zoals 'Journal Entry Created', 'Journal Submitted For Approval' en 'Journal Entry Posted', tot één samenhangend proces. Zo kun je doorlooptijden, bottlenecks en procesvariaties analyseren. Waarom dit belangrijk is Dit is de belangrijkste sleutel om een journaalpost van begin tot eind te volgen en het volledige proces voor elke unieke case te analyseren. Waar vind je dit? Dit is een primaire sleutel in kerntabellen van het grootboek, zoals GL_JE_HEADERS en GL_JE_LINES. Voorbeelden JE100523JE202311001882019
	Starttijd EventTime	Het tijdstip waarop een specifieke activiteit of gebeurtenis plaatsvond.
Beschrijving Deze timestamp geeft de exacte datum en tijd aan waarop een activiteit is uitgevoerd. In process mining is dit het belangrijkste tijdsgegeven om de volgorde van gebeurtenissen vast te stellen en de tijd ertussen te berekenen. Een nauwkeurige gebeurtenistijd is essentieel voor alle tijdsanalyses, zoals het berekenen van doorlooptijden, het opsporen van bottlenecks en het bewaken van prestaties ten opzichte van service level agreements. De timestamp geeft de chronologische volgorde die nodig is om het procesverloop te reconstrueren. Waarom dit belangrijk is Deze timestamp is nodig om gebeurtenissen te ordenen, alle procesduren te berekenen en tijdsanalyses uit te voeren. Waar vind je dit? Deze informatie staat meestal in auditsporen of als 'Last Update Date' of 'Creation Date' in 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 vandaan komt.
Beschrijving Dit attribuut geeft aan uit welk bronsysteem de procesdata is gehaald. In een complexe IT-omgeving kan data uit meerdere gekoppelde systemen komen. Met dit veld kun je de herkomst onderscheiden. Bij procesanalyse helpt de kennis van het bronsysteem om variaties te begrijpen die door verschillen tussen systemen ontstaan. Ook kun je data valideren en problemen oplossen door de data naar de bron terug te volgen. Waarom dit belangrijk is Geeft aan waar de data vandaan komt. Dat is belangrijk voor datagovernance, validatie en inzicht in procesvariaties tussen systemen. Waar vind je dit? Dit is vaak een vaste waarde die tijdens de data-extractie wordt ingesteld. Het kan ook een veld in de brontabellen zijn dat het invoersysteem aangeeft. Voorbeelden Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Laatste data-update LastDataUpdate	Het tijdstip van de meest recente data-update of extractie uit het bronsysteem.
Beschrijving Dit attribuut registreert wanneer de dataset voor het laatst is bijgewerkt. Zo weet je hoe actueel de data is waarop de analyse is gebaseerd. Voor elke analyse, en zeker voor operationele dashboards, is het belangrijk te weten wanneer de data voor het laatst is bijgewerkt. Zo kunnen gebruikers de data beoordelen en weloverwogen beslissingen nemen. Het tijdstip maakt duidelijk tot wanneer de data in het process mining-model loopt. Waarom dit belangrijk is Geeft aan hoe actueel de data is, zodat gebruikers weten hoe recent de procesanalyse is en de resultaten kunnen beoordelen. Waar vind je dit? Deze waarde wordt gegenereerd en opgeslagen tijdens de data-extractie en -transformatie. Meestal is dit het tijdstip waarop de ETL/ELT-taak is afgerond. Voorbeelden 2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
	Afdeling van gebruiker UserDepartment	De afdeling of het team waartoe de gebruiker behoort die de activiteit heeft uitgevoerd.
Beschrijving Dit attribuut geeft organisatorische context door een activiteit te koppelen aan een afdeling, zoals 'Finance', 'Accounting Operations' of 'Internal Audit'. De gegevens komen meestal uit de gebruikersstamgegevens. Met een analyse per gebruikersafdeling kun je bottlenecks tussen afdelingen opsporen, teamprestaties vergelijken en zien hoe de uitvoering van processen binnen de organisatie verschilt. Dit helpt bij de verdeling van middelen en bij gerichte procesverbeteringen. Waarom dit belangrijk is Geeft organisatorische context, zodat je prestaties per team of afdeling kunt analyseren en inefficiënties tussen afdelingen kunt opsporen. Waar vind je dit? Deze informatie staat meestal niet in de transactietabellen. Je moet UserName koppelen aan een tabel met gebruikersstamgegevens of aan data uit het HR-systeem. Voorbeelden Algemene boekhoudingFinanciële verslagleggingCrediteurenadministratie
	Bedrag journaalpost JournalAmount	De totale geldwaarde van de journaalpost, meestal de som van de debetbedragen.
Beschrijving Dit attribuut geeft de totale financiële waarde van de journaalpost weer. Het bedrag kan invloed hebben op het proces. Voor posten met een hoge waarde kunnen bijvoorbeeld extra goedkeuringsstappen of grondigere controles nodig zijn. Door het bedrag van de journaalpost te analyseren, kun je cases indelen op basis van hun financiële impact. Zo kun je vragen beantwoorden als: 'Worden posten met een hoge waarde langzamer goedgekeurd?' of 'Worden posten boven een bepaald bedrag vaker afgewezen?'. Dit geeft belangrijke bedrijfscontext bij het procesverloop. Waarom dit belangrijk is Geeft belangrijke bedrijfscontext voor analyses op basis van financiële impact en helpt vaststellen of posten met een hoge waarde een ander proces volgen. Waar vind je dit? Deze waarde wordt meestal berekend als de som van de debet- of creditbedragen in de tabel GL_JE_LINES voor een journaalpost. Voorbeelden 5000.00125000.75750.50
	Gebruiker UserName	De gebruiker die de activiteit heeft uitgevoerd, bijvoorbeeld door de journaalpost aan te maken, goed te keuren of te boeken.
Beschrijving Dit attribuut geeft aan welke medewerker of systeemgebruiker verantwoordelijk was voor een activiteit. Zo kun je de werkverdeling en prestaties bekijken en individuele bottlenecks opsporen. Met UserName kun je processen filteren op gebruiker, de efficiëntie van gebruikers vergelijken en oorzaken van vertragingen of fouten onderzoeken. Het ondersteunt dashboards zoals 'User Workload & Efficiency Across Teams' en KPI's zoals de 'User Journal Bottleneck Index'. Waarom dit belangrijk is Koppelt processtappen aan de verantwoordelijke gebruiker. Zo kun je de werkbelasting, individuele prestaties en opleidingsbehoeften analyseren. Waar vind je dit? Te vinden in transactietabellen zoals GL_JE_HEADERS (bijvoorbeeld CREATED_BY en LAST_UPDATED_BY) en in bijbehorende auditsporen. Voorbeelden john.doesusan.smithautoprocess_user
	Journaalbron JournalSource	Het subgrootboek of de bron die de journaalpost heeft aangemaakt, zoals 'Payables', 'Receivables' of 'Manual'.
Beschrijving Dit attribuut geeft aan waar de journaalpost in het ERP-systeem vandaan komt. Je kunt posten handmatig aanmaken in het grootboek of ze automatisch laten genereren vanuit subgrootboeken, zoals crediteuren, debiteuren of vaste activa. De journaalbron is belangrijk voor automatiseringsanalyses. Je kunt handmatig aangemaakte posten onderscheiden van systeemgegenereerde posten. Dat ondersteunt de KPI 'Automated Journal Entry Rate'. Processen voor posten uit verschillende bronnen verschillen vaak sterk in complexiteit en efficiëntie. Waarom dit belangrijk is Maakt onderscheid tussen handmatige en automatische posten. Dat is belangrijk om automatiseringspercentages te meten en procesverschillen te analyseren. Waar vind je dit? Beschikbaar in de tabel GL_JE_HEADERS, meestal in een veld met de naam JE_SOURCE. Voorbeelden HandmatigCrediteurenActivaDebiteuren
	Journaalcategorie JournalCategory	De categorie van de journaalpost, zoals 'Accrual', 'Adjustment' of 'Reclassification'.
Beschrijving De journaalcategorie deelt posten in op basis van hun bedrijfsdoel. Zo kun je het proces gedetailleerder analyseren, omdat categorieën verschillende procesroutes, goedkeuringsregels of doorlooptijden kunnen hebben. Een journaalpost voor een correctie aan het einde van de maand kan bijvoorbeeld een complexer en urgenter proces doorlopen dan een reguliere overlopende post. Door het proces per categorie te analyseren, zie je deze verschillen en kun je verbeteringen afstemmen op specifieke soorten journaalposten. Waarom dit belangrijk is Hiermee kun je het proces indelen naar het bedrijfsdoel van de journaalpost en verschillen in gedrag en prestaties tussen soorten posten zichtbaar maken. Waar vind je dit? Beschikbaar in de tabel GL_JE_HEADERS, meestal in een veld met de naam JE_CATEGORY. Voorbeelden Overlopende postHandmatigCorrectieHerwaardering
	Reden van afwijzing RejectionReason	Een tekstuele beschrijving of code die uitlegt waarom een journaalpost is afgewezen.
Beschrijving Als een journaalpost tijdens de goedkeuring wordt afgewezen, legt dit attribuut de reden vast. Dit kan een vooraf bepaalde code zijn of een opmerking van de goedkeurder in vrije tekst. Dit is een van de belangrijkste attributen voor oorzaakanalyse van procesinefficiënties. Door de meest voorkomende afwijsredenen te analyseren, kunnen organisaties verbeterpunten vinden, zoals betere training voor opstellers, duidelijkere richtlijnen of betere systeemcontroles. Het ondersteunt rechtstreeks het dashboard 'Journal Entry Rejection Rate Analysis'. Waarom dit belangrijk is Geeft inzicht in de oorzaken van herstelwerk en procesvertragingen, zodat je gericht verbeteringen kunt doorvoeren en het aantal afwijzingen kunt terugdringen. Waar vind je dit? Deze informatie staat mogelijk in workflow- of auditsporen van het goedkeuringsproces, of in een notitieveld in de journaalkop. Voorbeelden Onjuiste rekeningcombinatieOnvoldoende ondersteunende documentatieOverschrijdt budget
	Beoogde boekingsdatum TargetPostingDate	De vooraf bepaalde datum waarop de journaalpost naar verwachting is geboekt.
Beschrijving De beoogde boekingsdatum is de deadline voor het boeken van een journaalpost in het grootboek. Deze datum wordt vaak bepaald door service level agreements (SLA's) of de planning van de maandafsluiting en dient als maatstaf voor prestaties. Dit attribuut is nodig om de KPI 'On-Time Journal Posting Rate' te berekenen. Door de werkelijke boekingsdatum met de beoogde datum te vergelijken, kan het systeem posten automatisch als op tijd of te laat markeren. Zo zie je duidelijk of het proces de planning volgt. Waarom dit belangrijk is Bepaalt de service level agreement of deadline voor het boeken en maakt het mogelijk KPI's voor tijdige verwerking te berekenen. Waar vind je dit? Dit is mogelijk geen standaardveld. Je kunt de waarde afleiden uit bedrijfsregels op basis van de aanmaakdatum, boekingsperiode of journaalcategorie. Voorbeelden 2023-10-312023-11-302024-01-05
	Boekingsperiode AccountingPeriod	De boekingsperiode waarin de journaalpost is geboekt, zoals 'Jan-24'.
Beschrijving De boekingsperiode geeft aan in welke financiële periode de transactie wordt verantwoord. Dit is de basis voor financiële rapportage en analyse. In process mining is dit attribuut belangrijk voor trendanalyses. Je kunt procesprestaties, zoals doorlooptijden of afwijzingspercentages, vergelijken tussen maanden of kwartalen. Zo herken je seizoenspatronen, zoals een hogere werkdruk tijdens de maandafsluiting, en meet je het effect van procesverbeteringen door de tijd heen. Waarom dit belangrijk is Maakt trendanalyse van KPI's door de tijd heen mogelijk. Zo kun je procesverbeteringen meten en seizoenspatronen herkennen, zoals de drukte rond de maandafsluiting. Waar vind je dit? Beschikbaar in de tabel GL_JE_HEADERS, meestal in een veld met de naam PERIOD_NAME. Voorbeelden Jan-24Feb-24Mrt-24
	Boekingsstatus PostingStatus	De huidige boekingsstatus van de journaalpost, bijvoorbeeld 'Unposted' of 'Posted'.
Beschrijving Dit attribuut geeft de huidige status van de journaalpost in het grootboek weer. Het laat zien waar een journaalpost zich in de levenscyclus bevindt, vooral als de case nog loopt. De boekingsstatus is belangrijk voor het dashboard 'Real-Time Journal Entry Status Tracker', dat een momentopname van alle actieve posten geeft. Je kunt achterstanden met niet-geboekte posten volgen en vertragingen in de laatste processtappen opsporen. Waarom dit belangrijk is Geeft de huidige status van een journaalpost aan. Dit is nodig om achterstanden te bewaken en de status van lopende posten te volgen. Waar vind je dit? Beschikbaar in de tabel GL_JE_HEADERS, meestal in een kolom zoals STATUS of POSTING_STATUS. Voorbeelden GeboektNiet geboektFout
	Eindtijd EndTime	Het tijdstip waarop een specifieke activiteit is afgerond.
Beschrijving De eindtijd geeft aan wanneer een activiteit is afgerond. De starttijd registreert het begin; met de eindtijd kun je de verwerkingstijd van die stap nauwkeurig berekenen. Dit is nodig om verwerkingstijden van activiteiten te berekenen, een belangrijke metriek om bottlenecks op te sporen en de efficiëntie van ingezette middelen te meten. Het verschil tussen de eindtijd en starttijd van de activiteit 'Journal Entry Reviewed' laat bijvoorbeeld zien hoeveel tijd een beoordelaar daadwerkelijk aan de taak heeft besteed. Waarom dit belangrijk is Hiermee bereken je de werkelijke duur of verwerkingstijd van afzonderlijke activiteiten. Dat is belangrijk om efficiëntieproblemen op te sporen. Waar vind je dit? Net als de starttijd staat deze vaak in auditsporen. Je kunt de eindtijd ook afleiden uit de starttijd van de volgende activiteit in het proces. Voorbeelden 2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
	Grootboeknaam LedgerName	De naam van het grootboek waarin de journaalpost is vastgelegd.
Beschrijving De grootboeknaam geeft aan bij welk grootboek de journaalpost hoort. Organisaties met meerdere juridische entiteiten of rapportagevereisten kunnen verschillende grootboeken hebben, zoals een primair grootboek voor de bedrijfsboekhouding en secundaire grootboeken voor lokale wettelijke rapportages. Met dit attribuut kun je processen voor verschillende juridische entiteiten of bedrijfseenheden filteren en vergelijken. Zo voer je analyses uit binnen de juiste organisatorische context. Dat is vooral belangrijk voor financiële compliance en rapportage. Waarom dit belangrijk is Hiermee kun je procesanalyses filteren en vergelijken voor verschillende juridische entiteiten of boekhoudkundige kaders. Dit is belangrijk voor grote organisaties. Waar vind je dit? Te vinden in de tabel GL_JE_HEADERS, meestal gekoppeld via LEDGER_ID. Je kunt dit veld koppelen aan GL_LEDGERS om de naam op te halen. Voorbeelden Primair grootboek VSWettelijk grootboek VKWereldwijd consolidatiegrootboek
	Is herstelwerk IsRework	Een berekende vlag die op waar staat als de journaalpost is afgewezen en daarna gecorrigeerd.
Beschrijving Dit booleaanse attribuut wordt berekend om cases te herkennen waarin herstelwerk heeft plaatsgevonden. De waarde wordt meestal op 'true' gezet voor elke activiteit na een gebeurtenis 'Journal Entry Rejected', zoals 'Journal Corrected and Resubmitted'. Met het attribuut Is Rework kun je de omvang en impact van herstelwerk eenvoudig meten. Het ondersteunt rechtstreeks de KPI 'Average Journal Rework Rate' en helpt het procesverloop en de doorlooptijd van aangepaste cases te vergelijken met posten die in één keer goed zijn verwerkt. Waarom dit belangrijk is Markeert cases waarin inefficiënt herstelwerk heeft plaatsgevonden. Zo kun je de frequentie en impact van procesfouten eenvoudig meten. Waar vind je dit? Dit is niet beschikbaar in het bronsysteem. De waarde wordt berekend in de process mining-tool door de activiteitenreeks van elke case te analyseren. Voorbeelden truefalse
	Op tijd geboekt IsOnTimePosting	Een berekende vlag die op waar staat als de journaalpost op of vóór de beoogde datum is geboekt.
Beschrijving Dit booleaanse attribuut wordt afgeleid door de timestamp van de activiteit 'Journal Entry Posted' te vergelijken met de 'Target Posting Date'. Vindt de boeking op of vóór de beoogde datum plaats, dan is de waarde 'true'; anders is deze 'false'. Dit attribuut ondersteunt rechtstreeks de KPI 'On-Time Journal Posting Rate' en vereenvoudigt de berekening. Je kunt te laat geboekte posten eenvoudig filteren en analyseren om veelvoorkomende oorzaken van vertraging te vinden, zoals specifieke journaalcategorieën of goedkeurders. Waarom dit belangrijk is Geeft een duidelijke uitkomst voor de boekingsprestaties en vereenvoudigt de analyse van tijdige boekingen en oorzaken van vertraging. Waar vind je dit? Dit attribuut wordt berekend door de process mining-tool. Hiervoor zijn het attribuut 'TargetPostingDate' en de timestamp van de activiteit 'Journal Entry Posted' nodig. Voorbeelden truefalse
	Tegenboekingsindicator ReversalIndicator	Een vlag die aangeeft of de journaalpost een tegenboeking van een andere post is.
Beschrijving Dit booleaanse attribuut geeft aan welke journaalposten zijn aangemaakt om een eerder geboekte post terug te draaien. Tegenboekingen zijn een specifiek soort journaalpost en volgen vaak een afwijkend, soms problematisch proces. Deze indicator is belangrijk voor het dashboard 'Journal Reversal Process Performance'. Je kunt tegenboekingsprocessen afzonderlijk analyseren en de frequentie, oorzaken en doorlooptijden meten. Zo spoor je onderliggende problemen op in de oorspronkelijke posten die een tegenboeking nodig maken. Waarom dit belangrijk is Helpt het tegenboekingsproces afzonderlijk te analyseren. Tegenboekingen wijzen vaak op fouten of problemen in de oorspronkelijke transactie. Waar vind je dit? Dit kan een specifieke vlag in de tabel GL_JE_HEADERS zijn, zoals ACCRUAL_REV_FLAG. Je kunt tegenboekingen ook herkennen aan koppelingen met de oorspronkelijke journaalpost. Voorbeelden truefalse
	Totale doorlooptijd van begin tot eind EndToEndCycleTime	De totale berekende tijd vanaf het aanmaken van een journaalpost tot de definitieve afstemming.
Beschrijving Deze metriek geeft aan hoeveel tijd een journaalpost in het hele proces doorbrengt, vanaf de eerste gebeurtenis 'Journal Entry Created' tot de laatste gebeurtenis 'Journal Entry Reconciled'. Zo krijg je een volledig beeld van de procesprestaties. Dit is een belangrijke KPI om de algehele procesefficiëntie te meten. Trenddashboards gebruiken deze metriek om het effect van verbeteringen door de tijd heen te volgen. Ook vormt de metriek een uitgangspunt om proceswijzigingen mee te vergelijken. Waarom dit belangrijk is Geeft een totaalbeeld van de gezondheid en efficiëntie van het proces en is daarmee een belangrijke metriek voor rapportages aan het management. Waar vind je dit? Het process mining-platform berekent deze metriek als het tijdsverschil tussen de timestamps van de eerste en laatste gebeurtenis van elke case. Voorbeelden P10DT5HP4DT12HP22D
	Valuta CurrencyCode	De valutacode van het bedrag van de journaalpost, zoals USD, EUR of GBP.
Beschrijving De valutacode geeft aan in welke valuta de financiële bedragen van de journaalpost zijn uitgedrukt. Dit is belangrijk voor multinationale organisaties die met meerdere valuta werken. Met dit attribuut kun je financiële waarden correct interpreteren. Je kunt op valuta filteren en hebt het nodig voor analyses waarin geldbedragen uit verschillende regio's worden vergeleken of samengevoegd. Waarom dit belangrijk is Geeft de nodige context bij financiële bedragen, zodat je deze correct kunt interpreteren en analyses per valuta kunt uitvoeren. Waar vind je dit? Beschikbaar in de tabel GL_JE_HEADERS, meestal in een veld met de naam CURRENCY_CODE. Voorbeelden USDEURGBPJPY

Verplicht Aanbevolen Optioneel

Activiteiten voor Record to Report - journaalposten

Dit zijn de belangrijke processtappen en mijlpalen die je in het event log vastlegt voor een nauwkeurige procesontdekking van journaalposten.

5 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Journaalpost aangemaakt	Deze activiteit markeert het begin van het proces voor journaalposten. Een gebruiker maakt een nieuwe journaalkop aan en begint data in te voeren. De post is dan nog niet ingediend voor beoordeling of goedkeuring.
Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis van het proces. Door de tijd tussen deze activiteit en de volgende stappen te analyseren, kun je de efficiëntie van de eerste gegevensinvoer en de totale doorlooptijd meten. Waar vind je dit? Deze gebeurtenis wordt doorgaans afgeleid van de timestamp van de aanmaakdatum in de tabel GL_JE_HEADERS voor een specifieke Journaalpost-ID. In deze tabel staat ook welke gebruiker de post heeft aangemaakt. Vastleggen Gebruik CREATION_DATE uit de tabel GL_JE_HEADERS. Gebeurtenistype inferred
	Journaalpost afgestemd	De journaalpost is gematcht en afgeletterd tijdens een rekeningafstemming aan het einde van een periode. Zo wordt bevestigd dat de transactie overeenkomt met andere financiële gegevens, zoals bankafschriften.
Waarom dit belangrijk is Deze activiteit vormt het echte eindpunt van de levenscyclus van de journaalpost. De tijd tussen boeken en afstemmen is een belangrijke KPI voor de efficiëntie van het financiële afsluitproces. Waar vind je dit? Deze gebeurtenis wordt meestal vastgelegd in Oracle Financial Consolidation and Close Cloud Service (FCCS) of Account Reconciliation Cloud Service (ARCS), niet in het grootboek zelf. Je leidt de gebeurtenis af uit een statuswijziging van de afstemmingsregistratie die aan de journaalpost is gekoppeld. Vastleggen Koppel journaalgegevens aan statusupdates van afstemmingen in ARCS- of FCCS-tabellen. Gebeurtenistype inferred
	Journaalpost geboekt	De financiële gegevens van de journaalpost zijn succesvol vastgelegd in het grootboek. De debet- en creditbedragen zijn nu verwerkt in de rekeningsaldi.
Waarom dit belangrijk is Dit is een belangrijke mijlpaal: de journaalpost is opgenomen in de officiële financiële administratie. Deze stap is essentieel om het percentage tijdig geboekte posten en de totale tijd van aanmaak tot boeking te meten. Waar vind je dit? Dit wordt afgeleid uit een statuswijziging in de tabel GL_JE_HEADERS, waarbij het veld STATUS verandert in 'P' (Posted). De tabel GL_JE_BATCHES bevat ook een boekingsstatus. Vastleggen Registreer het tijdstip waarop STATUS in GL_JE_HEADERS verandert in 'P'. Gebeurtenistype inferred
	Journaalpost goedgekeurd	De aangewezen goedkeurder heeft de journaalpost formeel goedgekeurd en bevestigt daarmee dat deze klopt en geldig is. Dit is de laatste stap in de goedkeuringsworkflow. Daarna kan de post worden geboekt.
Waarom dit belangrijk is Deze mijlpaal markeert het einde van het goedkeuringsproces. De tijd tussen indiening en goedkeuring is een belangrijke KPI om de efficiëntie van de workflow te meten en bottlenecks in de goedkeuring op te sporen. Waar vind je dit? Deze gebeurtenis wordt afgeleid uit een statuswijziging in de tabel GL_JE_HEADERS, waarbij APPROVAL_STATUS_CODE wordt bijgewerkt naar 'APPROVED'. De workflowtabellen bevatten de identiteit van de goedkeurder en het tijdstip. Vastleggen Registreer het tijdstip waarop APPROVAL_STATUS_CODE in GL_JE_HEADERS verandert in 'APPROVED'. Gebeurtenistype inferred
	Journaalpost ter goedkeuring ingediend	Deze activiteit vindt plaats wanneer een gebruiker de voltooide journaalpost formeel indient voor goedkeuring. De post gaat dan van concept of onvolledig naar wachtend op goedkeuring.
Waarom dit belangrijk is Dit is een belangrijk moment om de goedkeuringsdoorlooptijd te meten en bottlenecks te vinden. Het markeert de overgang van gegevensinvoer naar beoordeling en goedkeuring. Waar vind je dit? Deze gebeurtenis wordt afgeleid uit een statuswijziging in de tabel GL_JE_HEADERS, met name wanneer APPROVAL_STATUS_CODE verandert in bijvoorbeeld 'REQUIRED' of 'INITIATED'. Mogelijk wordt ook de timestamp van de indiening vastgelegd. Vastleggen Volg de timestamp waarop APPROVAL_STATUS_CODE in GL_JE_HEADERS verandert om aan te geven dat de post is ingediend. Gebeurtenistype inferred
	Boeking gecontroleerd	Na het boeken controleert een gebruiker of systeem of de journaalpost correct is geboekt en of de saldi kloppen. Dit is vaak een handmatige controle.
Waarom dit belangrijk is Door deze activiteit te analyseren, zie je hoeveel tijd handmatige controles en kwaliteitsbewaking na het boeken kosten. Ook komen mogelijkheden om controles te automatiseren in beeld. Waar vind je dit? Dit is waarschijnlijk geen expliciete gebeurtenis in Oracle Fusion. Je moet deze afleiden uit andere acties, zoals het uitvoeren van een specifiek rapport door een gebruiker of het bijwerken van een aangepast statusveld. Dat laatste is niet standaard. Vastleggen Hiervoor is aangepaste logica nodig, bijvoorbeeld om de uitvoeringstijd van controlerapporten of wijzigingen in een descriptive flexfield bij te houden. Gebeurtenistype inferred
	Boeking van journaalpost gestart	Het boeken van de goedgekeurde journaalpost in het grootboek is gestart. Dit kan een automatische of handmatige stap zijn waarbij de journaalpost in de wachtrij wordt gezet voor verwerking door het boekingsprogramma.
Waarom dit belangrijk is Deze activiteit maakt onderscheid tussen de goedkeuring en het technische boekingsproces. Vertraging tussen goedkeuring en de start van het boeken kan wijzen op planningsproblemen of beperkte capaciteit van de boekingsengine. Waar vind je dit? Dit kan worden afgeleid uit statuswijzigingen in de tabel GL_JE_BATCHES of uit het indieningstijdstip van de gelijktijdige boekingsaanvraag voor de journaalbatch. Vastleggen Zoek het indieningstijdstip van het General Ledger Posting-programma voor de betreffende journaalbatch. Gebeurtenistype inferred
	Journaalpost afgewezen	Een goedkeurder heeft de journaalpost beoordeeld en afgewezen vanwege fouten, ontbrekende documentatie of overtreding van beleid. De post gaat terug naar de maker voor correctie.
Waarom dit belangrijk is Deze activiteit is belangrijk om herstelroutes, afwijzingspercentages en het percentage posten dat in één keer goed is te analyseren. Veel afwijzingen wijzen op problemen met de datakwaliteit of training. Waar vind je dit? Deze gebeurtenis wordt afgeleid uit een statuswijziging in de tabel GL_JE_HEADERS wanneer APPROVAL_STATUS_CODE wordt bijgewerkt naar 'REJECTED'. In de workflowhistorie worden de gebruiker en timestamp van deze actie vastgelegd. Vastleggen Volg de timestamp waarop APPROVAL_STATUS_CODE in GL_JE_HEADERS wordt ingesteld op 'REJECTED'. Gebeurtenistype inferred
	Journaalpost beoordeeld	Deze beoordelingsstap kan vóór of als onderdeel van de formele goedkeuring plaatsvinden. Een collega of manager controleert de nauwkeurigheid en compliance voordat de post naar de uiteindelijke goedkeurder gaat.
Waarom dit belangrijk is Door deze activiteit apart te bekijken, kun je de tijd voor een eerste beoordeling onderscheiden van de tijd voor de uiteindelijke goedkeuring. Zo worden verborgen bottlenecks zichtbaar als de beoordelingsstap informeel maar tijdrovend is. Waar vind je dit? Deze stap kan expliciet onderdeel zijn van een goedkeuringsworkflow met meerdere fasen en worden vastgelegd in workflowhistorietabellen. Een informele beoordeling wordt niet vastgelegd. Je kunt die mogelijk afleiden als een specifieke gebruikersactie wordt geregistreerd vóór de uiteindelijke goedkeuringsbeslissing. Vastleggen Analyseer workflowhistorietabellen op tussentijdse goedkeurings- of beoordelingsstappen vóór de uiteindelijke status 'Goedgekeurd'. Gebeurtenistype inferred
	Journaalpost gecorrigeerd en opnieuw ingediend	Nadat een journaalpost is afgewezen, voert de maker de benodigde correcties door en dient de post opnieuw in voor goedkeuring. Hiermee begint een nieuwe goedkeuringscyclus voor dezelfde journaalpost.
Waarom dit belangrijk is Herstelwerk volgen is belangrijk om inefficiënties in het proces te begrijpen. In combinatie met "Journaalpost afgewezen" maakt deze activiteit het mogelijk om de duur en frequentie van herstelwerk te meten. Waar vind je dit? Dit is een volgende gebeurtenis 'Journal Submitted For Approval' voor een journaalpost die eerder de status 'REJECTED' had. De gebeurtenis wordt herkend door de reeks statuswijzigingen voor één Journal Entry ID te analyseren. Vastleggen Zoek een indieningstijdstip dat volgt op een afwijzing voor dezelfde case-ID. Gebeurtenistype inferred
	Ondersteunende documentatie toegevoegd	Dit is het toevoegen van ondersteunende documenten, zoals facturen of spreadsheets, aan een journaalpost. Zo krijgen goedkeurders en auditors vaak extra context en bewijsstukken.
Waarom dit belangrijk is Door deze activiteit te volgen, zie je of ontbrekende documentatie vertraging veroorzaakt. Ook krijg je inzicht in de compliance en de volledigheid van journaalposten voordat ze de goedkeuringsworkflow ingaan. Waar vind je dit? Deze activiteit is lastig als afzonderlijke gebeurtenis te volgen. Je kunt die mogelijk afleiden uit timestamps in bijlagetabellen zoals FND_ATTACHED_DOCUMENTS, gekoppeld aan de journaalpost in GL_JE_HEADERS. Vastleggen Leid de activiteit af uit de aanmaakdatum van records in FND_ATTACHED_DOCUMENTS die aan de journaalpost zijn gekoppeld. Gebeurtenistype inferred
	Tegenboeking journaalpost verwerkt	Er is een tegenboeking aangemaakt en geboekt om in een volgende periode het financiële effect van de oorspronkelijke journaalpost ongedaan te maken. Dit komt vaak voor bij overlopende posten.
Waarom dit belangrijk is Door tegenboekingen bij te houden, zie je welke soorten posten vaak worden teruggedraaid en hoe efficiënt het tegenboekingsproces verloopt. Dit kan wijzen op problemen met het beheer van overlopende posten. Waar vind je dit? Dit wordt afgeleid door een nieuwe journaalpost te vinden die expliciet als tegenboeking aan de oorspronkelijke post is gekoppeld. De tabel GL_JE_HEADERS bevat velden zoals REVERSAL_PERIOD en REVERSAL_FLAG om deze posten te herkennen en aan elkaar te koppelen. Vastleggen Zoek de aanmaak- en boekingsdatum van de nieuwe journaalpost waarvan de kop verwijst naar de oorspronkelijke, teruggedraaide post. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data uit Oracle Fusion Financials

Stappen

Ga naar de werkruimte Reports and Analytics: Meld je aan bij Oracle Fusion Financials. Open het menu Navigator, ga naar Tools en kies Reports and Analytics. Hier maak en beheer je analyses en rapporten.
Maak een BI Publisher-datamodel: Voor het extraheren van dit type event log kun je beter rechtstreeks een BI Publisher-datamodel maken dan beginnen met een OTBI Analysis. Zo kun je een aangepaste SQL-query met UNION ALL-statements gebruiken. Klik op de knop 'Browse Catalog', ga naar een geschikte map en kies Create > Data Model.
Stel de SQL-querydataset in: Klik in de editor voor het datamodel op het pictogram '+' om een Data Set toe te voegen en kies 'SQL Query'. Geef de dataset een duidelijke naam, bijvoorbeeld 'JournalEventLog'.
Voer de SQL-query in: Kies 'Oracle BI EE' als databron. Kopieer het volledige SQL-script uit het onderstaande gedeelte Query en plak het in het tekstvak SQL Query. De query haalt alle benodigde activiteiten en attributen op in één structuur.
Stel parameters in: De query gebruikt parameters zoals :start_date, :end_date en :ledger_name. De interface van het datamodel herkent deze automatisch. Stel ze in als parameters met het juiste datatype (Date of Text) en eventueel een standaardwaarde. Zo kun je het rapport flexibel uitvoeren.
Maak een rapport op basis van het datamodel: Sla het datamodel op en ga terug naar de catalogus. Klik op Create > Report. Kies in de rapportwizard 'Use Existing Data Model' en selecteer het datamodel dat je zojuist hebt gemaakt.
Stel de rapportindeling in: Kies in de indelingeditor 'Table'. Sleep alle kolommen uit het datamodel naar de tabel, zodat ze in de export terechtkomen. Complexe opmaak is niet nodig.
Stel CSV in als standaarduitvoer: Klik in de rapporteditor op de link 'View a List'. Controleer onder 'Output Formats' of 'CSV' is geselecteerd. Schakel bij voorkeur de andere indelingen uit om het plannen eenvoudiger te maken. Sla het rapport op.
Plan het rapport voor automatische extractie: Zoek het opgeslagen rapport in de catalogus en klik op 'More' en daarna op 'Schedule'. Maak een nieuwe geplande taak aan en stel de frequentie in, bijvoorbeeld dagelijks of wekelijks.
Stel export en aflevering in: Geef op het tabblad 'Output' van de geplande taak de uitvoergegevens op. Selecteer je rapport en kies 'CSV' als indeling. Op het tabblad 'Destination' kun je het bestand laten afleveren op een locatie op de contentserver (UCM) of een externe SFTP-server, zodat het automatisch kan worden opgehaald.
Haal de data op en bereid deze voor: Haal na uitvoering van de geplande taak het CSV-bestand op uit de ingestelde locatie. Controleer of de kolomkoppen voldoen aan de vereisten voor ProcessMind: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName enzovoort. Het bestand kan nu worden geüpload.

Configuratie

Databron: Voer de query uit op de databron 'Oracle BI EE' in BI Publisher. Deze maakt verbinding met de onderliggende transactionele databaseweergaven waarop OTBI is gebaseerd.
Belangrijke onderwerpgebieden (ter referentie): De query is vooral gebaseerd op data uit het onderwerpgebied 'General Ledger - Journals Real Time'. Ook worden gegevens logisch gekoppeld die te vinden zijn in 'HCM - Workforce Management - Worker Assignment Real Time' voor gebruikersgegevens en mogelijk in onderwerpgebieden voor workflows met goedkeuringsgeschiedenis.
Filteren op datumbereik: Beperk de data tot een beheersbare periode. De query bevat de parameters :start_date en :end_date. Voor een eerste analyse raden we aan om drie tot zes maanden aan data te extraheren. Het filter wordt toegepast op de aanmaakdatum van de journaalpost.
Filteren op grootboek: Gebruik de parameter :ledger_name om de extractie te beperken tot één primair grootboek. Een extractie van alle grootboeken tegelijk kan zeer grote bestanden en prestatieproblemen opleveren.
Vereisten: De gebruiker die het rapport maakt en plant, moet de juiste BI-rollen hebben, zoals 'BI Administrator' of 'BI Author'. Ook moet het databeveiligingsprofiel van de gebruiker toegang geven tot de betreffende grootboeken en bedrijfseenheden.
Planning: Plan de extractietaak buiten piekuren, bijvoorbeeld ’s nachts. Zo beperk je de invloed op de systeemprestaties en andere gebruikers.

Voorbeeldquery sql

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Stappen

Ga naar BI Publisher: Meld je aan bij Oracle Fusion Financials. Open het menu Navigator, ga naar Tools en kies Reports and Analytics. De catalogus van Business Intelligence wordt geopend.
Maak een nieuw datamodel: Klik in de BI-catalogus op Create en kies Data Model. De editor voor het datamodel wordt geopend.
Stel de SQL-querydataset in: Klik in de editor op het plusteken op het tabblad Diagram en kies SQL Query. Geef de dataset in het nieuwe dialoogvenster een naam, bijvoorbeeld ProcessMind_JE_EventLog. Selecteer de juiste databron, meestal FUSIONDB. Plak de volledige SQL-query in het tekstvak SQL Query.
Stel parameters in: De query gebruikt parameters voor het datumbereik (p_start_date en p_end_date). Oracle BI Publisher herkent deze automatisch. Stel ze in als parameters van het type Text en geef ze duidelijke labels, zoals 'Start Date (YYYY-MM-DD)' en 'End Date (YYYY-MM-DD)'.
Sla het datamodel op: Klik na het plakken van de query en het instellen van de parameters op OK. Sla het datamodel op in een geschikte map, bijvoorbeeld Shared Folders/Custom/ProcessMining.
Maak het rapport: Klik rechtsboven in de editor voor het datamodel op Create Report. De rapportwizard wordt geopend.
Stel de rapportindeling in: Kies in de wizard de optie om het huidige datamodel te gebruiken. Selecteer de indeling 'Table'. Sleep alle kolommen uit de databron naar het tabelgedeelte. Schakel de optie 'Show Grand Totals Row' uit.
Sla het rapport op: Sla het rapport op in dezelfde map als het datamodel. Geef het een duidelijke naam, zoals 'Journal Entry Event Log Report'.
Stel de standaarduitvoer in: Bewerk het rapport en ga naar het tabblad 'Viewing'. Controleer onder 'Output Formats' of CSV is geselecteerd en stel dit bij voorkeur in als standaardindeling. Zo is de uitvoer meteen geschikt voor gebruik.
Voer het rapport uit en exporteer de data: Open het rapport en vul de parameters voor de begin- en einddatum in. Geef het gewenste datumbereik op en klik op Apply. Klik na uitvoering van het rapport op Export en kies de CSV-indeling om het event log te downloaden.
Bereid de upload voor: Open het gedownloade CSV-bestand. Controleer of de kolomkoppen overeenkomen met de verwachte attribuutnamen (JournalEntryId, ActivityName, EventTime enzovoort) en of de data correct is opgemaakt voordat je het bestand uploadt naar ProcessMind.

Configuratie

Vereisten: De gebruiker die het rapport uitvoert, moet een rol hebben met de benodigde databeveiligingsrechten voor toegang tot grootboekgegevens, zoals General Accountant of een aangepaste BI-rol. Ook is toegang tot BI Publisher vereist.
Databron: Stel het BI Publisher-datamodel in met de verbinding naar de applicatiedatabase FUSIONDB.
Parameters voor datumbereik: De query gebruikt de parameters p_start_date en p_end_date om de extractieperiode te bepalen. Begin bij voorkeur met drie tot zes maanden aan data om de prestaties op peil te houden.
Rapportfilters: Voor grote organisaties is het sterk aan te raden om filters rechtstreeks toe te voegen aan de WHERE-clausule van de algemene tabeluitdrukking JournalHeaders in de query. Filteren op LEDGER_ID of LEGAL_ENTITY_ID is essentieel om de hoeveelheid data beheersbaar te houden.
Aandacht voor prestaties: Deze query kan bij uitvoering op een grote productiedatabase veel bronnen gebruiken. Plan het rapport buiten piekuren om de invloed op de systeemprestaties te beperken.
Uitvoerindeling: Stel het rapport zo in dat het een CSV-bestand oplevert. Dit geeft een overzichtelijke, gestructureerde indeling die geschikt is voor process mining-tools.

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

Vereisten: Zorg dat Python 3 is geïnstalleerd, samen met de bibliotheken requests en pandas. Je hebt een gebruikersaccount voor Oracle Fusion Financials nodig met de juiste rechten voor toegang tot de REST API voor General Ledger Journals. Zorg dat je de URL van je Oracle Fusion-instantie, gebruikersnaam en wachtwoord bij de hand hebt.
Script instellen: Maak een nieuw Python-scriptbestand. Importeer eerst de benodigde bibliotheken: requests, json, pandas en datetime.
Configuratie: Definieer in het script variabelen voor je Oracle Fusion-inloggegevens en de basis-URL. Stel ook parameters in voor de data-extractie, zoals de begin- en einddatum van de query.
Authenticatie: Het script gebruikt Basic Authentication. De bibliotheek requests codeert de gebruikersnaam en het wachtwoord in de requestheaders.
Functie voor API-aanroepen definiëren: Maak een functie voor de API-aanroepen. Deze functie moet paginering afhandelen met de parameters offset en limit. De functie doet herhaaldelijk API-aanroepen totdat alle journaalposten binnen het opgegeven datumbereik zijn opgehaald.
API-query samenstellen: Gebruik de parameter q in de API-aanroep om journaalposten te filteren op LastUpdateDate. Zo haal je gericht data op voor een bepaalde periode, bijvoorbeeld LastUpdateDate between '2023-01-01' and '2023-03-31'.
Data ophalen: Roep de functie aan om data op te halen via het endpoint .../fscmRestApi/resources/11.13.18.05/journals. De functie retourneert een volledige lijst met journaalposten.
Data verwerken en omzetten: Doorloop alle journaalposten die de API retourneert. Maak voor elke journaalpost meerdere eventregels aan voor de verschillende bedrijfsactiviteiten (Journaalpost aangemaakt, Journaalpost goedgekeurd enzovoort). Gebruik de datumvelden en statuscodes uit het API-antwoord (CreationDate, PostedDate, ApprovalStatus enzovoort) om de afzonderlijke events vast te leggen.
Event log samenstellen: Sla elke aangemaakte eventregel als dictionary op in een lijst. Deze lijst vormt de ruwe data voor je event log.
DataFrame maken: Zet de lijst met event-dictionaries om in een Pandas DataFrame, zodat je de data eenvoudiger kunt bewerken.
Kolommen afronden: Selecteer de DataFrame-kolommen en hernoem ze volgens het vereiste schema voor ProcessMind: JournalEntryId, ActivityName, EventTime, UserName enzovoort.
Exporteren naar CSV: Sla de uiteindelijke DataFrame op als CSV-bestand. Je kunt dit bestand rechtstreeks uploaden naar ProcessMind voor analyse.

Configuratie

Inloggegevens: Voor Basic Authentication heb je een geldige Oracle Fusion-gebruikersnaam en een geldig wachtwoord nodig.
Instantie-URL: Je hebt de basis-URL van je Oracle Fusion Financials-instantie nodig om het API-endpoint samen te stellen (bijvoorbeeld https://[your-instance].fa.us2.oraclecloud.com).
API-endpoint: Het script haalt grootboekgegevens op via het endpoint fscmRestApi/resources/11.13.18.05/journals.
Filter op datumbereik: Stel het script in met een start_date en end_date om de extractieperiode te beperken. Voor een eerste analyse raden we drie tot zes maanden aan. Stel voor doorlopend gebruik dagelijkse of wekelijkse incrementele ladingen in.
Paginering: De parameter limit bepaalt hoeveel records elke API-aanroep ophaalt. Een waarde tussen 200 en 500 werkt doorgaans goed en biedt een goede balans tussen het aantal API-aanroepen en de omvang van elk antwoord.
Vereiste Oracle-rollen: Het gebruikersaccount moet de juiste rechten hebben om journaalgegevens via de REST API te lezen, bijvoorbeeld via de rol General Accountant of een aangepaste rol met gelijkwaardige rechten.

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

Controleer of BI Cloud Connector, de benodigde onderwerpgebieden voor General Ledger of Public View Objects in Oracle Fusion Financials en de vereiste autorisaties voor het bronsysteem beschikbaar zijn in je omgeving. Vraag je Oracle-beheerder om de ingestelde BICC-afleverbestemming en de bijbehorende toegangsgegevens te bevestigen.
Zoek in de BI Cloud Connector-console de Public View Objects met journaalkoppen, journaalregels, goedkeuringsgeschiedenis, bijlagen, boekingsstatus, afstemmingsstatus en terugboekingsgegevens. Noteer de exacte object- en attribuutnamen die in je omgeving zijn ingesteld. Vervang vóór uitvoering de placeholders in het extractiescript door deze namen.
Stel een BICC-taak in voor de geselecteerde Public View Objects van General Ledger. Gebruik incrementele extractie als er een betrouwbaar attribuut voor de laatste wijziging beschikbaar is. Gebruik voor de eerste lading een afgebakende periode van drie tot zes maanden, of een andere goedgekeurde periode.
Stel BICC zo in dat de extractiebestanden worden afgeleverd op de aangewezen cloudopslaglocatie. Controleer de bestandsindeling, het scheidingsteken, de tekencodering, compressie, partitionering, naamgevingsconventie en afleverplanning. Bewaar de extractiewatermark of timestamp van de laatste geslaagde extractie.
Haal de afgeleverde bestanden op en plaats ze in de goedgekeurde stagingomgeving. Laad elk bronbestand in de bijbehorende stagingtabel of -weergave. Gebruik de exacte koppelingen tussen bronobjecten en attributen die voor je omgeving zijn vastgelegd. Ga er niet van uit dat een Public View Object dezelfde structuur heeft als de onderliggende databasetabel.
Zet timestamps om naar één tijdzone en een consistent timestamp-datatype. Bewaar de timestamp van de bronwijziging als LastDataUpdate. Zet bron-ID’s en activiteitsattributen om naar de uitvoernamen die ProcessMind gebruikt.
Voer de query hieronder uit nadat je elke placeholder hebt vervangen door de werkelijke object- en attribuutnamen uit de stagingomgeving. De query maakt expliciet één eventlogregel aan voor elk van de 12 vereiste activiteiten. Activiteiten die niet in de brond data staan, worden niet afgeleid.
Controleer of JournalEntryId, ActivityName, EventTime, SourceSystem en LastDataUpdate voor elke uitvoerregel zijn ingevuld. Controleer dubbele events, de volgorde van timestamps, afgewezen en opnieuw ingediende journaalposten, relaties tussen terugboekingen en records met ontbrekende optionele attributen.
Exporteer het resultaat als een bestand met scheidingstekens of in een andere indeling die ProcessMind ondersteunt. Gebruik exact deze kolomnamen: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount en RejectionReason. Upload het bestand met JournalEntryId als case-ID, ActivityName als activiteit en EventTime als eventtimestamp.

Configuratie

Stel BICC in voor de Public View Objects van General Ledger die nodig zijn voor journaalkoppen, journaalregels, goedkeurings- of workflowgeschiedenis, bijlagen, boekingen, afstemmingen en terugboekingen. Controleer de exacte objectnamen en attributen in de BICC-catalogus voor je omgeving.
Gebruik voor de eerste extractie een periode van drie tot zes maanden. Verleng deze periode pas nadat je het datavolume, de opslagcapaciteit, de extractieduur en de verwerkingstijd van vervolgstappen hebt gecontroleerd.
Pas goedgekeurde filters toe voor boekingsdatum of datum van laatste wijziging, grootboek, juridische entiteit, bedrijfseenheid, bedrijfscode indien beschikbaar, journaalcategorie, journaalbron, documenttype indien beschikbaar en journaalstatus. Gebruik alleen filters die door de geselecteerde Public View Objects worden ondersteund.
Stel incrementele extractie in op basis van het attribuut voor de laatste wijziging in de bron en een bewaarde watermark. Voeg zo nodig een kleine overlapperiode toe om late wijzigingen mee te nemen. Verwijder daarna dubbele records op basis van JournalEntryId, ActivityName, EventTime en de relevante event-ID uit de bron.
Zorg dat alle bronobjecten compatibele extractiesleutels en verversingsschema’s gebruiken. Goedkeurings-, bijlage-, boekings-, afstemmings- en terugboekingsgegevens kunnen op verschillende momenten worden bijgewerkt.
Verdeel grote datasets op basis van boekingsperiode, grootboek, juridische entiteit of een ander ondersteund BICC-partitieattribuut. Voer tijdens kantooruren geen onbeperkte extracties van historische data uit.
Bewaar brontimestamps en timestamps van bronwijzigingen voordat je de data omzet. Leg vast welke tijdzone voor EventTime en LastDataUpdate wordt gebruikt.
Vereisten zijn toegang tot de BI Cloud Connector-console, toestemming om de geselecteerde extracties in te stellen en uit te voeren, toegang tot de ingestelde cloudopslagbestemming en de stagingomgeving, en toestemming om de benodigde General Ledger- en workflowgegevens te bekijken.
Controleer of de benodigde Oracle Fusion Financials-modules, workflowconfiguratie, bijlagenopslag, boekingsprocessen en databronnen voor afstemming zijn ingeschakeld voor de activiteiten die je wilt volgen.
Beschouw een ontbrekend bronrecord niet als bewijs dat een activiteit niet heeft plaatsgevonden. De BICC-uitvoer hangt af van de geselecteerde Public View Objects, filters, verversingstijden, bewaartermijnen en beschikbare geschiedenis.

Voorbeeldquery sql

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

Klaar om te beginnen?

Gebruik deze template om data over journaalposten in Oracle Fusion om te zetten in bruikbare inzichten en de Record-to-Report-cyclus te versnellen. Zet vandaag de eerste stap naar efficiëntere financiële processen.

Terug naar de verbetergids

Template downloaden

Versnel vandaag Record to Report - journaalposten

Verkort de doorlooptijd van journaalposten met 30% en maak financiële processen efficiënter.

Start je gratis proefperiode

Geen creditcard nodig. Activeer nu je proefperiode.

Datatemplate voor Record to Report - journaalposten

Datatemplate voor Record to Report - journaalposten

Attributen voor Record to Report - journaalposten

Activiteiten voor Record to Report - journaalposten

Extractiegidsen

Rapportexport met Oracle OTBI en BI Publisher

Stappen

Configuratie

Voorbeeldquery sql

BI Publisher-rapport met een directe SQL-query op het datamodel

Stappen

Configuratie

Voorbeeldquery sql

Python-script met de Oracle Fusion Financials REST API

Stappen

Configuratie

Voorbeeldquery python

Bulkdata-extractie met BI Cloud Connector (BICC)

Stappen

Configuratie

Voorbeeldquery sql

Klaar om te beginnen?

Versnel vandaag Record to Report - journaalposten