> Miglioramento Continuo dei Processi > Purchase to Pay Richiesta > Oracle Fusion Financials > Template Dati

Il Suo template per i dati delle richieste Purchase to Pay

Oracle Fusion Financials

Purchase to Pay - Attributi di richiesta (22) Purchase to Pay - Attività di richiesta (12) Guide all'Estrazione (4)

Il Suo template per i dati delle richieste Purchase to Pay

Questo template fornisce una roadmap chiara per raccogliere i dati essenziali necessari ad analizzare il Suo processo Purchase to Pay - Requisition. Delinea gli attributi chiave da raccogliere, le attività critiche da tracciare e consigli pratici su come estrarre queste informazioni da Oracle Fusion Financials. Grazie a questo strumento, potrà preparare efficacemente il Suo event log per un'attività di Process Mining approfondita.

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

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

Scarica Template

Purchase to Pay - Attributi di richiesta

Questi sono i campi dati consigliati da includere nell'event log per un'analisi completa del processo Purchase to Pay - Requisition.

5 Obbligatorio 7 Consigliato 10 Facoltativo

	Nome	Descrizione
	Activity ActivityName	Il nome dell'evento aziendale verificatosi in un punto specifico del processo di richiesta.
Descrizione L'Attività rappresenta un passaggio o una pietra miliare distinta nel ciclo di vita della richiesta di acquisto. Gli esempi includono 'Richiesta creata', 'Fase di approvazione approvata' o 'Ordine d'acquisto creato'. Queste attività derivano da cambi di stato, azioni dell'utente o eventi di sistema registrati nei log di audit o nelle tabelle delle transazioni del sistema sorgente. 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 identificare i percorsi comuni, i colli di bottiglia, i loop di rielaborazione e le deviazioni dalla procedura standard. Perché è importante Costituisce la spina dorsale della mappa di processo, consentendo la visualizzazione e l'analisi del workflow delle richieste. Dove trovare Derivato dai record di modifica dello stato in tabelle come POR_REQUISITION_HEADERS_ALL, dalla cronologia delle transazioni o dagli audit trail del workflow come FA_FUSION_SOAINFRA.WFTASK. Esempi Richiesta CreataFase di Approvazione ApprovataRichiesta rifiutataOrdine di acquisto creato
	ID requisizione d’acquisto PurchaseRequisitionId	L'identificativo univoco di una richiesta d'acquisto, che funge da ID del caso per il processo.
Descrizione L'ID della richiesta di acquisto è l'identificativo centrale che collega tutte le attività relative a una specifica richiesta di beni o servizi. Ogni richiesta riceve un ID univoco alla creazione, che rimane costante per tutto il suo ciclo di vita. Nel Process Mining, questo attributo viene utilizzato per raggruppare tutti gli eventi correlati, come creazione, invio, fasi di approvazione e chiusura finale, in un unico caso. Ciò consente l'analisi end-to-end del percorso della richiesta, rendendo possibile visualizzare mappe di processo, calcolare tempi di ciclo e analizzare varianti per ogni singola richiesta. Perché è importante Questo è l'attributo fondamentale per tracciare il ciclo di vita di una richiesta dall'inizio alla fine, consentendo tutte le analisi a livello di caso e i calcoli dei KPI. Dove trovare Solitamente è la chiave primaria nella tabella dell'intestazione della richiesta, come POR_REQUISITION_HEADERS_ALL.REQUISITION_HEADER_ID in Oracle Fusion Financials. Esempi 100234810023491002350
	Timestamp Evento EventTime	Il timestamp che indica quando l'attività si è verificata.
Descrizione L'Orario dell'evento registra la data e l'ora precise in cui si è verificata una specifica attività. Questo timestamp è fondamentale per l'ordinamento cronologico degli eventi all'interno di un caso e proviene dalle date di creazione, dalle date di ultimo aggiornamento o da timestamp di azioni specifiche nel sistema. In fase di analisi, l'Orario dell'evento viene utilizzato 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. È fondamentale per identificare 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 legati al tempo, ordinare correttamente gli eventi e analizzare le prestazioni del processo e i colli di bottiglia. Dove trovare Solitamente proviene da una colonna 'LAST_UPDATE_DATE' o 'CREATION_DATE' associata alla transazione o al cambio di stato, spesso presente in tabelle come POR_REQUISITION_HEADERS_ALL o nelle tabelle della cronologia del workflow. Esempi 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	Sistema di Origine SourceSystem	Il sistema informativo da cui questi dati sono stati estratti.
Descrizione Questo attributo identifica l'origine dei dati di processo. Per questo modello dati, sarà costantemente 'Oracle Fusion Financials'. In ambienti con più ERP o sistemi integrati, questo campo è fondamentale per la data lineage, la risoluzione dei problemi e la garanzia della qualità dei dati. Fornisce il contesto sulla fonte di verità per gli eventi di processo analizzati. Perché è importante Fornisce un contesto essenziale sull'origine dei dati, fondamentale per la data governance e per l'integrazione di dati provenienti da più sistemi. Dove trovare Questo è un valore statico aggiunto durante il processo di estrazione e trasformazione dei `dati` per etichettare l'origine del `dataset`. Esempi Oracle Fusion Financials
	Ultimo `Data Update` LastDataUpdate	Il timestamp dell'ultimo aggiornamento dei dati dal sistema sorgente.
Descrizione Questo attributo indica la data e l'ora in cui i dati sono stati estratti l'ultima volta da Oracle Fusion Financials. Si applica all'intero set di dati piuttosto che ai singoli eventi. Gli analisti utilizzano queste informazioni per capire quanto sono recenti i dati e per confermare quando sono state incluse le ultime transazioni. È un metadato fondamentale per i report delle dashboard e per garantire che le analisi si basino su informazioni aggiornate. Perché è importante Informa gli utenti sulla freschezza dei dati, assicurando che le analisi siano pertinenti e basate sulle ultime informazioni disponibili. Dove trovare Questo timestamp viene generato e memorizzato durante il processo di estrazione dati, solitamente dallo strumento ETL o dalla data pipeline. Esempi 2023-10-27T02:00:00Z
	Data richiesta di consegna RequiredByDate	La data entro la quale il richiedente necessita dei beni o dei servizi.
Descrizione Questa data è specificata dal richiedente per indicare la scadenza entro la quale ricevere gli articoli richiesti. Funge da obiettivo interno di Service Level Agreement (SLA) per il processo di approvvigionamento. Questo attributo è la base per la dashboard 'Performance della data richiesta' e per il KPI 'Tasso di aderenza alla data richiesta'. Confrontando questa data con la data effettiva di creazione dell'ordine d'acquisto o di ricezione merci, l'analisi può rivelare quanto il processo di acquisto stia soddisfacendo le richieste dei clienti interni e identificare eventuali ritardi sistemici. Perché è importante Fondamentale per misurare le prestazioni del processo rispetto alle scadenze interne e capire se il processo di approvvigionamento soddisfa le esigenze aziendali in modo tempestivo. Dove trovare Solitamente memorizzato a livello di riga articolo della richiesta, in tabelle come POR_REQUISITION_LINES_ALL in un campo come 'NEED_BY_DATE'. Esempi 2023-11-012023-12-152024-01-31
	Dipartimento DepartmentName	Il dipartimento aziendale a cui appartiene il richiedente.
Descrizione Questo attributo indica l'unità organizzativa della persona che ha creato la richiesta, come 'Amministrazione', 'IT' o 'Marketing'. Solitamente deriva dal profilo utente del richiedente nel sistema HR. L'analisi per dipartimento è un modo comune ed efficace per segmentare i dati di processo. Aiuta a identificare comportamenti specifici per reparto, come tassi di rifiuto più elevati o tempi di ciclo più lunghi, che possono guidare iniziative mirate di miglioramento del processo. È una dimensione chiave per la dashboard 'Metriche di performance dei richiedenti'. Perché è importante Consente l'analisi del processo segmentata per business unit, rivelando pattern specifici per dipartimento, prestazioni e problemi di conformità. Dove trovare Solitamente derivato dal profilo del richiedente, richiede spesso una join dalla tabella delle richieste a una tabella HR o di directory utenti che contenga le informazioni sul dipartimento. Esempi Tecnologia dell'InformazioneFinanzaOperazioniMarketing
	Importo Totale della Richiesta RequisitionTotalAmount	Il valore monetario totale della richiesta di acquisto.
Descrizione Questo attributo rappresenta la somma del valore di tutte le voci di una singola richiesta di acquisto. È un dato fondamentale per comprendere la rilevanza finanziaria di ogni richiesta. Nel Process Mining, l'importo totale viene utilizzato per una vasta gamma di analisi. Può essere usato per filtrare le richieste di alto valore, che spesso hanno percorsi di approvazione diversi o controlli più rigorosi. Le dashboard possono utilizzare questo attributo per analizzare come le metriche di processo, come il tempo di ciclo o il tasso di rifiuto, siano correlate al valore della richiesta. Perché è importante Fornisce il contesto finanziario, consentendo un'analisi basata sul valore per dare priorità ai miglioramenti di processo e comprendere come il valore della richiesta influenzi il comportamento del processo stesso. Dove trovare Si trova nell'intestazione della richiesta di acquisto, spesso in un campo come REQUISITION_TOTAL in POR_REQUISITION_HEADERS_ALL. Può anche essere calcolato sommando gli importi delle singole voci in POR_REQUISITION_LINES_ALL. Esempi 550.0012500.7599.99
	Motivo del Rigetto RejectionReason	Il motivo fornito da un approvatore quando una richiesta o una fase di approvazione viene respinta.
Descrizione Quando una richiesta viene respinta, l'approvatore solitamente fornisce un motivo, selezionandolo da un elenco predefinito o inserendo del testo libero. Questo attributo cattura tale giustificazione. Si tratta di un attributo critico per l'analisi delle cause alla base dei fallimenti del processo. Supporta direttamente la dashboard 'Tendenze di modifica e rifiuto' fornendo il 'perché' dei rifiuti. Analizzare i motivi di rifiuto aiuta a identificare problemi comuni, come codifiche errate, sforamenti di budget o violazioni delle policy, che possono poi essere affrontati tramite formazione o controlli di sistema. Perché è importante Fornisce insight diretti sui motivi per cui le richieste vengono respinte, consentendo miglioramenti mirati per ridurre i ritardi e aumentare il tasso di elaborazione automatica (straight-through). Dove trovare Proveniente dai commenti del workflow o dai campi specifici del codice motivo del rifiuto nell'audit trail del workflow, potenzialmente nelle tabelle relative a FA_FUSION_SOAINFRA.WFTASK o nell'archivio commenti associato. Esempi Conto CoGe erratoSupera il budget per il centro di costoFornitore non preferenziale selezionatoRichiesta 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. Questa informazione viene solitamente acquisita all'inizio del processo, al momento della creazione della richiesta. Analizzare le prestazioni del processo per Richiedente è fondamentale per la dashboard 'Metriche di performance dei richiedenti'. Aiuta a identificare quali utenti o gruppi potrebbero necessitare di formazione aggiuntiva, evidenziando tassi elevati di modifiche, rifiuti o lunghi tempi di ciclo associati alle loro richieste. Offre una visione del processo incentrata sull'aspetto umano. Perché è importante Consente l'analisi delle prestazioni per richiedente, aiutando a identificare le esigenze di formazione e a evidenziare utenti o dipartimenti efficienti. Dove trovare Proveniente dai dati di intestazione della richiesta, spesso unendo l'ID del richiedente con una tabella anagrafica dipendenti o utenti. Verifichi i campi relativi a 'PREPARER_ID' in POR_REQUISITION_HEADERS_ALL ed esegua la join con PER_ALL_PEOPLE_F. Esempi John SmithJane DoeEmily Jones
	Stato della richiesta RequisitionStatus	Lo stato attuale o finale della richiesta d'acquisto.
Descrizione Questo attributo indica lo stato generale della richiesta in un dato momento o il suo esito finale, come 'Approvato', 'Respinto', 'In corso' o 'Chiuso'. Questa è spesso la fonte da cui derivano molte attività nell'event log. Questo attributo è fondamentale per la dashboard 'Panoramica dello stato delle richieste', fornendo un'istantanea del carico di lavoro attuale e dell'arretrato. Viene anche utilizzato per calcolare i KPI basati sull'esito, come il Tasso di rifiuto delle richieste, filtrando i casi che terminano in uno stato specifico. Perché è importante Fornisce un'istantanea dello stato attuale delle richieste e viene utilizzato per determinare i risultati finali per il calcolo dei KPI. Dove trovare Si trova nella tabella di testata della richiesta, solitamente in un campo come "DOCUMENT_STATUS" o "APPROVAL_STATUS" in POR_REQUISITION_HEADERS_ALL. Esempi APPROVEDIN CORSORIFIUTATORITIRATO
	Unità aziendale BusinessUnit	La specifica business unit dell'organizzazione a cui appartiene la richiesta.
Descrizione La Business Unit rappresenta un'entità legale o funzionale distinta all'interno dell'azienda per la quale viene effettuata la richiesta. Si tratta di un raggruppamento organizzativo di livello superiore rispetto al dipartimento. L'analisi dei dati per Business Unit consente confronti di prestazioni di alto livello tra diverse aree dell'organizzazione. Questo aiuta il management a capire se le inefficienze di processo sono localizzate o diffuse e dove concentrare gli sforzi di miglioramento. È una dimensione fondamentale per filtrare quasi tutte le dashboard e i KPI. Perché è importante Fornisce un contesto organizzativo di alto livello, consentendo il confronto delle prestazioni e l'analisi strategica tra le diverse aree dell'azienda. Dove trovare Questo è un campo organizzativo fondamentale in Oracle Fusion, solitamente disponibile nell'intestazione della richiesta in tabelle come POR_REQUISITION_HEADERS_ALL. Esempi BU North AmericaBU EuropaSede centrale
	Descrizione articolo ItemDescription	La descrizione del prodotto o del servizio richiesto in una riga della richiesta.
Descrizione Questo attributo contiene la descrizione testuale dell'articolo acquistato. Fornisce dettagli specifici sui beni o servizi richiesti. Sebbene sia spesso un dato non strutturato, la Descrizione articolo offre un contesto prezioso per l'analisi. Può essere utilizzata nei filtri per isolare richieste di tipi specifici di acquisto che potrebbero non essere catturati dal Tipo di richiesta. Ad esempio, un analista potrebbe cercare tutte le richieste contenenti 'Licenza software' per comprenderne il flusso di processo specifico e il tempo di ciclo. Perché è importante Offre un contesto dettagliato sull'acquisto, consentendo filtri e analisi più granulari su beni o servizi specifici. Dove trovare Si trova nella tabella delle voci della richiesta di acquisto, POR_REQUISITION_LINES_ALL, in un campo come ITEM_DESCRIPTION. Esempi Laptop da 15 pollici, 16 GB di RAMServizi di consulenza - Progetto Q4Rinnovo annuale manutenzione software
	È Automatizzato IsAutomated	Un flag che indica 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 un essere umano. Gli esempi potrebbero includere cambi di stato gestiti dal sistema o passaggi di approvazione automatizzati per articoli di scarso valore. L'analisi di questo attributo aiuta a quantificare il livello di automazione del processo. Può essere utilizzato per confrontare la velocità e l'efficienza dei passaggi automatizzati rispetto a quelli manuali e per identificare opportunità per un'ulteriore automazione. Perché è importante Aiuta a misurare il livello di automazione nel processo e a identificare opportunità per automatizzare compiti manuali. Dove trovare Derivato verificando se l'utente associato a un'attività è un account di sistema o di servizio. Ciò richiede un elenco di ID utente di sistema noti. Esempi truefalse
	È modificata IsAmendedFlag	Un flag booleano impostato su true se la richiesta è stata modificata almeno una volta.
Descrizione Questo attributo calcolato indica se una richiesta ha subito modifiche dopo l'invio iniziale. Si ottiene verificando la presenza di un'attività 'Richiesta modificata' nella cronologia del caso. Questo flag semplifica l'analisi e il calcolo dei KPI. Viene utilizzato direttamente per calcolare il KPI 'Tasso di modifica delle richieste' e per identificare i casi che non sono straight-through (elaborazione diretta). 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 un facile confronto tra richieste modificate e non modificate. Dove trovare Questo attributo non è presente nel sistema sorgente ma viene calcolato durante la trasformazione dei dati in base alla presenza di attività legate a modifiche nell'event log. Esempi truefalse
	È Straight Through IsStraightThrough	Un flag che indica se la richiesta è stata approvata senza alcuna modifica o rifiuto.
Descrizione Questo flag calcolato identifica le richieste che sono passate attraverso il processo, dall'invio all'approvazione, senza alcun loop di rielaborazione, come modifiche o rifiuti. Rappresenta un processo eseguito perfettamente per un singolo caso. Questo attributo è alla base del KPI 'Tasso di richieste Straight-Through'. Analizzare le caratteristiche delle richieste elaborate direttamente (ad esempio, dipartimenti, richiedenti o tipi comuni) può rivelare best practice e opportunità di automazione. Al contrario, analizzare quelle che non sono straight-through aiuta a individuare i principali motori di inefficienza. Perché è importante Misura direttamente l'efficienza del processo ed è la base per il KPI "Straight-Through Requisition Rate", aiutando a identificare i fattori che causano rilavorazioni. Dove trovare Questo attributo viene calcolato durante la trasformazione dei dati. Un caso viene contrassegnato come vero se non sono presenti attività di 'Richiesta modificata' o 'Fase di approvazione respinta'. Esempi truefalse
	Nome Fornitore SupplierName	Il nome del fornitore suggerito o preselezionato per i beni o i servizi.
Descrizione Questo attributo identifica il fornitore dal quale si intendono acquistare i beni o i servizi. Il fornitore può essere suggerito dal richiedente o determinato dal sistema in base a cataloghi o accordi preventivi. L'analisi per fornitore può rivelare pattern di acquisto importanti. Ad esempio, può aiutare a identificare se le richieste per determinati fornitori impiegano più tempo per essere approvate o hanno tassi di rifiuto più elevati. Queste informazioni possono essere preziose per la gestione dei rapporti con i fornitori e per la strategia di acquisto. Perché è importante Consente l'analisi delle prestazioni del processo per fornitore, utile per la strategia di sourcing e la gestione dei rapporti con i fornitori. Dove trovare Si trova nella tabella delle voci della richiesta di acquisto, POR_REQUISITION_LINES_ALL, spesso collegata tramite un VENDOR_ID a una tabella anagrafica 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à, come un approvatore o un redattore.
Descrizione Mentre il Nome del Richiedente identifica l'iniziatore, il Nome Utente specifica l'individuo che ha eseguito un evento specifico nel processo, come un'approvazione o un rifiuto. Questo è particolarmente importante per i workflow di approvazione a più fasi, dove sono coinvolte diverse persone. Questo attributo è cruciale per analizzare i colli di bottiglia nelle approvazioni e per misurare le performance di specifici approvatori o team. Supporta direttamente la dashboard 'Colli di Bottiglia del Workflow di Approvazione' consentendo l'analisi dei tempi di elaborazione per ogni utente coinvolto nella catena di approvazione. Perché è importante Identifica l'attore di ogni evento, il che è vitale per analizzare i tempi di passaggio (handover), le prestazioni degli approvatori e l'allocazione delle risorse. Dove trovare Proveniente dalla cronologia del workflow o dalle tabelle di audit trail, come FA_FUSION_SOAINFRA.WFTASK, che registra l'utente associato al completamento di ogni attività. Esempi David LeeSusan ChenMichael Brown
	Numero Ordine d'Acquisto PurchaseOrderNumber	L'identificativo dell'ordine d'acquisto creato dalla richiesta approvata.
Descrizione Questo attributo collega una richiesta di acquisto all'ordine d'acquisto risultante. Una volta che una richiesta è completamente approvata, viene solitamente convertita in uno o più ordini d'acquisto da inviare a un fornitore. In fase di analisi, questo ID è essenziale per tracciare il processo a valle della richiesta. Consente il calcolo del KPI 'Lead Time da richiesta a ordine' e supporta la dashboard 'Tempo di ciclo da richiesta a ordine'. Permette inoltre di combinare i dati del processo di richiesta con i successivi processi di ordine e fatturazione per una vera analisi end-to-end del ciclo passivo. Perché è importante Collega la richiesta di acquisto al successivo ordine d'acquisto, consentendo di misurare il tempo di ciclo dalla richiesta all'ordine e di eseguire l'analisi end-to-end del processo. Dove trovare Questa informazione viene memorizzata una volta creato l'ordine (PO). In genere si trova consultando i riferimenti della richiesta sottostante nelle tabelle di distribuzione degli ordini, come PO_DISTRIBUTIONS_ALL, che rimanda alla riga della richiesta. Esempi PO-2023-5832PO-2023-5833PO-2023-5834
	Percorso `Workflow` di Approvazione ApprovalWorkflowPath	La sequenza predefinita di approvatori o gruppi di approvazione richiesti per la richiesta.
Descrizione Questo attributo definisce il processo di approvazione standard previsto per una determinata richiesta in base alle policy aziendali, considerando fattori come l'importo, il tipo e il dipartimento. Rappresenta il modello di processo ideale (to-be). Il Percorso del workflow di approvazione è fondamentale per l'analisi di conformità. Supporta direttamente la dashboard 'Analisi di conformità e deviazione' e il KPI 'Indice di conformità delle richieste', consentendo un confronto diretto tra le fasi di approvazione effettive e il percorso prescritto. Le deviazioni possono indicare violazioni delle policy o inefficienze di processo. Perché è importante Consente il controllo di conformità confrontando il flusso di processo effettivo con la gerarchia di approvazione richiesta, evidenziando le richieste non conformi. Dove trovare 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 Manager > Direttore > VP FinanceProprietario Centro di Costo > Sicurezza ITManager > Responsabile di dipartimento
	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 ordinato. I tipi comuni includono beni, servizi o spese in conto capitale. Il tipo può influenzare il workflow di approvazione richiesto e la strategia di acquisto. In fase di analisi, il Tipo di richiesta funge da potente dimensione per filtri e confronti. Ad esempio, si potrebbe analizzare se le richieste di servizi hanno un tempo di ciclo di approvazione più lungo rispetto a quelle per i beni. Aiuta a capire se diversi tipi di richieste mostrano comportamenti di processo o colli di bottiglia differenti. Perché è importante Consente di segmentare l'analisi per capire come il processo differisce per i vari tipi di acquisti, come beni rispetto a servizi. Dove trovare Questo è spesso determinato dal tipo o dalla categoria della riga articolo selezionata durante la creazione della richiesta. Può essere memorizzato nella tabella delle righe della richiesta, POR_REQUISITION_LINES_ALL. Esempi BeniServiziSpese in conto capitale (CAPEX)
	Valuta CurrencyCode	Il codice valuta per l'importo della richiesta, come USD o EUR.
Descrizione Questo attributo specifica la valuta dell'Importo totale della richiesta. Per le organizzazioni globali, le richieste possono essere create in varie valute. È essenziale per interpretare e aggregare correttamente i dati finanziari. In qualsiasi analisi che coinvolga valori monetari, il codice valuta deve essere utilizzato per garantire che gli importi siano confrontati accuratamente, filtrando per una singola valuta o convertendo tutti gli importi in una valuta comune. Perché è importante Garantisce analisi finanziarie e reportistica accurate, specialmente in organizzazioni multinazionali che gestiscono più valute. Dove trovare Solitamente si trova nella tabella dell'intestazione della richiesta insieme ai campi dell'importo, ad esempio in POR_REQUISITION_HEADERS_ALL. Esempi USDEURGBPJPY

Obbligatorio Consigliato Facoltativo

Purchase to Pay - Attività di richiesta

Questi sono i passaggi chiave e le pietre miliari del processo da acquisire nell'event log per una discovery accurata del processo Purchase to Pay - Requisition.

6 Consigliato 6 Facoltativo

	Activity	Descrizione
	Ordine di acquisto creato	Questo evento si verifica quando una riga della richiesta approvata viene utilizzata per generare un ordine d'acquisto. Collega il processo di richiesta al processo di acquisto a valle.
Perché è importante Questa è una pietra miliare critica per misurare il lead time dalla richiesta all'ordine. Ritardi in questa fase indicano colli di bottiglia nel passaggio dall'approvazione all'ufficio acquisti. Dove trovare Questo è un evento esplicito. Il collegamento tra la richiesta e l'ordine d'acquisto è memorizzato in tabelle come PO_LINE_LOCATIONS_ALL, che contiene un riferimento all'ID della riga della richiesta sorgente. Acquisisci Trovare la data di creazione dell'ordine d'acquisto che fa riferimento al dato ID della richiesta. Tipo di evento explicit
	Richiesta chiusa	Indica la chiusura finale del ciclo di vita di una richiesta, ovvero che tutte le sue righe sono state soddisfatte (es. convertite in PO) o annullate. Questo viene dedotto da un aggiornamento dello stato finale.
Perché è importante Questo è il principale evento di fine con successo del processo. Conferma che la richiesta è stata elaborata completamente e non è richiesta alcuna ulteriore azione. Dove trovare Dedotto dal cambio dello stato della testata della richiesta in "CLOSED" nella tabella POR_REQUISITION_HEADERS_ALL. Acquisisci Identificare il timestamp di quando lo stato del documento della richiesta passa a "Closed" (Chiusa). Tipo di evento inferred
	Richiesta Creata	Segna l'avvio del processo di approvvigionamento quando un utente salva per la prima volta una nuova richiesta di acquisto. Questo evento viene solitamente registrato come creazione esplicita di un record con relativo timestamp nel sistema.
Perché è importante Questo è l'evento di inizio principale per il processo di richiesta. Analizzare il tempo dalla creazione all'invio può rivelare ritardi nella formalizzazione della richiesta. Dove trovare Questo evento è registrato nella tabella POR_REQUISITION_HEADERS_ALL, acquisito dalla colonna creation_date quando viene generato un nuovo ID richiesta. Acquisisci Utilizzi il timestamp di creazione per il record di intestazione della richiesta. Tipo di evento explicit
	Richiesta di acquisto approvata	Indica l'approvazione finale della richiesta di acquisto dopo che ha superato con successo tutti i passaggi del workflow. Si deduce dal cambio dello stato generale della richiesta in 'Approvato'.
Perché è importante Questa è una pietra miliare chiave che indica che la richiesta è pronta per l'azione di acquisto. È il punto finale per misurare il tempo di ciclo totale dell'approvazione della richiesta. Dove trovare Dedotto dal cambio del campo dello stato del documento in "APPROVED" nella tabella POR_REQUISITION_HEADERS_ALL. La data di questo cambio di stato rappresenta l'ora dell'evento. Acquisisci Identificare il timestamp di quando lo stato del documento viene impostato per la prima volta su "Approved" (Approvata). Tipo di evento inferred
	Richiesta inviata	Rappresenta l'azione dell'utente che invia la richiesta completata nel workflow di approvazione. Viene rilevato quando lo stato della richiesta passa da 'Incompleta' o 'Bozza' a uno stato che indica l'attesa di approvazione.
Perché è importante Questa attività avvia il ciclo di approvazione. È una pietra miliare critica per misurare il tempo di ciclo di approvazione delle richieste e i lead time complessivi. Dove trovare Dedotto da un cambio di stato nella tabella POR_REQUISITION_HEADERS_ALL (es. lo stato passa a "PENDING APPROVAL"). Spesso anche la data di invio viene memorizzata esplicitamente. Acquisisci Identificare il timestamp di quando il campo dello stato del documento passa per la prima volta a "Pending Approval" (In attesa di approvazione). Tipo di evento inferred
	Richiesta rifiutata	Rappresenta il rifiuto finale della richiesta, che termina il processo. Si deduce quando lo stato generale della richiesta viene aggiornato a 'Respinto'.
Perché è importante Questa attività è il punto finale per le richieste non andate a buon fine. L'analisi di questi casi è essenziale per comprendere il KPI del Tasso di rifiuto delle richieste e i motivi del fallimento. Dove trovare Dedotto dal cambio dello stato del documento in "REJECTED" nella tabella POR_REQUISITION_HEADERS_ALL. Acquisisci Identificare il timestamp di quando lo stato del documento viene impostato per la prima volta su "Rejected" (Rifiutata). Tipo di evento inferred
	Fase di Approvazione Approvata	Rappresenta l'azione del singolo approvatore che approva la richiesta nel passaggio previsto del workflow. L'evento viene registrato esplicitamente nella cronologia delle approvazioni.
Perché è importante Il tracciamento dei singoli passaggi di approvazione aiuta a mappare il percorso reale e a misurare il tempo di elaborazione in ogni fase della gerarchia. Dove trovare Acquisito dalla cronologia delle azioni di approvazione della richiesta, solitamente memorizzata nelle tabelle di workflow (WF) o Human Capital Management (HCM) che gestiscono le gerarchie di approvazione. Acquisisci Utilizzi il timestamp dell'azione 'APPROVA' dal log della cronologia delle azioni del workflow. Tipo di evento explicit
	Fase di Approvazione Avviata	Indica il momento in cui una richiesta viene assegnata a uno specifico approvatore o gruppo di approvazione all'interno del workflow. Viene rilevato dal log delle transazioni del motore di workflow.
Perché è importante Questa attività è fondamentale per calcolare il tempo di attesa per ogni fase di approvazione. Aiuta a individuare i colli di bottiglia causati da specifici approvatori o livelli di approvazione. Dove trovare Recuperato dalle tabelle di workflow di Oracle Fusion, che registrano le attività assegnate agli utenti. Viene utilizzato il timestamp di assegnazione del task di approvazione. Acquisisci Utilizzi il timestamp di creazione dell'attività nella cronologia del workflow per la richiesta data. Tipo di evento explicit
	Fase di approvazione restituita	Un approvatore restituisce la richiesta a chi l'ha preparata per informazioni aggiuntive o piccole correzioni, senza rifiutarla formalmente. In genere si tratta di un'azione esplicita nel sistema di workflow.
Perché è importante Questo indica la necessità di chiarimenti e crea un loop di rielaborazione che allunga il tempo di ciclo. Differenziare le restituzioni dai rifiuti offre una comprensione più profonda degli attriti nel processo. Dove trovare Acquisito dalla cronologia delle azioni di approvazione della richiesta. Il sistema di workflow registra un'azione "RETURN" o simile con un timestamp. Acquisisci Utilizzi il timestamp dell'azione 'RESTITUISCI' o 'Richiesta di informazioni' dalla cronologia del workflow. Tipo di evento explicit
	Fase di Approvazione Rifiutata	Un singolo approvatore rifiuta la richiesta, il che solitamente la rimanda al preparatore per la correzione o annulla la richiesta. Questa azione viene registrata esplicitamente nella cronologia del workflow.
Perché è importante Questa attività è uno dei principali motori di rielaborazioni e ritardi. L'analisi dei rifiuti aiuta a identificare problemi di conformità, questioni di budget o giustificazioni poco chiare. Dove trovare Acquisito dalla cronologia delle azioni di approvazione della richiesta. Il sistema di workflow registra un'azione "REJECT" con un timestamp. Acquisisci Utilizzi il timestamp dell'azione 'RESPINGI' dal log della cronologia delle azioni del workflow. Tipo di evento explicit
	Richiesta modificata	Questo evento indica che un utente ha modificato una richiesta dopo l'invio iniziale, richiedendo spesso il riavvio del processo di approvazione. Si deduce rilevando modifiche a campi dati chiave o la creazione di una nuova versione della richiesta.
Perché è importante Modifiche frequenti indicano problemi di qualità dei dati o requisiti mutevoli, portando a rilavorazioni e ritardi. Questo supporta direttamente il KPI "Requisition Amendment Rate". Dove trovare Dedotto tracciando i numeri di versione della richiesta o identificando i cambiamenti di stato che tornano a "Incomplete" (Incompleta) dopo l'invio. Anche i log delle modifiche o le tabelle di audit trail possono catturare queste modifiche. Acquisisci Identificare i timestamp di creazione di nuove versioni per lo stesso ID richiesta dopo che è stato inviato. Tipo di evento inferred
	Richiesta ritirata	Si verifica quando il richiedente annulla o ritira una richiesta inviata prima che sia stata completamente approvata. Di solito si tratta di un'azione esplicita dell'utente che comporta un cambio di stato.
Perché è importante Tracciare i ritiri aiuta a identificare i motivi della chiusura anticipata, come il cambiamento delle esigenze aziendali o la correzione di errori da parte degli utenti dopo l'invio. Dove trovare Dedotto da un cambio di stato in "WITHDRAWN" nella tabella POR_REQUISITION_HEADERS_ALL. L'azione viene registrata nella cronologia delle azioni della richiesta. Acquisisci Rilevare il timestamp di quando lo stato della richiesta viene aggiornato a "Withdrawn" (Ritirata). Tipo di evento inferred

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i tuoi dati da Oracle Fusion Financials

Fasi

Navigare verso Reports and Analytics: Acceda a Oracle Fusion Financials. Utilizzi il menu Navigator per andare su Strumenti, quindi selezioni Reports and Analytics. Questo è l'hub centrale per tutte le attività di reportistica.
Creare una nuova Analisi: All'interno dell'area di lavoro Reports and Analytics, clicchi sul pulsante "Crea" e selezioni "Analisi" dal menu a discesa. Questo avvierà l'editor di analisi di Oracle Transactional Business Intelligence (OTBI) in una nuova scheda.
Selezionare 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 punti dati necessari per gli eventi del ciclo di vita delle richieste.
Costruire l'analisi per gli eventi di richiesta: Questo passaggio richiede la creazione di un'unione di diverse query per catturare ogni evento distinto. Poiché l'interfaccia utente di OTBI non dispone di una funzione UNION ALL diretta per diversi tipi di eventi, creerà un unico report estraendo tutti i campi rilevanti di data e stato. Nella scheda "Criteri", trascini le colonne elencate nella sezione query dal riquadro "Aree tematiche" a sinistra nell'area "Colonne selezionate". Ciò include colonne per data di creazione, data di invio, data di approvazione, data di creazione dell'ordine d'acquisto (PO), ecc.
Aggiungere la cronologia delle azioni della richiesta: Per acquisire i passaggi dettagliati dell'approvazione (Approvata, Rifiutata, Restituita, Ritirata), è necessario includere i campi della cartella "Requisition Action History" all'interno dell'area tematica. Trascini "Action Date", "Action" e "Performer" nelle colonne selezionate.
Configurare i filtri: Passi alla scheda "Prompt" per creare i filtri per l'analisi. È essenziale filtrare per intervallo di date per gestire il volume dei dati. Crei un filtro su "Requisition Header"."Requisition Creation Date" e lo imposti su un intervallo, ad esempio gli ultimi 6 mesi. Può anche aggiungere prompt per "Business Unit" o "Requester Name" per restringere i dati.
Eseguire e revisionare il report: Vada alla scheda "Risultati" per eseguire l'analisi e visualizzare l'anteprima dei dati. L'output sarà una tabella "larga" con una riga per riga di richiesta o azione di approvazione, contenente diverse colonne di data e stato.
Esportare i dati grezzi: Una volta soddisfatto dell'anteprima, clicchi sul link "Esporta", solitamente situato in fondo alla pagina dei risultati. Scelga "Dati" > "File CSV" come formato. Questo scaricherà i dati grezzi della Sua analisi.
Trasformare i dati nel formato Event Log: Il file CSV esportato sarà in formato largo. Deve utilizzare uno strumento esterno (come uno script Python, Power Query in Excel o un altro strumento di preparazione dati) per trasformare questi dati. Il processo prevede l'annullamento del pivot ("unpivoting") delle colonne di data in un'unica colonna "EventTime" e la creazione di una colonna "ActivityName" corrispondente per ogni tipo di evento (ad esempio, "Requisition Created", "Requisition Submitted").
Finalizzare e preparare per il caricamento: Dopo la trasformazione, si assicuri che il file abbia le colonne richieste: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate. Salvi l'event log finale come file CSV, che potrà poi essere caricato su ProcessMind.

Configurazione

Area tematica: L'area tematica principale da utilizzare è "Procurement - Requisitions Real Time". Contiene tutte le informazioni principali su testata, riga, distribuzione e cronologia delle approvazioni delle richieste.
Intervallo di date: Applichi sempre un filtro data obbligatorio per limitare il volume dei dati e migliorare le prestazioni. Un filtro su "Requisition Header"."Requisition Creation Date" per gli ultimi 3-6 mesi è un ottimo punto di partenza.
Filtri chiave: Valuti l'aggiunta di filtri per "Requisition Header"."Business Unit" e "Requisition Header"."Requisition Status" per focalizzare l'estrazione sulle unità organizzative pertinenti ed escludere stati non rilevanti come "Canceled" se non necessari per l'analisi.
Selezione delle colonne: Sia selettivo con le colonne che aggiunge all'analisi. L'inclusione di troppe colonne, specialmente da molte cartelle diverse (dimensioni), può influire negativamente sulle prestazioni. Si concentri solo sui campi necessari per l'event log.
Autorizzazioni: L'utente che esegue l'estrazione deve avere un ruolo con i permessi necessari 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.

a Query di Esempio config

/*
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'

Fasi

Acceda a Oracle Fusion Financials con un utente che disponga dei privilegi BI Author o simili.
Navighi verso l'area di lavoro Reports and Analytics cliccando sull'icona Navigator, quindi selezionando Strumenti > Reports and Analytics.
Clicchi sul pulsante "Sfoglia catalogo" per aprire il catalogo di Business Intelligence Publisher.
Nell'interfaccia di BI Publisher, clicchi su "Nuovo" e selezioni "Modello dati" dall'elenco a discesa.
Nelle proprietà del Modello dati, è possibile fornire un nome e una descrizione. Clicchi sull'icona "+" per aggiungere un nuovo Set di dati e selezioni "Query SQL".
Nella finestra di dialogo del nuovo Set di dati, fornisca un nome (ad esempio, Requisition_Event_Log), selezioni la Data Source appropriata per i Suoi dati Financials (ad esempio, ApplicationDB_FSCM) e imposti il Tipo di SQL su "SQL standard".
Copi lo script SQL completo dalla sezione "query" di questo documento e lo incolli nell'area di testo Query SQL.
La query include i parametri :p_start_date e :p_end_date, che verranno riconosciuti automaticamente da BI Publisher. Può impostare dei valori predefiniti, se lo desidera.
Salvi il Modello dati in una cartella del catalogo adatta (ad esempio, Cartelle condivise/Personalizzato).
Per esportare i dati, torni al catalogo, clicchi su "Nuovo" e selezioni "Report". Colleghi questo nuovo report al Modello dati appena creato.
Esegua il report, fornendo i parametri di data iniziale e finale. Una volta che il report visualizza i dati, utilizzi la funzione "Esporta" per scaricare i risultati come file CSV.
Si assicuri che il file CSV finale sia salvato con codifica UTF-8 e contenga le intestazioni richieste per l'importazione nel Suo strumento di process mining.

Configurazione

Origine dati: La Data Source di BI Publisher, solitamente denominata "ApplicationDB_FSCM" o simile, deve essere configurata con un utente che abbia accesso in lettura a tutte le tabelle della query, incluse quelle di Procurement (POR, PO), Human Capital Management (PER, HR) e Financials (FUN).
Filtro intervallo di date: La query è progettata con parametri di data obbligatori (:p_start_date e :p_end_date) che filtrano in base alla data di creazione della richiesta. Per le estrazioni iniziali o in sistemi di grandi dimensioni, è fondamentale estrarre i dati in batch gestibili, ad esempio da 3 a 6 mesi alla volta, per evitare timeout del sistema.
Filtro per Business Unit: Un filtro per il nome della Business Unit è incluso in una sezione commentata della clausola WHERE della query. Si consiglia vivamente di decommentare e configurare questo filtro per limitare i dati alle unità aziendali rilevanti per l'analisi, il che può migliorare significativamente le prestazioni.
Prerequisiti: L'utente che crea ed esegue il report deve avere un ruolo con privilegi BI Publisher, come "BI Administrator Role" o "BI Author Role". Inoltre, questo utente necessita delle autorizzazioni di sicurezza dei dati necessarie per accedere ai dati di approvvigionamento.

a 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'

Fasi

Prerequisiti e configurazione dell'ambiente: Si assicuri di avere Python 3 installato sul sistema. Installi la libreria requests necessaria eseguendo il comando seguente nel terminale: pip install requests. Avrà inoltre bisogno delle credenziali API (nome utente, password) per un utente Oracle Fusion con permessi sufficienti per leggere i dati delle richieste d'acquisto, insieme all'URL di base della Sua istanza Oracle Fusion.
Salvare lo script Python: Salvi il codice Python completo fornito nella sezione "query" come file, ad esempio extract_requisitions.py.
Configurare i parametri dello script: Apra il file dello script in un editor di testo. Modifichi i valori segnaposto all'inizio dello script. Imposti FUSION_URL, USERNAME e PASSWORD in base ai dettagli del Suo ambiente Oracle Fusion. Regoli START_DATE e END_DATE per definire il periodo di estrazione.
Comprendere Endpoint e Campi API: Lo script punta alla risorsa REST API purchaseRequisitions. Utilizza il parametro fields per richiedere solo i dati necessari, incluse collezioni annidate come lines (per le informazioni sull'ordine d'acquisto) e actionHistory (per gli eventi di approvazione), migliorando così le prestazioni.
Eseguire lo script: Esegua lo script dal terminale usando il comando: python extract_requisitions.py. Lo script si autenticherà con l'API, inizierà a recuperare i dati e stamperà gli aggiornamenti sull'avanzamento nella console, mostrando quante richieste sono state elaborate.
Gestire la paginazione: Lo script gestisce automaticamente la paginazione. La REST API di Oracle Fusion restituisce i dati in blocchi (pagine). Lo script controlla il flag hasMore in ogni risposta ed effettua ripetutamente richieste con un parametro offset aggiornato finché tutte le richieste nell'intervallo di date specificato non sono state recuperate.
Logica di trasformazione dei dati: Per ogni richiesta recuperata dall'API, lo script genera più righe nell'event log. Crea un evento "Requisition Created" dalla CreationDate, un evento "Requisition Submitted" dalla SubmittedDate e itera attraverso la collezione actionHistory per creare eventi dettagliati per ogni fase di approvazione (Iniziata, Approvata, Rifiutata, Restituita).
Inferire gli eventi di stato finale: Lo script acquisisce gli eventi di esito finale come "Requisition Approved" e "Requisition Rejected" controllando il DocumentStatus finale della richiesta e utilizzando LastUpdateDate come timestamp dell'evento.
Generare l'evento dell'Ordine d'Acquisto: Lo script ispeziona ogni riga della richiesta. Se una riga ha un PoHeaderId, significa che è stato creato un Ordine d'Acquisto (PO). Viene generata una voce nell'event log per questa attività, collegando la richiesta al processo di approvvigionamento a valle.
Revisionare il file di output: Al termine dello script, verrà creato un file CSV denominato oracle_fusion_requisitions_event_log.csv nella stessa directory. Questo file contiene l'event log estratto.
Preparare per il caricamento: Apra il file CSV generato in un programma per fogli di calcolo per verificarne il contenuto. Si assicuri che le colonne e i formati dei dati corrispondano ai requisiti del Suo strumento di process mining. Il file è ora pronto per essere caricato su ProcessMind.

Configurazione

Credenziali API: È necessario un account utente dedicato all'integrazione con un ruolo che garantisca l'accesso in sola lettura alla REST API delle Purchase Requisitions. Esempi di ruoli includono Procurement Manager o un ruolo di integrazione personalizzato.
Endpoint REST API: Il codice è configurato per utilizzare l'endpoint .../fscmRestApi/resources/11.13.18.05/purchaseRequisitions. Si assicuri che il numero di versione nell'URL corrisponda al Suo ambiente Oracle Fusion.
Filtro intervallo di date: Lo script include le variabili START_DATE e END_DATE. Si consiglia vivamente di estrarre i dati in batch gestibili, ad esempio da 3 a 6 mesi alla volta, per evitare timeout delle API e problemi di prestazioni. Il filtro viene applicato alla CreationDate delle richieste.
Selezione dei campi: Il parametro fields nello script è fondamentale per le prestazioni. Limita il payload della risposta ai soli attributi necessari per l'event log, riducendo il traffico di rete e i tempi di elaborazione. Non rimuova i campi obbligatori come RequisitionId, CreationDate, actionHistory o lines.
Limite di paginazione: Il parametro limit è impostato a 100, un valore sicuro per la maggior parte degli ambienti. Può provare ad aumentarlo a 200 o 500 per un'estrazione potenzialmente più rapida, ma presti attenzione a possibili problemi di memoria o limiti delle API se impostato troppo alto.

a 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()

Fasi

Navigare verso Reports and Analytics: Acceda a Oracle Fusion Financials. Utilizzi il menu Navigator per andare su Strumenti, quindi selezioni Reports and Analytics. Questo è l'hub centrale per tutte le attività di reportistica.
Creare una nuova Analisi: All'interno dell'area di lavoro Reports and Analytics, clicchi sul pulsante "Crea" e selezioni "Analisi" dal menu a discesa. Questo avvierà l'editor di analisi di Oracle Transactional Business Intelligence (OTBI) in una nuova scheda.
Selezionare 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 punti dati necessari per gli eventi del ciclo di vita delle richieste.
Costruire l'analisi per gli eventi di richiesta: Questo passaggio richiede la creazione di un'unione di diverse query per catturare ogni evento distinto. Poiché l'interfaccia utente di OTBI non dispone di una funzione UNION ALL diretta per diversi tipi di eventi, creerà un unico report estraendo tutti i campi rilevanti di data e stato. Nella scheda "Criteri", trascini le colonne elencate nella sezione query dal riquadro "Aree tematiche" a sinistra nell'area "Colonne selezionate". Ciò include colonne per data di creazione, data di invio, data di approvazione, data di creazione dell'ordine d'acquisto (PO), ecc.
Aggiungere la cronologia delle azioni della richiesta: Per acquisire i passaggi dettagliati dell'approvazione (Approvata, Rifiutata, Restituita, Ritirata), è necessario includere i campi della cartella "Requisition Action History" all'interno dell'area tematica. Trascini "Action Date", "Action" e "Performer" nelle colonne selezionate.
Configurare i filtri: Passi alla scheda "Prompt" per creare i filtri per l'analisi. È essenziale filtrare per intervallo di date per gestire il volume dei dati. Crei un filtro su "Requisition Header"."Requisition Creation Date" e lo imposti su un intervallo, ad esempio gli ultimi 6 mesi. Può anche aggiungere prompt per "Business Unit" o "Requester Name" per restringere i dati.
Eseguire e revisionare il report: Vada alla scheda "Risultati" per eseguire l'analisi e visualizzare l'anteprima dei dati. L'output sarà una tabella "larga" con una riga per riga di richiesta o azione di approvazione, contenente diverse colonne di data e stato.
Esportare i dati grezzi: Una volta soddisfatto dell'anteprima, clicchi sul link "Esporta", solitamente situato in fondo alla pagina dei risultati. Scelga "Dati" > "File CSV" come formato. Questo scaricherà i dati grezzi della Sua analisi.
Trasformare i dati nel formato Event Log: Il file CSV esportato sarà in formato largo. Deve utilizzare uno strumento esterno (come uno script Python, Power Query in Excel o un altro strumento di preparazione dati) per trasformare questi dati. Il processo prevede l'annullamento del pivot ("unpivoting") delle colonne di data in un'unica colonna "EventTime" e la creazione di una colonna "ActivityName" corrispondente per ogni tipo di evento (ad esempio, "Requisition Created", "Requisition Submitted").
Finalizzare e preparare per il caricamento: Dopo la trasformazione, si assicuri che il file abbia le colonne richieste: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate. Salvi l'event log finale come file CSV, che potrà poi essere caricato su ProcessMind.

Configurazione

Area tematica: L'area tematica principale da utilizzare è "Procurement - Requisitions Real Time". Contiene tutte le informazioni principali su testata, riga, distribuzione e cronologia delle approvazioni delle richieste.
Intervallo di date: Applichi sempre un filtro data obbligatorio per limitare il volume dei dati e migliorare le prestazioni. Un filtro su "Requisition Header"."Requisition Creation Date" per gli ultimi 3-6 mesi è un ottimo punto di partenza.
Filtri chiave: Valuti l'aggiunta di filtri per "Requisition Header"."Business Unit" e "Requisition Header"."Requisition Status" per focalizzare l'estrazione sulle unità organizzative pertinenti ed escludere stati non rilevanti come "Canceled" se non necessari per l'analisi.
Selezione delle colonne: Sia selettivo con le colonne che aggiunge all'analisi. L'inclusione di troppe colonne, specialmente da molte cartelle diverse (dimensioni), può influire negativamente sulle prestazioni. Si concentri solo sui campi necessari per l'event log.
Autorizzazioni: L'utente che esegue l'estrazione deve avere un ruolo con i permessi necessari 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.

a Query di Esempio config

/*
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'

Il Suo template per i dati delle richieste Purchase to Pay

Il Suo template per i dati delle richieste Purchase to Pay

Purchase to Pay - Attributi di richiesta

Purchase to Pay - Attività di richiesta

Guide all'Estrazione

Esportazione da Oracle Transactional Business Intelligence (OTBI)

Fasi

Configurazione

a Query di Esempio config

Estrazione del modello dati basata su SQL di Oracle BI Publisher

Fasi

Configurazione

a Query di Esempio sql

Script Python tramite API REST di Oracle Fusion

Fasi

Configurazione

a Query di Esempio python

Oracle BI Cloud Connector (BICC) Estrazione Massiva Dati

Fasi

Configurazione

a Query di Esempio config

Pronto per iniziare?

Velocizzare del 30% il ciclo di richiesta d'acquisto

Il Suo template per i dati delle richieste Purchase to Pay

Il Suo template per i dati delle richieste Purchase to Pay

Purchase to Pay - Attributi di richiesta

Purchase to Pay - Attività di richiesta

Guide all'Estrazione

Esportazione da Oracle Transactional Business Intelligence (OTBI)

Fasi

Configurazione

a Query di Esempio config

Estrazione del modello dati basata su SQL di Oracle BI Publisher

Fasi

Configurazione

a Query di Esempio sql

Script Python tramite API REST di Oracle Fusion

Fasi

Configurazione

a Query di Esempio python

Oracle BI Cloud Connector (BICC) Estrazione Massiva Dati

Fasi

Configurazione

a Query di Esempio config

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Velocizzare del 30% il ciclo di richiesta d'acquisto