> Continue procesverbetering > Record to report Journaalboekingen > Oracle Fusion Financialscials > Datatemplate

Uw Record to report - Journaalboekingens `datatemplate`

Oracle Fusion Financialscials

Record to report - `Attributen` Journaalboekingen (21) Record to report - Activiteiten Journaalboekingen (12) Extractiegidsen (4)

Uw Record to report - Journaalboekingens `datatemplate`

Deze datatemplate biedt een volledige gids voor het extraheren en structureren van uw Oracle Fusion Financialscials Journaalboekingen data. Het schetst de essentiële attributen die je moet verzamelen en de belangrijkste activiteiten die je moet volgen, wat garandeert dat u alle noodzakelijke Informatie vastlegt voor betrouwbare procesanalyse. Je vindt ook praktische begeleiding over hoe u deze data direct uit je systeem kunt extraheren.

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

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

Template downloaden

Record to report - `Attributen` Journaalboekingen

Dit zijn de aanbevolen velden om op te nemen in uw event log voor een grondige analyse van uw Record to report - Journaalboekingen proces.

5 Verplicht 6 Aanbevolen 10 Optioneel

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

Verplicht Aanbevolen Optioneel

Record to report - Activiteiten Journaalboekingen

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

5 Aanbevolen 7 Optioneel

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

Aanbevolen Optioneel

Extractiegidsen

Zo haal je je data uit Oracle Fusion Financialscials

Stappen

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

Configuratie

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

a Voorbeeldquery config

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Stappen

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

Configuratie

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

a Voorbeeldquery sql

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Stappen

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

Configuratie

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

a Voorbeeldquery python

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

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

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

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

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

    return all_journals

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

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

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

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

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

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

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

    return pd.DataFrame(event_log)

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

Stappen

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

Configuratie

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

a Voorbeeldquery config

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Uw Record to report - Journaalboekingens `datatemplate`

Uw Record to report - Journaalboekingens `datatemplate`

Record to report - `Attributen` Journaalboekingen

Record to report - Activiteiten Journaalboekingen

Extractiegidsen

Oracle OTBI en BI Publisher Rapport Export

Stappen

Configuratie

a Voorbeeldquery config

BI Publisher Rapport met Directe SQL Data Model Query

Stappen

Configuratie

a Voorbeeldquery sql

Python-script met Oracle Fusion Financialscials REST API

Stappen

Configuratie

a Voorbeeldquery python

Bulkdata-extractie met BI Cloud Connector (BICC)

Stappen

Configuratie

a Voorbeeldquery config

Klaar om te starten?

Versnel uw Record to report - Journaalboekingenenproces vandaag nog

Uw Record to report - Journaalboekingens datatemplate

Uw Record to report - Journaalboekingens datatemplate

Record to report - Attributen Journaalboekingen

Record to report - Activiteiten Journaalboekingen

Extractiegidsen

Oracle OTBI en BI Publisher Rapport Export

Stappen

Configuratie

a Voorbeeldquery config

BI Publisher Rapport met Directe SQL Data Model Query

Stappen

Configuratie

a Voorbeeldquery sql

Python-script met Oracle Fusion Financialscials REST API

Stappen

Configuratie

a Voorbeeldquery python

Bulkdata-extractie met BI Cloud Connector (BICC)

Stappen

Configuratie

a Voorbeeldquery config

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Versnel uw Record to report - Journaalboekingenenproces vandaag nog

Uw Record to report - Journaalboekingens `datatemplate`

Uw Record to report - Journaalboekingens `datatemplate`

Record to report - `Attributen` Journaalboekingen