> Miglioramento Continuo dei Processi > Gestione delle Spese > Ramp > Template Dati

Il suo Template per i Dati di Gestione delle Spese

Ramp

`Attributi` di Gestione delle Spese (23) Attività di Gestione delle Spese (12) Guide all'Estrazione (3)

Il suo Template per i Dati di Gestione delle Spese

Questo template fornisce una chiara roadmap per la raccolta dei dati necessari per analizzare e ottimizzare il Suo processo di gestione delle spese. Descrive attributi essenziali, attività chiave da tracciare e linee guida pratiche per estrarre i Suoi dati da Ramp. Utilizzi questa risorsa per assicurarsi di raccogliere tutte le informazioni necessarie per una scoperta e un miglioramento del processo ricchi di insight.

Attributi consigliati da raccogliere
Attività chiave da tracciare
Guida all'estrazione per Ramp

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

Scarica Template

`Attributi` di Gestione delle Spese

Questi sono i campi dati essenziali da includere nel Suo event log per un'analisi completa del Suo processo di gestione delle spese.

3 Obbligatorio 6 Consigliato 14 Facoltativo

	Nome	Descrizione
	ID Nota Spese ExpenseReportId	L'identificatore unico per ogni nota spese, che funge da identificatore di case primario per il processo.
Descrizione L'ID della Nota Spese raggruppa tutti gli eventi e le attività relative a un singolo invio di spese. Consente un tracciamento completo e cronologico di una richiesta di rimborso dalla sua registrazione iniziale al pagamento finale. Nel process mining, questo attributo è essenziale per ricostruire il percorso end-to-end di ogni nota spese. Utilizzandolo come ID case, le analisi possono calcolare con precisione i tempi di ciclo, identificare i colli di bottiglia e visualizzare i diversi percorsi che i report seguono attraverso il processo di approvazione. Perché è importante Questo è l'attributo fondamentale che collega tutte le attività correlate in una singola istanza di processo, rendendo possibile l'analisi end-to-end. Dove trovare Questo identificatore dovrebbe essere disponibile nel report principale delle spese o nella tabella delle transazioni all'interno di Ramp. Esempi ER-2023-08-1123ER-2023-09-4591ER-2023-10-0024
	Nome attività ActivityName	Il nome dello specifico event o task che si è verificato in un determinato momento all'interno del processo di gestione delle spese.
Descrizione Questo attributo descrive un singolo passaggio nel ciclo di vita della nota spese, come 'Spesa Inviata', 'Approvato dal Manager' o 'Rimborso Eseguito'. Queste attività formano i nodi nella mappa del processo, consentendo la visualizzazione e l'analisi del flusso del processo. L'analisi delle attività aiuta a identificare quali passaggi sono più frequenti, dove si verificano i colli di bottiglia e come variano i diversi workflow. È un componente fondamentale per comprendere la sequenza delle operazioni e misurare le performance in ogni fase. Perché è importante Definisce i passaggi nella mappa di processo, consentendo la visualizzazione e l'analisi del flusso di processo dall'inizio alla fine. Dove trovare Questo è tipicamente derivato dagli event logs o dai record di modifica dello status associati a ogni nota spese in Ramp. Esempi Spesa InviataApprovato dal ManagerRevisione Finanziaria in CorsoRimborso Eseguito
	Timestamp Evento EventTimestamp	La data e l'ora esatte in cui si è verificata l'attività.
Descrizione Ogni attività nel processo ha un `timestamp` corrispondente che registra quando è avvenuta. Questo `dato` temporale viene utilizzato per ordinare gli `eventi` cronologicamente ed è la base per tutte le analisi temporali. Nel Process Mining, i `timestamp` vengono utilizzati per calcolare i tempi di ciclo tra le attività, misurare la durata totale di un `case` e identificare i ritardi. Questa informazione è fondamentale per il monitoraggio delle prestazioni e l'identificazione di opportunità di miglioramento del processo. Perché è importante Questo attributo fornisce l'ordine cronologico degli eventi ed è essenziale per tutti i calcoli di durata e l'analisi delle performance. Dove trovare Queste informazioni si trovano tipicamente insieme ai record di attività o status negli event logs o nei dati di transazione di Ramp. Esempi 2023-10-26T10:00:00Z2023-10-26T14:30:00Z2023-10-27T09:00:00Z
	Categoria di Spesa ExpenseCategory	La categoria assegnata a una spesa, come 'Viaggi', 'Software' o 'Pasti'.
Descrizione Questo attributo classifica le spese in categorie predefinite, il che aiuta a tracciare e controllare la spesa aziendale. Una singola nota spese può contenere voci di più categorie. L'analisi per categoria di spesa è essenziale per la dashboard 'Analisi Categoria Spesa'. Aiuta i team finanziari a capire dove vengono spesi i soldi, a monitorare l'aderenza al budget e a identificare tendenze o anomalie nella spesa nel tempo. Perché è importante Consente un'analisi dettagliata della spesa, contribuendo a identificare i principali fattori di costo e le opportunità di ottimizzazione del budget. Dove trovare Questo è tipicamente un dettaglio a livello di line-item sulla nota spese in Ramp. I dati potrebbero dover essere aggregati a livello di report per alcune analisi. Esempi Biglietto AereoPasti e IntrattenimentoAbbonamento SoftwareForniture per ufficio
	Dipartimento Dipendente EmployeeDepartment	Il reparto del dipendente che ha inviato la nota spese.
Descrizione Questo attributo indica l'unità aziendale o il reparto a cui appartiene il dipendente che presenta la spesa, come 'Vendite', 'Ingegneria' o 'Marketing'. Questa è una dimensione critica per l'analisi, poiché consente di filtrare e confrontare le prestazioni del processo tra le diverse parti dell'organizzazione. Può rivelare variazioni nei tempi di approvazione, nei tassi di revisione e nella conformità alle policy tra i reparti, supportando iniziative di miglioramento mirate. Perché è importante Consente il confronto delle metriche di processo tra diverse unità aziendali, evidenziando variazioni di efficienza, `conformità` e spesa. Dove trovare Queste informazioni sono probabilmente associate al profilo utente del dipendente in Ramp o a un sistema HR integrato. Esempi VenditeMarketingIngegneriaFinanza
	Importo Totale del Report ReportTotalAmount	Il valore monetario totale della nota spese.
Descrizione Questo attributo rappresenta la somma di tutte le spese incluse in un singolo report. È una metrica finanziaria chiave per comprendere i modelli di spesa. Nell'analisi dei processi, l'importo del report può essere utilizzato per segmentare i case e indagare se i report di alto valore seguono percorsi di approvazione diversi o richiedono più tempo per essere elaborati. È fondamentale per le dashboard di analisi della spesa e per identificare opportunità di risparmio sui costi. Perché è importante Fornisce una dimensione finanziaria cruciale per l'analisi, consentendo la segmentazione delle note spese per valore e il tracciamento della spesa complessiva. Dove trovare Questo è un campo primario sull'object del report spese in Ramp. Esempi 150.752500.0089.99
	Indicatore di Violazione della Policy PolicyViolationFlag	Un flag che indica se la nota spese è stata segnalata per una violazione della policy.
Descrizione Questo attributo booleano è impostato su true se i controlli automatizzati del sistema rilevano una potenziale violazione delle policy di spesa aziendali, come il superamento di un limite di spesa o l'invio di una spesa duplicata. Questo flag è critico per la dashboard 'Rilevamento Violazioni Policy' e il KPI associato. Aiuta a misurare l'efficacia dei controlli delle policy e a identificare le aree comuni di non conformità, che possono informare gli aggiornamenti delle policy o la formazione dei dipendenti. Perché è importante Misura direttamente la `conformità` alle policy, contribuendo a identificare e ridurre le spese non conformi e i rischi associati. Dove trovare Questo è probabilmente un flag generato dal sistema all'interno di Ramp, attivato da controlli automatizzati delle policy durante il processo di invio o approvazione. Esempi truefalse
	Motivo della Revisione RevisionReason	Il motivo fornito quando una nota spese viene rimandata al dipendente per revisione.
Descrizione Quando un approvatore rifiuta o rimanda indietro una nota spese, di solito fornisce un motivo. Questo attributo cattura tale motivo, come 'Ricevuta Mancante', 'Categoria Errata' o 'Fuori Policy'. Queste informazioni sono inestimabili per la dashboard 'Tasso e Cause di Revisione delle Spese'. Analizzando i motivi più comuni di rilavorazione, le organizzazioni possono identificare problemi sistemici nel processo di invio e implementare formazione mirata o miglioramenti al sistema per ridurre gli errori. Perché è importante Fornisce una visione diretta delle cause profonde delle rilavorazioni, consentendo azioni mirate per migliorare la qualità della prima presentazione. Dove trovare Questi dati verrebbero catturati nei commenti o nei dettagli di rifiuto quando l'attività 'Spesa Rinviata per Revisione' si verifica in Ramp. Esempi Ricevuta dettagliata mancanteSpesa supera il limite della policyCategoria di spesa errata selezionataTransazione duplicata
	Nome Utente UserName	Il nome o l'ID dell'utente che ha eseguito l'attività, inclusi il dipendente che invia la spesa o l'approvatore.
Descrizione Questo attributo identifica l'individuo responsabile di un particolare event nel processo, come l'invio, l'approvazione o la revisione di una nota spese. Questo può essere il nome di un dipendente o un ID utente unico. L'analisi per utente aiuta a comprendere la distribuzione del carico di lavoro, identificare i migliori performer e individuare gli individui che potrebbero richiedere formazione aggiuntiva. È fondamentale per le dashboard relative alle performance di approvazione e alla gestione delle risorse. Perché è importante Attribuisce le attività di processo a individui specifici, consentendo l'analisi delle prestazioni a livello di risorsa e l'identificazione delle esigenze di formazione. Dove trovare Le informazioni dell'utente sono tipicamente registrate nell'audit trail o nella cronologia delle transazioni per ogni nota spese in Ramp. Esempi Alice JohnsonBob SmithCharlie BrownAutomazione di sistema
	Approvatore Finanziario FinanceApprover	L'utente del team finanziario che ha approvato la nota spese.
Descrizione Per i `workflow` che includono una fase di revisione finanziaria, questo `attributo` identifica la persona o il `team` specifico all'interno del dipartimento finanziario che ha eseguito l'approvazione finale. Questo `attributo` supporta il `dashboard` 'Efficienza Revisione Finanziaria' consentendo l'analisi delle prestazioni a livello individuale o di `team`. Aiuta a identificare i `bottleneck`, a valutare la distribuzione del carico di lavoro e a misurare l'efficacia della fase di revisione finanziaria. Perché è importante Consente un'analisi dettagliata delle prestazioni della fase di revisione finanziaria, contribuendo a ottimizzare un punto di controllo critico nel processo. Dove trovare Questo verrebbe catturato nella cronologia di approvazione della nota spese in Ramp durante la fase di revisione finanziaria. Esempi Team Finanza ADavid Lee`Bot` di Automazione Finanziaria
	Conteggio Passaggi di Approvazione ApprovalStepCount	Il numero totale di passaggi di approvazione formali che una nota spese ha attraversato.
Descrizione Questa metrica calcolata conta il numero di attività di approvazione distinte, come 'Approvato dal Manager' e 'Approvato dalla Finanza', che si sono verificate per una singola nota spese. Aiuta a quantificare la complessità del workflow di approvazione. Questo attributo è utilizzato per il KPI 'Passaggi di Approvazione Medi per Report' e la dashboard 'Percorsi Semplici di Approvazione Spese'. Analizzando questo conteggio, specialmente in relazione al valore o alla categoria del report, le organizzazioni possono identificare se le spese semplici e di basso valore sono soggette a processi di approvazione eccessivamente complessi. Perché è importante Quantifica la complessità del `workflow`, aiutando a identificare opportunità di semplificazione, specialmente per le note spese a basso rischio. Dove trovare Questo viene calcolato contando le occorrenze di attività specifiche legate all'approvazione all'interno di ogni case nell'event log. Esempi 123
	È una Rilavorazione IsRework	Un flag calcolato che indica se una nota spese è stata rimandata per revisione almeno una volta.
Descrizione Questo attributo booleano è derivato controllando se l'attività 'Spesa Rinviata per Revisione' si è verificata per un dato case. È impostato su true per qualsiasi report che abbia subito almeno un ciclo di revisione. Questo flag semplifica il calcolo del KPI 'Tasso di Revisione Note Spese' e consente un facile filtraggio e confronto tra i report approvati al primo passaggio e quelli che hanno richiesto rilavorazione. L'analisi di queste due coorti può rivelare l'impatto in termini di tempo e costi delle revisioni. Perché è importante Segmenta facilmente il processo per l'analisi delle rilavorazioni, aiutando a quantificare la frequenza e l'impatto delle note spese rimandate per correzione. Dove trovare Questo è un campo calcolato, derivato durante la trasformazione dei dati controllando l'esistenza di un'attività di revisione all'interno del case. Esempi truefalse
	Esito dell'`Audit` AuditOutcome	Il risultato di un audit interno o esterno della nota spese.
Descrizione Per le note spese che subiscono un `audit` formale, questo `attributo` registra l'esito finale, come 'Approvato', 'Parzialmente Negato' o 'Ulteriori Informazioni Richieste'. Questi `dati` sono centrali per il `dashboard` 'Prestazioni `Audit` Spese'. Aiuta a valutare l'efficacia del processo di `audit`, a tracciare la frequenza dei diversi esiti e a comprendere l'impatto finanziario dei risultati dell'`audit`. Perché è importante Misura l'efficacia e i risultati del processo di `audit`, fornendo intuizioni sulla `conformità` e sulle debolezze dei controlli. Dove trovare Questo verrebbe registrato nel modulo di audit di Ramp o in un sistema integrato se utilizzato per l'audit dettagliato delle spese. Esempi ApprovatoApprovato con OsservazioniRifiutatoScalato
	Manager Approvatore ApprovingManager	Il nome del manager che ha eseguito il passaggio di approvazione.
Descrizione Questo attributo identifica il manager responsabile della revisione e dell'approvazione della nota spese di un dipendente. È distinto dall'utente che ha inviato il report. Tracciare il manager che approva è essenziale per la dashboard 'Tempo di Ciclo di Approvazione del Manager'. Consente l'analisi dei carichi di lavoro e delle performance di approvazione, evidenziando i manager che approvano rapidamente rispetto a quelli che sono colli di bottiglia. Questo può aiutare a bilanciare i carichi di lavoro o a fornire supporto aggiuntivo. Perché è importante Consente l'analisi delle prestazioni dei singoli approvatori, aiutando a identificare e affrontare i `bottleneck` nel `workflow` di approvazione. Dove trovare Queste informazioni fanno parte dei dati del workflow di approvazione in Ramp, registrati quando un manager intraprende un'azione su un report. Esempi Jane DoeJohn MillerSusan Chen
	Metodo di Invio SubmissionMethod	Il canale attraverso il quale è stata inviata la nota spese, come app mobile o web portal.
Descrizione Questo attributo indica come il dipendente ha inviato la propria nota spese. I metodi comuni includono l'utilizzo di un'applicazione mobile, un browser web desktop o l'inoltro via email. L'analisi del metodo di invio può fornire insight sul comportamento degli utenti e sull'adozione della tecnologia. Ad esempio, un'elevata frequenza di revisioni per i report inviati tramite un certo canale potrebbe indicare problemi di usabilità con l'interfaccia di quel canale. Perché è importante Fornisce contesto sul comportamento degli utenti e può aiutare a identificare se determinati canali di invio sono associati a tassi di errore o ritardi più elevati. Dove trovare Queste informazioni possono essere catturate nei metadata dell'event di invio nei system logs di Ramp. Esempi App MobilePortale WebEmail
	Metodo di Rimborso ReimbursementMethod	Il metodo utilizzato per eseguire il pagamento del rimborso, come ACH o bonifico bancario.
Descrizione Questo attributo specifica il canale di pagamento attraverso il quale il dipendente è stato rimborsato. Metodi diversi possono avere tempi di elaborazione e costi associati diversi. L'analisi delle performance di rimborso per metodo aiuta a identificare i canali di pagamento più efficienti. La dashboard 'Performance Metodo di Rimborso' utilizza questi dati per confrontare i tempi di ciclo e l'affidabilità, portando potenzialmente all'ottimizzazione delle strategie di pagamento. Perché è importante Consente il confronto delle prestazioni tra diversi canali di pagamento, contribuendo a ottimizzare la velocità e l'affidabilità. Dove trovare Queste informazioni dovrebbero essere disponibili nei registri di pagamento o rimborso all'interno di Ramp. Esempi Trasferimento ACHCredito Carta AziendaleDeposito Diretto
	Ora Fine Evento EventEndTime	Il timestamp che indica quando un'attività con una durata si è conclusa.
Descrizione Mentre molte attività sono istantanee, alcune, come 'Controllo Policy Eseguito', potrebbero avere una durata misurabile. Questo attributo cattura l'ora di fine di tali attività, completando l'StartTime. Avere sia un'ora di inizio che un'ora di fine consente il calcolo preciso dei tempi di elaborazione delle attività. Questo è essenziale per KPI come 'Durata Media Controllo Policy' e per identificare esattamente quanto tempo impiegano specifiche task automatizzate o manuali per essere completate all'interno del processo complessivo. Perché è importante Consente il calcolo preciso delle durate delle singole attività, il che è cruciale per identificare le fasi di processo inefficienti. Dove trovare Per le attività con una durata, questo verrebbe registrato nei `dati` di `evento` di Ramp. Per gli `eventi` istantanei, può essere lo stesso del `StartTime`. Esempi 2023-10-26T10:00:05Z2023-10-26T14:35:10Z2023-10-27T09:10:00Z
	Sistema di Origine SourceSystem	Identifica l'applicazione sorgente da cui sono stati estratti i `dati`.
Descrizione Questo attributo specifica il sistema di registrazione per i dati del processo, che in questo case è Ramp. È utile in ambienti in cui i dati potrebbero essere combinati da più sistemi, garantendo una chiara data lineage. Per l'analisi, aiuta a filtrare i dati da una fonte specifica e può essere utilizzato per scopi di convalida e governance dei dati. Perché è importante Fornisce contesto sull'origine dei `dati`, il che è cruciale per la `data governance` e quando si integrano `dati` da più sistemi. Dove trovare Questo è tipicamente un valore statico ('Ramp') aggiunto durante il processo di estrazione e trasformazione dei dati. Esempi Ramp
	Tempo di Approvazione Manager ManagerApprovalTime	Il tempo impiegato da quando un report è in attesa di revisione del manager a quando il manager lo approva o lo rifiuta.
Descrizione Questa metrica calcola la durata della fase di approvazione del manager. È la differenza di tempo tra l'attività 'Revisione Manager in Sospeso' e l'attività successiva 'Approvato dal Manager' o 'Rifiutato dal Manager'. Questa durata è utilizzata per calcolare il KPI 'Tempo Medio di Approvazione del Manager' e alimentare la dashboard 'Tempo di Ciclo di Approvazione del Manager'. Aiuta a individuare i ritardi nel primo livello di approvazione, che è spesso un significativo collo di bottiglia. Perché è importante Isola la durata di una fase di approvazione critica, aiutando a identificare e affrontare i `bottleneck` causati dalle revisioni dei manager. Dove trovare Questo viene calcolato dall'event log trovando la differenza di tempo tra gli eventi di revisione del manager in sospeso e di completamento. Esempi 1 ora 15 minuti2 giorni 3 ore5 ore 30 minuti
	Tempo di Contabilizzazione AccountingPostingTime	Il tempo da quando un rimborso viene eseguito fino a quando la transazione viene registrata nel sistema contabile.
Descrizione Questa metrica calcolata misura il ritardo nella tenuta dei registri finanziari. È la differenza di tempo tra l'event 'Rimborso Eseguito' e l'event 'Sincronizzato con il Sistema Contabile'. Questo attributo è utilizzato per il KPI 'Tempo Medio di Registrazione Contabile' e la dashboard 'Ritardi di Registrazione Contabile'. Aiuta a garantire che i registri finanziari siano aggiornati tempestivamente, il che è importante per una reportistica finanziaria accurata e puntuale. Perché è importante Evidenzia i ritardi nella tenuta dei registri finanziari, consentendo azioni per accelerare il processo di chiusura contabile. Dove trovare Questo viene calcolato dai timestamp degli eventi nel data log per gli eventi di rimborso e sincronizzazione contabile. Esempi 2 ore1 giorno5 minuti
	Tempo di Revisione Finanziaria FinanceReviewTime	Il tempo che una nota spese trascorre nella fase di revisione finanziaria.
Descrizione Questa metrica misura la durata da quando un report entra nella coda finanziaria ('Revisione Finanziaria in Sospeso') fino a quando un approvatore finanziario intraprende un'azione ('Approvato dalla Finanza' o 'Rifiutato dalla Finanza'). È la misura primaria per il KPI 'Tempo Medio di Revisione Finanziaria' e la dashboard 'Efficienza della Revisione Finanziaria'. L'analisi di questa durata aiuta a identificare opportunità per snellire o automatizzare il processo di revisione finanziaria, riducendo lo sforzo manuale e accelerando il ciclo complessivo. Perché è importante Misura l'efficienza del processo di revisione del dipartimento finanziario, evidenziando opportunità di automazione e razionalizzazione. Dove trovare Questo valore viene calcolato dai timestamp degli eventi per l'inizio e la fine delle attività di revisione finanziaria. Esempi 4 ore1 giorno 2 ore18 ore
	Tempo Totale del Ciclo di Rimborso TotalReimbursementCycleTime	Il tempo totale trascorso da quando una nota spese è stata inviata a quando il rimborso è stato eseguito.
Descrizione Questa metrica calcolata misura la durata end-to-end del processo di rimborso dal punto di vista del dipendente. Viene calcolata come la differenza di tempo tra gli eventi 'Spesa Inviata' e 'Rimborso Eseguito' per ogni case. Questo attributo è la base per il KPI 'Tempo Medio di Ciclo di Rimborso' e la dashboard 'Ciclo di Rimborso End-to-End'. Fornisce una misura di alto livello dell'efficienza del processo ed è un indicatore chiave della soddisfazione dei dipendenti. Perché è importante Quantifica la durata complessiva del processo, fornendo un `KPI` chiave per misurare l'efficienza `end-to-end`. Dove trovare Questo viene calcolato durante la trasformazione dei dati sottraendo il timestamp del primo event di invio dall'event finale di rimborso. Esempi 3 giorni e 4 ore10 giorni 1 ora1 giorno 8 ore
	Ultimo `Data Update` LastDataUpdate	Il timestamp che indica l'ultima volta in cui i dati sono stati aggiornati dal sistema sorgente.
Descrizione Questo attributo registra la data e l'ora dell'estrazione dei dati più recente. Fornisce contesto sulla freschezza dei dati analizzati. In qualsiasi analisi, conoscere la recenza dei dati è cruciale per interpretare correttamente i risultati. Questo attributo aiuta gli utenti a capire se stanno visualizzando informazioni aggiornate. Perché è importante Informa gli utenti sulla tempestività dei `dati`, garantendo che le analisi siano basate su informazioni attuali e pertinenti. Dove trovare Questo timestamp viene generato e aggiunto durante il processo di estrazione dei dati. Esempi 2023-11-01T06:00:00Z

Obbligatorio Consigliato Facoltativo

Attività di Gestione delle Spese

Queste sono le fasi di processo chiave e le tappe fondamentali da acquisire nel tuo `event log` per un'accurata `process discovery` e misurazione delle prestazioni.

5 Consigliato 7 Facoltativo

	Activity	Descrizione
	Approvato dal Manager	Il manager ha revisionato la spesa e l'ha approvata, consentendone il passaggio al passo successivo, come la revisione finanziaria o il rimborso. Questo viene catturato tramite un'azione utente esplicita.
Perché è importante Questa è una milestone chiave che indica il completamento con successo del primo livello di approvazione. È cruciale per analizzare i workflow di approvazione e identificare i colli di bottiglia. Dove trovare Registrato come un event nella cronologia di approvazione della spesa quando il manager clicca 'Approvato'. L'event log dovrebbe contenere l'ID dell'approvatore e un timestamp. Acquisisci Un `evento` viene registrato all'azione di 'Approvazione' da parte di un utente con permessi di manager. Tipo di evento explicit
	Rimborso Eseguito	Il pagamento del rimborso è stato elaborato con successo e inviato al dipendente. Questo è tipicamente il passaggio finale per il dipendente e segna la fine del ciclo di pagamento.
Perché è importante Questo è l'event finale primario per il processo di rimborso. La durata dall'invio a questo punto è un KPI critico per la soddisfazione dei dipendenti e l'efficienza del processo. Dove trovare Catturato dai `log` di elaborazione dei pagamenti o da un'integrazione con il fornitore di pagamenti. Lo stato della spesa in Ramp verrebbe aggiornato a 'Rimborsato' o 'Pagato'. Acquisisci Un `evento` viene registrato quando il sistema di pagamento conferma il trasferimento di pagamento riuscito. Tipo di evento explicit
	Sincronizzato con il Sistema Contabile	I dati della transazione di spesa sono stati registrati con successo nel sistema contabile integrato, come NetSuite, QuickBooks o Xero. Questo event segna il completamento della parte di registrazione finanziaria del processo.
Perché è importante Questa è l'attività finale nel processo end-to-end. I ritardi qui possono influire sull'accuratezza della reportistica finanziaria e sulla velocità della chiusura finanziaria. Dove trovare Registrato in un log di integrazione o come aggiornamento di status sull'object di spesa in Ramp. Cerchi uno status come 'Synced', 'Posted' o 'Exported'. Acquisisci Una voce di `log` viene creata dal servizio di integrazione contabile al completamento della sincronizzazione dei `dati`. Tipo di evento explicit
	Spesa Inviata	Un dipendente conferma che tutte le informazioni necessarie per una spesa sono complete e la invia per il processo di approvazione. Questa è un'azione utente esplicita che sposta la spesa da uno stato di 'bozza' o 'richiede attenzione' a uno stato di 'approvazione in sospeso'.
Perché è importante Questa attività è una milestone critica che avvia ufficialmente il ciclo di approvazione e rimborso. È la base per misurare gli SLA di approvazione e rimborso. Dove trovare Catturato dalla cronologia dello stato dell'oggetto spesa. Ciò corrisponde all'azione dell'utente di inviare la transazione per la revisione. Acquisisci Registrato quando l'utente clicca il pulsante 'Invia', attivando un cambiamento di stato. Tipo di evento explicit
	Spesa Sostenuta	Segna la creazione di una spesa, tipicamente avviata automaticamente quando viene usata una carta aziendale o quando un dipendente crea manualmente una registrazione di spesa anticipata. Questo evento viene solitamente acquisito da feed di dati di transazione o azioni dell'interfaccia utente.
Perché è importante Questo è l'event di inizio primario per il ciclo di vita della spesa. L'analisi del tempo da questo event aiuta a comprendere i ritardi di invio e la velocità complessiva del processo. Dove trovare Generato dai `log` delle transazioni con carta Ramp o dal `timestamp` di creazione di un oggetto spesa inserito manualmente. Cerchi l'`evento` di creazione del record iniziale nella tabella delle spese o delle transazioni. Acquisisci Registrato direttamente quando una transazione con carta viene elaborata o un utente crea una nuova voce di spesa. Tipo di evento explicit
	Approvato dalla Finanza	Il team finanziario ha esaminato e dato l'approvazione finale per la spesa, autorizzandola al rimborso e alla sincronizzazione contabile. Questo viene catturato come un'azione utente esplicita da un membro del team finanziario.
Perché è importante Rappresenta l'ultimo gate di approvazione prima del pagamento. L'analisi di questa attività aiuta a comprendere il ciclo di approvazione end-to-end e l'efficienza del team finanziario. Dove trovare Registrato come event nella cronologia di approvazione della spesa. Cercare un event di approvazione associato a un utente dell'ufficio finanziario. Acquisisci Un `evento` viene registrato all'azione di 'Approvazione' da parte di un utente con permessi finanziari. Tipo di evento explicit
	Controllo Policy Eseguito	Il sistema esegue automaticamente l'audit della spesa rispetto alle policy aziendali configurate, segnalando eventuali violazioni. Questo è tipicamente un event generato dal sistema che si verifica poco dopo l'invio.
Perché è importante Misura l'efficienza dei controlli di conformità automatizzati e il loro impatto sul processo. Aiuta a identificare le violazioni comuni delle policy e le aree per la formazione dei dipendenti. Dove trovare Probabilmente registrato in una traccia di `audit` o `log` associato alla transazione di spesa. Cerchi `eventi` di sistema relativi a 'policy_check' o 'compliance_scan'. Acquisisci Una voce di `log` di sistema viene creata dopo che il motore automatico delle policy viene eseguito sulla transazione. Tipo di evento explicit
	Revisione Finanziaria in Corso	Una spesa approvata è stata inoltrata e ora è in attesa di revisione da parte del `team` finanziario o contabile. Ciò accade tipicamente per spese di alto valore o quelle con `flag` di policy. L'attività è inferita da un cambiamento di stato.
Perché è importante Segna l'inizio del ciclo di revisione finanziaria. Misurare la durata di questa fase aiuta a valutare il carico di lavoro e l'efficienza del team finanziario, e identifica opportunità di automazione. Dove trovare Inferred from a status change on the expense object to 'Pending Finance Approval' after manager approval. Ciò richiede l'accesso alla cronologia dello stato della spesa. Acquisisci Derivato dal `timestamp` quando lo stato della spesa si aggiorna a 'In Attesa di Revisione Finanziaria'. Tipo di evento inferred
	Revisione Manager in Corso	La spesa è stata inviata ed è ora in attesa di revisione da parte del manager diretto del dipendente. Questo stato viene inferito quando lo status della spesa cambia in 'In Attesa di Approvazione del Manager' o un valore simile dopo l'invio.
Perché è importante Identifica l'inizio della fase di approvazione del manager. L'analisi del tempo trascorso in questo stato è fondamentale per misurare e migliorare i tempi di ciclo di approvazione del manager. Dove trovare Inferred from a status change on the expense object to a state like 'Pending Approval' and assignment to a manager's queue. Richiede il tracciamento della cronologia dello stato. Acquisisci Derivato dal `timestamp` quando lo stato della spesa diventa 'In Attesa di Approvazione Manager'. Tipo di evento inferred
	Ricevuta Allegata	Rappresenta il momento in cui una ricevuta viene associata a una spesa, sia automaticamente tramite matching OCR che manualmente dall'utente. Questo viene acquisito quando il file della ricevuta è collegato con successo al record di transazione.
Perché è importante Il tracciamento di questa attività aiuta a identificare i ritardi causati dalla documentazione mancante. È un passaggio chiave per garantire la conformità e la preparazione all'audit. Dove trovare Registrato nella cronologia delle spese o delle transazioni quando una ricevuta viene caricata o abbinata. Verifichi la presenza di un `evento` di creazione allegato o di un `flag` che indica 'receipt_attached'. Acquisisci L'`evento` viene creato quando il sistema collega un'immagine o un file di ricevuta al record della spesa. Tipo di evento explicit
	Rimborso Programmato	Per le spese `out-of-pocket`, l'importo approvato è stato messo in coda per l'elaborazione del pagamento. Questo `evento` indica che la spesa ha superato tutte le approvazioni ed è pronta per essere erogata.
Perché è importante Questa milestone separa il processo di approvazione dal processo di esecuzione del pagamento. Aiuta a isolare i ritardi che si verificano nell'elaborazione dei pagamenti rispetto a quelli nelle approvazioni. Dove trovare Probabilmente inferito dal cambiamento di stato della spesa a 'Rimborso in Sospeso' o 'Pronto per il Pagamento' dopo l'approvazione finale. Potrebbe anche essere un `evento` esplicito se i pagamenti sono in `batch`. Acquisisci Derivato da un cambiamento di stato a 'Pronto per il Pagamento' o dalla creazione di un record in una tabella di `batch` di pagamento. Tipo di evento inferred
	Spesa Rimandata per Revisione	Un approvatore, sia esso un manager o un revisore finanziario, ha rifiutato la spesa e l'ha rimandata al dipendente per la correzione. Questo è catturato da un cambiamento di stato a 'Richiede Revisione' o 'Rifiutato'.
Perché è importante Questa attività indica un loop di rilavorazione nel processo, che aumenta direttamente il tempo di ciclo. Il tracciamento di questi eventi aiuta a identificare errori comuni di invio e a migliorare il tasso di successo al primo passaggio. Dove trovare Inferred from a status change on the expense object to 'Needs Revision' or a similar state. L'`evento` dovrebbe essere collegato all'approvatore che ha avviato l'azione. Acquisisci Derivato dal `timestamp` quando lo stato della spesa diventa 'Richiede Revisione' o 'Rifiutato'. Tipo di evento inferred

Consigliato Facoltativo

Guide all'Estrazione

Come ottenere i Suoi `dati` da Ramp

Fasi

Acceda al Suo account Ramp con privilegi di Amministratore o Contabile.
Navighi alla sezione Transazioni dal menu a sinistra. Questa visualizzazione contiene tutte le spese con carta aziendale.
Applichi i filtri desiderati ai dati. Al minimo, imposti un Intervallo di Date per il periodo che desidera analizzare. Può anche filtrare per altre proprietà come Stato, Categoria o Dipartimento per restringere l'ambito, se necessario.
Clicchi sul pulsante Esporta situato in alto a destra nell'elenco delle transazioni.
Nel modale di esportazione, selezioni Transazioni come tipo di esportazione e CSV come formato. Scarichi il file e lo nomini transactions_export.csv.
Successivamente, navighi alla sezione Rimborsi dal menu a sinistra. Questa visualizzazione contiene tutte le spese out-of-pocket presentate dai dipendenti.
Applichi lo stesso filtro per l'intervallo di date utilizzato per l'esportazione delle transazioni per garantire la coerenza dei dati.
Clicchi sul pulsante Esporta e scarichi i dati dei rimborsi come file CSV. Lo nomini reimbursements_export.csv.
Posizioni entrambi i file CSV esportati (transactions_export.csv e reimbursements_export.csv) nella stessa directory dello script Python fornito.
Esegua lo script Python. Lo script caricherà entrambi i file, trasformerà i dati creando una riga distinta per ogni evento aziendale e li unirà in un singolo event log strutturato.
Lo script produrrà un file denominato ramp_event_log.csv. Questo file è formattato secondo i requisiti di ProcessMind.
Carichi il file ramp_event_log.csv su ProcessMind per l'analisi.

Configurazione

Autorizzazioni: Deve possedere ruoli 'Admin' o 'Bookkeeper' in Ramp per accedere ed esportare i set di dati completi di transazioni e rimborsi.
Intervallo di Date: Per un'analisi iniziale, selezioni un intervallo di date di almeno 6-12 mesi per catturare sufficienti variazioni di processo. Per il monitoraggio continuo, può usare un intervallo più breve e più recente.
Coerenza dei dati: Si assicuri di usare lo stesso intervallo di date e gli stessi filtri quando esporta sia i file delle Transazioni che quelli dei Rimborsi per mantenere un dataset coerente.
Formato di Esportazione: Scelga sempre il formato CSV per entrambe le esportazioni, poiché lo script di trasformazione è progettato per elaborare file separati da virgole.
Nomi dei File: Si attenga ai nomi dei file transactions_export.csv e reimbursements_export.csv o aggiorni di conseguenza le variabili del percorso dei file nello script di trasformazione.

a Query di Esempio config

import pandas as pd
import numpy as np

# --- Configuration ---
TRANSACTIONS_FILE = 'transactions_export.csv'
REIMBURSEMENTS_FILE = 'reimbursements_export.csv'
OUTPUT_FILE = 'ramp_event_log.csv'

# --- Load Data ---
def load_data():
    try:
        transactions_df = pd.read_csv(TRANSACTIONS_FILE)
        reimbursements_df = pd.read_csv(REIMBURSEMENTS_FILE)
        print("Successfully loaded transactions and reimbursements files.")
        return transactions_df, reimbursements_df
    except FileNotFoundError as e:
        print(f"Error: {e}. Make sure '{TRANSACTIONS_FILE}' and '{REIMBURSEMENTS_FILE}' are in the same directory.")
        return None, None

# --- Main Transformation Logic ---
def transform_to_event_log(transactions_df, reimbursements_df):
    events = []

    # Standardize column names for easier processing
    # These names are based on typical Ramp CSV exports, adjust if your export has different headers
    transactions_df.rename(columns={
        'Transaction ID': 'ExpenseReportId',
        'User Name': 'UserName',
        'Department': 'EmployeeDepartment',
        'Amount': 'ReportTotalAmount',
        'Category Name': 'ExpenseCategory',
        'Transaction Date': 'ExpenseIncurredTimestamp',
        'Receipts Attached At': 'ReceiptAttachedTimestamp',
        'Submitted At': 'ExpenseSubmittedTimestamp',
        'Manager Approved At': 'ManagerApprovedTimestamp',
        'Needs Review At': 'FinanceReviewPendingTimestamp',
        'Admin Approved At': 'FinanceApprovedTimestamp',
        'Accounting Sync At': 'SyncedTimestamp',
        'Memo': 'RevisionReason',
        'State': 'Status'
    }, inplace=True)

    reimbursements_df.rename(columns={
        'Reimbursement ID': 'ExpenseReportId',
        'User Name': 'UserName',
        'Department': 'EmployeeDepartment',
        'Amount': 'ReportTotalAmount',
        'Category Name': 'ExpenseCategory',
        'Created At': 'ReimbursementScheduledTimestamp',
        'Paid Out At': 'ReimbursementExecutedTimestamp',
        'Memo': 'RevisionReason',
        'State': 'Status'
    }, inplace=True)

    # Combine card transactions and reimbursements into a single dataframe for processing common events
    # Note: Reimbursements will be processed separately for reimbursement-specific events
    combined_df = transactions_df

    # Process activities from the combined dataframe
    for _, row in combined_df.iterrows():
        base_event = {
            'ExpenseReportId': row.get('ExpenseReportId'),
            'UserName': row.get('UserName'),
            'EmployeeDepartment': row.get('EmployeeDepartment'),
            'ReportTotalAmount': row.get('ReportTotalAmount'),
            'ExpenseCategory': row.get('ExpenseCategory'),
            'PolicyViolationFlag': 'FLAGGED' in str(row.get('Flags')), # Infer from 'Flags' column
            'RevisionReason': row.get('RevisionReason')
        }

        # Activity: Expense Incurred
        if pd.notna(row.get('ExpenseIncurredTimestamp')):
            events.append({**base_event, 'ActivityName': 'Expense Incurred', 'EventTimestamp': row.get('ExpenseIncurredTimestamp')})

        # Activity: Receipt Attached
        if pd.notna(row.get('ReceiptAttachedTimestamp')):
            events.append({**base_event, 'ActivityName': 'Receipt Attached', 'EventTimestamp': row.get('ReceiptAttachedTimestamp')})

        # Activity: Expense Submitted
        if pd.notna(row.get('ExpenseSubmittedTimestamp')):
            events.append({**base_event, 'ActivityName': 'Expense Submitted', 'EventTimestamp': row.get('ExpenseSubmittedTimestamp')})
            # Inferred Activity: Policy Check Performed (assumed to happen right after submission)
            policy_check_ts = pd.to_datetime(row.get('ExpenseSubmittedTimestamp')) + pd.Timedelta(seconds=1)
            events.append({**base_event, 'ActivityName': 'Policy Check Performed', 'EventTimestamp': policy_check_ts.isoformat()})
            # Inferred Activity: Manager Review Pending (starts when submitted)
            events.append({**base_event, 'ActivityName': 'Manager Review Pending', 'EventTimestamp': row.get('ExpenseSubmittedTimestamp')})

        # Activity: Manager Approved
        if pd.notna(row.get('ManagerApprovedTimestamp')):
            events.append({**base_event, 'ActivityName': 'Manager Approved', 'EventTimestamp': row.get('ManagerApprovedTimestamp')})

        # Activity: Finance Review Pending
        if pd.notna(row.get('FinanceReviewPendingTimestamp')):
            events.append({**base_event, 'ActivityName': 'Finance Review Pending', 'EventTimestamp': row.get('FinanceReviewPendingTimestamp')})

        # Activity: Finance Approved
        if pd.notna(row.get('FinanceApprovedTimestamp')):
            events.append({**base_event, 'ActivityName': 'Finance Approved', 'EventTimestamp': row.get('FinanceApprovedTimestamp')})

        # Activity: Synced with Accounting System
        if pd.notna(row.get('SyncedTimestamp')):
            events.append({**base_event, 'ActivityName': 'Synced with Accounting System', 'EventTimestamp': row.get('SyncedTimestamp')})

        # Activity: Expense Sent Back for Revision
        if row.get('Status') == 'REJECTED' and pd.notna(row.get('Updated At')):
             events.append({**base_event, 'ActivityName': 'Expense Sent Back for Revision', 'EventTimestamp': row.get('Updated At')}) # Using last updated time for rejection

    # Process reimbursement-specific activities
    for _, row in reimbursements_df.iterrows():
        base_event = {
            'ExpenseReportId': row.get('ExpenseReportId'),
            'UserName': row.get('UserName'),
            'EmployeeDepartment': row.get('EmployeeDepartment'),
            'ReportTotalAmount': row.get('ReportTotalAmount'),
            'ExpenseCategory': row.get('ExpenseCategory'),
            'PolicyViolationFlag': False, # Typically less flagging on reimbursements
            'RevisionReason': row.get('RevisionReason')
        }

        # Activity: Reimbursement Scheduled
        if row.get('Status') == 'APPROVED' and pd.notna(row.get('ReimbursementScheduledTimestamp')):
            events.append({**base_event, 'ActivityName': 'Reimbursement Scheduled', 'EventTimestamp': row.get('ReimbursementScheduledTimestamp')})

        # Activity: Reimbursement Executed
        if row.get('Status') == 'PAID' and pd.notna(row.get('ReimbursementExecutedTimestamp')):
            events.append({**base_event, 'ActivityName': 'Reimbursement Executed', 'EventTimestamp': row.get('ReimbursementExecutedTimestamp')})

    if not events:
        print("Warning: No events were generated. Check the input files and column names.")
        return None

    # Create final DataFrame
    event_log_df = pd.DataFrame(events)
    event_log_df['EventTimestamp'] = pd.to_datetime(event_log_df['EventTimestamp'])
    event_log_df.sort_values(by=['ExpenseReportId', 'EventTimestamp'], inplace=True)
    
    return event_log_df

# --- Main execution block ---
if __name__ == "__main__":
    transactions_df, reimbursements_df = load_data()
    if transactions_df is not None and reimbursements_df is not None:
        event_log = transform_to_event_log(transactions_df, reimbursements_df)
        if event_log is not None:
            event_log.to_csv(OUTPUT_FILE, index=False, date_format='%Y-%m-%dT%H:%M:%S.%fZ')
            print(f"Successfully created event log with {len(event_log)} events. Saved to '{OUTPUT_FILE}'.")

Fasi

Prerequisiti e Configurazione dell'Ambiente: Si assicuri di avere Python 3.8 o versioni successive installate. Installi le librerie Python necessarie eseguendo pip install requests pandas. Deve anche avere accesso come amministratore alla Sua istanza Ramp per generare le credenziali API.
Generare le Credenziali API di Ramp: Acceda al Suo account Ramp. Navighi su Impostazioni, quindi selezioni API Sviluppatore dal menu laterale. Clicchi su 'Crea App', dia un nome alla Sua applicazione e configuri gli ambiti richiesti. Avrà bisogno di transactions:read, reimbursements:read e users:read. Una volta creata, copi in modo sicuro il Client ID e il Client Secret.
Configurare lo Script Python: Crei un nuovo file Python, ad esempio extract_ramp_log.py. Copi lo script Python fornito in questo file. Imposti il Suo Client ID e Client Secret come variabili d'ambiente o direttamente nello script per scopi di test. Si raccomanda vivamente di utilizzare variabili d'ambiente per motivi di sicurezza.
Impostare l'Intervallo di Date di Estrazione: Nello script, individui le variabili START_DATE e END_DATE all'interno del blocco di esecuzione main. Regoli queste date per definire la finestra temporale per l'estrazione dei dati. Si raccomanda un periodo di 3-6 mesi per un'analisi iniziale.
Eseguire lo Script: Esegua lo script dal Suo terminale utilizzando il comando python extract_ramp_log.py. Lo script si autenticherà con l'API di Ramp, recupererà i dati dagli endpoint di utenti, transazioni e rimborsi e gestirà automaticamente la paginazione.
Comprendere le Chiamate API: Lo script recupera prima tutti i dati utente per creare una mappatura degli ID utente a nomi e dipartimenti. Quindi recupera tutti i rimborsi all'interno dell'intervallo di date specificato. Per ogni rimborso, estrae la cronologia di approvazione e pagamento.
Trasformare i dati in un Event Log: La logica principale dello script itera attraverso ogni rimborso e la sua cronologia di stato associata. Traduce ogni cambiamento di stato, come 'MANAGER_APPROVAL' o 'FINISHED', in un'attività distinta come 'Revisione Manager in Corso' o 'Rimborso Eseguito'. Recupera anche i dati di transazione associati per creare eventi 'Spesa Sostenuta' e 'Ricevuta Allegata'.
Gestione dell'Arricchimento dei Dati: Lo script arricchisce l'Event Log aggiungendo dettagli utente, informazioni sul dipartimento e categoria di spesa per ogni evento, creando un dataset completo per l'analisi dei processi.
Rivedere l'Output: Una volta completato lo script, genererà un file denominato ramp_event_log.csv nella stessa directory. Apra questo file CSV in un programma di fogli di calcolo per ispezionare i dati e assicurarsi che siano stati estratti come previsto.
Preparare per il Caricamento: Il file CSV generato è strutturato con le colonne richieste: ExpenseReportId, ActivityName, EventTimestamp e altri attributi raccomandati. Questo file è pronto per il caricamento diretto nella piattaforma ProcessMind.

Configurazione

Credenziali API: Sono necessari un Client ID e un Client Secret validi per l'autenticazione. Questi vengono generati all'interno della dashboard di Ramp in Impostazioni > API Sviluppatore.
Scope API: Lo script richiede autorizzazioni specifiche per accedere ai dati. Si assicuri che i seguenti ambiti siano abilitati per la Sua chiave API: transactions:read (per dettagli spese e ricevute), reimbursements:read (per stato di invio, approvazione e pagamento) e users:read (per nome dipendente e dipartimento).
Intervallo di Date: L'estrazione è regolata dai parametri START_DATE e END_DATE nello script. Si raccomanda di iniziare con un periodo recente, come gli ultimi 3-6 mesi, per mantenere il dataset iniziale gestibile. Il filtro viene applicato alla data di creazione del rimborso.
Paginazione: Lo script gestisce automaticamente la paginazione dell'API usando il cursore starting_after fornito dall'API di Ramp. Recupera i record in batch (fino a 100 per richiesta) per assicurare che tutti i dati all'interno dell'intervallo di date vengano recuperati.
Rate Limiting: L'API di Ramp è soggetta a limiti di frequenza, tipicamente 600 richieste al minuto. Lo script fornito è generalmente efficiente, ma per dataset estremamente grandi, potrebbe essere necessario introdurre piccoli ritardi tra le chiamate API se incontra errori di limite di frequenza.

a Query di Esempio python

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

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># It is recommended to use environment variables for credentials
CLIENT_ID = os.getenv(class="hl-string">'RAMP_CLIENT_ID', class="hl-string">'[Your_Ramp_Client_ID]')
CLIENT_SECRET = os.getenv(class="hl-string">'RAMP_CLIENT_SECRET', class="hl-string">'[Your_Ramp_Client_Secret]')

API_BASE_URL = class="hl-string">'https://api.ramp.com/v1'
TOKEN_URL = class="hl-string">'https://api.ramp.com/v1/public/customer/token'

class=class="hl-string">"hl-comment"># --- Main Functions ---

def get_access_token():
    class="hl-string">"""Authenticates with the Ramp API to get a bearer token."""
    headers = {class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded'}
    data = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET,
        class="hl-string">'scope': class="hl-string">'transactions:read reimbursements:read users:read'
    }
    try:
        response = requests.post(TOKEN_URL, headers=headers, data=data)
        response.raise_for_status()
        return response.json()[class="hl-string">'access_token']
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error obtaining access token: {e}")
        if e.response is not None:
            print(fclass="hl-string">"Response body: {e.response.text}")
        return None

def fetch_paginated_data(endpoint, access_token, params=None):
    class="hl-string">"""Fetches all data from a paginated Ramp API endpoint."""
    all_data = []
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}'}
    url = fclass="hl-string">"{API_BASE_URL}{endpoint}"
    
    while url:
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_data.extend(data.get(class="hl-string">'data', []))
            url = data.get(class="hl-string">'next') class=class="hl-string">"hl-comment"># Ramp uses a full URL for the next page
            params = None class=class="hl-string">"hl-comment"># Subsequent requests use the class="hl-string">'next' URL which includes params
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {endpoint}: {e}")
            break
            
    return all_data

def map_state_to_activity(state, reason_code):
    class="hl-string">"""Maps reimbursement state history to a user-friendly activity name."""
    if reason_code == class="hl-string">'REJECTED':
        return class="hl-string">'Expense Sent Back for Revision'
    
    state_map = {
        class="hl-string">'SUBMITTED': class="hl-string">'Expense Submitted',
        class="hl-string">'MANAGER_APPROVAL': class="hl-string">'Manager Review Pending',
        class="hl-string">'ACCOUNTING_APPROVAL': class="hl-string">'Finance Review Pending',
        class="hl-string">'MANAGER_APPROVED': class="hl-string">'Manager Approved',
        class="hl-string">'ACCOUNTING_APPROVED': class="hl-string">'Finance Approved',
        class="hl-string">'PAYMENT_SCHEDULED': class="hl-string">'Reimbursement Scheduled',
        class="hl-string">'PAYMENT_PROCESSING': class="hl-string">'Reimbursement Executed', class=class="hl-string">"hl-comment"># Approximation
        class="hl-string">'FINISHED': class="hl-string">'Reimbursement Executed',
        class="hl-string">'SYNCED': class="hl-string">'Synced with Accounting System'
    }
    return state_map.get(state)

class=class="hl-string">"hl-comment"># --- Main Execution ---
def main():
    class="hl-string">"""Main script to extract, transform, and save the event log."""
    print(class="hl-string">"Starting Ramp data extraction...")
    access_token = get_access_token()
    if not access_token:
        print(class="hl-string">"Failed to get access token. Exiting.")
        return

    class=class="hl-string">"hl-comment"># 1. Fetch Users for enrichment
    print(class="hl-string">"Fetching users...")
    users = fetch_paginated_data(class="hl-string">'/users', access_token)
    user_map = {u[class="hl-string">'id']: {class="hl-string">'name': fclass="hl-string">"{u['first_name']} {u['last_name']}", class="hl-string">'department': u.get(class="hl-string">'department')} for u in users}
    print(fclass="hl-string">"Found {len(user_map)} users.")

    class=class="hl-string">"hl-comment"># 2. Fetch Reimbursements within a date range
    START_DATE = class="hl-string">'2023-01-01T00:00:00Z'
    END_DATE = class="hl-string">'2023-12-31T23:59:59Z'
    print(fclass="hl-string">"Fetching reimbursements from {START_DATE} to {END_DATE}...")
    reimbursement_params = {class="hl-string">'created_at_gte': START_DATE, class="hl-string">'created_at_lte': END_DATE}
    reimbursements = fetch_paginated_data(class="hl-string">'/reimbursements', access_token, params=reimbursement_params)
    print(fclass="hl-string">"Found {len(reimbursements)} reimbursements.")

    event_log = []

    class=class="hl-string">"hl-comment"># 3. Process each reimbursement to create the event log
    for r in reimbursements:
        case_id = r[class="hl-string">'id']
        report_total = r[class="hl-string">'amount']
        submitter_id = r[class="hl-string">'user_id']
        submitter_details = user_map.get(submitter_id, {class="hl-string">'name': class="hl-string">'Unknown User', class="hl-string">'department': None})
        expense_category = r.get(class="hl-string">'merchant_name') class=class="hl-string">"hl-comment"># Best available proxy for category
        
        class=class="hl-string">"hl-comment"># Process reimbursement state history
        for history in r.get(class="hl-string">'state_history', []):
            activity_name = map_state_to_activity(history[class="hl-string">'state'], history.get(class="hl-string">'reason_code'))
            if activity_name:
                event_log.append({
                    class="hl-string">'ExpenseReportId': case_id,
                    class="hl-string">'ActivityName': activity_name,
                    class="hl-string">'EventTimestamp': history[class="hl-string">'created_at'],
                    class="hl-string">'UserName': user_map.get(history.get(class="hl-string">'user_id'), submitter_details)[class="hl-string">'name'],
                    class="hl-string">'EmployeeDepartment': submitter_details[class="hl-string">'department'],
                    class="hl-string">'ReportTotalAmount': report_total,
                    class="hl-string">'ExpenseCategory': expense_category,
                    class="hl-string">'PolicyViolationFlag': None, class=class="hl-string">"hl-comment"># Not directly available in reimbursement history
                    class="hl-string">'RevisionReason': history.get(class="hl-string">'reason_notes')
                })

        class=class="hl-string">"hl-comment"># Fetch and process associated transactions
        for tx_id in r.get(class="hl-string">'transaction_ids', []):
            try:
                tx_response = requests.get(fclass="hl-string">"{API_BASE_URL}/transactions/{tx_id}", headers={class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}'})
                tx_response.raise_for_status()
                tx = tx_response.json()

                class=class="hl-string">"hl-comment"># Activity: Expense Incurred
                event_log.append({
                    class="hl-string">'ExpenseReportId': case_id,
                    class="hl-string">'ActivityName': class="hl-string">'Expense Incurred',
                    class="hl-string">'EventTimestamp': tx[class="hl-string">'user_transaction_time'],
                    class="hl-string">'UserName': submitter_details[class="hl-string">'name'],
                    class="hl-string">'EmployeeDepartment': submitter_details[class="hl-string">'department'],
                    class="hl-string">'ReportTotalAmount': report_total,
                    class="hl-string">'ExpenseCategory': tx.get(class="hl-string">'merchant_name'),
                    class="hl-string">'PolicyViolationFlag': tx.get(class="hl-string">'flagged_for_review'),
                    class="hl-string">'RevisionReason': None
                })

                class=class="hl-string">"hl-comment"># Activity: Receipt Attached
                if tx.get(class="hl-string">'receipts') and len(tx[class="hl-string">'receipts']) > 0:
                    receipt_time = tx[class="hl-string">'receipts'][0].get(class="hl-string">'upload_time', tx[class="hl-string">'user_transaction_time']) class=class="hl-string">"hl-comment"># Use transaction time as fallback
                    event_log.append({
                        class="hl-string">'ExpenseReportId': case_id,
                        class="hl-string">'ActivityName': class="hl-string">'Receipt Attached',
                        class="hl-string">'EventTimestamp': receipt_time,
                        class="hl-string">'UserName': submitter_details[class="hl-string">'name'],
                        class="hl-string">'EmployeeDepartment': submitter_details[class="hl-string">'department'],
                        class="hl-string">'ReportTotalAmount': report_total,
                        class="hl-string">'ExpenseCategory': tx.get(class="hl-string">'merchant_name'),
                        class="hl-string">'PolicyViolationFlag': tx.get(class="hl-string">'flagged_for_review'),
                        class="hl-string">'RevisionReason': None
                    })

                class=class="hl-string">"hl-comment"># Activity: Policy Check Performed (Approximation)
                if tx.get(class="hl-string">'flagged_for_review'):
                    event_log.append({
                        class="hl-string">'ExpenseReportId': case_id,
                        class="hl-string">'ActivityName': class="hl-string">'Policy Check Performed',
                        class="hl-string">'EventTimestamp': r.get(class="hl-string">'created_at'), class=class="hl-string">"hl-comment"># Use submission time as proxy
                        class="hl-string">'UserName': class="hl-string">'System',
                        class="hl-string">'EmployeeDepartment': submitter_details[class="hl-string">'department'],
                        class="hl-string">'ReportTotalAmount': report_total,
                        class="hl-string">'ExpenseCategory': tx.get(class="hl-string">'merchant_name'),
                        class="hl-string">'PolicyViolationFlag': True,
                        class="hl-string">'RevisionReason': None
                    })

            except requests.exceptions.RequestException as e:
                print(fclass="hl-string">"Could not fetch transaction {tx_id}: {e}")

    if not event_log:
        print(class="hl-string">"No events were generated. Check the date range and API responses.")
        return

    class=class="hl-string">"hl-comment"># 4. Create and save DataFrame
    print(class="hl-string">"Finalizing event log...")
    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
    df = df.sort_values(by=[class="hl-string">'ExpenseReportId', class="hl-string">'EventTimestamp'])

    class=class="hl-string">"hl-comment"># Ensure required columns are present
    final_columns = [
        class="hl-string">'ExpenseReportId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'UserName',
        class="hl-string">'EmployeeDepartment', class="hl-string">'ReportTotalAmount', class="hl-string">'ExpenseCategory',
        class="hl-string">'PolicyViolationFlag', class="hl-string">'RevisionReason'
    ]
    for col in final_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[final_columns]

    output_filename = class="hl-string">'ramp_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f%z')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

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

Fasi

Acceda al Suo account Ramp con privilegi di Amministratore o Contabile.
Navighi alla sezione Transazioni dal menu a sinistra. Questa visualizzazione contiene tutte le spese con carta aziendale.
Applichi i filtri desiderati ai dati. Al minimo, imposti un Intervallo di Date per il periodo che desidera analizzare. Può anche filtrare per altre proprietà come Stato, Categoria o Dipartimento per restringere l'ambito, se necessario.
Clicchi sul pulsante Esporta situato in alto a destra nell'elenco delle transazioni.
Nel modale di esportazione, selezioni Transazioni come tipo di esportazione e CSV come formato. Scarichi il file e lo nomini transactions_export.csv.
Successivamente, navighi alla sezione Rimborsi dal menu a sinistra. Questa visualizzazione contiene tutte le spese out-of-pocket presentate dai dipendenti.
Applichi lo stesso filtro per l'intervallo di date utilizzato per l'esportazione delle transazioni per garantire la coerenza dei dati.
Clicchi sul pulsante Esporta e scarichi i dati dei rimborsi come file CSV. Lo nomini reimbursements_export.csv.
Posizioni entrambi i file CSV esportati (transactions_export.csv e reimbursements_export.csv) nella stessa directory dello script Python fornito.
Esegua lo script Python. Lo script caricherà entrambi i file, trasformerà i dati creando una riga distinta per ogni evento aziendale e li unirà in un singolo event log strutturato.
Lo script produrrà un file denominato ramp_event_log.csv. Questo file è formattato secondo i requisiti di ProcessMind.
Carichi il file ramp_event_log.csv su ProcessMind per l'analisi.

Configurazione

Autorizzazioni: Deve possedere ruoli 'Admin' o 'Bookkeeper' in Ramp per accedere ed esportare i set di dati completi di transazioni e rimborsi.
Intervallo di Date: Per un'analisi iniziale, selezioni un intervallo di date di almeno 6-12 mesi per catturare sufficienti variazioni di processo. Per il monitoraggio continuo, può usare un intervallo più breve e più recente.
Coerenza dei dati: Si assicuri di usare lo stesso intervallo di date e gli stessi filtri quando esporta sia i file delle Transazioni che quelli dei Rimborsi per mantenere un dataset coerente.
Formato di Esportazione: Scelga sempre il formato CSV per entrambe le esportazioni, poiché lo script di trasformazione è progettato per elaborare file separati da virgole.
Nomi dei File: Si attenga ai nomi dei file transactions_export.csv e reimbursements_export.csv o aggiorni di conseguenza le variabili del percorso dei file nello script di trasformazione.

a Query di Esempio config

import pandas as pd
import numpy as np

# --- Configuration ---
TRANSACTIONS_FILE = 'transactions_export.csv'
REIMBURSEMENTS_FILE = 'reimbursements_export.csv'
OUTPUT_FILE = 'ramp_event_log.csv'

# --- Load Data ---
def load_data():
    try:
        transactions_df = pd.read_csv(TRANSACTIONS_FILE)
        reimbursements_df = pd.read_csv(REIMBURSEMENTS_FILE)
        print("Successfully loaded transactions and reimbursements files.")
        return transactions_df, reimbursements_df
    except FileNotFoundError as e:
        print(f"Error: {e}. Make sure '{TRANSACTIONS_FILE}' and '{REIMBURSEMENTS_FILE}' are in the same directory.")
        return None, None

# --- Main Transformation Logic ---
def transform_to_event_log(transactions_df, reimbursements_df):
    events = []

    # Standardize column names for easier processing
    # These names are based on typical Ramp CSV exports, adjust if your export has different headers
    transactions_df.rename(columns={
        'Transaction ID': 'ExpenseReportId',
        'User Name': 'UserName',
        'Department': 'EmployeeDepartment',
        'Amount': 'ReportTotalAmount',
        'Category Name': 'ExpenseCategory',
        'Transaction Date': 'ExpenseIncurredTimestamp',
        'Receipts Attached At': 'ReceiptAttachedTimestamp',
        'Submitted At': 'ExpenseSubmittedTimestamp',
        'Manager Approved At': 'ManagerApprovedTimestamp',
        'Needs Review At': 'FinanceReviewPendingTimestamp',
        'Admin Approved At': 'FinanceApprovedTimestamp',
        'Accounting Sync At': 'SyncedTimestamp',
        'Memo': 'RevisionReason',
        'State': 'Status'
    }, inplace=True)

    reimbursements_df.rename(columns={
        'Reimbursement ID': 'ExpenseReportId',
        'User Name': 'UserName',
        'Department': 'EmployeeDepartment',
        'Amount': 'ReportTotalAmount',
        'Category Name': 'ExpenseCategory',
        'Created At': 'ReimbursementScheduledTimestamp',
        'Paid Out At': 'ReimbursementExecutedTimestamp',
        'Memo': 'RevisionReason',
        'State': 'Status'
    }, inplace=True)

    # Combine card transactions and reimbursements into a single dataframe for processing common events
    # Note: Reimbursements will be processed separately for reimbursement-specific events
    combined_df = transactions_df

    # Process activities from the combined dataframe
    for _, row in combined_df.iterrows():
        base_event = {
            'ExpenseReportId': row.get('ExpenseReportId'),
            'UserName': row.get('UserName'),
            'EmployeeDepartment': row.get('EmployeeDepartment'),
            'ReportTotalAmount': row.get('ReportTotalAmount'),
            'ExpenseCategory': row.get('ExpenseCategory'),
            'PolicyViolationFlag': 'FLAGGED' in str(row.get('Flags')), # Infer from 'Flags' column
            'RevisionReason': row.get('RevisionReason')
        }

        # Activity: Expense Incurred
        if pd.notna(row.get('ExpenseIncurredTimestamp')):
            events.append({**base_event, 'ActivityName': 'Expense Incurred', 'EventTimestamp': row.get('ExpenseIncurredTimestamp')})

        # Activity: Receipt Attached
        if pd.notna(row.get('ReceiptAttachedTimestamp')):
            events.append({**base_event, 'ActivityName': 'Receipt Attached', 'EventTimestamp': row.get('ReceiptAttachedTimestamp')})

        # Activity: Expense Submitted
        if pd.notna(row.get('ExpenseSubmittedTimestamp')):
            events.append({**base_event, 'ActivityName': 'Expense Submitted', 'EventTimestamp': row.get('ExpenseSubmittedTimestamp')})
            # Inferred Activity: Policy Check Performed (assumed to happen right after submission)
            policy_check_ts = pd.to_datetime(row.get('ExpenseSubmittedTimestamp')) + pd.Timedelta(seconds=1)
            events.append({**base_event, 'ActivityName': 'Policy Check Performed', 'EventTimestamp': policy_check_ts.isoformat()})
            # Inferred Activity: Manager Review Pending (starts when submitted)
            events.append({**base_event, 'ActivityName': 'Manager Review Pending', 'EventTimestamp': row.get('ExpenseSubmittedTimestamp')})

        # Activity: Manager Approved
        if pd.notna(row.get('ManagerApprovedTimestamp')):
            events.append({**base_event, 'ActivityName': 'Manager Approved', 'EventTimestamp': row.get('ManagerApprovedTimestamp')})

        # Activity: Finance Review Pending
        if pd.notna(row.get('FinanceReviewPendingTimestamp')):
            events.append({**base_event, 'ActivityName': 'Finance Review Pending', 'EventTimestamp': row.get('FinanceReviewPendingTimestamp')})

        # Activity: Finance Approved
        if pd.notna(row.get('FinanceApprovedTimestamp')):
            events.append({**base_event, 'ActivityName': 'Finance Approved', 'EventTimestamp': row.get('FinanceApprovedTimestamp')})

        # Activity: Synced with Accounting System
        if pd.notna(row.get('SyncedTimestamp')):
            events.append({**base_event, 'ActivityName': 'Synced with Accounting System', 'EventTimestamp': row.get('SyncedTimestamp')})

        # Activity: Expense Sent Back for Revision
        if row.get('Status') == 'REJECTED' and pd.notna(row.get('Updated At')):
             events.append({**base_event, 'ActivityName': 'Expense Sent Back for Revision', 'EventTimestamp': row.get('Updated At')}) # Using last updated time for rejection

    # Process reimbursement-specific activities
    for _, row in reimbursements_df.iterrows():
        base_event = {
            'ExpenseReportId': row.get('ExpenseReportId'),
            'UserName': row.get('UserName'),
            'EmployeeDepartment': row.get('EmployeeDepartment'),
            'ReportTotalAmount': row.get('ReportTotalAmount'),
            'ExpenseCategory': row.get('ExpenseCategory'),
            'PolicyViolationFlag': False, # Typically less flagging on reimbursements
            'RevisionReason': row.get('RevisionReason')
        }

        # Activity: Reimbursement Scheduled
        if row.get('Status') == 'APPROVED' and pd.notna(row.get('ReimbursementScheduledTimestamp')):
            events.append({**base_event, 'ActivityName': 'Reimbursement Scheduled', 'EventTimestamp': row.get('ReimbursementScheduledTimestamp')})

        # Activity: Reimbursement Executed
        if row.get('Status') == 'PAID' and pd.notna(row.get('ReimbursementExecutedTimestamp')):
            events.append({**base_event, 'ActivityName': 'Reimbursement Executed', 'EventTimestamp': row.get('ReimbursementExecutedTimestamp')})

    if not events:
        print("Warning: No events were generated. Check the input files and column names.")
        return None

    # Create final DataFrame
    event_log_df = pd.DataFrame(events)
    event_log_df['EventTimestamp'] = pd.to_datetime(event_log_df['EventTimestamp'])
    event_log_df.sort_values(by=['ExpenseReportId', 'EventTimestamp'], inplace=True)
    
    return event_log_df

# --- Main execution block ---
if __name__ == "__main__":
    transactions_df, reimbursements_df = load_data()
    if transactions_df is not None and reimbursements_df is not None:
        event_log = transform_to_event_log(transactions_df, reimbursements_df)
        if event_log is not None:
            event_log.to_csv(OUTPUT_FILE, index=False, date_format='%Y-%m-%dT%H:%M:%S.%fZ')
            print(f"Successfully created event log with {len(event_log)} events. Saved to '{OUTPUT_FILE}'.")

Il suo Template per i Dati di Gestione delle Spese

Il suo Template per i Dati di Gestione delle Spese

`Attributi` di Gestione delle Spese

Attività di Gestione delle Spese

Guide all'Estrazione

Esportazione Integrata CSV di Transazioni e Rimborsi di Ramp

Fasi

Configurazione

a Query di Esempio config

Estrazione tramite Script Python via l'API per Sviluppatori di Ramp

Fasi

Configurazione

a Query di Esempio python

Sincronizzazione dell'Integrazione con Data Warehouse Ramp (Snowflake/BigQuery)

Fasi

Configurazione

a Query di Esempio config

Pronto per iniziare?

Sblocchi l'Efficienza: Ottimizzi la Gestione delle Spese Ramp Oggi

Il suo Template per i Dati di Gestione delle Spese

Il suo Template per i Dati di Gestione delle Spese

Attributi di Gestione delle Spese

Attività di Gestione delle Spese

Guide all'Estrazione

Esportazione Integrata CSV di Transazioni e Rimborsi di Ramp

Fasi

Configurazione

a Query di Esempio config

Estrazione tramite Script Python via l'API per Sviluppatori di Ramp

Fasi

Configurazione

a Query di Esempio python

Sincronizzazione dell'Integrazione con Data Warehouse Ramp (Snowflake/BigQuery)

Fasi

Configurazione

a Query di Esempio config

Abbiamo a cuore la Sua privacy

Pronto per iniziare?

Sblocchi l'Efficienza: Ottimizzi la Gestione delle Spese Ramp Oggi

`Attributi` di Gestione delle Spese