> Miglioramento continuo dei processi > Gestione delle note spese > Coupa Expenses > Template dei dati

Il Suo template di dati per la gestione delle spese

Coupa Expenses

Attributi della gestione delle spese(20) Attività di gestione delle spese(13) Guide all’estrazione(2)

Il Suo template di dati per la gestione delle spese

Questo template di dati completo offre un approccio strutturato per analizzare il processo di gestione delle spese in Coupa Expenses. Illustra quali attributi dei dati raccogliere, quali attività monitorare e come estrarre i dati. Lo utilizzi per raccogliere tutte le informazioni necessarie a un’analisi approfondita con Process Mining.

Attributi consigliati per raccogliere dati in modo completo
Attività chiave della gestione delle spese da monitorare
Istruzioni dettagliate per estrarre i dati da Coupa Expenses

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

Scarica il template

Attributi della gestione delle spese

Questi sono i campi dati consigliati da includere nell’Event Log per analizzare in modo completo il processo di gestione delle spese.

5 Obbligatorio 7 Consigliato 8 Facoltativo

	Nome	Descrizione
	ID della nota spese ExpenseReportId	Identificativo univoco della nota spese, che raggruppa tutte le attività e le spese relative a un singolo invio.
Descrizione L’ID della nota spese è l’identificativo principale del caso e raggruppa tutti gli eventi e le attività relativi a un singolo invio di spese. A ogni nota spese viene assegnato un ID univoco al momento della creazione, che consente di ricostruire cronologicamente l’intero percorso della richiesta, dall’inserimento iniziale al pagamento finale. Nell’analisi di Process Mining, questo ID è essenziale per ricostruire il percorso completo di ogni nota spese. Consente agli analisti di visualizzare i flussi di processo, individuare le variazioni nei percorsi di elaborazione e calcolare metriche a livello di caso, come il tempo di ciclo totale e i cicli di rilavorazione delle singole richieste. Perché è importante È la chiave essenziale per collegare tutti gli eventi relativi a una singola richiesta di rimborso e analizzare l’intero processo dall’inizio alla fine. Dove reperirli È una chiave primaria negli oggetti delle note spese di Coupa; spesso compare come 'id' o 'report-id' nell’endpoint Expense Reports dell’API o nelle tabelle sottostanti. Esempi ER-0012345ER-0012399ER-0013001
	Nome dell’attività ActivityName	Nome dell’evento aziendale che si è verificato in un momento specifico per una nota spese.
Descrizione Il nome dell’attività descrive un passaggio o una tappa specifica del processo di gestione delle note spese, ad esempio 'Nota spese inviata', 'Approvata dal responsabile' o 'Rimborso eseguito'. Queste attività costituiscono i nodi della mappa del processo e sono alla base dell’analisi dei flussi, dei colli di bottiglia e delle variazioni. L’analisi di questo attributo aiuta a comprendere la sequenza degli eventi, la frequenza dei diversi passaggi e le transizioni tra di essi. È fondamentale per creare la mappa del processo, calcolare i tempi di transizione e individuare i percorsi più comuni o non conformi. Perché è importante Definisce i passaggi del processo e consente di visualizzare e analizzare il flusso, elemento centrale del Process Mining. Dove reperirli In genere si ricava dai log degli eventi, dai record delle modifiche di stato o dalle tabelle del registro di controllo associate all’oggetto della nota spese in Coupa. Potrebbe essere necessario associare i codici di stato o i tipi di evento a nomi comprensibili per gli utenti. Esempi Nota spese inviataApprovata dal responsabileRifiutata dall’ufficio finanziarioRimborso eseguito
	Ora dell’evento EventTime	Data e ora in cui si è verificata un’attività o un evento.
Descrizione L’ora dell’evento indica la data e l’ora esatte in cui una specifica attività è stata registrata nel sistema. Questo timestamp è essenziale per ordinare cronologicamente gli eventi e per tutte le analisi basate sul tempo. Fornisce un riferimento oggettivo per comprendere quando si svolgono i passaggi del processo e quanto durano. Nel Process Mining, questo attributo serve a ricostruire la cronologia di ogni caso, calcolare la durata tra le attività, individuare i ritardi e misurare i tempi di ciclo complessivi. È fondamentale per analizzare le prestazioni, il rispetto degli accordi sui livelli di servizio e l’eventuale presenza di schemi temporali o colli di bottiglia. Perché è importante Questo timestamp stabilisce l’ordine cronologico degli eventi ed è alla base di tutte le analisi di durata e prestazioni, compresi il tempo di ciclo e l’individuazione dei colli di bottiglia. Dove reperirli Queste informazioni si trovano nelle tabelle del registro di controllo o dei log degli eventi di Coupa, in genere insieme al record dell’attività o della modifica di stato. Esempi 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
	Sistema di origine SourceSystem	Il sistema da cui provengono i dati.
Descrizione Questo attributo identifica l’applicazione di origine in cui sono stati generati i dati degli eventi. In questo caso, si tratta di 'Coupa Expenses'. È importante per la governance dei dati e per distinguere quelli provenienti da sistemi diversi nella vista di un processo che coinvolge più sistemi. Indica l’origine dei dati, un’informazione utile quando si analizzano processi che si svolgono in più applicazioni. Perché è importante Fornisce informazioni essenziali sull’origine dei dati, fondamentali per la governance, la convalida e l’analisi dei processi che coinvolgono più sistemi. 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 ExpensesCoupa
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento o dell’ultima estrazione dei dati dal sistema di origine.
Descrizione Questo attributo registra la data e l’ora dell’ultima estrazione dei dati da Coupa Expenses e del loro caricamento nello strumento di Process Mining. Indica quanto sono aggiornati i dati analizzati. Queste informazioni sono importanti perché consentono agli utenti di valutare l’attualità dell’analisi e di verificare se le Dashboard riflettono la situazione operativa più recente. Sono metadati essenziali per la governance dei dati e per garantire l’affidabilità dei risultati analitici. Perché è importante Indica quanto sono aggiornati i dati, così gli utenti possono comprendere il periodo a cui si riferisce l’analisi e valutarne l’attualità. Dove reperirli In genere, questo timestamp viene generato e memorizzato dallo strumento di estrazione dei dati o ETL al termine di un caricamento completato correttamente. Esempi 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	Importo totale TotalAmount	Valore monetario complessivo della nota spese.
Descrizione Questo attributo rappresenta la somma di tutte le righe di spesa incluse nella nota. È una metrica finanziaria importante per comprendere il valore che attraversa il processo. L’analisi dell’importo totale consente di suddividere le note spese in fasce di valore, che possono seguire iter di approvazione o livelli di controllo diversi. Nelle Dashboard, serve ad analizzare le abitudini di spesa, individuare le note di importo elevato che potrebbero creare colli di bottiglia e correlare il valore della nota ai tempi di elaborazione o ai tassi di rifiuto. Perché è importante Fornisce un contesto finanziario per il processo e consente di analizzare le note spese in base al loro valore, che spesso influisce sull’iter di approvazione e sulla priorità di elaborazione. Dove reperirli È un campo standard nell’intestazione della nota spese in Coupa, spesso denominato 'total' o 'total-amount'. Esempi 150.752500.0085.50
	Indicatore di violazione delle policy PolicyViolationFlag	Indicatore booleano che vale true se la nota spese è stata segnalata per una violazione delle policy.
Descrizione Coupa può segnalare automaticamente le spese che violano le policy aziendali, ad esempio quando superano i limiti di spesa o riguardano fornitori non approvati. Questo attributo è un semplice indicatore true o false che segnala se è stata rilevata una violazione per la nota spese. L’indicatore è essenziale per monitorare e analizzare la conformità. Consente di creare Dashboard che mostrano l’andamento delle violazioni delle policy nel tempo e nei diversi reparti. Permette inoltre di confrontare la gestione delle note non conformi con quella delle altre, ad esempio per verificare se richiedono più tempo per l’approvazione o vengono respinte più spesso. Perché è importante Consente di misurare e analizzare direttamente la conformità alle policy, aiutando a individuare e affrontare le aree a rischio elevato o caratterizzate da frequenti inosservanze. Dove reperirli In genere è disponibile come indicatore o stato nella nota spese o nelle singole righe di spesa in Coupa. Spesso viene impostato dal motore di regole del sistema. Esempi truefalse
	Motivo del rifiuto RejectionReason	Motivo indicato quando un approvatore respinge una nota spese.
Descrizione Quando un approvatore, che sia un responsabile o un membro dell’ufficio finanziario, respinge una nota spese, spesso ne indica il motivo. Questo attributo registra la motivazione, che può essere selezionata da un elenco predefinito o inserita come testo libero. È un attributo molto utile per individuare le cause profonde dei problemi. Analizzando i motivi di rifiuto più frequenti, le organizzazioni possono capire se le policy non sono chiare, se i dipendenti hanno bisogno di ulteriore formazione o se il processo di invio presenta criticità. Queste informazioni aiutano direttamente a ridurre le rilavorazioni e ad aumentare la percentuale di approvazioni al primo tentativo. Perché è importante Spiega direttamente perché si verificano le rilavorazioni e fornisce indicazioni utili per ridurre i rifiuti con interventi mirati di formazione, chiarimenti sulle policy o miglioramenti del processo. Dove reperirli Queste informazioni sono in genere registrate nel registro di controllo o nei commenti associati a un evento di rifiuto in Coupa. Possono trovarsi in un campo dedicato oppure essere ricavate dai commenti. Esempi Ricevuta mancanteSpesa non conforme alla policyCategoria di spesa errataInvio duplicato
	Nome utente UserName	Nome del dipendente o dell’utente che ha svolto l’attività.
Descrizione Questo attributo identifica la persona associata a un evento specifico, ad esempio chi ha inviato, approvato o respinto una nota spese. Può contenere un nome, un ID dipendente o il nome dell’account utente del sistema. L’analisi del processo per utente aiuta a individuare schemi nelle prestazioni, nella distribuzione del carico di lavoro e nelle esigenze di formazione. È essenziale per le Dashboard che suddividono le metriche per risorsa, ad esempio per confrontare i tempi di approvazione dei diversi responsabili. Perché è importante Associa le attività a persone specifiche, consentendo di analizzare il carico di lavoro, le prestazioni e i comportamenti delle risorse nel processo. Dove reperirli Queste informazioni sono in genere disponibili nelle tabelle del registro di controllo di Coupa Expenses e collegate a ogni evento o azione. Cerchi campi come 'user-id', 'submitted-by' o 'updated-by'. Esempi John Smithjsmith11023
	Ora di fine EndTime	Data e ora in cui un’attività è stata completata.
Descrizione L’ora di fine indica la conclusione di un’attività. In molti sistemi transazionali, un’attività è un evento istantaneo, quindi l’ora di fine coincide con l’ora di inizio. Se invece l’attività ha una durata misurabile, questo attributo ne registra il momento di conclusione. Il campo è essenziale per calcolare con precisione il tempo di elaborazione delle singole attività. Consente di analizzare meglio come viene impiegato il tempo nel processo e di distinguere l’attesa dal lavoro effettivo. Perché è importante Consente di calcolare con precisione la durata delle attività, un dato fondamentale per individuare e analizzare il tempo dedicato a specifiche attività rispetto a quello trascorso in attesa. Dove reperirli Per gli eventi atomici, spesso coincide con l’ora di inizio (EventTime). Per le attività che hanno una durata, potrebbe essere necessario ricavare il dato da un campo separato o calcolarlo in base al timestamp dell’evento successivo. Esempi 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
	Reparto del dipendente EmployeeDepartment	Reparto del dipendente che ha inviato la nota spese.
Descrizione Questo attributo indica il reparto o l’unità aziendale a cui appartiene chi ha inviato la nota spese. In genere, l’informazione si ricava dai dati anagrafici dei dipendenti. È una dimensione essenziale per confrontare le prestazioni del processo tra le diverse aree dell’organizzazione. Le Dashboard che analizzano per reparto i tempi di approvazione, i tassi di rifiuto o le violazioni delle policy si basano su questo attributo per individuare le aree in cui servono miglioramenti del processo o interventi di formazione mirati. Perché è importante Consente di confrontare le prestazioni tra i reparti e di individuare le aree dell’organizzazione più efficienti e quelle che potrebbero aver bisogno di supporto. Dove reperirli Si ricava dal profilo dell’utente che ha inviato la nota spese in Coupa oppure collegando i dati a un sistema esterno di gestione delle risorse umane tramite l’ID utente. Cerchi un campo 'department' nell’oggetto utente. Esempi VenditeMarketingIngegneriaFinanza
	Stato della nota spese ExpenseReportStatus	Stato attuale o finale della nota spese.
Descrizione Questo attributo indica lo stato complessivo della nota spese al termine del suo ciclo di vita, ad esempio 'Approvata', 'Pagata', 'Respinta' o 'Ritirata'. Fornisce l’esito conclusivo di ogni caso. Nell’analisi, lo stato finale serve a filtrare i casi completati e a classificare gli esiti. È essenziale per calcolare metriche come il tasso di rifiuto e comprendere la percentuale di note che raggiunge ciascuno stato finale possibile. Aiuta inoltre a individuare le note bloccate in uno stato intermedio. Perché è importante Definisce l’esito di ogni caso ed è fondamentale per le analisi basate sui risultati, ad esempio per confrontare i percorsi delle note approvate con quelli delle note respinte. Dove reperirli È un campo di stato principale dell’oggetto nota spese in Coupa. Si trova nei dati dell’intestazione e viene aggiornato durante il processo. Esempi in attesa di approvazioneapprovatapagatarespinta
	Approvata al primo tentativo IsFirstPassApproval	Indicatore che vale true se la nota spese è stata approvata senza rifiuti o revisioni.
Descrizione Questo attributo calcolato a livello di caso indica se la nota spese ha superato il processo di approvazione al primo tentativo. Viene impostato su 'true' se il caso non contiene attività di rifiuto o di restituzione per revisione. L’attributo misura direttamente l’efficienza del processo di invio e approvazione ed è alla base del KPI relativo al tasso di approvazione al primo tentativo. Analizzare i fattori associati a un tasso basso, come il reparto o la categoria di spesa, può fornire indicazioni utili per migliorare il processo. Perché è importante Fornisce una misura chiara della qualità e dell’efficienza del processo e aiuta a quantificare la percentuale di note elaborate senza rilavorazioni. Dove reperirli Si calcola a livello di caso. Occorre esaminare tutte le attività associate a un determinato ExpenseReportId e verificare che non siano presenti eventi di rifiuto o revisione. Esempi truefalse
	Categoria di spesa ExpenseCategory	Categoria della spesa, ad esempio viaggi, pasti o forniture per ufficio.
Descrizione Questo attributo classifica il tipo di spesa richiesto. Le note spese contengono spesso più righe, ciascuna con una propria categoria. Per l’analisi a livello di caso, si può utilizzare la categoria più frequente o un elenco aggregato. Suddividere il processo per categoria di spesa può rivelare comportamenti o colli di bottiglia diversi. Ad esempio, le spese di viaggio potrebbero seguire un iter di approvazione più complesso rispetto agli acquisti di forniture per ufficio. Questa dimensione è essenziale per capire come la natura della spesa influisce sul suo percorso di elaborazione. Perché è importante Consente di suddividere il processo in base al tipo di spesa e di individuare colli di bottiglia, policy o iter di approvazione specifici per ciascuna categoria. Dove reperirli Queste informazioni sono memorizzate a livello di singola riga di spesa in Coupa. Per l’analisi a livello di caso, devono essere aggregate, ad esempio utilizzando la categoria della riga di importo più elevato. Esempi Biglietto aereoPasti e intrattenimentoSoftwareForniture per ufficio
	Centro di costo CostCenter	Centro di costo a cui vengono imputate le spese.
Descrizione Il centro di costo è una dimensione finanziaria utilizzata per la contabilità e la pianificazione del budget, che indica quale area dell’organizzazione sosterrà il costo delle spese. Può essere diverso dal reparto di chi ha inviato la nota. L’analisi per centro di costo offre una prospettiva contabile sul processo. Consente di monitorare le spese e l’efficienza del processo rispetto a budget o unità finanziarie specifici. È particolarmente importante per gli uffici finanziari che devono comprendere e gestire le spese dell’organizzazione. Perché è importante Fornisce una dimensione finanziaria essenziale per l’analisi e consente di collegare direttamente le metriche di processo alle unità finanziarie e di budget. Dove reperirli È un campo contabile standard in Coupa, presente nell’intestazione della nota spese o nelle singole righe. Spesso fa parte del piano dei conti. Esempi CC4510-MarketingCC2100-IngegneriaCC7800-Vendite-Est
	È una rilavorazione IsRework	Indicatore che segnala se un’attività fa parte di un ciclo di rilavorazione, ad esempio quando una nota viene restituita per una revisione.
Descrizione Questo attributo booleano calcolato segnala le attività che rappresentano una rilavorazione. In genere viene impostato su 'true' per eventi come 'Restituita per revisione' o per qualsiasi attività che si verifica nello stesso caso dopo tale evento. Individuare le rilavorazioni è uno degli obiettivi principali del Process Mining. Questo indicatore ne semplifica l’analisi, consentendo di filtrare e aggregare direttamente i dati. Serve a calcolare il tasso di rilavorazione, visualizzare i relativi cicli nella mappa del processo e analizzare le cause profonde delle attività che costringono a ripetere alcuni passaggi. Perché è importante Segnala direttamente i cicli di rilavorazione inefficienti e consente di quantificarne facilmente la frequenza, l’impatto sul tempo di ciclo e le cause profonde. Dove reperirli Si calcola in base al flusso del processo. Occorre applicare una logica per individuare le attività che indicano un ritorno a una fase precedente, ad esempio 'Restituita per revisione'. Esempi truefalse
	Motivo della violazione delle policy PolicyViolationReason	Motivo specifico per cui la nota spese è stata segnalata per una violazione delle policy.
Descrizione Quando viene segnalata una violazione delle policy, questo attributo ne specifica il motivo, ad esempio 'Importo superiore al limite' o 'Esercente non approvato'. Fornisce quindi più dettagli rispetto a un semplice indicatore booleano. Analizzare i motivi delle violazioni permette di comprendere più a fondo i problemi di conformità. Aiuta a individuare le policy che vengono violate più spesso, segnalando la necessità di comunicare meglio le regole, modificarle o applicarle con maggiore rigore. È un elemento fondamentale per definire strategie efficaci di miglioramento della conformità. Perché è importante Fornisce dettagli specifici sui problemi di conformità e consente di intervenire in modo mirato per migliorare il rispetto delle policy aziendali sulle spese. Dove reperirli Queste informazioni sono in genere disponibili nei dettagli dell’indicatore di violazione o nel messaggio di avviso generato dal motore di conformità di Coupa. Esempi Limite giornaliero per i pasti superatoLa spesa è un duplicatoÈ necessaria la ricevuta
	Nome dell’approvatore ApproverName	Nome del responsabile o dell’utente dell’ufficio finanziario che ha approvato o respinto la nota spese.
Descrizione Questo attributo identifica l’approvatore coinvolto in un passaggio di approvazione del responsabile o dell’ufficio finanziario. Si distingue dall’utente che ha inviato la nota. Questi dati sono utili per analizzare le prestazioni e il comportamento degli approvatori. Consentono di misurare i tempi di approvazione per singola persona e di individuare i colli di bottiglia causati da approvatori sovraccarichi o che necessitano di ulteriore formazione. Sono inoltre utili per creare Dashboard che aiutano a bilanciare il carico di lavoro e a rendere più efficiente l’approvazione. Perché è importante Aiuta a individuare i colli di bottiglia nell’iter di approvazione, associando i ritardi o gli elevati tassi di rifiuto a specifici approvatori e consentendo interventi mirati. Dove reperirli Si trova nella cronologia delle approvazioni o nel registro di controllo della nota spese in Coupa. Ogni passaggio di approvazione dovrebbe riportare l’utente che ha eseguito l’azione. Esempi Sarah ChenDavid RodriguezCoda del team finanziario
	Paese Country	Paese del dipendente che ha inviato la nota o della transazione.
Descrizione Questo attributo indica il paese associato alla nota spese, che di solito corrisponde al paese di residenza del dipendente che l’ha inviata. È una dimensione importante per analizzare i processi di un’organizzazione globale. L’analisi per paese consente di confrontare le prestazioni, la conformità e le variazioni del processo nelle diverse aree geografiche. Può mettere in luce differenze regionali nelle normative, nelle policy o nell’efficienza operativa che richiedono un intervento. Perché è importante Consente di confrontare le prestazioni e la conformità del processo nelle diverse aree geografiche, un’esigenza essenziale per le organizzazioni globali. Dove reperirli Si può ricavare dal profilo dell’utente in Coupa o dall’entità giuridica associata alla nota spese. Esempi USADEUGBRJPN
	Valuta Currency	Codice della valuta in cui è espresso l’importo totale della nota spese.
Descrizione Questo attributo indica la valuta in cui è espresso l’importo totale della nota spese, ad esempio USD, EUR o GBP. È un’informazione essenziale per interpretare correttamente i dati finanziari. Quando si analizzano le spese di un’organizzazione globale, questo campo è fondamentale per interpretare e aggregare correttamente i valori monetari. Per confrontare in modo significativo le diverse aree geografiche, potrebbe essere necessario convertire tutti gli importi in un’unica valuta di riferimento. Perché è importante Fornisce il contesto necessario per interpretare i valori monetari, garantisce l’accuratezza dell’analisi finanziaria e consente di convertire le valute per la rendicontazione globale. Dove reperirli È un campo standard nell’intestazione della nota spese in Coupa, in genere accanto all’importo totale e spesso denominato 'currency-code'. Esempi USDEURGBPJPY

Obbligatorio Consigliato Facoltativo

Attività di gestione delle spese

Queste sono le fasi e le tappe fondamentali da registrare nell’Event Log per individuare e analizzare con precisione il flusso di lavoro delle spese.

6 Consigliato 7 Facoltativo

	Attività	Descrizione
	Approvata dal responsabile	Il responsabile diretto del dipendente o l’approvatore di primo livello approva la nota spese. L’azione viene registrata come evento esplicito nella cronologia delle approvazioni della nota, con il relativo timestamp.
Perché è importante Segna il completamento del primo livello di approvazione. Analizzare il tempo necessario per raggiungere questo evento è essenziale per il KPI Tempo del ciclo di approvazione e per individuare i colli di bottiglia a livello dei responsabili. Dove reperirli Ricavato dal timestamp dell’azione di approvazione nella cronologia dettagliata delle approvazioni di Coupa o nel registro di audit della nota spese. Acquisizione Dal timestamp dell’evento di approvazione nel registro della cronologia delle approvazioni della nota spese. Tipo di evento explicit
	Approvata dall’ufficio finanziario	Il team finanziario o di audit concede l’approvazione finale della nota spese. L’evento indica che la nota è stata convalidata ed è pronta per l’elaborazione del pagamento; viene registrato nella cronologia delle approvazioni.
Perché è importante È la tappa finale dell’approvazione. Il tempo che intercorre tra l’approvazione del responsabile e quella dell’ufficio finanziario è una componente fondamentale del ciclo di approvazione complessivo. Dove reperirli Ricavato dal timestamp dell’approvazione finale nella cronologia dettagliata delle approvazioni o nel registro di audit della nota spese. Acquisizione Dal timestamp dell’evento di approvazione finale nella cronologia delle approvazioni della nota spese. Tipo di evento explicit
	Nota spese creata	Segna l’inizio del ciclo di vita della nota spese. L’evento viene registrato quando un utente crea e salva per la prima volta una nuova nota spese, che viene così impostata come bozza.
Perché è importante È il punto di partenza per tutte le analisi del processo ed è essenziale per misurare il tempo di ciclo complessivo della nota spese, dall’inizio alla fine. Dove reperirli È un evento esplicito, ricavato dal timestamp di creazione del record di intestazione della nota spese in Coupa. La fonte è il timestamp 'created_at' nella tabella delle intestazioni delle spese. Acquisizione Utilizzi il timestamp di creazione dell’oggetto nota spese. Tipo di evento explicit
	Nota spese inviata	Il dipendente invia formalmente la nota spese completata per l’approvazione. Questa azione porta la nota dallo stato di bozza a quello di approvazione in sospeso e viene registrata esplicitamente dal sistema.
Perché è importante È una tappa fondamentale che avvia il conteggio dei tempi di approvazione. La durata tra creazione e invio indica quanto tempo impiegano i dipendenti a preparare le note spese. Dove reperirli Ricavato dal timestamp di invio presente nel record della nota spese oppure dalla voce corrispondente all’evento di invio nel registro di audit. Acquisizione Utilizzi il campo timestamp 'submitted_at' della nota spese. Tipo di evento explicit
	Registrazione contabile effettuata	Le transazioni finanziarie relative alla nota spese vengono registrate nel libro mastro generale. Dal punto di vista della contabilità finanziaria, questo è l’ultimo passaggio del processo.
Perché è importante Questa è l’attività conclusiva e segna la fine effettiva del processo. Il tempo che intercorre tra il rimborso e la registrazione è determinante per chiudere i conti in modo rapido e accurato. Dove reperirli L’evento viene rilevato in base alla data di registrazione della scrittura contabile o delle righe contabili associate alla nota spese, gestite dall’integrazione contabile di Coupa. Acquisizione Dal campo della data di registrazione presente nelle righe contabili relative alla nota spese. Tipo di evento explicit
	Rimborso eseguito	Il pagamento viene elaborato correttamente e i fondi sono versati al dipendente. L’evento conferma che il dipendente ha ricevuto il pagamento e completa la fase di rimborso del processo.
Perché è importante È una tappa fondamentale per la soddisfazione dei dipendenti e rappresenta il punto finale del KPI Tempo medio di attraversamento del rimborso. Dove reperirli Ricavato dalla data di esecuzione del pagamento nel record associato alla nota spese, in genere in Coupa Pay o in un sistema integrato di contabilità fornitori. Acquisizione Dalla data di pagamento nel record associato e collegato alla nota spese. Tipo di evento explicit
	Controllo della policy eseguito	Viene eseguito un controllo automatico della conformità alle policy aziendali sulle spese. In genere, l’evento si deduce dal timestamp in cui viene impostato per la prima volta un avviso o un indicatore di violazione della policy sulla nota.
Perché è importante È essenziale per la Dashboard di panoramica della conformità alle policy. Aiuta a capire se e quando vengono rilevate violazioni nel processo e quale impatto hanno sui tempi di approvazione. Dove reperirli Deducibile dal timestamp associato all’applicazione di un indicatore di violazione della policy a una riga di spesa o all’intestazione della nota. Acquisizione Timestamp in cui viene impostato per la prima volta un indicatore di violazione della policy sulla nota spese o sulle relative righe. Tipo di evento inferred
	Nota spese ritirata	Il dipendente ritira una nota spese inviata prima che sia stata approvata completamente. Questa azione annulla il processo di approvazione in corso e viene registrata come evento esplicito.
Perché è importante Registra i casi in cui i dipendenti correggono autonomamente o annullano l’invio, circostanza che può indicare confusione sul processo. Si tratta di un’interruzione del processo. Dove reperirli Ricavato da un’azione esplicita dell’utente, che porta allo stato 'Ritirata' o 'Annullata' e viene registrata nel registro di audit. Acquisizione Dal timestamp dell’azione 'ritira' nel registro di audit della nota spese. Tipo di evento explicit
	Restituita per revisione	Un approvatore restituisce la nota al dipendente perché apporti correzioni, senza rifiutarla definitivamente. Questa azione crea un ciclo di rilavorazione e si deduce da una modifica dello stato o da un evento specifico nel registro di audit.
Perché è importante Questa attività è fondamentale per analizzare i cicli di rilavorazione. Capire perché le note vengono restituite aiuta a migliorare la formazione e il tasso di approvazione al primo tentativo. Dove reperirli Deducibile da una modifica dello stato a valori come 'Correzione in sospeso' o 'Restituita'. Coupa potrebbe anche registrare esplicitamente l’azione nella cronologia delle approvazioni. Acquisizione Timestamp della modifica dello stato a un valore che indica la necessità di una revisione, oppure evento specifico nel registro di audit. Tipo di evento inferred
	Ricevute allegate	Rappresenta l’azione dell’utente che carica o allega le ricevute a una riga di spesa della nota. L’evento viene rilevato osservando la creazione dei record degli allegati collegati alla nota spese.
Perché è importante Analizzare la frequenza e i tempi di questa attività può rivelare schemi nel comportamento degli utenti e possibili ritardi dovuti alla documentazione mancante. Dove reperirli Deducibile dal timestamp di creazione dei record degli allegati collegati allo specifico ID della nota spese. Acquisizione Individui i timestamp in cui i record degli allegati vengono collegati alla nota spese. Tipo di evento inferred
	Rifiutata dal responsabile	Il responsabile del dipendente rifiuta la nota spese, interrompendo spesso il processo e restituendola al dipendente. L’azione viene registrata come evento specifico nella cronologia delle approvazioni.
Perché è importante È un esito negativo che mette in evidenza gli ostacoli nel processo. Analizzare questi eventi è essenziale per la Dashboard e il KPI del tasso di rifiuto delle note spese. Dove reperirli Ricavato dal timestamp dell’azione di rifiuto nella cronologia delle approvazioni o nel registro di audit della nota spese. Acquisizione Dal timestamp dell’evento di rifiuto nel registro della cronologia delle approvazioni della nota spese. Tipo di evento explicit
	Rifiutata dall’ufficio finanziario	Il team finanziario o di audit rifiuta la nota spese, determinando un esito negativo definitivo. L’evento viene registrato come stato di rifiuto finale nella cronologia della nota.
Perché è importante Monitorare i rifiuti da parte dell’ufficio finanziario aiuta a individuare gravi problemi di conformità o documentazione che potrebbero essere sfuggiti alle revisioni precedenti e che incidono sul KPI del tasso di rifiuto. Dove reperirli Ricavato dal timestamp dell’azione di rifiuto eseguita da un approvatore dell’ufficio finanziario nel registro di audit della nota spese. Acquisizione Dal timestamp dell’evento di rifiuto nel registro di audit, durante la fase di revisione dell’ufficio finanziario. Tipo di evento explicit
	Rimborso programmato	Dopo l’approvazione finale, la nota spese viene inserita in un lotto di pagamenti. Questo segna il passaggio dalla fase di approvazione a quella di elaborazione del pagamento.
Perché è importante Questa attività avvia il conteggio del tempo del ciclo di esecuzione del rimborso. Eventuali ritardi indicano un arretrato nel trasferimento delle note approvate al sistema di pagamento. Dove reperirli Deducibile dalla modifica dello stato a 'Pagamento in sospeso' o dalla data in cui la nota viene associata a un record di lotto di pagamento in Coupa Pay. Acquisizione Timestamp della modifica dello stato a 'Pagamento in sospeso' oppure data di creazione del lotto di pagamento associato. Tipo di evento inferred

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Coupa Expenses

Passaggi

Prerequisiti: Verifichi di disporre di un account utente Coupa con le autorizzazioni necessarie, in genere il ruolo di amministratore o specialista delle integrazioni, per accedere alle esportazioni pianificate e configurarle. Dovrà inoltre poter accedere a un server SFTP su cui Coupa possa depositare i file esportati.
Accedere alle esportazioni pianificate: Acceda alla Sua istanza Coupa. Apra il menu Setup e, nella sezione Integrations, selezioni Scheduled Exports.
Configurare l’esportazione dei rendiconti spese: Selezioni il pulsante 'Create'. Configuri la prima esportazione per l’oggetto 'Expense Report'. Le assegni un nome descrittivo, ad esempio 'ProcessMind_Expense_Reports'. Selezioni 'CSV' come formato. Nella sezione 'Fields', selezioni colonne quali id, created-at, submitted-at, updated-at, status, total, user-id e gli altri attributi pertinenti a livello di rendiconto.
Configurare l’esportazione dello storico delle approvazioni: Crei una seconda esportazione pianificata per l’oggetto 'Expense Report Approval'. La denomini 'ProcessMind_Expense_Approvals'. Includa campi quali id, created-at, updated-at, status, approver-id ed expense-report-id. Questo oggetto è essenziale per registrare gli eventi di approvazione, rifiuto e revisione.
Configurare l’esportazione degli allegati: Crei una terza esportazione per l’oggetto 'Expense Report Attachment' e la denomini 'ProcessMind_Expense_Attachments'. Includa il timestamp created-at e l’expense-report-id o expense-line-id associato, per rilevare quando vengono aggiunte le ricevute.
Configurare l’esportazione delle fatture per i pagamenti: Crei una quarta esportazione per l’oggetto 'Invoice from Expense Report'. La denomini 'ProcessMind_Expense_Invoices'. È necessaria per monitorare gli eventi di rimborso e contabilità. Includa campi quali expense-report-id, paid-date, scheduled-payment-date, exported e updated-at.
Impostare la consegna e la pianificazione: Per ciascuna esportazione creata, apra la scheda 'Delivery'. Inserisca i dati di connessione al server SFTP, inclusi host, nome utente e percorso della directory. Imposti il metodo di autenticazione, in genere tramite password o chiave. Nella scheda 'Schedule', imposti la frequenza su 'Daily' per ricevere aggiornamenti regolari.
Eseguire e acquisire le esportazioni: Attivi le pianificazioni e, se necessario, esegua manualmente le esportazioni per la prima volta. Predisponga un processo automatizzato, ad esempio uno script ETL o uno strumento di acquisizione per il data warehouse, per recuperare i file CSV dal server SFTP e caricarli in un database di staging.
Trasformare i dati in un Event Log: Esegua sui dati di staging uno script di trasformazione, ad esempio la query SQL fornita. Lo script combina i dati delle diverse tabelle (rendiconti, approvazioni e fatture) per creare un’unica tabella Event Log.
Esportare i dati per ProcessMind: Esporti la tabella Event Log risultante dal database o dal data warehouse in un unico file CSV. Verifichi che le intestazioni delle colonne corrispondano agli attributi richiesti, come ExpenseReportId, ActivityName ed EventTime. Il file è pronto per essere caricato nello strumento di Process Mining.

Configurazione

Prerequisiti: È necessario disporre di un modulo Coupa Expenses attivo. L’utente che configura le esportazioni deve avere un ruolo con autorizzazioni per 'Scheduled CSV Exports'. È inoltre necessario un server SFTP; se richiesto, il relativo indirizzo IP deve essere inserito nella lista degli indirizzi autorizzati.
Oggetti Coupa principali: L’estrazione si basa sulla pianificazione delle esportazioni di diversi oggetti dati standard di Coupa: 'Expense Report', 'Expense Report Approval', 'Expense Report Attachment' e 'Invoice from Expense Report'.
Configurazione SFTP: Dovrà fornire l’URL del server SFTP, la porta (in genere 22), le credenziali di un utente dedicato e la directory di destinazione dei file. Verifichi che la connessione funzioni correttamente nell’interfaccia di Coupa.
Intervallo di date e filtri: In genere, le esportazioni pianificate includono i record creati o aggiornati dall’ultima esecuzione completata correttamente. Per il caricamento iniziale dei dati storici, può impostare un intervallo specifico per created-at o updated-at che copra il periodo desiderato, ad esempio gli ultimi 6-12 mesi.
Formato dei file: Utilizzi sempre il formato CSV, semplice da gestire e ampiamente compatibile con gli strumenti di elaborazione dei dati.
Frequenza di pianificazione: Per il Process Mining è consigliabile pianificare un’esportazione giornaliera, così da mantenere i dati del processo ragionevolmente aggiornati. Eseguirla nelle ore di minore attività può contribuire a ridurre eventuali effetti sulle prestazioni.

Query di esempio sql

WITH last_update AS (
  SELECT CURRENT_TIMESTAMP AS last_data_update
)
SELECT
  er.id AS ExpenseReportId,
  'Expense Report Created' AS ActivityName,
  er."created-at" AS EventTime,
  er."updated-at" AS EndTime,
  u.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_reports er
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu

UNION ALL

SELECT
  er.id AS ExpenseReportId,
  'Receipts Attached' AS ActivityName,
  att."created-at" AS EventTime,
  att."updated-at" AS EndTime,
  u.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_attachments att
JOIN stg_expense_reports er ON att.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu

UNION ALL

SELECT
  er.id AS ExpenseReportId,
  'Expense Report Submitted' AS ActivityName,
  er."submitted-at" AS EventTime,
  er."updated-at" AS EndTime,
  u.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_reports er
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE er."submitted-at" IS NOT NULL

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Manager Approved' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'approved' AND approver.role LIKE '%Manager%'

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Manager Rejected' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  era.reason AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'rejected' AND approver.role LIKE '%Manager%'

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Sent Back For Revision' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  era.reason AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'sent_back'

UNION ALL

SELECT
  er.id AS ExpenseReportId,
  'Policy Check Performed' AS ActivityName,
  er."updated-at" AS EventTime,
  er."updated-at" AS EndTime,
  'System' AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_reports er
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE er.has_policy_violations = TRUE

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Finance Approved' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'approved' AND approver.role LIKE '%Finance%'

UNION ALL

SELECT
  era.expense_report_id AS ExpenseReportId,
  'Finance Rejected' AS ActivityName,
  era."updated-at" AS EventTime,
  era."updated-at" AS EndTime,
  approver.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  era.reason AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_report_approvals era
JOIN stg_expense_reports er ON era.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
LEFT JOIN stg_users approver ON era.approver_id = approver.id
CROSS JOIN last_update lu
WHERE era.status = 'rejected' AND approver.role LIKE '%Finance%'

UNION ALL

SELECT
  er.id AS ExpenseReportId,
  'Expense Report Withdrawn' AS ActivityName,
  er."updated-at" AS EventTime,
  er."updated-at" AS EndTime,
  u.full_name AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_expense_reports er
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE er.status = 'withdrawn'

UNION ALL

SELECT
  inv.expense_report_id AS ExpenseReportId,
  'Reimbursement Scheduled' AS ActivityName,
  inv.scheduled_payment_date AS EventTime,
  inv.updated_at AS EndTime,
  'System' AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_invoices_from_expense_reports inv
JOIN stg_expense_reports er ON inv.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE inv.scheduled_payment_date IS NOT NULL

UNION ALL

SELECT
  inv.expense_report_id AS ExpenseReportId,
  'Reimbursement Executed' AS ActivityName,
  inv.paid_date AS EventTime,
  inv.updated_at AS EndTime,
  'System' AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_invoices_from_expense_reports inv
JOIN stg_expense_reports er ON inv.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE inv.paid_date IS NOT NULL

UNION ALL

SELECT
  inv.expense_report_id AS ExpenseReportId,
  'Accounting Posted' AS ActivityName,
  inv.updated_at AS EventTime,
  inv.updated_at AS EndTime,
  'System' AS UserName,
  u.department_name AS EmployeeDepartment,
  er.total AS TotalAmount,
  er.status AS ExpenseReportStatus,
  NULL AS RejectionReason,
  er.has_policy_violations AS PolicyViolationFlag,
  'Coupa' AS SourceSystem,
  lu.last_data_update AS LastDataUpdate
FROM stg_invoices_from_expense_reports inv
JOIN stg_expense_reports er ON inv.expense_report_id = er.id
LEFT JOIN stg_users u ON er.user_id = u.id
CROSS JOIN last_update lu
WHERE inv.exported = TRUE;

Passaggi

Prerequisiti e configurazione dell’ambiente: Verifichi di avere installato Python 3.6 o una versione successiva. Installi le librerie necessarie, pandas per la manipolazione dei dati e requests per effettuare chiamate API, eseguendo pip install pandas requests nel terminale. Dovrà inoltre richiedere all’amministratore Coupa una chiave API con autorizzazioni di lettura per i rendiconti spese, le righe di spesa, gli allegati e le approvazioni.
Generare una chiave API Coupa: Acceda alla Sua istanza Coupa. Selezioni Setup > Company Setup > API Keys. Crei una nuova chiave API e verifichi che disponga delle autorizzazioni di lettura per i moduli Expense richiesti. Conservi la chiave in modo sicuro, poiché consente di accedere ai dati aziendali.
Inizializzare lo script Python: Crei un nuovo file Python. Inizi importando le librerie necessarie (requests, pandas, datetime). Definisca le costanti globali per l’URL della Sua istanza Coupa (ad esempio, https://[your_company].coupahost.com), la chiave API e le intestazioni necessarie per l’autenticazione API.
Definire l’intervallo di date e i parametri API: Specifichi le date di inizio e fine del periodo di estrazione. Verranno utilizzate come filtri nelle chiamate API per limitare il volume dei dati. Definisca anche il limite di paginazione, che per Coupa è in genere di 50 record per richiesta.
Recuperare le intestazioni dei rendiconti spese: Implementi una funzione per recuperare tutte le intestazioni dei rendiconti spese comprese nell’intervallo di date specificato. La funzione deve gestire la paginazione effettuando chiamate ripetute all’endpoint /api/expense_reports e incrementando il parametro offset finché non vengono recuperati tutti i rendiconti. Salvi le intestazioni in un elenco.
Scorrere i risultati e recuperare i dati dettagliati: Scorra le intestazioni dei rendiconti spese ottenute nel passaggio precedente. Per ciascun rendiconto, effettui chiamate API separate per recuperare i dettagli associati: le approvazioni da /api/expense_reports/{id}/approvals e gli allegati da /api/expense_reports/{id}/attachments. Questi dati sono essenziali per creare l’Event Log completo.
Creare l’Event Log: Inizializzi un elenco vuoto in cui inserire i record dell’Event Log. Durante l’elaborazione di ciascun rendiconto e dei relativi dettagli, trasformi le risposte API grezze in righe standardizzate dell’Event Log. Per ciascuna delle 13 attività richieste, crei un dizionario che rappresenti un singolo evento e lo aggiunga all’elenco. Ad esempio, utilizzi il campo created-at per l’evento 'Expense Report Created' e scorra i dati delle approvazioni per creare gli eventi 'Manager Approved' o 'Finance Rejected'.
Associare i dati API agli attributi: Nella logica di trasformazione, associ i campi JSON delle risposte API di Coupa agli attributi richiesti e consigliati. Ad esempio, associ id a ExpenseReportId, created-at a EventTime e total a TotalAmount. Estragga le informazioni sull’utente e sul reparto dagli oggetti utente annidati.
Gestire gli eventi dedotti: Alcune attività, come 'Reimbursement Scheduled' o 'Accounting Posted', vengono dedotte dalle modifiche di stato. Utilizzi il campo status del rendiconto e il timestamp updated-at per generare questi eventi. Ad esempio, una modifica dello stato in 'processing_payment' può essere registrata come attività 'Reimbursement Scheduled'.
Creare ed esportare il DataFrame: Dopo aver elaborato tutti i rendiconti spese e inserito gli eventi nell’elenco, lo converta in un DataFrame pandas. Aggiunga colonne statiche come SourceSystem e LastDataUpdate. Infine, esporti il DataFrame in un file CSV con il metodo to_csv, verificando che index sia impostato su False. Il file CSV è pronto per essere caricato in ProcessMind.

Configurazione

Autorizzazioni della chiave API: La chiave API utilizzata per l’autenticazione deve disporre almeno dell’accesso in sola lettura ai seguenti oggetti Coupa: Expense Reports, Expense Lines, Users, Approvals e Attachments.
URL dell’istanza Coupa: Dovrà fornire l’URL di base dell’istanza Coupa aziendale (ad esempio, https://your-company.coupahost.com). È l’indirizzo di base per tutte le chiamate agli endpoint API.
Filtri per l’intervallo di date: È fondamentale filtrare i dati per un periodo specifico, così da gestire le prestazioni e il volume dei dati. Utilizzi i parametri di query created-at[gt] (maggiore di) e created-at[lt] (minore di). In genere, si inizia con un intervallo di 3-6 mesi di dati.
Limite di paginazione: L’API Coupa limita il numero di record restituiti da una singola richiesta, in genere a 50. Lo script deve gestire questo limit e utilizzare il parametro offset per recuperare tutte le pagine successive.
Filtri di stato: Per restringere ulteriormente l’ambito dell’estrazione, può aggiungere un filtro status alla query iniziale delle intestazioni dei rendiconti spese. Ad esempio, può estrarre solo i rendiconti con stato 'approved', 'paid' o 'denied'.
Considerazioni sulle prestazioni: Lo script effettua più chiamate API per ciascun rendiconto spese. Se l’istanza contiene decine di migliaia di rendiconti, l’estrazione può richiedere molto tempo. Valuti di eseguire lo script nelle ore di minore attività o di implementare un caricamento incrementale basato sul timestamp updated-at.

Query di esempio python

import requests
import pandas as pd
import datetime
import time

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

class=class="hl-string">"hl-comment"># Define the date range for the extraction
class=class="hl-string">"hl-comment"># Format: YYYY-MM-DDTHH:MM:SSZ (UTC)
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-12-31T23:59:59Z"

class=class="hl-string">"hl-comment"># API request headers
HEADERS = {
    class="hl-string">"Accept": class="hl-string">"application/json",
    class="hl-string">"X-COUPA-API-KEY": API_KEY
}

class=class="hl-string">"hl-comment"># Static values for the event log
SOURCE_SYSTEM = class="hl-string">"Coupa Expenses"
LAST_DATA_UPDATE = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

def get_paginated_data(endpoint, params):
    class="hl-string">"""Helper function to fetch all pages for a given API endpoint."""
    all_data = []
    offset = 0
    limit = 50
    while True:
        params[class="hl-string">'offset'] = offset
        params[class="hl-string">'limit'] = limit
        try:
            response = requests.get(endpoint, headers=HEADERS, params=params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            if not data:
                break
            all_data.extend(data)
            offset += limit
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {endpoint}: {e}")
            break
    return all_data

def main():
    class="hl-string">"""Main function to extract, transform, and save expense data."""
    print(class="hl-string">"Starting expense report extraction...")
    event_log = []

    class=class="hl-string">"hl-comment"># 1. Fetch all expense report headers in the date range
    reports_endpoint = fclass="hl-string">"{COUPA_URL}/api/expense_reports"
    reports_params = {
        class="hl-string">"created-at[gt]": START_DATE,
        class="hl-string">"created-at[lt]": END_DATE,
        class="hl-string">"fields": class="hl-string">"["idclass="hl-string">", "created-atclass="hl-string">", "updated-atclass="hl-string">", "submitted-atclass="hl-string">", "withdrawn-atclass="hl-string">", "statusclass="hl-string">", "totalclass="hl-string">", "userclass="hl-string">", "exportedclass="hl-string">", "expense-linesclass="hl-string">", "policy-violationsclass="hl-string">"]"
    }
    expense_reports = get_paginated_data(reports_endpoint, reports_params)

    print(fclass="hl-string">"Found {len(expense_reports)} expense reports to process.")

    class=class="hl-string">"hl-comment"># 2. Process each expense report to create events
    for i, report in enumerate(expense_reports):
        print(fclass="hl-string">"Processing report {i+1}/{len(expense_reports)}: ID {report['id']}")
        
        class=class="hl-string">"hl-comment"># Common attributes for all events of this case
        base_event = {
            class="hl-string">'ExpenseReportId': report[class="hl-string">'id'],
            class="hl-string">'TotalAmount': float(report.get(class="hl-string">'total', 0.0)),
            class="hl-string">'ExpenseReportStatus': report.get(class="hl-string">'status'),
            class="hl-string">'EmployeeDepartment': report.get(class="hl-string">'user', {}).get(class="hl-string">'department', {}).get(class="hl-string">'name') if report.get(class="hl-string">'user', {}).get(class="hl-string">'department') else None,
            class="hl-string">'SourceSystem': SOURCE_SYSTEM,
            class="hl-string">'LastDataUpdate': LAST_DATA_UPDATE,
            class="hl-string">'EndTime': None, class=class="hl-string">"hl-comment"># EndTime can be populated if duration is meaningful
            class="hl-string">'RejectionReason': None, class=class="hl-string">"hl-comment"># Will be populated by rejection events
            class="hl-string">'PolicyViolationFlag': bool(report.get(class="hl-string">'policy-violations'))
        }

        class=class="hl-string">"hl-comment"># Event: Expense Report Created
        event_log.append({
            **base_event,
            class="hl-string">'ActivityName': class="hl-string">'Expense Report Created',
            class="hl-string">'EventTime': report[class="hl-string">'created-at'],
            class="hl-string">'UserName': report.get(class="hl-string">'user', {}).get(class="hl-string">'fullname')
        })
        
        class=class="hl-string">"hl-comment"># Event: Expense Report Submitted
        if report.get(class="hl-string">'submitted-at'):
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Expense Report Submitted',
                class="hl-string">'EventTime': report[class="hl-string">'submitted-at'],
                class="hl-string">'UserName': report.get(class="hl-string">'user', {}).get(class="hl-string">'fullname')
            })

        class=class="hl-string">"hl-comment"># Event: Expense Report Withdrawn
        if report.get(class="hl-string">'withdrawn-at'):
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Expense Report Withdrawn',
                class="hl-string">'EventTime': report[class="hl-string">'withdrawn-at'],
                class="hl-string">'UserName': report.get(class="hl-string">'user', {}).get(class="hl-string">'fullname')
            })
        
        class=class="hl-string">"hl-comment"># Event: Policy Check Performed (inferred)
        if base_event[class="hl-string">'PolicyViolationFlag']:
             event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Policy Check Performed',
                class="hl-string">'EventTime': report[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Using updated-at as a proxy timestamp
                class="hl-string">'UserName': class="hl-string">'System'
            })

        class=class="hl-string">"hl-comment"># 3. Fetch attachments for class="hl-string">'Receipts Attached' event
        attachments_endpoint = fclass="hl-string">"{COUPA_URL}/api/expense_reports/{report['id']}/attachments"
        attachments = get_paginated_data(attachments_endpoint, {})
        if attachments:
            first_attachment_time = min(att[class="hl-string">'created-at'] for att in attachments if class="hl-string">'created-at' in att)
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Receipts Attached',
                class="hl-string">'EventTime': first_attachment_time,
                class="hl-string">'UserName': report.get(class="hl-string">'user', {}).get(class="hl-string">'fullname')
            })

        class=class="hl-string">"hl-comment"># 4. Fetch approvals for approval/rejection events
        approvals_endpoint = fclass="hl-string">"{COUPA_URL}/api/expense_reports/{report['id']}/approvals"
        approvals = get_paginated_data(approvals_endpoint, {})
        
        is_first_approval = True
        for approval in sorted(approvals, key=lambda x: x[class="hl-string">'updated-at']):
            activity = None
            rejection_reason = approval.get(class="hl-string">'reason')
            
            if approval[class="hl-string">'status'] == class="hl-string">'approved':
                activity = class="hl-string">'Manager Approved' if is_first_approval else class="hl-string">'Finance Approved'
                is_first_approval = False
            elif approval[class="hl-string">'status'] == class="hl-string">'rejected':
                activity = class="hl-string">'Manager Rejected' if is_first_approval else class="hl-string">'Finance Rejected'
                is_first_approval = False
            elif approval[class="hl-string">'status'] in [class="hl-string">'sent_back', class="hl-string">'pending_resubmit']:
                activity = class="hl-string">'Sent Back For Revision'

            if activity:
                event_log.append({
                    **base_event,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': approval[class="hl-string">'updated-at'],
                    class="hl-string">'UserName': approval.get(class="hl-string">'approver', {}).get(class="hl-string">'fullname'),
                    class="hl-string">'RejectionReason': rejection_reason
                })
        
        class=class="hl-string">"hl-comment"># 5. Infer payment and accounting events from status
        if report[class="hl-string">'status'] == class="hl-string">'processing_payment':
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Reimbursement Scheduled',
                class="hl-string">'EventTime': report[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Inferred from last update timestamp
                class="hl-string">'UserName': class="hl-string">'System'
            })
            
        if report[class="hl-string">'status'] == class="hl-string">'paid':
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Reimbursement Executed',
                class="hl-string">'EventTime': report[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Inferred from last update timestamp
                class="hl-string">'UserName': class="hl-string">'System'
            })

        class=class="hl-string">"hl-comment"># class="hl-string">'exported' flag indicates posting to an ERP system
        if report.get(class="hl-string">'exported') == True:
            event_log.append({
                **base_event,
                class="hl-string">'ActivityName': class="hl-string">'Accounting Posted',
                class="hl-string">'EventTime': report[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Inferred from last update timestamp
                class="hl-string">'UserName': class="hl-string">'System'
            })

    class=class="hl-string">"hl-comment"># 6. Create DataFrame and save to CSV
    if not event_log:
        print(class="hl-string">"No events were generated. Exiting.")
        return
        
    df = pd.DataFrame(event_log)
    class=class="hl-string">"hl-comment"># Reorder columns for clarity
    column_order = [
        class="hl-string">'ExpenseReportId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'EndTime', class="hl-string">'UserName',
        class="hl-string">'EmployeeDepartment', class="hl-string">'TotalAmount', class="hl-string">'ExpenseReportStatus',
        class="hl-string">'RejectionReason', class="hl-string">'PolicyViolationFlag', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate'
    ]
    df = df[column_order]
    df.sort_values(by=[class="hl-string">'ExpenseReportId', class="hl-string">'EventTime'], inplace=True)
    
    output_filename = class="hl-string">'coupa_expense_event_log.csv'
    df.to_csv(output_filename, index=False)
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

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

È pronto a iniziare?

Utilizzi questo template per avviare il Suo percorso di Process Mining e ottenere informazioni utili sulla gestione delle spese. Inizi oggi a ottimizzare le operazioni.

Torna alla guida al miglioramento

Scarica il template

Ottimizzi la gestione delle spese: elimini oggi i colli di bottiglia

Individui le inefficienze e riduca del 30% i tempi di ciclo delle spese grazie a informazioni chiare.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito. Inizi in pochi minuti.

Il Suo template di dati per la gestione delle spese

Il Suo template di dati per la gestione delle spese

Attributi della gestione delle spese

Attività di gestione delle spese

Guide all’estrazione

Esportazioni pianificate di Coupa tramite SFTP per i dati sulle spese

Passaggi

Configurazione

Query di esempio sql

Script Python che utilizza l’API REST di Coupa per le spese

Passaggi

Configurazione

Query di esempio python

È pronto a iniziare?

Ottimizzi la gestione delle spese: elimini oggi i colli di bottiglia