> Continue procesverbetering > Van vastlegging tot rapportage journaalpost > Oracle Fusion Financials > Datatemplate

Jouw datatemplate voor Record to Report - Journaalpost

Oracle Fusion Financials

Van vastlegging tot rapportage - attributen van journaalposten (21) Van vastlegging tot rapportage - activiteiten van journaalposten (12) Extractiegidsen (4)

Jouw datatemplate voor Record to Report - Journaalpost

Deze datatemplate helpt je om data over journaalposten uit Oracle Fusion Financials te extraheren en te structureren. Je ziet welke attributen je moet verzamelen en welke activiteiten je moet volgen, zodat je alle benodigde informatie vastlegt voor een goede procesanalyse. Je vindt ook praktische uitleg over hoe je deze data rechtstreeks uit je systeem haalt.

Aanbevolen attributen om te verzamelen
Belangrijke activiteiten om te volgen
Extractiehandleiding voor Oracle Fusion Financials

Nieuw met event logs? Leer hoe je een process mining-event log maakt.

Template downloaden

Van vastlegging tot rapportage - attributen van journaalposten

Dit zijn de aanbevolen datavelden voor je event log voor een volledige analyse van je proces van vastlegging tot rapportage en journaalposten.

5 Verplicht 6 Aanbevolen 10 Optioneel

	Naam	Beschrijving
	Activiteit ActivityName	De naam van de specifieke bedrijfsgebeurtenis of taak die op een bepaald moment in het journaalpostproces heeft plaatsgevonden.
Beschrijving De Activity Name beschrijft één stap in de levenscyclus van een journaalpost, zoals 'Journaalpost aangemaakt' of 'Journaalpost goedgekeurd'. Deze data is belangrijk voor het opbouwen van de proceskaart en het begrijpen van de volgorde van gebeurtenissen. Door activiteiten te analyseren, zie je de processtroom, inclusief standaardroutes, afwijkingen en herstelrondes. Door verschillende activiteiten te volgen, meet je hoeveel tijd specifieke fasen kosten, zoals goedkeuring, en zie je welke stappen de meeste tijd kosten of het vaakst fouten veroorzaken. Waarom dit belangrijk is Dit veld definieert de processtappen. Daarmee vormt het de basis van de proceskaart en maakt het analyse van de stroom, knelpunten en varianten mogelijk. Waar je het vindt Dit attribuut wordt meestal afgeleid uit statuswijzigingen, event logs of audittabellen die aan journaalpostobjecten in de General Ledger-module zijn gekoppeld. Voorbeelden Journaalpost aangemaaktJournaalpost ingediend ter goedkeuringJournaalpost goedgekeurdJournaalpost geboekt
	ID journaalpost JournalEntryId	De unieke identificatie van één journaalpost, waarmee alle bijbehorende financiële transactieactiviteiten aan elkaar worden gekoppeld.
Beschrijving De Journal Entry ID is de primaire case-identificatie. Hiermee koppel je alle activiteiten rond een specifieke reeks financiële transacties op unieke wijze. 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 verwerkt. Binnen process mining is deze ID essentieel om het volledige traject van elke journaalpost te reconstrueren. De ID verbindt afzonderlijke gebeurtenissen, zoals 'Journaalpost aangemaakt', 'Journaalpost ingediend ter goedkeuring' en 'Journaalpost geboekt', tot één samenhangende processtroom. Daarmee kun je doorlooptijden, knelpunten en procesvarianten analyseren. Waarom dit belangrijk is Dit is de basis voor het volgen van een journaalpost van begin tot eind. Zo kun je de volledige processtroom van elke unieke case analyseren. Waar je het vindt Dit is een primaire sleutel in kerntabellen van het General Ledger, zoals GL_JE_HEADERS en GL_JE_LINES. Voorbeelden JE100523JE202311001882019
	Starttijd EventTime	De timestamp die aangeeft wanneer een specifieke activiteit of gebeurtenis heeft plaatsgevonden.
Beschrijving Deze timestamp markeert de exacte datum en tijd waarop een activiteit is uitgevoerd. Het is het belangrijkste tijdselement binnen process mining om de volgorde van gebeurtenissen te bepalen en de duur ertussen te berekenen. De nauwkeurigheid van Event Time is belangrijk voor alle tijdgebaseerde analyses, waaronder het berekenen van doorlooptijden, het vinden van knelpunten en het volgen van prestaties ten opzichte van service level agreements. De timestamp levert de chronologische volgorde die nodig is om de werkelijke processtroom te reconstrueren. Waarom dit belangrijk is Deze timestamp is essentieel voor het ordenen van gebeurtenissen, het berekenen van alle procesduren en elke tijdgebaseerde analyse. Waar je het vindt Deze informatie staat meestal in audittabellen 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 waaruit de data afkomstig is.
Beschrijving Dit attribuut identificeert het bronsysteem waaruit de procesdata is geëxtraheerd. In een complexe IT-omgeving kan data uit meerdere geïntegreerde systemen komen. Dit veld helpt om die bronnen van elkaar te onderscheiden. Bij procesanalyse helpt het bronsysteem om procesvarianten te begrijpen die door verschillend systeemgedrag kunnen ontstaan. Het ondersteunt ook datavalidatie en probleemoplossing, omdat je data kunt terugleiden naar de oorsprong. Waarom dit belangrijk is Identificeert de herkomst van de data. Dat is belangrijk voor datagovernance, validatie en het begrijpen van procesvarianten tussen verschillende systemen. Waar je het vindt Dit is vaak een statische waarde die tijdens de data-extractie wordt ingesteld. Het kan ook een veld in de brontabellen zijn dat het systeem van invoer identificeert. Voorbeelden Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Laatste data-update LastDataUpdate	De timestamp van de meest recente datarefresh of extractie uit het bronsysteem.
Beschrijving Dit attribuut registreert wanneer de dataset voor het laatst is bijgewerkt. Het geeft context over de actualiteit van de geanalyseerde data, wat belangrijk is om de relevantie van de inzichten te beoordelen. Voor elke analyse, en vooral voor operationele dashboards, is het belangrijk om te weten wanneer de data voor het laatst is bijgewerkt. Zo kunnen gebruikers de data vertrouwen en betere beslissingen nemen. De timestamp maakt duidelijk tot welk moment data in het process mining-model is opgenomen. Waarom dit belangrijk is Geeft aan hoe actueel de data is. Zo weten gebruikers hoe recent de procesanalyse is en kunnen ze de inzichten vertrouwen. Waar je het vindt Deze waarde wordt gegenereerd en opgeslagen tijdens het proces van data-extractie en transformatie. Meestal is dit de timestamp waarop de ETL/ELT-job 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 aan een specifieke afdeling te koppelen, zoals 'Finance', 'Accounting Operations' of 'Internal Audit'. De waarde wordt meestal afgeleid uit gebruikersstamgegevens. Door te analyseren per afdeling van gebruiker, vind je knelpunten tussen afdelingen, vergelijk je teamprestaties en zie je hoe de uitvoering van het proces binnen de organisatie verschilt. Dit helpt bij capaciteitsverdeling en gerichte verbeterinitiatieven. Waarom dit belangrijk is Geeft organisatorische context. Zo kun je prestaties per team of afdeling analyseren en inefficiënties tussen functies zichtbaar maken. Waar je het vindt Dit staat meestal niet in de transactietabellen. Je moet de waarde ophalen door UserName te koppelen aan een tabel met gebruikersstamgegevens of aan data uit een HR-systeem. Voorbeelden Algemene boekhoudingFinanciële rapportageCrediteurenadministratie
	Bedrag journaalpost JournalAmount	De totale geldwaarde van de journaalpost, meestal de som van de debetbedragen.
Beschrijving Dit attribuut vertegenwoordigt de totale financiële waarde die in de journaalpost wordt verwerkt. Het bedrag kan een belangrijke invloed hebben op het proces. Voor journaalposten met een hoge waarde zijn bijvoorbeeld extra goedkeuringsstappen of grondigere controles nodig. Met Journal Amount kun je cases indelen op basis van financiële impact. Het helpt vragen te beantwoorden als: 'Worden journaalposten met een hoge waarde langzamer goedgekeurd?' en 'Komen afwijzingen vaker voor bij journaalposten boven een bepaalde drempel?'. Zo krijgt de procesflow de juiste bedrijfscontext. Waarom dit belangrijk is Geeft belangrijke bedrijfscontext. Je kunt analyses uitvoeren op basis van financiële impact en vaststellen of journaalposten met een hoge waarde een ander proces volgen. Waar je het vindt Deze waarde wordt meestal berekend als de som van de debet- of creditbedragen uit de tabel GL_JE_LINES voor een bepaalde journaalpost. Voorbeelden 5000.00125000.75750.50
	Bron van journaalpost JournalSource	Het subledger of de bron die de journaalpost heeft gegenereerd, zoals 'Payables', 'Receivables' of 'Manual'.
Beschrijving Dit attribuut geeft aan waar de journaalpost binnen het ERP-systeem vandaan komt. Journaalposten kunnen handmatig in het grootboek worden aangemaakt of automatisch worden gegenereerd vanuit subadministraties, zoals Crediteuren, Debiteuren of Vaste activa. Journal Source is een belangrijk attribuut voor automatiseringsanalyses. Het helpt onderscheid te maken tussen handmatige en systeemgegenereerde journaalposten en ondersteunt de KPI 'Automated Journal Entry Rate'. Processen voor journaalposten uit verschillende bronnen kunnen sterk verschillen in complexiteit en efficiëntie. Waarom dit belangrijk is Maakt onderscheid tussen handmatige en geautomatiseerde journaalposten. Dat is belangrijk om automatiseringspercentages te meten en procesverschillen te analyseren. Waar je het vindt Beschikbaar in de tabel GL_JE_HEADERS, meestal in een veld met de naam JE_SOURCE. Voorbeelden HandmatigCrediteurenActivaDebiteuren
	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 identificeert de specifieke medewerker of systeemgebruiker die verantwoordelijk is voor een activiteit. Het is belangrijk om de verdeling van het werk en prestaties te begrijpen en individuele knelpunten te vinden. Met UserName kun je processen filteren op gebruiker, de efficiëntie per gebruiker vergelijken en oorzaken van vertragingen of fouten onderzoeken. Het ondersteunt dashboards zoals 'Werkbelasting en efficiëntie per team' en KPI's zoals de 'User Journal Bottleneck Index'. Waarom dit belangrijk is Legt de verantwoordelijkheid voor processtappen vast. Zo kun je de werkbelasting, individuele prestaties en trainingsbehoeften analyseren. Waar je het vindt Te vinden in transactietabellen zoals GL_JE_HEADERS, bijvoorbeeld in CREATED_BY en LAST_UPDATED_BY, en in gerelateerde audittabellen. Voorbeelden john.doesusan.smithautoprocess_user
	Journaalcategorie JournalCategory	De categorie van de journaalpost, zoals 'Accrual', 'Adjustment' of 'Reclassification'.
Beschrijving Journal Category deelt journaalposten in op basis van hun bedrijfsdoel. Daardoor kun je het proces gedetailleerder analyseren, omdat verschillende categorieën hun eigen processtromen, goedkeuringsregels of doorlooptijden kunnen hebben. Journaalposten voor aanpassingen aan het einde van de maand kunnen bijvoorbeeld complexer en urgenter zijn dan reguliere overlopende posten. Door het proces per categorie te analyseren, ontdek je deze verschillen en kun je verbeteringen afstemmen op specifieke typen journaalposten. Waarom dit belangrijk is Maakt het mogelijk om het proces te segmenteren op basis van het bedrijfsdoel van de journaalpost. Zo zie je verschillend gedrag en verschillende prestaties per type journaalpost. Waar je het vindt Beschikbaar in de tabel GL_JE_HEADERS, meestal in een veld met de naam JE_CATEGORY. Voorbeelden Overlopende postHandmatigAanpassingHerwaardering
	Reden van afwijzing RejectionReason	Een tekstuele omschrijving of code die uitlegt waarom een journaalpost is afgewezen.
Beschrijving Wanneer een journaalpost tijdens het goedkeuringsproces wordt afgewezen, legt dit attribuut de reden vast. Dat kan een vooraf gedefinieerde code zijn of een vrije tekst van de goedkeurder. Dit is een van de belangrijkste attributen voor een 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 direct inzicht in de oorzaken van herstelwerk en procesvertragingen. Zo kun je gericht verbeteren en het aantal afwijzingen verlagen. Waar je het vindt Deze informatie kan worden opgeslagen in workflow- of audittrailtabellen die bij het goedkeuringsproces horen, of in een notitieveld op de journaalkop. Voorbeelden Onjuiste rekeningcombinatieOnvoldoende ondersteunende documentatieBudget overschreden
	Boekhoudperiode AccountingPeriod	De fiscale periode waarin de journaalpost wordt geboekt, zoals 'Jan-24'.
Beschrijving Accounting Period geeft de financiële periode aan waarin de transactie wordt verwerkt. Dit vormt de basis voor financiële rapportage en analyses. Binnen process mining is dit attribuut belangrijk voor trendanalyses. Je kunt procesprestaties, zoals doorlooptijden of afwijspercentages, vergelijken tussen maanden of kwartalen. Zo zie je seizoenseffecten, zoals een hogere werkdruk tijdens de maandafsluiting, en meet je het effect van procesverbeteringen in de tijd. Waarom dit belangrijk is Maakt trendanalyses van KPI's in de tijd mogelijk. Zo kun je procesverbeteringen meten en seizoenspatronen herkennen, zoals de druk rond de maandafsluiting. Waar je het vindt Beschikbaar in de tabel GL_JE_HEADERS, meestal in een veld met de naam PERIOD_NAME. Voorbeelden Jan-24Feb-24Mrt-24
	Boeking op tijd IsOnTimePosting	Een berekende vlag die waar is als de journaalpost op of vóór de doel datum is geboekt.
Beschrijving Dit booleaanse attribuut wordt afgeleid door de timestamp van de activiteit 'Journal Entry Posted' te vergelijken met 'Target Posting Date'. Als de boeking op of vóór de doel datum plaatsvindt, is de waarde 'true'. Anders is de waarde 'false'. Dit attribuut ondersteunt rechtstreeks de KPI 'On-Time Journal Posting Rate' en vereenvoudigt de berekening. Je kunt te late journaalposten eenvoudig filteren en analyseren om veelvoorkomende oorzaken van vertragingen te vinden, zoals specifieke journaalcategorieën of goedkeurders. Waarom dit belangrijk is Geeft een duidelijke binaire uitkomst voor de boekingsprestatie. Zo worden analyses van tijdige verwerking en oorzaken van vertragingen eenvoudiger. Waar je het vindt 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
	Boekingsstatus PostingStatus	De huidige boekingsstatus van de journaalpost, bijvoorbeeld 'Unposted' of 'Posted'.
Beschrijving Dit attribuut geeft de huidige status van de journaalpost aan in relatie tot de boeking in het grootboek. Het is een belangrijke indicator voor de fase waarin een journaalpost zich bevindt, vooral bij cases die nog in behandeling zijn. Posting Status is belangrijk voor het dashboard 'Real-Time Journal Entry Status Tracker'. Het geeft een momentopname van alle actieve journaalposten. Zo kun je achterstanden met niet-geboekte journaalposten volgen en vertragingen in de laatste procesfasen opsporen. Waarom dit belangrijk is Geeft de huidige status van een journaalpost aan. Dat is belangrijk om achterstanden te volgen en de status van journaalposten in behandeling te bewaken. Waar je het vindt Beschikbaar in de tabel GL_JE_HEADERS, meestal in een kolom zoals STATUS of POSTING_STATUS. Voorbeelden GeboektNiet geboektFout
	Eindtijd EndTime	De timestamp die aangeeft wanneer een specifieke activiteit is afgerond.
Beschrijving End Time markeert het einde van een activiteit. Start Time registreert het begin, terwijl End Time het eindpunt vastlegt. Zo kun je de verwerkingstijd van die stap precies berekenen. Dit is nodig om verwerkingstijden per activiteit te berekenen. Die zijn belangrijk voor het vinden van knelpunten en het meten van de efficiëntie van ingezette capaciteit. Het verschil tussen End Time en Start Time van de activiteit 'Journaalpost beoordeeld' laat bijvoorbeeld zien hoeveel tijd een beoordelaar werkelijk aan de taak heeft besteed. Waarom dit belangrijk is Hiermee kun je de werkelijke duur of verwerkingstijd van afzonderlijke activiteiten berekenen. Dat is belangrijk om efficiëntieproblemen te vinden. Waar je het vindt Net als Start Time staat dit vaak in audittabellen. Je kunt de waarde ook afleiden uit de Start Time van de volgende activiteit in het proces. Voorbeelden 2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
	Geplande boekingsdatum TargetPostingDate	De vooraf bepaalde datum waarop de journaalpost uiterlijk naar verwachting wordt geboekt.
Beschrijving Target Posting Date 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. Je gebruikt de datum als referentie om prestaties te meten. Dit attribuut is nodig om de KPI 'On-Time Journal Posting Rate' te berekenen. Door de werkelijke boekingsdatum met deze doel datum te vergelijken, kan het systeem journaalposten automatisch als op tijd of te laat markeren. Zo krijg je een helder beeld van de naleving van de planning. Waarom dit belangrijk is Definieert de service level agreement of deadline voor het boeken en maakt de berekening van KPI's voor tijdige verwerking mogelijk. Waar je het vindt Dit is mogelijk geen standaardveld. De waarde kan worden afgeleid uit bedrijfsregels op basis van de aanmaakdatum, boekhoudperiode of journaalcategorie. Voorbeelden 2023-10-312023-11-302024-01-05
	Indicator voor terugboeking ReversalIndicator	Een vlag die aangeeft of de journaalpost een terugboeking van een andere journaalpost is.
Beschrijving Dit booleaanse attribuut identificeert journaalposten die zijn aangemaakt om een eerder geboekte journaalpost terug te draaien. Terugboekingen vormen een specifiek type journaalpost en volgen vaak een afwijkend, soms problematisch proces. Analyse van deze indicator is belangrijk voor het dashboard 'Journal Reversal Process Performance'. Je kunt terugboekingsprocessen afzonderlijk analyseren op frequentie, oorzaken en doorlooptijden. Zo spoor je onderliggende problemen op in de oorspronkelijke journaalposten die de terugboeking nodig maakten. Waarom dit belangrijk is Helpt het terugboekingsproces afzonderlijk te analyseren. Dat proces wijst vaak op fouten of problemen in de oorspronkelijke transactie. Waar je het vindt Dit kan een specifieke vlag in de tabel GL_JE_HEADERS zijn, zoals ACCRUAL_REV_FLAG, of worden vastgesteld via koppelingen met de oorspronkelijke journaalpost die wordt teruggeboekt. Voorbeelden truefalse
	Is herstelwerk IsRework	Een berekende vlag die waar is als de journaalpost een afwijzings- en correctieronde heeft doorlopen.
Beschrijving Dit booleaanse attribuut wordt berekend om cases te identificeren waarin herstelwerk heeft plaatsgevonden. Meestal krijgt het de waarde 'true' voor elke activiteit na een gebeurtenis 'Journal Entry Rejected', zoals 'Journal Corrected and Resubmitted'. Is Rework is een krachtig analyseattribuut. Je kunt er eenvoudig het volume en de impact van herstelwerklussen mee meten. Het ondersteunt rechtstreeks de KPI 'Average Journal Rework Rate' en helpt de procesflow en doorlooptijd van herstelde cases te vergelijken met cases die in één keer goed zijn verwerkt. Waarom dit belangrijk is Markeert direct cases die inefficiënte herstelwerklussen hebben doorlopen. Zo kun je de frequentie en impact van procesfouten eenvoudig meten. Waar je het vindt Dit is niet beschikbaar in het bronsysteem. De waarde wordt in de process mining-tool berekend door de activiteitenvolgorde van elke case te analyseren. Voorbeelden truefalse
	Naam grootboek LedgerName	De naam van het grootboek waarin de journaalpost wordt vastgelegd.
Beschrijving Ledger Name identificeert het specifieke grootboek waartoe de journaalpost behoort. Organisaties met meerdere juridische entiteiten of rapportagevereisten kunnen meerdere grootboeken hebben, zoals een primair grootboek voor de concernadministratie en secundaire grootboeken voor lokale wettelijke rapportages. Dit attribuut is essentieel om processen voor verschillende juridische entiteiten of bedrijfsonderdelen te filteren en te 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 Maakt het mogelijk om procesanalyses te filteren en te vergelijken voor verschillende juridische entiteiten of boekhoudkundige kaders. Dat is belangrijk voor grote organisaties. Waar je het vindt Te vinden in de tabel GL_JE_HEADERS, meestal gekoppeld via een LEDGER_ID. Die kun je met GL_LEDGERS verbinden om de naam op te halen. Voorbeelden Amerikaans primair grootboekBrits statutair grootboekGlobaal consolidatiegrootboek
	Totale end-to-end-doorlooptijd EndToEndCycleTime	De totale berekende duur vanaf het aanmaken van een journaalpost tot en met de definitieve reconciliatie.
Beschrijving Deze metriek geeft aan hoeveel tijd een journaalpost in het volledige proces doorbrengt, vanaf de eerste gebeurtenis 'Journal Entry Created' tot en met 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. De metriek wordt gebruikt in trenddashboards om het effect van verbeterinitiatieven in de tijd te volgen. Ook vormt deze een referentiepunt voor het meten van alle proceswijzigingen. Waarom dit belangrijk is Geeft op hoofdlijnen inzicht in de gezondheid en efficiëntie van het volledige proces. Daarmee is het een belangrijke metriek voor rapportage aan het management. Waar je het vindt Deze metriek wordt door het process mining-platform berekend als het tijdsverschil tussen de timestamp van de eerste en de laatste gebeurtenis van elke case. Voorbeelden P10DT5HP4DT12HP22D
	Valuta CurrencyCode	De valutacode voor het bedrag van de journaalpost, zoals USD, EUR of GBP.
Beschrijving Currency Code geeft aan in welke valuta de financiële bedragen in de journaalpost zijn uitgedrukt. Dat is belangrijk voor multinationale organisaties die transacties in meerdere valuta uitvoeren. Met dit attribuut worden financiële waarden correct geïnterpreteerd. Je kunt op valuta filteren. Het veld is ook nodig voor analyses waarin je geldbedragen uit verschillende regio's vergelijkt of samenvoegt. Waarom dit belangrijk is Geeft de benodigde context voor financiële bedragen, zodat je ze correct kunt interpreteren en analyses per valuta kunt uitvoeren. Waar je het vindt Beschikbaar in de tabel GL_JE_HEADERS, meestal in een veld met de naam CURRENCY_CODE. Voorbeelden USDEURGBPJPY

Verplicht Aanbevolen Optioneel

Van vastlegging tot rapportage - activiteiten van journaalposten

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

5 Aanbevolen 7 Optioneel

	Activiteit	Beschrijving
	Journaalpost aangemaakt	Deze activiteit markeert de start van het journaalpostproces. Het is het moment waarop een gebruiker een nieuwe journaalkop aanmaakt en data begint in te voeren, voordat de journaalpost ter beoordeling of goedkeuring wordt ingediend.
Waarom dit belangrijk is Dit is de belangrijkste startgebeurtenis van het proces. Door de tijd vanaf deze activiteit tot de volgende stappen te analyseren, meet je de efficiëntie van de eerste data-invoer en de totale doorlooptijd van het proces. Waar je het vindt Deze gebeurtenis wordt meestal afgeleid van de timestamp van de aanmaakdatum in de tabel GL_JE_HEADERS voor een specifieke Journal Entry ID. De gebruiker die het record heeft aangemaakt, staat ook in deze tabel. Vastleggen Gebruik CREATION_DATE uit de tabel GL_JE_HEADERS. Eventtype inferred
	Journaalpost geboekt	De financiële data van de journaalpost is succesvol vastgelegd in het General Ledger. De debet- en creditbedragen zijn nu verwerkt in de rekeningsaldi.
Waarom dit belangrijk is Dit is een belangrijk meetpunt: de journaalpost is opgenomen in het officiële financiële register. Het is essentieel voor het meten van het percentage boekingen op tijd en de totale tijd van aanmaak tot boeking. Waar je het vindt Dit wordt afgeleid uit een statuswijziging in de tabel GL_JE_HEADERS, waar het veld STATUS verandert naar 'P' (Posted). De tabel GL_JE_BATCHES bevat ook een boekingsstatus. Vastleggen Volg de timestamp waarop STATUS in GL_JE_HEADERS verandert naar 'P'. Eventtype inferred
	Journaalpost gereconcilieerd	De journaalpost is gematcht en afgeletterd tijdens de reconciliatie van een rekening aan het einde van een periode. Dit bevestigt dat de transactie overeenkomt met andere financiële data, zoals bankafschriften.
Waarom dit belangrijk is Deze activiteit vormt het echte eindpunt van de levenscyclus van de journaalpost. De tijd tussen boeken en reconciliatie is een belangrijke KPI voor het beoordelen van de efficiëntie van het financiële afsluitproces. Waar je het vindt Deze gebeurtenis wordt meestal vastgelegd in Oracle Financial Consolidation and Close Cloud Service (FCCS) of Account Reconciliation Cloud Service (ARCS), niet in het General Ledger zelf. Je leidt de gebeurtenis af uit een statuswijziging op het reconciliatierecord dat aan de journaalpost is gekoppeld. Vastleggen Koppel journaalpostdata aan statusupdates van reconciliaties uit ARCS- of FCCS-tabellen. Eventtype inferred
	Journaalpost goedgekeurd	De aangewezen goedkeurder heeft de journaalpost formeel goedgekeurd en daarmee de juistheid en geldigheid bevestigd. Dit is de laatste stap in de goedkeuringsworkflow en maakt de weg vrij voor het boeken.
Waarom dit belangrijk is Dit meetpunt markeert het einde van het goedkeuringsproces. De tijd tussen indiening en goedkeuring is een belangrijke KPI voor het meten van de efficiëntie van de workflow en het vinden van goedkeuringsknelpunten. Waar je het vindt Deze gebeurtenis wordt afgeleid uit een statuswijziging in de tabel GL_JE_HEADERS, waar APPROVAL_STATUS_CODE wordt bijgewerkt naar 'APPROVED'. Workflowtabellen bevatten de identiteit en timestamp van de goedkeurder. Vastleggen Volg de timestamp waarop APPROVAL_STATUS_CODE in GL_JE_HEADERS verandert naar 'APPROVED'. Eventtype inferred
	Journaalpost ingediend ter goedkeuring	Deze activiteit vindt plaats wanneer de gebruiker de voltooide journaalpost formeel indient voor de goedkeuringsworkflow. De journaalpost gaat daarmee van concept of onvolledig naar wachtend op goedkeuring.
Waarom dit belangrijk is Dit is een belangrijk meetpunt. Vanaf hier begint de klok voor het meten van goedkeuringsdoorlooptijden en het vinden van knelpunten. Het markeert de overgang van data-invoer naar beoordeling en goedkeuring. Waar je het vindt Deze gebeurtenis wordt afgeleid uit een statuswijziging in de tabel GL_JE_HEADERS, specifiek wanneer APPROVAL_STATUS_CODE verandert in een waarde zoals 'REQUIRED' of 'INITIATED'. De timestamp van de indiening kan ook worden opgeslagen. Vastleggen Volg de timestamp waarop APPROVAL_STATUS_CODE in GL_JE_HEADERS verandert om de indiening aan te geven. Eventtype inferred
	Boeking gecontroleerd	Een controle na het boeken waarbij een gebruiker of systeem bevestigt dat de journaalpost correct is geboekt en 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 kwaliteitsborging na het boeken kosten. Ook komen mogelijkheden voor automatisering van verificatieprocessen aan het licht. Waar je het vindt Dit is waarschijnlijk geen expliciete gebeurtenis in Oracle Fusion. Je moet de activiteit afleiden uit andere acties, zoals het uitvoeren van een specifiek rapport door een gebruiker of het bijwerken van een aangepast statusveld. Dat is geen standaardfunctie. Vastleggen Hiervoor is aangepaste logica nodig, bijvoorbeeld om de uitvoeringstijd van verificatierapporten of wijzigingen in een descriptive flexfield te volgen. Eventtype inferred
	Boeking van journaalpost gestart	Het boeken van de goedgekeurde journaalpost in het General Ledger is gestart. Dit kan een geautomatiseerde 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 goedkeuring en het technische boekingsproces. Vertraging tussen goedkeuring en de start van het boeken kan wijzen op planningsproblemen of beperkte capaciteit in de boekingsengine. Waar je het vindt Je kunt dit afleiden uit statuswijzigingen in de tabel GL_JE_BATCHES of uit de indieningstijd van het gelijktijdige boekingsverzoek dat aan de journaalbatch is gekoppeld. Vastleggen Identificeer de indieningstijd van het General Ledger Posting-programma voor de specifieke journaalbatch. Eventtype inferred
	Journaalpost afgewezen	Een goedkeurder heeft de journaalpost beoordeeld en afgewezen vanwege fouten, ontbrekende documentatie of overtreding van beleid. De journaalpost gaat terug naar de maker voor correctie.
Waarom dit belangrijk is Deze activiteit is belangrijk voor het analyseren van herstelrondes, afwijzingspercentages en first-time-right-KPI's. Veel afwijzingen wijzen vaak op problemen met datakwaliteit of training. Waar je het vindt Dit wordt afgeleid uit een statuswijziging in de tabel GL_JE_HEADERS wanneer APPROVAL_STATUS_CODE wordt bijgewerkt naar 'REJECTED'. De workflowhistorie registreert de gebruiker en timestamp van deze actie. Vastleggen Volg de timestamp waarop APPROVAL_STATUS_CODE in GL_JE_HEADERS wordt ingesteld op 'REJECTED'. Eventtype inferred
	Journaalpost beoordeeld	Een beoordelingsstap die vóór of als onderdeel van het formele goedkeuringsproces kan plaatsvinden. Een collega of manager controleert of de journaalpost klopt en aan de compliance-eisen voldoet voordat die naar de eindgoedkeurder gaat.
Waarom dit belangrijk is Door deze activiteit apart te analyseren, maak je onderscheid tussen de tijd voor een eerste beoordeling en de tijd voor de definitieve goedkeuring. Zo komen verborgen knelpunten aan het licht als de beoordelingsfase informeel maar tijdrovend is. Waar je het vindt Dit kan een expliciete stap zijn in een goedkeuringsworkflow met meerdere fasen, vastgelegd in workflowhistorietabellen. Bij een informele beoordeling wordt de stap niet vastgelegd. Je kunt de activiteit afleiden als een specifieke gebruikersactie vóór de definitieve goedkeuringsbeslissing wordt geregistreerd. Vastleggen Analyseer workflowhistorietabellen op tussentijdse goedkeurings- of beoordelingsstappen vóór de definitieve status 'Approved'. Eventtype inferred
	Journaalpost gecorrigeerd en opnieuw ingediend	Na een afwijzing corrigeert de maker de journaalpost en dient die opnieuw in ter goedkeuring. Deze activiteit markeert de start van een nieuwe goedkeuringscyclus voor dezelfde journaalpost.
Waarom dit belangrijk is Het volgen van herstelwerk 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 je het vindt Dit is een volgende gebeurtenis 'Journaalpost ingediend ter goedkeuring' voor een journaalpost die eerder de status 'REJECTED' had. Je herkent deze gebeurtenis door de reeks statuswijzigingen voor één Journal Entry ID te analyseren. Vastleggen Identificeer een timestamp van een indiening die na een afwijzing voor dezelfde case-ID plaatsvindt. Eventtype inferred
	Ondersteunende documentatie toegevoegd	Dit is het toevoegen van ondersteunende documenten, zoals facturen of spreadsheets, aan de journaalpost. Dat gebeurt vaak om auditors en goedkeurders context en bewijs te geven.
Waarom dit belangrijk is Door deze activiteit te volgen, zie je of vertragingen worden veroorzaakt door ontbrekende documentatie. Je krijgt ook inzicht in compliance en de volledigheid van journaalposten voordat ze de goedkeuringsworkflow ingaan. Waar je het vindt Dit is lastig als afzonderlijke gebeurtenis te volgen. Je kunt de activiteit afleiden uit timestamps in bijlagetabellen zoals FND_ATTACHED_DOCUMENTS, gekoppeld aan het journaalpostrecord in GL_JE_HEADERS. Vastleggen Leid dit af uit de aanmaakdatum van records in FND_ATTACHED_DOCUMENTS die aan het journaal zijn gekoppeld. Eventtype inferred
	Terugboeking van journaalpost verwerkt	Er is een tegenboekingsjournaalpost aangemaakt en geboekt om het financiële effect van de oorspronkelijke journaalpost in een volgende periode teniet te doen. Dit gebeurt vaak bij overlopende posten.
Waarom dit belangrijk is Door terugboekingen te volgen, zie je welke typen journaalposten vaak worden teruggeboekt en kun je de efficiëntie van het terugboekingsproces analyseren. Dit kan wijzen op problemen met het beheer van overlopende posten. Waar je het vindt Dit wordt afgeleid door een nieuwe journaalpost te identificeren die expliciet aan de oorspronkelijke journaalpost is gekoppeld als terugboeking. De tabel GL_JE_HEADERS bevat velden zoals REVERSAL_PERIOD en REVERSAL_FLAG om deze journaalposten te identificeren en aan elkaar te koppelen. Vastleggen Identificeer de aanmaak- en boekingsdatum van de nieuwe journaalpost waarvan de kop verwijst naar de oorspronkelijke journaalpost als teruggeboekt. Eventtype inferred

Aanbevolen Optioneel

Extractiegidsen

Zo haal je data uit Oracle Fusion Financials

Stappen

Ga naar de werkruimte Reports and Analytics: Log in bij Oracle Fusion Financials. Open het menu Navigator, ga naar Tools en selecteer Reports and Analytics. Dit is de centrale plek voor het maken en beheren van analyses en rapporten.
Maak een BI Publisher-datamodel: Begin voor dit type event log-extractie niet met een OTBI Analysis. Het is efficiënter om rechtstreeks een BI Publisher-datamodel te maken. Daarmee 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.
Definieer de SQL-querydataset: Klik in de editor van het datamodel op het pictogram '+' om een nieuwe Data Set toe te voegen en selecteer 'SQL Query'. Geef de dataset een duidelijke naam, bijvoorbeeld 'JournalEventLog'.
Voer de SQL-query in: Selecteer 'Oracle BI EE' als Data Source. Kopieer het volledige SQL-script uit het gedeelte Query hieronder en plak het in het tekstvak SQL Query. De query haalt alle benodigde activiteiten en attributen op in één uniforme structuur.
Definieer parameters: De query gebruikt parameters zoals :start_date, :end_date en :ledger_name. De interface van het datamodel herkent deze automatisch. Je moet ze als parameters configureren en het juiste datatype instellen, zoals Date of Text. Voeg indien nodig standaardwaarden toe. Zo kun je het rapport flexibel uitvoeren.
Maak een rapport vanuit het datamodel: Sla het datamodel op en ga terug naar de catalogus. Klik op Create > Report. Selecteer in de wizard voor het maken van rapporten 'Use Existing Data Model' en zoek het datamodel dat je net hebt gemaakt.
Configureer de rapportindeling: Kies in de layout-editor de indeling 'Table'. Sleep alle kolommen uit het datamodel naar de tabel, zodat ze in de export worden opgenomen. Complexe opmaak is niet nodig.
Stel CSV in als standaarduitvoer: Ga in de rapporteditor naar de link 'View a List'. Controleer in het gedeelte 'Output Formats' of 'CSV' is geselecteerd. Het is verstandig om de andere indelingen uit te schakelen, zodat het plannen eenvoudiger wordt. 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. Stel de frequentie in, bijvoorbeeld dagelijks of wekelijks.
Configureer export en levering: 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 instellen dat het bestand automatisch wordt afgeleverd op een locatie op de contentserver (UCM) of op een externe SFTP-server.
Haal de data op en bereid deze voor: Haal het gegenereerde CSV-bestand op zodra de geplande taak is uitgevoerd. Controleer of de kolomkoppen voldoen aan de vereisten voor opname in ProcessMind: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, enzovoort. Het bestand is nu klaar om te uploaden.

Configuratie

Databron: De query moet worden uitgevoerd op de databron ‘Oracle BI EE’ in BI Publisher. Deze maakt verbinding met de onderliggende transactionele databaseweergaven die OTBI ondersteunen.
Belangrijkste onderwerpgebieden (ter referentie): De querylogica is voornamelijk gebaseerd op data uit het onderwerpgebied ‘General Ledger - Journals Real Time’. Daarnaast worden logisch gegevens gekoppeld die afkomstig zouden zijn uit ‘HCM - Workforce Management - Worker Assignment Real Time’ voor gebruikersgegevens en mogelijk uit workflow-onderwerpgebieden voor de goedkeuringsgeschiedenis.
Filteren op periode: Het is belangrijk om de data te beperken tot een beheersbare periode. De query bevat de parameters :start_date en :end_date. Voor een eerste analyse raden we aan 3 tot 6 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. Extractie voor alle grootboeken tegelijk kan leiden tot zeer grote bestanden en prestatieproblemen.
Vereisten: De gebruiker die het rapport maakt en plant, moet over de juiste BI-rollen beschikken, zoals ‘BI Administrator’ of ‘BI Author’. Daarnaast moet het databeveiligingsprofiel van de gebruiker toegang geven tot de specifieke grootboeken en bedrijfseenheden waarvoor de query wordt uitgevoerd.
Planning: Plan de extractie voor optimale prestaties en om gebruikers zo min mogelijk te hinderen buiten piekuren, bijvoorbeeld ’s nachts.

a 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: Log in bij Oracle Fusion Financials. Open het menu Navigator, ga naar Tools en selecteer Reports and Analytics. Hiermee open je de Business Intelligence-catalogus.
Maak een nieuw datamodel: Klik in de BI-catalogus op de knop Create en selecteer Data Model. De editor van het datamodel wordt geopend.
Definieer de SQL-querydataset: Klik in de editor van het datamodel op het plusteken op het tabblad Diagram en selecteer SQL Query. Geef de dataset in het nieuwe dialoogvenster een naam, bijvoorbeeld ProcessMind_JE_EventLog. Selecteer de juiste Data Source, meestal FUSIONDB. Plak de volledige SQL-query in het tekstvak SQL Query.
Definieer parameters: De query gebruikt parameters voor het datumbereik (p_start_date en p_end_date). Oracle BI Publisher herkent deze automatisch. Configureer ze als parameters van het type Text en gebruik 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 definiëren 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 van het datamodel op de knop Create Report. De wizard voor het maken van rapporten wordt geopend.
Configureer de rapportindeling: Selecteer in de wizard de optie om het huidige datamodel te gebruiken. Kies de indeling 'Table'. Sleep alle kolommen uit de databron naar het gedeelte voor de tabelindeling. 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 het: Open het rapport. Je wordt gevraagd om de begin- en einddatum in te voeren. Geef het gewenste datumbereik op en klik op Apply. Klik na het uitvoeren van het rapport op Export en kies de CSV-indeling om het event log-bestand 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 het ProcessMind-platform.

Configuratie

Vereisten: De gebruiker die het rapport uitvoert, moet een rol hebben met de benodigde databeveiligingsrechten voor toegang tot General Ledger-data, zoals General Accountant of een aangepaste BI-rol. Ook toegang tot de BI Publisher-tool is vereist.
Databron: Het BI Publisher-datamodel moet zijn geconfigureerd met de applicatiedatabaseverbinding FUSIONDB.
Parameters voor de periode: De query bevat de parameters p_start_date en p_end_date om het extractievenster te bepalen. Begin bij voorkeur met een periode van 3 tot 6 maanden, zodat de prestaties beheersbaar blijven.
Rapportfilters: Voor grote organisaties is het sterk aan te raden om filters rechtstreeks toe te voegen aan de WHERE-clausule van de common table expression JournalHeaders in de query. Filteren op LEDGER_ID of LEGAL_ENTITY_ID is essentieel om de hoeveelheid data beheersbaar te houden.
Aandacht voor prestaties: Het uitvoeren van deze query op een grote productiedatabase kan veel bronnen gebruiken. Plan het rapport buiten piekuren om de invloed op de systeemprestaties te beperken.
Uitvoerformaat: Configureer het rapport om een CSV-bestand te genereren. Dit levert een duidelijke, gestructureerde indeling op voor inladen in process mining-tools.

a Voorbeeldquery sql

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Stappen

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 General Ledger Journals REST API. Verzamel de URL van je Oracle Fusion-instantie, je gebruikersnaam en je wachtwoord.
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 verwerkt de codering van de gebruikersnaam en het wachtwoord in de requestheaders.
Functie voor API-aanroepen definiëren: Maak een functie die de API-aanvragen afhandelt. Deze functie moet paginering beheren met de parameters offset en limit. De functie blijft API-aanroepen uitvoeren tot alle journaalrecords binnen het opgegeven datumbereik zijn opgehaald.
API-query opbouwen: Gebruik de parameter q in de API-aanvraag om journaalposten te filteren op LastUpdateDate. Zo haal je gericht data op binnen een bepaalde periode, bijvoorbeeld LastUpdateDate between '2023-01-01' and '2023-03-31'.
Data ophalen: Roep de functie aan om data op te halen uit het endpoint .../fscmRestApi/resources/11.13.18.05/journals. De functie retourneert een volledige lijst met journaalposten.
Data verwerken en transformeren: Loop door elke journaalpost die de API retourneert. Maak voor elke journaalpost meerdere eventregels voor de verschillende bedrijfsactiviteiten (Journal Entry Created, Journal Entry Approved, enzovoort). Gebruik de datumvelden en statuscodes uit de API-respons (CreationDate, PostedDate, ApprovalStatus, enzovoort) om deze afzonderlijke events te maken.
Event log structureren: Sla elke gegenereerde eventregel op als een dictionary in een lijst. Deze lijst wordt 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 kolommen van het DataFrame en geef ze een nieuwe naam, zodat ze voldoen aan het vereiste schema van ProcessMind: JournalEntryId, ActivityName, EventTime, UserName, enzovoort.
Exporteren naar CSV: Sla het 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 gebruikt het endpoint fscmRestApi/resources/11.13.18.05/journals om General Ledger-data op te halen.
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 3 tot 6 maanden aan. Stel voor doorlopend gebruik dagelijkse of wekelijkse incrementele loads in.
Pagineringlimiet: De parameter limit bepaalt hoeveel records per API-aanroep worden opgehaald. Een waarde tussen 200 en 500 werkt meestal goed, omdat je daarmee het aantal API-aanroepen en de omvang van elke respons in balans houdt.
Vereiste Oracle-rollen: Het gebruikersaccount moet een rol hebben met de benodigde rechten om journaaldata via de REST API te lezen, zoals General Accountant of een aangepaste rol met gelijkwaardige rechten.

a Voorbeeldquery python

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

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

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

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

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

    return all_journals

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

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

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

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

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

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

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

    return pd.DataFrame(event_log)

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

Stappen

Controleer of BI Cloud Connector, de vereiste Oracle Fusion Financials General Ledger-subject areas of Public View Objects en de benodigde autorisaties in je omgeving beschikbaar zijn. Controleer samen met je Oracle-beheerder het geconfigureerde BICC-doel voor levering en de bijbehorende toegangsgegevens.
Zoek in de BICC-console de Public View Objects met journaalkoppen, journaalregels, goedkeuringsgeschiedenis, bijlagen, boekingsstatus, reconciliatiestatus en informatie over terugboekingen. Noteer de exacte object- en attribuutnamen die in jouw omgeving zijn geconfigureerd. Vervang de placeholders in het extractiescript door deze namen voordat je het script uitvoert.
Configureer een BICC-taak voor de geselecteerde General Ledger Public View Objects. Gebruik incrementele extractie als er een betrouwbaar attribuut voor de laatste wijziging beschikbaar is. Gebruik voor de eerste load een gecontroleerde periode van drie tot zes maanden, of een andere goedgekeurde boekhoudperiode.
Configureer BICC om de extractbestanden af te leveren op de aangewezen locatie voor cloudopslag. Controleer de bestandsindeling, scheidingstekens, tekencodering, compressie, partitionering, naamgevingsconventie en planning. Bewaar de extractiewatermark of timestamp van de laatste geslaagde extractie.
Haal de afgeleverde bestanden op naar de goedgekeurde stagingomgeving. Laad elk bronbestand in de bijbehorende stagingtabel of -weergave. Gebruik de exacte bronobject- en attribuutkoppelingen die voor jouw omgeving zijn vastgelegd. Ga er niet van uit dat een Public View Object dezelfde structuur heeft als een onderliggende databasetabel.
Normaliseer timestamps naar één tijdzone en zet bron-timestamps om naar één consistent timestamp-datatype. Bewaar de timestamp van de laatste bronupdate als LastDataUpdate. Zet bronidentifiers en activiteitsattributen om naar de uitvoernamen die ProcessMind gebruikt.
Voer de query hieronder uit nadat je elke placeholder hebt vervangen door de werkelijke namen van stagingobjecten en attributen. De query maakt expliciet één event-logregel voor elk van de 12 vereiste activiteiten. De query leidt geen activiteiten af die niet in de brondata staan.
Controleer of JournalEntryId, ActivityName, EventTime, SourceSystem en LastDataUpdate voor elke uitvoerregel aanwezig zijn. 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 ander door ProcessMind ondersteund formaat. Gebruik exact de kolomnamen JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount en RejectionReason. Upload het bestand met JournalEntryId als case-identificatie, ActivityName als activiteit en EventTime als event-timestamp.

Configuratie

Configureer BICC voor de General Ledger Public View Objects die nodig zijn voor journaalkoppen, journaalregels, goedkeurings- of workflowgeschiedenis, bijlagen, boekingsdata, reconciliatie en terugboekingen. Controleer de exacte objectnamen en attributen in de BICC-catalogus voor jouw omgeving.
Gebruik een eerste extractieperiode van drie tot zes maanden. Verleng deze periode pas nadat je het volume, de opslagcapaciteit, de extractieduur en de verwerkingstijd in de volgende stappen hebt gecontroleerd.
Pas goedgekeurde filters toe voor boekingsdatum of datum van laatste wijziging, ledger, juridische entiteit, bedrijfseenheid, bedrijfscode waar beschikbaar, journaalcategorie, journaalbron, documenttype waar beschikbaar en journaalstatus. Gebruik alleen filters die door de geselecteerde Public View Objects worden ondersteund.
Configureer incrementele extractie met het bronattribuut voor de laatste wijziging en een opgeslagen watermark. Voeg indien nodig een kleine overlap toe om late updates op te vangen. Verwijder daarna dubbele records op basis van JournalEntryId, ActivityName, EventTime en de relevante bronidentifier van het event.
Zorg dat alle bronobjecten compatibele extractiesleutels en vernieuwingsschema's gebruiken. Goedkeurings-, bijlage-, boekings-, reconciliatie- en terugboekingsdata kunnen op verschillende momenten worden vernieuwd.
Partitioneer grote datasets op boekingsperiode, ledger, juridische entiteit of een ander door BICC ondersteund partitioneringsattribuut. Vermijd onbeperkte historische extracties tijdens kantooruren.
Bewaar bron-timestamps en timestamps van bronupdates vóór de transformatie. Leg vast welke tijdzone je gebruikt voor EventTime en LastDataUpdate.
Vereiste voorwaarden zijn toegang tot de BI Cloud Connector-console, toestemming om de geselecteerde extracties te configureren en uit te voeren, toegang tot de geconfigureerde cloudopslag, toegang tot de stagingomgeving en toestemming om de benodigde General Ledger- en workflowdata te bekijken.
Controleer of de vereiste Oracle Fusion Financials-modules, workflowconfiguratie, opslag voor bijlagen, boekingsprocessen en databronnen voor reconciliatie zijn ingeschakeld voor de activiteiten die je verwacht.
Beschouw een ontbrekend bronrecord niet als bewijs dat een activiteit niet heeft plaatsgevonden. De BICC-uitvoer weerspiegelt de geselecteerde Public View Objects, filters, vernieuwingsmomenten, bewaartermijnen en beschikbare geschiedenis.

a 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 aan de slag te gaan?

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

Terug naar de verbetergids Template downloaden

Versnel vandaag je Record to Report - Journaalpostproces

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

Start je gratis proefperiode

Je hebt geen creditcard nodig. Activeer nu je proefperiode.

Jouw datatemplate voor Record to Report - Journaalpost

Jouw datatemplate voor Record to Report - Journaalpost

Van vastlegging tot rapportage - attributen van journaalposten

Van vastlegging tot rapportage - activiteiten van journaalposten

Extractiegidsen

Export van Oracle OTBI- en BI Publisher-rapporten

Stappen

Configuratie

a Voorbeeldquery sql

BI Publisher-rapport met directe SQL-query in het datamodel

Stappen

Configuratie

a Voorbeeldquery sql

Python-script met de Oracle Fusion Financials REST API

Stappen

Configuratie

a Voorbeeldquery python

Bulkdata-extractie met BI Cloud Connector (BICC)

Stappen

Configuratie

a Voorbeeldquery sql

Klaar om aan de slag te gaan?

Versnel vandaag je Record to Report - Journaalpostproces

Jouw datatemplate voor Record to Report - Journaalpost

Jouw datatemplate voor Record to Report - Journaalpost

Van vastlegging tot rapportage - attributen van journaalposten

Van vastlegging tot rapportage - activiteiten van journaalposten

Extractiegidsen

Export van Oracle OTBI- en BI Publisher-rapporten

Stappen

Configuratie

a Voorbeeldquery sql

BI Publisher-rapport met directe SQL-query in het datamodel

Stappen

Configuratie

a Voorbeeldquery sql

Python-script met de Oracle Fusion Financials REST API

Stappen

Configuratie

a Voorbeeldquery python

Bulkdata-extractie met BI Cloud Connector (BICC)

Stappen

Configuratie

a Voorbeeldquery sql

Klaar om aan de slag te gaan?

Versnel vandaag je Record to Report - Journaalpostproces

We respecteren je privacy