> Miglioramento continuo dei processi > Acquisto pagamento Richiesta di acquisto > Oracle Fusion Financials > Template dei dati

Il Suo template dei dati per l’acquisto e il pagamento delle richieste

Oracle Fusion Financials

← Torna alla guida al miglioramento

Attributi del processo di acquisto e pagamento delle richieste(22) Attività del processo di acquisto e pagamento delle richieste(12) Guide all’estrazione(4)

Il Suo template dei dati per l’acquisto e il pagamento delle richieste

Questo template offre indicazioni chiare per raccogliere i dati essenziali necessari ad analizzare il processo di acquisto e pagamento delle richieste. Illustra gli attributi principali da acquisire, le attività da monitorare e le istruzioni pratiche per estrarre queste informazioni da Oracle Fusion Financials. Potrà così preparare l’Event Log per un’analisi efficace con il Process Mining.

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

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

Scarica il template

Attributi del processo di acquisto e pagamento delle richieste

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa del processo di acquisto e pagamento delle richieste.

5 Obbligatorio 7 Consigliato 10 Facoltativo

	Nome	Descrizione
	Attività ActivityName	Il nome dell’evento aziendale che si è verificato in un determinato momento del processo di richiesta.
Descrizione L’attività rappresenta una fase o una tappa specifica del ciclo di vita della richiesta d’acquisto. Alcuni esempi sono «Richiesta creata», «Fase di approvazione approvata» e «Ordine d’acquisto creato». Le attività vengono ricavate dalle modifiche di stato, dalle azioni degli utenti o dagli eventi di sistema registrati nei log di audit o nelle tabelle delle transazioni del sistema di origine. Questo attributo è essenziale per costruire la mappa di processo, che rappresenta visivamente il flusso delle richieste. Analizzare la sequenza e la frequenza delle attività aiuta a individuare i percorsi più comuni, i colli di bottiglia, i cicli di rilavorazione e le deviazioni dalla procedura standard. Perché è importante Costituisce la struttura portante della mappa di processo e consente di visualizzare e analizzare il flusso di lavoro delle richieste. Dove reperirli Ricavato dai record delle modifiche di stato in tabelle come POR_REQUISITION_HEADERS_ALL, dalla cronologia delle transazioni o dai log di audit del flusso di lavoro, come FA_FUSION_SOAINFRA.WFTASK. Esempi Richiesta di acquisto creataFase di approvazione approvataRichiesta di acquisto rifiutataOrdine di acquisto creato
	ID della richiesta di acquisto PurchaseRequisitionId	Identificativo univoco di una richiesta di acquisto, utilizzato come ID del caso nel processo.
Descrizione L’ID della richiesta d’acquisto è l’identificativo centrale che collega tutte le attività relative a una specifica richiesta di beni o servizi. A ogni richiesta viene assegnato un ID univoco al momento della creazione, che rimane invariato per tutto il suo ciclo di vita. Nel Process Mining, questo attributo viene utilizzato per raggruppare in un unico caso tutti gli eventi correlati, come la creazione, l’invio, le fasi di approvazione e la chiusura finale. In questo modo è possibile analizzare l’intero percorso della richiesta, visualizzare le mappe di processo, calcolare i tempi di ciclo e analizzare le varianti di ogni singola richiesta. Perché è importante È l’attributo fondamentale per monitorare il ciclo di vita di una richiesta dall’inizio alla fine e consente tutte le analisi a livello di caso e il calcolo dei KPI. Dove reperirli In genere è la chiave primaria della tabella di intestazione delle richieste, ad esempio POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID in Oracle Fusion Financials. Esempi 100234810023491002350
	Ora dell’evento EventTime	Il timestamp che indica quando si è verificata l’attività.
Descrizione L’ora dell’evento registra la data e l’ora esatte in cui si è svolta una specifica attività. Questo timestamp è fondamentale per ordinare cronologicamente gli eventi all’interno di un caso e proviene dalle date di creazione, dalle date dell’ultimo aggiornamento o dai timestamp associati a specifiche azioni nel sistema. Nelle analisi, l’ora dell’evento viene utilizzata per calcolare tutte le metriche basate sulla durata, come i tempi di ciclo tra le attività, i tempi di attesa e la durata complessiva del caso. È essenziale per individuare i colli di bottiglia, misurare le prestazioni rispetto agli SLA e comprendere le dinamiche temporali del processo di richiesta. Perché è importante Questo attributo è essenziale per calcolare tutti i KPI relativi ai tempi, ordinare correttamente gli eventi e analizzare le prestazioni del processo e i colli di bottiglia. Dove reperirli In genere proviene da una colonna LAST_UPDATE_DATE o CREATION_DATE associata alla transazione o alla modifica di stato, spesso presente in tabelle come POR_REQUISITION_HEADERS_ALL o nelle tabelle della cronologia del flusso di lavoro. Esempi 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	Sistema di origine SourceSystem	Il sistema informativo da cui sono stati estratti questi dati.
Descrizione Questo attributo identifica l’origine dei dati del processo. In questo modello di dati, il valore sarà sempre «Oracle Fusion Financials». Negli ambienti con più sistemi ERP o sistemi integrati, questo campo è fondamentale per ricostruire la provenienza dei dati, risolvere i problemi e garantirne la qualità. Fornisce il contesto sull’origine attendibile degli eventi di processo analizzati. Perché è importante Fornisce informazioni essenziali sull’origine dei dati, fondamentali per la governance dei dati e per l’integrazione di dati provenienti da più sistemi. Dove reperirli È un valore statico aggiunto durante l’estrazione e la trasformazione dei dati per indicare l’origine del set di dati. Esempi Oracle Fusion Financials
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp dell’aggiornamento più recente dei dati dal sistema di origine.
Descrizione Questo attributo indica la data e l’ora dell’ultima estrazione dei dati da Oracle Fusion Financials. Si riferisce all’intero set di dati, non ai singoli eventi. Gli analisti utilizzano questa informazione per valutare quanto siano aggiornati i dati e verificare quando sono state incluse le transazioni più recenti. È un metadato importante per i report delle Dashboard e per assicurarsi che le analisi si basino su informazioni aggiornate. Perché è importante Indica quanto sono recenti i dati, così da garantire che le analisi siano pertinenti e basate sulle informazioni più aggiornate disponibili. Dove reperirli Questo timestamp viene generato e memorizzato durante l’estrazione dei dati, in genere dallo strumento ETL o dalla pipeline di dati. Esempi 2023-10-27T02:00:00Z
	Data richiesta RequiredByDate	La data entro cui il richiedente ha bisogno dei beni o dei servizi.
Descrizione Il richiedente specifica questa data per indicare entro quando devono essere ricevuti gli articoli richiesti. Rappresenta l’obiettivo interno del livello di servizio (SLA) per il processo di approvvigionamento. Questo attributo è alla base della Dashboard «Prestazioni rispetto alla data richiesta» e del KPI «Tasso di rispetto della data richiesta». Confrontando questa data con la data effettiva di creazione dell’ordine d’acquisto o di ricezione dei beni, l’analisi mostra quanto il processo di approvvigionamento soddisfi le esigenze dei clienti interni e aiuta a individuare ritardi sistematici. Perché è importante È fondamentale per misurare le prestazioni del processo rispetto alle scadenze interne e capire se l’approvvigionamento soddisfa tempestivamente le esigenze aziendali. Dove reperirli Di solito è memorizzata a livello di riga della richiesta, in tabelle come POR_REQUISITION_LINES_ALL, in un campo quale NEED_BY_DATE. Esempi 2023-11-012023-12-152024-01-31
	Importo totale della richiesta RequisitionTotalAmount	Il valore monetario complessivo della richiesta d’acquisto.
Descrizione Questo attributo rappresenta la somma del valore di tutte le righe di una singola richiesta d’acquisto. È un dato fondamentale per comprendere il valore finanziario di ogni richiesta. Nel Process Mining, l’importo totale consente numerose analisi. Può essere utilizzato per filtrare le richieste di importo elevato, che spesso seguono percorsi di approvazione diversi o sono sottoposte a controlli più rigorosi. Le Dashboard possono utilizzare questo attributo per analizzare la correlazione tra il valore della richiesta e le metriche di processo, come il tempo di ciclo o il tasso di rifiuto. Perché è importante Fornisce il contesto finanziario necessario per analizzare i dati in base al valore, stabilire le priorità degli interventi di miglioramento e comprendere come l’importo della richiesta influisca sul processo. Dove reperirli Si trova nell’intestazione della richiesta, spesso in un campo come REQUISITION_TOTAL in POR_REQUISITION_HEADERS_ALL. In alternativa, può essere calcolato sommando gli importi delle righe in POR_REQUISITION_LINES_ALL. Esempi 550.0012500.7599.99
	Motivo del rifiuto RejectionReason	Il motivo indicato da un approvatore quando viene rifiutata una richiesta o una fase di approvazione.
Descrizione Quando una richiesta viene rifiutata, l’approvatore di solito ne indica il motivo, selezionandolo da un elenco predefinito oppure inserendo un testo libero. Questo attributo registra la motivazione. È un attributo fondamentale per analizzare le cause profonde dei problemi di processo. Supporta direttamente la Dashboard «Tendenze di modifiche e rifiuti», fornendo il motivo dei rifiuti. Analizzare le motivazioni aiuta a individuare problemi ricorrenti, come codici errati, superamenti del budget o violazioni delle policy, che possono essere affrontati con interventi di formazione o controlli di sistema. Perché è importante Mostra direttamente perché le richieste vengono rifiutate e consente di definire interventi mirati per ridurre le rilavorazioni e aumentare il tasso di elaborazione senza interventi manuali. Dove reperirli Ricavato dai commenti del flusso di lavoro o dai campi specifici dei codici motivo di rifiuto nel log di audit del flusso di lavoro, eventualmente nelle tabelle relative a FA_FUSION_SOAINFRA.WFTASK o nei relativi archivi dei commenti. Esempi Conto di contabilità generale erratoSupera il budget del centro di costoÈ stato selezionato un fornitore non preferenzialeRichiesta duplicata
	Nome del richiedente RequesterName	Il nome del dipendente che ha creato e inviato la richiesta d’acquisto.
Descrizione Questo attributo identifica la persona che ha avviato la richiesta di beni o servizi. In genere, l’informazione viene registrata all’inizio del processo, quando la richiesta viene creata. Analizzare le prestazioni del processo per richiedente è fondamentale per la Dashboard «Metriche delle prestazioni dei richiedenti». Aiuta a individuare gli utenti o i gruppi che potrebbero aver bisogno di ulteriore formazione, mettendo in evidenza un numero elevato di modifiche o rifiuti, oppure tempi di ciclo lunghi per le loro richieste. Offre una prospettiva del processo incentrata sulle persone. Perché è importante Consente di analizzare le prestazioni per richiedente, individuare le esigenze di formazione e mettere in evidenza gli utenti o i reparti più efficienti. Dove reperirli Ricavato dai dati dell’intestazione della richiesta, spesso collegando l’ID del richiedente a una tabella anagrafica dei dipendenti o degli utenti. Si cerchino i campi relativi a PREPARER_ID in POR_REQUISITION_HEADERS_ALL e si effettui il collegamento con PER_ALL_PEOPLE_F. Esempi John SmithJane DoeEmily Jones
	Reparto DepartmentName	Il reparto aziendale a cui appartiene il richiedente.
Descrizione Questo attributo indica l’unità organizzativa della persona che ha creato la richiesta, ad esempio «Finanza», «IT» o «Marketing». In genere viene ricavato dal profilo del richiedente nel sistema HR. L’analisi per reparto è un metodo comune ed efficace per segmentare i dati di processo. Aiuta a individuare comportamenti specifici dei reparti, come tassi di rifiuto più elevati o tempi di ciclo più lunghi, e a definire iniziative di miglioramento mirate. È una dimensione fondamentale per la Dashboard «Metriche delle prestazioni dei richiedenti». Perché è importante Consente di segmentare l’analisi per unità aziendale, mettendo in luce modelli, prestazioni e problemi di conformità specifici dei reparti. Dove reperirli In genere viene ricavato dal profilo del richiedente, collegando la tabella delle richieste a una tabella HR o a una directory utenti che contiene le informazioni sui reparti. Esempi Tecnologie dell’informazioneFinanzaOperazioniMarketing
	Stato della richiesta RequisitionStatus	Lo stato attuale o finale della richiesta d’acquisto.
Descrizione Questo attributo indica lo stato complessivo della richiesta in un determinato momento o il suo esito finale, ad esempio «Approvata», «Rifiutata», «In elaborazione» o «Chiusa». Spesso è la fonte da cui vengono ricavate molte attività dell’Event Log. Questo attributo è fondamentale per la Dashboard «Panoramica dello stato delle richieste», che offre una fotografia del carico di lavoro e delle richieste arretrate. Viene inoltre utilizzato per calcolare i KPI basati sull’esito, come il tasso di rifiuto delle richieste, filtrando i casi che terminano con uno stato specifico. Perché è importante Fornisce una fotografia dello stato attuale delle richieste e consente di determinare gli esiti finali per il calcolo dei KPI. Dove reperirli Si trova nella tabella di intestazione della richiesta, in genere in un campo come DOCUMENT_STATUS o APPROVAL_STATUS in POR_REQUISITION_HEADERS_ALL. Esempi APPROVATAIN ELABORAZIONERIFIUTATARITIRATA
	Unità aziendale BusinessUnit	L’unità aziendale specifica dell’organizzazione a cui appartiene la richiesta.
Descrizione L’unità aziendale rappresenta un’entità legale o funzionale distinta dell’azienda per conto della quale viene effettuata la richiesta. È un raggruppamento organizzativo di livello superiore rispetto al reparto. L’analisi dei dati per unità aziendale consente di confrontare le prestazioni delle diverse aree dell’organizzazione a un livello più ampio. Aiuta la direzione a capire se le inefficienze del processo sono circoscritte o diffuse e dove concentrare gli interventi di miglioramento. È una dimensione fondamentale per filtrare quasi tutte le Dashboard e i KPI. Perché è importante Fornisce un contesto organizzativo di alto livello e consente di confrontare le prestazioni e condurre analisi strategiche tra le diverse aree dell’azienda. Dove reperirli È un campo organizzativo fondamentale in Oracle Fusion, in genere disponibile nell’intestazione della richiesta in tabelle come POR_REQUISITION_HEADERS_ALL. Esempi Unità aziendale Nord AmericaUnità aziendale EuropaSede centrale
	Automatizzata IsAutomated	Indicatore che segnala se un’attività è stata eseguita automaticamente dal sistema.
Descrizione Questo attributo identifica gli eventi del processo eseguiti da un utente di sistema o da un agente automatizzato anziché da una persona. Alcuni esempi sono le modifiche di stato avviate dal sistema o le fasi di approvazione automatizzate per gli articoli di importo ridotto. Analizzare questo attributo aiuta a quantificare il livello di automazione del processo. Può essere utilizzato per confrontare la velocità e l’efficienza delle fasi automatizzate con quelle manuali e individuare ulteriori opportunità di automazione. Perché è importante Aiuta a misurare il livello di automazione del processo e a individuare le attività manuali che potrebbero essere automatizzate. Dove reperirli Ricavato verificando se l’utente associato a un’attività è un account di sistema o di servizio. A tal fine è necessario disporre di un elenco degli ID utente di sistema noti. Esempi truefalse
	Descrizione dell’articolo ItemDescription	La descrizione del prodotto o servizio richiesto in una riga della richiesta.
Descrizione Questo attributo contiene la descrizione testuale dell’articolo da acquistare e fornisce dettagli specifici sui beni o servizi richiesti. Anche se spesso non è strutturata, la descrizione dell’articolo offre un contesto utile per l’analisi. Può essere utilizzata nei filtri per isolare richieste relative a specifici tipi di acquisto che potrebbero non essere identificati dal tipo di richiesta. Ad esempio, un analista può cercare tutte le richieste che contengono «Licenza software» per comprenderne il flusso di processo e il tempo di ciclo. Perché è importante Fornisce informazioni dettagliate sugli articoli acquistati e consente di filtrare e analizzare con maggiore precisione specifici beni o servizi. Dove reperirli Si trova nella tabella delle righe della richiesta, POR_REQUISITION_LINES_ALL, in un campo come ITEM_DESCRIPTION. Esempi Portatile da 15 pollici, 16 GB di RAMServizi di consulenza - progetto del quarto trimestreRinnovo annuale della manutenzione software
	È stata modificata IsAmendedFlag	Indicatore booleano che vale true se la richiesta è stata modificata almeno una volta.
Descrizione Questo attributo calcolato indica se una richiesta è stata modificata dopo l’invio iniziale. Viene ricavato verificando la presenza dell’attività «Richiesta modificata» nella cronologia del caso. L’indicatore semplifica le analisi e il calcolo dei KPI. Viene utilizzato direttamente per calcolare il KPI «Tasso di modifica delle richieste» e individuare i casi che non sono stati elaborati senza interventi manuali. Consente di filtrare e confrontare facilmente le metriche di processo tra richieste modificate e non modificate. Perché è importante Semplifica il calcolo del tasso di modifica e consente di confrontare facilmente le richieste modificate con quelle non modificate. Dove reperirli Questo attributo non è presente nel sistema di origine, ma viene calcolato durante la trasformazione dei dati in base alla presenza di attività di modifica nell’Event Log. Esempi truefalse
	Elaborata senza interventi manuali IsStraightThrough	Indicatore che segnala se la richiesta è stata approvata senza modifiche o rifiuti.
Descrizione Questo indicatore calcolato identifica le richieste che hanno attraversato il processo dall’invio all’approvazione senza cicli di rilavorazione, come modifiche o rifiuti. Segnala che il processo è stato completato correttamente per un singolo caso. Questo attributo è alla base del KPI «Tasso di richieste elaborate senza interventi manuali». Analizzare le caratteristiche di queste richieste, ad esempio i reparti, i richiedenti o i tipi più comuni, può rivelare buone pratiche e opportunità di automazione. Al contrario, analizzare le richieste che hanno richiesto interventi aiuta a individuare le principali cause di inefficienza. Perché è importante Misura direttamente l’efficienza del processo ed è alla base del KPI «Tasso di richieste elaborate senza interventi manuali», aiutando a individuare le cause delle rilavorazioni. Dove reperirli Questo attributo viene calcolato durante la trasformazione dei dati. Il caso è contrassegnato come true se non sono presenti attività «Richiesta modificata» o «Fase di approvazione rifiutata». Esempi truefalse
	Nome del fornitore SupplierName	Il nome del fornitore suggerito o preselezionato per i beni o servizi.
Descrizione Questo attributo identifica il fornitore da cui si intendono acquistare i beni o i servizi. Il fornitore può essere suggerito dal richiedente oppure individuato dal sistema in base ai cataloghi o agli accordi precedenti. L’analisi per fornitore può rivelare importanti tendenze negli approvvigionamenti. Ad esempio, aiuta a capire se le richieste relative a determinati fornitori richiedono più tempo per essere approvate o presentano tassi di rifiuto più elevati. Queste informazioni possono essere utili per la gestione dei rapporti con i fornitori e per definire la strategia di approvvigionamento. Perché è importante Consente di analizzare le prestazioni del processo per fornitore e può contribuire a definire la strategia di approvvigionamento e a gestire i rapporti con i fornitori. Dove reperirli Si trova nella tabella delle righe della richiesta, POR_REQUISITION_LINES_ALL, spesso collegata tramite VENDOR_ID a una tabella anagrafica dei fornitori come POZ_SUPPLIERS. Esempi Office Supplies Inc.Global Tech SolutionsCreative Marketing Agency
	Nome utente UserName	Il nome dell’utente che ha eseguito una specifica attività, ad esempio un approvatore o una persona che ha apportato una modifica.
Descrizione Mentre il nome del richiedente identifica chi ha avviato la richiesta, il nome utente indica la persona che ha eseguito un determinato evento del processo, come un’approvazione o un rifiuto. È particolarmente importante nei flussi di lavoro con più fasi di approvazione, in cui intervengono persone diverse. Questo attributo è fondamentale per analizzare i colli di bottiglia nelle approvazioni e misurare le prestazioni di specifici approvatori o team. Supporta direttamente la Dashboard «Colli di bottiglia nel flusso di lavoro di approvazione», consentendo di analizzare i tempi di elaborazione per ogni utente coinvolto nella catena di approvazione. Perché è importante Identifica chi ha eseguito ciascun evento, un’informazione essenziale per analizzare i tempi di passaggio di consegne, le prestazioni degli approvatori e l’allocazione delle risorse. Dove reperirli Ricavato dalla cronologia del flusso di lavoro o dalle tabelle dei log di audit, come FA_FUSION_SOAINFRA.WFTASK, che registra l’utente associato al completamento di ogni attività. Esempi David LeeSusan ChenMichael Brown
	Numero dell’ordine d’acquisto PurchaseOrderNumber	L’identificativo dell’ordine d’acquisto creato a partire dalla richiesta approvata.
Descrizione Questo attributo collega una richiesta d’acquisto all’ordine d’acquisto che ne deriva. Una volta approvata completamente, la richiesta viene in genere convertita in uno o più ordini d’acquisto da inviare al fornitore. Nelle analisi, questo ID è essenziale per monitorare le fasi successive alla richiesta. Consente di calcolare il KPI «Tempo di attraversamento dalla richiesta all’ordine d’acquisto» e supporta la Dashboard «Tempo di ciclo dalla richiesta all’ordine d’acquisto». Permette inoltre di combinare i dati del processo di richiesta con quelli dei successivi processi relativi agli ordini d’acquisto e alla fatturazione, per un’analisi completa del processo Procure-to-Pay. Perché è importante Collega la richiesta al successivo ordine d’acquisto, consentendo di misurare il tempo di ciclo tra i due e di analizzare il processo dall’inizio alla fine. Dove reperirli Questa informazione viene memorizzata quando viene creato un ordine d’acquisto. In genere si trova nei riferimenti alla richiesta originaria nelle tabelle di distribuzione dell’ordine, come PO_DISTRIBUTIONS_ALL, che rimanda alla riga della richiesta. Esempi PO-2023-5832PO-2023-5833PO-2023-5834
	Percorso di approvazione ApprovalWorkflowPath	La sequenza predefinita di approvatori o gruppi di approvazione richiesta per la richiesta.
Descrizione Questo attributo definisce il processo di approvazione standard previsto per una richiesta in base alle policy aziendali e a fattori quali l’importo, il tipo e il reparto. Rappresenta il modello di processo previsto. Il percorso di approvazione è fondamentale per la conformità e l’analisi della conformità. Supporta direttamente la Dashboard «Analisi della conformità e delle deviazioni» e il KPI «Indice di conformità delle richieste», consentendo di confrontare le fasi di approvazione effettivamente svolte con il percorso prescritto. Le deviazioni possono indicare violazioni delle policy o inefficienze del processo. Perché è importante Consente il controllo di conformità confrontando il flusso effettivo del processo con la gerarchia di approvazione prevista e mettendo in evidenza le richieste non conformi. Dove reperirli Questa informazione è configurata in Oracle Fusion BPM Worklist o nell’Approval Management Engine (AMX). Estrarre il percorso definito per ogni richiesta può essere complesso e potrebbe richiedere l’interrogazione delle tabelle di configurazione. Esempi Responsabile > Direttore > Vicepresidente FinanzaResponsabile del centro di costo > Sicurezza ITResponsabile > Responsabile di reparto
	Tipo di richiesta RequisitionType	La categoria della richiesta, ad esempio una richiesta di beni o servizi.
Descrizione Questo attributo classifica la richiesta in base a ciò che viene richiesto. Tra le tipologie più comuni figurano beni, servizi e spese in conto capitale. Il tipo può influire sul flusso di lavoro di approvazione richiesto e sulla strategia di approvvigionamento. Nelle analisi, il tipo di richiesta è una dimensione utile per filtrare e confrontare i dati. Ad esempio, è possibile verificare se le richieste di servizi richiedono tempi di ciclo di approvazione più lunghi rispetto a quelle di beni. Aiuta a capire se i diversi tipi di richiesta presentano comportamenti o colli di bottiglia differenti. Perché è importante Consente di segmentare l’analisi per capire come varia il processo in base al tipo di acquisto, ad esempio tra beni e servizi. Dove reperirli Spesso viene determinato dal tipo o dalla categoria della riga selezionati al momento della creazione della richiesta. Può essere memorizzato nella tabella delle righe della richiesta, POR_REQUISITION_LINES_ALL. Esempi BeniServiziSpesa in conto capitale
	Valuta CurrencyCode	Il codice della valuta dell’importo della richiesta, ad esempio USD o EUR.
Descrizione Questo attributo specifica la valuta in cui è espresso l’importo totale della richiesta. Nelle organizzazioni globali, le richieste possono essere create in valute diverse. È essenziale per interpretare e aggregare correttamente i dati finanziari. In ogni analisi che include valori monetari, occorre utilizzare il codice della valuta per confrontare gli importi in modo accurato, filtrando una singola valuta oppure convertendo tutti gli importi in una valuta comune. Perché è importante Garantisce l’accuratezza delle analisi e dei report finanziari, soprattutto nelle organizzazioni multinazionali che utilizzano più valute. Dove reperirli In genere si trova nella tabella di intestazione della richiesta, insieme ai campi relativi agli importi, ad esempio in POR_REQUISITION_HEADERS_ALL. Esempi USDEURGBPJPY

Obbligatorio Consigliato Facoltativo

Attività del processo di acquisto e pagamento delle richieste

Questi sono i passaggi e le tappe fondamentali da registrare nell’Event Log per individuare con precisione il processo di acquisto e pagamento delle richieste.

6 Consigliato 6 Facoltativo

	Attività	Descrizione
	Ordine di acquisto creato	Questo evento si verifica quando una riga di richiesta approvata viene utilizzata per generare un ordine di acquisto. Collega il processo delle richieste alla successiva fase di acquisto.
Perché è importante È una tappa fondamentale per misurare il tempo di attraversamento dalla richiesta all’ordine di acquisto. I ritardi in questa fase segnalano colli di bottiglia nel passaggio dall’approvazione agli acquisti. Dove reperirli Si tratta di un evento esplicito. Il collegamento tra la richiesta e l’ordine di acquisto è registrato in tabelle come PO_LINE_LOCATIONS_ALL, che contiene un riferimento all’ID della riga di richiesta di origine. Acquisizione Individui la data di creazione dell’ordine di acquisto che fa riferimento all’ID richiesta in questione. Tipo di evento explicit
	Richiesta di acquisto approvata	Segna l’approvazione finale della richiesta di acquisto, dopo il completamento di tutte le fasi del flusso di lavoro. Si deduce quando lo stato complessivo della richiesta passa a 'Approved'.
Perché è importante È una tappa fondamentale: indica che la richiesta è pronta per avviare l’acquisto e segna la fine del periodo da misurare per calcolare il tempo totale del ciclo di approvazione. Dove reperirli Si deduce quando il campo dello stato del documento nella tabella POR_REQUISITION_HEADERS_ALL passa a 'APPROVED'. La data e l’ora di questa variazione costituiscono il momento dell’evento. Acquisizione Individui la data e l’ora in cui lo stato del documento viene impostato per la prima volta su 'Approved'. Tipo di evento inferred
	Richiesta di acquisto chiusa	Indica la chiusura definitiva del ciclo di vita della richiesta: tutte le righe sono state evase, ad esempio convertendole in ordini di acquisto, oppure annullate. Si deduce da un aggiornamento finale dello stato.
Perché è importante È il principale evento di conclusione positiva del processo. Conferma che la richiesta è stata elaborata completamente e che non sono necessarie altre azioni. Dove reperirli Si deduce quando lo stato dell’intestazione della richiesta nella tabella POR_REQUISITION_HEADERS_ALL passa a 'CLOSED'. Acquisizione Individui la data e l’ora in cui lo stato del documento della richiesta passa a 'Closed'. Tipo di evento inferred
	Richiesta di acquisto creata	Segna l’avvio del processo di acquisto, quando un utente salva per la prima volta una nuova richiesta di acquisto. In genere, l’evento viene registrato esplicitamente nel sistema con la relativa data e ora di creazione.
Perché è importante È l’evento iniziale principale del processo delle richieste. Analizzare il tempo che intercorre tra la creazione e l’invio può far emergere ritardi nella formalizzazione della richiesta. Dove reperirli L’evento è registrato nella tabella POR_REQUISITION_HEADERS_ALL e viene rilevato dalla colonna creation_date quando viene generato un nuovo ID richiesta. Acquisizione Utilizzi la data e l’ora di creazione del record di intestazione della richiesta. Tipo di evento explicit
	Richiesta di acquisto inviata	Rappresenta l’azione con cui l’utente invia la richiesta completata al flusso di lavoro di approvazione. L’evento viene rilevato quando lo stato della richiesta passa da 'Incompleta' o 'Bozza' a uno stato che indica che è in attesa di approvazione.
Perché è importante Questa attività avvia il ciclo di approvazione. È una tappa fondamentale per misurare il tempo di ciclo di approvazione della richiesta e i tempi di attraversamento complessivi. Dove reperirli Si deduce da una variazione di stato nella tabella POR_REQUISITION_HEADERS_ALL, ad esempio quando lo stato diventa 'PENDING APPROVAL'. Spesso è disponibile anche la data di invio esplicita. Acquisizione Individui la data e l’ora in cui il campo dello stato del documento passa per la prima volta a 'Pending Approval'. Tipo di evento inferred
	Richiesta di acquisto rifiutata	Rappresenta il rifiuto definitivo della richiesta, che conclude il processo per questa richiesta. Si deduce quando lo stato complessivo viene aggiornato a 'Rejected'.
Perché è importante Questa attività segna la conclusione di una richiesta non andata a buon fine. Analizzare questi casi è essenziale per comprendere il KPI del tasso di rifiuto delle richieste e le ragioni dei mancati esiti. Dove reperirli Si deduce quando lo stato del documento nella tabella POR_REQUISITION_HEADERS_ALL passa a 'REJECTED'. Acquisizione Individui la data e l’ora in cui lo stato del documento viene impostato per la prima volta su 'Rejected'. Tipo di evento inferred
	Fase di approvazione approvata	Rappresenta l’azione con cui un singolo approvatore approva la richiesta nella fase assegnatagli del flusso di lavoro. L’evento è registrato esplicitamente nella cronologia delle approvazioni.
Perché è importante Monitorare le singole fasi di approvazione aiuta a ricostruire il percorso effettivo e a misurare il tempo di elaborazione in ogni livello della gerarchia. Dove reperirli Si rileva dalla cronologia delle azioni di approvazione della richiesta, generalmente conservata nelle tabelle del flusso di lavoro (WF) o di Human Capital Management (HCM) che gestiscono le gerarchie di approvazione. Acquisizione Utilizzi la data e l’ora dell’azione 'APPROVE' nel registro della cronologia delle azioni del flusso di lavoro. Tipo di evento explicit
	Fase di approvazione avviata	Segna il momento in cui una richiesta viene assegnata a uno specifico approvatore o gruppo di approvazione nel flusso di lavoro. L’evento viene rilevato dal registro delle transazioni del motore del flusso di lavoro.
Perché è importante Questa attività è essenziale per calcolare il tempo di attesa di ogni fase di approvazione. Aiuta a individuare i colli di bottiglia causati da specifici approvatori o livelli di approvazione. Dove reperirli Si recupera dalle tabelle del flusso di lavoro di Oracle Fusion, che registrano le attività assegnate agli utenti. Si utilizza la data e l’ora di assegnazione dell’attività di approvazione. Acquisizione Utilizzi la data e l’ora di creazione dell’attività nella cronologia del flusso di lavoro per la richiesta in questione. Tipo di evento explicit
	Fase di approvazione rifiutata	Un approvatore rifiuta la richiesta, che di norma viene rinviata a chi l’ha preparata per le correzioni oppure viene chiusa. L’azione è registrata esplicitamente nella cronologia del flusso di lavoro.
Perché è importante Questa attività è una delle principali cause di rilavorazioni e ritardi. Analizzare i rifiuti aiuta a individuare problemi di conformità, di budget o motivazioni poco chiare. Dove reperirli Si rileva dalla cronologia delle azioni di approvazione della richiesta. Il sistema del flusso di lavoro registra un’azione 'REJECT' con la relativa data e ora. Acquisizione Utilizzi la data e l’ora dell’azione 'REJECT' nel registro della cronologia delle azioni del flusso di lavoro. Tipo di evento explicit
	Fase di approvazione rinviata	Un approvatore rinvia la richiesta a chi l’ha preparata per ottenere ulteriori informazioni o apportare correzioni minori, senza rifiutarla formalmente. Di solito si tratta di un’azione esplicita nel sistema del flusso di lavoro.
Perché è importante Questo evento segnala la necessità di chiarimenti e crea un ciclo di rilavorazione che allunga il tempo di ciclo. Distinguere i rinvii dai rifiuti offre una visione più approfondita degli ostacoli nel processo. Dove reperirli Si rileva dalla cronologia delle azioni di approvazione della richiesta. Il sistema del flusso di lavoro registra un’azione 'RETURN' o equivalente con la relativa data e ora. Acquisizione Utilizzi la data e l’ora dell’azione 'RETURN' o 'Request for Information' nella cronologia del flusso di lavoro. Tipo di evento explicit
	Richiesta di acquisto modificata	Questo evento indica che un utente ha modificato una richiesta dopo il primo invio, spesso rendendo necessario riavviare il processo di approvazione. Si deduce rilevando modifiche ai campi dati principali o la creazione di una nuova versione della richiesta.
Perché è importante Modifiche frequenti indicano problemi di qualità dei dati o requisiti in evoluzione, che comportano rilavorazioni e ritardi. Questo indicatore contribuisce direttamente al KPI 'Tasso di modifica delle richieste'. Dove reperirli Si deduce monitorando i numeri di versione della richiesta o rilevando il ritorno allo stato 'Incomplete' dopo l’invio. Anche i registri delle modifiche o le tabelle di audit possono contenere queste informazioni. Acquisizione Individui le date e le ore di creazione di nuove versioni per lo stesso ID richiesta dopo il suo invio. Tipo di evento inferred
	Richiesta di acquisto ritirata	Si verifica quando il richiedente annulla o ritira una richiesta inviata prima che sia stata approvata completamente. Di solito si tratta di un’azione esplicita dell’utente che comporta una variazione di stato.
Perché è importante Monitorare i ritiri aiuta a individuare le ragioni dell’interruzione anticipata, come un cambiamento delle esigenze aziendali o la correzione di errori da parte degli utenti dopo l’invio. Dove reperirli Si deduce dalla variazione dello stato a 'WITHDRAWN' nella tabella POR_REQUISITION_HEADERS_ALL. L’azione è registrata nella cronologia delle azioni della richiesta. Acquisizione Rilevi la data e l’ora in cui lo stato della richiesta viene aggiornato a 'Withdrawn'. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Oracle Fusion Financials

Passaggi

Acceda a Reports and Analytics: acceda a Oracle Fusion Financials. Dal menu Navigator, apra Tools e selezioni Reports and Analytics. Questa è l’area centrale per tutte le attività di reporting.
Crei una nuova analisi: nell’area di lavoro Reports and Analytics, faccia clic sul pulsante 'Create' e selezioni 'Analysis' dal menu a discesa. Si aprirà in una nuova scheda l’editor di analisi Oracle Transactional Business Intelligence (OTBI).
Selezioni l’area tematica: Le verrà chiesto di selezionare un’area tematica. Nella casella di ricerca, digiti 'Procurement - Requisitions Real Time' e la selezioni dall’elenco. Quest’area contiene tutti i dati necessari sugli eventi del ciclo di vita delle richieste.
Crei l’analisi degli eventi delle richieste: in questo passaggio occorre combinare più query per acquisire ciascun evento distinto. Poiché l’interfaccia OTBI non dispone di una funzione UNION ALL diretta per tipi di evento diversi, crei un unico report che includa tutti i campi pertinenti relativi a date e stati. Nella scheda 'Criteria', trascini le colonne indicate nella sezione delle query dal riquadro 'Subject Areas' a sinistra all’area 'Selected Columns'. Includa le colonne relative, ad esempio, alla data di creazione, di invio, di approvazione e di creazione dell’ordine di acquisto.
Aggiunga la cronologia delle azioni sulle richieste: per acquisire i dettagli delle fasi di approvazione (Approved, Rejected, Returned, Withdrawn), includa i campi della cartella 'Requisition Action History' nell’area tematica. Trascini 'Action Date', 'Action' e 'Performer' tra le colonne selezionate.
Configuri i filtri: passi alla scheda 'Prompts' per creare i filtri dell’analisi. È essenziale impostare un intervallo di date per gestire il volume dei dati. Crei un filtro su 'Requisition Header'.'Requisition Creation Date' e imposti un intervallo, ad esempio gli ultimi 6 mesi. Può anche aggiungere prompt per 'Business Unit' o 'Requester Name' per restringere i dati.
Esegua e riveda il report: apra la scheda 'Results' per eseguire l’analisi e visualizzare un’anteprima dei dati. Il risultato sarà una tabella in formato «wide», con una riga per ogni riga della richiesta o azione di approvazione e più colonne relative a date e stati.
Esporti i dati grezzi: dopo aver verificato l’anteprima, faccia clic sul collegamento 'Export', in genere in fondo alla pagina dei risultati. Scelga 'Data' > 'CSV File' come formato. Verranno scaricati i dati grezzi dell’analisi.
Trasformi i dati nel formato Event Log: il file CSV esportato avrà un formato «wide». Per trasformare i dati, utilizzi uno strumento esterno, ad esempio uno script Python, Power Query in Excel o un altro strumento di preparazione dei dati. Occorre trasformare le colonne delle date in un’unica colonna 'EventTime' e creare una colonna 'ActivityName' corrispondente per ogni tipo di evento, ad esempio 'Requisition Created' e 'Requisition Submitted'.
Completi la preparazione per il caricamento: dopo la trasformazione, verifichi che il file contenga le colonne richieste: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate. Salvi l’Event Log finale in formato CSV, pronto per essere caricato in ProcessMind.

Configurazione

Area tematica: l’area tematica principale da utilizzare è 'Procurement - Requisitions Real Time'. Contiene le informazioni essenziali sulle intestazioni e sulle righe delle richieste, sulle distribuzioni e sulla cronologia delle approvazioni.
Intervallo di date: applichi sempre un filtro obbligatorio sulle date per limitare il volume dei dati e migliorare le prestazioni. Un buon punto di partenza è filtrare 'Requisition Header'.'Requisition Creation Date' sugli ultimi 3-6 mesi.
Filtri principali: valuti l’aggiunta di filtri per 'Requisition Header'.'Business Unit' e 'Requisition Header'.'Requisition Status', così da concentrarsi sulle unità organizzative pertinenti ed escludere stati non rilevanti, come 'Canceled', se non necessari per l’analisi.
Selezione delle colonne: scelga con attenzione le colonne da includere nell’analisi. Un numero eccessivo di colonne, soprattutto se provenienti da molte cartelle (dimensioni) diverse, può ridurre le prestazioni. Si limiti ai campi necessari per l’Event Log.
Autorizzazioni: l’utente che esegue l’estrazione deve avere un ruolo con le autorizzazioni necessarie per accedere all’area di lavoro Reports and Analytics e all’area tematica 'Procurement - Requisitions Real Time'. In genere, ruoli come 'BI Author' o 'Procurement Analyst' dispongono di questi privilegi.

Query di esempio sql

/*
OTBI analyses are built visually, not with SQL. This conceptual query illustrates the logic required to extract the data for all specified activities. The user would build an analysis containing these fields and then transform the output into an event log.
*/

-- 1. Requisition Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Created' AS ActivityName,
  "Requisition Header"."Requisition Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Creation Date" IS NOT NULL

UNION ALL

-- 2. Requisition Submitted
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Submitted' AS ActivityName,
  "Requisition Header"."Submitted Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Submitted Date" IS NOT NULL

UNION ALL

-- 3, 5, 6, 7, 8. Approval History Events (Withdrawn, Started, Approved, Rejected, Returned)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  CASE "Requisition Action History"."Action"
    WHEN 'WITHDRAW' THEN 'Requisition Withdrawn'
    WHEN 'SUBMIT' THEN 'Approval Step Started' -- Assumes submit action assigns to first approver
    WHEN 'APPROVE' THEN 'Approval Step Approved'
    WHEN 'REJECT' THEN 'Approval Step Rejected'
    WHEN 'RETURN' THEN 'Approval Step Returned'
  END AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  CASE WHEN "Requisition Action History"."Action" = 'REJECT' THEN "Requisition Action History"."Action Note" ELSE NULL END AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Action History"."Action" IN ('WITHDRAW', 'SUBMIT', 'APPROVE', 'REJECT', 'RETURN')

UNION ALL

-- 4. Requisition Amended
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Amended' AS ActivityName,
  "Requisition Header"."Last Update Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Version" > 1 AND "Requisition Header"."Last Update Date" > "Requisition Header"."Submitted Date"

UNION ALL

-- 9. Requisition Approved (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Approved' AS ActivityName,
  "Requisition Header"."Approved Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'APPROVED'
AND "Requisition Header"."Approved Date" IS NOT NULL

UNION ALL

-- 10. Requisition Rejected (Final)
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Rejected' AS ActivityName,
  "Requisition Action History"."Action Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  "Requisition Action History"."Action Note" AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Header"."Requisition Status" = 'REJECTED'
AND "Requisition Action History"."Action" = 'REJECT'
AND "Requisition Action History"."Sequence Number" = (SELECT MAX(T2."Sequence Number") FROM "Procurement - Requisitions Real Time" T2 WHERE T2."Requisition Header"."Requisition Number" = "Requisition Header"."Requisition Number")

UNION ALL

-- 11. Purchase Order Created
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Purchase Order Created' AS ActivityName,
  "Purchase Order Schedule"."PO Creation Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Purchase Order Schedule"."PO Creation Date" IS NOT NULL

UNION ALL

-- 12. Requisition Closed
SELECT 
  "Requisition Header"."Requisition Number" AS PurchaseRequisitionId,
  'Requisition Closed' AS ActivityName,
  "Requisition Line"."Line Close Date" AS EventTime,
  'Oracle Fusion Financials OTBI' AS SourceSystem,
  CURRENT_TIMESTAMP AS LastDataUpdate,
  "Requisition Distribution"."Requester Name" AS RequesterName,
  "Requisition Distribution"."Requester Department" AS DepartmentName,
  "Requisition Header"."Total" AS RequisitionTotalAmount,
  "Requisition Header"."Requisition Status" AS RequisitionStatus,
  "Requisition Line"."Need By Date" AS RequiredByDate,
  NULL AS RejectionReason,
  "Requisition Header"."Business Unit" AS BusinessUnit
FROM "Procurement - Requisitions Real Time"
WHERE "Requisition Line"."Line Close Date" IS NOT NULL AND "Requisition Line"."Line Status" = 'CLOSED'

Passaggi

Acceda a Oracle Fusion Financials con un utente che disponga del ruolo BI Author o di privilegi equivalenti.
Apra l’area di lavoro Reports and Analytics facendo clic sull’icona Navigator, quindi selezioni Tools > Reports and Analytics.
Faccia clic sul pulsante "Browse Catalog" per aprire il catalogo di Business Intelligence Publisher.
Nell’interfaccia di BI Publisher, faccia clic su "New" e selezioni "Data Model" dal menu a discesa.
Nelle proprietà del Data Model, può inserire un nome e una descrizione. Faccia clic sull’icona "+" per aggiungere un Data Set e selezioni "SQL Query".
Nella finestra di dialogo del nuovo Data Set, inserisca un nome, ad esempio Requisition_Event_Log, selezioni l’Origine dei dati appropriata per i dati Financials, ad esempio ApplicationDB_FSCM, e imposti Type of SQL su "Standard SQL".
Copi lo script SQL completo dalla sezione "query" di questo documento e lo incolli nell’area di testo SQL Query.
La query include i parametri :p_start_date e :p_end_date, che BI Publisher riconosce automaticamente. Se lo desidera, può impostare valori predefiniti.
Salvi il Data Model in una cartella appropriata del catalogo, ad esempio Shared Folders/Custom.
Per esportare i dati, torni al catalogo, faccia clic su "New" e selezioni "Report". Colleghi il nuovo report al Data Model appena creato.
Esegua il report specificando i parametri di data iniziale e finale. Quando i dati vengono visualizzati, utilizzi la funzione "Export" per scaricare i risultati in formato CSV.
Verifichi che il file CSV finale sia salvato con codifica UTF-8 e contenga le intestazioni richieste per l’importazione nello strumento di Process Mining.

Configurazione

Origine dei dati: l’Origine dei dati di BI Publisher, in genere denominata 'ApplicationDB_FSCM' o simile, deve essere configurata con un utente che disponga dell’accesso in lettura a tutte le tabelle utilizzate nella query, comprese quelle di Procurement (POR, PO), Human Capital Management (PER, HR) e Financials (FUN).
Filtro per intervallo di date: la query prevede i parametri obbligatori per le date (:p_start_date e :p_end_date), che filtrano i dati in base alla data di creazione della richiesta. Per le prime estrazioni o nei sistemi di grandi dimensioni, è fondamentale estrarre i dati in intervalli gestibili, ad esempio 3-6 mesi alla volta, per evitare timeout del sistema.
Filtro per unità aziendale: nella clausola WHERE della query è presente una sezione commentata con un filtro per il nome dell’unità aziendale. Si consiglia vivamente di rimuovere i commenti e configurare questo filtro per limitare i dati alle unità aziendali pertinenti all’analisi, migliorando sensibilmente le prestazioni.
Prerequisiti: l’utente che crea ed esegue il report deve disporre di un ruolo con privilegi BI Publisher, ad esempio 'BI Administrator Role' o 'BI Author Role'. Deve inoltre avere le autorizzazioni di sicurezza sui dati necessarie per accedere ai dati degli acquisti.

Query di esempio sql

WITH BaseRequisitions AS (
    SELECT
        PRH.REQUISITION_HEADER_ID,
        PRH.REQUISITION_NUMBER,
        PRH.CREATION_DATE,
        PRH.LAST_UPDATE_DATE AS HEADER_LAST_UPDATE_DATE,
        PRH.DOCUMENT_STATUS,
        PRH.PREPARER_ID,
        PPNF_REQ.DISPLAY_NAME AS RequesterName,
        HOU.NAME AS DepartmentName,
        BU.BU_NAME AS BusinessUnit,
        SUM(PRL.AMOUNT) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequisitionTotalAmount,
        MIN(PRL.NEED_BY_DATE) OVER (PARTITION BY PRH.REQUISITION_HEADER_ID) AS RequiredByDate
    FROM
        POR_REQUISITION_HEADERS_ALL PRH
    JOIN
        POR_REQUISITION_LINES_ALL PRL ON PRH.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
    JOIN
        PER_USERS PU_REQ ON PRH.PREPARER_ID = PU_REQ.USER_ID
    LEFT JOIN
        PER_PERSON_NAMES_F PPNF_REQ ON PU_REQ.PERSON_ID = PPNF_REQ.PERSON_ID AND PPNF_REQ.NAME_TYPE = 'GLOBAL' AND SYSDATE BETWEEN PPNF_REQ.EFFECTIVE_START_DATE AND PPNF_REQ.EFFECTIVE_END_DATE
    LEFT JOIN
        PER_ALL_ASSIGNMENTS_F PAAF ON PU_REQ.PERSON_ID = PAAF.PERSON_ID AND PAAF.ASSIGNMENT_TYPE = 'E' AND PAAF.PRIMARY_FLAG = 'Y' AND SYSDATE BETWEEN PAAF.EFFECTIVE_START_DATE AND PAAF.EFFECTIVE_END_DATE
    LEFT JOIN
        HR_ORGANIZATION_UNITS_F_VL HOU ON PAAF.ORGANIZATION_ID = HOU.ORGANIZATION_ID AND SYSDATE BETWEEN HOU.EFFECTIVE_START_DATE AND HOU.EFFECTIVE_END_DATE
    JOIN
        FUN_ALL_BUSINESS_UNITS_V BU ON PRH.REQ_BU_ID = BU.BU_ID
    WHERE PRH.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
    -- AND BU.BU_NAME IN ('[Your Business Unit Name]') -- Recommended: Uncomment and specify your Business Unit(s)
)
-- 1. Requisition Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Created' AS "ActivityName",
    BR.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR

UNION ALL

-- 2. Requisition Submitted, 4. Requisition Amended
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    CASE 
        WHEN PAH.OBJECT_REVISION_NUM > 1 THEN 'Requisition Amended'
        ELSE 'Requisition Submitted'
    END AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'SUBMIT'

UNION ALL

-- 3. Requisition Withdrawn
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Withdrawn' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'WITHDRAW'

UNION ALL

-- 5. Approval Step Started
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Started' AS "ActivityName",
    PAH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE IN ('APPROVE', 'REJECT', 'SUBMIT', 'RETURN')

UNION ALL

-- 6. Approval Step Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'APPROVE'

UNION ALL

-- 7. Approval Step Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'

UNION ALL

-- 8. Approval Step Returned
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Approval Step Returned' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'RETURN'

UNION ALL

-- 9. Requisition Approved
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Approved' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'APPROVED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'FINALLY CLOSE' AND BR.DOCUMENT_STATUS = 'APPROVED'

UNION ALL

-- 10. Requisition Rejected
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Rejected' AS "ActivityName",
    PAH.ACTION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'REJECTED' AS "RequisitionStatus",
    BR.RequiredByDate,
    PAH.NOTE AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN PO_ACTION_HISTORY PAH ON BR.REQUISITION_HEADER_ID = PAH.OBJECT_ID
WHERE PAH.OBJECT_TYPE_CODE = 'REQUISITION' AND PAH.ACTION_CODE = 'REJECT'
AND BR.DOCUMENT_STATUS = 'REJECTED'
AND PAH.ACTION_DATE = (SELECT MAX(PAH2.ACTION_DATE) FROM PO_ACTION_HISTORY PAH2 WHERE PAH2.OBJECT_ID = BR.REQUISITION_HEADER_ID AND PAH2.ACTION_CODE = 'REJECT')

UNION ALL

-- 11. Purchase Order Created
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Purchase Order Created' AS "ActivityName",
    POH.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    BR.DOCUMENT_STATUS AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
JOIN POR_REQUISITION_LINES_ALL PRL ON BR.REQUISITION_HEADER_ID = PRL.REQUISITION_HEADER_ID
JOIN PO_DISTRIBUTIONS_ALL POD ON PRL.REQUISITION_LINE_ID = POD.REQUISITION_LINE_ID
JOIN PO_HEADERS_ALL POH ON POD.PO_HEADER_ID = POH.PO_HEADER_ID

UNION ALL

-- 12. Requisition Closed
SELECT DISTINCT
    BR.REQUISITION_HEADER_ID AS "PurchaseRequisitionId",
    'Requisition Closed' AS "ActivityName",
    BR.HEADER_LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    BR.RequesterName,
    BR.DepartmentName,
    BR.RequisitionTotalAmount,
    'CLOSED' AS "RequisitionStatus",
    BR.RequiredByDate,
    NULL AS "RejectionReason",
    BR.BusinessUnit
FROM BaseRequisitions BR
WHERE BR.DOCUMENT_STATUS = 'CLOSED'

Passaggi

Prerequisiti e configurazione dell’ambiente: verifichi che Python 3 sia installato nel sistema. Installi la libreria requests necessaria eseguendo il comando seguente nel terminale: pip install requests. Le serviranno anche le credenziali API (nome utente e password) di un utente Oracle Fusion con autorizzazioni sufficienti per leggere i dati delle richieste di acquisto, oltre all’URL di base dell’istanza Oracle Fusion.
Salvi lo script Python: salvi il codice Python completo fornito nella sezione 'query' in un file, ad esempio extract_requisitions.py.
Configuri i parametri dello script: apra il file dello script in un editor di testo e modifichi i valori segnaposto all’inizio. Imposti FUSION_URL, USERNAME e PASSWORD in base ai dati dell’ambiente Oracle Fusion. Modifichi START_DATE e END_DATE per definire il periodo di estrazione.
Esamini gli endpoint API e i campi: lo script utilizza la risorsa REST API purchaseRequisitions. Il parametro fields consente di richiedere solo i dati necessari, comprese raccolte annidate come lines (per le informazioni sugli ordini di acquisto) e actionHistory (per gli eventi di approvazione), migliorando le prestazioni.
Esegua lo script: avvii lo script dal terminale con il comando python extract_requisitions.py. Lo script eseguirà l’autenticazione tramite API, avvierà il recupero dei dati e mostrerà nella console gli aggiornamenti sul numero di richieste elaborate.
Gestisca la paginazione: lo script gestisce automaticamente la paginazione. Oracle Fusion REST API restituisce i dati in blocchi (pagine). Per ogni risposta, lo script controlla il flag hasMore e invia ripetutamente richieste con il parametro offset aggiornato finché non ha recuperato tutte le richieste nell’intervallo di date specificato.
Logica di trasformazione dei dati: per ogni richiesta recuperata tramite API, lo script genera più righe nell’Event Log. Crea l’evento 'Requisition Created' a partire da CreationDate e l’evento 'Requisition Submitted' da SubmittedDate; quindi scorre la raccolta actionHistory per creare eventi dettagliati per ogni fase di approvazione (Started, Approved, Rejected, Returned).
Determini gli eventi di stato finale: lo script rileva gli eventi che rappresentano l’esito finale, come 'Requisition Approved' e 'Requisition Rejected', controllando il valore finale di DocumentStatus e utilizzando LastUpdateDate come data e ora dell’evento.
Generi l’evento dell’ordine di acquisto: lo script esamina ogni riga della richiesta. Se una riga contiene PoHeaderId, significa che è stato creato un ordine di acquisto. Viene quindi aggiunta una voce all’Event Log per questa attività, collegando la richiesta al processo di approvvigionamento successivo.
Verifichi il file di output: al termine dell’esecuzione, lo script crea nella stessa cartella un file CSV denominato oracle_fusion_requisitions_event_log.csv, che contiene l’Event Log estratto.
Prepari il caricamento: apra il file CSV generato con un programma per fogli di calcolo e ne verifichi il contenuto. Controlli che le colonne e i formati dei dati siano conformi ai requisiti dello strumento di Process Mining. Il file è pronto per essere caricato in ProcessMind.

Configurazione

Credenziali API: è necessario un account utente dedicato all’integrazione, con un ruolo che consenta l’accesso in sola lettura alla REST API Purchase Requisitions. Tra i ruoli possibili figurano Procurement Manager o un ruolo personalizzato per l’integrazione.
Endpoint REST API: lo script è configurato per utilizzare l’endpoint .../fscmRestApi/resources/11.13.18.05/purchaseRequisitions. Verifichi che il numero di versione nell’URL corrisponda all’ambiente Oracle Fusion in uso.
Filtro per intervallo di date: lo script include le variabili START_DATE e END_DATE. Si consiglia vivamente di estrarre i dati in intervalli gestibili, ad esempio 3-6 mesi alla volta, per evitare timeout API e problemi di prestazioni. Il filtro viene applicato a CreationDate delle richieste.
Selezione dei campi: il parametro fields dello script è fondamentale per le prestazioni. Limita i dati restituiti agli attributi necessari per l’Event Log, riducendo il traffico di rete e i tempi di elaborazione. Non rimuova campi obbligatori come RequisitionId, CreationDate, actionHistory o lines.
Limite di paginazione: il parametro limit è impostato su 100, un valore adatto alla maggior parte degli ambienti. Può provare ad aumentarlo a 200 o 500 per velocizzare potenzialmente l’estrazione, tenendo presente che valori troppo elevati possono causare problemi di memoria o superare i limiti API.

Query di esempio python

import requests
import csv
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Settings --- 
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance URL, username, and password.
FUSION_URL = class="hl-string">"https://[your-fusion-instance-url].oraclecloud.com"
USERNAME = class="hl-string">"your_api_user"
PASSWORD = class="hl-string">"your_api_password"

class=class="hl-string">"hl-comment"># Define the date range for the extraction.
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def get_requisitions_data():
    class="hl-string">"""Fetches and processes purchase requisition data from Oracle Fusion REST API."""
    
    api_url = fclass="hl-string">"{FUSION_URL}/fscmRestApi/resources/11.13.18.05/purchaseRequisitions"
    
    class=class="hl-string">"hl-comment"># Define the fields to retrieve to optimize the API call
    fields_to_get = [
        class="hl-string">"RequisitionId", class="hl-string">"RequisitionNumber", class="hl-string">"CreationDate", class="hl-string">"SubmittedDate", class="hl-string">"LastUpdateDate",
        class="hl-string">"DocumentStatus", class="hl-string">"PreparerName", class="hl-string">"BusinessUnitName", class="hl-string">"RequisitionTotal", class="hl-string">"NeedByDate",
        class="hl-string">"Department", class="hl-string">"RejectionReason", 
        class="hl-string">"actionHistory(ActionCode,ActionDate,PerformerName)",
        class="hl-string">"lines(PoHeaderId,LastUpdateDate)"
    ]
    
    class=class="hl-string">"hl-comment"># Parameters for the API request
    params = {
        class="hl-string">"q": fclass="hl-string">"CreationDate between '{START_DATE}' and '{END_DATE}'",
        class="hl-string">"fields": class="hl-string">",".join(fields_to_get),
        class="hl-string">"limit": 100,
        class="hl-string">"offset": 0
    }
    
    headers = {
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourceitem+json'
    }
    
    event_log = []
    has_more = True
    total_processed = 0
    now_iso = datetime.utcnow().isoformat() + class="hl-string">'Z'

    while has_more:
        print(fclass="hl-string">"Fetching requisitions from offset {params['offset']}...")
        try:
            response = requests.get(
                api_url, 
                auth=(USERNAME, PASSWORD), 
                params=params, 
                headers=headers
            )
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise an exception for bad status codes (4xx or 5xx)
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data: {e}")
            break

        data = response.json()
        requisitions = data.get(class="hl-string">'items', [])

        if not requisitions:
            print(class="hl-string">"No more requisitions found.")
            break

        for req in requisitions:
            base_event = {
                class="hl-string">'PurchaseRequisitionId': req.get(class="hl-string">'RequisitionNumber'),
                class="hl-string">'RequesterName': req.get(class="hl-string">'PreparerName'),
                class="hl-string">'DepartmentName': req.get(class="hl-string">'Department'),
                class="hl-string">'RequisitionTotalAmount': req.get(class="hl-string">'RequisitionTotal'),
                class="hl-string">'RequisitionStatus': req.get(class="hl-string">'DocumentStatus'),
                class="hl-string">'RequiredByDate': req.get(class="hl-string">'NeedByDate'),
                class="hl-string">'RejectionReason': req.get(class="hl-string">'RejectionReason'),
                class="hl-string">'BusinessUnit': req.get(class="hl-string">'BusinessUnitName'),
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': now_iso
            }

            class=class="hl-string">"hl-comment"># 1. Requisition Created
            if req.get(class="hl-string">'CreationDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Created', class="hl-string">'EventTime': req[class="hl-string">'CreationDate']})

            class=class="hl-string">"hl-comment"># 2. Requisition Submitted
            if req.get(class="hl-string">'SubmittedDate'):
                event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Submitted', class="hl-string">'EventTime': req[class="hl-string">'SubmittedDate']})

            class=class="hl-string">"hl-comment"># 3-8. Approval Workflow Events from actionHistory
            po_created = False
            if class="hl-string">'actionHistory' in req and req[class="hl-string">'actionHistory'] is not None:
                for action in req[class="hl-string">'actionHistory']:
                    activity = None
                    action_code = action.get(class="hl-string">'ActionCode')
                    if action_code == class="hl-string">'SUBMIT':
                        class=class="hl-string">"hl-comment"># This is often the first step in the approval flow
                        activity = class="hl-string">'Approval Step Started'
                    elif action_code == class="hl-string">'APPROVE':
                        activity = class="hl-string">'Approval Step Approved'
                    elif action_code == class="hl-string">'REJECT':
                        activity = class="hl-string">'Approval Step Rejected'
                    elif action_code == class="hl-string">'RETURN':
                        activity = class="hl-string">'Approval Step Returned'
                    elif action_code == class="hl-string">'WITHDRAW':
                        activity = class="hl-string">'Requisition Withdrawn'
                    elif action_code == class="hl-string">'UPDATE':
                        activity = class="hl-string">'Requisition Amended'
                    
                    if activity:
                        event_log.append({**base_event, class="hl-string">'ActivityName': activity, class="hl-string">'EventTime': action.get(class="hl-string">'ActionDate')})

            class=class="hl-string">"hl-comment"># 9-10 & 12. Final Status Events
            final_status = req.get(class="hl-string">'DocumentStatus')
            last_update_date = req.get(class="hl-string">'LastUpdateDate')
            if last_update_date:
                if final_status == class="hl-string">'APPROVED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Approved', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'REJECTED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Rejected', class="hl-string">'EventTime': last_update_date})
                elif final_status == class="hl-string">'CLOSED':
                    event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Requisition Closed', class="hl-string">'EventTime': last_update_date})

            class=class="hl-string">"hl-comment"># 11. Purchase Order Created
            if class="hl-string">'lines' in req and req[class="hl-string">'lines'] is not None:
                for line in req[class="hl-string">'lines']:
                    if line.get(class="hl-string">'PoHeaderId') and not po_created:
                        event_log.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Purchase Order Created', class="hl-string">'EventTime': line.get(class="hl-string">'LastUpdateDate', last_update_date)})
                        po_created = True class=class="hl-string">"hl-comment"># Create only one PO event per requisition
                        break
        
        total_processed += len(requisitions)
        print(fclass="hl-string">"Processed {total_processed} total requisitions so far.")

        class=class="hl-string">"hl-comment"># Check if there is more data to fetch for pagination
        has_more = data.get(class="hl-string">'hasMore', False)
        if has_more:
            params[class="hl-string">'offset'] += params[class="hl-string">'limit']

    class=class="hl-string">"hl-comment"># Write to CSV
    if event_log:
        filename = class="hl-string">'oracle_fusion_requisitions_event_log.csv'
        fieldnames = list(event_log[0].keys())
        with open(filename, class="hl-string">'w', newline=class="hl-string">'', encoding=class="hl-string">'utf-8') as csvfile:
            writer = csv.DictWriter(csvfile, fieldnames=fieldnames)
            writer.writeheader()
            writer.writerows(event_log)
        print(fclass="hl-string">"\nSuccessfully extracted {len(event_log)} events to {filename}")
    else:
        print(class="hl-string">"\nNo events were generated.")

if __name__ == class="hl-string">"__main__":
    get_requisitions_data()

Passaggi

Verifichi che Oracle BI Cloud Connector, i contenuti di procurement richiesti per Oracle Fusion Financials e l’accesso ai Public View Objects pertinenti siano disponibili nell’ambiente. Verifichi inoltre che l’utente BICC o l’account di integrazione sia autorizzato a estrarre i dati delle richieste, la cronologia delle approvazioni e gli ordini di acquisto. I nomi esatti dei ruoli e delle voci di navigazione variano in base alla versione Oracle; utilizzi quindi l’area di amministrazione BICC corrispondente nel proprio tenant.
Individui e abiliti i PVO necessari per l’estrazione. Utilizzi RequisitionHeaderPVO, o il PVO corrispondente per le intestazioni delle richieste disponibile nell’ambiente, insieme ai PVO che espongono le righe delle richieste, la cronologia degli stati, la cronologia del flusso di lavoro di approvazione e i riferimenti agli ordini di acquisto. Non presuma che un singolo PVO contenga la cronologia del flusso di lavoro o quella della creazione degli ordini di acquisto. Annoti i nomi esatti dei PVO e gli attributi disponibili nel tenant.
Configuri un processo BICC per un’estrazione massiva incrementale o storica. Imposti l’intervallo di estrazione con [Start date parameter] e [End date parameter] e configuri il processo affinché invii i file CSV alla posizione di archiviazione cloud approvata. Per il caricamento iniziale, utilizzi un intervallo storico sufficientemente ampio. Per le estrazioni ricorrenti, usi intervalli sovrapposti per includere gli aggiornamenti tardivi, quindi elimini i duplicati usando, quando disponibili, l’identificativo del caso, l’attività, la data e ora dell’evento e l’identificativo dell’evento sorgente.
Configuri le colonne da estrarre. Includa l’identificativo della richiesta, gli identificativi dell’intestazione e delle righe, il richiedente, il reparto, l’importo, lo stato, la data di consegna richiesta, l’unità aziendale, il motivo del rifiuto, le date e ore di creazione e aggiornamento, le date e ore delle transizioni di stato, quelle dell’assegnazione e delle azioni di approvazione, l’azione di approvazione, il riferimento all’ordine di acquisto e la data e ora di aggiornamento BICC. Utilizzi i nomi esatti degli attributi esposti dai PVO selezionati. Se un attributo non è disponibile, lo associ a [Configure based on your system] e documenti il limite, senza sostituirlo con un campo non verificato.
Estragga i file CSV sorgente e conservi gli originali. Carichi ogni file in un’area di staging, registri il nome del PVO e del file sorgente, uniformi le date e ore a un unico fuso orario concordato e analizzi in modo coerente i valori di data e ora di Oracle. Gestisca gli identificativi come stringhe per evitare di perdere gli zeri iniziali o la precisione.
Riorganizzi i dati sorgente in una tabella di eventi con una riga per ogni evento aziendale esplicito. L’output deve contenere PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate. Aggiunga gli attributi consigliati quando disponibili. Non faccia affidamento su ProcessMind per dedurre gli eventi dalle modifiche di stato o dei campi: la trasformazione deve creare esplicitamente righe per tutte le dodici attività elencate nella query.
Generi le righe degli eventi sulla base delle evidenze sorgente appropriate. Utilizzi le registrazioni di creazione per Requisition Created, una transizione esplicita di invio per Requisition Submitted, un’azione o transizione esplicita di ritiro per Requisition Withdrawn, una modifica successiva all’invio o una nuova versione rilevata per Requisition Amended, l’assegnazione nel flusso di lavoro per Approval Step Started e le azioni esplicite nella cronologia delle approvazioni per Approval Step Approved, Approval Step Rejected e Approval Step Returned. Utilizzi una transizione esplicita dello stato complessivo per Requisition Approved, Requisition Rejected e Requisition Closed. Per Purchase Order Created, utilizzi una registrazione esplicita della creazione dell’ordine di acquisto o la relativa data e ora, collegata alla richiesta.
Applichi una deduplicazione deterministica. Se più righe sorgente rappresentano lo stesso evento, ne conservi una utilizzando la data e ora dell’evento più specifica e, quando disponibile, un identificativo sorgente stabile. Non accorpi fasi di approvazione distinte solo perché condividono lo stesso identificativo della richiesta. Mantenga separati gli eventi di approvazione relativi a responsabili o fasi del flusso di lavoro diversi.
Convalidi l’Event Log risultante. Verifichi che siano presenti tutte le attività richieste, che ogni evento abbia un identificativo del caso e una data e ora, che le date e ore rientrino nell’intervallo di estrazione o che gli aggiornamenti tardivi siano documentati e che gli attributi consigliati siano compilati quando disponibili nella fonte. Confronti il numero di richieste e i collegamenti agli ordini di acquisto con le estrazioni sorgente.
Esporti l’Event Log finale in formato CSV UTF-8, con una riga di intestazione e un evento per riga. Utilizzi i nomi esatti delle colonne PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate, oltre agli attributi consigliati. Carichi il CSV in ProcessMind e configuri PurchaseRequisitionId come identificativo del caso, ActivityName come attività ed EventTime come data e ora dell’evento.

Configurazione

Metodo di estrazione: estrazione massiva dei dati con Oracle BI Cloud Connector, con consegna dei file CSV alla posizione di archiviazione cloud configurata.
Oggetti sorgente: utilizzi RequisitionHeaderPVO e i PVO corrispondenti, disponibili nel tenant, per le righe delle richieste, la cronologia degli stati, la cronologia del flusso di lavoro di approvazione e i riferimenti agli ordini di acquisto. Verifichi nell’ambiente i nomi esatti dei PVO e degli attributi.
Colonne di output obbligatorie: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate.
Colonne di output consigliate: RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason e BusinessUnit.
Intervallo di date: per le analisi periodiche, utilizzi un intervallo di tre-sei mesi. Se necessario, per il caricamento storico iniziale usi un intervallo più ampio. Per le estrazioni ricorrenti, imposti intervalli sovrapposti per acquisire gli aggiornamenti tardivi, quindi elimini i duplicati.
Filtri: applichi [Company-specific filter], [Document Type filter], [Business Unit filter] e [Date range filter] solo se i relativi attributi sono disponibili nei PVO selezionati. Verifichi se il filtro si applica alla data di creazione, alla data di aggiornamento, alla data di transizione dello stato o a un’altra data sorgente.
Estrazione incrementale: preferisca una data e ora di aggiornamento o un meccanismo di estrazione incrementale supportato ed esposto da BICC. Conservi il riferimento temporale dell’ultima estrazione completata correttamente e includa una breve sovrapposizione nell’esecuzione successiva.
Completezza degli eventi: configuri estrazioni sorgente separate quando le intestazioni delle richieste non espongono la cronologia delle approvazioni, le transizioni di stato, le modifiche o la creazione degli ordini di acquisto. Una sola estrazione delle intestazioni allo stato corrente non consente di ricostruire in modo affidabile gli eventi storici.
Prestazioni: limiti l’intervallo di date e le colonne selezionate, suddivida le estrazioni di grandi dimensioni quando supportato, eviti attributi descrittivi non necessari ed elabori i file CSV in batch. Conservi i file sorgente per le verifiche.
Archiviazione: configuri una posizione di archiviazione cloud approvata con capacità, conservazione, cifratura e controlli di accesso adeguati. Verifichi che l’account di estrazione possa scrivere i file e che il processo di trasformazione possa leggerli.
Prerequisiti: disponibilità di BICC, accesso ai dati di procurement e approvazione pertinenti in Oracle Fusion, autorizzazioni di integrazione adeguate, accesso ai PVO selezionati ed eventuali abbonamenti o diritti d’uso Oracle richiesti. I nomi esatti dei ruoli, le licenze e i percorsi di navigazione dipendono dalla versione Oracle e dalla configurazione del tenant.
Gestione dell’ora: uniformi tutte le date e ore sorgente a un fuso orario documentato e conservi i valori originali quando è necessario garantire la tracciabilità.
Gestione dei casi: utilizzi PurchaseRequisitionId come identificativo del caso. Non utilizzi l’identificativo di una riga della richiesta come identificativo del caso, a meno che il processo non venga modellato intenzionalmente a livello di riga.

Query di esempio sql

WITH
source_requisition AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([Creation timestamp attribute] AS TIMESTAMP) AS CreatedAt,
        CAST([Submission timestamp attribute] AS TIMESTAMP) AS SubmittedAt,
        CAST([Withdrawal timestamp attribute] AS TIMESTAMP) AS WithdrawnAt,
        CAST([Approval timestamp attribute] AS TIMESTAMP) AS ApprovedAt,
        CAST([Rejection timestamp attribute] AS TIMESTAMP) AS RejectedAt,
        CAST([Closure timestamp attribute] AS TIMESTAMP) AS ClosedAt,
        CAST([Last update timestamp attribute] AS TIMESTAMP) AS SourceLastUpdate,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition header extract or view]
    WHERE CAST([Last update timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Last update timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
      AND ([Company filter attribute] = '[Company-specific filter]' OR '[Company-specific filter]' = '[All companies]')
      AND ([Document type filter attribute] = '[Document Type filter]' OR '[Document Type filter]' = '[All document types]')
),
source_status_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Previous status attribute] AS VARCHAR(200)) AS PreviousStatus,
        CAST([New status attribute] AS VARCHAR(200)) AS NewStatus,
        CAST([Status change timestamp attribute] AS TIMESTAMP) AS StatusChangedAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition status history extract or view]
    WHERE CAST([Status change timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Status change timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_amendments AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Amendment timestamp attribute] AS TIMESTAMP) AS AmendedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Requisition amendment or version extract or view]
    WHERE CAST([Amendment timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Amendment timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_approval_history AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Approval step identifier attribute] AS VARCHAR(200)) AS ApprovalStepId,
        CAST([Approver or approval group attribute] AS VARCHAR(500)) AS ApproverName,
        CAST([Approval action attribute] AS VARCHAR(200)) AS ApprovalAction,
        CAST([Approval assignment timestamp attribute] AS TIMESTAMP) AS ApprovalStartedAt,
        CAST([Approval action timestamp attribute] AS TIMESTAMP) AS ApprovalActionAt,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Approval workflow history extract or view]
    WHERE COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND COALESCE(CAST([Approval assignment timestamp attribute] AS TIMESTAMP), CAST([Approval action timestamp attribute] AS TIMESTAMP)) < CAST('[End date parameter]' AS TIMESTAMP)
),
source_purchase_orders AS (
    SELECT
        CAST([Requisition identifier attribute] AS VARCHAR(200)) AS PurchaseRequisitionId,
        CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) AS PurchaseOrderCreatedAt,
        CAST([Requester name attribute] AS VARCHAR(500)) AS RequesterName,
        CAST([Department attribute] AS VARCHAR(500)) AS DepartmentName,
        CAST([Total amount attribute] AS DECIMAL(38, 10)) AS RequisitionTotalAmount,
        CAST([Status attribute] AS VARCHAR(200)) AS RequisitionStatus,
        CAST([Required by date attribute] AS TIMESTAMP) AS RequiredByDate,
        CAST([Rejection reason attribute] AS VARCHAR(4000)) AS RejectionReason,
        CAST([Business unit attribute] AS VARCHAR(500)) AS BusinessUnit,
        CAST([BICC refresh timestamp attribute] AS TIMESTAMP) AS LastDataUpdate
    FROM [Purchase order reference extract or view]
    WHERE CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) >= CAST('[Start date parameter]' AS TIMESTAMP)
      AND CAST([Purchase order creation timestamp attribute] AS TIMESTAMP) < CAST('[End date parameter]' AS TIMESTAMP)
),
events AS (
    SELECT PurchaseRequisitionId, 'Requisition Created' AS ActivityName, CreatedAt AS EventTime, RequesterName, DepartmentName, RequisitionTotalAmount, RequisitionStatus, RequiredByDate, RejectionReason, BusinessUnit, LastDataUpdate FROM source_requisition WHERE CreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Submitted', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('pending approval', 'submitted', 'pending') AND LOWER(COALESCE(h.PreviousStatus, '')) IN ('incomplete', 'draft')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Withdrawn', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('withdrawn', 'cancelled', 'canceled')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Requisition Amended', a.AmendedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_amendments a WHERE a.AmendedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Started', a.ApprovalStartedAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalStartedAt IS NOT NULL
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Approved', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('approved', 'approve')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Rejected', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('rejected', 'reject')
    UNION ALL
    SELECT a.PurchaseRequisitionId, 'Approval Step Returned', a.ApprovalActionAt, a.RequesterName, a.DepartmentName, a.RequisitionTotalAmount, a.RequisitionStatus, a.RequiredByDate, a.RejectionReason, a.BusinessUnit, a.LastDataUpdate FROM source_approval_history a WHERE a.ApprovalActionAt IS NOT NULL AND LOWER(a.ApprovalAction) IN ('returned', 'return', 'sent back', 'send back')
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Approved', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'approved'
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Rejected', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) = 'rejected'
    UNION ALL
    SELECT p.PurchaseRequisitionId, 'Purchase Order Created', p.PurchaseOrderCreatedAt, p.RequesterName, p.DepartmentName, p.RequisitionTotalAmount, p.RequisitionStatus, p.RequiredByDate, p.RejectionReason, p.BusinessUnit, p.LastDataUpdate FROM source_purchase_orders p WHERE p.PurchaseOrderCreatedAt IS NOT NULL
    UNION ALL
    SELECT h.PurchaseRequisitionId, 'Requisition Closed', h.StatusChangedAt, h.RequesterName, h.DepartmentName, h.RequisitionTotalAmount, h.NewStatus, h.RequiredByDate, h.RejectionReason, h.BusinessUnit, h.LastDataUpdate FROM source_status_history h WHERE LOWER(h.NewStatus) IN ('closed', 'finally closed', 'complete', 'completed')
)
SELECT
    PurchaseRequisitionId,
    ActivityName,
    EventTime,
    'Oracle Fusion Financials' AS SourceSystem,
    LastDataUpdate,
    RequesterName,
    DepartmentName,
    RequisitionTotalAmount,
    RequisitionStatus,
    RequiredByDate,
    RejectionReason,
    BusinessUnit
FROM events
WHERE PurchaseRequisitionId IS NOT NULL
  AND EventTime IS NOT NULL
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

È pronto a iniziare?

Utilizzi questo template per iniziare a ottimizzare il processo di acquisto e pagamento delle richieste e ottenere nuove efficienze. Si prepari a trasformare le operazioni di approvvigionamento.

Torna alla guida al miglioramento

Scarica il template

Riduca del 30% i tempi del processo di acquisto e pagamento delle richieste

Semplifichi la gestione delle richieste P2P in Oracle e riduca del 30% il tempo di ciclo.

Inizi la prova gratuita

Non è richiesta una carta di credito; la configurazione richiede pochi minuti.

Il Suo template dei dati per l’acquisto e il pagamento delle richieste

Il Suo template dei dati per l’acquisto e il pagamento delle richieste

Attributi del processo di acquisto e pagamento delle richieste

Attività del processo di acquisto e pagamento delle richieste

Guide all’estrazione

Esportazione da Oracle Transactional Business Intelligence (OTBI)

Passaggi

Configurazione

Query di esempio sql

Estrazione di dati con modello SQL di Oracle BI Publisher

Passaggi

Configurazione

Query di esempio sql

Script Python tramite Oracle Fusion REST API

Passaggi

Configurazione

Query di esempio python

Estrazione massiva dei dati con Oracle BI Cloud Connector (BICC)

Passaggi

Configurazione

Query di esempio sql

È pronto a iniziare?

Riduca del 30% i tempi del processo di acquisto e pagamento delle richieste