> Miglioramento continuo dei processi > Purchase to Pay Richiesta di acquisto > Coupa > Template dei dati

Il Suo template dei dati per il processo di acquisto e pagamento delle richieste d’acquisto

Coupa

Attributi del processo di acquisto e pagamento delle richieste d’acquisto(21) Attività del processo di acquisto e pagamento delle richieste d’acquisto(12) Guide all’estrazione(3)

Il Suo template dei dati per il processo di acquisto e pagamento delle richieste d’acquisto

Questo template dei dati completo offre un metodo strutturato per raccogliere le informazioni necessarie ad analizzare il processo di acquisto e pagamento delle richieste d’acquisto. Descrive gli attributi e le attività essenziali per creare un Event Log affidabile e fornisce indicazioni per estrarre efficacemente questi dati dal sistema Coupa.

Attributi consigliati per un’analisi completa
Attività chiave del processo da monitorare
Indicazioni pratiche per estrarre i dati

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

Scarica il template

Attributi del processo di acquisto e pagamento delle richieste d’acquisto

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il processo di acquisto e pagamento delle richieste d’acquisto.

5 Obbligatorio 5 Consigliato 11 Facoltativo

	Nome	Descrizione
	ID della richiesta di acquisto PurchaseRequisitionId	Identificativo univoco di ogni richiesta di acquisto, utilizzato come ID del caso principale del processo.
Descrizione L’ID della richiesta di acquisto è la chiave centrale che collega tutte le attività relative a una singola richiesta di beni o servizi. A ogni richiesta viene assegnato un ID univoco al momento della creazione, che resta invariato per tutto il suo ciclo di vita. Questo consente di monitorare la richiesta dall’inizio alla fine: dalla creazione e dall’invio iniziali, attraverso tutti i passaggi di approvazione o rifiuto, fino alla selezione del fornitore e alla chiusura. Nel Process Mining, ogni voce dell’Event Log è associata a questo ID, permettendo di ricostruire l’intero percorso di ciascun caso. Perché è importante È l’ID del caso essenziale che collega tutti i passaggi del processo e consente di analizzare l’intero ciclo di vita della richiesta, dall’inizio alla fine. Dove reperirli È un campo chiave primaria presente nel modulo Requisitions di Coupa e nelle relative esportazioni di dati. Esempi PR-102934PR-102935PR-102936
	Nome dell’attività ActivityName	Nome dell’attività o dell’evento aziendale specifico che si è verificato in un determinato momento per la richiesta.
Descrizione Questo attributo registra i singoli passaggi del ciclo di vita della richiesta di acquisto. Alcuni esempi sono «Richiesta creata», «Passaggio di approvazione approvato» e «Richiesta avviata alla selezione del fornitore». Ogni attività rappresenta una tappa o un’azione specifica relativa alla richiesta. Analizzare la sequenza e la frequenza di queste attività è fondamentale per il Process Mining: permette di visualizzare le mappe del processo, individuare i percorsi più comuni e rilevare le deviazioni dalla procedura standard. Perché è importante Definisce i passaggi della mappa del processo e permette di visualizzare e analizzare il flusso delle richieste. Dove reperirli In genere deriva dagli Event Log, dai record delle modifiche di stato o dagli audit trail del sistema Coupa. Potrebbe essere necessario ricavarlo dai campi di stato o dai codici delle azioni. Esempi Richiesta creataRichiesta inviataFase di approvazione approvataRichiesta rifiutataOrdine di acquisto creato
	Ora dell’evento EventTime	Data e ora esatte in cui si è verificata l’attività.
Descrizione L’ora dell’evento, o timestamp, registra il momento esatto in cui un’attività relativa a una richiesta di acquisto è stata registrata. Questi dati sono fondamentali per ordinare cronologicamente gli eventi e ricostruire il flusso del processo. Costituiscono la base di tutte le analisi temporali, compreso il calcolo dei tempi di ciclo, l’individuazione dei colli di bottiglia misurando la durata tra le attività e l’analisi delle prestazioni del processo in periodi diversi. Per ottenere analisi significative, i timestamp devono essere accurati e dettagliati. Perché è importante Questo timestamp è fondamentale per ordinare correttamente gli eventi e calcolare tutte le metriche basate sulla durata, come i tempi di ciclo e i colli di bottiglia. Dove reperirli Queste informazioni sono registrate nell’audit trail o nella cronologia di ogni richiesta in Coupa, spesso in un campo «created_at» o «updated_at» relativo a ciascuna azione. Esempi 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
	Sistema di origine SourceSystem	Identifica il sistema di origine da cui sono stati estratti i dati.
Descrizione Questo attributo specifica il sistema di registrazione da cui provengono i dati del processo. In questa analisi, il valore sarà sempre «Coupa». Includere questo campo è una buona prassi, soprattutto quando i dati provengono da più sistemi. Fornisce un contesto essenziale sulla provenienza dei dati e aiuta a gestire la governance dei dati e le regole di qualità. Perché è importante Fornisce informazioni chiare sulla provenienza dei dati, fondamentali per la governance dei dati e per l’integrazione di dati provenienti da più sistemi aziendali. Dove reperirli In genere è un valore statico aggiunto durante l’estrazione e la trasformazione dei dati per indicare l’origine del set di dati. Esempi Coupa
	Ultimo aggiornamento dei dati LastDataUpdate	Timestamp che indica l’ultimo aggiornamento dei dati dal sistema di origine.
Descrizione Questo attributo registra la data e l’ora dell’estrazione più recente dei dati da Coupa. Indica con chiarezza quanto sono aggiornati i dati analizzati. Conoscerne la data è fondamentale per capire se le informazioni riflettono la situazione operativa attuale o un momento precedente. È particolarmente importante per le Dashboard che monitorano le attività in corso. Perché è importante Indica quanto sono aggiornati i dati, aiutando gli utenti a comprendere il periodo a cui si riferisce l’analisi e a prendere decisioni sulla base di informazioni aggiornate. Dove reperirli Questo timestamp viene generato e aggiunto dalla pipeline di dati o dallo strumento ETL al termine di un’estrazione completata correttamente. Esempi 2024-05-21T02:00:00Z
	Approvatore Approver	Utente o gruppo responsabile di un’attività di approvazione.
Descrizione Questo attributo identifica la persona o il gruppo di approvazione specifico a cui è assegnato un passaggio di approvazione. Viene valorizzato per attività come «Passaggio di approvazione avviato», «Passaggio di approvazione approvato» e «Passaggio di approvazione rifiutato». Analizzare i dati per approvatore è essenziale per creare la Dashboard «Prestazioni e carico degli approvatori». Aiuta a misurare i tempi di approvazione individuali, individuare i colli di bottiglia causati da approvatori specifici e valutare la distribuzione del carico di lavoro. Perché è importante È fondamentale per analizzare le prestazioni degli approvatori, bilanciare il carico di lavoro e individuare i colli di bottiglia legati a singole persone o gruppi di approvazione. Dove reperirli Queste informazioni si trovano nei dettagli della catena di approvazione associata a ogni richiesta in Coupa. Potrebbe essere necessario unirle ai dati degli utenti. Esempi David MillerApprovatori Finance L2Susan Chen
	Importo totale TotalAmount	Valore monetario complessivo della richiesta di acquisto.
Descrizione Questo attributo rappresenta il costo totale di tutti i beni e servizi richiesti. L’importo è un fattore importante nell’analisi del processo, poiché spesso influisce sulla complessità del flusso di approvazione: le richieste di importo elevato richiedono in genere più passaggi di approvazione. Analizzare le metriche di processo per fasce di importo, ad esempio <1000 $, 1000 $-10000 $, può rivelare come il processo gestisce richieste di diverso valore economico. Perché è importante Aiuta ad analizzare le differenze nel processo per richieste di importo diverso, poiché gli importi più elevati comportano spesso flussi di approvazione più complessi. Dove reperirli È un campo standard dell’intestazione dell’oggetto Requisition in Coupa, generalmente denominato «total» o «total_amount». Esempi 500.0012550.7599.99
	Reparto Department	Reparto aziendale o centro di costo a cui viene addebitata la richiesta.
Descrizione L’attributo Reparto collega ogni richiesta a una specifica unità organizzativa o a un centro di costo. È una dimensione fondamentale per le analisi comparative. Consente di filtrare e segmentare le Dashboard e i KPI per reparto, permettendo ai responsabili di confrontare i tempi di ciclo delle approvazioni, i tassi di rifiuto e la conformità tra le diverse aree dell’organizzazione. In questo modo è possibile individuare problemi specifici di un reparto o buone prassi. Perché è importante Consente di confrontare KPI di processo, come i tempi di ciclo e i tassi di rifiuto, tra diverse unità aziendali e di individuare le aree da migliorare. Dove reperirli È un campo standard dell’oggetto Requisition in Coupa, spesso associato al profilo utente del richiedente o specificato nelle righe della richiesta. Esempi MarketingOperazioni ITServizi generaliRicerca e sviluppo
	Richiedente Requester	Dipendente che ha creato e inviato la richiesta di acquisto.
Descrizione Questo attributo identifica la persona che ha avviato la richiesta. Analizzare i dati per richiedente aiuta a individuare schemi ricorrenti associati a utenti specifici, come un numero elevato di modifiche o rifiuti frequenti, che potrebbero indicare la necessità di ulteriore formazione. Consente inoltre di analizzare il volume delle richieste e il comportamento del processo per singoli utenti o gruppi di utenti. Perché è importante Consente di analizzare il comportamento del processo in base all’utente, individuare le esigenze di formazione e comprendere come le diverse persone interagiscono con il processo. Dove reperirli È disponibile come campo standard dell’oggetto Requisition in Coupa, spesso collegato all’oggetto User e denominato «requester» o «created_by». Esempi Alice JohnsonBob SmithCharlie Brown
	Stato della richiesta RequisitionStatus	Stato attuale o finale della richiesta di acquisto.
Descrizione Questo attributo indica lo stato complessivo della richiesta al momento dell’estrazione dei dati o il suo esito finale. Tra gli stati più comuni figurano «In attesa di approvazione», «Approvata», «Rifiutata», «Ritirata» e «Chiusa». È una dimensione fondamentale per filtrare e analizzare i dati. Serve a calcolare i tassi di approvazione e di rifiuto, monitorare il carico di lavoro corrente delle richieste aperte e comprendere l’esito finale delle richieste. Perché è importante È fondamentale per comprendere gli esiti delle richieste, calcolare i tassi di approvazione e di rifiuto e monitorare lo stato attuale delle richieste in corso. Dove reperirli È un campo standard dell’oggetto Purchase Requisition in Coupa, spesso denominato «status» o «state». Esempi In attesa di approvazioneApprovataRifiutataRitirataChiusa
	Categoria merceologica Commodity	Categoria generale dei beni o servizi richiesti.
Descrizione L’attributo Categoria merceologica fornisce una classificazione standardizzata degli articoli inclusi nella richiesta, ad esempio «Materiale per ufficio», «Hardware informatico» o «Servizi di marketing». Consente di analizzare le modalità di acquisto e le variazioni del processo in base ai beni o servizi acquistati. Alcune categorie merceologiche possono prevedere requisiti di approvazione o strategie di selezione dei fornitori specifici; analizzare il processo per categoria aiuta a ottimizzare gli approvvigionamenti per le diverse categorie di spesa. Perché è importante Aiuta ad analizzare le categorie di spesa e a capire se il comportamento del processo, ad esempio i tempi di approvazione, varia in base al tipo di beni o servizi acquistati. Dove reperirli È un campo standard di Coupa, generalmente disponibile a livello di riga della richiesta. Potrebbe essere necessario aggregarlo a livello di intestazione. Esempi Materiale per ufficioHardware informaticoServizi di marketingViaggi
	Durata del passaggio di approvazione ApprovalStepDuration	Tempo di attesa della richiesta in un singolo passaggio di approvazione.
Descrizione Questa metrica calcolata misura il tempo che intercorre tra l’attività «Passaggio di approvazione avviato» e la corrispondente attività «Passaggio di approvazione approvato» o «Passaggio di approvazione rifiutato». Isola il tempo di attesa in ciascuna fase della catena di approvazione. È fondamentale per la Dashboard «Colli di bottiglia nei passaggi critici di approvazione», perché individua con precisione gli approvatori o le fasi che causano i ritardi più significativi nel processo complessivo. Perché è importante Individua i colli di bottiglia specifici nel flusso di approvazione misurando i tempi di attesa di ogni singolo passaggio, anziché limitarsi al tempo di ciclo complessivo. Dove reperirli Nel software di Process Mining, si calcola la differenza di tempo tra «Approval Step Started» e il successivo evento conclusivo di approvazione («Approved» o «Rejected»). Esempi 1,2 giorni4 ore3,8 giorni
	ID dell’ordine di acquisto PurchaseOrderId	Identificativo dell’ordine di acquisto creato a partire dalla richiesta approvata.
Descrizione Dopo l’approvazione completa e la selezione del fornitore, in genere viene creato un ordine di acquisto. Questo attributo ne registra l’ID e collega il processo di richiesta a monte al processo dell’ordine di acquisto a valle. Consente di calcolare il KPI «Tempo tra approvazione della richiesta e creazione dell’ordine di acquisto» e di analizzare l’intero ciclo Purchase-to-Pay dall’inizio alla fine. Perché è importante Collega la richiesta al successivo ordine di acquisto, consentendo di analizzare il tempo di passaggio e di ottenere una visione più ampia dell’intero processo P2P. Dove reperirli È un campo standard dell’oggetto Requisition in Coupa, valorizzato dopo la creazione dell’ordine di acquisto. Esempi PO-45000123PO-45000124PO-45000125
	Livello di urgenza UrgencyLevel	Classificazione che indica il livello di urgenza della richiesta, ad esempio «Alta», «Media» o «Bassa».
Descrizione Il livello di urgenza, spesso associato a un campo di priorità, consente ai richiedenti di segnalare le richieste che necessitano di una gestione più rapida. Questo attributo è essenziale per la Dashboard «Tempo di elaborazione delle richieste urgenti». Confrontando i tempi di ciclo delle richieste ad alta urgenza con quelli delle richieste standard, le organizzazioni possono valutare l’efficacia dei meccanismi di definizione delle priorità e verificare se le esigenze aziendali urgenti vengono soddisfatte tempestivamente. Perché è importante Consente di verificare se le richieste urgenti vengono elaborate più rapidamente di quelle standard e di valutare l’efficacia delle policy di definizione delle priorità. Dove reperirli Potrebbe essere un campo standard o personalizzato dell’oggetto Requisition in Coupa. Consultare la documentazione di Coupa o la configurazione del sistema. Esempi AltaMediaBassa
	Modificata IsAmended	Indicatore booleano impostato su vero se la richiesta è stata modificata una o più volte dopo l’invio iniziale.
Descrizione Questo attributo calcolato è un semplice indicatore (vero/falso) che segnala se, per un determinato caso, si è verificata l’attività «Richiesta modificata». Semplifica l’analisi e il filtraggio, consentendo agli utenti di isolare facilmente le richieste che hanno richiesto modifiche. Serve a calcolare il KPI «Tasso di modifica delle richieste» e alimenta la Dashboard «Volume delle modifiche alle richieste», aiutando a individuare le cause profonde delle rilavorazioni e a migliorare la qualità al primo tentativo. Perché è importante Semplifica il calcolo del KPI relativo al tasso di modifica e consente di segmentare facilmente i casi che hanno richiesto rilavorazioni rispetto a quelli che non ne hanno richieste. Dove reperirli Si calcola nello strumento di Process Mining verificando se nell’Event Log di ciascun caso è presente l’attività «Richiesta modificata». Esempi truefalse
	Motivo del rifiuto RejectionReason	Motivo indicato da un approvatore quando viene rifiutata una richiesta o un passaggio di approvazione.
Descrizione Quando rifiuta una richiesta, spesso l’approvatore ne indica il motivo. Questo attributo registra la spiegazione testuale. Analizzare i motivi dei rifiuti fornisce un riscontro diretto e qualitativo sulle cause del mancato esito positivo delle richieste. Queste informazioni sono preziose per individuare le cause profonde, come codici errati, budget insufficiente o motivazioni inadeguate, e intervenire con attività di formazione o miglioramenti del processo. Perché è importante Fornisce informazioni dirette sulle cause profonde degli esiti negativi del processo e aiuta a individuare le aree in cui servono formazione degli utenti o chiarimenti sul processo. Dove reperirli Queste informazioni sono in genere registrate nel campo dei commenti o delle note associato alla modifica dello stato in «Rifiutata» nella cronologia delle approvazioni della richiesta. Esempi Centro di costo erratoSupera il budget del trimestreRichiesta duplicataMotivazione insufficiente
	Nome del fornitore SupplierName	Nome del fornitore selezionato per la richiesta.
Descrizione Questo attributo identifica il fornitore previsto per i beni o servizi richiesti. Il richiedente può specificarlo oppure può essere aggiunto in seguito durante la procedura di selezione del fornitore. Analizzare le metriche di processo per fornitore aiuta a valutarne le prestazioni e a individuare eventuali relazioni tra determinati fornitori, tempi di ciclo più lunghi e altre inefficienze del processo. Fornisce inoltre un contesto importante per la strategia di approvvigionamento e la gestione dei rapporti con i fornitori. Perché è importante Consente di analizzare le prestazioni del processo in base al fornitore selezionato e può orientare le strategie di approvvigionamento e la gestione dei fornitori. Dove reperirli Queste informazioni sono disponibili nell’oggetto Requisition Line in Coupa, spesso in un campo denominato «supplier» o «vendor». Esempi StaplesDell TechnologiesAccentureCDW
	Numero di passaggi di approvazione ApprovalStepCount	Numero totale di passaggi di approvazione completati per una richiesta d’acquisto.
Descrizione Questo attributo calcolato conta, per ogni richiesta d’acquisto, le occorrenze distinte dell’attività «Approval Step Approved». Consente di quantificare la complessità del flusso di approvazione di ciascun caso e costituisce la base del KPI «Numero medio di passaggi di approvazione». È inoltre utile per individuare le richieste che seguono percorsi di approvazione insolitamente lunghi o complessi, che potrebbero richiedere una semplificazione del flusso di lavoro. Perché è importante Quantifica la complessità del flusso di approvazione di ogni richiesta d’acquisto e aiuta a individuare i percorsi troppo complessi da semplificare. Dove reperirli Nel software di Process Mining, questa metrica si calcola contando le occorrenze di «Approval Step Approved» per ogni ID del caso. Esempi 253
	Percorso del flusso di approvazione ApprovalWorkflowPath	Identificativo della specifica catena di approvazione o del template del flusso di lavoro applicato alla richiesta.
Descrizione Questo attributo identifica la sequenza predefinita di approvatori che la richiesta dovrebbe seguire. La sequenza è determinata da regole aziendali, spesso in base a fattori quali importo, reparto e tipo di richiesta. Analizzare questo attributo è fondamentale per la Dashboard «Conformità alle policy delle richieste». Confrontando la sequenza effettiva degli approvatori con il percorso del flusso di lavoro assegnato, è possibile rilevare deviazioni, misurare i tassi di conformità e individuare eccezioni non gestite. Perché è importante Consente di analizzare la conformità confrontando i passaggi di approvazione previsti con quelli effettivi e mettendo in evidenza le deviazioni del processo. Dove reperirli Consultare la documentazione di Coupa. Il dato potrebbe essere ricavato dal nome della catena di approvazione o della regola del flusso di lavoro attivata per la richiesta. Esempi Approvazione standard <5.000 $Approvazione hardware IT >10.000 $Revisione CFO per spesa in conto capitale
	Tipo di richiesta RequisitionType	Categoria o tipo della richiesta, ad esempio «Spesa in conto capitale», «Spesa operativa» o «Software».
Descrizione Il tipo di richiesta è una classificazione che consente di categorizzare le richieste in base alla finalità aziendale o alla natura dell’acquisto. Questo attributo è utile per l’analisi della conformità e per comprendere come le diverse tipologie di richieste attraversano il processo. Per esempio, le richieste di spesa in conto capitale potrebbero seguire un percorso di approvazione più rigoroso e lungo rispetto alle richieste operative standard. Analizzare il processo per tipo di richiesta può far emergere informazioni utili per ottimizzarlo. Perché è importante Consente di segmentare l’analisi in base alla finalità aziendale della richiesta, poiché tipologie diverse possono seguire flussi di processo e policy differenti. Dove reperirli È probabilmente un campo di classificazione standard o personalizzato dell’oggetto Requisition in Coupa. Esempi Spesa in conto capitaleSpesa operativaHardware ITServizi professionali
	Valuta Currency	Codice della valuta dell’importo totale della richiesta.
Descrizione Questo attributo specifica la valuta, ad esempio USD, EUR o GBP, in cui è espresso l’importo totale della richiesta. È un’informazione essenziale per qualsiasi analisi finanziaria, soprattutto nelle organizzazioni multinazionali che operano con più valute. Garantisce la corretta interpretazione dei valori monetari e consente conversioni e aggregazioni accurate nei report finanziari e nelle Dashboard. Perché è importante Fornisce il contesto necessario per l’attributo «Importo totale» e consente analisi finanziarie accurate in contesti con più valute. Dove reperirli È un campo standard dell’oggetto Requisition in Coupa, solitamente denominato «currency_code» o con un nome simile. Esempi USDEURGBP

Obbligatorio Consigliato Facoltativo

Attività del processo di acquisto e pagamento delle richieste d’acquisto

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

6 Consigliato 6 Facoltativo

	Attività	Descrizione
	Ordine di acquisto creato	L’ordine di acquisto (PO) viene generato correttamente sulla base delle informazioni contenute nella richiesta approvata. L’evento si deduce dalla creazione di un record PO che fa riferimento all’ID della richiesta di origine.
Perché è importante È il principale esito positivo del processo di richiesta e segna il passaggio alla fase successiva del processo Purchase-to-Pay. Analizzare il tempo che intercorre tra «Richiesta approvata» e questo evento permette di individuare eventuali ritardi nell’esecuzione. Dove reperirli Dedotta dalla creazione di un record nella tabella «purchase_orders» che contiene un riferimento all’ID dell’intestazione «requisition_headers» o della riga «requisition_lines» di origine. Acquisizione Utilizzare il timestamp «created-at» del record PO collegato all’ID della richiesta. Tipo di evento inferred
	Richiesta approvata	La richiesta ha completato correttamente tutti i passaggi previsti dal flusso di approvazione. L’evento si deduce dal passaggio dello stato complessivo dell’intestazione della richiesta a «approved».
Perché è importante È una tappa fondamentale per il buon esito del processo e segna la conclusione del ciclo di approvazione. Il tempo necessario per raggiungere questa attività è un KPI primario e costituisce il presupposto per le successive attività di approvvigionamento. Dove reperirli Dedotta dalla modifica dello stato nella tabella «requisition_headers», quando il campo «status» viene aggiornato a «approved». Il timestamp è registrato nell’audit trail associato. Acquisizione Individuare il timestamp in cui lo stato complessivo della richiesta passa a «approved». Tipo di evento inferred
	Richiesta chiusa	La richiesta viene chiusa formalmente, a indicare che non saranno intraprese altre azioni. Può accadere dopo la creazione e l’evasione di un ordine di acquisto oppure se la richiesta viene annullata dopo l’approvazione ma prima dell’ordine.
Perché è importante Questa attività segna la conclusione definitiva del ciclo di vita della richiesta. In questo modo ogni caso si chiude correttamente e non risulta «attivo» a tempo indeterminato nell’analisi del processo. Dove reperirli Dedotta dalla modifica dello stato nella tabella «requisition_headers», quando il campo «status» viene aggiornato a «closed». Il timestamp è registrato nell’audit trail associato. Acquisizione Individuare il timestamp in cui lo stato complessivo della richiesta passa a «closed». Tipo di evento inferred
	Richiesta creata	Un utente avvia una nuova richiesta di acquisto e la salva come bozza. Questo è il punto di partenza di ogni caso relativo a una richiesta e viene in genere dedotto dal timestamp di creazione del record della richiesta.
Perché è importante Questa attività segna l’inizio del ciclo di vita della richiesta. Analizzare il tempo che intercorre tra la creazione e l’invio può rivelare ritardi dovuti all’incertezza dell’utente o alla complessità del sistema. Dove reperirli L’evento viene ricavato dal timestamp 'created-at' della tabella 'requisition_headers' per un determinato ID della richiesta di acquisto. Acquisizione Utilizzi il timestamp di creazione del record dell’intestazione della richiesta. Tipo di evento inferred
	Richiesta inviata	Chi ha richiesto l’acquisto invia formalmente la richiesta completata nel flusso di lavoro di approvazione. L’evento si deduce osservando nei log di audit o nelle tabelle della cronologia il passaggio dello stato della richiesta da 'draft' a 'pending_approval'.
Perché è importante L’invio avvia il processo di approvazione e costituisce quindi una tappa fondamentale per misurare il KPI «Tempo medio di ciclo dell’approvazione delle richieste». I ritardi precedenti a questa fase dipendono dall’utente, mentre quelli successivi sono legati al processo. Dove reperirli L’evento si deduce da una modifica dello stato nella tabella 'requisition_headers', in particolare quando il campo 'status' passa a 'pending_approval'. Il timestamp della modifica si trova nel registro di audit associato. Acquisizione Individui il timestamp in cui lo stato della richiesta passa per la prima volta a 'pending_approval'. Tipo di evento inferred
	Richiesta rifiutata	La richiesta viene rifiutata definitivamente durante il processo di approvazione e non sarà convertita in un ordine di acquisto. L’evento si deduce dal passaggio dello stato complessivo dell’intestazione della richiesta a «rejected».
Perché è importante Questa attività rappresenta un esito negativo definitivo del processo. Analizzare questi eventi è essenziale per migliorare il «Tasso di rifiuto delle richieste» e individuare le cause profonde, come violazioni delle policy o problemi di budget. Dove reperirli Dedotta dalla modifica dello stato nella tabella «requisition_headers», quando il campo «status» viene aggiornato a «rejected». Il timestamp è registrato nell’audit trail associato. Acquisizione Individuare il timestamp in cui lo stato complessivo della richiesta passa a «rejected». Tipo di evento inferred
	Fase di approvazione approvata	Un singolo approvatore del flusso di lavoro approva la richiesta. Si tratta di un’azione esplicita, registrata dal sistema con un timestamp specifico e le informazioni sull’utente.
Perché è importante Questa attività offre una visione dettagliata del flusso di approvazione. L’aggregazione di questi passaggi consente di calcolare il «Tempo medio di attesa per passaggio di approvazione» e analizzare le prestazioni degli approvatori. Dove reperirli Rilevata da un’azione esplicita di «approvazione», registrata nella tabella «approvals» o nel relativo audit trail e associata alla specifica richiesta e al relativo approvatore. Acquisizione Filtrare gli eventi di «approvazione» nella cronologia delle approvazioni della richiesta. Tipo di evento explicit
	Fase di approvazione avviata	Un’attività di approvazione viene assegnata a un approvatore specifico o a un gruppo di approvazione e la richiesta resta in attesa del relativo intervento. L’evento si deduce dalla creazione di un record di approvazione associato alla richiesta con stato 'pending'.
Perché è importante Questo evento segna l’inizio del tempo di attesa per una specifica approvazione. Misurare il tempo tra questo evento e la corrispondente «Fase di approvazione approvata/rifiutata» aiuta a individuare i colli di bottiglia nella catena di approvazione. Dove reperirli L’evento si deduce dal timestamp di creazione di un record nella tabella 'approvals' collegato alla richiesta, in cui lo stato dell’azione dell’approvatore è 'pending' o equivalente. Acquisizione Utilizzi il timestamp di creazione del record di approvazione in attesa di una persona nella catena di approvazione. Tipo di evento inferred
	Passaggio di approvazione rifiutato	Nella fase del flusso di lavoro di propria competenza, un singolo approvatore rifiuta la richiesta, che in genere viene rinviata al richiedente per le modifiche necessarie. Coupa registra esplicitamente questa azione.
Perché è importante I rifiuti in qualsiasi fase generano rilavorazioni e allungano i tempi di ciclo. Analizzare dove e perché si verificano è fondamentale per migliorare il processo e formare gli utenti. Dove reperirli Rilevata da un’azione esplicita di «rifiuto», registrata nella tabella «approvals» o nel relativo audit trail e associata alla specifica richiesta e al relativo approvatore. Acquisizione Filtrare gli eventi di «rifiuto» nella cronologia delle approvazioni della richiesta. Tipo di evento explicit
	Richiesta avviata alla selezione del fornitore	La richiesta approvata viene inviata a una procedura di selezione del fornitore, come una RFQ o un’asta, invece di essere convertita subito in un ordine di acquisto. L’evento si deduce quando la richiesta viene collegata a un oggetto relativo alla selezione del fornitore.
Perché è importante Questa attività evidenzia un percorso alternativo importante nel processo di approvvigionamento. Distingue gli acquisti semplici dalle attività di selezione strategica dei fornitori più complesse e consente un’analisi più articolata dei tempi di ciclo. Dove reperirli Dedotta rilevando il passaggio dello stato a «sourcing» oppure la creazione di un collegamento tra la tabella «requisition_lines» e una tabella relativa agli eventi di selezione del fornitore. Acquisizione Verificare se lo stato passa a «sourcing» o se viene creato un collegamento a un ID di un evento di selezione del fornitore. Tipo di evento inferred
	Richiesta modificata	Dopo l’invio, chi ha richiesto l’acquisto o un altro utente autorizzato modifica la richiesta. Coupa registra esplicitamente la modifica come nuova versione o voce di audit e spesso riavvia alcune o tutte le fasi del flusso di lavoro di approvazione.
Perché è importante Monitorare le modifiche è essenziale per comprendere le rilavorazioni e le inefficienze del processo. Un numero elevato di modifiche può indicare requisiti iniziali poco chiari o politiche di acquisto complesse, con effetti sul KPI «Tasso di modifica delle richieste». Dove reperirli L’evento si ricava dalle tabelle del registro di audit associate alla tabella 'requisition_headers', che registrano le modifiche di versione o specifiche azioni 'edit'. Acquisizione Cerchi eventi 'edit' o 'update' espliciti nella cronologia della richiesta successivi all’invio. Tipo di evento explicit
	Richiesta ritirata	Il richiedente originale annulla la richiesta prima che riceva l’approvazione finale. Questa azione esplicita, avviata dall’utente, interrompe il processo per quella richiesta.
Perché è importante Il ritiro può indicare un cambiamento delle esigenze aziendali, richieste duplicate o tentativi degli utenti di aggirare il processo. Monitorare questi casi aiuta a comprendere la variabilità della domanda e i possibili problemi di rispetto del processo. Dove reperirli Dedotta dalla modifica dello stato nella tabella «requisition_headers» a «withdrawn» o a uno stato equivalente, in seguito a un’azione esplicita dell’utente registrata nell’audit trail. Acquisizione Individuare il timestamp in cui lo stato della richiesta passa a «withdrawn». Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come estrarre i dati da Coupa

Passaggi

Acceda a Coupa: acceda alla Sua istanza Coupa con un account utente autorizzato a creare e pianificare report.
Apra il modulo di reportistica: selezioni la scheda «Setup» e individui la sezione «Reporting». Selezioni «Reports» per aprire la Dashboard dei report.
Crei un nuovo report personalizzato: faccia clic su «Create» per iniziare a creare un report e scelga «Custom Report» come tipo.
Definisca le origini dei dati del report: nel generatore di report, selezioni e unisca più origini dati per raccogliere tutte le informazioni necessarie. Inizi da «Requisition Headers» come origine principale, quindi aggiunga i seguenti oggetti correlati:
- «Approvals»: per ottenere i dettagli di ogni passaggio di approvazione, inclusi approvatore, Stato e timestamp.
- «Requisition Lines»: per aggregare gli importi Totale e ottenere i dettagli delle singole voci.
- «Purchase Order Headers»: per individuare quando una richiesta d’acquisto viene convertita in un ordine d’acquisto.
- «Users»: per recuperare i Nome completo e i dettagli del reparto di richiedenti e approvatori.
Configuri le colonne del report: trascini i campi necessari dalle origini dati disponibili nel layout del report. Questo passaggio è fondamentale, perché le colonne serviranno a generare l’Event Log. Includa almeno i seguenti campi:
- Da «Requisition Headers»: Requisition #, Created At, Submitted At, Updated At, Stato, Created by (Login ID), Totale, Sourced Externally?
- Da «Users» (per il richiedente): Nome completo, Department Name.
- Da «Approvals»: Created At, Updated At, Stato, Approver (Login ID).
- Da «Purchase Order Headers»: PO Number, Created At.
Imposti i filtri del report: applichi filtri per definire l’ambito dei dati estratti. Un filtro comune ed efficace si basa su «Requisition Headers - Created At» e imposta un intervallo di date dinamico, ad esempio «Last 90 days». Se necessario, può anche filtrare per specifici codici aziendali.
Pianifichi il report: apra la scheda «Schedule» nel generatore di report e imposti la frequenza di esecuzione, ad esempio giornaliera o settimanale. Scelga un orario in una fascia di minore attività.
Configuri la consegna: specifichi il metodo di consegna. Per automatizzarla, scelga «SFTP» e inserisca le credenziali del server e la directory di destinazione. In alternativa, può inviare il report a un indirizzo e-mail. Scelga «CSV» come formato del file.
Salvi e attivi il report: salvi il report e verifichi che la pianificazione sia attiva. Il primo report verrà eseguito alla successiva data e ora pianificata.
Trasformi i dati: il file CSV generato è un file semplice, non un Event Log. Dovrà elaborarlo con uno script esterno, ad esempio in Python, o con uno strumento ETL. Lo script deve riorganizzare i dati creando una riga distinta per ogni attività: per esempio, una riga «Requisition Created» usando la colonna Created At, una riga per ogni passaggio di approvazione usando le colonne «Approvals» e una riga «Purchase Order Created» usando la colonna Created At dell’ordine d’acquisto.
Generi l’Event Log finale: lo script di trasformazione deve produrre un file CSV finale con le colonne richieste: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate e gli altri attributi consigliati. Il file è quindi pronto per il caricamento.

Configurazione

Origini dati principali: il report deve essere creato unendo più oggetti Coupa. Le origini principali sono «Requisition Headers», «Approvals», «Requisition Lines» e «Purchase Order Headers».
Filtro per intervallo di date: è fondamentale applicare un filtro per limitare il volume dei dati. Come punto di partenza, si consiglia di usare una finestra mobile degli ultimi 3-6 mesi basata su «Requisition Headers - Created At».
Caricamenti incrementali: per le analisi continuative, pianifichi l’esecuzione giornaliera del report ed estragga i dati del giorno precedente, ad esempio «Yesterday», per effettuare caricamenti incrementali.
Configurazione della consegna: configuri l’invio a un server SFTP per integrare in modo affidabile e automatizzato i dati nella pipeline. Verifichi che la destinazione sia sicura e disponga di spazio sufficiente.
Autorizzazioni necessarie: l’account utente che configura il report deve disporre di autorizzazioni amministrative o specifiche per la reportistica, così da poter creare e pianificare il report e accedere a tutti gli oggetti dati necessari (richieste d’acquisto, ordini d’acquisto, approvazioni e utenti).

Query di esempio config

This extraction is configured within the Coupa UI and does not use a direct script. The following outlines the objects and fields required to build the report, which is then transformed into an event log.

**Data Sources (Objects to Join):**
1.  `Requisition Headers` (Primary)
2.  `Approvals` (Joined on Requisition Header ID)
3.  `Users` (Joined from `Requisition Headers` for Requester details)
4.  `Users` (Joined from `Approvals` for Approver details)
5.  `Purchase Order Headers` (Joined on Requisition Header ID)

**Report Columns Configuration (Fields to Select):**

*   **For 'Requisition Created' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Requisition #` -> Maps to `PurchaseRequisitionId`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Requisition Submitted' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Submitted At` -> Maps to `EventTime`

*   **For 'Requisition Amended' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime` (Logic must be applied to identify updates after submission)

*   **For 'Approval Step Started' event:**
    *   Source Object: `Approvals`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Approval Step Approved' / 'Approval Step Rejected' events:**
    *   Source Object: `Approvals`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName` ('Approved' or 'Rejected')

*   **For 'Requisition Withdrawn' / 'Requisition Approved' / 'Requisition Rejected' / 'Requisition Closed' events:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName`

*   **For 'Requisition Sourced' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Sourced Externally?` -> Used in logic to identify this event

*   **For 'Purchase Order Created' event:**
    *   Source Object: `Purchase Order Headers`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For General Attributes:**
    *   `Requisition Headers | Requisition #` -> `PurchaseRequisitionId`
    *   `Requisition Headers | Status` -> `RequisitionStatus`
    *   `Requisition Headers | Created By (Full Name)` -> `Requester`
    *   `Requisition Headers | Account Department` -> `Department`
    *   `Requisition Headers | Total` -> `TotalAmount`
    *   `Approvals | Approver (Full Name)` -> `Approver`

Passaggi

Prerequisiti: verifichi di avere installato un ambiente Python 3. Installi le librerie necessarie, pandas e requests, eseguendo pip install pandas requests nel terminale o nel prompt dei comandi.
Ottenga una chiave API Coupa: acceda alla Sua istanza Coupa come amministratore. Apra Setup > Company Setup > API Keys. Crei una nuova chiave API con almeno i permessi di lettura per i seguenti ambiti: core.purchase_order.read, core.requisition.read e core.user.read.
Configuri lo script: crei un nuovo file Python, ad esempio extract_coupa_reqs.py, e vi copi lo script fornito. Sostituisca i valori segnaposto di COUPA_INSTANCE_URL con l’URL Coupa della Sua azienda, ad esempio https://yourcompany.coupahost.com, e di API_KEY con la chiave ottenuta nel passaggio precedente.
Imposti i parametri di estrazione: nella sezione main dello script, modifichi le variabili START_DATE e END_DATE per definire l’intervallo temporale dei dati da estrarre. Il filtro seleziona le richieste d’acquisto in base alla data di creazione.
Esegua lo script: avvii lo script dal terminale con il comando python extract_coupa_reqs.py. Lo script si collegherà all’API Coupa, recupererà i dati e mostrerà l’avanzamento nella console.
Gestisca la paginazione dell’API: lo script include una funzione che gestisce automaticamente la paginazione dell’API. Recupera i dati in blocchi di 50 record e prosegue finché non ha acquisito tutte le richieste d’acquisto comprese nell’intervallo di date specificato.
Elabori i dati delle richieste d’acquisto: per ogni intestazione di richiesta recuperata, lo script genera gli eventi «Requisition Created» e «Requisition Submitted». Effettua quindi ulteriori chiamate API per recuperare i dati associati alle approvazioni e agli ordini d’acquisto.
Generi gli eventi delle attività: lo script elabora i record di approvazione per creare gli eventi «Approval Step Started», «Approval Step Approved» e «Approval Step Rejected». Verifica inoltre lo stato finale della richiesta e i dati correlati per generare eventi come «Requisition Approved», «Purchase Order Created» e «Requisition Withdrawn».
Rilevi le modifiche: lo script controlla l’attributo version di ogni richiesta. Se il valore è maggiore di 1, la richiesta è stata modificata. In tal caso, crea l’evento «Requisition Amended» usando il timestamp updated-at della versione più recente.
Componga l’Event Log: tutti gli eventi generati vengono raccolti in un elenco strutturato. Ogni evento include gli attributi richiesti, come PurchaseRequisitionId, ActivityName ed EventTime, e quelli consigliati, come Requester e TotalAmount.
Esporti i dati in CSV: dopo aver elaborato tutte le richieste, lo script converte l’elenco finale degli eventi in un DataFrame pandas e lo salva nella stessa directory in un file CSV chiamato coupa_requisition_event_log.csv. Il file è formattato per essere caricato direttamente in ProcessMind.

Configurazione

Permessi della chiave API: la chiave API usata per l’estrazione deve avere accesso in lettura agli oggetti requisition_headers, requisition_lines, approvals, purchase_orders e users in Coupa. Senza questi permessi, lo script non funzionerà o restituirà dati incompleti.
Intervallo di date: lo script filtra i dati in base alla data di creazione della richiesta (created-at). Per evitare tempi di esecuzione lunghi e possibili timeout dell’API, si consiglia di estrarre i dati in intervalli gestibili, ad esempio da 3 a 6 mesi alla volta. Modifichi di conseguenza le variabili START_DATE e END_DATE.
Filtro per stato: lo script fornito recupera tutte le richieste d’acquisto, indipendentemente dallo stato. Per un’analisi più mirata, può aggiungere un parametro status al dizionario params nella chiamata API iniziale e selezionare stati specifici, come approved, pending_approval o ordered.
Limite di paginazione: lo script è configurato per recuperare 50 record per chiamata API (limit=50), un valore standard che funziona bene con l’API Coupa. Aumentarlo non garantisce prestazioni migliori e può accrescere il rischio di timeout per le query complesse.
Considerazioni sui tempi di esecuzione: per ogni richiesta, lo script effettua più chiamate API: una per l’intestazione, una per le approvazioni e una per gli ordini d’acquisto. L’estrazione di migliaia di richieste può richiedere molto tempo ed essere soggetta ai limiti di frequenza dell’API Coupa. È preferibile eseguire lo script fuori dagli orari di punta.

Query di esempio python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Coupa instance URL and API Key
COUPA_INSTANCE_URL = class="hl-string">"https://[your_instance].coupahost.com"
API_KEY = class="hl-string">"[your_api_key]"

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

def get_coupa_data(endpoint, params={}):
    class="hl-string">"""Fetches paginated data from a Coupa API endpoint."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"X-COUPA-API-KEY": API_KEY
    }
    
    all_records = []
    offset = 0
    limit = 50
    
    while True:
        paginated_params = params.copy()
        paginated_params[class="hl-string">'offset'] = offset
        paginated_params[class="hl-string">'limit'] = limit
        
        try:
            response = requests.get(fclass="hl-string">"{COUPA_INSTANCE_URL}{endpoint}", headers=headers, params=paginated_params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for 4xx/5xx errors
            data = response.json()
            
            if not data:
                break
                
            all_records.extend(data)
            offset += limit
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {endpoint}: {e}")
            break
            
    return all_records

def main(start_date, end_date):
    class="hl-string">"""Main function to extract, transform, and save the event log.""" 
    print(class="hl-string">"Starting Coupa Requisition data extraction...")
    
    event_log = []
    current_time_utc = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Requisition Headers within the date range
    req_params = {
        class="hl-string">"created-at[gt]": start_date,
        class="hl-string">"created-at[lt]": end_date,
        class="hl-string">"fields": class="hl-string">'["id", "created-at", "submitted-at", "updated-at", "version", "status", "total", "requester", "currency", "sourcing-event-id"]'
    }
    requisition_headers = get_coupa_data(class="hl-string">"/api/requisition_headers", req_params)
    print(fclass="hl-string">"Found {len(requisition_headers)} requisitions to process.")

    for i, header in enumerate(requisition_headers):
        print(fclass="hl-string">"Processing requisition {i+1}/{len(requisition_headers)}: ID {header['id']}")
        
        class=class="hl-string">"hl-comment"># Common attributes for all events of this case
        case_id = str(header[class="hl-string">'id'])
        total_amount = header.get(class="hl-string">'total', {}).get(class="hl-string">'total')
        requester_name = fclass="hl-string">"{header.get('requester', {}).get('firstname', '')} {header.get('requester', {}).get('lastname', '')}".strip()
        department_name = header.get(class="hl-string">'requester', {}).get(class="hl-string">'department', {}).get(class="hl-string">'name')

        base_event = {
            class="hl-string">"PurchaseRequisitionId": case_id,
            class="hl-string">"TotalAmount": total_amount,
            class="hl-string">"Requester": requester_name,
            class="hl-string">"Department": department_name,
            class="hl-string">"Approver": None,
            class="hl-string">"SourceSystem": class="hl-string">"Coupa",
            class="hl-string">"LastDataUpdate": current_time_utc
        }

        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        event_log.append({
            **base_event,
            class="hl-string">"ActivityName": class="hl-string">"Requisition Created",
            class="hl-string">"EventTime": header[class="hl-string">'created-at'],
            class="hl-string">"RequisitionStatus": class="hl-string">"draft"
        })

        class=class="hl-string">"hl-comment"># Activity: Requisition Submitted
        if header.get(class="hl-string">'submitted-at'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Submitted",
                class="hl-string">"EventTime": header[class="hl-string">'submitted-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval"
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Amended
        if header.get(class="hl-string">'version') and int(header[class="hl-string">'version']) > 1:
             event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Amended",
                class="hl-string">"EventTime": header[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Timestamp of the new version
                class="hl-string">"RequisitionStatus": header[class="hl-string">'status']
            })

        class=class="hl-string">"hl-comment"># 2. Fetch Approvals for this requisition
        approval_params = {
            class="hl-string">"approvable-id": header[class="hl-string">'id'],
            class="hl-string">"approvable-type": class="hl-string">"RequisitionHeader"
        }
        approvals = get_coupa_data(class="hl-string">"/api/approvals", approval_params)

        for approval in approvals:
            approver = approval.get(class="hl-string">'approver', {}).get(class="hl-string">'fullname')
            approval_status = approval[class="hl-string">'status']

            class=class="hl-string">"hl-comment"># Activity: Approval Step Started
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Approval Step Started",
                class="hl-string">"EventTime": approval[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                class="hl-string">"Approver": approver
            })

            if approval_status == class="hl-string">'approved':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Approved
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Approved",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
            elif approval_status == class="hl-string">'rejected':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Rejected
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Rejected",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
        
        class=class="hl-string">"hl-comment"># 3. Handle final status and related events
        final_status_event_time = header[class="hl-string">'updated-at']
        final_status = header[class="hl-string">'status']

        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": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        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": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'withdrawn':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Withdrawn",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        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": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Sourced
        if header.get(class="hl-string">'sourcing-event-id'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Sourced",
                class="hl-string">"EventTime": final_status_event_time, class=class="hl-string">"hl-comment"># Assumes status update time reflects sourcing
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># 4. Fetch Purchase Orders to detect PO Creation
        po_params = {class="hl-string">"requisition-header-id": header[class="hl-string">'id']}
        purchase_orders = get_coupa_data(class="hl-string">"/api/purchase_orders", po_params)

        for po in purchase_orders:
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Purchase Order Created",
                class="hl-string">"EventTime": po[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"ordered" 
            })

    class=class="hl-string">"hl-comment"># 5. Create and save the DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. The output file will be empty.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">"PurchaseRequisitionId", class="hl-string">"EventTime"])
    df.to_csv(class="hl-string">"coupa_requisition_event_log.csv", index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to coupa_requisition_event_log.csv")

if __name__ == class="hl-string">"__main__":
    class=class="hl-string">"hl-comment"># Define the extraction period. Format: YYYY-MM-DDTHH:MM:SSZ
    START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
    END_DATE = class="hl-string">"2023-06-30T23:59:59Z"
    main(START_DATE, END_DATE)

Passaggi

Verifichi che la piattaforma iPaaS o di Process Mining di terze parti scelta offra un connettore Coupa verificato, con accesso alle intestazioni delle richieste d’acquisto, alla cronologia o ai dati di audit delle richieste, ai record di approvazione, alle relazioni di approvvigionamento e agli ordini d’acquisto, nonché alle informazioni di chiusura. I nomi dei connettori e degli oggetti e i campi disponibili variano a seconda del fornitore: li configuri in base alla documentazione del connettore e al Suo tenant Coupa.
Crei una connessione al connettore tramite l’interfaccia della piattaforma. Inserisca l’URL del tenant Coupa, il metodo di autenticazione, le credenziali, i dettagli OAuth e gli eventuali ambiti richiesti. Fino alla configurazione della connessione nell’ambiente di destinazione, usi segnaposto come [Your Coupa tenant URL] e [Your connector credentials].
Definisca l’ambito dell’estrazione. Inizialmente selezioni un intervallo mobile da tre a sei mesi, quindi lo estenda dopo aver verificato la corrispondenza dei dati. Applichi solo filtri validi per il Suo tenant, come [Your company filter] o [Your document type filter]. Non escluda le richieste solo perché il loro stato attuale è chiuso, rifiutato, ritirato o approvato: questi casi sono necessari per analizzare l’intero ciclo di vita.
Mappi gli oggetti di origine nel connettore. Selezioni l’oggetto delle intestazioni delle richieste, quello della cronologia o dell’audit delle richieste, l’oggetto delle approvazioni, quello delle relazioni di approvvigionamento, quello delle relazioni con gli ordini d’acquisto e qualsiasi oggetto relativo alla cronologia di chiusura o dello stato reso disponibile dal connettore. Se un oggetto necessario non è disponibile, usi la rappresentazione della cronologia o dell’audit supportata dal connettore oppure documenti il limite prima di pubblicare l’estrazione.
Configuri le associazioni di casi ed eventi. Associ l’identificativo della richiesta a PurchaseRequisitionId, l’etichetta dell’evento a ActivityName, il timestamp di origine a EventTime, il valore costante Coupa a SourceSystem e il timestamp di aggiornamento del connettore a LastDataUpdate. Associ anche il richiedente, il reparto, l’importo totale, lo stato della richiesta e l’approvatore, se questi campi sono disponibili.
Configuri regole che creino esplicitamente righe per tutte le dodici attività. Generi Requisition Created dal timestamp di creazione della richiesta; Requisition Submitted dalla transizione da bozza a pending_approval; Requisition Amended da una versione successiva all’invio o da una voce di audit; Approval Step Started da un record di approvazione in attesa; Approval Step Approved da un’azione di approvazione; Approval Step Rejected da un’azione di rifiuto; Requisition Withdrawn da un’azione esplicita di ritiro o da una transizione di stato; Requisition Approved dalla transizione dell’intestazione allo stato approvato; Requisition Rejected dalla transizione dell’intestazione allo stato rifiutato; Requisition Sourced da una relazione tra richiesta e approvvigionamento; Purchase Order Created da un ordine d’acquisto che fa riferimento alla richiesta; Requisition Closed da un’azione di chiusura o da una transizione di stato.
Normalizzi i dati estratti prima di unire i flussi di eventi. Converta tutti i timestamp in un unico fuso orario, preferibilmente UTC, mantenga la precisione dei timestamp di origine, assegni all’identificativo della richiesta un tipo di testo coerente e conservi i valori di stato e utente originali. Rimuova i duplicati solo quando i record di origine sono tecnicamente identici, usando come chiavi di confronto l’identificativo della richiesta, il nome dell’attività, il timestamp dell’evento, l’identificativo del record di origine, se disponibile, e l’approvatore.
Pubblichi o pianifichi il flusso del connettore. Esegua un’estrazione completa iniziale per l’intervallo di date selezionato, seguita da aggiornamenti incrementali basati sul timestamp di aggiornamento dell’origine o sul meccanismo di rilevamento delle modifiche supportato dal connettore. Configuri un intervallo di recupero per includere le voci di audit tardive e i record di approvazione modificati.
Convalidi l’Event Log risultante confrontandolo con i report Coupa o con l’anteprima del connettore. Verifichi che ogni richiesta abbia un evento di creazione, che le transizioni di stato e di approvazione seguano la cronologia prevista e che siano presenti gli eventi basati sulle relazioni quando esistono dati di approvvigionamento o ordini d’acquisto.
Esporti il risultato finale come CSV semplice o in un altro formato di Event Log supportato da ProcessMind. Includa una riga per evento e usi PurchaseRequisitionId come identificativo del caso, ActivityName come attività ed EventTime come timestamp dell’evento. Carichi il file o pubblichi il dataset del connettore in ProcessMind senza fare affidamento sul rilevamento automatico degli eventi mancanti da parte di ProcessMind.

Configurazione

Connettore e accesso: usi un connettore Coupa verificato, fornito dalla piattaforma iPaaS o di Process Mining scelta. Le autorizzazioni Coupa, gli ambiti API, i moduli e le licenze del connettore necessari dipendono dal fornitore e dalla configurazione del tenant. Prima dell’implementazione, verifichi l’accesso ai dati delle richieste, della cronologia o dell’audit, delle approvazioni, dell’approvvigionamento, degli ordini d’acquisto e delle chiusure.
Intervallo di date: inizi con dati relativi a un periodo da tre a sei mesi. Per gli aggiornamenti pianificati, usi una finestra di estrazione mobile e includa un intervallo di recupero per acquisire aggiornamenti tardivi, azioni di approvazione e richieste modificate.
Associazioni necessarie: associ l’identificativo della richiesta a PurchaseRequisitionId, l’etichetta dell’evento a ActivityName, il timestamp dell’evento a EventTime, il valore dell’origine a SourceSystem e il timestamp di aggiornamento a LastDataUpdate.
Associazioni consigliate: associ lo stato della richiesta, il richiedente, il reparto o il centro di costo, l’importo totale e l’approvatore. Se il connettore supporta le istantanee storiche, conservi sia i valori attuali sia quelli relativi ai singoli eventi.
Regole degli eventi: configuri la creazione esplicita di eventi per tutte le dodici attività richieste. ProcessMind legge l’Event Log così com’è e non ricava né deduce altri eventi.
Filtri: applichi solo filtri supportati dal connettore e validi per il tenant, come [Your company filter], [Your document type filter], [Your business unit filter] o [Your requisition date range]. Eviti di escludere gli stati terminali, a meno che l’analisi non lo richieda espressamente.
Gestione dei timestamp: converta i timestamp in un fuso orario comune, mantenga la precisione originale e definisca un criterio di ordinamento deterministico per gli eventi con timestamp identici.
Aggiornamenti incrementali: usi il campo updated-at o il meccanismo di rilevamento delle modifiche supportato dal connettore. Configuri un intervallo di recupero, poiché la cronologia delle approvazioni, i collegamenti all’approvvigionamento e agli ordini d’acquisto e le informazioni di chiusura possono essere aggiunti dopo la creazione iniziale.
Prestazioni: limiti l’estrazione iniziale in base alle date e ai filtri aziendali validi, recuperi solo i campi necessari, gestisca la paginazione degli oggetti di grandi dimensioni ed eviti di unire ripetutamente interi dataset storici. Quando possibile, estragga in modo incrementale i dati relativi alle relazioni e agli audit.
Qualità dei dati: richieda che PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate siano valorizzati. Se il connettore li rende disponibili, conservi gli identificativi di origine per facilitare la risoluzione dei problemi e la rimozione dei duplicati.
Differenze di configurazione: i nomi degli oggetti e dei campi, i valori di stato, le rappresentazioni di audit e i dati sulle relazioni disponibili variano a seconda del tenant Coupa e del connettore. Se il connettore non offre un equivalente documentato, usi [Configure based on your system].

Query di esempio config

WITH
requisition_created AS (
    SELECT
        CAST(r.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        CAST(r.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(r.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your requisition header object] r
    WHERE r.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND r.created_at < CAST('[Your end date]' AS TIMESTAMP)
      AND [Your company filter]
),
requisition_submitted AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Submitted' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.previous_status AS VARCHAR(255))) = 'draft'
      AND LOWER(CAST(h.new_status AS VARCHAR(255))) = 'pending_approval'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_amended AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('amended', 'updated', 'version_created')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_started AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        CAST(a.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.status AS VARCHAR(255))) = 'pending'
      AND a.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_approved AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        CAST(a.action_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.action AS VARCHAR(255))) = 'approved'
      AND a.action_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.action_time < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_rejected AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        CAST(a.action_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.action AS VARCHAR(255))) = 'rejected'
      AND a.action_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.action_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_withdrawn AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('withdrawn', 'withdrawal', 'cancelled_before_approval')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_approved AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.new_status AS VARCHAR(255))) = 'approved'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_rejected AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.new_status AS VARCHAR(255))) = 'rejected'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_sourced AS (
    SELECT
        CAST(s.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Sourced' AS ActivityName,
        CAST(s.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(s.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your sourcing relationship object] s
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(s.requisition_id AS VARCHAR(255))
    WHERE s.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND s.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
purchase_order_created AS (
    SELECT
        CAST(p.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        CAST(p.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(p.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your purchase order relationship object] p
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(p.requisition_id AS VARCHAR(255))
    WHERE p.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND p.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_closed AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('closed', 'closure', 'cancelled_after_approval')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_created
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_submitted
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_amended
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_started
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_approved
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_rejected
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_withdrawn
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_approved
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_rejected
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_sourced
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM purchase_order_created
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_closed
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

È pronto a iniziare?

Inizi oggi a ottimizzare il processo di acquisto e pagamento delle richieste d’acquisto in Coupa con questo template. Ottenga informazioni utili e migliori l’efficienza degli approvvigionamenti.

Torna alla guida al miglioramento

Scarica il template

Ottimizzi le richieste d’acquisto P2P in Coupa e riduca oggi il tempo di ciclo

Individui le inefficienze e riduca del 30% il tempo di ciclo delle richieste d’acquisto P2P.

Inizi ora la prova gratuita.

Non è richiesta alcuna carta di credito. Ottimizzi i processi in pochi minuti.

Il Suo template dei dati per il processo di acquisto e pagamento delle richieste d’acquisto

Il Suo template dei dati per il processo di acquisto e pagamento delle richieste d’acquisto

Attributi del processo di acquisto e pagamento delle richieste d’acquisto

Attività del processo di acquisto e pagamento delle richieste d’acquisto

Guide all’estrazione

Esportare i dati delle richieste d’acquisto con i report pianificati di Coupa

Passaggi

Configurazione

Query di esempio config

Estrazione con uno script Python tramite l’API REST di Coupa

Passaggi

Configurazione

Query di esempio python

Estrazione con un connettore iPaaS di terze parti

Passaggi

Configurazione

Query di esempio config

È pronto a iniziare?

Ottimizzi le richieste d’acquisto P2P in Coupa e riduca oggi il tempo di ciclo