> Miglioramento continuo dei processi > Purchase to Pay Requisition > Oracle Fusion Financials > Template dei dati

Il Suo Template dei dati Purchase to Pay - Requisition

Oracle Fusion Financials

Purchase to Pay - Requisition: attributi (22) Purchase to Pay - Requisition: attività (12) Guide all'estrazione (4)

Il Suo Template dei dati Purchase to Pay - Requisition

Questo Template offre una roadmap chiara per raccogliere i dati essenziali necessari ad analizzare il processo Purchase to Pay - Requisition. Indica gli attributi principali da raccogliere, le attività critiche da monitorare e indicazioni pratiche per estrarre queste informazioni da Oracle Fusion Financials. In questo modo potrà preparare efficacemente il Suo event log per un'analisi di Process Mining ricca di insight.

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

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

Scarica il Template

Purchase to Pay - Requisition: attributi

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
	Attività ActivityName	Il nome dell'evento aziendale che si è verificato in un determinato momento del processo della richiesta.
Descrizione L'attività rappresenta una fase o una milestone distinta nel ciclo di vita della richiesta di acquisto. Tra gli esempi rientrano 'Requisition Created', 'Approval Step Approved' e 'Purchase Order Created'. Queste attività derivano da modifiche dello stato, azioni degli utenti o eventi di sistema registrati nei registri 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. L'analisi della sequenza e della frequenza delle attività aiuta a individuare percorsi di processo ricorrenti, colli di bottiglia, cicli di rilavorazione e deviazioni dalla procedura standard. Perché è importante Costituisce la struttura portante della mappa di processo e consente di visualizzare e analizzare il Workflow della richiesta. Dove reperirlo Derivato dai record delle modifiche dello stato in tabelle come POR_REQUISITION_HEADERS_ALL, dallo storico delle transazioni o dagli audit trail del Workflow, come FA_FUSION_SOAINFRA.WFTASK. Esempi Richiesta creataFase di approvazione approvataRichiesta rifiutataOrdine di acquisto creato
	ID richiesta di acquisto PurchaseRequisitionId	L'identificativo univoco di una richiesta di acquisto, utilizzato come ID del caso per il processo.
Descrizione L'ID richiesta di 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 creazione, invio, fasi di approvazione e chiusura finale. Ciò consente di analizzare il percorso della richiesta dall'inizio alla fine, visualizzare le mappe di processo, calcolare i tempi di ciclo e analizzare le varianti per ogni singola richiesta. Perché è importante È l'Attributo fondamentale per monitorare il ciclo di vita della richiesta dall'inizio alla fine e consente tutte le analisi a livello di caso e i calcoli dei KPI. Dove reperirlo È generalmente la chiave primaria nella tabella dell'intestazione della richiesta, 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 precise 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 specifici delle azioni nel sistema. Nell'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 della richiesta. Perché è importante Questo Attributo è essenziale per calcolare tutti i KPI relativi ai tempi, ordinare correttamente gli eventi e analizzare le prestazioni e i colli di bottiglia del processo. Dove reperirlo In genere proviene da una colonna 'LAST_UPDATE_DATE' o 'CREATION_DATE' associata alla transazione o alla modifica dello stato, spesso presente in tabelle come POR_REQUISITION_HEADERS_ALL o nelle tabelle dello storico del Workflow. Esempi 2023-04-15T10:30:00Z2023-04-15T11:05:21Z2023-04-16T09:00:15Z
	Sistema di origine SourceSystem	Il sistema informativo dal quale sono stati estratti questi dati.
Descrizione Questo Attributo identifica l'origine dei dati di processo. Per questo modello dati, il valore sarà sempre 'Oracle Fusion Financials'. Negli ambienti con più ERP o sistemi integrati, questo campo è fondamentale per la tracciabilità dei dati, la risoluzione dei problemi e la garanzia della qualità dei dati. Fornisce il contesto sull'origine autorevole degli eventi di processo analizzati. Perché è importante Fornisce un contesto essenziale sull'origine dei dati, fondamentale per la governance dei dati e per l'integrazione di dati provenienti da più sistemi. Dove reperirlo È un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per indicare l'origine del dataset. 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 applica all'intero dataset e non ai singoli eventi. Gli analisti utilizzano queste informazioni per comprendere l'aggiornamento dei dati e verificare quando sono state incluse le transazioni più recenti. Si tratta di un elemento essenziale dei metadati per i report nei Dashboard e per garantire che le analisi si basino su informazioni aggiornate. Perché è importante Informa gli utenti sull'aggiornamento dei dati, garantendo che le analisi siano pertinenti e basate sulle informazioni più recenti disponibili. Dove reperirlo Questo timestamp viene generato e memorizzato durante il processo di estrazione dei dati, generalmente dallo strumento ETL o dalla pipeline dati. Esempi 2023-10-27T02:00:00Z
	Data richiesta RequiredByDate	La data entro la quale il richiedente necessita dei beni o dei servizi.
Descrizione Questa data viene indicata dal richiedente per specificare il termine entro il quale ricevere gli articoli richiesti. Funge da obiettivo interno di livello di servizio (SLA) per il processo di approvvigionamento. Questo Attributo costituisce la base del 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 di acquisto o di ricezione dei beni, l'analisi può mostrare quanto il processo di approvvigionamento soddisfi le esigenze dei clienti interni e individuare ritardi sistemici. Perché è importante È fondamentale per misurare le prestazioni del processo rispetto alle scadenze interne e comprendere se il processo di approvvigionamento soddisfa tempestivamente le esigenze aziendali. Dove reperirlo Di norma viene 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 di acquisto.
Descrizione Questo Attributo rappresenta la somma del valore di tutte le righe 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 numerose analisi. Può servire a filtrare le richieste di importo elevato, che spesso seguono percorsi di approvazione diversi o sono sottoposte a controlli più rigorosi. I Dashboard possono utilizzare questo Attributo per analizzare la correlazione tra metriche di processo, come il tempo di ciclo o il tasso di rifiuto, e il valore della richiesta. Perché è importante Fornisce un contesto finanziario che consente analisi basate sul valore, utili per stabilire le priorità degli interventi di miglioramento del processo e comprendere l'impatto del valore della richiesta sul comportamento del processo. Dove reperirlo Si trova nell'intestazione della richiesta, spesso in un campo come REQUISITION_TOTAL di POR_REQUISITION_HEADERS_ALL. Può anche essere calcolato sommando gli importi delle righe dalla tabella POR_REQUISITION_LINES_ALL. Esempi 550.0012500.7599.99
	Motivo del rifiuto RejectionReason	Il motivo fornito da un approvatore quando una richiesta o una fase di approvazione viene rifiutata.
Descrizione Quando una richiesta viene rifiutata, l'approvatore fornisce generalmente un motivo, selezionandolo da un elenco predefinito oppure inserendo testo libero. Questo Attributo acquisisce tale motivazione. È fondamentale per l'analisi delle cause principali dei problemi di processo. Supporta direttamente il Dashboard 'Andamento delle modifiche e dei rifiuti', fornendo la spiegazione alla base dei rifiuti. L'analisi dei motivi di rifiuto aiuta a individuare problemi ricorrenti, come codifiche errate, superamenti del budget o violazioni delle policy, che possono essere affrontati con formazione o controlli di sistema. Perché è importante Fornisce una visione diretta delle cause dei rifiuti delle richieste, consentendo miglioramenti mirati per ridurre le rilavorazioni e aumentare il tasso di elaborazione straight-through. Dove reperirlo Proviene dai commenti del Workflow o da specifici campi relativi ai codici dei motivi di rifiuto nell'audit trail del Workflow, potenzialmente nelle tabelle collegate a FA_FUSION_SOAINFRA.WFTASK o nei relativi archivi dei commenti. Esempi Conto Co.Ge. erratoBudget del centro di costo superatoFornitore non preferenziale selezionatoRichiesta duplicata
	Nome del richiedente RequesterName	Il nome del dipendente che ha creato e inviato la richiesta di acquisto.
Descrizione Questo Attributo identifica la persona che ha avviato la richiesta di beni o servizi. Di norma, queste informazioni vengono acquisite all'inizio del processo, quando la richiesta viene creata per la prima volta. L'analisi delle prestazioni del processo per richiedente è fondamentale per il Dashboard 'Metriche delle prestazioni dei richiedenti'. Aiuta a individuare gli utenti o i gruppi che potrebbero necessitare di ulteriore formazione, evidenziando tassi elevati di modifiche o rifiuti oppure tempi di ciclo lunghi associati alle loro richieste. Offre una visione del processo incentrata sulle persone. Perché è importante Consente di analizzare le prestazioni per richiedente, aiutando a individuare le esigenze formative e a mettere in evidenza gli utenti o i reparti più efficienti. Dove reperirlo Proviene dai dati dell'intestazione della richiesta, spesso collegando l'ID del richiedente a una tabella anagrafica dei dipendenti o degli utenti. Cercare i campi relativi a 'PREPARER_ID' in POR_REQUISITION_HEADERS_ALL e collegarli a PER_ALL_PEOPLE_F. Esempi John SmithJane DoeEmily Jones
	Reparto DepartmentName	Il reparto aziendale di appartenenza del richiedente.
Descrizione Questo Attributo indica l'unità organizzativa della persona che ha creato la richiesta, ad esempio 'Finance', 'IT' o 'Marketing'. In genere deriva dal profilo utente 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, che possono orientare iniziative mirate di miglioramento del processo. È una dimensione fondamentale per il Dashboard 'Metriche delle prestazioni dei richiedenti'. Perché è importante Consente di analizzare il processo per unità aziendale, mettendo in evidenza modelli, prestazioni e problemi di conformità specifici dei reparti. Dove reperirlo In genere deriva dal profilo del richiedente e spesso richiede un collegamento tra la tabella delle richieste e una tabella HR o una directory degli utenti contenente le informazioni sul reparto. Esempi Tecnologie dell'informazioneFinanzaOperationsMarketing
	Stato della richiesta RequisitionStatus	Lo stato attuale o finale della richiesta di acquisto.
Descrizione Questo Attributo indica lo stato complessivo della richiesta in un determinato momento o il suo esito finale, ad esempio 'Approved', 'Rejected', 'In Process' o 'Closed'. Spesso costituisce la fonte da cui vengono derivate molte attività nell'Event Log. Questo Attributo è fondamentale per il Dashboard 'Panoramica dello stato delle richieste', che offre una fotografia del carico di lavoro e dell'arretrato attuali. Viene inoltre utilizzato per calcolare 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 viene utilizzato per determinare gli esiti finali ai fini del calcolo dei KPI. Dove reperirlo Si trova nella tabella dell'intestazione della richiesta, generalmente in un campo come 'DOCUMENT_STATUS' o 'APPROVAL_STATUS' di POR_REQUISITION_HEADERS_ALL. Esempi APPROVATAIN CORSORIFIUTATARITIRATA
	Unità aziendale BusinessUnit	La specifica unità aziendale dell'organizzazione a cui appartiene la richiesta.
Descrizione L'unità aziendale rappresenta un'entità legale o funzionale distinta all'interno dell'azienda per la quale viene effettuata la richiesta. È un raggruppamento organizzativo di livello superiore rispetto al reparto. L'analisi dei dati per unità aziendale consente confronti ad alto livello delle prestazioni tra diverse aree dell'organizzazione. Aiuta il senior management a comprendere se le inefficienze di processo sono circoscritte o diffuse e dove concentrare gli interventi di miglioramento. È una dimensione fondamentale per filtrare quasi tutti i Dashboard e i KPI. Perché è importante Fornisce un contesto organizzativo di alto livello, consentendo confronti delle prestazioni e analisi strategiche tra diverse aree dell'azienda. Dove reperirlo È un campo organizzativo fondamentale in Oracle Fusion, generalmente disponibile nell'intestazione della richiesta in tabelle come POR_REQUISITION_HEADERS_ALL. Esempi BU Nord AmericaBU EuropaSede centrale aziendale
	Automatizzato 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. Tra gli esempi rientrano le modifiche di stato gestite dal sistema o i passaggi di approvazione automatizzati per gli articoli di basso 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 con quelle dei passaggi manuali e per individuare ulteriori opportunità di automazione. Perché è importante Aiuta a misurare il livello di automazione del processo e a individuare opportunità per automatizzare le attività manuali. Dove reperirlo Derivato verificando se l'utente associato a un'attività è un account di sistema o di servizio. È necessario disporre di un elenco degli ID utente di sistema noti. Esempi truefalse
	Descrizione dell'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 non strutturata, la descrizione dell'articolo offre un contesto prezioso per l'analisi. Può essere utilizzata nei filtri per isolare le richieste relative a specifici tipi di acquisto che potrebbero non essere identificati dal tipo di richiesta. Ad esempio, un analista potrebbe cercare tutte le richieste contenenti 'Software License' per comprenderne il flusso di processo e il tempo di ciclo specifici. Perché è importante Offre un contesto dettagliato sull'oggetto dell'acquisto e consente filtri e analisi più granulari di beni o servizi specifici. Dove reperirlo Si trova nella tabella delle righe della richiesta, POR_REQUISITION_LINES_ALL, in un campo come ITEM_DESCRIPTION. Esempi Laptop da 15 pollici, 16 GB di RAMServizi di consulenza - Progetto del quarto trimestreRinnovo annuale della manutenzione software
	Flusso diretto 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. Indica che il processo è stato eseguito perfettamente per il singolo caso. Questo attributo costituisce la base per il KPI 'Straight-Through Requisition Rate'. L'analisi delle caratteristiche delle richieste straight-through, ad esempio reparti, richiedenti o tipologie ricorrenti, può far emergere best practice e opportunità di automazione. Al contrario, l'analisi delle richieste che non seguono un flusso straight-through aiuta a individuare i principali fattori di inefficienza. Perché è importante Misura direttamente l'efficienza del processo e costituisce la base per il KPI Straight-Through Requisition Rate, contribuendo a identificare i fattori che determinano la rilavorazione. Dove reperirlo Questo attributo viene calcolato durante la trasformazione dei dati. Un caso viene contrassegnato come true se non contiene attività 'Requisition Amended' o 'Approval Step Rejected'. Esempi truefalse
	Modificata IsAmendedFlag	Un flag booleano che assume il valore true se la richiesta è stata modificata almeno una volta.
Descrizione Questo attributo calcolato indica se una richiesta ha subito modifiche dopo l'invio iniziale. Viene determinato verificando la presenza dell'attività 'Requisition Amended' nella cronologia del caso. Questo indicatore semplifica l'analisi e il calcolo dei KPI. Viene utilizzato direttamente per calcolare il KPI 'Requisition Amendment Rate' e per identificare i casi che non seguono un flusso straight-through. 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 reperirlo Questo attributo non è presente nel sistema di origine, ma viene calcolato durante la trasformazione dei dati in base alla presenza di attività correlate alle modifiche nell'event log. Esempi truefalse
	Nome del fornitore SupplierName	Il nome del fornitore suggerito o preselezionato per i beni o servizi.
Descrizione Questo Attributo identifica il fornitore dal quale si intende acquistare i beni o i servizi. Il fornitore può essere suggerito dal richiedente oppure determinato dal sistema in base a cataloghi o accordi precedenti. L'analisi per fornitore può rivelare importanti modelli di approvvigionamento. Ad esempio, può aiutare a individuare 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 delle relazioni con i fornitori e per la strategia di approvvigionamento. Perché è importante Consente di analizzare le prestazioni del processo per fornitore, fornendo indicazioni utili per la strategia di sourcing e la gestione delle relazioni con i fornitori. Dove reperirlo 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 un editor.
Descrizione Mentre il nome del richiedente identifica l'iniziatore, il nome utente specifica la persona che ha eseguito un determinato evento del processo, come un'approvazione o un rifiuto. Questo è particolarmente importante nei Workflow di approvazione a più fasi, nei quali sono coinvolte persone diverse. Questo Attributo è fondamentale per analizzare i colli di bottiglia nelle approvazioni e misurare le prestazioni di specifici approvatori o team. Supporta direttamente il Dashboard 'Colli di bottiglia del Workflow di approvazione', consentendo di analizzare i tempi di elaborazione per ogni utente coinvolto nella catena di approvazione. Perché è importante Identifica l'attore di ogni evento, un elemento essenziale per analizzare i tempi di passaggio, le prestazioni degli approvatori e l'allocazione delle risorse. Dove reperirlo Proviene dalle tabelle dello storico del Workflow o dell'audit trail, come FA_FUSION_SOAINFRA.WFTASK, che registra l'utente associato al completamento di ogni attività. Esempi David LeeSusan ChenMichael Brown
	Numero dell'ordine di acquisto PurchaseOrderNumber	L'identificativo dell'ordine di acquisto creato dalla richiesta approvata.
Descrizione Questo Attributo collega una richiesta di acquisto all'ordine di acquisto risultante. Una volta approvata completamente, la richiesta viene generalmente convertita in uno o più ordini di acquisto da inviare a un fornitore. Nell'analisi, questo ID è essenziale per monitorare il processo a valle della richiesta. Consente di calcolare il KPI 'Tempo di attraversamento dalla richiesta all'ordine di acquisto' e supporta il Dashboard 'Tempo di ciclo dalla richiesta all'ordine di acquisto'. Permette inoltre di combinare i dati del processo della richiesta con i successivi processi relativi agli ordini di acquisto e alla fatturazione, per un'analisi end-to-end completa del processo Purchase-to-Pay. Perché è importante Collega la richiesta al successivo ordine di acquisto, consentendo di misurare il tempo di ciclo dalla richiesta all'ordine e analizzare il processo dall'inizio alla fine. Dove reperirlo Queste informazioni vengono memorizzate quando viene creato un ordine di acquisto. In genere si trovano nei riferimenti alla richiesta di origine presenti 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 del Workflow 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 determinata richiesta in base alle policy aziendali, considerando fattori quali importo, tipo e reparto della richiesta. Rappresenta il modello di processo 'to-be'. Il percorso del Workflow di approvazione è fondamentale per le analisi di conformità e conformance. Supporta direttamente il Dashboard 'Analisi della conformità e delle deviazioni' e il KPI 'Indice di conformance delle richieste', consentendo di confrontare direttamente le fasi di approvazione effettivamente eseguite con il percorso prescritto. Le deviazioni possono indicare violazioni delle policy o inefficienze di processo. Perché è importante Consente di verificare la conformance confrontando il flusso di processo effettivo con la gerarchia di approvazione richiesta e mettendo in evidenza le richieste non conformi. Dove reperirlo Queste informazioni sono configurate in Oracle Fusion BPM Worklist o nell'Approval Management Engine (AMX). L'estrazione del percorso definito per ogni richiesta può essere complessa e richiedere interrogazioni delle tabelle di configurazione. Esempi Manager > Direttore > VP FinanzaResponsabile del centro di costo > Sicurezza ITManager > Responsabile di reparto
	Tipo di richiesta RequisitionType	La categoria della richiesta, ad esempio una richiesta di beni o di servizi.
Descrizione Questo Attributo classifica la richiesta in base all'oggetto della richiesta. I tipi più comuni includono beni, servizi o spese in conto capitale. Il tipo può influenzare il Workflow di approvazione richiesto e la strategia di approvvigionamento. Nell'analisi, il tipo di richiesta è una dimensione efficace per filtrare e confrontare i dati. Ad esempio, è possibile verificare se le richieste di servizi presentano un tempo del ciclo di approvazione più lungo rispetto alle richieste di beni. Aiuta a comprendere se tipi diversi di richieste mostrano comportamenti di processo o colli di bottiglia differenti. Perché è importante Consente di segmentare l'analisi per comprendere come il processo varia in base ai diversi tipi di acquisto, ad esempio beni rispetto a servizi. Dove reperirlo Viene spesso determinato dal tipo o dalla categoria della riga selezionata durante la creazione della richiesta. Può essere memorizzato nella tabella delle righe della richiesta, POR_REQUISITION_LINES_ALL. Esempi BeniServiziSpese in conto capitale
	Valuta CurrencyCode	Il codice 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 qualsiasi analisi che coinvolga valori monetari, il codice valuta deve essere utilizzato per garantire confronti accurati, 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 gestiscono più valute. Dove reperirlo Si trova generalmente nella tabella dell'intestazione della richiesta, insieme ai campi relativi agli importi, ad esempio in POR_REQUISITION_HEADERS_ALL. Esempi USDEURGBPJPY

Obbligatorio Consigliato Facoltativo

Purchase to Pay - Requisition: attività

Questi sono i passaggi chiave e le principali tappe del processo da acquisire nell’Event Log per una corretta individuazione del processo Purchase to Pay - Requisition.

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 della richiesta al successivo processo di approvvigionamento.
Perché è importante È una milestone fondamentale per misurare il tempo di attraversamento dalla richiesta all'ordine di acquisto. I ritardi in questa fase indicano colli di bottiglia nel passaggio dall'approvazione all'acquisto. Dove reperirlo Si tratta di un evento esplicito. Il collegamento tra la richiesta e l'ordine di acquisto è memorizzato in tabelle come PO_LINE_LOCATIONS_ALL, che contiene un riferimento all'ID della riga di richiesta di origine. Acquisizione Individuare la data di creazione dell'ordine di acquisto che fa riferimento all'ID richiesta indicato. Tipo di evento explicit
	Richiesta approvata	Indica l'approvazione finale della richiesta di acquisto dopo il superamento di tutte le fasi del Workflow. L'evento viene dedotto dalla modifica dello stato complessivo della richiesta in 'Approved'.
Perché è importante È una milestone fondamentale, poiché indica che la richiesta è pronta per le attività di approvvigionamento. Rappresenta il punto finale per misurare il tempo complessivo del ciclo di approvazione della richiesta. Dove reperirlo Dedotto dalla modifica del campo dello stato del documento nella tabella POR_REQUISITION_HEADERS_ALL in 'APPROVED'. La data di questa modifica dello stato rappresenta l'ora dell'evento. Acquisizione Identificare il timestamp in cui lo stato del documento viene impostato per la prima volta su 'Approved'. Tipo di evento inferred
	Richiesta chiusa	Indica la chiusura definitiva del ciclo di vita della richiesta: tutte le righe sono state evase, ad esempio convertite in ordini di acquisto, oppure annullate. L'evento viene dedotto da un aggiornamento dello stato finale.
Perché è importante È il principale evento di chiusura positiva del processo. Conferma che la richiesta è stata elaborata completamente e che non sono necessarie ulteriori azioni. Dove reperirlo Dedotto dalla modifica dello stato dell'intestazione della richiesta nella tabella POR_REQUISITION_HEADERS_ALL in 'CLOSED'. Acquisizione Identificare il timestamp in cui lo stato del documento della richiesta cambia in 'Closed'. Tipo di evento inferred
	Richiesta creata	Indica l’avvio del processo di approvvigionamento, quando un utente salva per la prima volta una nuova richiesta di acquisto. Questo evento viene generalmente acquisito come registrazione esplicita della creazione, con il relativo timestamp nel sistema.
Perché è importante Questo è 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 reperirlo Questo evento viene registrato nella tabella POR_REQUISITION_HEADERS_ALL, acquisito dalla colonna creation_date quando viene generato un nuovo ID di richiesta. Acquisizione Utilizzi il timestamp di creazione del record di intestazione della richiesta. Tipo di evento explicit
	Richiesta inviata	Rappresenta l’azione dell’utente che invia la richiesta completata al Workflow di approvazione. Viene acquisito quando lo stato della richiesta passa da "Incomplete" o "Draft" a uno stato che indica che è in attesa di approvazione.
Perché è importante Questa attività avvia il ciclo di approvazione. Rappresenta una milestone fondamentale per misurare il tempo del ciclo di approvazione della richiesta e i tempi di attraversamento complessivi. Dove reperirlo Dedotto da una modifica dello stato nella tabella POR_REQUISITION_HEADERS_ALL, ad esempio quando lo stato passa a 'PENDING APPROVAL'. Spesso anche la data di invio è memorizzata esplicitamente. Acquisizione Identificare il timestamp in cui il campo dello stato del documento cambia per la prima volta in 'Pending Approval'. Tipo di evento inferred
	Richiesta rifiutata	Rappresenta il rifiuto definitivo della richiesta e termina il processo per questa richiesta. L'evento viene dedotto quando lo stato complessivo della richiesta viene aggiornato a 'Rejected'.
Perché è importante Questa attività rappresenta il punto terminale delle richieste non andate a buon fine. L'analisi di questi casi è essenziale per comprendere il KPI del tasso di rifiuto delle richieste e le cause dell'insuccesso. Dove reperirlo Dedotto dalla modifica dello stato del documento nella tabella POR_REQUISITION_HEADERS_ALL in 'REJECTED'. Acquisizione Identificare il timestamp 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 Workflow. L'evento viene registrato esplicitamente nello storico delle approvazioni.
Perché è importante Il monitoraggio delle singole fasi di approvazione consente di mappare il percorso di approvazione effettivo e misurare il tempo di elaborazione in ogni livello della gerarchia. Dove reperirlo Acquisito dallo storico delle azioni di approvazione della richiesta, generalmente memorizzato nelle tabelle del Workflow (WF) o di Human Capital Management (HCM) che gestiscono le gerarchie di approvazione. Acquisizione Utilizzare il timestamp dell'azione 'APPROVE' dal registro dello storico 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. Questo dato viene acquisito dal registro delle transazioni del motore del Workflow.
Perché è importante Questa attività è fondamentale 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 reperirlo Recuperato dalle tabelle del Workflow di Oracle Fusion, che registrano le attività assegnate agli utenti. Viene utilizzato il timestamp di assegnazione dell'attività di approvazione. Acquisizione Utilizzare il timestamp di creazione dell'attività nello storico del Workflow per la richiesta indicata. Tipo di evento explicit
	Fase di approvazione restituita	Un approvatore restituisce la richiesta al preparatore per ottenere ulteriori informazioni o apportare correzioni minori, senza rifiutarla formalmente. Di norma si tratta di un'azione esplicita nel sistema di Workflow.
Perché è importante Indica la necessità di chiarimenti e crea un ciclo di rilavorazione che prolunga il tempo del ciclo. Distinguere le restituzioni dai rifiuti offre una visione più approfondita degli attriti del processo. Dove reperirlo Acquisito dallo storico delle azioni di approvazione della richiesta. Il sistema di Workflow registra un'azione 'RETURN' o simile con il relativo timestamp. Acquisizione Utilizzare il timestamp dell'azione 'RETURN' o 'Request for Information' dallo storico del Workflow. Tipo di evento explicit
	Fase di approvazione rifiutata	Un approvatore rifiuta la richiesta, che in genere viene rinviata al preparatore per la correzione oppure terminata. L'azione viene registrata esplicitamente nello storico del Workflow.
Perché è importante Questa attività è una delle principali cause di rilavorazioni e ritardi. L'analisi dei rifiuti aiuta a individuare problemi di conformità, criticità di budget o motivazioni poco chiare. Dove reperirlo Acquisito dallo storico delle azioni di approvazione della richiesta. Il sistema di Workflow registra un'azione 'REJECT' con il relativo timestamp. Acquisizione Utilizzare il timestamp dell'azione 'REJECT' dal registro dello storico delle azioni del Workflow. Tipo di evento explicit
	Richiesta modificata	Questo evento indica che un utente ha modificato una richiesta dopo il suo invio iniziale, rendendo spesso necessario riavviare il processo di approvazione. L'evento viene dedotto rilevando modifiche ai principali campi dati o la creazione di una nuova versione della richiesta.
Perché è importante Modifiche frequenti indicano problemi di qualità dei dati o requisiti in evoluzione, con conseguenti rilavorazioni e ritardi nel processo. Questo evento supporta direttamente il KPI 'Tasso di modifica delle richieste'. Dove reperirlo Dedotto monitorando i numeri di versione della richiesta oppure identificando modifiche dello stato nuovamente in 'Incomplete' dopo l'invio. Anche i registri delle modifiche o le tabelle dell'audit trail possono acquisire queste variazioni. Acquisizione Identificare i timestamp di creazione delle nuove versioni per lo stesso ID richiesta dopo l'invio. Tipo di evento inferred
	Richiesta ritirata	Si verifica quando il richiedente annulla o ritira una richiesta inviata prima che sia stata approvata completamente. Di norma si tratta di un'azione esplicita dell'utente che comporta una modifica dello stato.
Perché è importante Il monitoraggio dei ritiri aiuta a individuare le cause della terminazione prematura, ad esempio il cambiamento delle esigenze aziendali o la correzione di errori da parte degli utenti dopo l'invio. Dove reperirlo Dedotto da una modifica dello stato in 'WITHDRAWN' nella tabella POR_REQUISITION_HEADERS_ALL. L'azione viene registrata nello storico delle azioni della richiesta. Acquisizione Rilevare il timestamp in cui lo stato della richiesta viene aggiornato a 'Withdrawn'. Tipo di evento inferred

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i Suoi dati da Oracle Fusion Financials

Passaggi

Acceda a Reports and Analytics: acceda a Oracle Fusion Financials. Utilizzi il menu Navigator per aprire Tools, quindi selezioni Reports and Analytics. Questo è il punto centrale per 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. In questo modo verrà aperto in una nuova scheda l'editor di analisi Oracle Transactional Business Intelligence (OTBI).
Selezioni la Subject Area: Le verrà richiesto di selezionare una Subject Area. Nella casella di ricerca, digiti 'Procurement - Requisitions Real Time' e la selezioni dall'elenco. Questa Subject Area contiene tutti i dati necessari sugli eventi del ciclo di vita delle richieste.
Crei l'analisi per gli eventi delle richieste: questo passaggio richiede la creazione di un'unione di diverse query per acquisire ogni evento distinto. Poiché l'interfaccia OTBI non dispone di una funzione UNION ALL diretta per diversi tipi di evento, crei un unico report che estragga tutti i campi pertinenti relativi a date e stati. Nella scheda 'Criteria', trascini le colonne elencate nella sezione della query dal riquadro 'Subject Areas' a sinistra all'area 'Selected Columns'. Sono incluse le colonne relative a data di creazione, data di invio, data di approvazione, data di creazione del PO e così via.
Aggiunga la cronologia delle azioni della richiesta: per acquisire i passaggi dettagliati di approvazione, ovvero Approved, Rejected, Returned e Withdrawn, includa i campi della cartella 'Requisition Action History' all'interno della Subject Area. Trascini 'Action Date', 'Action' e 'Performer' nelle colonne selezionate.
Configuri i filtri: passi alla scheda 'Prompts' per creare i filtri dell'analisi. È essenziale filtrare per 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ò inoltre aggiungere prompt per 'Business Unit' o 'Requester Name' per restringere i dati.
Esegua e verifichi il report: acceda alla scheda 'Results' per eseguire l'analisi e visualizzare un'anteprima dei dati. L'output sarà una tabella 'ampia', con una riga per ogni riga della richiesta o azione di approvazione, contenente più colonne relative a date e stati.
Esporti i dati grezzi: dopo aver verificato l'anteprima, faccia clic sul link 'Export', generalmente situato in fondo alla pagina dei risultati. Scelga 'Data' > 'CSV File' come formato. I dati grezzi dell'analisi verranno scaricati.
Trasformi i dati nel formato event log: il CSV esportato sarà in formato ampio. Dovrà utilizzare uno strumento esterno, come uno script Python, Power Query in Excel o un altro strumento di preparazione dei dati, per trasformarlo. Il processo consiste nel trasformare le colonne delle date in formato unpivot in un'unica colonna 'EventTime' e nel 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 come file CSV, che potrà quindi caricare in ProcessMind.

Configurazione

Subject Area: la Subject Area principale da utilizzare è 'Procurement - Requisitions Real Time'. Contiene tutte le informazioni principali relative a intestazione e righe delle richieste, distribuzione e cronologia delle approvazioni.
Intervallo di date: applichi sempre un filtro obbligatorio sulle date per limitare il volume dei dati e migliorare le prestazioni. Un filtro su 'Requisition Header'.'Requisition Creation Date' relativo agli ultimi 3-6 mesi rappresenta un buon punto di partenza.
Filtri principali: valuti l'aggiunta di filtri per 'Requisition Header'.'Business Unit' e 'Requisition Header'.'Requisition Status' per concentrarsi sulle unità organizzative pertinenti ed escludere stati non rilevanti, come 'Canceled', se non necessari per l'analisi.
Selezione delle colonne: selezioni con attenzione le colonne da aggiungere all'analisi. L'inclusione di un numero eccessivo di colonne, soprattutto da molte cartelle o dimensioni diverse, può compromettere le prestazioni. Si concentri esclusivamente sui campi necessari per l'event log.
Autorizzazioni: l'utente che esegue l'estrazione deve disporre di un ruolo con le autorizzazioni necessarie per accedere all'area di lavoro Reports and Analytics e alla Subject Area 'Procurement - Requisitions Real Time'. In genere, ruoli come 'BI Author' o 'Procurement Analyst' dispongono di questi privilegi.

a 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 dei privilegi BI Author o equivalenti.
Acceda all'area di lavoro Reports and Analytics facendo clic sull'icona Navigator, quindi selezionando Tools > Reports and Analytics.
Faccia clic sul pulsante "Browse Catalog" per aprire il catalogo Business Intelligence Publisher.
Nell'interfaccia 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 nuovo Data Set e selezioni "SQL Query".
Nella finestra di dialogo del nuovo Data Set, inserisca un nome, ad esempio Requisition_Event_Log, selezioni la Data Source appropriata per i dati Financials, ad esempio ApplicationDB_FSCM, e imposti il 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 verranno riconosciuti automaticamente da BI Publisher. 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 fornendo i parametri relativi alla data di inizio e alla data di fine. Quando il report visualizza i dati, utilizzi la funzione "Export" per scaricare i risultati come file CSV.
Verifichi che il file CSV finale sia salvato con codifica UTF-8 e contenga le intestazioni richieste per l'acquisizione nel Suo strumento di process mining.

Configurazione

Origine dei dati: l’origine dati BI Publisher, generalmente denominata 'ApplicationDB_FSCM' o con un nome simile, deve essere configurata con un utente che disponga dell’accesso in lettura a tutte le tabelle utilizzate nella query, incluse quelle di Procurement (POR, PO), Human Capital Management (PER, HR) e Financials (FUN).
Filtro per 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 prime estrazioni o per 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 unità aziendale: nella sezione commentata della clausola WHERE della query è incluso un filtro per il nome dell’unità aziendale. È fortemente consigliato rimuovere il commento e configurare questo filtro per limitare i dati alle unità aziendali pertinenti all’analisi, migliorando significativamente le prestazioni.
Prerequisiti: l’utente che crea ed esegue il report deve disporre di un ruolo con privilegi BI Publisher, come 'BI Administrator Role' o 'BI Author Role'. Inoltre, l’utente deve avere le autorizzazioni di sicurezza sui 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'

Passaggi

Prerequisiti e configurazione dell'ambiente: verifichi che Python 3 sia installato sul sistema. Installi la libreria requests necessaria eseguendo il comando seguente nel terminale: pip install requests. Avrà inoltre bisogno delle credenziali API, ovvero username e password, di un utente Oracle Fusion con autorizzazioni sufficienti per leggere i dati delle richieste di acquisto, oltre all'URL di base della Sua 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. Modifichi i valori segnaposto all'inizio dello script. Imposti FUSION_URL, USERNAME e PASSWORD in base ai dati del Suo ambiente Oracle Fusion. Modifichi START_DATE e END_DATE per definire il periodo di estrazione.
Comprenda gli endpoint e i campi API: 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 sui PO, e actionHistory, per gli eventi di approvazione, migliorando così le prestazioni.
Esegua lo script: esegua lo script dal terminale utilizzando il comando python extract_requisitions.py. Lo script eseguirà l'autenticazione tramite API, inizierà a recuperare i dati e visualizzerà nella console gli aggiornamenti sull'avanzamento, indicando il numero di richieste elaborate.
Gestisca la paginazione: lo script gestisce automaticamente la paginazione. Oracle Fusion REST API restituisce i dati in blocchi, o pagine. Lo script verifica il flag hasMore in ogni risposta ed effettua ripetutamente le richieste con un parametro offset aggiornato finché non vengono recuperate tutte le richieste comprese nell'intervallo di date specificato.
Logica di trasformazione dei dati: per ogni richiesta recuperata dall'API, lo script genera più righe nell'event log. Crea un evento 'Requisition Created' a partire da CreationDate, un evento 'Requisition Submitted' a partire da SubmittedDate e scorre la raccolta actionHistory per creare eventi dettagliati per ogni passaggio di approvazione, ovvero Started, Approved, Rejected e Returned.
Determini gli eventi relativi allo stato finale: lo script acquisisce gli eventi relativi all'esito finale, come 'Requisition Approved' e 'Requisition Rejected', verificando il DocumentStatus finale della richiesta e utilizzando LastUpdateDate come timestamp dell'evento.
Generi l'evento Purchase Order: lo script esamina ogni riga della richiesta. Se una riga contiene un PoHeaderId, significa che è stato creato un Purchase Order. Viene quindi generata una voce nell'event log per questa attività, collegando la richiesta al processo di procurement a valle.
Verifichi il file di output: al termine dell'esecuzione, lo script creerà un file CSV denominato oracle_fusion_requisitions_event_log.csv nella stessa directory. Il file contiene l'event log estratto.
Prepari il caricamento: apra il file CSV generato in un programma per fogli di calcolo per verificarne il contenuto. Verifichi che le colonne e i formati dei dati siano conformi ai requisiti del Suo strumento di process mining. Il file è ora pronto per essere caricato in ProcessMind.

Configurazione

Credenziali API: è necessario un account utente dedicato all'integrazione, con un ruolo che garantisca l'accesso in sola lettura alla Purchase Requisitions REST API. Tra i ruoli di esempio figurano Procurement Manager o un ruolo di integrazione personalizzato.
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 al Suo ambiente Oracle Fusion.
Filtro per intervallo di date: lo script include le variabili START_DATE e END_DATE. È fortemente consigliato estrarre i dati in batch gestibili, ad esempio 3-6 mesi alla volta, per evitare timeout dell'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 su 100, un valore sicuro per la maggior parte degli ambienti. Può provare ad aumentarlo a 200 o 500 per velocizzare potenzialmente l'estrazione, tenendo però conto dei possibili problemi di memoria o dei limiti dell'API in caso di valori troppo elevati.

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

Passaggi

Verifichi che Oracle BI Cloud Connector, i contenuti di procurement richiesti di Oracle Fusion Financials e l'accesso ai Public View Objects pertinenti siano disponibili nel Suo ambiente. Verifichi inoltre che l'utente BICC o l'account di integrazione disponga dell'autorizzazione a estrarre dati relativi a richieste, cronologia delle approvazioni e Purchase Order. I nomi esatti dei ruoli e le etichette di navigazione variano in base alla release Oracle; utilizzi quindi l'area di amministrazione BICC corrispondente nel Suo tenant.
Identifichi e abiliti i PVO necessari per l'estrazione. Utilizzi RequisitionHeaderPVO, o il PVO dell'intestazione della richiesta corrispondente nel Suo ambiente, insieme ai PVO che espongono le righe della richiesta, la cronologia degli stati della richiesta, la cronologia del Workflow di approvazione e i riferimenti ai Purchase Order. Non presuma che un singolo PVO contenga la cronologia del Workflow o quella della creazione dei Purchase Order. Registri i nomi esatti dei PVO e gli Attributi disponibili nel Suo tenant.
Configuri un job BICC per un'estrazione massiva incrementale o storica. Imposti la finestra di estrazione con [Start date parameter] e [End date parameter] e configuri il job affinché distribuisca i file CSV nella posizione di cloud storage approvata. Per il caricamento iniziale, utilizzi un intervallo storico sufficientemente ampio. Per i caricamenti ricorrenti, utilizzi finestre sovrapposte per tenere conto degli aggiornamenti tardivi, quindi elimini i duplicati utilizzando l'identificativo del caso, l'attività, il timestamp dell'evento e l'identificativo dell'evento di origine, quando disponibile.
Configuri le colonne dell'estrazione. Includa l'identificativo della richiesta, gli identificativi dell'intestazione e delle righe della richiesta, il richiedente, il reparto, l'importo, lo stato, la data richiesta, la Business Unit, il motivo del rifiuto, i timestamp di creazione e aggiornamento, i timestamp delle transizioni di stato, i timestamp dell'assegnazione e delle azioni di approvazione, l'azione di approvazione, il riferimento al Purchase Order e il timestamp di aggiornamento BICC. Utilizzi i nomi esatti degli Attributi esposti dai PVO selezionati. Se un attributo non è disponibile, lo mappi a [Configure based on your system] e documenti la limitazione, anziché sostituirlo con un campo non verificato.
Estragga i file CSV di origine e conservi i file originali. Carichi ogni file in un'area di staging, conservi il nome del PVO di origine e quello del file, normalizzi i timestamp in un unico fuso orario concordato e analizzi in modo coerente i valori di data e timestamp di Oracle. Tratti gli identificativi come stringhe per evitare la perdita degli zeri iniziali o della precisione.
Ristrutturi i dati di origine in una tabella degli 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 le righe per tutte le dodici attività elencate nella query.
Costruisca le righe degli eventi sulla base delle evidenze appropriate presenti nell'origine. Utilizzi l'evidenza della creazione del record per Requisition Created, una transizione esplicita di invio per Requisition Submitted, un'azione o transizione esplicita di ritiro per Requisition Withdrawn, una modifica rilevata dopo l'invio o una nuova versione per Requisition Amended, l'assegnazione nel Workflow 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. Utilizzi un record esplicito di creazione del Purchase Order o il timestamp di creazione collegato alla richiesta per Purchase Order Created.
Applichi una deduplicazione deterministica. Se più righe di origine rappresentano lo stesso evento, ne conservi una utilizzando il timestamp dell'evento più specifico e un identificativo di origine stabile, quando disponibile. Non accorpi passaggi di approvazione distinti solo perché condividono lo stesso identificativo della richiesta. Conservi eventi di approvazione separati per approvatori o passaggi di Workflow distinti.
Convalidi l'event log risultante. Verifichi che ogni attività obbligatoria sia rappresentata, che ogni evento disponga di un identificativo del caso e di un timestamp, che i timestamp rientrino nella finestra di estrazione o che gli aggiornamenti tardivi siano adeguatamente motivati e che gli Attributi consigliati siano valorizzati quando l'origine li fornisce. Riconcili il numero di richieste e i collegamenti ai Purchase Order con gli estratti di origine.
Esporti l'event log finale come 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 timestamp dell'evento.

Configurazione

Metodo di estrazione: estrazione massiva dei dati tramite Oracle BI Cloud Connector, con consegna dei file CSV nella posizione di archiviazione cloud configurata.
Oggetti di origine: utilizzi RequisitionHeaderPVO e i PVO corrispondenti disponibili nel tenant per le righe della richiesta, la cronologia degli stati, la cronologia del Workflow di approvazione e il riferimento all'ordine di acquisto. I nomi esatti dei PVO e gli Attributi devono essere confermati nell'ambiente.
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: utilizzi da tre a sei mesi per l'analisi ordinaria. Per il caricamento iniziale dello storico, utilizzi un intervallo più ampio quando necessario. Per le estrazioni ricorrenti, utilizzi finestre di estrazione sovrapposte 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 quando questi Attributi sono disponibili nei PVO selezionati. Confermi se il filtro si applica alla data di creazione, alla data di aggiornamento, alla data di transizione dello stato o a un'altra data di origine.
Estrazione incrementale: preferisca un timestamp di aggiornamento o un meccanismo di estrazione incrementale supportato ed esposto da BICC. Conservi il watermark dell'ultima estrazione completata correttamente e includa una piccola sovrapposizione nell'esecuzione successiva.
Completezza degli eventi: configuri estrazioni di origine 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 dell'intestazione allo stato attuale 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 di origine per la riconciliazione.
Archiviazione: configuri una posizione di archiviazione cloud approvata, con capacità, conservazione, crittografia e controlli di accesso adeguati. Confermi che l'account utilizzato per l'estrazione possa scrivere i file e che il processo di trasformazione possa leggerli.
Prerequisiti: disponibilità di BICC, accesso ai dati di approvvigionamento e approvazione pertinenti di Oracle Fusion, autorizzazioni di integrazione adeguate, accesso ai PVO selezionati ed eventuali abbonamenti Oracle o diritti di utilizzo delle funzionalità necessari. I nomi esatti dei ruoli, le licenze e i percorsi di navigazione dipendono dalla release di Oracle e dalla configurazione del tenant.
Gestione dell'ora: normalizzi tutti i timestamp di origine in base a un fuso orario documentato e conservi il timestamp originale quando è richiesta la tracciabilità a fini di audit.
Gestione dei casi: utilizzi PurchaseRequisitionId come identificativo del caso. Non utilizzi l'identificativo della riga della richiesta come identificativo del caso, salvo che il processo sia modellato intenzionalmente a livello di riga.

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

Utilizzi questo Template per iniziare il percorso verso l'ottimizzazione del processo Purchase to Pay - Requisition e liberare nuove efficienze. Si prepari a trasformare le Sue operazioni di approvvigionamento.

Torna alla guida al miglioramento Scarica il Template

Ottenga un processo Purchase to Pay - Requisition più rapido del 30%

Semplifichi il processo Oracle P2P Requisition e riduca del 30% il tempo di ciclo.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito: la configurazione richiede pochi minuti.

Il Suo Template dei dati Purchase to Pay - Requisition

Il Suo Template dei dati Purchase to Pay - Requisition

Purchase to Pay - Requisition: attributi

Purchase to Pay - Requisition: attività

Guide all'estrazione

Estrazione Oracle Transactional Business Intelligence (OTBI)

Passaggi

Configurazione

a Query di esempio sql

Estrazione di un modello dati basato su SQL con Oracle BI Publisher

Passaggi

Configurazione

a Query di esempio sql

Script Python tramite Oracle Fusion REST API

Passaggi

Configurazione

a Query di esempio python

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

Passaggi

Configurazione

a Query di esempio sql

Pronto per iniziare?

Ottenga un processo Purchase to Pay - Requisition più rapido del 30%

Il Suo Template dei dati Purchase to Pay - Requisition

Il Suo Template dei dati Purchase to Pay - Requisition

Purchase to Pay - Requisition: attributi

Purchase to Pay - Requisition: attività

Guide all'estrazione

Estrazione Oracle Transactional Business Intelligence (OTBI)

Passaggi

Configurazione

a Query di esempio sql

Estrazione di un modello dati basato su SQL con Oracle BI Publisher

Passaggi

Configurazione

a Query di esempio sql

Script Python tramite Oracle Fusion REST API

Passaggi

Configurazione

a Query di esempio python

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

Passaggi

Configurazione

a Query di esempio sql

Pronto per iniziare?

Ottenga un processo Purchase to Pay - Requisition più rapido del 30%

La Sua privacy è importante