> Miglioramento continuo dei processi > Record to Report Registrazione contabile > Oracle Fusion Financials > Template dei dati

Il Suo Template dati per Record to Report - Journal Entry

Oracle Fusion Financials

← Torna alla guida al miglioramento

Record to Report - Attributi della registrazione contabile (21) Record to Report - Attività della registrazione contabile (12) Guide all’estrazione (4)

Il Suo Template dati per Record to Report - Journal Entry

Questo Template dati offre una guida completa per estrarre e strutturare i dati di Oracle Fusion Financials relativi a Journal Entry. Illustra gli Attributi essenziali da raccogliere e le attività principali da monitorare, così da acquisire tutte le informazioni necessarie per un’analisi approfondita del processo. Include inoltre indicazioni pratiche per estrarre direttamente questi dati dal Suo sistema.

Attributi consigliati da raccogliere
Attività principali da monitorare
Indicazioni per l’estrazione da Oracle Fusion Financials

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il Template

Record to Report - Attributi della registrazione contabile

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa del processo Record to Report - registrazione contabile.

5 Obbligatorio 6 Consigliato 10 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Il nome dello specifico evento aziendale o Task che si è verificato in un determinato momento del processo di Journal Entry.
Descrizione L’Activity Name descrive un singolo passaggio del ciclo di vita di una registrazione contabile, come 'Journal Entry Created' o 'Journal Entry Approved'. Questi dati sono fondamentali per creare la mappa di processo e comprendere la sequenza degli eventi. L’analisi delle attività consente di identificare il flusso del processo, inclusi percorsi standard, deviazioni e cicli di rilavorazione. Monitorando le diverse attività, è possibile misurare il tempo trascorso nelle fasi specifiche, come l’approvazione, e individuare i passaggi più lunghi o soggetti a errori. Perché è importante Definisce i passaggi del processo, costituisce la struttura portante della mappa di processo e consente di analizzare flusso, colli di bottiglia e variazioni. Dove reperirlo Questo attributo deriva generalmente da modifiche di stato, Event Log o tabelle di audit trail associate agli oggetti di Journal Entry nel modulo General Ledger. Esempi Journal Entry creataJournal Entry inviata per l’approvazioneJournal Entry approvataJournal Entry contabilizzata
	ID della registrazione contabile JournalEntryId	L’identificativo univoco di una singola registrazione contabile, che collega tutte le attività finanziarie correlate.
Descrizione Il Journal Entry ID funge da identificativo principale del caso e collega in modo univoco tutte le attività relative a uno specifico insieme di transazioni finanziarie. Consente di monitorare l’intero ciclo di vita di una singola registrazione contabile, dall’avvio alla contabilizzazione finale, assicurando che tutti gli addebiti e gli accrediti siano contabilizzati. Nel Process Mining, questo ID è essenziale per ricostruire il percorso end-to-end di ogni registrazione contabile. Collega eventi distinti come 'Journal Entry Created', 'Journal Submitted For Approval' e 'Journal Entry Posted' in un flusso di processo coerente, consentendo di analizzare i tempi di ciclo, i colli di bottiglia e le variazioni del processo. Perché è importante È la chiave fondamentale per monitorare una registrazione contabile dall’inizio alla fine e analizzare l’intero flusso di processo di ogni caso univoco. Dove reperirlo È una chiave primaria presente nelle tabelle principali del General Ledger, come GL_JE_HEADERS e GL_JE_LINES. Esempi JE100523JE202311001882019
	Ora di inizio EventTime	Il timestamp che indica quando si è verificata una specifica attività o un determinato evento.
Descrizione Questo timestamp indica la data e l’ora esatte in cui è stata eseguita un’attività. È il principale elemento temporale utilizzato nel Process Mining per determinare la sequenza degli eventi e calcolare la durata tra di essi. L’accuratezza dell’Event Time è fondamentale per tutte le analisi basate sul tempo, inclusi il calcolo dei tempi di ciclo, l’identificazione dei colli di bottiglia e il monitoraggio delle performance rispetto agli accordi sui livelli di servizio. Fornisce l’ordine cronologico necessario per ricostruire il flusso del processo così come si è verificato. Perché è importante Questo timestamp è essenziale per ordinare gli eventi, calcolare tutte le durate del processo ed eseguire qualsiasi analisi basata sul tempo. Dove reperirlo Queste informazioni sono generalmente archiviate nelle tabelle di audit trail oppure come 'Last Update Date' o 'Creation Date' nelle tabelle delle transazioni, come GL_JE_HEADERS e GL_JE_LINES, per eventi specifici. Esempi 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
	Sistema di origine SourceSystem	Il sistema o il modulo da cui hanno origine i dati.
Descrizione Questo attributo identifica il sistema di origine dal quale sono stati estratti i dati del processo. In un panorama IT complesso, i dati possono provenire da più sistemi integrati e questo campo aiuta a distinguerli. Nell’analisi dei processi, conoscere il sistema di origine è fondamentale per comprendere le variazioni del processo che possono dipendere da comportamenti diversi dei sistemi. Aiuta inoltre a convalidare i dati e a risolvere i problemi, consentendo di risalire alla loro origine. Perché è importante Identifica l’origine dei dati, un elemento fondamentale per la governance dei dati, la convalida e la comprensione delle variazioni del processo tra sistemi diversi. Dove reperirlo Spesso si tratta di un valore statico configurato durante l’estrazione dei dati, oppure di un campo nelle tabelle di origine che identifica il sistema di inserimento. Esempi Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp dell’aggiornamento o dell’estrazione più recente dei dati dal sistema di origine.
Descrizione Questo attributo registra quando il dataset è stato aggiornato l’ultima volta. Fornisce il contesto sulla freschezza dei dati analizzati, un elemento importante per comprendere la rilevanza degli insight ottenuti. In qualsiasi analisi, soprattutto nei Dashboard operativi, conoscere l’orario dell’ultimo aggiornamento dei dati è fondamentale affinché gli utenti possano fidarsi dei dati e prendere decisioni informate. Comunica chiaramente il punto di cutoff dei dati inclusi nel modello di Process Mining. Perché è importante Indica la freschezza dei dati, assicurando che gli utenti comprendano quanto sia aggiornata l’analisi del processo e possano fidarsi degli insight. Dove reperirlo Questo valore viene generato e archiviato durante il processo di estrazione e trasformazione dei dati. In genere corrisponde al timestamp di completamento del job ETL/ELT. Esempi 2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
	Categoria della Journal JournalCategory	La categoria della registrazione contabile, ad esempio 'Accrual', 'Adjustment' o 'Reclassification'.
Descrizione Journal Category classifica le registrazioni in base alla loro finalità aziendale. Questa classificazione consente un’analisi più granulare del processo, poiché categorie diverse possono avere flussi di processo, regole di approvazione o tempi di ciclo distinti. Ad esempio, le registrazioni di rettifica di fine mese possono seguire un processo più complesso e urgente rispetto agli accantonamenti ordinari. Analizzare il processo per categoria aiuta a individuare queste variazioni e a definire miglioramenti mirati per specifici tipi di registrazione contabile. Perché è importante Consente di segmentare il processo in base alla finalità aziendale della registrazione, facendo emergere comportamenti e performance diversi per i vari tipi di registrazione. Dove reperirlo Disponibile nella tabella GL_JE_HEADERS, generalmente in un campo denominato JE_CATEGORY. Esempi RateoManualeRettificaRivalutazione
	Importo della registrazione JournalAmount	Il valore monetario complessivo della registrazione contabile, generalmente pari alla somma degli addebiti.
Descrizione Questo attributo rappresenta il valore finanziario complessivo movimentato nella registrazione contabile. L’importo può influenzare in modo significativo il processo. Ad esempio, le registrazioni di importo elevato potrebbero richiedere ulteriori fasi di approvazione o verifiche più approfondite. L’analisi di Journal Amount consente di segmentare i casi in base all’impatto finanziario. Aiuta a rispondere a domande come «Le registrazioni di importo elevato richiedono più tempo per essere approvate?» oppure «I rifiuti sono più frequenti per le registrazioni superiori a una determinata soglia?». In questo modo fornisce un contesto aziendale essenziale per interpretare il flusso del processo. Perché è importante Fornisce un contesto aziendale essenziale, consentendo di analizzare i processi in base all’impatto finanziario e di individuare se le registrazioni di importo elevato seguono un processo diverso. Dove reperirlo Questo valore viene generalmente calcolato come somma degli addebiti o degli accrediti presenti nella tabella GL_JE_LINES per una determinata registrazione contabile. Esempi 5000.00125000.75750.50
	Motivo del rifiuto RejectionReason	Una descrizione testuale o un codice che spiega perché una registrazione contabile è stata rifiutata.
Descrizione Quando una registrazione contabile viene rifiutata durante il processo di approvazione, questo attributo ne registra il motivo. Può trattarsi di un codice predefinito oppure di un commento in testo libero inserito dall’approvatore. È uno degli attributi più importanti per l’analisi delle cause alla radice delle inefficienze di processo. Analizzando i motivi di rifiuto più frequenti, le organizzazioni possono individuare aree di miglioramento, come una formazione più efficace per i preparatori, linee guida più chiare o il potenziamento dei controlli di sistema. Supporta direttamente il Dashboard «Journal Entry Rejection Rate Analysis». Perché è importante Fornisce una visione diretta delle cause alla radice delle rilavorazioni e dei ritardi di processo, consentendo interventi mirati per ridurre il tasso di rifiuto. Dove reperirlo Queste informazioni possono essere memorizzate nelle tabelle Workflow o di audit trail associate al processo di approvazione, oppure in un campo note dell’intestazione della registrazione contabile. Esempi Combinazione di conti errataDocumentazione giustificativa insufficienteBudget superato
	Origine della Journal JournalSource	Il subledger o il sistema di origine che ha generato la registrazione contabile, ad esempio 'Payables', 'Receivables' o 'Manual'.
Descrizione Questo attributo indica l’origine della registrazione contabile all’interno del sistema ERP. Le registrazioni possono essere create manualmente nella contabilità generale oppure generate automaticamente da moduli secondari come Accounts Payable, Accounts Receivable o Fixed Assets. Journal Source è un attributo fondamentale per l’analisi dell’automazione. Consente di distinguere le registrazioni manuali da quelle generate dal sistema e supporta il KPI «Automated Journal Entry Rate». I processi relativi a registrazioni provenienti da fonti diverse presentano spesso differenze significative in termini di complessità ed efficienza. Perché è importante Distingue le registrazioni manuali da quelle automatizzate, un elemento essenziale per misurare il livello di automazione e analizzare le differenze tra i processi. Dove reperirlo Disponibile nella tabella GL_JE_HEADERS, in genere in un campo denominato JE_SOURCE. Esempi ManualeDebitiAttivitàCrediti
	Reparto dell’utente UserDepartment	Il reparto o il team a cui appartiene l’utente che ha eseguito l’attività.
Descrizione Questo attributo fornisce il contesto organizzativo collegando un’attività a uno specifico reparto, come 'Finance', 'Accounting Operations' o 'Internal Audit'. Generalmente deriva dai dati anagrafici degli utenti. L’analisi per User Department aiuta a individuare i colli di bottiglia interfunzionali, confrontare le performance dei team e comprendere come l’esecuzione del processo vari all’interno dell’organizzazione. È utile per l’allocazione delle risorse e per iniziative di miglioramento mirate. Perché è importante Fornisce il contesto organizzativo, consentendo di analizzare le performance per team o reparto e di mettere in evidenza le inefficienze interfunzionali. Dove reperirlo In genere non è presente nelle tabelle delle transazioni. Deve essere ricavato collegando UserName a una tabella anagrafica degli utenti o ai dati del sistema HR. Esempi Contabilità generaleReporting finanziarioDebiti verso fornitori
	Utente UserName	L’utente che ha eseguito l’attività, ad esempio creando, approvando o contabilizzando la registrazione contabile.
Descrizione Questo attributo identifica lo specifico dipendente o utente di sistema responsabile dell’esecuzione di un’attività. È fondamentale per comprendere la distribuzione dei carichi di lavoro e le performance, nonché per individuare i colli di bottiglia individuali. Nell’analisi, UserName consente di filtrare i processi per utente, confrontare l’efficienza degli utenti e analizzare le cause di ritardi o errori. Supporta direttamente Dashboard come 'User Workload & Efficiency Across Teams' e KPI come il 'User Journal Bottleneck Index'. Perché è importante Attribuisce la responsabilità dei passaggi del processo, consentendo di analizzare il carico di lavoro degli utenti, le performance individuali e le esigenze formative. Dove reperirlo È presente in tabelle delle transazioni come GL_JE_HEADERS, ad esempio in CREATED_BY e LAST_UPDATED_BY, e nelle relative tabelle di audit trail. Esempi john.doesusan.smithautoprocess_user
	Contabilizzazione puntuale IsOnTimePosting	Un indicatore calcolato che assume valore true se la registrazione contabile è stata contabilizzata entro la data prevista o prima di essa.
Descrizione Questo attributo booleano viene derivato confrontando il timestamp dell’attività «Journal Entry Posted» con «Target Posting Date». Se la contabilizzazione avviene entro la data prevista o prima di essa, il valore è «true»; in caso contrario è «false». Questo attributo supporta direttamente il KPI «On-Time Journal Posting Rate», semplificandone il calcolo. Consente di filtrare e analizzare facilmente le registrazioni in ritardo per individuare le cause più frequenti, come specifiche categorie di registrazioni o determinati approvatori. Perché è importante Fornisce un esito binario chiaro sulle prestazioni di contabilizzazione, semplificando l’analisi dei tassi di puntualità e delle cause alla radice dei ritardi. Dove reperirlo Questo attributo viene calcolato dallo strumento di Process Mining. Richiede l’attributo «TargetPostingDate» e il timestamp dell’attività «Journal Entry Posted». Esempi truefalse
	Data prevista di contabilizzazione TargetPostingDate	La data prestabilita entro la quale si prevede che la registrazione contabile venga contabilizzata.
Descrizione Target Posting Date rappresenta la scadenza entro la quale una registrazione contabile deve essere contabilizzata nel Ledger generale, spesso determinata dagli accordi sul livello di servizio (SLA) o dai calendari di chiusura di fine mese. Funge da riferimento per la misurazione delle prestazioni. Questo attributo è essenziale per calcolare il KPI «On-Time Journal Posting Rate». Confrontando la data effettiva di contabilizzazione con quella prevista, il sistema può contrassegnare automaticamente le registrazioni come puntuali o in ritardo, fornendo una misura chiara del rispetto delle scadenze di processo. Perché è importante Definisce l’accordo sul livello di servizio o la scadenza per la contabilizzazione e consente di calcolare i KPI relativi alle prestazioni puntuali. Dove reperirlo Potrebbe non essere un campo standard. Potrebbe essere derivato da regole aziendali basate sulla data di creazione, sul periodo contabile o sulla categoria della registrazione contabile. Esempi 2023-10-312023-11-302024-01-05
	È una rilavorazione IsRework	Un indicatore calcolato che assume valore true se la registrazione contabile ha attraversato un ciclo di rifiuto e correzione.
Descrizione Questo attributo booleano viene calcolato per identificare i casi che hanno richiesto una rilavorazione. In genere assume il valore «true» per qualsiasi attività successiva all’evento «Journal Entry Rejected», come «Journal Corrected and Resubmitted». Is Rework è un attributo particolarmente utile per l’analisi, poiché consente di quantificare facilmente il volume e l’impatto dei cicli di rilavorazione. Supporta direttamente il KPI «Average Journal Rework Rate» e aiuta a confrontare il flusso e la durata dei casi rilavorati con quelli elaborati correttamente al primo tentativo. Perché è importante Segnala direttamente i casi che hanno attraversato cicli di rilavorazione inefficienti, rendendo semplice quantificare la frequenza e l’impatto dei problemi di processo. Dove reperirlo Non è disponibile nel sistema di origine. Viene calcolato all’interno dello strumento di Process Mining analizzando la sequenza delle attività per ciascun caso. Esempi truefalse
	Indicatore di storno ReversalIndicator	Un indicatore che segnala se la registrazione contabile costituisce lo storno di un’altra registrazione.
Descrizione Questo attributo booleano identifica le registrazioni contabili create per stornare una registrazione contabilizzata in precedenza. Gli storni rappresentano una tipologia specifica di registrazione contabile e seguono spesso un processo distinto, talvolta problematico. L’analisi di questo indicatore è fondamentale per supportare il Dashboard «Journal Reversal Process Performance». Consente di isolare i processi di storno per misurarne frequenza, cause e tempi di ciclo, aiutando a individuare i problemi sottostanti nelle registrazioni originali che hanno reso necessario lo storno. Perché è importante Aiuta a isolare e analizzare il processo di storno, spesso indicativo di errori o problemi nella transazione originale. Dove reperirlo Può trattarsi di un indicatore specifico nella tabella GL_JE_HEADERS, come ACCRUAL_REV_FLAG, oppure può essere identificato tramite collegamenti alla registrazione contabile originale oggetto di storno. Esempi truefalse
	Nome del Ledger LedgerName	Il nome del Ledger generale nel quale viene registrata la scrittura contabile.
Descrizione Ledger Name identifica il Ledger specifico al quale appartiene la registrazione contabile. Nelle organizzazioni con più entità giuridiche o requisiti di reporting possono essere presenti più Ledger, ad esempio un Ledger principale per la contabilità aziendale e Ledger secondari per il reporting civilistico locale. Questo attributo è essenziale per filtrare e confrontare i processi tra diverse entità giuridiche o unità aziendali. Garantisce che le analisi vengano condotte nel corretto contesto organizzativo, aspetto particolarmente importante per la Conformità e il reporting finanziario. Perché è importante Consente di filtrare e confrontare l’analisi dei processi tra diverse entità giuridiche o strutture contabili, un requisito fondamentale per le organizzazioni di grandi dimensioni. Dove reperirlo Presente nella tabella GL_JE_HEADERS, in genere collegato tramite LEDGER_ID, che può essere unito a GL_LEDGERS per ottenere il nome. Esempi Libro mastro principale USALibro mastro civilistico del Regno UnitoLibro mastro per il consolidamento globale
	Ora di fine EndTime	Il timestamp che indica quando è stata completata una specifica attività.
Descrizione L’End Time indica il completamento di un’attività. Mentre lo Start Time registra l’inizio, l’End Time fornisce il punto di chiusura e consente di calcolare con precisione il tempo di elaborazione di quello specifico passaggio. È essenziale per calcolare i tempi di elaborazione delle attività, una metrica centrale per individuare i colli di bottiglia e misurare l’efficienza delle risorse. Ad esempio, la differenza tra l’End Time e lo Start Time dell’attività 'Journal Entry Reviewed' indica il tempo effettivo impiegato da un revisore per completare il Task. Perché è importante Consente di calcolare la durata effettiva o il tempo di elaborazione delle singole attività, un elemento fondamentale per individuare i problemi di efficienza. Dove reperirlo Come lo Start Time, si trova spesso nelle tabelle di audit trail oppure può essere dedotto dallo Start Time dell’attività successiva nel processo. Esempi 2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
	Periodo contabile AccountingPeriod	Il periodo fiscale al quale viene contabilizzata la registrazione contabile, ad esempio «Jan-24».
Descrizione Accounting Period specifica il periodo finanziario nel quale la transazione viene rilevata. È un’informazione fondamentale per ogni attività di reporting e analisi finanziaria. Nel Process Mining, questo attributo è essenziale per l’analisi dei trend. Consente di confrontare le prestazioni del processo, come i tempi di ciclo o i tassi di rifiuto, tra mesi o trimestri diversi. Aiuta inoltre a individuare gli effetti della stagionalità, come l’aumento del carico di lavoro durante la chiusura di fine mese, e a misurare nel tempo l’impatto dei miglioramenti apportati al processo. Perché è importante Consente di analizzare l’andamento dei KPI nel tempo, aiutando a misurare i miglioramenti del processo e a individuare schemi stagionali, come le pressioni legate alla chiusura di fine mese. Dove reperirlo Disponibile nella tabella GL_JE_HEADERS, in genere in un campo denominato PERIOD_NAME. Esempi Gen-24Feb-24Mar-24
	Stato di contabilizzazione PostingStatus	Lo stato corrente di contabilizzazione della registrazione contabile, ad esempio «Unposted» o «Posted».
Descrizione Questo attributo riflette lo stato corrente della registrazione contabile rispetto alla sua contabilizzazione nel Ledger generale. È un indicatore fondamentale della posizione della registrazione nel relativo ciclo di vita, soprattutto per i casi ancora in corso. Posting Status è essenziale per il Dashboard «Real-Time Journal Entry Status Tracker», che offre una panoramica di tutte le registrazioni attive. Consente di monitorare gli arretrati delle registrazioni non contabilizzate e di individuare i ritardi nelle fasi finali del processo. Perché è importante Indica lo stato corrente di una registrazione contabile, un’informazione essenziale per monitorare gli arretrati e seguire lo stato delle registrazioni in corso. Dove reperirlo Disponibile nella tabella GL_JE_HEADERS, in genere in una colonna come STATUS o POSTING_STATUS. Esempi RegistratoNon registratoErrore
	Tempo di ciclo end-to-end EndToEndCycleTime	La durata complessiva calcolata dalla creazione della registrazione contabile fino alla sua riconciliazione finale.
Descrizione Questa metrica rappresenta il tempo totale che una registrazione contabile trascorre nell’intero processo, dal primo evento 'Registrazione contabile creata' fino all’evento finale 'Registrazione contabile riconciliata'. Offre una visione complessiva delle prestazioni del processo. Si tratta di un KPI principale per misurare l’efficienza complessiva del processo. Viene utilizzata nelle Dashboard delle tendenze per monitorare nel tempo l’impatto delle iniziative di miglioramento e fornisce una base di riferimento rispetto alla quale misurare tutte le modifiche al processo. Perché è importante Fornisce una misura di alto livello dello stato e dell’efficienza dell’intero processo, risultando quindi una metrica fondamentale per il reporting direzionale. Dove reperirlo Questa metrica viene calcolata dalla piattaforma di Process Mining come differenza temporale tra i timestamp del primo e dell’ultimo evento di ciascun caso. Esempi P10DT5HP4DT12HP22D
	Valuta CurrencyCode	Il codice valuta dell’importo della registrazione contabile, ad esempio USD, EUR o GBP.
Descrizione Currency Code specifica la valuta degli importi finanziari presenti nella registrazione contabile. È un’informazione essenziale per le organizzazioni multinazionali che effettuano transazioni in più valute. Questo attributo garantisce la corretta interpretazione dei valori finanziari. Consente di filtrare i dati per valuta ed è necessario per qualsiasi analisi che preveda il confronto o l’aggregazione di importi monetari tra regioni diverse. Perché è importante Fornisce il contesto necessario per interpretare correttamente gli importi finanziari e consente di effettuare analisi specifiche per valuta. Dove reperirlo Disponibile nella tabella GL_JE_HEADERS, in genere in un campo denominato CURRENCY_CODE. Esempi USDEURGBPJPY

Obbligatorio Consigliato Facoltativo

Record to Report - Attività della registrazione contabile

Queste sono le fasi chiave e le principali tappe del processo da acquisire nell’Event Log per una corretta individuazione del processo di registrazione contabile.

5 Consigliato 7 Facoltativo

	Attività	Descrizione
	Journal Entry approvata	L’approvatore designato ha approvato formalmente la registrazione contabile, confermandone accuratezza e validità. È il passaggio finale del Workflow di approvazione e consente di procedere alla contabilizzazione.
Perché è importante Questa tappa segna la conclusione del processo di approvazione. Il tempo tra invio e approvazione è un KPI fondamentale per misurare l’efficienza del Workflow e individuare i colli di bottiglia nelle approvazioni. Dove reperirlo Questo evento viene dedotto da una modifica di stato nella tabella GL_JE_HEADERS, dove APPROVAL_STATUS_CODE viene aggiornato a 'APPROVED'. Le tabelle del Workflow contengono l’identità dell’approvatore e il timestamp. Acquisizione Monitori il timestamp in cui APPROVAL_STATUS_CODE in GL_JE_HEADERS cambia in 'APPROVED'. Tipo di evento inferred
	Journal Entry contabilizzata	I dati finanziari della registrazione contabile sono stati registrati correttamente nel General Ledger. Gli addebiti e gli accrediti sono ora riflessi nei saldi dei conti.
Perché è importante Questa è una tappa fondamentale, che rappresenta l’ingresso della registrazione nei dati finanziari ufficiali. È essenziale per misurare il tasso di contabilizzazione puntuale e il tempo totale dalla creazione alla contabilizzazione. Dove reperirlo Viene dedotta da una modifica di stato nella tabella GL_JE_HEADERS, dove il campo STATUS cambia in 'P' (Posted). Anche la tabella GL_JE_BATCHES contiene uno stato di contabilizzazione. Acquisizione Monitori il timestamp in cui STATUS in GL_JE_HEADERS cambia in 'P'. Tipo di evento inferred
	Journal Entry creata	Questa attività segna l’avvio del processo di Journal Entry. Rappresenta il momento in cui un utente crea una nuova testata della registrazione e inizia a inserire i dati, prima dell’invio per qualsiasi revisione o approvazione.
Perché è importante Si tratta dell’evento iniziale principale del processo. Analizzare il tempo che intercorre tra questa attività e i passaggi successivi aiuta a misurare l’efficienza dell’inserimento iniziale dei dati e la durata complessiva del ciclo di processo. Dove reperirlo Questo evento viene generalmente dedotto dal timestamp della data di creazione nella tabella GL_JE_HEADERS per uno specifico Journal Entry ID. In questa tabella è disponibile anche l’utente che ha creato il record. Acquisizione Utilizzi CREATION_DATE dalla tabella GL_JE_HEADERS. Tipo di evento inferred
	Journal Entry inviata per l’approvazione	Questa attività si verifica quando l’utente invia formalmente la registrazione contabile completata al Workflow di approvazione. La registrazione passa dallo stato di bozza o incompleto a quello di approvazione in sospeso.
Perché è importante Si tratta di una tappa fondamentale, che avvia il conteggio dei tempi del ciclo di approvazione e consente di individuare i colli di bottiglia. Separa la fase di inserimento dei dati da quella di revisione e approvazione. Dove reperirlo Questo evento viene dedotto da una modifica di stato nella tabella GL_JE_HEADERS, in particolare quando APPROVAL_STATUS_CODE cambia in un valore come 'REQUIRED' o 'INITIATED'. Potrebbe essere registrato anche il timestamp della data di invio. Acquisizione Monitori il timestamp in cui APPROVAL_STATUS_CODE in GL_JE_HEADERS cambia per indicare l’invio. Tipo di evento inferred
	Journal Entry riconciliata	La registrazione contabile è stata abbinata e chiusa durante il processo di riconciliazione dei conti di fine periodo. Ciò conferma che la transazione è coerente con altri dati finanziari, come gli estratti conto bancari.
Perché è importante Questa attività rappresenta il vero punto finale del ciclo di vita della registrazione. Misurare il tempo dalla contabilizzazione alla riconciliazione è un KPI fondamentale per valutare l’efficienza del processo di chiusura finanziaria. Dove reperirlo Questo evento viene generalmente acquisito in Oracle Financial Consolidation and Close Cloud Service (FCCS) o Account Reconciliation Cloud Service (ARCS), non nel General Ledger. Viene dedotto da una modifica di stato del record di riconciliazione collegato alla registrazione. Acquisizione Metta in correlazione i dati della registrazione con gli aggiornamenti dello stato di riconciliazione provenienti dalle tabelle ARCS o FCCS. Tipo di evento inferred
	Contabilizzazione della Journal Entry avviata	È stato avviato il processo di contabilizzazione della registrazione approvata nel General Ledger. Può trattarsi di un passaggio automatico o manuale, che accoda la registrazione per l’elaborazione da parte del programma di contabilizzazione.
Perché è importante Questa attività separa l’approvazione dal processo tecnico di contabilizzazione. I ritardi tra approvazione e avvio della contabilizzazione possono indicare problemi di pianificazione o vincoli di risorse nel motore di contabilizzazione. Dove reperirlo Può essere dedotta dalle modifiche di stato nella tabella GL_JE_BATCHES oppure dall’orario di invio della richiesta concorrente di contabilizzazione associata al batch della registrazione. Acquisizione Individui l’orario di invio della richiesta per il programma General Ledger Posting relativo allo specifico batch di registrazioni. Tipo di evento inferred
	Contabilizzazione verificata	Un passaggio di verifica successivo alla contabilizzazione, durante il quale un utente o il sistema conferma che la registrazione è stata contabilizzata correttamente e che i saldi sono quelli attesi. Spesso si tratta di un controllo manuale.
Perché è importante Analizzare questa attività aiuta a comprendere il tempo dedicato ai controlli manuali e alla garanzia della qualità dopo la contabilizzazione. Può mettere in evidenza opportunità per automatizzare i processi di verifica. Dove reperirlo È improbabile che si tratti di un evento esplicito in Oracle Fusion. Dovrebbe essere dedotto da altre azioni, come l’esecuzione di un report specifico da parte di un utente o l’aggiornamento di un campo di stato personalizzato, che non è standard. Acquisizione Richiede una logica personalizzata, come il monitoraggio dell’orario di esecuzione dei report di verifica o degli aggiornamenti a un descriptive flexfield. Tipo di evento inferred
	Documentazione di supporto allegata	Rappresenta l’azione di allegare documenti di supporto, come fatture o fogli di calcolo, alla registrazione contabile. Questa operazione viene spesso eseguita per fornire contesto e prove ad auditor e approvatori.
Perché è importante Monitorare questa attività aiuta a capire se i ritardi sono causati dalla documentazione mancante. Offre inoltre insight sulla conformità e sulla completezza delle registrazioni contabili prima che entrino nel Workflow di approvazione. Dove reperirlo Può essere difficile monitorarla come evento distinto. Potrebbe essere dedotta dai timestamp presenti in tabelle degli allegati come FND_ATTACHED_DOCUMENTS, collegate al record della registrazione nella tabella GL_JE_HEADERS. Acquisizione La deduca dalla data di creazione dei record in FND_ATTACHED_DOCUMENTS collegati alla registrazione contabile. Tipo di evento inferred
	Journal corretta e inviata nuovamente	Dopo il rifiuto di una registrazione contabile, il creatore apporta le correzioni necessarie e la invia nuovamente per l’approvazione. Questa attività rappresenta l’avvio di un nuovo ciclo di approvazione per la stessa registrazione.
Perché è importante Monitorare la rilavorazione è essenziale per comprendere l’inefficienza del processo. Questa attività, insieme a 'Journal Entry Rejected', consente di misurare il tempo e la frequenza delle rilavorazioni. Dove reperirlo Si tratta di un evento successivo di 'Journal Submitted For Approval' relativo a una registrazione che in precedenza si trovava nello stato 'REJECTED'. Viene identificato analizzando la sequenza delle modifiche di stato per uno specifico Journal Entry ID. Acquisizione Individui un timestamp di invio che si verifica dopo un evento di rifiuto per lo stesso case ID. Tipo di evento inferred
	Journal Entry revisionata	Un passaggio di revisione che può verificarsi prima o come parte del processo formale di approvazione. Rappresenta un controllo eseguito da un collega o da un responsabile per verificare accuratezza e conformità prima del passaggio all’approvatore finale.
Perché è importante Isolare questa attività aiuta a distinguere i tempi della revisione preliminare da quelli dell’approvazione finale. Può far emergere colli di bottiglia nascosti se la fase di revisione è informale ma richiede molto tempo. Dove reperirlo Può trattarsi di un passaggio esplicito in un Workflow di approvazione a più livelli, registrato nelle tabelle della cronologia del Workflow. Se informale, non viene acquisito. Può essere dedotto se un’azione specifica dell’utente viene registrata prima della decisione di approvazione finale. Acquisizione Analizzi le tabelle della cronologia del Workflow per individuare i passaggi intermedi di approvazione o revisione prima dello stato finale 'Approved'. Tipo di evento inferred
	Journal Entry rifiutata	Un approvatore ha esaminato la registrazione contabile e l’ha rifiutata a causa di errori, documentazione insufficiente o violazioni delle policy. L’azione rimanda la registrazione al creatore per la correzione.
Perché è importante Questa attività è fondamentale per analizzare i cicli di rilavorazione, i tassi di rifiuto e le metriche first-time-right. Un’elevata frequenza di rifiuti indica problemi nella qualità dei dati o nella formazione. Dove reperirlo Viene dedotta da una modifica di stato nella tabella GL_JE_HEADERS, quando APPROVAL_STATUS_CODE viene aggiornato a 'REJECTED'. La cronologia del Workflow registra l’utente e il timestamp di questa azione. Acquisizione Monitori il timestamp in cui APPROVAL_STATUS_CODE in GL_JE_HEADERS viene impostato su 'REJECTED'. Tipo di evento inferred
	Processo di storno della Journal Entry elaborato	È stata creata e contabilizzata una registrazione contabile di storno per annullare l’impatto finanziario della registrazione originale in un periodo successivo. Si tratta di un’operazione comune per gli accantonamenti.
Perché è importante Monitorare gli storni aiuta a individuare i tipi di registrazioni che vengono stornati più frequentemente e ad analizzare l’efficienza del processo di storno. Ciò può indicare problemi nella gestione degli accantonamenti. Dove reperirlo Viene dedotta individuando una nuova registrazione contabile esplicitamente collegata all’originale come relativo storno. La tabella GL_JE_HEADERS contiene campi come REVERSAL_PERIOD e REVERSAL_FLAG per identificare e collegare queste registrazioni. Acquisizione Individui la data di creazione e di contabilizzazione della nuova registrazione la cui testata fa riferimento alla registrazione originale come oggetto di storno. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Oracle Fusion Financials

Passaggi

Acceda all’area di lavoro Reports and Analytics: acceda a Oracle Fusion Financials. Utilizzi il menu Navigator per aprire Tools, quindi selezioni Reports and Analytics. Questo è il punto centrale per creare e gestire tutte le analisi e i report.
Crei un Data Model BI Publisher: invece di iniziare da un’analisi OTBI, per questo tipo di estrazione dell’Event Log è più efficace creare direttamente un Data Model BI Publisher. In questo modo potrà utilizzare una query SQL personalizzata con istruzioni UNION ALL. Faccia clic sul pulsante 'Browse Catalog', apra una cartella appropriata e selezioni Create > Data Model.
Definisca il dataset della query SQL: nell’editor del Data Model, faccia clic sull’icona '+' per aggiungere un nuovo Data Set e selezioni 'SQL Query'. Assegni al dataset un nome descrittivo, ad esempio 'JournalEventLog'.
Inserisca la query SQL: selezioni 'Oracle BI EE' come Data Source. Copi lo script SQL completo dalla sezione Query riportata di seguito e lo incolli nell’area di testo SQL Query. La query è progettata per acquisire tutte le attività e gli Attributi richiesti in un’unica struttura coerente.
Definisca i parametri: la query fornita utilizza parametri come :start_date, :end_date e :ledger_name. L’interfaccia del Data Model li rileverà automaticamente. Dovrà configurarli come parametri, impostando tipi di dati appropriati, Date o Text, e valori predefiniti, se necessari. In questo modo l’esecuzione del report sarà più flessibile.
Crei un report dal Data Model: dopo aver salvato il Data Model, torni al catalogo. Faccia clic su Create > Report. Nella procedura guidata di creazione del report, selezioni 'Use Existing Data Model' e individui il Data Model appena creato.
Configuri il layout del report: nell’editor del layout, scelga il layout 'Table'. È fondamentale trascinare nella tabella tutte le colonne del Data Model, così da includerle nell’esportazione. Non sono necessarie formattazioni complesse.
Imposti CSV come formato di output predefinito: nell’editor del report, apra il collegamento 'View a List'. Nella sezione 'Output Formats', verifichi che sia selezionato 'CSV'. È consigliabile deselezionare tutti gli altri formati per semplificare la pianificazione. Salvi il report.
Pianifichi l’esecuzione automatica del report: individui il report salvato nel catalogo e faccia clic su 'More', quindi su 'Schedule'. Crei un nuovo job pianificato e configuri la frequenza, ad esempio giornaliera o settimanale.
Configuri l’esportazione e la distribuzione: nella scheda 'Output' del job pianificato, specifichi i dettagli dell’output. Selezioni il report e scelga 'CSV' come formato. Nella scheda 'Destination' potrà configurare la distribuzione del file verso una posizione del content server (UCM) o un server SFTP esterno, per il recupero automatico.
Recuperi e prepari i dati: una volta eseguito il job pianificato, recuperi il file CSV generato dalla destinazione configurata. Verifichi che le intestazioni delle colonne corrispondano ai requisiti per l’acquisizione in ProcessMind: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, ecc. Il file è ora pronto per il caricamento.

Configurazione

Origine dei dati: La query deve essere eseguita sull’origine dei dati 'Oracle BI EE' all’interno di BI Publisher, che si connette alle viste del database transazionale sottostante utilizzate da OTBI.
Principali aree tematiche, come riferimento: La logica della query si basa principalmente sui dati presenti nell’area tematica 'General Ledger - Journals Real Time'. Esegue inoltre un join logico con i dati che si troverebbero nell’area 'HCM - Workforce Management - Worker Assignment Real Time' per i dettagli degli utenti e, potenzialmente, con le aree tematiche dei flussi di lavoro per la cronologia delle approvazioni.
Filtro dell’intervallo di date: È fondamentale filtrare i dati in modo da gestire un periodo ragionevole. La query include i parametri :start_date e :end_date. Per un’analisi iniziale, consigliamo di estrarre da 3 a 6 mesi di dati. Il filtro viene applicato alla data di creazione della registrazione contabile.
Filtro del libro contabile: Utilizzi il parametro :ledger_name per limitare l’estrazione a uno specifico libro contabile principale. L’estrazione simultanea di tutti i libri contabili può generare file estremamente voluminosi e problemi di prestazioni.
Prerequisiti: L’utente che crea e pianifica il report deve disporre di ruoli BI appropriati, come 'BI Administrator' o 'BI Author'. Inoltre, il profilo di sicurezza dei dati dell’utente deve consentire l’accesso ai libri contabili e alle unità aziendali specifici oggetto della query.
Pianificazione: Per ottenere prestazioni ottimali ed evitare di influire sugli utenti del sistema, pianifichi l’esecuzione del job di estrazione nelle ore di minor utilizzo, ad esempio durante la notte.

a Query di esempio sql

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Passaggi

Acceda a BI Publisher: acceda a Oracle Fusion Financials. Utilizzi il menu Navigator per aprire Tools, quindi selezioni Reports and Analytics. Si aprirà il catalogo Business Intelligence.
Crei un nuovo Data Model: nel catalogo BI, faccia clic sul pulsante Create e selezioni Data Model. Si aprirà l’editor del Data Model.
Definisca il dataset della query SQL: nell’editor del Data Model, faccia clic sull’icona più nella scheda Diagram e selezioni SQL Query. Nella nuova finestra di dialogo, assegni al dataset un nome, ad esempio ProcessMind_JE_EventLog. Selezioni la Data Source appropriata, generalmente FUSIONDB. Incolli la query SQL completa nell’area di testo SQL Query.
Definisca i parametri: la query utilizza parametri per l’intervallo di date (p_start_date e p_end_date). Oracle BI Publisher li rileverà automaticamente. Li configuri come parametri di tipo Text e assegni etichette intuitive, come 'Start Date (YYYY-MM-DD)' e 'End Date (YYYY-MM-DD)'.
Salvi il Data Model: dopo aver incollato la query e definito i parametri, faccia clic su OK e salvi il Data Model in una cartella appropriata, ad esempio Shared Folders/Custom/ProcessMining.
Crei il report: faccia clic sul pulsante Create Report nell’angolo superiore destro dell’editor del Data Model. Si avvierà la procedura guidata per la creazione del report.
Configuri il layout del report: nella procedura guidata, selezioni l’opzione per utilizzare il Data Model corrente. Scelga il layout 'Table'. Trascini tutte le colonne della Data Source nell’area del layout della tabella. Deselezioni l’opzione 'Show Grand Totals Row'.
Salvi il report: salvi il report nella stessa cartella del Data Model. Gli assegni un nome descrittivo, ad esempio 'Journal Entry Event Log Report'.
Imposti il formato di output predefinito: modifichi il report e apra la scheda 'Viewing'. In 'Output Formats', verifichi che sia selezionato CSV e, preferibilmente, lo imposti come formato predefinito. In questo modo l’output sarà direttamente compatibile.
Esegua ed esporti: apra il report; Le verrà richiesto di inserire i parametri relativi alla data iniziale e finale. Inserisca l’intervallo desiderato e faccia clic su Apply. Al termine dell’esecuzione, faccia clic sul pulsante Export e scelga il formato CSV per scaricare il file dell’Event Log.
Prepari il caricamento: apra il file CSV scaricato. Verifichi che le intestazioni delle colonne corrispondano ai nomi degli Attributi previsti (JournalEntryId, ActivityName, EventTime, ecc.) e che i dati siano formattati correttamente prima di caricarli sulla piattaforma ProcessMind.

Configurazione

Prerequisiti: L’utente che esegue il report deve disporre di un ruolo con i privilegi di sicurezza dei dati necessari per accedere ai dati del General Ledger, come General Accountant o un ruolo BI personalizzato. È inoltre necessario poter accedere allo strumento BI Publisher.
Origine dei dati: Il modello dati di BI Publisher deve essere configurato per utilizzare la connessione al database applicativo FUSIONDB.
Parametri dell’intervallo di date: La query è progettata con i parametri p_start_date e p_end_date per controllare la finestra di estrazione dei dati. È consigliabile iniziare con un periodo compreso tra 3 e 6 mesi di dati, così da garantire prestazioni adeguate.
Filtri del report: Per le organizzazioni di grandi dimensioni, è fortemente consigliato aggiungere i filtri direttamente nella clausola WHERE dell’espressione di tabella comune JournalHeaders della query. Il filtraggio per LEDGER_ID o LEGAL_ENTITY_ID è essenziale per gestire il volume dei dati.
Considerazioni sulle prestazioni: L’esecuzione di questa query su un database di produzione di grandi dimensioni può consumare risorse significative. Pianifichi l’esecuzione del report nelle ore di minor utilizzo per ridurre al minimo l’impatto sulle prestazioni del sistema.
Formato dell’output: Il report deve essere configurato per produrre un file CSV. Questo formato strutturato e ordinato facilita l’acquisizione dei dati negli strumenti di Process Mining.

a Query di esempio 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"

Passaggi

Prerequisiti: verifichi di avere Python 3 installato insieme alle librerie requests e pandas. Le servirà un account utente Oracle Fusion Financials con le autorizzazioni necessarie per accedere alla REST API General Ledger Journals. Recuperi l’URL dell’istanza Oracle Fusion, il nome utente e la password.
Configurazione dello script: crei un nuovo file di script Python. Inizi importando le librerie necessarie: requests, json, pandas e datetime.
Configurazione: nello script, definisca le variabili per le credenziali Oracle Fusion e l’URL di base. Imposti inoltre i parametri per l’estrazione dei dati, come le date iniziale e finale della query.
Autenticazione: lo script utilizza l’autenticazione Basic. La libreria requests gestisce la codifica del nome utente e della password nelle intestazioni della richiesta.
Definizione della funzione per le chiamate API: crei una funzione per gestire le richieste API. La funzione deve gestire la paginazione utilizzando i parametri offset e limit. Eseguirà chiamate API successive finché non saranno stati recuperati tutti i record dei journal compresi nell’intervallo di date specificato.
Costruzione della query API: utilizzi il parametro q nella richiesta API per filtrare i journal in base a LastUpdateDate. In questo modo potrà estrarre dati relativi a un intervallo specifico, ad esempio LastUpdateDate between '2023-01-01' and '2023-03-31'.
Avvio del recupero dei dati: richiami la funzione per iniziare il recupero dei dati dall’endpoint .../fscmRestApi/resources/11.13.18.05/journals. La funzione restituirà l’elenco completo delle registrazioni.
Elaborazione e trasformazione dei dati: analizzi ogni registrazione restituita dall’API. Per ciascun journal, generi più righe di evento corrispondenti alle diverse attività aziendali (Journal Entry Created, Journal Entry Approved, ecc.). Utilizzi i campi data e i codici di stato della risposta API (CreationDate, PostedDate, ApprovalStatus, ecc.) per creare questi eventi distinti.
Strutturazione dell’Event Log: man mano che genera ogni riga di evento, la memorizzi come dizionario in un elenco. Questo elenco costituirà i dati grezzi dell’Event Log.
Creazione del DataFrame: dopo aver elaborato tutti i journal, converta l’elenco dei dizionari di eventi in un DataFrame Pandas, così da poterlo manipolare più facilmente.
Definizione finale delle colonne: selezioni e rinomini le colonne del DataFrame affinché corrispondano allo schema richiesto da ProcessMind: JournalEntryId, ActivityName, EventTime, UserName, ecc.
Esportazione in CSV: salvi il DataFrame finale in un file CSV. Potrà quindi caricare direttamente questo file in ProcessMind per l’analisi.

Configurazione

Credenziali: per l’autenticazione Basic sono necessari un nome utente e una password Oracle Fusion validi.
URL dell’istanza: è necessario l’URL di base dell’istanza Oracle Fusion Financials per costruire l’endpoint API, ad esempio https://[your-instance].fa.us2.oraclecloud.com.
Endpoint API: lo script utilizza l’endpoint fscmRestApi/resources/11.13.18.05/journals per recuperare i dati del General Ledger.
Filtro dell’intervallo di date: lo script deve essere configurato con start_date e end_date per limitare l’ambito dell’estrazione. Per un’analisi iniziale, è consigliato un periodo compreso tra 3 e 6 mesi. Per l’utilizzo continuativo, configuri caricamenti incrementali giornalieri o settimanali.
Limite della paginazione: il parametro limit controlla il numero di record recuperati per ogni chiamata API. In genere, un valore compreso tra 200 e 500 offre un buon equilibrio tra il numero di chiamate API e la dimensione di ciascuna risposta.
Ruoli Oracle richiesti: l’account utente deve disporre di un ruolo con i privilegi necessari per leggere i dati dei journal tramite REST API, ad esempio General Accountant o un ruolo personalizzato con autorizzazioni equivalenti.

a Query di esempio 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.")

Passaggi

Verifichi che BI Cloud Connector, le aree tematiche General Ledger di Oracle Fusion Financials o i Public View Objects richiesti e le autorizzazioni necessarie del sistema sorgente siano disponibili nel Suo ambiente. Verifichi con l’amministratore Oracle la destinazione BICC configurata e le relative credenziali di accesso.
Nella console BI Cloud Connector, individui i Public View Objects che contengono intestazioni e righe dei journal, cronologia delle approvazioni, allegati, stato di contabilizzazione, stato di riconciliazione e informazioni sugli storni. Annoti i nomi esatti degli oggetti e degli Attributi configurati nel Suo ambiente. Prima dell’esecuzione, sostituisca i segnaposto nello script di estrazione con tali nomi.
Configuri un job BICC per i Public View Objects General Ledger selezionati. Utilizzi un’estrazione incrementale quando è disponibile un Attributo affidabile relativo all’ultimo aggiornamento. Per il caricamento iniziale, utilizzi un periodo controllato di tre-sei mesi o un altro intervallo contabile approvato.
Configuri BICC affinché distribuisca i file estratti nella posizione di cloud storage designata. Verifichi formato del file, delimitatore, codifica dei caratteri, compressione, partizionamento, convenzione di denominazione e pianificazione della distribuzione. Conservi il watermark dell’estrazione o il timestamp dell’ultima estrazione completata correttamente.
Recuperi i file distribuiti nell’area di staging approvata. Carichi ogni file sorgente nella tabella o vista di staging corrispondente. Utilizzi le mappature esatte degli oggetti e degli Attributi sorgente documentate per il Suo ambiente. Non presuma che un Public View Object abbia la stessa struttura di una tabella del database sottostante.
Normalizzi i timestamp in un unico fuso orario e converta i timestamp sorgente in un tipo di dato timestamp coerente. Conservi il timestamp di aggiornamento sorgente come LastDataUpdate. Converta gli identificativi sorgente e gli Attributi delle attività nei nomi di output utilizzati da ProcessMind.
Esegua la query riportata di seguito dopo aver sostituito ogni segnaposto con i nomi effettivi degli oggetti e degli Attributi di staging. La query crea esplicitamente una riga dell’Event Log per ciascuna delle 12 attività richieste. Non deduce attività assenti nei dati sorgente.
Verifichi che JournalEntryId, ActivityName, EventTime, SourceSystem e LastDataUpdate siano presenti in ogni riga di output. Esamini gli eventi duplicati, l’ordine dei timestamp, i journal rifiutati e reinviati, le relazioni di storno e i record privi di Attributi facoltativi.
Esporti il risultato come file delimitato o in un altro formato supportato da ProcessMind. Includa i nomi esatti delle colonne JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount e RejectionReason. Carichi il file configurando JournalEntryId come identificativo del caso, ActivityName come attività ed EventTime come timestamp dell’evento.

Configurazione

Configuri BICC sui Public View Objects General Ledger necessari per intestazioni e righe dei journal, cronologia delle approvazioni o dei Workflow, allegati, contabilizzazione, riconciliazione e dati sugli storni. I nomi esatti degli oggetti e degli Attributi devono essere verificati nel catalogo BICC del Suo ambiente.
Utilizzi un periodo iniziale di estrazione compreso tra tre e sei mesi. Estenda il periodo solo dopo aver convalidato volume, capacità di archiviazione, durata dell’estrazione e tempi di elaborazione a valle.
Applichi filtri approvati per data contabile o data dell’ultimo aggiornamento, ledger, entità giuridica, business unit, codice società, se disponibile, categoria del journal, origine del journal, tipo di documento, se disponibile, e stato del journal. Utilizzi esclusivamente i filtri supportati dai Public View Objects selezionati.
Configuri l’estrazione incrementale utilizzando l’Attributo sorgente relativo all’ultimo aggiornamento e un watermark persistente. Quando necessario, includa una piccola finestra di sovrapposizione per gestire gli aggiornamenti arrivati in ritardo, quindi elimini i duplicati in base a JournalEntryId, ActivityName, EventTime e all’identificativo dell’evento sorgente pertinente.
Verifichi che tutti gli oggetti sorgente utilizzino chiavi di estrazione e pianificazioni di aggiornamento compatibili. I dati relativi ad approvazioni, allegati, contabilizzazione, riconciliazione e storni potrebbero essere aggiornati in momenti diversi.
Per dataset di grandi dimensioni, partizioni i dati per periodo contabile, ledger, entità giuridica o un altro Attributo di partizionamento supportato da BICC. Eviti estrazioni storiche senza restrizioni durante l’orario lavorativo.
Conservi i timestamp sorgente e i timestamp di aggiornamento sorgente prima della trasformazione. Documenti il fuso orario utilizzato per EventTime e LastDataUpdate.
I prerequisiti includono l’accesso alla console BI Cloud Connector, l’autorizzazione a configurare ed eseguire le estrazioni selezionate, l’accesso alla destinazione di cloud storage configurata, l’accesso all’ambiente di staging e l’autorizzazione a visualizzare i dati richiesti del General Ledger e dei Workflow.
Verifichi che i moduli Oracle Fusion Financials richiesti, la configurazione dei Workflow, l’archiviazione degli allegati, i processi di contabilizzazione e le Data Source di riconciliazione siano abilitati nei casi in cui tali attività siano previste.
Non consideri l’assenza di un record sorgente come prova del mancato svolgimento di un’attività. L’output BICC riflette i Public View Objects selezionati, i filtri, la tempistica di aggiornamento, la conservazione e la cronologia disponibile.

a Query di esempio sql

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

È pronto per iniziare?

Utilizzi questo Template per trasformare i dati di Oracle Fusion Journal Entry in informazioni operative concrete e accelerare il ciclo Record to Report. Inizi oggi il percorso verso operazioni finanziarie più efficienti.

Torna alla guida al miglioramento Scarica il Template

Acceleri oggi Record to Report - Journal Entry

Riduca del 30% i tempi del ciclo Journal Entry e semplifichi le operazioni finanziarie.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito: attivi subito la prova.

Il Suo Template dati per Record to Report - Journal Entry

Il Suo Template dati per Record to Report - Journal Entry

Record to Report - Attributi della registrazione contabile

Record to Report - Attività della registrazione contabile

Guide all’estrazione

Esportazione dei report Oracle OTBI e BI Publisher

Passaggi

Configurazione

a Query di esempio sql

Report BI Publisher con query diretta SQL del Data Model

Passaggi

Configurazione

a Query di esempio sql

Script Python che utilizza l’API REST di Oracle Fusion Financials

Passaggi

Configurazione

a Query di esempio python

Estrazione massiva dei dati tramite BI Cloud Connector (BICC)

Passaggi

Configurazione

a Query di esempio sql

È pronto per iniziare?

Acceleri oggi Record to Report - Journal Entry

Il Suo Template dati per Record to Report - Journal Entry

Il Suo Template dati per Record to Report - Journal Entry

Record to Report - Attributi della registrazione contabile

Record to Report - Attività della registrazione contabile

Guide all’estrazione

Esportazione dei report Oracle OTBI e BI Publisher

Passaggi

Configurazione

a Query di esempio sql

Report BI Publisher con query diretta SQL del Data Model

Passaggi

Configurazione

a Query di esempio sql

Script Python che utilizza l’API REST di Oracle Fusion Financials

Passaggi

Configurazione

a Query di esempio python

Estrazione massiva dei dati tramite BI Cloud Connector (BICC)

Passaggi

Configurazione

a Query di esempio sql

È pronto per iniziare?

Acceleri oggi Record to Report - Journal Entry

La Sua privacy è importante