> Miglioramento continuo dei processi > Purchase to Pay Requisition > Coupa > Template dei dati

Il Suo Template dati per Purchase to Pay, richiesta di acquisto

Coupa

Purchase to Pay - Requisition: attributi (21) Purchase to Pay - Requisition: attività (12) Guide all’estrazione (3)

Il Suo Template dati per Purchase to Pay, richiesta di acquisto

Questo Template dati completo offre un approccio strutturato alla raccolta delle informazioni necessarie per analizzare il processo Purchase to Pay, richiesta di acquisto. Descrive gli attributi e le attività essenziali per creare un Event Log affidabile e include indicazioni utili per estrarre i dati in modo efficace dal Suo sistema Coupa.

Attributi consigliati per un’analisi completa
Attività chiave del processo da monitorare
Indicazioni pratiche per l’estrazione dei dati

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 5 Consigliato 11 Facoltativo

	Nome	Descrizione
	ID della richiesta di acquisto PurchaseRequisitionId	L'identificativo univoco di ogni richiesta di acquisto, utilizzato come identificativo primario del caso nel 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 rimane invariato per tutto il suo ciclo di vita. Ciò consente di monitorare la richiesta dall'inizio alla fine, dalla creazione e dall'invio iniziali, attraverso tutti i passaggi di approvazione o rifiuto, fino al sourcing e alla chiusura finali. Nel Process Mining, ogni voce dell'Event Log è associata a questo ID, consentendo di ricostruire il percorso completo di ogni caso. Perché è importante Si tratta del Case ID essenziale che collega tutti i passaggi del processo e consente un'analisi completa del ciclo di vita della richiesta, dall'inizio alla fine. Dove reperirlo È un campo chiave primario presente nel modulo Requisitions di Coupa e nelle relative esportazioni di dati. Esempi PR-102934PR-102935PR-102936
	Nome dell'attività ActivityName	Il nome della specifica attività o dell'evento aziendale verificatosi in un determinato momento per la richiesta.
Descrizione Questo Attributo registra i diversi passaggi del ciclo di vita della richiesta di acquisto. Tra gli esempi rientrano «Requisition Created», «Approval Step Approved» e «Requisition Sourced». Ogni attività rappresenta una milestone o un'azione specifica eseguita sulla richiesta. Analizzare la sequenza e la frequenza di queste attività è fondamentale nel Process Mining, poiché consente di visualizzare le mappe di processo, identificare i percorsi più comuni e rilevare le deviazioni dalla procedura standard. Perché è importante Definisce i passaggi della mappa di processo, rendendo possibile visualizzare e analizzare il flusso delle richieste. Dove reperirlo In genere deriva dagli Event Log, dai record delle modifiche di stato o dagli audit trail all'interno del sistema Coupa. Potrebbe essere necessario effettuare una mappatura dai campi di stato o dai codici azione. Esempi Richiesta creataRichiesta inviataFase di approvazione approvataRichiesta rifiutataOrdine di acquisto creato
	Ora dell'evento EventTime	La data e l'ora precise in cui si è verificata l'attività.
Descrizione L'ora dell'evento, ovvero il timestamp, registra il momento esatto in cui un'attività è stata registrata per una richiesta di acquisto. Questi dati sono fondamentali per ordinare cronologicamente gli eventi e costruire il flusso del processo. Costituiscono la base di tutte le analisi basate sul tempo, compreso il calcolo dei tempi di ciclo, l'identificazione dei colli di bottiglia attraverso la misurazione della durata tra le attività e la comprensione delle prestazioni del processo in periodi diversi. Timestamp accurati e granulari sono essenziali per un'analisi significativa del processo. 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 reperirlo Queste informazioni sono acquisite nell'audit trail o nei record della cronologia di ogni richiesta in Coupa, spesso nei campi «created_at» o «updated_at» associati 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 dal quale sono stati estratti i dati.
Descrizione Questo Attributo specifica il sistema di riferimento in cui hanno avuto origine i dati di processo. Per questa analisi, il valore sarà sempre «Coupa». Includere questo campo è una best practice, soprattutto negli ambienti in cui i dati possono essere uniti a quelli provenienti da più sistemi. Fornisce un contesto essenziale sulla provenienza dei dati e contribuisce alla gestione delle regole di governance e qualità dei dati. Perché è importante Fornisce una chiara tracciabilità dei dati, fondamentale per la governance dei dati e per l'integrazione di dati provenienti da più sistemi aziendali. Dove reperirlo In genere si tratta di un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per indicare l'origine del dataset. Esempi Coupa
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp che indica l'ultima volta in cui i dati sono stati aggiornati dal sistema di origine.
Descrizione Questo Attributo registra la data e l'ora dell'estrazione più recente dei dati da Coupa. Offre trasparenza sull'aggiornamento dei dati analizzati. Conoscere la loro attualità è fondamentale per consentire agli utenti di capire se gli insight riflettono lo stato operativo corrente o una situazione precedente. Ciò è particolarmente importante per i Dashboard che monitorano le attività in corso. Perché è importante Informa gli utenti sull'aggiornamento dei dati, assicurando che comprendano l'intervallo temporale dell'analisi e prendano decisioni sulla base di informazioni aggiornate. Dove reperirlo Questo timestamp viene generato e aggiunto dalla pipeline dei dati o dallo strumento ETL al termine di un'esecuzione riuscita dell'estrazione dei dati. Esempi 2024-05-21T02:00:00Z
	Approvatore Approver	L'utente o il gruppo responsabile di un'attività di approvazione.
Descrizione Questo Attributo identifica la persona o il gruppo di approvazione specifico assegnato a un passaggio di approvazione. Viene valorizzato per attività come «Approval Step Started», «Approval Step Approved» e «Approval Step Rejected». Analizzare i dati per approvatore è fondamentale per creare il Dashboard «Prestazioni e carico degli approvatori». Aiuta a misurare i tempi di approvazione individuali, identificare 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 identificare i colli di bottiglia associati a persone o gruppi di approvazione specifici. Dove reperirlo Queste informazioni si trovano nei dettagli della catena di approvazione associata a ogni richiesta in Coupa. Potrebbe essere necessario effettuare un join con i dati User. Esempi David MillerApprovatori Finance L2Susan Chen
	Importo totale TotalAmount	Il valore monetario complessivo della richiesta di acquisto.
Descrizione Questo Attributo rappresenta il costo totale di tutti i beni e servizi richiesti nella richiesta. L'importo è un fattore fondamentale nell'analisi del processo, poiché spesso influenza la complessità del Workflow di approvazione: le richieste di valore più elevato richiedono generalmente un numero maggiore di passaggi di approvazione. Analizzare le metriche di processo per fasce di valore, ad esempio <1.000 € e 1.000-10.000 €, può rivelare come il processo gestisce richieste di diversa rilevanza finanziaria. Perché è importante Aiuta ad analizzare come varia il processo per richieste di valore diverso, poiché gli importi più elevati attivano spesso Workflow di approvazione più complessi. Dove reperirlo È un campo standard dell'intestazione dell'oggetto Requisition in Coupa, generalmente denominato «total» o «total_amount». Esempi 500.0012550.7599.99
	Reparto Department	Il reparto aziendale o il centro di costo a cui viene addebitata la richiesta.
Descrizione L'Attributo Department collega ogni richiesta a una specifica unità organizzativa o a un centro di costo. Si tratta di una dimensione fondamentale per l'analisi comparativa. Consente di filtrare e segmentare Dashboard e KPI per reparto, permettendo ai responsabili di confrontare i tempi del ciclo di approvazione, i tassi di rifiuto e la conformità tra le diverse aree dell'organizzazione. In questo modo è possibile individuare problemi o best practice specifici di un reparto. Perché è importante Consente di confrontare KPI di processo, come il tempo di ciclo e i tassi di rifiuto, tra diverse unità aziendali, evidenziando le aree da migliorare. Dove reperirlo È un campo standard dell'oggetto Requisition in Coupa, spesso associato al profilo utente del richiedente o specificato nelle righe della richiesta. Esempi MarketingOperazioni ITGestione delle struttureRicerca e sviluppo
	Richiedente Requester	Il 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 associati a utenti specifici, come tassi elevati di modifica o rifiuti frequenti, che possono indicare la necessità di ulteriore formazione. Viene inoltre utilizzato per analizzare i volumi delle richieste e il comportamento nel processo di utenti o gruppi di utenti diversi. Perché è importante Consente di analizzare il comportamento nel processo per utente, aiutando a individuare le esigenze formative e a comprendere come persone diverse interagiscono con il processo. Dove reperirlo Disponibile come campo standard nell'oggetto Requisition di Coupa, spesso collegato all'oggetto User e denominato «requester» o «created_by». Esempi Alice JohnsonBob SmithCharlie Brown
	Stato della richiesta RequisitionStatus	Lo 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. Gli stati più comuni includono «Pending Approval», «Approved», «Rejected», «Withdrawn» e «Closed». Si tratta di una dimensione fondamentale per il filtraggio e l'analisi. Viene utilizzato per calcolare i tassi di approvazione e rifiuto, monitorare il carico di lavoro corrente delle richieste aperte e comprendere l'esito finale delle richieste. Perché è importante È essenziale per comprendere gli esiti delle richieste, calcolare i tassi di approvazione e rifiuto e monitorare lo stato corrente delle richieste in corso. Dove reperirlo È un campo standard dell'oggetto Purchase Requisition in Coupa, spesso denominato «status» o «state». Esempi In attesa di approvazioneApprovatoRifiutatoRitiratoChiuso
	Categoria merceologica Commodity	La categoria di alto livello dei beni o dei servizi richiesti.
Descrizione L'Attributo Commodity fornisce una classificazione standardizzata degli articoli presenti nella richiesta, come «Office Supplies», «Computer Hardware» o «Marketing Services». Ciò consente di analizzare i modelli di acquisto e le variazioni del processo in base a ciò che viene acquistato. Alcune categorie merceologiche possono richiedere approvazioni o strategie di sourcing specifiche; analizzare il processo per categoria può contribuire a ottimizzare gli approvvigionamenti per le diverse categorie di spesa. Perché è importante Aiuta ad analizzare le categorie di spesa e a comprendere se il comportamento del processo, ad esempio i tempi di approvazione, varia in base al tipo di beni o servizi acquistati. Dove reperirlo È 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 marketingTrasferta
	Durata del passaggio di approvazione ApprovalStepDuration	Il tempo durante il quale una richiesta è rimasta in attesa in un singolo passaggio di approvazione.
Descrizione Questa metrica calcolata misura la durata tra l'attività «Approval Step Started» e la corrispondente attività «Approval Step Approved» o «Approval Step Rejected». Isola il tempo di attesa in ogni singola fase della catena di approvazione. È fondamentale per il Dashboard «Colli di bottiglia critici nei passaggi di approvazione», poiché individua con precisione gli approvatori o le fasi di approvazione che causano i ritardi più significativi nel processo complessivo. Perché è importante Individua i colli di bottiglia specifici all'interno del Workflow di approvazione misurando il tempo di attesa di ogni singolo passaggio, anziché limitarsi al tempo di ciclo totale. Dove reperirlo Calcolata nello strumento di Process Mining determinando la differenza temporale tra «Approval Step Started» e il successivo evento terminale di approvazione, «Approved» o «Rejected». Esempi 1,2 giorni4 ore3,8 giorni
	È stata modificata IsAmended	Un flag booleano impostato su true se la richiesta è stata modificata una o più volte dopo l'invio iniziale.
Descrizione Questo Attributo calcolato è un semplice flag (True/False) che indica se per un determinato caso si è verificata l'attività «Requisition Amended». Semplifica l'analisi e il filtraggio, consentendo agli utenti di isolare facilmente le richieste che hanno richiesto modifiche. Viene utilizzato per calcolare il KPI del tasso di modifica delle richieste e alimentare il Dashboard «Volume delle modifiche alle richieste», contribuendo a individuare le cause principali delle rilavorazioni e a migliorare la qualità al primo invio. 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 reperirlo Viene calcolato nello strumento di Process Mining verificando l'esistenza dell'attività «Requisition Amended» nell'Event Log di ogni caso. Esempi truefalse
	ID dell'ordine di acquisto PurchaseOrderId	L'identificativo dell'ordine di acquisto creato a partire dalla richiesta approvata.
Descrizione Una volta che la richiesta è stata approvata completamente e inviata al sourcing, viene generalmente creato un ordine di acquisto. Questo Attributo memorizza l'ID del PO risultante. Funge da collegamento fondamentale tra il processo Requisition a monte e il processo Purchase Order a valle. Consente di calcolare il KPI «Tempo dall'approvazione della richiesta alla creazione del PO» e di eseguire un'analisi end-to-end più ampia dell'intero ciclo Purchase-to-Pay. Perché è importante Collega la richiesta al successivo ordine di acquisto, consentendo di analizzare il tempo di passaggio e facilitando una visione P2P end-to-end più ampia. Dove reperirlo È un campo standard dell'oggetto Requisition in Coupa, valorizzato dopo la creazione del PO. Esempi PO-45000123PO-45000124PO-45000125
	Livello di urgenza UrgencyLevel	Una classificazione che indica l'urgenza della richiesta, ad esempio «High», «Medium» o «Low».
Descrizione Il livello di urgenza, spesso mappato a un campo di priorità, consente ai richiedenti di segnalare le richieste che richiedono un'elaborazione accelerata. Questo Attributo è essenziale per il 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 prioritizzazione e verificare se le esigenze aziendali urgenti vengono soddisfatte tempestivamente. Perché è importante Consente di analizzare se le richieste urgenti vengono elaborate più rapidamente di quelle standard, verificando l'efficacia delle policy di prioritizzazione. Dove reperirlo Può essere un campo standard o personalizzato dell'oggetto Requisition in Coupa. Consultare la documentazione di Coupa o la configurazione del sistema. Esempi AltaMediaBassa
	Motivo del rifiuto RejectionReason	Il motivo indicato da un approvatore quando una richiesta o un passaggio di approvazione viene rifiutato.
Descrizione Quando un approvatore rifiuta una richiesta, spesso fornisce il motivo della decisione. Questo Attributo acquisisce tale spiegazione testuale. Analizzare i motivi del rifiuto offre un riscontro qualitativo diretto sulle cause del mancato esito delle richieste. Questo insight è prezioso per l'analisi delle cause principali, poiché aiuta a individuare problemi ricorrenti, come codifica errata, budget insufficiente o motivazione inadeguata, che possono essere affrontati attraverso la formazione o il miglioramento del processo. Perché è importante Fornisce una visione diretta delle cause principali dei problemi nel processo, aiutando a individuare le aree che richiedono formazione degli utenti o maggiore chiarezza del processo. Dove reperirlo Queste informazioni vengono generalmente acquisite nel campo dei commenti o delle note associato a una modifica dello stato in «Rejected» nella cronologia delle approvazioni della richiesta. Esempi Centro di costo erratoSupera il budget di questo trimestreRichiesta duplicataMotivazione insufficiente
	Nome del fornitore SupplierName	Il nome del fornitore selezionato per la richiesta.
Descrizione Questo Attributo identifica il fornitore previsto per i beni o i servizi richiesti. Il fornitore può essere indicato dal richiedente o aggiunto successivamente durante il processo di sourcing. Analizzare le metriche di processo per fornitore può aiutare a valutarne le prestazioni e a individuare se le interazioni con determinati fornitori comportano tempi di ciclo più lunghi o altre inefficienze. Fornisce 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, fornendo indicazioni utili per le strategie di sourcing e la gestione dei fornitori. Dove reperirlo Queste informazioni sono disponibili nell'oggetto Requisition Line in Coupa, spesso nel campo «supplier» o «vendor». Esempi StaplesDell TechnologiesAccentureCDW
	Numero di passaggi di approvazione ApprovalStepCount	Il numero totale di passaggi di approvazione attraversati dalla richiesta.
Descrizione Questo Attributo calcolato conta il numero di attività distinte «Approval Step Approved» per ogni richiesta. Aiuta a quantificare la complessità del Workflow di approvazione per ciascun caso. Costituisce la base del KPI «Numero medio di passaggi di approvazione» ed è utile per identificare le richieste che seguono percorsi di approvazione insolitamente lunghi o complessi, i quali possono indicare la necessità di semplificare il Workflow. Perché è importante Quantifica la complessità del Workflow di approvazione per ogni richiesta e aiuta a individuare i percorsi eccessivamente complessi che devono essere semplificati. Dove reperirlo Questa metrica viene calcolata nello strumento di Process Mining contando le occorrenze di «Approval Step Approved» per ogni Case ID. Esempi 253
	Percorso del Workflow di approvazione ApprovalWorkflowPath	Un identificativo della specifica catena di approvazione o del Template di Workflow applicato alla richiesta.
Descrizione Questo Attributo identifica la sequenza predefinita di approvatori che la richiesta dovrebbe seguire. Viene determinato dalle regole aziendali, spesso sulla base di fattori quali importo, reparto e tipo di richiesta. Analizzare questo Attributo è fondamentale per il Dashboard «Conformità alle policy delle richieste». Confrontando la sequenza effettiva degli approvatori con il percorso di Workflow assegnato, è possibile rilevare deviazioni, misurare i tassi di conformità e identificare le 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 dal processo. Dove reperirlo Consultare la documentazione di Coupa. Il dato potrebbe derivare dal nome della catena di approvazione o della regola di Workflow attivata per la richiesta. Esempi Approvazione standard <$5kApprovazione hardware IT >$10kRevisione del CFO per spesa in conto capitale
	Tipo di richiesta RequisitionType	La categoria o il tipo della richiesta, ad esempio «Capital Expense», «Operational Expense» o «Software».
Descrizione Requisition Type è una classificazione che consente di categorizzare le richieste in base alla loro finalità aziendale o alla natura dell'acquisto. Questo Attributo è utile per l'analisi della conformità e per comprendere come i diversi tipi di richiesta attraversano il processo. Ad esempio, le richieste di spesa in conto capitale possono seguire un percorso di approvazione più rigoroso e lungo rispetto alle richieste operative standard. Analizzare il processo per Requisition Type può fornire insight preziosi per l'ottimizzazione del processo. Perché è importante Consente di segmentare l'analisi in base alla finalità aziendale della richiesta, poiché tipi diversi possono seguire flussi di processo e policy distinti. Dove reperirlo È probabilmente un campo di classificazione standard o personalizzato dell'oggetto Requisition in Coupa. Esempi Spesa in conto capitaleSpesa operativaHardware ITServizi professionali
	Valuta Currency	Il codice 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. Costituisce un contesto 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 appropriate nella reportistica finanziaria e nei Dashboard. Perché è importante Fornisce il contesto necessario per l'Attributo «Importo totale», assicurando un'analisi finanziaria accurata negli ambienti multivaluta. Dove reperirlo È un campo standard dell'oggetto Requisition in Coupa, generalmente denominato «currency_code» o in modo analogo. Esempi USDEURGBP

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 Workflow Purchase to Pay, Requisition.

6 Consigliato 6 Facoltativo

	Attività	Descrizione
	Ordine di acquisto creato	Un ordine di acquisto (PO) viene generato correttamente sulla base delle informazioni contenute nella richiesta approvata. L'evento è dedotto quando viene creato un record PO che fa riferimento all'ID della richiesta di origine.
Perché è importante Si tratta del principale esito positivo del processo di richiesta e segna il passaggio alla fase successiva del processo Purchase-to-Pay. Analizzare il tempo trascorso da «Richiesta approvata» a questo evento consente di evidenziare eventuali ritardi nell'esecuzione. Dove reperirlo Dedotta dalla creazione di un record nella tabella «purchase_orders» contenente un riferimento all'ID dell'intestazione o delle righe della richiesta di origine, «requisition_headers» o «requisition_lines». Acquisizione Utilizzare il timestamp «created-at» del record PO collegato all'ID della richiesta. Tipo di evento inferred
	Richiesta approvata	La richiesta ha superato correttamente tutti i passaggi richiesti nel Workflow di approvazione. L'evento è dedotto dalla modifica dello stato complessivo dell'intestazione della richiesta in «approved».
Perché è importante Si tratta di una milestone fondamentale, che segna la conclusione del ciclo di approvazione. Il tempo necessario per raggiungere questa attività è un KPI primario e costituisce il trigger per le successive azioni di approvvigionamento. Dove reperirlo Dedotta dalla modifica dello stato nella tabella «requisition_headers» quando il campo «status» viene aggiornato a «approved». Il timestamp è registrato nel relativo audit trail. Acquisizione Individuare il timestamp in cui lo stato complessivo della richiesta cambia in «approved». Tipo di evento inferred
	Richiesta chiusa	La richiesta viene chiusa formalmente, a indicare che non saranno intraprese ulteriori azioni. Ciò può avvenire dopo la creazione e l'evasione di un PO oppure se la richiesta viene annullata dopo l'approvazione ma prima dell'ordine.
Perché è importante Questa attività costituisce il punto finale definitivo del ciclo di vita della richiesta. Garantisce una conclusione chiara dei casi, impedendo che continuino a comparire come «attivi» nelle analisi di processo. Dove reperirlo Dedotta dalla modifica dello stato nella tabella «requisition_headers» quando il campo «status» viene aggiornato a «closed». Il timestamp è registrato nel relativo audit trail. Acquisizione Individuare il timestamp in cui lo stato complessivo della richiesta cambia in «closed». Tipo di evento inferred
	Richiesta creata	Un utente avvia una nuova richiesta di acquisto e la salva come bozza. Questo rappresenta il punto di partenza di ogni caso di richiesta e viene generalmente 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 causati dall'incertezza dell'utente o dalla complessità del sistema. Dove reperirlo Questo evento viene acquisito dal timestamp «created-at» nella tabella «requisition_headers» per uno specifico ID della Purchase Requisition. Acquisizione Utilizzi il timestamp di creazione del record dell'intestazione della richiesta. Tipo di evento inferred
	Richiesta inviata	Il richiedente invia formalmente la richiesta completata al Workflow di approvazione. Questo evento viene dedotto osservando il cambiamento dello stato della richiesta da «draft» a «pending_approval» nei log di audit o nelle tabelle della cronologia del sistema.
Perché è importante L'invio attiva il processo di approvazione e costituisce quindi una tappa fondamentale per misurare il KPI «Average Requisition Approval Cycle Time». I ritardi precedenti a questo punto sono legati all'utente, mentre quelli successivi sono legati al processo. Dove reperirlo Deducibile da un cambiamento di stato nella tabella «requisition_headers», in particolare quando il campo «status» passa a «pending_approval». Il timestamp di questa modifica si trova nella relativa traccia di audit. Acquisizione Identifichi 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 è dedotto dalla modifica dello stato complessivo dell'intestazione della richiesta in «rejected».
Perché è importante Questa attività rappresenta un esito negativo terminale del processo. Analizzare questi eventi è fondamentale per migliorare il «Tasso di rifiuto delle richieste» e individuare le cause principali, come violazioni delle policy o problemi di budget. Dove reperirlo Dedotta dalla modifica dello stato nella tabella «requisition_headers» quando il campo «status» viene aggiornato a «rejected». Il timestamp è registrato nel relativo audit trail. Acquisizione Individuare il timestamp in cui lo stato complessivo della richiesta cambia in «rejected». Tipo di evento inferred
	Fase di approvazione approvata	Un approvatore del Workflow 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 del processo 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 reperirlo Acquisita da un'azione esplicita «approve» registrata nella tabella «approvals» o nel relativo audit trail, collegata alla specifica richiesta e al relativo approvatore. Acquisizione Filtrare gli eventi «approve» nella cronologia delle approvazioni della richiesta. Tipo di evento explicit
	Fase di approvazione avviata	Un'attività di approvazione viene assegnata a uno specifico approvatore o gruppo di approvazione e la richiesta è ora in attesa di un'azione da parte sua. Questo evento viene dedotto quando viene creato un record di approvazione associato alla richiesta con stato «pending».
Perché è importante Questo segna l'inizio del tempo di attesa per una specifica approvazione. Misurare la durata tra questo evento e il corrispondente «Approval Step Approved/Rejected» aiuta a identificare i colli di bottiglia specifici nella catena di approvazione. Dove reperirlo Deducibile 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 sospeso di un singolo individuo nella catena di approvazione. Tipo di evento inferred
	Passaggio di approvazione rifiutato	Un approvatore rifiuta la richiesta nella fase del Workflow di sua competenza, rinviandola generalmente al richiedente per una modifica. Si tratta di un'azione esplicita registrata da Coupa.
Perché è importante I rifiuti in qualsiasi fase generano rilavorazioni e prolungano i tempi di ciclo. Analizzare dove e perché si verificano i rifiuti è fondamentale per migliorare il processo e la formazione degli utenti. Dove reperirlo Acquisita da un'azione esplicita «reject» registrata nella tabella «approvals» o nel relativo audit trail, collegata alla specifica richiesta e al relativo approvatore. Acquisizione Filtrare gli eventi «reject» nella cronologia delle approvazioni della richiesta. Tipo di evento explicit
	Richiesta inviata al sourcing	La richiesta approvata viene inviata a un evento di sourcing, come una RFQ o un'asta, invece di essere convertita immediatamente in un ordine di acquisto. L'evento è dedotto quando la richiesta viene collegata a un oggetto relativo a un evento di sourcing.
Perché è importante Questa attività evidenzia un importante percorso alternativo nel processo di approvvigionamento. Distingue gli acquisti semplici dalle attività di sourcing più complesse e strategiche, consentendo un'analisi più precisa dei tempi di ciclo. Dove reperirlo Dedotta rilevando una modifica dello stato in «sourcing» oppure identificando la creazione di un collegamento tra la tabella «requisition_lines» e una tabella relativa agli eventi di sourcing. Acquisizione Verificare la modifica dello stato in «sourcing» o la creazione di un collegamento a un ID di evento di sourcing. Tipo di evento inferred
	Richiesta modificata	Il richiedente o un altro utente autorizzato modifica la richiesta dopo che è già stata inviata. Coupa registra esplicitamente l'operazione come una nuova versione o una voce di audit, spesso reimpostando in parte o completamente il Workflow di approvazione.
Perché è importante Monitorare le modifiche è fondamentale per comprendere il lavoro di rifacimento e le inefficienze del processo. Un volume elevato di modifiche può indicare requisiti iniziali poco chiari o policy di acquisto complesse, incidendo sul KPI «Requisition Amendment Rate». Dove reperirlo Questo dato viene acquisito dalle tabelle della traccia di audit associate alla tabella «requisition_headers», che registrano le modifiche di versione o specifiche azioni di «edit». Acquisizione Cerchi eventi espliciti di «edit» o «update» nel log della cronologia della richiesta dopo l'invio. Tipo di evento explicit
	Richiesta ritirata	Il richiedente originale annulla la richiesta prima che riceva l'approvazione finale. Si tratta di un'azione esplicita avviata dall'utente che interrompe il processo per quella richiesta.
Perché è importante I ritiri possono indicare un cambiamento delle esigenze aziendali, richieste duplicate o tentativi degli utenti di aggirare il processo. Monitorarli aiuta a comprendere la volatilità della domanda e i potenziali problemi di aderenza al processo. Dove reperirlo Dedotta da una modifica dello stato nella tabella «requisition_headers» a «withdrawn» o a uno stato analogo, sulla base di un'azione esplicita dell'utente registrata nell'audit trail. Acquisizione Individuare il timestamp in cui lo stato della richiesta cambia in «withdrawn». Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i Suoi dati da Coupa

Passaggi

Acceda a Coupa: acceda alla Sua istanza Coupa con un account utente autorizzato a creare e pianificare report.
Acceda al modulo di reporting: apra la scheda 'Configurazione' e individui la sezione 'Reporting'. Selezioni 'Report' per aprire la Dashboard di reporting.
Crei un nuovo report personalizzato: faccia clic sul pulsante 'Crea' per iniziare a creare un nuovo report. Selezioni 'Report personalizzato' come tipo.
Definisca le origini dati del report: nel generatore di report, selezioni e colleghi più origini dati per raccogliere tutte le informazioni necessarie. Inizi con 'Testate delle richieste di acquisto' come origine principale. Aggiunga quindi i seguenti oggetti correlati:
- 'Approvazioni': per ottenere i dettagli di ogni passaggio di approvazione, inclusi approvatore, Stato e timestamp.
- 'Righe delle richieste di acquisto': per aggregare gli importi totali e ottenere i dettagli a livello di articolo.
- 'Testate degli ordini di acquisto': per individuare il momento in cui una richiesta viene convertita in un ordine di acquisto.
- 'Utenti': per recuperare i nomi completi e i dettagli del Reparto dei richiedenti e degli approvatori.
Configuri le colonne del report: trascini i campi necessari dalle origini dati disponibili nel layout del report. Questo è il passaggio più importante, poiché queste colonne verranno utilizzate per generare l’Event Log. Includa almeno quanto segue:
- Da Testate delle richieste di acquisto: Requisition #, Created At, Submitted At, Updated At, Stato, Created by (Login ID), Totale, Sourced Externally?
- Da Utenti (per il richiedente): Nome completo, Department Name.
- Da Approvazioni: Created At, Updated At, Stato, Approver (Login ID).
- Da Testate degli ordini di acquisto: PO Number, Created At.
Imposti i filtri del report: applichi filtri per definire l’ambito dell’estrazione dei dati. Un filtro comune ed efficace consiste nell’utilizzare 'Testate delle richieste di acquisto - Created At' e impostare un intervallo di date dinamico, ad esempio 'Ultimi 90 giorni'. Se pertinente, può anche filtrare codici società specifici.
Pianifichi il report: acceda alla scheda 'Pianificazione' nel generatore di report. Definisca la frequenza di esecuzione, ad esempio giornaliera o settimanale. Imposti l’orario in una fascia di minore attività.
Configuri la distribuzione: specifichi il metodo di distribuzione. Per automatizzare il processo, selezioni 'SFTP' e fornisca le credenziali del server e la directory di destinazione. In alternativa, può inviare il file a un indirizzo e-mail. Scelga 'CSV' come formato del file.
Salvi e attivi: salvi il report e verifichi che la pianificazione sia attiva. Il primo report verrà eseguito al successivo orario pianificato.
Trasformi i dati: il CSV generato è un file flat, non un Event Log. Deve utilizzare uno script esterno, ad esempio Python, o uno strumento ETL per elaborare il file. Lo script deve trasformare i dati creando una riga distinta per ogni attività, ad esempio una riga per 'Richiesta di acquisto creata' utilizzando la colonna Created At, un’altra riga per ogni passaggio di approvazione utilizzando le colonne 'Approvazioni' e una riga per 'Ordine di acquisto creato' utilizzando Created At dell’ordine di 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 è ora pronto per essere caricato.

Configurazione

Origini dati principali: il report deve essere creato collegando più oggetti Coupa. Le origini principali sono Requisition Headers, Approvals, Requisition Lines e Purchase Order Headers.
Filtro dell’intervallo di date: è fondamentale applicare un filtro data per limitare il volume dei dati. Come punto di partenza, si consiglia una finestra mobile degli ultimi 3-6 mesi basata su Requisition Headers - Created At.
Caricamenti incrementali: per l’analisi continuativa, pianifichi l’esecuzione giornaliera del report ed estragga i dati del giorno precedente, ad esempio Yesterday, per creare caricamenti incrementali.
Configurazione della distribuzione: configuri la consegna a un server SFTP per un’integrazione automatizzata e affidabile con la pipeline dati. 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 il reporting, così da poter creare e pianificare il report e accedere a tutti gli oggetti dati necessari, inclusi Requisitions, POs, Approvals e Users.

a 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 disporre di un ambiente Python 3 installato. Installi le librerie necessarie, pandas e requests, eseguendo pip install pandas requests nel terminale o nel prompt dei comandi.
Ottenga la chiave API di Coupa: acceda alla Sua istanza Coupa come amministratore. Vada a Setup > Company Setup > API Keys. Crei una nuova chiave API con almeno autorizzazioni 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. Copi in questo file lo script Python 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 dell’estrazione. In questo modo filtrerà le richieste in base alla data di creazione.
Esegua lo script: esegua lo script dal terminale utilizzando il comando python extract_coupa_reqs.py. Lo script si collegherà all’API Coupa, recupererà i dati e mostrerà gli aggiornamenti di avanzamento nella console.
Gestisca la paginazione dell’API: lo script include una funzione per gestire automaticamente la paginazione dell’API. Recupererà i dati in blocchi, o pagine, di 50 record e continuerà fino a ottenere tutte le richieste comprese nell’intervallo di date specificato.
Elabori i dati delle richieste: per ogni intestazione di richiesta recuperata, lo script genera gli eventi Requisition Created e Requisition Submitted. Esegue quindi ulteriori chiamate API per recuperare i dati associati alle approvazioni e agli ordini di acquisto.
Generi gli eventi delle attività: lo script elabora i record delle approvazioni 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 quali Requisition Approved, Purchase Order Created e Requisition Withdrawn.
Rilevi le modifiche: lo script verifica l’attributo version di ogni richiesta. Se la versione è superiore a 1, significa che è stata apportata una modifica. Viene quindi creato un evento Requisition Amended utilizzando il timestamp updated-at della versione più recente.
Assembli l’Event Log: tutti gli eventi generati vengono raccolti in un elenco strutturato. Ogni evento include gli attributi obbligatori, quali PurchaseRequisitionId, ActivityName ed EventTime, oltre ad attributi consigliati come Requester e TotalAmount.
Esporti in CSV: una volta elaborate tutte le richieste, lo script converte l’elenco finale degli eventi in un DataFrame pandas e lo salva come file CSV denominato coupa_requisition_event_log.csv nella stessa directory. Il file è formattato per il caricamento diretto in ProcessMind.

Configurazione

Autorizzazioni della chiave API: la chiave API utilizzata per l’estrazione deve disporre dell’accesso in lettura agli oggetti requisition_headers, requisition_lines, approvals, purchase_orders e users in Coupa. In assenza di tali autorizzazioni, lo script non funzionerà o restituirà dati incompleti.
Intervallo di date: lo script utilizza un filtro basato sulla data di creazione della richiesta (created-at). Si consiglia di estrarre i dati in blocchi gestibili, ad esempio da 3 a 6 mesi alla volta, per evitare tempi di esecuzione prolungati e possibili timeout dell’API. Modifichi di conseguenza le variabili START_DATE e END_DATE.
Filtro per stato: lo script fornito recupera tutte le richieste, indipendentemente dal loro stato. Per un’analisi più mirata, può aggiungere un parametro status al dizionario params nella chiamata API iniziale, così da selezionare stati specifici come approved, pending_approval o ordered.
Limite di paginazione: lo script è configurato per recuperare 50 record per chiamata API (limit=50). Si tratta di un valore standard che funziona bene con l’API Coupa. Aumentarlo non migliora necessariamente le prestazioni e potrebbe aumentare il rischio di timeout per query complesse.
Considerazioni sulle prestazioni: lo script esegue più chiamate API per ogni richiesta, una per l’intestazione, una per le approvazioni e una per gli ordini di acquisto. L’estrazione dei dati relativi a migliaia di richieste può richiedere tempo ed essere soggetta ai limiti di frequenza dell’API Coupa. È preferibile eseguire lo script al di fuori degli orari di punta.

a Query di esempio python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your 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 selezionata offra un connettore Coupa verificato, con accesso alle intestazioni delle richieste, alla cronologia o ai dati di audit delle richieste, ai record delle approvazioni, alle relazioni di sourcing, alle relazioni con gli ordini di acquisto e alle informazioni di chiusura. I nomi dei connettori, degli oggetti e dei campi disponibili variano in base al fornitore; li configuri pertanto secondo la documentazione del connettore e il Suo tenant Coupa.
Crei una connessione al connettore utilizzando l’interfaccia di connessione della piattaforma. Inserisca l’URL del tenant Coupa, il metodo di autenticazione, le credenziali, i dettagli OAuth e gli eventuali ambiti richiesti. Utilizzi segnaposto come [Your Coupa tenant URL] e [Your connector credentials] fino alla configurazione della connessione nell’ambiente di destinazione.
Configuri l’ambito dell’estrazione. Selezioni inizialmente un intervallo mobile di tre-sei mesi, quindi lo estenda dopo la riconciliazione. Applichi esclusivamente filtri validi per il Suo tenant, come [Your company filter] o [Your document type filter]. Non escluda le richieste soltanto perché il loro stato attuale è closed, rejected, withdrawn o approved, poiché questi casi sono necessari per l’analisi del ciclo di vita.
Mappi gli oggetti di origine nel connettore. Selezioni l’oggetto dell’intestazione della richiesta, l’oggetto della cronologia o dell’audit della richiesta, l’oggetto delle approvazioni, l’oggetto della relazione di sourcing, l’oggetto della relazione con l’ordine di acquisto e qualsiasi oggetto di cronologia della chiusura o dello stato esposto dal connettore. Se un oggetto necessario non è disponibile, utilizzi la rappresentazione della cronologia o dell’audit supportata dal connettore oppure documenti la limitazione prima di pubblicare l’estrazione.
Configuri le mappature di caso ed evento. Mappi l’identificativo della richiesta a PurchaseRequisitionId, l’etichetta dell’evento ad ActivityName, il timestamp di origine a EventTime, il valore costante Coupa a SourceSystem e il timestamp di aggiornamento del connettore a LastDataUpdate. Mappi richiedente, reparto, importo totale, stato della richiesta e approvatore quando tali campi sono disponibili.
Configuri regole evento che creino esplicitamente righe per tutte le dodici attività. Crei Requisition Created dal timestamp di creazione della richiesta, Requisition Submitted dalla transizione da draft 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 sospeso, Approval Step Approved da un’azione di approvazione, Approval Step Rejected da un’azione di rifiuto, Requisition Withdrawn da un’azione di ritiro esplicita o da una transizione di stato, Requisition Approved dalla transizione dello stato dell’intestazione ad approved, Requisition Rejected dalla transizione dello stato dell’intestazione a rejected, Requisition Sourced da una relazione tra richiesta e sourcing, Purchase Order Created da un ordine di acquisto che fa riferimento alla richiesta e Requisition Closed da un’azione o una transizione di stato di chiusura.
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 del timestamp di origine, converta l’identificativo della richiesta in un tipo di testo coerente e conservi i valori di stato e utente di origine. Deduplichi esclusivamente i record di origine tecnicamente identici, utilizzando come chiave di confronto l’identificativo della richiesta, il nome dell’attività, il timestamp dell’evento, l’identificativo del record di origine quando disponibile e l’approvatore.
Pubblichi o pianifichi il flusso del connettore. Utilizzi 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 periodo di lookback 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 disponga di un evento di creazione, che le transizioni di stato e approvazione seguano la cronologia prevista e che gli eventi basati sulle relazioni siano presenti quando esistono sourcing o ordini di acquisto.
Esporti il risultato finale come CSV piatto o in un altro formato di Event Log supportato da ProcessMind. Includa una riga per evento, utilizzi 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 affidarsi a ProcessMind per dedurre gli eventi mancanti.

Configurazione

Connettore e accesso: utilizzi un connettore Coupa verificato, fornito dalla piattaforma iPaaS o di Process Mining selezionata. Le autorizzazioni Coupa, gli ambiti API, i moduli e le licenze del connettore necessari dipendono dal fornitore e dalla configurazione del tenant. Verifichi l’accesso ai dati delle richieste, della cronologia o dell’audit, delle approvazioni, del sourcing, degli ordini di acquisto e della chiusura prima dell’implementazione.
Intervallo di date: inizi con un intervallo di dati compreso tra tre e sei mesi. Utilizzi una finestra mobile per le estrazioni pianificate e includa un periodo di lookback per acquisire aggiornamenti tardivi, azioni di approvazione e richieste modificate.
Mappature necessarie: mappi l’identificativo della richiesta a PurchaseRequisitionId, l’etichetta dell’evento ad ActivityName, il timestamp dell’evento a EventTime, il valore dell’origine a SourceSystem e il timestamp di aggiornamento a LastDataUpdate.
Mappature consigliate: mappi lo stato della richiesta, il richiedente, il reparto o centro di costo, l’importo totale e l’approvatore. Conservi sia i valori correnti sia quelli a livello di evento quando il connettore supporta gli snapshot storici.
Regole evento: configuri la creazione esplicita di tutti i dodici eventi richiesti. ProcessMind legge l’Event Log così com’è e non ricava né deduce ulteriori eventi.
Filtri: applichi esclusivamente 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, salvo che l’analisi non lo richieda espressamente.
Gestione dei timestamp: converta i timestamp in un fuso orario comune, conservi la precisione di origine e definisca una regola di ordinamento deterministica per gli eventi con timestamp identici.
Aggiornamento incrementale: utilizzi il campo updated-at o il campo di rilevamento delle modifiche supportato dal connettore. Configuri una finestra di lookback, poiché la cronologia delle approvazioni, i collegamenti di sourcing, i collegamenti agli ordini di acquisto e le informazioni di chiusura possono essere aggiunti dopo la creazione iniziale.
Prestazioni: limiti l’estrazione iniziale in base alla data e a filtri aziendali validi, recuperi soltanto i campi necessari, utilizzi la paginazione per gli oggetti di grandi dimensioni ed eviti di unire ripetutamente interi dataset storici. Estragga in modo incrementale i dati delle relazioni e degli audit quando supportato.
Qualità dei dati: richieda valori non vuoti per PurchaseRequisitionId, ActivityName, EventTime, SourceSystem e LastDataUpdate. Conservi gli identificativi di origine per la risoluzione dei problemi e la deduplicazione quando il connettore li espone.
Variabilità della configurazione: i nomi degli oggetti e dei campi, i valori di stato, le rappresentazioni degli audit e i dati sulle relazioni disponibili variano in base al tenant Coupa e al connettore. Utilizzi [Configure based on your system] quando il connettore non espone un equivalente documentato.

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

Inizi oggi stesso a ottimizzare il processo Coupa Purchase to Pay, richiesta di acquisto con questo Template. Ottenga informazioni preziose e migliori l’efficienza del Suo processo di approvvigionamento.

Torna alla guida al miglioramento Scarica il Template

Ottimizzi le richieste Coupa P2P e riduca oggi i tempi di ciclo

Individui le inefficienze e riduca del 30% i tempi di ciclo delle Sue richieste P2P.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Ottimizzi il processo in pochi minuti.

Il Suo Template dati per Purchase to Pay, richiesta di acquisto

Il Suo Template dati per Purchase to Pay, richiesta di acquisto

Purchase to Pay - Requisition: attributi

Purchase to Pay - Requisition: attività

Guide all’estrazione

Report pianificati Coupa per l’esportazione dei dati delle richieste

Passaggi

Configurazione

a Query di esempio config

Estrazione tramite script Python con l’API REST di Coupa

Passaggi

Configurazione

a Query di esempio python

Estrazione tramite un connettore iPaaS di terze parti

Passaggi

Configurazione

a Query di esempio config

È pronto per iniziare?

Ottimizzi le richieste Coupa P2P e riduca oggi i tempi di ciclo

Il Suo Template dati per Purchase to Pay, richiesta di acquisto

Il Suo Template dati per Purchase to Pay, richiesta di acquisto

Purchase to Pay - Requisition: attributi

Purchase to Pay - Requisition: attività

Guide all’estrazione

Report pianificati Coupa per l’esportazione dei dati delle richieste

Passaggi

Configurazione

a Query di esempio config

Estrazione tramite script Python con l’API REST di Coupa

Passaggi

Configurazione

a Query di esempio python

Estrazione tramite un connettore iPaaS di terze parti

Passaggi

Configurazione

a Query di esempio config

È pronto per iniziare?

Ottimizzi le richieste Coupa P2P e riduca oggi i tempi di ciclo

La Sua privacy è importante