> Miglioramento continuo dei processi > Record to Report Registrazione delle scritture contabili > Oracle Fusion Financials > Template dei dati

Il Suo template dei dati per Record to Report - Registrazione contabile

Oracle Fusion Financials

← Torna alla guida al miglioramento

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

Il Suo template dei dati per Record to Report - Registrazione contabile

Questo template dei dati fornisce indicazioni complete per estrarre e strutturare i dati delle registrazioni contabili di Oracle Fusion Financials. 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 i dati direttamente dal sistema.

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

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

Scarica il template

Attributi di Record to Report - Registrazione contabile

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il processo Record to Report - Registrazione contabile.

5 Obbligatorio 6 Consigliato 10 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Nome dello specifico evento aziendale o dell’attività che si è verificata in un determinato momento del processo di registrazione contabile.
Descrizione Il nome dell’attività descrive una singola fase del ciclo di vita della registrazione contabile, ad esempio «Journal Entry Created» o «Journal Entry Approved». Questi dati sono fondamentali per creare la mappa del processo e comprenderne la sequenza degli eventi. L’analisi delle attività permette di individuare il flusso di processo, inclusi i percorsi standard, le deviazioni e i cicli di rilavorazione. Monitorando le diverse attività, è possibile misurare il tempo impiegato nelle singole fasi, ad esempio nell’approvazione, e individuare quelle che richiedono più tempo o sono più soggette a errori. Perché è importante Definisce le fasi del processo, costituisce la struttura portante della mappa e permette di analizzare il flusso, i colli di bottiglia e le variazioni. Dove reperirli Questo attributo deriva in genere dalle variazioni di stato, dai log degli eventi o dalle tabelle di audit trail associate agli oggetti di registrazione contabile nel modulo General Ledger. Esempi Registrazione contabile creataRegistrazione contabile inviata per l’approvazioneRegistrazione contabile approvataRegistrazione contabile contabilizzata
	ID della registrazione contabile JournalEntryId	Identificativo univoco di una singola registrazione contabile, che collega tutte le attività relative alla transazione finanziaria.
Descrizione L’ID della registrazione contabile è l’identificativo univoco del caso e collega tutte le attività relative a uno specifico insieme di transazioni finanziarie. Consente di seguire l’intero ciclo di vita di una singola registrazione, dall’avvio alla contabilizzazione finale, verificando che tutti gli addebiti e gli accrediti siano inclusi. Nel Process Mining, questo ID è essenziale per ricostruire il percorso completo 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, permettendo di analizzare i tempi di ciclo, i colli di bottiglia e le variazioni del processo. Perché è importante È la chiave fondamentale per seguire una registrazione contabile dall’inizio alla fine e analizzare l’intero flusso di processo di ogni caso. Dove reperirli È una chiave primaria presente nelle tabelle principali del General Ledger, come GL_JE_HEADERS e GL_JE_LINES. Esempi JE100523JE202311001882019
	Ora di inizio EventTime	Data e ora che indicano quando si è verificata una specifica attività o un evento.
Descrizione Questa data e ora indicano il momento esatto in cui è stata eseguita un’attività. È il principale riferimento temporale utilizzato nel Process Mining per determinare la sequenza degli eventi e calcolare gli intervalli tra loro. La precisione dell’ora dell’evento è fondamentale per tutte le analisi temporali, dal calcolo dei tempi di ciclo all’individuazione dei colli di bottiglia, fino al monitoraggio delle prestazioni rispetto agli accordi sui livelli di servizio. Fornisce l’ordine cronologico necessario per ricostruire il flusso di processo così come si è svolto. Perché è importante Questa data e ora è essenziale per ordinare gli eventi, calcolare tutte le durate del processo ed eseguire qualsiasi analisi temporale. Dove reperirli Queste informazioni sono in genere memorizzate nelle tabelle di audit trail oppure, per eventi specifici, nei campi «Last Update Date» o «Creation Date» delle tabelle delle transazioni, come GL_JE_HEADERS e GL_JE_LINES. Esempi 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
	Sistema di origine SourceSystem	Sistema o modulo da cui provengono i dati.
Descrizione Questo attributo identifica il sistema di origine da cui sono stati estratti i dati del processo. In un’architettura IT complessa, i dati possono provenire da più sistemi integrati e questo campo permette di distinguerli. Nell’analisi dei processi, conoscere il sistema di origine è fondamentale per comprendere le variazioni dovute al diverso comportamento dei sistemi. Aiuta inoltre a convalidare i dati e a risolvere i problemi, risalendo alla loro origine. Perché è importante Identifica l’origine dei dati, un’informazione fondamentale per la governance e la convalida dei dati e per comprendere le variazioni del processo tra sistemi diversi. Dove reperirli Spesso si tratta di un valore statico configurato durante l’estrazione dei dati; in alternativa, può essere un campo delle tabelle di origine che identifica il sistema in cui è stata inserita la registrazione. Esempi Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento o dell’ultima estrazione dei dati dal sistema di origine.
Descrizione Questo attributo registra quando è stato aggiornato il set di dati per l’ultima volta. Indica quanto sono aggiornati i dati analizzati, un’informazione importante per valutarne la pertinenza. In qualsiasi analisi, soprattutto nelle Dashboard operative, conoscere l’ora dell’ultimo aggiornamento dei dati è fondamentale affinché gli utenti possano fidarsi dei dati e prendere decisioni informate. Indica chiaramente fino a quale momento sono inclusi i dati nel modello di Process Mining. Perché è importante Indica quanto sono aggiornati i dati, così che gli utenti possano capire a quale momento si riferisce l’analisi del processo e fidarsi dei risultati. Dove reperirli Questo valore viene generato e memorizzato durante l’estrazione e la trasformazione dei dati. In genere corrisponde alla data e ora di completamento del processo ETL/ELT. Esempi 2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
	Categoria della registrazione contabile JournalCategory	Categoria della registrazione contabile, ad esempio «Accantonamento», «Rettifica» o «Riclassificazione».
Descrizione La categoria della registrazione contabile classifica le registrazioni in base alla loro finalità aziendale. Questa classificazione consente un’analisi più dettagliata del processo, poiché categorie diverse possono seguire flussi di processo, regole di approvazione o tempi di ciclo differenti. Ad esempio, le registrazioni di rettifica di fine mese possono seguire un processo più complesso e urgente rispetto agli accantonamenti ordinari. L’analisi per categoria aiuta a individuare queste differenze e a definire interventi mirati per ciascun tipo di registrazione. Perché è importante Permette di segmentare il processo in base alla finalità aziendale della registrazione e di mettere in luce differenze nel comportamento e nelle prestazioni tra le varie tipologie. Dove reperirli Disponibile nella tabella GL_JE_HEADERS, in genere nel campo JE_CATEGORY. Esempi AccantonamentoManualeRettificaRivalutazione
	Importo della registrazione contabile JournalAmount	Valore monetario totale della registrazione contabile, in genere pari alla somma degli addebiti.
Descrizione Questo attributo rappresenta il valore finanziario totale della transazione registrata. L’importo può influire in modo significativo sul processo. Ad esempio, le registrazioni di importo elevato possono richiedere ulteriori fasi di approvazione o verifiche più approfondite. L’analisi dell’importo della registrazione contabile permette di segmentare i casi in base all’impatto finanziario e di rispondere a domande come «Le registrazioni di importo elevato richiedono più tempo per essere approvate?» o «I rifiuti sono più frequenti per le registrazioni che superano una determinata soglia?». In questo modo si aggiunge un contesto aziendale essenziale all’analisi del flusso di processo. Perché è importante Fornisce un contesto aziendale fondamentale per analizzare l’impatto finanziario e capire se le registrazioni di importo elevato seguono un processo diverso. Dove reperirli In genere, questo valore si calcola sommando gli addebiti o gli accrediti nella tabella GL_JE_LINES per una determinata registrazione contabile. Esempi 5000.00125000.75750.50
	Motivo del rifiuto RejectionReason	Descrizione testuale o 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 o di un commento in testo libero dell’approvatore. È uno degli attributi più importanti per individuare le cause profonde delle inefficienze del processo. Analizzando i motivi di rifiuto più frequenti, le organizzazioni possono individuare le aree da migliorare, ad esempio con una formazione più adeguata per chi prepara le registrazioni, indicazioni più chiare o controlli di sistema più efficaci. Supporta direttamente la Dashboard «Analisi del tasso di rifiuto delle registrazioni contabili». Perché è importante Fornisce indicazioni dirette sulle cause profonde delle rilavorazioni e dei ritardi del processo, consentendo interventi mirati per ridurre i rifiuti. Dove reperirli Queste informazioni possono essere memorizzate nelle tabelle del flusso di lavoro o di audit trail associate al processo di approvazione, oppure in un campo note dell’intestazione della registrazione. Esempi Combinazione di conti non correttaDocumentazione di supporto insufficienteSupera il budget
	Origine della registrazione contabile JournalSource	Libro ausiliario o origine che ha generato la registrazione contabile, ad esempio «Debiti verso fornitori», «Crediti verso clienti» o «Manuale».
Descrizione Questo attributo indica l’origine della registrazione contabile all’interno del sistema ERP. Le registrazioni possono essere create manualmente nel General Ledger oppure generate automaticamente da libri ausiliari, come quelli dei debiti verso fornitori, dei crediti verso clienti o delle immobilizzazioni. L’origine della registrazione è un attributo importante per analizzare l’automazione. Permette di distinguere le registrazioni manuali da quelle generate dal sistema e supporta il KPI «Percentuale di registrazioni contabili automatizzate». I processi relativi a registrazioni di origine diversa spesso variano sensibilmente per complessità ed efficienza. Perché è importante Distingue le registrazioni manuali da quelle automatizzate, un dato fondamentale per misurare i livelli di automazione e analizzare le differenze tra i processi. Dove reperirli Disponibile nella tabella GL_JE_HEADERS, in genere nel campo JE_SOURCE. Esempi ManualeDebiti verso fornitoriImmobilizzazioniCrediti verso clienti
	Reparto dell’utente UserDepartment	Reparto o team a cui appartiene l’utente che ha eseguito l’attività.
Descrizione Questo attributo fornisce il contesto organizzativo collegando un’attività a un reparto specifico, ad esempio «Finanza», «Operazioni contabili» o «Audit interno». In genere deriva dai dati anagrafici degli utenti. L’analisi per reparto dell’utente aiuta a individuare i colli di bottiglia tra reparti, confrontare le prestazioni dei team e capire come cambia l’esecuzione del processo all’interno dell’organizzazione. È utile per allocare le risorse e definire interventi mirati di miglioramento dei processi. Perché è importante Fornisce il contesto organizzativo per analizzare le prestazioni per team o reparto e mettere in luce le inefficienze tra funzioni. Dove reperirli In genere non è presente nelle tabelle delle transazioni. Occorre recuperarlo collegando UserName a una tabella anagrafica degli utenti o ai dati del sistema HR. Esempi Contabilità generaleRendicontazione finanziariaDebiti verso fornitori
	Utente UserName	Utente che ha eseguito l’attività, ad esempio creando, approvando o contabilizzando la registrazione.
Descrizione Questo attributo identifica il dipendente o l’utente di sistema responsabile dell’esecuzione di un’attività. È fondamentale per comprendere la distribuzione del carico di lavoro e le prestazioni e per individuare i colli di bottiglia legati alle singole persone. Nell’analisi, UserName permette di filtrare i processi per utente, confrontare l’efficienza e indagare le cause di ritardi o errori. Supporta direttamente Dashboard come «Carico di lavoro ed efficienza degli utenti nei team» e KPI come l’«Indice dei colli di bottiglia delle registrazioni per utente». Perché è importante Associa le fasi del processo ai responsabili, consentendo di analizzare il carico di lavoro degli utenti, le prestazioni individuali e le esigenze di formazione. Dove reperirli Si trova nelle tabelle delle transazioni, come GL_JE_HEADERS (ad esempio, CREATED_BY e LAST_UPDATED_BY), e nelle relative tabelle di audit trail. Esempi john.doesusan.smithautoprocess_user
	Contabilizzazione puntuale IsOnTimePosting	Indicatore calcolato, impostato su vero se la registrazione è stata contabilizzata entro la data prevista.
Descrizione Questo attributo booleano si ricava confrontando la data e ora dell’attività «Journal Entry Posted» con la «Target Posting Date». Se la contabilizzazione avviene entro la data prevista, il valore è «true»; altrimenti è «false». L’attributo supporta direttamente il KPI «Percentuale di contabilizzazioni puntuali» e ne semplifica il calcolo. Permette di filtrare e analizzare facilmente le registrazioni in ritardo per individuare le cause più frequenti, come specifiche categorie di registrazione o determinati approvatori. Perché è importante Fornisce un esito chiaro e binario sulle prestazioni di contabilizzazione, semplificando l’analisi della puntualità e delle cause profonde dei ritardi. Dove reperirli Questo attributo viene calcolato dallo strumento di Process Mining. Richiede l’attributo «TargetPostingDate» e la data e ora dell’attività «Journal Entry Posted». Esempi truefalse
	Data prevista di contabilizzazione TargetPostingDate	Data entro la quale si prevede di contabilizzare la registrazione contabile.
Descrizione La data prevista di contabilizzazione rappresenta la scadenza entro cui registrare la registrazione contabile nel General Ledger, spesso definita dagli accordi sui livelli di servizio (SLA) o dalle scadenze di chiusura di fine mese. Costituisce un valore di riferimento per misurare le prestazioni. Questo attributo è essenziale per calcolare il KPI «Percentuale di contabilizzazioni puntuali». Confrontando la data effettiva di contabilizzazione con quella prevista, il sistema può segnalare automaticamente le registrazioni puntuali o in ritardo e misurare con chiarezza il rispetto delle scadenze. Perché è importante Definisce il livello di servizio o la scadenza per la contabilizzazione e consente di calcolare i KPI relativi al rispetto dei tempi. Dove reperirli Potrebbe non essere un campo standard. Può essere ricavato da regole aziendali basate sulla data di creazione, sul periodo contabile o sulla categoria della registrazione. Esempi 2023-10-312023-11-302024-01-05
	È una rilavorazione IsRework	Indicatore calcolato, impostato su vero 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 è impostato su «true» per tutte le attività successive a un evento «Journal Entry Rejected», ad esempio «Journal Corrected and Resubmitted». L’indicatore di rilavorazione è utile per l’analisi perché permette di quantificare facilmente il volume e l’impatto dei cicli di rilavorazione. Supporta direttamente il KPI «Tasso medio di rilavorazione delle registrazioni contabili» 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, facilitando la quantificazione della frequenza e dell’impatto degli errori di processo. Dove reperirli Non è disponibile nel sistema di origine. Viene calcolato nello strumento di Process Mining analizzando la sequenza delle attività di ciascun caso. Esempi truefalse
	Indicatore di storno ReversalIndicator	Indicatore che specifica se la registrazione contabile stornata un’altra registrazione.
Descrizione Questo attributo booleano identifica le registrazioni contabili create per stornare una registrazione contabilizzata in precedenza. Gli storni costituiscono una tipologia specifica di registrazione e spesso seguono un processo distinto, talvolta problematico. L’analisi di questo indicatore è fondamentale per la Dashboard «Prestazioni del processo di storno delle registrazioni contabili». Permette di isolare i processi di storno e misurarne frequenza, cause e tempi di ciclo, aiutando a individuare i problemi alla base delle registrazioni originali che hanno reso necessario lo storno. Perché è importante Permette di isolare e analizzare il processo di storno, spesso indicativo di errori o problemi nella transazione originale. Dove reperirli Può trattarsi di un indicatore specifico nella tabella GL_JE_HEADERS, come ACCRUAL_REV_FLAG, oppure può essere individuato tramite i collegamenti alla registrazione originale stornata. Esempi truefalse
	Nome del libro mastro LedgerName	Nome del libro mastro in cui viene registrata la registrazione contabile.
Descrizione Il nome del libro mastro identifica quello a cui appartiene la registrazione contabile. Nelle organizzazioni con più entità giuridiche o requisiti di rendicontazione possono essere presenti diversi libri mastri, ad esempio un libro mastro principale per la contabilità aziendale e libri mastri secondari per la rendicontazione prevista dalle normative locali. Questo attributo è essenziale per filtrare e confrontare i processi tra entità giuridiche o unità aziendali diverse. Garantisce che le analisi siano condotte nel corretto contesto organizzativo, un aspetto particolarmente importante per la conformità e la rendicontazione finanziaria. Perché è importante Permette di filtrare e confrontare l’analisi dei processi tra entità giuridiche o principi contabili diversi, un’esigenza fondamentale per le grandi organizzazioni. Dove reperirli Si trova nella tabella GL_JE_HEADERS, in genere collegata tramite LEDGER_ID, che può essere associato a GL_LEDGERS per recuperare il nome. Esempi Libro mastro principale USALibro mastro statutario Regno UnitoLibro mastro di consolidamento globale
	Ora di fine EndTime	Data e ora che indicano quando è stata completata una specifica attività.
Descrizione L’ora di fine indica il completamento di un’attività. L’ora di inizio ne registra l’avvio, mentre quella di fine ne segna la conclusione e permette di calcolare con precisione il tempo di elaborazione della singola fase. È un dato essenziale per calcolare i tempi di elaborazione delle attività, una metrica fondamentale per individuare i colli di bottiglia e misurare l’efficienza nell’impiego delle risorse. Ad esempio, la differenza tra l’ora di fine e quella di inizio dell’attività «Journal Entry Reviewed» indica il tempo effettivamente dedicato dal revisore. Perché è importante Permette di calcolare la durata effettiva o il tempo di elaborazione delle singole attività, un dato fondamentale per individuare i problemi di efficienza. Dove reperirli Come l’ora di inizio, questo dato si trova spesso nelle tabelle di audit trail oppure si può dedurre dall’ora di inizio dell’attività successiva nel processo. Esempi 2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
	Periodo contabile AccountingPeriod	Periodo fiscale a cui viene attribuita la registrazione contabile, ad esempio «Gen-24».
Descrizione Il periodo contabile specifica il periodo finanziario in cui viene rilevata la transazione. È un dato fondamentale per tutta la rendicontazione e l’analisi finanziaria. Nel Process Mining, questo attributo è essenziale per l’analisi dell’andamento. Permette di confrontare le prestazioni del processo, ad esempio i tempi di ciclo o i tassi di rifiuto, tra mesi o trimestri diversi. Aiuta a individuare gli effetti stagionali, 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 Permette di analizzare l’andamento dei KPI nel tempo, misurare i miglioramenti del processo e individuare schemi stagionali, come i picchi di lavoro a fine mese. Dove reperirli Disponibile nella tabella GL_JE_HEADERS, in genere nel campo PERIOD_NAME. Esempi Gen-24Feb-24Mar-24
	Stato della contabilizzazione PostingStatus	Stato attuale della contabilizzazione della registrazione contabile, ad esempio «Non contabilizzata» o «Contabilizzata».
Descrizione Questo attributo indica lo stato attuale della registrazione contabile rispetto alla contabilizzazione nel General Ledger. È un indicatore importante della fase del ciclo di vita in cui si trova la registrazione, soprattutto per i casi ancora in corso. Lo stato della contabilizzazione è fondamentale per la Dashboard «Monitoraggio in tempo reale dello stato delle registrazioni contabili», che offre una panoramica di tutte le registrazioni attive. Aiuta a monitorare gli arretrati delle registrazioni non contabilizzate e a individuare i ritardi nelle fasi finali del processo. Perché è importante Indica lo stato attuale di una registrazione, un dato essenziale per monitorare gli arretrati e seguire le registrazioni ancora in corso. Dove reperirli Disponibile nella tabella GL_JE_HEADERS, in genere in una colonna denominata STATUS o POSTING_STATUS. Esempi ContabilizzataNon contabilizzataErrore
	Tempo di ciclo end-to-end EndToEndCycleTime	Durata totale calcolata dalla creazione della registrazione contabile alla sua riconciliazione finale.
Descrizione Questa metrica rappresenta il tempo totale trascorso dalla registrazione contabile nell’intero processo, dal primo evento «Journal Entry Created» all’evento finale «Journal Entry Reconciled». Offre una visione complessiva delle prestazioni del processo. È un KPI fondamentale per misurare l’efficienza complessiva del processo. Viene utilizzato nelle Dashboard sull’andamento per monitorare nel tempo l’impatto degli interventi di miglioramento e costituisce una base di riferimento per valutare ogni modifica al processo. Perché è importante Fornisce una misura complessiva della salute e dell’efficienza del processo ed è quindi una metrica importante per la rendicontazione ai dirigenti. Dove reperirli La piattaforma di Process Mining calcola questa metrica come differenza tra la data e ora del primo e dell’ultimo evento di ciascun caso. Esempi P10DT5HP4DT12HP22D
	Valuta CurrencyCode	Codice valuta dell’importo della registrazione contabile, ad esempio USD, EUR o GBP.
Descrizione Il codice valuta specifica la valuta degli importi finanziari nella registrazione contabile. È un dato essenziale per le organizzazioni multinazionali che effettuano transazioni in più valute. Questo attributo garantisce la corretta interpretazione dei valori finanziari. Permette di filtrare per valuta ed è necessario per qualsiasi analisi che confronti o aggreghi importi monetari relativi a regioni diverse. Perché è importante Fornisce il contesto necessario per interpretare correttamente gli importi finanziari e consente di analizzare i dati per valuta. Dove reperirli Disponibile nella tabella GL_JE_HEADERS, in genere nel campo CURRENCY_CODE. Esempi USDEURGBPJPY

Obbligatorio Consigliato Facoltativo

Attività di Record to Report - Registrazione contabile

Questi sono i passaggi e le tappe fondamentali del processo da acquisire nell’Event Log per individuare con precisione il processo di registrazione contabile.

5 Consigliato 7 Facoltativo

	Attività	Descrizione
	Registrazione contabile approvata	L’approvatore designato ha approvato formalmente la registrazione contabile, confermandone l’accuratezza e la validità. È l’ultima fase del flusso di lavoro di approvazione e consente di procedere con la contabilizzazione.
Perché è importante Questa tappa segna la conclusione del processo di approvazione. Il tempo che intercorre tra l’invio e l’approvazione è un KPI importante per misurare l’efficienza del flusso di lavoro e individuare i colli di bottiglia nell’approvazione. Dove reperirli L’evento si deduce da una variazione di stato nella tabella GL_JE_HEADERS, quando APPROVAL_STATUS_CODE viene aggiornato a «APPROVED». Le tabelle del flusso di lavoro contengono l’identità dell’approvatore e la data e ora dell’evento. Acquisizione Registrare la data e ora in cui APPROVAL_STATUS_CODE nella tabella GL_JE_HEADERS cambia in «APPROVED». Tipo di evento inferred
	Registrazione contabile contabilizzata	I dati finanziari della registrazione contabile sono stati registrati correttamente nel General Ledger. Gli addebiti e gli accrediti sono ora inclusi nei saldi dei conti.
Perché è importante Questa è una tappa fondamentale: la registrazione entra nei registri finanziari ufficiali. È essenziale per misurare la percentuale di contabilizzazioni puntuali e il tempo totale che intercorre dalla creazione alla contabilizzazione. Dove reperirli L’evento si deduce da una variazione di stato nella tabella GL_JE_HEADERS, quando il campo STATUS cambia in «P» (contabilizzato). Anche la tabella GL_JE_BATCHES contiene uno stato di contabilizzazione. Acquisizione Registrare la data e ora in cui STATUS nella tabella GL_JE_HEADERS cambia in «P». Tipo di evento inferred
	Registrazione contabile creata	Questa attività segna l’avvio del processo di registrazione contabile. Indica il momento in cui un utente crea una nuova testata contabile e inizia a inserire i dati, prima dell’invio per la revisione o l’approvazione.
Perché è importante È l’evento di inizio 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 il tempo di ciclo complessivo. Dove reperirli Questo evento viene in genere dedotto dalla data e dall’ora di creazione registrate nella tabella GL_JE_HEADERS per uno specifico ID di registrazione contabile. La tabella contiene anche l’utente che ha creato il record. Acquisizione Utilizzi CREATION_DATE della tabella GL_JE_HEADERS. Tipo di evento inferred
	Registrazione contabile inviata per l’approvazione	Questa attività si verifica quando l’utente invia formalmente la registrazione contabile completata al flusso di approvazione. La registrazione passa così dallo stato di bozza o incompleto a quello di approvazione in sospeso.
Perché è importante È una tappa fondamentale per iniziare a misurare i tempi del ciclo di approvazione e individuare i colli di bottiglia. Segna il passaggio dalla fase di inserimento dei dati a quella di revisione e approvazione. Dove reperirli Questo evento si deduce da una modifica dello stato nella tabella GL_JE_HEADERS, in particolare quando APPROVAL_STATUS_CODE assume un valore come 'REQUIRED' o 'INITIATED'. Potrebbe essere registrata anche la data e l’ora di invio. Acquisizione Rilevi la data e l’ora in cui APPROVAL_STATUS_CODE in GL_JE_HEADERS cambia per indicare l’invio. Tipo di evento inferred
	Registrazione contabile riconciliata	La registrazione contabile è stata abbinata e chiusa durante la riconciliazione dei conti di fine periodo. Questo conferma che la transazione è coerente con gli altri dati finanziari, ad esempio gli estratti conto bancari.
Perché è importante Questa attività rappresenta la vera conclusione del ciclo di vita della registrazione. Misurare il tempo che intercorre tra la contabilizzazione e la riconciliazione è un KPI importante per valutare l’efficienza del processo di chiusura finanziaria. Dove reperirli In genere, l’evento viene registrato in Oracle Financial Consolidation and Close Cloud Service (FCCS) o Account Reconciliation Cloud Service (ARCS), non nel General Ledger. Si deduce da una variazione di stato nel record di riconciliazione collegato alla registrazione. Acquisizione Correlare i dati della registrazione con gli aggiornamenti dello stato di riconciliazione nelle tabelle ARCS o FCCS. Tipo di evento inferred
	Avvio della contabilizzazione della registrazione	È stato avviato il processo di contabilizzazione della registrazione approvata nel General Ledger. Questa fase, automatica o manuale, inserisce la registrazione nella coda di elaborazione del programma di contabilizzazione.
Perché è importante Questa attività separa l’approvazione dalla fase tecnica di contabilizzazione. Eventuali ritardi tra l’approvazione e l’avvio della contabilizzazione possono indicare problemi di pianificazione o vincoli di risorse nel motore di contabilizzazione. Dove reperirli L’evento si può dedurre dalle variazioni di stato nella tabella GL_JE_BATCHES oppure dall’ora di invio della richiesta di elaborazione concorrente per la contabilizzazione associata al batch della registrazione. Acquisizione Individuare l’ora di invio della richiesta per il programma di contabilizzazione del General Ledger relativa al batch della registrazione. Tipo di evento inferred
	Contabilizzazione verificata	Dopo la contabilizzazione, un utente o un sistema verifica che la registrazione sia stata contabilizzata correttamente e che i saldi siano quelli previsti. Spesso si tratta di un controllo manuale.
Perché è importante L’analisi di questa attività aiuta a capire quanto tempo viene dedicato ai controlli manuali e alla verifica della qualità dopo la contabilizzazione. Può inoltre evidenziare opportunità per automatizzare le verifiche. Dove reperirli È improbabile che in Oracle Fusion sia presente un evento esplicito di questo tipo. Occorre dedurlo da altre azioni, ad esempio dall’esecuzione di un report specifico da parte di un utente o dall’aggiornamento di un campo di stato personalizzato, non previsto nella configurazione standard. Acquisizione Richiede una logica personalizzata, ad esempio il rilevamento dell’ora di esecuzione dei report di verifica o degli aggiornamenti di un campo descrittivo flessibile. Tipo di evento inferred
	Documentazione di supporto allegata	Indica l’azione di allegare alla registrazione contabile documenti di supporto, come fatture o fogli di calcolo. Spesso serve a fornire contesto e prove a revisori e approvatori.
Perché è importante Monitorare questa attività aiuta a capire se i ritardi dipendono dalla documentazione mancante. Offre inoltre indicazioni sulla conformità e sulla completezza delle registrazioni contabili prima che entrino nel flusso di approvazione. Dove reperirli Può essere difficile rilevare questa attività come evento distinto. È possibile dedurla dalle date e dagli orari registrati in tabelle degli allegati come FND_ATTACHED_DOCUMENTS, collegate alla registrazione contabile in GL_JE_HEADERS. Acquisizione La deduca dalla data di creazione dei record in FND_ATTACHED_DOCUMENTS collegati alla registrazione contabile. Tipo di evento inferred
	Registrazione contabile corretta e inviata di nuovo	Dopo il rifiuto di una registrazione contabile, l’autore apporta le correzioni necessarie e la invia nuovamente per l’approvazione. Questa attività segna l’inizio di un nuovo ciclo di approvazione per la stessa registrazione.
Perché è importante Monitorare le rilavorazioni è essenziale per comprendere le inefficienze del processo. Insieme all’attività «Registrazione contabile respinta», questa attività consente di misurare la durata e la frequenza delle rilavorazioni. Dove reperirli Si tratta di un evento successivo «Journal Submitted For Approval» relativo a una registrazione prima in stato «REJECTED». L’evento viene individuato analizzando la sequenza delle variazioni di stato associate a un singolo ID della registrazione contabile. Acquisizione Individuare l’ora di invio successiva a un evento di rifiuto per lo stesso ID caso. Tipo di evento inferred
	Registrazione contabile respinta	Un approvatore ha esaminato la registrazione contabile e l’ha respinta a causa di errori, documentazione mancante o violazioni delle procedure. Questa azione la rinvia all’autore per la correzione.
Perché è importante Questa attività è fondamentale per analizzare i cicli di rilavorazione, i tassi di rifiuto e gli indicatori di correttezza al primo tentativo. Un numero elevato di rifiuti segnala problemi nella qualità dei dati o nella formazione. Dove reperirli L’evento si deduce da una modifica dello stato nella tabella GL_JE_HEADERS, quando APPROVAL_STATUS_CODE viene aggiornato a 'REJECTED'. La cronologia del flusso di lavoro registra l’utente e la data e l’ora dell’azione. Acquisizione Rilevi la data e l’ora in cui APPROVAL_STATUS_CODE in GL_JE_HEADERS viene impostato su 'REJECTED'. Tipo di evento inferred
	Registrazione contabile revisionata	Una fase di revisione che può precedere il processo formale di approvazione o farne parte. Consiste in un controllo da parte di un collega o di un responsabile per verificare l’accuratezza e la conformità prima dell’invio all’approvatore finale.
Perché è importante Isolare questa attività consente di distinguere i tempi della revisione preliminare da quelli dell’approvazione finale. Può far emergere colli di bottiglia nascosti quando la revisione è informale ma richiede molto tempo. Dove reperirli Può essere un passaggio esplicito di un flusso di approvazione articolato in più fasi, registrato nelle tabelle della cronologia del flusso di lavoro. Se è informale, non viene registrato. È possibile dedurlo se prima della decisione finale di approvazione viene registrata un’azione specifica dell’utente. Acquisizione Analizzi le tabelle della cronologia del flusso di lavoro per individuare le fasi intermedie di approvazione o revisione precedenti allo stato finale 'Approvato'. Tipo di evento inferred
	Storno della registrazione elaborato	È stata creata e contabilizzata una registrazione di storno per annullare, in un periodo successivo, l’impatto finanziario della registrazione originale. È un’operazione comune per gli accantonamenti.
Perché è importante Il monitoraggio degli storni aiuta a individuare le tipologie di registrazioni che vengono stornate più spesso e ad analizzare l’efficienza del processo di storno. Può far emergere problemi nella gestione degli accantonamenti. Dove reperirli L’evento si deduce 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, che consentono di identificare e collegare queste registrazioni. Acquisizione Individuare la data di creazione e di contabilizzazione della nuova registrazione, la cui intestazione indica che la registrazione originale è stata stornata. 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. Dal menu Navigator, apra Tools e selezioni Reports and Analytics. Questa è l’area centrale per creare e gestire analisi e report.
Crei un modello dati BI Publisher: invece di iniziare con un’analisi OTBI, per estrarre questo tipo di Event Log è più efficace creare direttamente un modello dati BI Publisher. In questo modo può utilizzare una query SQL personalizzata con istruzioni UNION ALL. Faccia clic sul pulsante 'Browse Catalog', apra una cartella adatta e scelga Create > Data Model.
Definisca il set di dati della query SQL: nell’editor del modello dati, faccia clic sull’icona '+' per aggiungere un nuovo Data Set e selezioni 'SQL Query'. Assegni al set di dati un nome descrittivo, ad esempio 'JournalEventLog'.
Inserisca la query SQL: selezioni 'Oracle BI EE' come origine dei dati. Copi lo script SQL completo dalla sezione Query qui sotto e lo incolli nell’area di testo SQL Query. La query è progettata per raccogliere tutte le attività e gli attributi necessari in un’unica struttura.
Definisca i parametri: la query fornita utilizza parametri come :start_date, :end_date e :ledger_name. L’interfaccia del modello dati li rileva automaticamente. Li configuri come parametri, impostando i tipi di dati appropriati (Date o Text) e, se necessario, i valori predefiniti. In questo modo il report può essere eseguito in modo flessibile.
Crei un report dal modello dati: dopo aver salvato il modello dati, torni al catalogo. Faccia clic su Create > Report. Nella procedura guidata di creazione del report, selezioni 'Use Existing Data Model' e individui il modello dati appena creato.
Configuri il layout del report: nell’editor del layout, scelga il layout 'Table'. Per includere tutte le colonne nell’esportazione, è fondamentale trascinarle dal modello dati alla tabella. Non occorre applicare formattazioni complesse.
Imposti CSV come formato di output predefinito: apra il collegamento 'View a List' nell’editor del report. Nella sezione 'Output Formats', verifichi che sia selezionato 'CSV'. È consigliabile deselezionare tutti gli altri formati per semplificare la pianificazione. Salvi il report.
Pianifichi l’estrazione automatica del report: individui il report salvato nel catalogo e faccia clic su 'More', quindi su 'Schedule'. Crei una nuova pianificazione e ne configuri la frequenza, ad esempio giornaliera o settimanale.
Configuri l’esportazione e la consegna: nella scheda 'Output' del processo pianificato, specifichi i dettagli di output. Selezioni il report e scelga 'CSV' come formato. Nella scheda 'Destination' può configurare la consegna del file a una posizione del server dei contenuti (UCM) o a un server SFTP esterno, per il recupero automatico.
Recuperi e prepari i dati: una volta eseguito il processo pianificato, recuperi il file CSV generato dalla destinazione configurata. Verifichi che le intestazioni delle colonne corrispondano ai requisiti di acquisizione di ProcessMind: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName e così via. Il file è pronto per il caricamento.

Configurazione

Origine dei dati: la query deve essere eseguita sull’origine dati 'Oracle BI EE' in BI Publisher, che si connette alle viste del database transazionale sottostante utilizzate da OTBI.
Aree tematiche principali (per riferimento): la logica della query si basa principalmente sui dati dell’area tematica 'General Ledger - Journals Real Time'. Include inoltre join logici con dati che si trovano nell’area 'HCM - Workforce Management - Worker Assignment Real Time' per i dettagli degli utenti e, potenzialmente, nelle aree tematiche dei flussi di lavoro per la cronologia delle approvazioni.
Filtro per intervallo di date: è fondamentale limitare i dati a un periodo gestibile. La query include i parametri :start_date e :end_date. Per l’analisi iniziale, consigliamo di estrarre da 3 a 6 mesi di dati. Il filtro viene applicato alla data di creazione della registrazione contabile.
Filtro per registro contabile: utilizzi il parametro :ledger_name per limitare l’estrazione a un registro contabile primario specifico. L’estrazione simultanea di tutti i registri può generare file molto grandi e problemi di prestazioni.
Prerequisiti: l’utente che crea e pianifica il report deve disporre dei ruoli BI appropriati, ad esempio 'BI Administrator' o 'BI Author'. Inoltre, il profilo di sicurezza dei dati dell’utente deve consentire l’accesso ai registri contabili e alle unità aziendali interessati dalla query.
Pianificazione: per ottenere prestazioni ottimali ed evitare di interferire con gli utenti del sistema, pianifichi l’estrazione nelle ore di minore attività, ad esempio durante la notte.

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. Dal menu Navigator, apra Tools e selezioni Reports and Analytics. Si aprirà il catalogo Business Intelligence.
Crei un nuovo modello dati: nel catalogo BI, faccia clic sul pulsante Create e selezioni Data Model. Si aprirà l’editor del modello dati.
Definisca il set di dati della query SQL: nell’editor del modello dati, faccia clic sull’icona più nella scheda Diagram e selezioni SQL Query. Nella nuova finestra di dialogo, assegni un nome al set di dati, ad esempio ProcessMind_JE_EventLog. Selezioni l’origine dei dati appropriata, in genere FUSIONDB. Incolli la query SQL completa fornita 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 rileva automaticamente. Li configuri come parametri di tipo Text e assegni etichette chiare, ad esempio 'Start Date (YYYY-MM-DD)' e 'End Date (YYYY-MM-DD)'.
Salvi il modello dati: dopo aver incollato la query e definito i parametri, faccia clic su OK e salvi il modello dati in una cartella adatta, ad esempio Shared Folders/Custom/ProcessMining.
Crei il report: faccia clic sul pulsante Create Report nell’angolo in alto a destra dell’editor del modello dati. Si avvierà la procedura guidata di creazione del report.
Configuri il layout del report: nella procedura guidata, selezioni l’opzione per utilizzare il modello dati corrente. Scelga il layout 'Table'. Trascini tutte le colonne dall’origine dati all’area del layout della tabella. Deselezioni l’opzione 'Show Grand Totals Row'.
Salvi il report: salvi il report nella stessa cartella del modello dati. 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 CSV sia selezionato e, preferibilmente, lo imposti come formato predefinito. In questo modo l’output sarà pronto per l’uso diretto.
Esegua ed esporti il report: apra il report e inserisca i parametri relativi alle date iniziale e finale. Indichi l’intervallo desiderato e faccia clic su Apply. Al termine dell’esecuzione, faccia clic su Export e scelga il formato CSV per scaricare il file dell’Event Log.
Prepari il file per il caricamento: apra il file CSV scaricato. Verifichi che le intestazioni delle colonne corrispondano ai nomi degli attributi previsti (JournalEntryId, ActivityName, EventTime e così via) 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 della contabilità generale, ad esempio General Accountant o un ruolo BI personalizzato. È inoltre necessario poter accedere a BI Publisher.
Origine dei dati: il modello dati BI Publisher deve essere configurato per utilizzare la connessione al database applicativo FUSIONDB.
Parametri dell’intervallo di date: la query utilizza i parametri p_start_date e p_end_date per definire l’intervallo di estrazione dei dati. Per garantire prestazioni adeguate, si consiglia di iniziare con un periodo da 3 a 6 mesi.
Filtri del report: per le organizzazioni di grandi dimensioni, è fortemente consigliato aggiungere filtri direttamente alla clausola WHERE dell’espressione di tabella comune JournalHeaders della query. Filtrare 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 molte risorse. Pianifichi il report nelle ore di minore attività per ridurre al minimo l’impatto sulle prestazioni del sistema.
Formato di output: il report deve essere configurato per generare un file CSV. Questo formato strutturato e privo di elementi superflui è adatto all’acquisizione negli strumenti di Process Mining.

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 che Python 3 sia installato insieme alle librerie requests e pandas. Le servirà un account utente Oracle Fusion Financials con le autorizzazioni necessarie per accedere all’API REST 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, ad esempio le date iniziale e finale della query.
Autenticazione: lo script utilizza l’autenticazione di base. 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 contabili nell’intervallo di date specificato.
Creazione della query API: utilizzi il parametro q nella richiesta API per filtrare le registrazioni contabili in base a LastUpdateDate. In questo modo potrà estrarre i dati di un intervallo specifico, ad esempio LastUpdateDate between '2023-01-01' and '2023-03-31'.
Avvio del recupero dei dati: richiami la funzione per iniziare a recuperare i dati dall’endpoint .../fscmRestApi/resources/11.13.18.05/journals. La funzione restituirà l’elenco completo delle registrazioni contabili.
Elaborazione e trasformazione dei dati: esamini ogni registrazione contabile restituita dall’API. Per ciascuna, generi più righe di eventi corrispondenti alle diverse attività aziendali (Journal Entry Created, Journal Entry Approved e così via). Utilizzi i campi data e i codici di stato della risposta API (CreationDate, PostedDate, ApprovalStatus e così via) per creare gli eventi distinti.
Strutturazione dell’Event Log: man mano che genera le righe degli eventi, le memorizzi come dizionari in un elenco. Questo elenco costituirà i dati grezzi dell’Event Log.
Creazione del DataFrame: dopo aver elaborato tutte le registrazioni contabili, converta l’elenco dei dizionari degli eventi in un DataFrame Pandas, più semplice da gestire.
Definizione delle colonne finali: selezioni e rinomini le colonne del DataFrame in modo che corrispondano allo schema richiesto da ProcessMind: JournalEntryId, ActivityName, EventTime, UserName e così via.
Esportazione in CSV: salvi il DataFrame finale in un file CSV, che potrà caricare direttamente su ProcessMind per l’analisi.

Configurazione

Credenziali: per l’autenticazione di base sono necessari un nome utente e una password Oracle Fusion validi.
URL dell’istanza: serve l’URL di base dell’istanza Oracle Fusion Financials per comporre 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 della contabilità generale.
Filtro per intervallo di date: configuri lo script con start_date e end_date per limitare l’ambito dell’estrazione. Per un’analisi iniziale si consiglia un periodo da 3 a 6 mesi. Per l’uso continuativo, configuri caricamenti incrementali giornalieri o settimanali.
Limite di paginazione: il parametro limit determina quanti record vengono recuperati per 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 necessari: l’account utente deve disporre di un ruolo con i privilegi necessari per leggere i dati delle registrazioni contabili tramite l’API REST, ad esempio General Accountant o un ruolo personalizzato con autorizzazioni equivalenti.

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 nell’ambiente siano disponibili BI Cloud Connector, le aree tematiche General Ledger o i Public View Objects richiesti di Oracle Fusion Financials e le autorizzazioni necessarie per il sistema di origine. 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 le intestazioni e le righe delle registrazioni contabili, la cronologia delle approvazioni, gli allegati, lo stato di contabilizzazione, lo stato di riconciliazione e le informazioni sugli storni. Annoti i nomi esatti degli oggetti e degli attributi configurati nell’ambiente. Prima di eseguire lo script di estrazione, sostituisca i segnaposto con tali nomi.
Configuri un processo 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 intervallo controllato da tre a sei mesi, oppure un altro intervallo di periodi contabili approvato.
Configuri BICC per inviare i file estratti alla posizione designata nell’archiviazione cloud. Verifichi il formato dei file, il delimitatore, la codifica dei caratteri, la compressione, il partizionamento, la convenzione di denominazione e la pianificazione della consegna. Conservi il watermark dell’estrazione o la data e ora dell’ultima estrazione completata correttamente.
Recuperi i file consegnati e li trasferisca nell’area di staging approvata. Carichi ciascun file di origine nella tabella o vista di staging corrispondente. Utilizzi le mappature esatte degli oggetti e degli attributi di origine documentate per l’ambiente. Non presuma che un Public View Object abbia la stessa struttura della tabella di database sottostante.
Normalizzi i timestamp in un unico fuso orario e converta i timestamp di origine in un tipo di dato coerente. Conservi il timestamp di aggiornamento di origine come LastDataUpdate. Converta gli identificatori di origine e gli attributi delle attività nei nomi di output utilizzati da ProcessMind.
Esegua la query seguente dopo aver sostituito ogni segnaposto con il nome effettivo dell’oggetto e dell’attributo di staging. La query crea esplicitamente una riga dell’Event Log per ciascuna delle 12 attività richieste. Non deduce attività assenti dai dati di origine.
Verifichi che JournalEntryId, ActivityName, EventTime, SourceSystem e LastDataUpdate siano presenti in ogni riga di output. Riveda gli eventi duplicati, l’ordine dei timestamp, le registrazioni contabili rifiutate e inviate nuovamente, le relazioni tra storni e i record privi di attributi facoltativi.
Esporti il risultato in un 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 per utilizzare i Public View Objects General Ledger necessari per le intestazioni e le righe delle registrazioni contabili, la cronologia delle approvazioni o dei flussi di lavoro, gli allegati e i dati di contabilizzazione, riconciliazione e storno. Verifichi nel catalogo BICC i nomi esatti degli oggetti e degli attributi disponibili nell’ambiente.
Utilizzi un intervallo iniziale di estrazione da tre a sei mesi. Lo estenda solo dopo aver verificato il volume dei dati, la capacità di archiviazione, la durata dell’estrazione e i tempi di elaborazione a valle.
Applichi i filtri approvati per data contabile o data dell’ultimo aggiornamento, registro contabile, entità giuridica, unità aziendale, codice società se disponibile, categoria e origine della registrazione contabile, tipo di documento se disponibile e stato della registrazione. Utilizzi solo i filtri supportati dai Public View Objects selezionati.
Configuri l’estrazione incrementale utilizzando l’attributo di origine relativo all’ultimo aggiornamento e un watermark persistente. Se necessario, includa una breve finestra di sovrapposizione per gestire gli aggiornamenti ricevuti in ritardo, quindi elimini i duplicati in base a JournalEntryId, ActivityName, EventTime e all’identificativo dell’evento di origine pertinente.
Verifichi che tutti gli oggetti di origine 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 i set di dati di grandi dimensioni, esegua il partizionamento per periodo contabile, registro contabile, entità giuridica o un altro attributo di partizionamento supportato da BICC. Eviti estrazioni storiche senza restrizioni durante l’orario lavorativo.
Conservi i timestamp di origine e quelli relativi agli aggiornamenti prima della trasformazione. Documenti il fuso orario utilizzato per EventTime e LastDataUpdate.
I prerequisiti necessari includono l’accesso alla console BI Cloud Connector, l’autorizzazione a configurare ed eseguire le estrazioni selezionate, l’accesso alla destinazione di archiviazione cloud configurata e all’ambiente di staging, nonché l’autorizzazione a visualizzare i dati General Ledger e dei flussi di lavoro richiesti.
Verifichi che i moduli Oracle Fusion Financials, la configurazione dei flussi di lavoro, l’archiviazione degli allegati, i processi di contabilizzazione e le origini dati di riconciliazione necessari siano abilitati per le attività previste.
Non consideri l’assenza di un record di origine come prova che un’attività non sia avvenuta. L’output BICC dipende dai Public View Objects selezionati, dai filtri, dai tempi di aggiornamento, dalla conservazione dei dati e dalla cronologia disponibile.

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 a iniziare?

Utilizzi questo template per trasformare i dati delle registrazioni contabili di Oracle Fusion in informazioni utili e accelerare il ciclo Record to Report. Inizi oggi a ottimizzare le attività finanziarie.

Torna alla guida al miglioramento

Scarica il template

Accelera oggi il processo Record to Report - Registrazione contabile

Riduca del 30% il tempo di ciclo delle registrazioni contabili e semplifichi le attività finanziarie.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Attivi subito la prova.

Il Suo template dei dati per Record to Report - Registrazione contabile

Il Suo template dei dati per Record to Report - Registrazione contabile

Attributi di Record to Report - Registrazione contabile

Attività di Record to Report - Registrazione contabile

Guide all’estrazione

Esportazione dei report da Oracle OTBI e BI Publisher

Passaggi

Configurazione

Query di esempio sql

Report BI Publisher con query SQL diretta nel modello dati

Passaggi

Configurazione

Query di esempio sql

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

Passaggi

Configurazione

Query di esempio python

Estrazione di dati in blocco con BI Cloud Connector (BICC)

Passaggi

Configurazione

Query di esempio sql

È pronto a iniziare?

Accelera oggi il processo Record to Report - Registrazione contabile