> Miglioramento Continuo dei Processi > Record to Report Registrazioni contabili > Oracle Fusion Financials > Template Dati

Il Suo template di dati per Record to Report - Registrazioni contabili

Oracle Fusion Financials

← Torna alla Guida al Miglioramento

Record to Report - Attributi registrazioni contabili (22) Record to Report - Attività registrazioni contabili (12) Guide all'Estrazione (4)

Il Suo template di dati per Record to Report - Registrazioni contabili

Questo template di dati fornisce una guida completa per estrarre e strutturare i dati delle registrazioni contabili di Oracle Fusion Financials. Delinea gli attributi essenziali da raccogliere e le attività chiave da tracciare, assicurando l'acquisizione di tutte le informazioni necessarie per una solida analisi dei processi. Troverà inoltre consigli pratici su come estrarre questi dati direttamente dal Suo sistema.

Attributi consigliati da raccogliere
Attività chiave da tracciare
Guida all'estrazione per Oracle Fusion Financials

È nuovo agli event log? Impari come creare un event log di Process Mining.

Scarica Template

Record to Report - Attributi registrazioni contabili

Questi sono i campi dati raccomandati da includere nel Suo Event Log per un'analisi completa del processo Record to Report - Registrazioni contabili.

5 Obbligatorio 6 Consigliato 11 Facoltativo

	Nome	Descrizione
	Activity ActivityName	Il nome dello specifico evento aziendale o compito che si è verificato in un momento dato nel processo di registrazione contabile.
Descrizione L'Activity Name descrive una singola fase all'interno del ciclo di vita della registrazione contabile, come `Journal Entry Created` o `Journal Entry Approved`. Questo dato è fondamentale per costruire la mappa dei processi e comprendere la sequenza degli eventi. L'analisi delle attività consente di identificare il flusso del processo, inclusi percorsi standard, deviazioni e cicli di rilavorazione. Tracciando le diverse attività, possiamo misurare il tempo trascorso in fasi specifiche, come l'approvazione, e identificare quali passaggi richiedono più tempo o sono più soggetti a errori. Perché è importante Definisce le fasi del processo, formando l'ossatura della mappa di processo e consentendo l'analisi di flussi, bottleneck e variazioni. Dove trovare Questo attributo deriva tipicamente dai cambiamenti di stato, dagli Event Log o dalle tabelle di audit trail associate agli oggetti delle registrazioni contabili nel modulo Libro Giornale. Esempi Registrazione Contabile CreataScrittura inviata per approvazioneScrittura contabile approvataScrittura contabile registrata
	ID scrittura contabile JournalEntryId	L'identificativo univoco per una singola registrazione contabile, che collega tutte le attività delle transazioni finanziarie correlate.
Descrizione L'ID registrazione contabile funge da identificatore primario del caso, collegando univocamente tutte le attività relative a un set specifico di transazioni finanziarie. Ciò consente di tracciare il ciclo di vita completo di una singola registrazione, dall'apertura alla contabilizzazione finale, assicurando che tutti i dare e avere siano contabilizzati. Nel Process Mining, questo ID è essenziale per ricostruire il percorso end-to-end di ogni scrittura. Collega eventi distinti come `Journal Entry Created`, `Journal Submitted For Approval` e `Journal Entry Posted` in un flusso di processo coerente, consentendo l'analisi dei tempi di ciclo, dei colli di bottiglia e delle varianti di processo. Perché è importante Questa è la chiave fondamentale per tracciare una registrazione contabile dall'inizio alla fine, rendendo possibile l'analisi dell'intero flusso di processo per ogni singolo caso. Dove trovare Questa è una chiave primaria che si trova nelle tabelle principali del Libro Giornale (General Ledger) come GL_JE_HEADERS e GL_JE_LINES. Esempi JE100523JE202311001882019
	Ora di Inizio EventTime	Il timestamp che indica quando una specifica attività o un evento si è verificato.
Descrizione Questo timestamp segna la data e l'ora esatte in cui è stata eseguita un'attività. È l'elemento temporale primario utilizzato nel Process Mining per determinare la sequenza degli eventi e calcolare le durate tra di essi. L'accuratezza dell'Event Time è fondamentale per tutte le analisi basate sul tempo, inclusi il calcolo dei tempi di ciclo, l'identificazione dei colli di bottiglia e il monitoraggio delle prestazioni rispetto agli accordi sul livello di servizio (SLA). Fornisce l'ordine cronologico necessario per ricostruire il flusso del processo così come è avvenuto. Perché è importante Questo timestamp è essenziale per ordinare gli eventi, calcolare tutte le durate del processo ed eseguire qualsiasi analisi basata sul tempo. Dove trovare Queste informazioni sono solitamente memorizzate in tabelle di audit trail o come 'Last Update Date' o 'Creation Date' nelle tabelle delle transazioni come GL_JE_HEADERS e GL_JE_LINES per eventi specifici. Esempi 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
	Sistema di Origine SourceSystem	Il sistema o il modulo da cui hanno avuto origine i dati.
Descrizione Questo attributo identifica il sistema sorgente da cui sono stati estratti i dati del processo. In un panorama IT complesso, i dati possono provenire da più sistemi integrati e questo campo aiuta a differenziarli. Nell'analisi dei processi, conoscere il sistema sorgente è fondamentale per comprendere le varianti di processo che possono essere guidate da diversi comportamenti del sistema. Aiuta inoltre nella convalida dei dati e nella risoluzione dei problemi, tracciando i dati fino alla loro origine. Perché è importante Identifica l'origine dei dati, che è fondamentale per la data governance, la validazione e la comprensione delle variazioni di processo tra i diversi sistemi. Dove trovare Spesso si tratta di un valore statico configurato durante l'estrazione dei dati, oppure potrebbe essere un campo nelle tabelle sorgente che identifica il sistema di inserimento. Esempi Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Ultimo `Data Update` LastDataUpdate	Il timestamp del più recente data refresh o estrazione dal sistema sorgente.
Descrizione Questo attributo registra quando il dataset è stato aggiornato l'ultima volta. Fornisce indicazioni sulla freschezza dei dati analizzati, il che è importante per comprendere la rilevanza degli approfondimenti derivati. In qualsiasi analisi, specialmente nelle dashboard operative, conoscere l'ora dell'ultimo aggiornamento dei dati è fondamentale affinché gli utenti possano fidarsi dei dati e prendere decisioni informate. Comunica chiaramente il punto di cut-off per i dati inclusi nel modello di Process Mining. Perché è importante Indica quanto sono aggiornati i dati, assicurando che gli utenti comprendano l'attualità dell'analisi di processo e possano fidarsi degli insight. Dove trovare Questo valore viene generato e memorizzato durante il processo di estrazione e trasformazione dei dati. In genere è il timestamp di quando il job ETL/ELT è stato completato. Esempi 2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
	Categoria scrittura JournalCategory	La categoria della registrazione contabile, come 'Rateo/Risconto', 'Rettifica' o 'Riclassificazione'.
Descrizione La categoria della scrittura classifica le registrazioni in base al loro scopo aziendale. Questa classificazione consente un'analisi più granulare del processo, poiché diverse categorie possono avere flussi di processo, regole di approvazione o tempi di ciclo distinti. Ad esempio, le scritture di rettifica di fine mese potrebbero avere un processo più complesso e urgente rispetto ai ratei ordinari. Analizzare il processo per categoria aiuta a scoprire queste variazioni e a personalizzare i miglioramenti per tipi specifici di scritture contabili. Perché è importante Consente di segmentare il processo in base allo scopo aziendale della scrittura, rivelando comportamenti e prestazioni differenti per i diversi tipi di registrazione. Dove trovare Disponibile nella tabella GL_JE_HEADERS, solitamente in un campo denominato JE_CATEGORY. Esempi Rateo/RiscontoManualeRettificaRivalutazione
	Importo scrittura JournalAmount	Il valore monetario totale della registrazione contabile, tipicamente la somma dei debiti.
Descrizione Questo attributo rappresenta il valore finanziario totale della transazione nella registrazione contabile. L'importo può essere un fattore significativo che influenza il processo. Ad esempio, le registrazioni di alto valore potrebbero richiedere passaggi di approvazione aggiuntivi o revisioni più approfondite. L'analisi del Journal Amount consente la segmentazione dei casi in base all'impatto finanziario. Aiuta a rispondere a domande come 'Le registrazioni di alto valore richiedono più tempo per essere approvate?' o 'I rifiuti sono più comuni per le registrazioni superiori a una certa soglia?'. Ciò fornisce un contesto aziendale cruciale al flusso del processo. Perché è importante Fornisce un contesto aziendale critico, consentendo analisi basate sull'impatto finanziario e aiutando a identificare se le registrazioni di alto valore seguono un processo differente. Dove trovare Questo valore viene in genere calcolato come la somma dei debiti o dei crediti dalla tabella GL_JE_LINES per una data registrazione contabile. Esempi 5000.00125000.75750.50
	Motivo del Rigetto RejectionReason	Una descrizione testuale o un codice che spiega perché una scrittura contabile è stata rifiutata.
Descrizione Quando una registrazione contabile viene rifiutata durante il processo di approvazione, questo attributo cattura il motivo del rifiuto. Potrebbe trattarsi di un codice predefinito o di un commento in testo libero dell'approvatore. Questo è uno degli attributi più importanti per l'analisi delle cause alla base delle inefficienze dei processi. Analizzando i motivi di rifiuto più comuni, le organizzazioni possono identificare le aree di miglioramento, come una migliore formazione per chi prepara le registrazioni, linee guida più chiare o potenziamenti dei controlli di sistema. Supporta direttamente la dashboard 'Analisi del tasso di rifiuto delle registrazioni contabili'. Perché è importante Offre informazioni dirette sulle cause principali delle rilavorazioni e dei ritardi di processo, consentendo miglioramenti mirati per ridurre i tassi di rifiuto. Dove trovare Queste informazioni possono essere memorizzate in tabelle di workflow o di audit trail associate al processo di approvazione, oppure in un campo note nell'intestazione della registrazione. Esempi Combinazione account errataDocumentazione di supporto insufficienteSupera il budget
	Reparto Utente UserDepartment	Il dipartimento o il team a cui appartiene l'utente che ha eseguito l'attività.
Descrizione Questo attributo fornisce un contesto organizzativo collegando un'attività a un dipartimento specifico, come 'Finanza', 'Operazioni contabili' o 'Audit interno'. In genere deriva dai dati anagrafici dell'utente. L'analisi per dipartimento utente aiuta a identificare i colli di bottiglia interdipartimentali, confrontare le prestazioni dei team e comprendere come l'esecuzione dei processi differisca all'interno dell'organizzazione. È prezioso per l'allocazione delle risorse e le iniziative mirate di miglioramento dei processi. Perché è importante Fornisce un contesto organizzativo, permettendo l'analisi delle prestazioni per team o dipartimento e evidenziando le inefficienze trasversali. Dove trovare Questo dato in genere non si trova nelle tabelle delle transazioni. Deve essere ottenuto unendo lo UserName con una tabella di dati anagrafici utente o dati del sistema HR. Esempi Contabilità generaleReporting finanziarioContabilità Fornitori
	Sorgente scrittura JournalSource	Il libro ausiliario o la fonte che ha generato la registrazione contabile, come 'Payables', 'Receivables' o 'Manuale'.
Descrizione Questo attributo indica l'origine della registrazione contabile all'interno del sistema ERP. Le registrazioni possono essere create manualmente nel Libro Giornale o generate automaticamente da libri ausiliari come Accounts Payable, Accounts Receivable o Fixed Assets. La Journal Source è un attributo chiave per l'analisi dell'automazione. Aiuta a differenziare tra inserimenti manuali e generati dal sistema, supportando il KPI 'Tasso di registrazioni contabili automatizzate'. I processi per le registrazioni provenienti da fonti diverse variano spesso in modo significativo in termini di complessità ed efficienza. Perché è importante Distingue tra scritture manuali e automatizzate, il che è fondamentale per misurare i tassi di automazione e analizzare le differenze di processo. Dove trovare Disponibile nella tabella GL_JE_HEADERS, solitamente in un campo denominato JE_SOURCE. Esempi ManualeContabilità fornitoriAssetContabilità Clienti
	Utente UserName	L'utente che ha eseguito l'attività, come la creazione, l'approvazione o la contabilizzazione della registrazione.
Descrizione Questo attributo identifica lo specifico dipendente o utente di sistema responsabile dell'esecuzione di un'attività. È fondamentale per comprendere la distribuzione del carico di lavoro, le prestazioni e identificare i singoli colli di bottiglia. In fase di analisi, lo UserName consente di filtrare i processi per utente, confrontare l'efficienza degli utenti e indagare sulle ragioni di ritardi o errori. Supporta direttamente dashboard come 'Carico di lavoro ed efficienza degli utenti tra i team' e KPI come l' 'Indice dei colli di bottiglia delle registrazioni per utente'. Perché è importante Attribuisce la responsabilità delle fasi del processo, consentendo l'analisi del carico di lavoro degli utenti, delle prestazioni individuali e delle esigenze di formazione. Dove trovare Si trova nelle tabelle transazionali come GL_JE_HEADERS (ad es. CREATED_BY, LAST_UPDATED_BY) e nelle relative tabelle di audit trail. Esempi john.doesusan.smithautoprocess_user
	Data di contabilizzazione prevista TargetPostingDate	La data predefinita entro la quale è prevista la contabilizzazione della registrazione.
Descrizione La Target Posting Date rappresenta la scadenza per la contabilizzazione di una registrazione nel libro mastro generale, spesso determinata da accordi sul livello di servizio (SLA) o dai programmi di chiusura di fine mese. Funge da parametro di riferimento per misurare le prestazioni. Questo attributo è essenziale per calcolare il KPI 'Tasso di contabilizzazione puntuale'. Confrontando la data di contabilizzazione effettiva con questo obiettivo, il sistema può segnalare automaticamente le voci come puntuali o in ritardo, fornendo una misura chiara dell'aderenza del processo alle tempistiche previste. Perché è importante Definisce lo SLA (Service Level Agreement) o la scadenza per la registrazione, consentendo il calcolo dei KPI di performance puntuale. Dove trovare Questo potrebbe non essere un campo standard. Potrebbe derivare 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 registrazione puntuale IsOnTimePosting	Un flag calcolato che è vero se la scrittura è stata registrata entro o prima della data obiettivo.
Descrizione Questo attributo booleano deriva dal confronto tra il timestamp dell'attività `Journal Entry Posted` e la 'Target Posting Date'. Se la contabilizzazione avviene entro la data prevista, il valore è 'true'; altrimenti è 'false'. Questo attributo supporta direttamente il KPI 'Tasso di contabilizzazione puntuale' semplificandone il calcolo. Consente di filtrare e analizzare facilmente le registrazioni in ritardo per identificare le cause comuni dei ritardi, come specifiche categorie di registrazioni o approvatori. Perché è importante Fornisce un risultato binario chiaro per le prestazioni di contabilizzazione, semplificando l'analisi dei tassi di puntualità e le cause alla base dei ritardi. Dove trovare Questo attributo è calcolato dallo strumento di Process Mining. Richiede l'attributo 'TargetPostingDate' e il timestamp dell'attività `Journal Entry Posted`. Esempi truefalse
	È una Rilavorazione IsRework	Un flag calcolato che è vero se la scrittura contabile ha subito un ciclo di rifiuto e correzione.
Descrizione Questo attributo booleano viene calcolato per identificare i casi che hanno subito rilavorazioni. In genere viene contrassegnato come 'true' per qualsiasi attività che segue un evento `Journal Entry Rejected`, come `Journal Corrected and Resubmitted`. L'Is Rework è un attributo potente per l'analisi, in quanto consente di quantificare facilmente il volume e l'impatto dei cicli di rilavorazione. Supporta direttamente il KPI 'Tasso medio di rilavorazione delle registrazioni' e aiuta a confrontare il flusso e la durata dei casi rilavorati rispetto a quelli elaborati correttamente la prima volta. Perché è importante Contrassegna direttamente i casi che hanno subito loop di rilavorazione inefficienti, rendendo facile quantificare la frequenza e l'impatto dei fallimenti di processo. Dove trovare Questo dato non è disponibile nel sistema sorgente. Viene calcolato all'interno dello strumento di Process Mining analizzando la sequenza delle attività per ogni caso. Esempi truefalse
	Indicatore di storno ReversalIndicator	Un flag che indica se la scrittura contabile è uno storno di un'altra registrazione.
Descrizione Questo attributo booleano identifica le registrazioni contabili create per stornare una voce precedentemente contabilizzata. Gli storni sono un tipo specifico di registrazione contabile che spesso segue un processo distinto e, a volte, problematico. L'analisi di questo indicatore è fondamentale per supportare la dashboard 'Prestazioni del processo di storno contabile'. Consente di isolare i processi di storno per misurarne la frequenza, le cause e i tempi di ciclo, aiutando a identificare i problemi sottostanti nelle registrazioni originali che ne rendono necessario lo storno. Perché è importante Aiuta a isolare e analizzare il processo di storno, che spesso è un indicatore di errori o problemi nella transazione originale. Dove trovare Può essere un flag specifico sulla tabella GL_JE_HEADERS, come ACCRUAL_REV_FLAG, o identificato tramite collegamenti alla registrazione originale oggetto di storno. Esempi truefalse
	Nome del Registro Contabile LedgerName	Il nome del libro mastro generale dove viene registrata la scrittura contabile.
Descrizione Il Ledger Name identifica il libro mastro specifico a cui appartiene la registrazione contabile. Nelle organizzazioni con più entità legali o requisiti di reporting, possono esserci più libri mastro, come un libro mastro primario per la contabilità aziendale e libri mastro secondari per il reporting statutario locale. Questo attributo è essenziale per filtrare e confrontare i processi tra diverse entità legali o business unit. Garantisce che le analisi siano condotte nel corretto contesto organizzativo, il che è particolarmente importante per la conformità finanziaria e il reporting. Perché è importante Consente di filtrare e confrontare l'analisi dei processi tra diverse entità legali o framework contabili, il che è vitale per le grandi organizzazioni. Dove trovare Si trova nella tabella GL_JE_HEADERS, solitamente collegata tramite un LEDGER_ID che può essere unito con GL_LEDGERS per ottenere il nome. Esempi US Primary LedgerUK Statutory LedgerLedger di consolidamento globale
	Ora di Fine EndTime	Il `timestamp` che indica quando una specifica attività è stata completata.
Descrizione L'End Time segna il completamento di un'attività. Mentre lo Start Time registra l'inizio, l'End Time fornisce il punto di chiusura, consentendo il calcolo preciso del tempo di elaborazione per quella fase specifica. Questo è essenziale per calcolare i tempi di elaborazione delle attività, che è una metrica fondamentale per identificare i colli di bottiglia e misurare l'efficienza delle risorse. Ad esempio, la differenza tra l'End Time e lo Start Time dell'attività `Journal Entry Reviewed` indica il tempo effettivo che un revisore ha dedicato al compito. Perché è importante Consente il calcolo della durata effettiva o del tempo di elaborazione delle singole attività, elemento chiave per identificare problemi di efficienza. Dove trovare Similmente all'ora di inizio, questo dato si trova spesso nelle tabelle di audit trail o può essere dedotto 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	Il periodo fiscale in cui la registrazione viene contabilizzata, ad esempio 'Gen-24'.
Descrizione L'Accounting Period specifica il periodo finanziario in cui la transazione viene riconosciuta. Questo elemento è fondamentale per tutto il reporting e l'analisi finanziaria. Nel Process Mining, questo attributo è cruciale per l'analisi dei trend. Consente di confrontare le prestazioni del processo, come i tempi di ciclo o i tassi di rifiuto, tra diversi mesi o trimestri. Ciò aiuta a identificare gli effetti della stagionalità, come l'aumento del carico di lavoro durante la chiusura del mese, e a misurare l'impatto dei miglioramenti del processo nel tempo. Perché è importante Consente l'analisi dei trend dei KPI nel tempo, aiutando a misurare il miglioramento dei processi e a identificare modelli stagionali come le pressioni di fine mese. Dove trovare Disponibile nella tabella GL_JE_HEADERS, solitamente in un campo denominato PERIOD_NAME. Esempi Gen-24Feb-24Mar-24
	Stato registrazione PostingStatus	Lo stato di contabilizzazione attuale della registrazione contabile, ad esempio 'Unposted' o 'Posted'.
Descrizione Questo attributo riflette lo stato attuale della registrazione contabile rispetto alla sua contabilizzazione nel libro mastro generale. È un indicatore chiave della posizione di una registrazione nel suo ciclo di vita, specialmente per i casi in corso. Il Posting Status è fondamentale per la dashboard 'Tracker dello stato delle registrazioni contabili in tempo reale', fornendo un'istantanea di tutte le voci attive. Aiuta a monitorare gli arretrati di registrazioni non contabilizzate e a identificare i ritardi nelle fasi finali del processo. Perché è importante Indica lo stato attuale di una scrittura, che è essenziale per monitorare gli arretrati e tracciare lo stato delle registrazioni in corso. Dove trovare Disponibile nella tabella GL_JE_HEADERS, solitamente in una colonna come STATUS o POSTING_STATUS. Esempi RegistratoNon contabilizzataErrore
	Tempo approvazione scrittura JournalApprovalTime	La durata calcolata tra l'invio della registrazione e la decisione finale di approvazione o rifiuto.
Descrizione Questa metrica misura il tempo trascorso dal momento in cui una registrazione viene inviata per l'approvazione fino a quando viene approvata o rifiutata. È una misura critica dell'efficienza del workflow di approvazione. Il Journal Approval Time alimenta direttamente il KPI 'Tempo medio di approvazione delle registrazioni' e la dashboard 'Colli di bottiglia nell'approvazione delle registrazioni contabili'. L'analisi di questa durata aiuta a individuare i ritardi nella catena di approvazione, siano essi causati da specifici approvatori, dipartimenti o tipi di registrazioni. Perché è importante Misura direttamente l'efficienza del workflow di approvazione, che spesso è una delle principali fonti di ritardi nel processo. Dove trovare Questa è una metrica calcolata all'interno dello strumento di Process Mining. È la differenza di tempo tra gli eventi `Journal Submitted For Approval` e `Journal Entry Approved` o `Journal Entry Rejected`. Esempi P2DT4H30MPT8HP5D
	Tempo di Ciclo End-to-End EndToEndCycleTime	La durata totale calcolata dalla creazione di una registrazione contabile alla sua riconciliazione finale.
Descrizione Questa metrica rappresenta il tempo totale che una registrazione contabile trascorre nell'intero processo, dal primissimo evento `Journal Entry Created` all'evento finale `Journal Entry Reconciled`. Fornisce una visione olistica delle prestazioni del processo. Questo è un KPI primario per misurare l'efficienza complessiva del processo. Viene utilizzato nelle dashboard dei trend per monitorare l'impatto delle iniziative di miglioramento nel tempo e fornisce una base di riferimento rispetto alla quale misurare tutti i cambiamenti del processo. Perché è importante Fornisce una misura di alto livello della salute e dell'efficienza dell'intero processo, rendendolo una metrica chiave per il reporting direzionale. Dove trovare Questa metrica viene calcolata dalla piattaforma di Process Mining come differenza di tempo tra i timestamp del primo e dell'ultimo evento per ogni caso. Esempi P10DT5HP4DT12HP22D
	Valuta CurrencyCode	Il codice valuta per l'importo della registrazione contabile, come USD, EUR o GBP.
Descrizione Il Currency Code specifica la valuta degli importi finanziari nella registrazione contabile. È essenziale per le organizzazioni multinazionali che operano in più valute. Questo attributo garantisce che i valori finanziari siano interpretati correttamente. Consente di filtrare per valuta ed è un campo necessario quando si esegue qualsiasi analisi che comporti il confronto o l'aggregazione di importi monetari tra diverse regioni. Perché è importante Fornisce il contesto necessario per gli importi finanziari, garantendo un'interpretazione accurata e consentendo analisi specifiche per le diverse valute. Dove trovare Disponibile nella tabella GL_JE_HEADERS, solitamente in un campo denominato CURRENCY_CODE. Esempi USDEURGBPJPY

Obbligatorio Consigliato Facoltativo

Record to Report - Attività registrazioni contabili

Questi sono i passaggi chiave del processo e le pietre miliari da catturare nel Suo Event Log per una scoperta accurata del processo di registrazione contabile.

5 Consigliato 7 Facoltativo

	Activity	Descrizione
	Registrazione Contabile Creata	Questa attività segna l'avvio del processo di registrazione contabile. Rappresenta il momento in cui un utente crea una nuova intestazione di registrazione e inizia a inserire i dati, prima che venga inviata per la revisione o l'approvazione.
Perché è importante Questo è l'evento iniziale principale del processo. L'analisi del 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 del processo. Dove trovare Questo evento viene in genere dedotto dal timestamp della data di creazione nella tabella GL_JE_HEADERS per uno specifico ID registrazione contabile. In questa tabella è disponibile anche l'utente che ha creato il record. Acquisisci Utilizzi la CREATION_DATE della tabella GL_JE_HEADERS. Tipo di evento inferred
	Scrittura contabile approvata	L'approvatore designato ha approvato formalmente la registrazione contabile, confermandone l'accuratezza e la validità. Questo è il passaggio finale nel workflow di approvazione, che apre la strada alla contabilizzazione.
Perché è importante Questa pietra miliare segna la fine del processo di approvazione. Il tempo tra l'invio e l'approvazione è un KPI chiave per misurare l'efficienza del workflow e identificare i colli di bottiglia nell'approvazione. Dove trovare Questo evento viene dedotto da un cambiamento di stato nella tabella GL_JE_HEADERS, dove l'APPROVAL_STATUS_CODE viene aggiornato in 'APPROVED'. Le tabelle di workflow contengono l'identità dell'approvatore e il timestamp. Acquisisci Traccia il timestamp di quando APPROVAL_STATUS_CODE in GL_JE_HEADERS passa a 'APPROVED'. Tipo di evento inferred
	Scrittura contabile registrata	I dati finanziari della registrazione contabile sono stati registrati con successo nel Libro Giornale (General Ledger). I debiti e i crediti sono ora riflessi nei saldi dei conti.
Perché è importante Questa è una pietra miliare critica che rappresenta l'inserimento della scrittura nei registri finanziari ufficiali. È essenziale per misurare il tasso di contabilizzazione puntuale e il tempo totale dalla creazione alla contabilizzazione. Dove trovare Questo dato viene dedotto da un cambiamento di stato nella tabella GL_JE_HEADERS, dove il campo STATUS cambia in 'P' (Posted). Anche la tabella GL_JE_BATCHES ha uno stato di contabilizzazione. Acquisisci Traccia il timestamp di quando lo STATUS in GL_JE_HEADERS cambia in 'P'. Tipo di evento inferred
	Scrittura contabile riconciliata	La registrazione contabile è stata abbinata e chiusa durante un processo di riconciliazione dei conti di fine periodo. Ciò conferma che la transazione è allineata con altri dati finanziari, come gli estratti conto bancari.
Perché è importante Questa attività funge da vero punto finale per il ciclo di vita della registrazione. La misurazione del tempo dalla contabilizzazione alla riconciliazione è un KPI chiave per valutare l'efficienza del processo di chiusura finanziaria. Dove trovare Questo evento viene solitamente catturato in Oracle Financial Consolidation and Close Cloud Service (FCCS) o Account Reconciliation Cloud Service (ARCS), e non nel Libro Giornale stesso. Viene dedotto da un cambiamento di stato nel record di riconciliazione collegato alla registrazione. Acquisisci Correli i dati del registro con gli aggiornamenti dello stato di riconciliazione dalle tabelle ARCS o FCCS. Tipo di evento inferred
	Scrittura inviata per approvazione	Questa attività si verifica quando l'utente invia formalmente la registrazione contabile completata nel workflow di approvazione. Fa passare la registrazione da uno stato di bozza o incompleto a uno stato di approvazione in sospeso.
Perché è importante Questa è una pietra miliare critica che avvia il cronometro per misurare i tempi del ciclo di approvazione e identificare i colli di bottiglia. Separa la fase di inserimento dei dati dalla fase di revisione e approvazione. Dove trovare Questo evento viene dedotto da un cambiamento di stato nella tabella GL_JE_HEADERS, specificamente quando l'APPROVAL_STATUS_CODE cambia in un valore come 'REQUIRED' o 'INITIATED'. Potrebbe essere registrato anche il timestamp della data di invio. Acquisisci Traccia il timestamp di quando APPROVAL_STATUS_CODE in GL_JE_HEADERS cambia per indicare l'invio. Tipo di evento inferred
	Documentazione di supporto allegata	Rappresenta l'azione di allegare documenti di supporto, come fatture o fogli di calcolo, alla registrazione contabile. Questa operazione viene spesso eseguita per fornire contesto e prove ai revisori e ai responsabili delle approvazioni.
Perché è importante Il tracciamento di questa attività aiuta a capire se i ritardi sono causati da documentazione mancante. Fornisce inoltre approfondimenti sulla conformità e sulla completezza delle registrazioni contabili prima che entrino nel workflow di approvazione. Dove trovare Può essere difficile da tracciare come evento discreto. Potrebbe essere dedotto dai timestamp nelle tabelle degli allegati come FND_ATTACHED_DOCUMENTS, collegate al record della registrazione contabile in GL_JE_HEADERS. Acquisisci Deduce dalla data di creazione dei record in FND_ATTACHED_DOCUMENTS collegati alla scrittura. Tipo di evento inferred
	Registrazione scrittura avviata	Il processo di contabilizzazione della registrazione approvata nel Libro Giornale è stato avviato. Può trattarsi di un passaggio automatico o manuale che mette la registrazione in coda per l'elaborazione da parte del programma di contabilizzazione.
Perché è importante Questa attività separa l'approvazione dal processo tecnico di contabilizzazione. I ritardi tra l'approvazione e l'inizio della contabilizzazione possono indicare problemi di programmazione o vincoli di risorse nel motore di contabilizzazione. Dove trovare Questo dato può essere dedotto dai cambiamenti di stato nella tabella GL_JE_BATCHES o dall'ora di invio della richiesta simultanea di contabilizzazione associata al batch di registrazioni. Acquisisci Identifica l'ora di invio della richiesta per il programma di registrazione della contabilità generale per lo specifico batch di scritture. Tipo di evento inferred
	Registrazione verificata	Una fase di verifica post-registrazione in cui un utente o il sistema conferma che la scrittura è stata registrata correttamente e che i saldi sono quelli attesi. Spesso si tratta di una fase di controllo manuale.
Perché è importante L'analisi di questa attività aiuta a capire il tempo speso nei controlli manuali e nella garanzia della qualità dopo la registrazione. Può evidenziare opportunità per automatizzare i processi di verifica. Dove trovare È improbabile che si tratti di un evento esplicito in Oracle Fusion. Dovrebbe essere dedotto da altre azioni, come l'esecuzione di un report specifico da parte di un utente o l'aggiornamento di un campo di stato personalizzato, cosa che non è standard. Acquisisci Richiede una logica personalizzata, come il tracciamento del tempo di esecuzione dei report di verifica o degli aggiornamenti a un campo flessibile descrittivo. Tipo di evento inferred
	Scrittura contabile revisionata	Una fase di revisione che può avvenire prima o come parte del processo di approvazione formale. Rappresenta un controllo da parte di un collega o di un manager per garantire accuratezza e conformità prima che passi all'approvatore finale.
Perché è importante Isolare questa attività aiuta a differenziare i tempi di revisione preliminare dai tempi di approvazione finale. Può rivelare bottleneck nascosti se la fase di revisione è informale ma richiede tempo. Dove trovare Questo potrebbe essere un passaggio esplicito in un workflow di approvazione a più stadi, catturato nelle tabelle della cronologia del workflow. Se informale, non viene catturato. Può essere dedotto se viene registrata un'azione specifica dell'utente prima della decisione di approvazione finale. Acquisisci Analizzi le tabelle della cronologia del workflow per individuare fasi di approvazione o revisione intermedie prima dello stato finale 'Approved'. Tipo di evento inferred
	Scrittura contabile rifiutata	Un approvatore ha esaminato la scrittura contabile e l'ha rifiutata a causa di errori, mancanza di documentazione o violazioni delle policy. Questa azione rimanda la scrittura al creatore per la correzione.
Perché è importante Questa attività è fondamentale per analizzare i cicli di rilavorazione, i tassi di rifiuto e le metriche first-time-right. Un'alta frequenza di rifiuti indica problemi di qualità dei dati o di formazione. Dove trovare Questo dato viene dedotto da un cambiamento di stato nella tabella GL_JE_HEADERS quando l'APPROVAL_STATUS_CODE viene aggiornato a 'REJECTED'. La cronologia del workflow registrerà l'utente e il timestamp di questa azione. Acquisisci Traccia il timestamp di quando APPROVAL_STATUS_CODE in GL_JE_HEADERS viene impostato su 'REJECTED'. Tipo di evento inferred
	Scrittura corretta e reinviata	Dopo che una scrittura contabile è stata rifiutata, il creatore apporta le correzioni necessarie e la reinvia per l'approvazione. Questa attività rappresenta l'inizio di un nuovo ciclo di approvazione per la stessa scrittura.
Perché è importante Il tracciamento delle rilavorazioni è essenziale per comprendere l'inefficienza del processo. Questa attività, combinata con `Journal Entry Rejected`, consente di misurare il tempo e la frequenza delle rilavorazioni. Dove trovare Si tratta di un evento successivo di `Journal Submitted For Approval` per una scrittura che era precedentemente in uno stato 'REJECTED'. Viene identificato analizzando la sequenza dei cambiamenti di stato per un singolo ID registrazione contabile. Acquisisci Identifica un timestamp dell'evento di invio che si verifica dopo un evento di rifiuto per lo stesso ID caso. Tipo di evento inferred
	Storno scrittura elaborato	Una scrittura di storno è stata creata e registrata per annullare l'impatto finanziario della scrittura originale in un periodo successivo. Si tratta di un'azione comune per i ratei e i risconti.
Perché è importante Il tracciamento degli storni aiuta a identificare i tipi di registrazioni che vengono stornate frequentemente e ad analizzare l'efficienza del processo di storno stesso. Ciò può indicare problemi nella gestione dei ratei e risconti. Dove trovare Questo dato viene dedotto identificando una nuova registrazione contabile esplicitamente collegata all'originale come suo storno. La tabella GL_JE_HEADERS contiene campi come REVERSAL_PERIOD e REVERSAL_FLAG per identificare e collegare queste voci. Acquisisci Identifica la data di creazione e di registrazione della nuova scrittura la cui intestazione fa riferimento alla scrittura originale come stornata. Tipo di evento inferred

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i tuoi dati da Oracle Fusion Financials

Fasi

Andare nell'area di lavoro Report e analisi: effettui il login in Oracle Fusion Financials. Utilizzi il menu Navigator per andare su Strumenti, quindi selezioni Report e analisi. Questo è l'hub centrale per la creazione e la gestione di tutte le analisi e i report.
Creare un modello dati BI Publisher: invece di iniziare con un'analisi OTBI, per questo tipo di estrazione di Event Log è più efficace creare direttamente un modello dati BI Publisher. Ciò consente di utilizzare una query SQL personalizzata con istruzioni UNION ALL. Clicchi sul pulsante 'Sfoglia catalogo', vada in una cartella adatta e scelga Crea > Modello dati.
Definire il dataset della query SQL: nell'editor del modello dati, clicchi sull'icona '+' per aggiungere un nuovo set di dati e selezioni 'Query SQL'. Assegni al dataset un nome descrittivo, ad esempio 'JournalEventLog'.
Inserire la query SQL: selezioni 'Oracle BI EE' come sorgente dati. Copi lo script SQL completo dalla sezione Query qui sotto e lo incolli nell'area di testo Query SQL. La query è progettata per estrarre tutte le attività e gli attributi richiesti in un'unica struttura unificata.
Definire i parametri: la query fornita utilizza parametri come :start_date, :end_date e :ledger_name. L'interfaccia del modello dati li rileverà automaticamente. Deve configurarli come parametri, impostando i tipi di dati appropriati (Data o Testo) e i valori predefiniti se necessario. Ciò consente un'esecuzione flessibile del report.
Creare un report dal modello dati: dopo aver salvato il modello dati, torni al catalogo. Clicchi su Crea > Report. Nella procedura guidata di creazione del report, selezioni 'Usa modello dati esistente' e individui il modello dati appena creato.
Configurare il layout del report: nell'editor del layout, scelga il layout 'Tabella'. È fondamentale trascinare tutte le colonne dal modello dati nella tabella per assicurarsi che siano incluse nell'esportazione. Non è necessaria una formattazione complessa.
Impostare l'output predefinito su CSV: vada al link 'Visualizza elenco' nell'editor del report. Nella sezione 'Formati di output', si assicuri che 'CSV' sia selezionato. Si consiglia di deselezionare tutti gli altri formati per semplificare la pianificazione. Salvi il report.
Pianificare il report per l'estrazione automatica: trovi il report salvato nel catalogo e clicchi su 'Altro', quindi su 'Pianifica'. Crei un nuovo job di pianificazione. Ne configuri la frequenza, ad esempio giornaliera o settimanale.
Configurare esportazione e consegna: nella scheda 'Output' del job di pianificazione, specifichi i dettagli dell'output. Selezioni il report e scelga 'CSV' come formato. Nella scheda 'Destinazione', può configurare la consegna del file in una posizione del server di contenuti (UCM) o in un server SFTP esterno per il recupero automatizzato.
Recuperare e preparare i dati: una volta eseguito il job pianificato, recuperi il file CSV generato dalla destinazione configurata. Si assicuri che le intestazioni delle colonne corrispondano ai requisiti per l'importazione in ProcessMind: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, ecc. Il file è ora pronto per il caricamento.

Configurazione

Sorgente dati: la query deve essere eseguita sulla sorgente dati 'Oracle BI EE' all'interno di BI Publisher, che si connette alle viste del database transazionale sottostante che supportano OTBI.
Aree tematiche chiave (per riferimento): la logica della query si basa su dati presenti principalmente nell'area tematica 'General Ledger - Journals Real Time'. Inoltre, unisce logicamente dati presenti in 'HCM - Workforce Management - Worker Assignment Real Time' per i dettagli dell'utente e potenzialmente aree tematiche di workflow per la cronologia delle approvazioni.
Filtro intervallo date: è fondamentale filtrare i dati in un intervallo gestibile. La query include i parametri :start_date e :end_date. Raccomandiamo di estrarre da 3 a 6 mesi di dati per un'analisi iniziale. Il filtro viene applicato alla data di creazione della scrittura.
Filtro Ledger: utilizzi il parametro :ledger_name per limitare l'estrazione a un ledger primario specifico. L'estrazione simultanea di tutti i ledger può causare file estremamente voluminosi e problemi di prestazioni.
Prerequisiti: l'utente che crea e pianifica il report deve disporre di ruoli BI appropriati, come 'BI Administrator' o 'BI Author'. Inoltre, il profilo di sicurezza dei dati dell'utente deve garantire l'accesso ai ledger e alle business unit oggetto della query.
Pianificazione: per prestazioni ottimali e per evitare impatti sugli utenti del sistema, pianifichi l'esecuzione dell'estrazione durante le ore non di punta, come la notte.

a Query di Esempio config

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Fasi

Andare su BI Publisher: effettui il login in Oracle Fusion Financials. Utilizzi il menu Navigator per andare su Strumenti, quindi selezioni Report e analisi. Si aprirà il catalogo di Business Intelligence.
Creare un nuovo modello dati: nel catalogo BI, clicchi sul pulsante Crea e selezioni Modello dati. Si aprirà l'editor del modello dati.
Definire il dataset della query SQL: nell'editor del modello dati, clicchi sull'icona più nella scheda Diagramma e selezioni Query SQL. Nella nuova finestra di dialogo, assegni un nome al dataset, ad esempio ProcessMind_JE_EventLog. Selezioni la sorgente dati appropriata, solitamente FUSIONDB. Incolli la query SQL completa fornita nell'area di testo Query SQL.
Definire i parametri: la query utilizza parametri per l'intervallo di date (p_start_date e p_end_date). Oracle BI Publisher li rileverà automaticamente. Deve configurarli come parametri di tipo Testo e impostare etichette intuitive come 'Start Date (YYYY-MM-DD)' e 'End Date (YYYY-MM-DD)'.
Salvare il modello dati: dopo aver incollato la query e definito i parametri, clicchi su OK e salvi il modello dati in una cartella adatta, ad esempio Cartelle condivise/Custom/ProcessMining.
Creare il report: clicchi sul pulsante Crea report nell'angolo in alto a destra dell'editor del modello dati. Verrà avviata la procedura guidata di creazione del report.
Configurare il layout del report: nella procedura guidata, selezioni l'opzione per utilizzare il modello dati corrente. Scelga il layout 'Tabella'. Trascini tutte le colonne dalla sorgente dati nell'area del layout della tabella. Deselezioni l'opzione 'Mostra riga totali complessivi'.
Salvare il report: salvi il report nella stessa cartella del modello dati. Gli assegni un nome descrittivo come 'Journal Entry Event Log Report'.
Impostare il formato di output predefinito: modifichi il report e vada alla scheda 'Visualizzazione'. In 'Formati di output', si assicuri che CSV sia selezionato e lo imposti preferibilmente come formato predefinito. Ciò garantisce che l'output sia compatibile per l'uso diretto.
Eseguire ed esportare: apra il report e le verrà chiesto di inserire i parametri della data di inizio e di fine. Inserisca l'intervallo desiderato e clicchi su Applica. Una volta eseguito il report, clicchi sul pulsante Esporta e scelga il formato CSV per scaricare il file dell'Event Log.
Preparare per l'upload: apra il file CSV scaricato. Verifichi che le intestazioni delle colonne corrispondano ai nomi degli attributi attesi (JournalEntryId, ActivityName, EventTime, ecc.) e che i dati siano formattati correttamente prima di caricarli sulla piattaforma ProcessMind.

Configurazione

Prerequisiti: l'utente che esegue il report deve avere un ruolo con i privilegi di sicurezza necessari per accedere ai dati di Contabilità Generale, come General Accountant o un ruolo BI personalizzato. È inoltre necessario l'accesso allo strumento BI Publisher.
Sorgente dati: il Data Model di BI Publisher deve essere configurato per utilizzare la connessione al database dell'applicazione FUSIONDB.
Parametri intervallo date: la query è progettata con i parametri p_start_date e p_end_date per controllare la finestra di estrazione dei dati. Si consiglia di iniziare con un periodo di 3-6 mesi per garantire le prestazioni.
Filtri del report: per le grandi organizzazioni, si raccomanda vivamente di aggiungere filtri direttamente nella clausola WHERE della common table expression 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 risorse significative. Pianifichi l'esecuzione del report durante le ore non di punta per ridurre al minimo l'impatto sulle prestazioni del sistema.
Formato di output: il report deve essere configurato per generare un file CSV. Questo fornisce un formato pulito e strutturato per l'importazione nei tool di Process Mining.

a Query di Esempio sql

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Fasi

Prerequisiti: si assicuri di avere installato Python 3 insieme alle librerie requests e pandas. Sarà necessario un account utente per Oracle Fusion Financials con i permessi necessari per accedere all'API REST General Ledger Journals. Recuperi l'URL della propria 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 proprie credenziali Oracle Fusion e l'URL di base. Inoltre, imposti i parametri per l'estrazione dei dati, come le date di inizio e fine per la query.
Autenticazione: lo script utilizza l'autenticazione di base. La libreria requests gestisce la codifica di nome utente e password nelle intestazioni della richiesta.
Definire la funzione di chiamata API: crei una funzione per gestire le richieste API. Questa funzione deve gestire la paginazione utilizzando i parametri offset e limit. Eseguirà un ciclo, effettuando chiamate API successive, finché non saranno stati recuperati tutti i record di registrazione nell'intervallo di date specificato.
Costruire la query API: utilizzi il parametro q nella richiesta API per filtrare le scritture in base a LastUpdateDate. Ciò consente l'estrazione mirata dei dati in un arco temporale specifico, ad esempio LastUpdateDate between '2023-01-01' and '2023-03-31'.
Avviare il recupero dei dati: chiami la funzione per iniziare a recuperare i dati dall'endpoint .../fscmRestApi/resources/11.13.18.05/journals. La funzione restituirà un elenco completo di scritture contabili.
Elaborare e trasformare i dati: iteri attraverso ogni scrittura restituita dall'API. Per ogni scrittura, generi più righe di evento corrispondenti alle diverse attività aziendali (Journal Entry Created, Journal Entry Approved, ecc.). Utilizzi i campi data e i codici di stato della risposta API (CreationDate, PostedDate, ApprovalStatus, ecc.) per creare questi eventi distinti.
Strutturare l'Event Log: man mano che viene generata ogni riga di evento, la memorizzi come dizionario in una lista. Questa lista diventerà il dato grezzo per l'Event Log.
Creare il DataFrame: una volta elaborate tutte le scritture, converta la lista di dizionari di eventi in un DataFrame Pandas per una manipolazione più semplice.
Finalizzare le colonne: selezioni e rinomini le colonne del DataFrame per farle corrispondere allo schema richiesto per ProcessMind: JournalEntryId, ActivityName, EventTime, UserName, ecc.
Esportare in CSV: salvi il DataFrame finale in un file CSV. Questo file può essere caricato direttamente su ProcessMind per l'analisi.

Configurazione

Credenziali: sono necessari un nome utente e una password validi di Oracle Fusion per l'autenticazione di base.
URL dell'istanza: l'URL di base dell'istanza di Oracle Fusion Financials è necessario per costruire l'endpoint API (ad es. https://[vostra-istanza].fa.us2.oraclecloud.com).
API Endpoint: lo script punta all'endpoint fscmRestApi/resources/11.13.18.05/journals per recuperare i dati della contabilità generale.
Filtro intervallo date: lo script deve essere configurato con una start_date e una end_date per limitare l'ambito dell'estrazione. Per un'analisi iniziale, si consiglia un periodo da 3 a 6 mesi. Per l'uso continuo, configurarlo per caricamenti incrementali giornalieri o settimanali.
Limite di paginazione: il parametro limit controlla il numero di record recuperati per ogni chiamata API. Un valore compreso tra 200 e 500 è solitamente efficiente, bilanciando il numero di chiamate API con la dimensione di ogni risposta.
Ruoli Oracle richiesti: l'account utente deve avere un ruolo con i privilegi necessari per leggere i dati del registro tramite l'API REST, come General Accountant o un ruolo personalizzato con autorizzazioni equivalenti.

a Query di Esempio python

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

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

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

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

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

    return all_journals

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

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

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

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

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

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

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

    return pd.DataFrame(event_log)

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

Fasi

Andare nell'area di lavoro Report e analisi: effettui il login in Oracle Fusion Financials. Utilizzi il menu Navigator per andare su Strumenti, quindi selezioni Report e analisi. Questo è l'hub centrale per la creazione e la gestione di tutte le analisi e i report.
Creare un modello dati BI Publisher: invece di iniziare con un'analisi OTBI, per questo tipo di estrazione di Event Log è più efficace creare direttamente un modello dati BI Publisher. Ciò consente di utilizzare una query SQL personalizzata con istruzioni UNION ALL. Clicchi sul pulsante 'Sfoglia catalogo', vada in una cartella adatta e scelga Crea > Modello dati.
Definire il dataset della query SQL: nell'editor del modello dati, clicchi sull'icona '+' per aggiungere un nuovo set di dati e selezioni 'Query SQL'. Assegni al dataset un nome descrittivo, ad esempio 'JournalEventLog'.
Inserire la query SQL: selezioni 'Oracle BI EE' come sorgente dati. Copi lo script SQL completo dalla sezione Query qui sotto e lo incolli nell'area di testo Query SQL. La query è progettata per estrarre tutte le attività e gli attributi richiesti in un'unica struttura unificata.
Definire i parametri: la query fornita utilizza parametri come :start_date, :end_date e :ledger_name. L'interfaccia del modello dati li rileverà automaticamente. Deve configurarli come parametri, impostando i tipi di dati appropriati (Data o Testo) e i valori predefiniti se necessario. Ciò consente un'esecuzione flessibile del report.
Creare un report dal modello dati: dopo aver salvato il modello dati, torni al catalogo. Clicchi su Crea > Report. Nella procedura guidata di creazione del report, selezioni 'Usa modello dati esistente' e individui il modello dati appena creato.
Configurare il layout del report: nell'editor del layout, scelga il layout 'Tabella'. È fondamentale trascinare tutte le colonne dal modello dati nella tabella per assicurarsi che siano incluse nell'esportazione. Non è necessaria una formattazione complessa.
Impostare l'output predefinito su CSV: vada al link 'Visualizza elenco' nell'editor del report. Nella sezione 'Formati di output', si assicuri che 'CSV' sia selezionato. Si consiglia di deselezionare tutti gli altri formati per semplificare la pianificazione. Salvi il report.
Pianificare il report per l'estrazione automatica: trovi il report salvato nel catalogo e clicchi su 'Altro', quindi su 'Pianifica'. Crei un nuovo job di pianificazione. Ne configuri la frequenza, ad esempio giornaliera o settimanale.
Configurare esportazione e consegna: nella scheda 'Output' del job di pianificazione, specifichi i dettagli dell'output. Selezioni il report e scelga 'CSV' come formato. Nella scheda 'Destinazione', può configurare la consegna del file in una posizione del server di contenuti (UCM) o in un server SFTP esterno per il recupero automatizzato.
Recuperare e preparare i dati: una volta eseguito il job pianificato, recuperi il file CSV generato dalla destinazione configurata. Si assicuri che le intestazioni delle colonne corrispondano ai requisiti per l'importazione in ProcessMind: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, ecc. Il file è ora pronto per il caricamento.

Configurazione

Sorgente dati: la query deve essere eseguita sulla sorgente dati 'Oracle BI EE' all'interno di BI Publisher, che si connette alle viste del database transazionale sottostante che supportano OTBI.
Aree tematiche chiave (per riferimento): la logica della query si basa su dati presenti principalmente nell'area tematica 'General Ledger - Journals Real Time'. Inoltre, unisce logicamente dati presenti in 'HCM - Workforce Management - Worker Assignment Real Time' per i dettagli dell'utente e potenzialmente aree tematiche di workflow per la cronologia delle approvazioni.
Filtro intervallo date: è fondamentale filtrare i dati in un intervallo gestibile. La query include i parametri :start_date e :end_date. Raccomandiamo di estrarre da 3 a 6 mesi di dati per un'analisi iniziale. Il filtro viene applicato alla data di creazione della scrittura.
Filtro Ledger: utilizzi il parametro :ledger_name per limitare l'estrazione a un ledger primario specifico. L'estrazione simultanea di tutti i ledger può causare file estremamente voluminosi e problemi di prestazioni.
Prerequisiti: l'utente che crea e pianifica il report deve disporre di ruoli BI appropriati, come 'BI Administrator' o 'BI Author'. Inoltre, il profilo di sicurezza dei dati dell'utente deve garantire l'accesso ai ledger e alle business unit oggetto della query.
Pianificazione: per prestazioni ottimali e per evitare impatti sugli utenti del sistema, pianifichi l'esecuzione dell'estrazione durante le ore non di punta, come la notte.

a Query di Esempio config

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

UNION ALL

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

Il Suo template di dati per Record to Report - Registrazioni contabili

Il Suo template di dati per Record to Report - Registrazioni contabili

Record to Report - Attributi registrazioni contabili

Record to Report - Attività registrazioni contabili

Guide all'Estrazione

Esportazione report Oracle OTBI e BI Publisher

Fasi

Configurazione

a Query di Esempio config

Report BI Publisher con query diretta al modello dati SQL

Fasi

Configurazione

a Query di Esempio sql

Script Python che utilizza le REST API di Oracle Fusion Financials

Fasi

Configurazione

a Query di Esempio python

Estrazione dati massiva tramite BI Cloud Connector (BICC)

Fasi

Configurazione

a Query di Esempio config

Pronto per iniziare?

Acceleri il ciclo Record to Report - Scritture Contabili oggi stesso

Il Suo template di dati per Record to Report - Registrazioni contabili

Il Suo template di dati per Record to Report - Registrazioni contabili

Record to Report - Attributi registrazioni contabili

Record to Report - Attività registrazioni contabili

Guide all'Estrazione

Esportazione report Oracle OTBI e BI Publisher

Fasi

Configurazione

a Query di Esempio config

Report BI Publisher con query diretta al modello dati SQL

Fasi

Configurazione

a Query di Esempio sql

Script Python che utilizza le REST API di Oracle Fusion Financials

Fasi

Configurazione

a Query di Esempio python

Estrazione dati massiva tramite BI Cloud Connector (BICC)

Fasi

Configurazione

a Query di Esempio config

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Acceleri il ciclo Record to Report - Scritture Contabili oggi stesso