> Mejora Continua de Procesos > Gestión de gastos > Ramp > Plantilla de Datos

Plantilla de Datos de Gestión de Gastos

Ramp

Atributos de gestión de gastos (23) Actividades de gestión de gastos (12) Guías de Extracción (3)

Plantilla de Datos de Gestión de Gastos

Este `template` proporciona una hoja de ruta clara para recopilar los `data` necesarios para analizar y optimizar su proceso de gestión de gastos. Describe los `atributos` esenciales, las actividades clave a rastrear y una guía práctica para extraer sus `data` de Ramp. Utilice este recurso para asegurarse de que recopila toda la información necesaria para un descubrimiento y mejora de procesos perspicaces.

Atributos recomendados para recopilar
Actividades clave para el seguimiento
Guía de extracción para Ramp

¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Descargar Plantilla

Atributos de gestión de gastos

Estos son los campos de `data` esenciales para incluir en su `registro de eventos` para un análisis exhaustivo de su proceso de gestión de gastos.

3 Requerido 6 Recomendado 14 Opcional

	Nombre	Descripción
	ID de informe de gastos ExpenseReportId	El identificador único para cada informe de gastos, que sirve como identificador principal del `case` para el proceso.
Descripción El ID del Informe de Gastos agrupa todos los `event` y actividades relacionados con una única presentación de gastos. Permite un seguimiento completo y cronológico de un reclamo de gastos desde su entrada inicial hasta su pago final. En `Process Mining`, este `atributo` es esencial para reconstruir el recorrido de extremo a extremo de cada informe de gastos. Al usarlo como ID de `case`, los análisis pueden calcular con precisión los tiempos de ciclo, identificar `bottleneck` y visualizar las diferentes rutas que toman los informes a través del proceso de aprobación. Por qué es importante Este es el `atributo` fundamental que vincula todas las actividades relacionadas en una única instancia de proceso, haciendo posible el análisis de principio a fin. Dónde obtener Este identificador debería estar disponible en el informe de gastos principal o en la tabla de transacciones dentro de Ramp. Ejemplos ER-2023-08-1123ER-2023-09-4591ER-2023-10-0024
	Nombre de la Actividad ActivityName	El nombre del `event` o `task` específico que ocurrió en un `timestamp` dado dentro del proceso de gestión de gastos.
Descripción Este `atributo` describe un solo paso en el ciclo de vida del informe de gastos, como 'Gasto Enviado', 'Aprobado por el Gerente' o 'Reembolso Ejecutado'. Estas actividades forman los nodos en el mapa del proceso, permitiendo la visualización y el análisis del flujo del proceso. Analizar las actividades ayuda a identificar qué pasos son los más frecuentes, dónde ocurren los `bottleneck` y cómo varían los diferentes `workflow`. Es un componente central para comprender la secuencia de operaciones y medir el rendimiento en cada etapa. Por qué es importante Define los pasos en el mapa de procesos, permitiendo la visualización y el análisis del flujo del proceso de principio a fin. Dónde obtener Esto se deriva típicamente de `registro de eventos` o registros de cambio de estado asociados con cada informe de gastos en Ramp. Ejemplos Gasto enviadoAprobado por el GerenteRevisión de finanzas pendienteReembolso Ejecutado
	Timestamp del Evento EventTimestamp	La fecha y hora exactas en que ocurrió la actividad.
Descripción Cada actividad en el proceso tiene una marca de tiempo correspondiente que registra cuándo ocurrió. Estos datos temporales se utilizan para ordenar los eventos cronológicamente y son la base para todo el análisis relacionado con el tiempo. En Process Mining, los timestamps se utilizan para calcular los tiempos de ciclo entre actividades, medir la duración total de un caso e identificar retrasos. Esta información es fundamental para la monitorización del rendimiento y la identificación de oportunidades de mejora del proceso. Por qué es importante Este `atributo` proporciona el orden cronológico de los `event` y es esencial para todos los cálculos de duración y el análisis de rendimiento. Dónde obtener Esta información se encuentra típicamente junto a los registros de actividad o estado en los `registro de eventos` o `data` de transacciones de Ramp. Ejemplos 2023-10-26T10:00:00Z2023-10-26T14:30:00Z2023-10-27T09:00:00Z
	Bandera de Violación de Política PolicyViolationFlag	Un indicador que señala si el informe de gastos fue marcado por una infracción de política.
Descripción Este `atributo` booleano se establece en verdadero si los controles automatizados del sistema detectan una posible violación de las políticas de gastos de la empresa, como exceder un límite de gasto o presentar un gasto duplicado. Esta bandera es fundamental para el `dashboard` 'Detección de Violaciones de Política' y el KPI asociado. Ayuda a medir la eficacia de los controles de políticas e identificar áreas comunes de incumplimiento, lo que puede informar actualizaciones de políticas o capacitación de empleados. Por qué es importante Mide directamente el cumplimiento de las políticas, ayudando a identificar y reducir el gasto no conforme y los riesgos asociados. Dónde obtener Es probable que esta sea una bandera generada por el sistema dentro de Ramp, activada por verificaciones de políticas automatizadas durante el proceso de envío o aprobación. Ejemplos truefalse
	Categoría de gasto ExpenseCategory	La categoría asignada a un gasto, como 'Viajes', 'Software' o 'Comidas'.
Descripción Este `atributo` clasifica los gastos en categorías predefinidas, lo que ayuda a rastrear y controlar el gasto de la empresa. Un único informe de gastos puede contener elementos de varias categorías. Analizar por categoría de gasto es esencial para el `dashboard` 'Análisis de Categoría de Gasto'. Ayuda a los equipos financieros a comprender dónde se está gastando el dinero, monitorear el cumplimiento del presupuesto e identificar tendencias o anomalías en el gasto a lo largo del `timestamp`. Por qué es importante Permite un análisis detallado del gasto, ayudando a identificar los principales factores de costo y las oportunidades de optimización presupuestaria. Dónde obtener Esto es típicamente un detalle a nivel de partida individual en el informe de gastos en Ramp. Los `data` pueden necesitar ser agregados a nivel de informe para algunos análisis. Ejemplos Pasajes aéreosComidas y EntretenimientoSuscripción de SoftwareSuministros de Oficina
	Departamento del empleado EmployeeDepartment	El departamento del empleado que presentó el informe de gastos.
Descripción Este `atributo` indica la unidad de negocio o departamento al que pertenece el empleado que presenta el gasto, como 'Ventas', 'Ingeniería' o 'Marketing'. Esta es una dimensión crítica para el análisis, ya que permite filtrar y comparar el rendimiento del proceso en diferentes partes de la organización. Puede revelar variaciones en los tiempos de aprobación, las tasas de revisión y el `cumplimiento` de las políticas entre departamentos, apoyando iniciativas de mejora dirigidas. Por qué es importante Permite la comparación de métricas de proceso entre diferentes unidades de negocio, destacando variaciones en eficiencia, cumplimiento y gasto. Dónde obtener Es probable que esta información esté asociada con el perfil de usuario del empleado en Ramp o en un sistema de RRHH integrado. Ejemplos VentasMarketingIngenieríaFinanzas
	Importe Total del Informe ReportTotalAmount	El valor monetario total del informe de gastos.
Descripción Este `atributo` representa la suma de todos los gastos incluidos en un único informe. Es una métrica financiera clave para comprender los patrones de gasto. En el análisis de procesos, el importe del informe se puede utilizar para segmentar `case` e investigar si los informes de alto valor siguen diferentes rutas de aprobación o tardan más en procesarse. Es fundamental para los `dashboard` de análisis de gastos y para identificar oportunidades de ahorro de costos. Por qué es importante Proporciona una dimensión financiera crucial para el análisis, permitiendo la segmentación de informes por valor y el seguimiento del gasto total. Dónde obtener Este es un campo primario en el objeto del informe de gastos en Ramp. Ejemplos 150.752500.0089.99
	Motivo de Revisión RevisionReason	El motivo proporcionado cuando un informe de gastos se devuelve al empleado para su revisión.
Descripción Cuando un aprobador rechaza o devuelve un informe de gastos, típicamente proporciona un motivo. Este `atributo` captura ese motivo, como 'Recibo Faltante', 'Categoría Incorrecta' o 'Fuera de Política'. Esta información es invaluable para el `dashboard` 'Tasa y Causas de Revisión de Gastos'. Al analizar las razones más comunes de retrabajo, las organizaciones pueden identificar problemas sistémicos en el proceso de envío e implementar capacitaciones específicas o mejoras en el sistema para reducir errores. Por qué es importante Proporciona información directa sobre las causas raíz del retrabajo, permitiendo acciones dirigidas para mejorar la calidad de la primera presentación. Dónde obtener Estos `data` se capturarían en los comentarios o detalles de rechazo cuando la actividad 'Gasto Enviado de Vuelta para Revisión' ocurre en Ramp. Ejemplos Recibo detallado faltanteEl gasto excede el límite de la políticaCategoría de gasto incorrecta seleccionadaTransacción duplicada
	Nombre de Usuario UserName	El nombre o ID del usuario que realizó la actividad, incluyendo al empleado que presenta el gasto o al aprobador.
Descripción Este `atributo` identifica al individuo responsable de un `event` particular en el proceso, como enviar, aprobar o revisar un informe de gastos. Puede ser el nombre de un empleado o una ID de usuario única. Analizar por usuario ayuda a comprender la distribución de la carga de trabajo, identificar a los de mejor rendimiento y señalar a las personas que pueden requerir capacitación adicional. Es clave para los `dashboard` relacionados con el rendimiento de la aprobación y la gestión de recursos. Por qué es importante Atribuye las actividades del proceso a individuos específicos, lo que permite un análisis del rendimiento a nivel de recursos e identifica las necesidades de capacitación. Dónde obtener La información del usuario se registra típicamente en la pista de auditoría o en el historial de transacciones de cada informe de gastos en Ramp. Ejemplos Alice JohnsonBob SmithCharlie BrownAutomatización del Sistema
	¿Es Retrabajo? IsRework	Un indicador calculado que señala si un informe de gastos ha sido devuelto para revisión al menos una vez.
Descripción Este `atributo` booleano se deriva verificando si la actividad 'Gasto Enviado de Vuelta para Revisión' ha ocurrido para un `case` dado. Se establece en verdadero para cualquier informe que haya pasado por al menos un ciclo de revisión. Esta bandera simplifica el cálculo del KPI 'Tasa de Revisión de Informes de Gastos' y permite un fácil filtrado y comparación entre informes que fueron aprobados en la primera pasada y aquellos que requirieron retrabajo. Analizar estas dos cohortes puede revelar el impacto en `timestamp` y costo de las revisiones. Por qué es importante Segmenta fácilmente el proceso para el análisis de retrabajo, ayudando a cuantificar la frecuencia y el impacto de los informes que se devuelven para su corrección. Dónde obtener Este es un campo calculado, derivado durante la transformación de `data` al verificar la existencia de una actividad de revisión dentro del `case`. Ejemplos truefalse
	Aprobador de finanzas FinanceApprover	El usuario del equipo de finanzas que aprobó el informe de gastos.
Descripción Para los flujos de trabajo que incluyen un paso de revisión financiera, este atributo identifica a la persona o equipo específico dentro del departamento de finanzas que realizó la aprobación final. Este atributo respalda el panel de control de 'Eficiencia de la Revisión Financiera' al permitir que el rendimiento se analice a nivel individual o de equipo. Ayuda a identificar cuellos de botella, evaluar la distribución de la carga de trabajo y medir la eficacia de la etapa de revisión financiera. Por qué es importante Permite un análisis detallado del rendimiento del paso de revisión financiera, lo que ayuda a optimizar un punto de control crítico en el proceso. Dónde obtener Esto se capturaría en el historial de aprobación del informe de gastos en Ramp durante la etapa de revisión financiera. Ejemplos Equipo de Finanzas ADavid LeeBot de automatización financiera
	Gerente aprobador ApprovingManager	El nombre del gerente que realizó el paso de aprobación.
Descripción Este `atributo` identifica al gerente responsable de revisar y aprobar el informe de gastos de un empleado. Es distinto del usuario que envió el informe. El seguimiento del gerente que aprueba es esencial para el `dashboard` 'Tiempo de Ciclo de Aprobación del Gerente'. Permite el análisis de las cargas de trabajo y el rendimiento de las aprobaciones, destacando a los gerentes que aprueban rápidamente frente a aquellos que son `bottleneck`. Esto puede ayudar a equilibrar las cargas de trabajo o a proporcionar apoyo adicional. Por qué es importante Permite el análisis de rendimiento de los aprobadores individuales, ayudando a identificar y abordar los cuellos de botella en el flujo de trabajo de aprobación. Dónde obtener Esta información es parte de los `data` del `workflow` de aprobación en Ramp, registrada cuando un gerente toma una acción sobre un informe. Ejemplos Jane DoeJohn MillerSusan Chen
	Hora Fin del Evento EventEndTime	El `timestamp` que indica cuándo concluyó una actividad con una duración.
Descripción Si bien muchas actividades son instantáneas, algunas, como 'Verificación de Política Realizada', pueden tener una duración medible. Este `atributo` captura la hora de finalización de dichas actividades, complementando la Hora de Inicio. Tener tanto una hora de inicio como una de finalización permite el cálculo preciso de los tiempos de procesamiento de la actividad. Esto es esencial para KPIs como 'Duración Promedio de la Verificación de Política' y para identificar exactamente cuánto `timestamp` tardan en completarse `task` específicas automatizadas o manuales dentro del proceso general. Por qué es importante Permite el cálculo preciso de la duración de las actividades individuales, lo cual es crucial para identificar pasos del proceso ineficientes. Dónde obtener Para actividades con duración, esto se registraría en los datos de eventos de Ramp. Para eventos instantáneos, puede ser lo mismo que StartTime. Ejemplos 2023-10-26T10:00:05Z2023-10-26T14:35:10Z2023-10-27T09:10:00Z
	Método de Envío SubmissionMethod	El canal a través del cual se envió el informe de gastos, como aplicación móvil o portal web.
Descripción Este `atributo` indica cómo el empleado envió su informe de gastos. Los métodos comunes incluyen el uso de una aplicación móvil, un navegador web de escritorio o el reenvío de correo electrónico. Analizar el método de envío puede proporcionar `insights` sobre el comportamiento del usuario y la adopción de tecnología. Por ejemplo, una alta tasa de revisiones para informes enviados a través de un determinado canal podría indicar problemas de usabilidad con la interfaz de ese canal. Por qué es importante Proporciona contexto sobre el comportamiento del usuario y puede ayudar a identificar si ciertos canales de envío están asociados con mayores tasas de error o retrasos. Dónde obtener Esta información puede capturarse en los metadatos del `event` de envío en los `logs` del sistema de Ramp. Ejemplos App móvilPortal webEmail
	Método de Reembolso ReimbursementMethod	El método utilizado para ejecutar el pago de reembolso, como ACH o transferencia bancaria.
Descripción Este `atributo` especifica el canal de pago a través del cual se reembolsó al empleado. Los diferentes métodos pueden tener diferentes tiempos de procesamiento y costos asociados. Analizar el rendimiento del reembolso por método ayuda a identificar los canales de pago más eficientes. El `dashboard` 'Rendimiento del Método de Reembolso' utiliza estos `data` para comparar los tiempos de ciclo y la fiabilidad, lo que puede llevar a la optimización de las estrategias de pago. Por qué es importante Permite comparar el rendimiento entre diferentes canales de pago, ayudando a optimizar la velocidad y la fiabilidad. Dónde obtener Esta información debería estar disponible en los registros de pago o reembolso dentro de Ramp. Ejemplos Transferencia ACHCrédito de tarjeta corporativaDepósito directo
	Recuento de pasos de aprobación ApprovalStepCount	El número total de pasos de aprobación formales por los que ha pasado un informe de gastos.
Descripción Esta métrica calculada cuenta el número de actividades de aprobación distintas, como 'Aprobado por el Gerente' y 'Aprobado por Finanzas', que han ocurrido para un único informe de gastos. Ayuda a cuantificar la complejidad del `workflow` de aprobación. Este `atributo` se utiliza para el KPI 'Promedio de Pasos de Aprobación por Informe' y el `dashboard` 'Rutas de Aprobación de Gastos Simples'. Al analizar este recuento, especialmente en relación con el valor o la categoría del informe, las organizaciones pueden identificar si los gastos simples y de bajo valor están sujetos a procesos de aprobación excesivamente complejos. Por qué es importante Cuantifica la complejidad del flujo de trabajo, ayudando a identificar oportunidades de simplificación, especialmente para informes de bajo riesgo. Dónde obtener Esto se calcula contando las ocurrencias de actividades específicas relacionadas con la aprobación dentro de cada `case` en el `registro de eventos`. Ejemplos 123
	Resultado de la auditoría AuditOutcome	El resultado de una auditoría interna o externa del informe de gastos.
Descripción Para los informes de gastos que se someten a una auditoría formal, este atributo registra el resultado final, como 'Aprobado', 'Parcialmente denegado' o 'Información adicional requerida'. Estos datos son fundamentales para el panel de control de 'Rendimiento de Auditoría de Gastos'. Ayuda a evaluar la eficacia del proceso de auditoría, a rastrear la frecuencia de los diferentes resultados y a comprender el impacto financiero de los hallazgos de la auditoría. Por qué es importante Mide la eficacia y los resultados del proceso de auditoría, proporcionando información sobre las debilidades de cumplimiento y control. Dónde obtener Esto se registraría en el módulo de auditoría de Ramp o en un sistema integrado si se utiliza para una auditoría detallada de gastos. Ejemplos AprobadoAprobado con ObservacionesRechazadaEscalado
	Source System SourceSystem	Identifica la aplicación de origen de la que se extrajeron los datos.
Descripción Este `atributo` especifica el sistema de registro para los `data` del proceso, que en este `case` es Ramp. Es útil en entornos donde los `data` pueden mezclarse de múltiples sistemas, asegurando una clara línea de `data`. Para el análisis, ayuda a filtrar `data` de una fuente específica y puede usarse para fines de validación y gobernanza de `data`. Por qué es importante Proporciona contexto sobre el origen de los datos, lo cual es crucial para la gobernanza de datos y al integrar datos de múltiples sistemas. Dónde obtener Este es típicamente un valor estático ('Ramp') añadido durante el proceso de extracción y transformación de `data`. Ejemplos Ramp
	Tiempo de aprobación del gerente ManagerApprovalTime	El tiempo transcurrido desde que un informe está pendiente de revisión del gerente hasta que este lo aprueba o rechaza.
Descripción Esta métrica calcula la duración de la etapa de aprobación del gerente. Es la diferencia de `timestamp` entre la actividad 'Revisión del Gerente Pendiente' y la actividad subsiguiente 'Aprobado por el Gerente' o 'Rechazado por el Gerente'. Esta duración se utiliza para calcular el KPI 'Tiempo Promedio de Aprobación del Gerente' y alimentar el `dashboard` 'Tiempo de Ciclo de Aprobación del Gerente'. Ayuda a identificar retrasos en el primer nivel de aprobación, que a menudo es un `bottleneck` significativo. Por qué es importante Aísla la duración de un paso de aprobación crítico, ayudando a identificar y abordar los cuellos de botella causados por las revisiones del gerente. Dónde obtener Esto se calcula a partir del `registro de eventos` al encontrar la diferencia de `timestamp` entre los `event` de revisión pendiente del gerente y los de finalización. Ejemplos 1 hora 15 minutos2 days 3 hours5 horas 30 minutos
	Tiempo de contabilización AccountingPostingTime	El tiempo desde que se ejecuta un reembolso hasta que la transacción se contabiliza en el sistema contable.
Descripción Esta métrica calculada mide el retraso en el registro financiero. Es la diferencia de `timestamp` entre el `event` 'Reembolso Ejecutado' y el `event` 'Sincronizado con el Sistema Contable'. Este `atributo` se utiliza para el KPI 'Tiempo Promedio de Asiento Contable' y el `dashboard` 'Retrasos en el Asiento Contable'. Ayuda a asegurar que los registros financieros se actualicen rápidamente, lo cual es importante para informes financieros precisos y oportunos. Por qué es importante Destaca los retrasos en el mantenimiento de registros financieros, lo que permite tomar medidas para acelerar el proceso de cierre contable. Dónde obtener Esto se calcula a partir de los `timestamp` de los `event` en el `data` `log` para los `event` de reembolso y sincronización contable. Ejemplos 2 horas1 día5 minutos
	Tiempo de revisión de finanzas FinanceReviewTime	El tiempo que un informe de gastos pasa en la etapa de revisión financiera.
Descripción Esta métrica mide la duración desde que un informe entra en la cola de finanzas ('Revisión Financiera Pendiente') hasta que un aprobador financiero toma acción ('Aprobado por Finanzas' o 'Rechazado por Finanzas'). Es la medida principal para el KPI 'Tiempo Promedio de Revisión Financiera' y el `dashboard` 'Eficiencia de Revisión Financiera'. Analizar esta duración ayuda a identificar oportunidades para agilizar o automatizar el proceso de revisión financiera, reduciendo el esfuerzo manual y acelerando el ciclo general. Por qué es importante Mide la eficiencia del proceso de revisión del departamento de finanzas, destacando oportunidades de automatización y optimización. Dónde obtener Este valor se calcula a partir de los `timestamp` de los `event` para el inicio y el final de las actividades de revisión financiera. Ejemplos 4 horas1 día 2 horas18 horas
	Tiempo Total del Ciclo de Reembolso TotalReimbursementCycleTime	El tiempo total transcurrido desde que se presentó un informe de gastos hasta que se ejecutó el reembolso.
Descripción Esta métrica calculada mide la duración de extremo a extremo del proceso de reembolso desde el punto de vista del empleado. Se calcula como la diferencia de `timestamp` entre los `event` 'Gasto Enviado' y 'Reembolso Ejecutado' para cada `case`. Este `atributo` es la base para el KPI 'Tiempo Promedio del Ciclo de Reembolso' y el `dashboard` 'Ciclo de Reembolso de Extremo a Extremo'. Proporciona una medida de alto nivel de la eficiencia del proceso y es un indicador clave de la satisfacción del empleado. Por qué es importante Cuantifica la duración total del proceso, proporcionando un indicador clave de rendimiento para medir la eficiencia de principio a fin. Dónde obtener Esto se calcula durante la transformación de `data` restando el `timestamp` del primer `event` de envío del `event` final de reembolso. Ejemplos 3 días 4 horas10 días 1 hora1 día 8 horas
	Última actualización de datos LastDataUpdate	La `timestamp` que indica la última vez que los `datos` se actualizaron desde el sistema de origen.
Descripción Este `atributo` registra la fecha y hora de la extracción de `data` más reciente. Proporciona contexto sobre la actualidad de los `data` que se están analizando. En cualquier análisis, conocer la antigüedad de los `data` es crucial para interpretar los resultados correctamente. Este `atributo` ayuda a los usuarios a comprender si están viendo información actualizada. Por qué es importante Informa a los usuarios sobre la puntualidad de los datos, asegurando que los análisis se basen en información actual y relevante. Dónde obtener Este `timestamp` se genera y añade durante el proceso de extracción de `data`. Ejemplos 2023-11-01T06:00:00Z

Requerido Recomendado Opcional

Actividades de gestión de gastos

Estos son los pasos clave y los hitos del proceso que deben capturarse en su registro de eventos para un descubrimiento de procesos preciso y una medición del rendimiento.

5 Recomendado 7 Opcional

	Actividad	Descripción
	Aprobado por el Gerente	El gerente ha revisado el gasto y lo ha aprobado, permitiendo que proceda al siguiente paso, como la revisión financiera o el reembolso. Esto se captura a través de una acción explícita del usuario.
Por qué es importante Este es un hito clave que indica la finalización exitosa del primer nivel de aprobación. Es crucial para analizar los `workflow` de aprobación e identificar `bottleneck`. Dónde obtener Registrado como un `event` en el historial de aprobación del gasto cuando el gerente hace clic en 'Aprobar'. El `registro de eventos` debe contener la ID del aprobador y un `timestamp`. Capturar Se registra un evento al realizar la acción 'Aprobar' por parte de un usuario con permisos de gerente. Tipo de evento explicit
	Gasto enviado	Un empleado confirma que toda la información necesaria para un gasto está completa y lo envía para el proceso de aprobación. Esta es una acción explícita del usuario que mueve el gasto de un estado de 'borrador' o 'necesita atención' a un estado de 'aprobación pendiente'.
Por qué es importante Esta actividad es un hito crítico que inicia oficialmente el ciclo de aprobación y reembolso. Es la línea de base para medir los SLA de aprobación y reembolso. Dónde obtener Capturado del historial de estado del objeto de gasto. Esto corresponde a la acción del usuario de enviar la transacción para revisión. Capturar Registrado cuando el usuario hace clic en el botón 'Enviar', lo que activa un cambio de estado. Tipo de evento explicit
	Gasto incurrido	Marca la creación de un gasto, típicamente iniciado de forma automática cuando se utiliza una tarjeta corporativa o cuando un empleado crea manualmente un registro de gasto de bolsillo. Este `event` se captura generalmente a partir de flujos de `data` de transacciones o acciones de interfaz de usuario.
Por qué es importante Este es el `event` de inicio primario para el ciclo de vida del gasto. Analizar el `timestamp` desde este `event` ayuda a comprender los retrasos en el envío y la velocidad general del proceso. Dónde obtener Generado a partir de los registros de transacciones de tarjetas de Ramp o de la marca de tiempo de creación de un objeto de gasto introducido manualmente. Busque el evento inicial de creación de registro en la tabla de gastos o transacciones. Capturar Registrado directamente cuando se procesa una transacción con tarjeta o un usuario crea una nueva entrada de gasto. Tipo de evento explicit
	Reembolso Ejecutado	El pago de reembolso ha sido procesado y enviado con éxito al empleado. Este suele ser el paso final para el empleado y marca el fin del ciclo de pago.
Por qué es importante Este es el `event` final primario para el proceso de reembolso. La duración desde el envío hasta este punto es un KPI crítico para la satisfacción del empleado y la eficiencia del proceso. Dónde obtener Capturado de los registros de procesamiento de pagos o de una integración con el proveedor de pagos. El estado del gasto en Ramp se actualizaría a 'Reembolsado' o 'Pagado'. Capturar Se registra un evento cuando el sistema de pagos confirma la transferencia exitosa del pago. Tipo de evento explicit
	Sincronizado con el Sistema Contable	Los `data` de la transacción de gastos se han contabilizado con éxito en el sistema contable integrado, como NetSuite, QuickBooks o Xero. Este `event` marca la finalización de la parte de registro financiero del proceso.
Por qué es importante Esta es la actividad final en el proceso de extremo a extremo. Los retrasos aquí pueden afectar la precisión de los informes financieros y la velocidad del cierre financiero. Dónde obtener Registrado en un `log` de integración o como una actualización de estado en el objeto de gasto en Ramp. Busque un estado como 'Synced', 'Posted' o 'Exported'. Capturar Una entrada de registro es creada por el servicio de integración contable tras la sincronización exitosa de los datos. Tipo de evento explicit
	Aprobado por finanzas	El equipo de finanzas ha revisado y dado la aprobación final del gasto, autorizándolo para reembolso y sincronización contable. Esto se captura como una acción explícita del usuario por parte de un miembro del equipo de finanzas.
Por qué es importante Representa la puerta de aprobación final antes del pago. Analizar esta actividad ayuda a comprender el ciclo de aprobación de principio a fin y la eficiencia del equipo de finanzas. Dónde obtener Registrado como un evento en el historial de aprobación del gasto. Busque un evento de aprobación asociado a un usuario del departamento de finanzas. Capturar Se registra un evento al realizar la acción 'Aprobar' por parte de un usuario con permisos de finanzas. Tipo de evento explicit
	Gasto devuelto para revisión	Un aprobador, ya sea un gerente o un revisor de finanzas, ha rechazado el gasto y lo ha devuelto al empleado para su corrección. Esto se registra mediante un cambio de estado a 'Necesita Revisión' o 'Rechazado'.
Por qué es importante Esta actividad significa un bucle de retrabajo en el proceso, que aumenta directamente el tiempo de ciclo. El seguimiento de estos `event` ayuda a identificar errores comunes de envío y a mejorar el rendimiento en el primer intento. Dónde obtener Inferido de un cambio de estado en el objeto de gasto a 'Necesita revisión' o un estado similar. El evento debe vincularse al aprobador que inició la acción. Capturar Derivado de la marca de tiempo cuando el estado del gasto pasa a ser 'Necesita revisión' o 'Rechazado'. Tipo de evento inferred
	Recibo Adjunto	Representa el momento en que se asocia un recibo a un gasto, ya sea automáticamente mediante OCR o manualmente por el usuario. Esto se captura cuando el archivo del recibo se vincula con éxito al registro de la transacción.
Por qué es importante El seguimiento de esta actividad ayuda a identificar retrasos causados por la falta de documentación. Es un paso clave para garantizar el `cumplimiento` y la preparación para la auditoría. Dónde obtener Registrado en el historial de gastos o transacciones cuando se sube o se asocia un recibo. Busque un evento de creación de adjunto o un indicador que señale 'receipt_attached'. Capturar El evento se crea cuando el sistema vincula una imagen o archivo de recibo al registro de gastos. Tipo de evento explicit
	Reembolso Programado	Para los gastos de bolsillo, el monto aprobado ha sido puesto en cola para su procesamiento de pago. Este evento indica que el gasto ha pasado todas las aprobaciones y está listo para ser pagado.
Por qué es importante Este hito separa el proceso de aprobación del proceso de ejecución de pagos. Ayuda a aislar los retrasos que ocurren en el procesamiento de pagos frente a los de las aprobaciones. Dónde obtener Probablemente inferido del cambio de estado del gasto a 'Reembolso Pendiente' o 'Listo para Pago' después de la aprobación final. También puede ser un evento explícito si los pagos se realizan por lotes. Capturar Derivado de un cambio de estado a 'Listo para pagar' o de la creación de un registro en una tabla de lotes de pago. Tipo de evento inferred
	Revisión de finanzas pendiente	Un gasto aprobado ha sido escalado y ahora está a la espera de revisión por parte del equipo de finanzas o contabilidad. Esto ocurre normalmente con gastos de alto valor o aquellos con indicadores de política. La actividad se infiere de un cambio de estado.
Por qué es importante Marca el inicio del ciclo de revisión financiera. Medir la duración de esta etapa ayuda a evaluar la carga de trabajo y la eficiencia del equipo de finanzas, e identifica oportunidades de automatización. Dónde obtener Inferido de un cambio de estado en el objeto de gasto a 'Aprobación financiera pendiente' después de la aprobación del gerente. Esto requiere acceso al historial de estado del gasto. Capturar Derivado de la marca de tiempo cuando el estado del gasto se actualiza a 'Pendiente de revisión financiera'. Tipo de evento inferred
	Revisión del gerente pendiente	El gasto ha sido presentado y ahora está a la espera de la revisión del gerente directo del empleado. Este estado se infiere cuando el estado del gasto cambia a 'Aprobación del Gerente Pendiente' o un valor similar después del envío.
Por qué es importante Identifica el inicio de la etapa de aprobación del gerente. Analizar el tiempo transcurrido en este estado es clave para medir y mejorar los tiempos de ciclo de aprobación del gerente. Dónde obtener Inferido de un cambio de estado en el objeto de gasto a un estado como 'Aprobación pendiente' y asignación a la cola de un gerente. Requiere seguimiento del historial de estado. Capturar Derivado de la marca de tiempo cuando el estado del gasto pasa a ser 'Pendiente de aprobación del gerente'. Tipo de evento inferred
	Verificación de Política Realizada	El sistema audita automáticamente el gasto contra las políticas configuradas de la empresa, marcando cualquier posible infracción. Este es típicamente un `event` generado por el sistema que ocurre poco después de la presentación.
Por qué es importante Mide la eficiencia de los controles automatizados de `cumplimiento` y su impacto en el proceso. Ayuda a identificar violaciones comunes de políticas y áreas para la capacitación del empleado. Dónde obtener Probablemente registrado en un rastro de auditoría o registro asociado con la transacción de gastos. Busque eventos del sistema relacionados con 'policy_check' o 'compliance_scan'. Capturar Se crea una entrada de registro del sistema después de que el motor de políticas automatizado se ejecuta en la transacción. Tipo de evento explicit

Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de Ramp

Pasos

Inicie sesión en su cuenta de Ramp con privilegios de Administrador o Contable.
Navegue a la sección de Transacciones desde el menú de la izquierda. Esta vista contiene todos los gastos de tarjeta corporativa.
Aplique los filtros deseados a los datos. Como mínimo, establezca un Rango de Fechas para el período que desea analizar. También puede filtrar por otras propiedades como Estado, Categoría o Departamento para acotar el alcance si es necesario.
Haga clic en el botón Exportar ubicado en la parte superior derecha de la lista de transacciones.
En la ventana modal de exportación, seleccione Transacciones como tipo de exportación y CSV como formato. Descargue el archivo y nómbrelo transactions_export.csv.
A continuación, navegue a la sección de Reembolsos desde el menú de la izquierda. Esta vista contiene todos los gastos de bolsillo presentados por los empleados.
Aplique el mismo filtro de rango de fechas utilizado para la exportación de transacciones para asegurar la consistencia de los datos.
Haga clic en el botón Exportar y descargue los datos de reembolsos como un archivo CSV. Nómbrelo reimbursements_export.csv.
Coloque ambos archivos CSV exportados (transactions_export.csv y reimbursements_export.csv) en el mismo directorio que el script de Python proporcionado.
Ejecute el script de Python. El script cargará ambos archivos, transformará los datos creando una fila distinta para cada evento de negocio y los fusionará en un único registro de eventos estructurado.
El script generará un archivo llamado ramp_event_log.csv. Este archivo está formateado de acuerdo con los requisitos de ProcessMind.
Suba el archivo ramp_event_log.csv a ProcessMind para su análisis.

Configuración

Permisos: Debe tener roles de 'Admin' o 'Bookkeeper' en Ramp para acceder y exportar los conjuntos de datos completos de transacciones y reembolsos.
Rango de Fechas: Para un análisis inicial, seleccione un rango de fechas de al menos 6 a 12 meses para capturar suficientes variaciones del proceso. Para una monitorización continua, puede utilizar un rango más corto y reciente.
Consistencia de Datos: Asegúrese de usar el mismo rango de fechas y filtros al exportar los archivos de Transacciones y Reembolsos para mantener un conjunto de datos consistente.
Formato de Exportación: Elija siempre el formato CSV para ambas exportaciones, ya que el script de transformación está diseñado para procesar archivos separados por comas.
Nomenclatura de Archivos: Adhiera a los nombres de archivo transactions_export.csv y reimbursements_export.csv o actualice las variables de ruta de archivo en el script de transformación según sea necesario.

a Consulta de ejemplo 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}'.")

Pasos

Requisitos previos y configuración del entorno: Asegúrese de tener Python 3.8 o superior instalado. Instale las bibliotecas de Python necesarias ejecutando pip install requests pandas. También debe tener acceso de administrador a su instancia de Ramp para generar credenciales de API.
Generar credenciales de API de Ramp: Inicie sesión en su cuenta de Ramp. Navegue a Configuración y luego seleccione API de desarrollador en el menú lateral. Haga clic en 'Crear aplicación', déle un nombre a su aplicación y configure los ámbitos requeridos. Necesitará transactions:read, reimbursements:read y users:read. Una vez creada, copie de forma segura el Client ID y el Client Secret.
Configurar el script de Python: Cree un nuevo archivo de Python, por ejemplo extract_ramp_log.py. Copie el script de Python proporcionado en este archivo. Establezca su Client ID y Client Secret como variables de entorno o directamente en el script para fines de prueba. Es altamente recomendable utilizar variables de entorno por seguridad.
Establecer el rango de fechas de extracción: En el script, localice las variables START_DATE y END_DATE dentro del bloque de ejecución main. Ajuste estas fechas para definir la ventana de tiempo para la extracción de datos. Se recomienda un período de 3 a 6 meses para un análisis inicial.
Ejecutar el script: Ejecute el script desde su terminal usando el comando python extract_ramp_log.py. El script se autenticará con la API de Ramp, obtendrá datos de los puntos finales de usuarios, transacciones y reembolsos, y gestionará la paginación automáticamente.
Comprender las llamadas a la API: El script primero obtiene todos los datos de usuario para crear un mapeo de IDs de usuario a nombres y departamentos. Luego recupera todos los reembolsos dentro del rango de fechas especificado. Para cada reembolso, extrae el historial de aprobación y pago.
Transformar datos en un registro de eventos: La lógica central del script itera a través de cada reembolso y su historial de estado asociado. Traduce cada cambio de estado, como 'MANAGER_APPROVAL' o 'FINISHED', en una actividad distinta como 'Revisión del Gerente Pendiente' o 'Reembolso Ejecutado'. También obtiene datos de transacciones asociados para crear eventos de 'Gasto Incurrido' y 'Recibo Adjunto'.
Manejo del enriquecimiento de datos: El script enriquece el registro de eventos agregando detalles de usuario, información de departamento y categoría de gastos para cada evento, creando un conjunto de datos completo para el análisis de procesos.
Revisar la salida: Una vez que el script se complete, generará un archivo llamado ramp_event_log.csv en el mismo directorio. Abra este archivo CSV en un programa de hoja de cálculo para inspeccionar los datos y asegurarse de que se hayan extraído como se esperaba.
Preparar para la carga: El archivo CSV generado está estructurado con las columnas requeridas: ExpenseReportId, ActivityName, EventTimestamp y otros atributos recomendados. Este archivo está listo para su carga directa en la plataforma ProcessMind.

Configuración

Credenciales de API: Se requiere un Client ID y Client Secret válidos para la autenticación. Estos se generan en el panel de control de Ramp en Configuración > API de Desarrollador.
Ámbitos de API: El script requiere permisos específicos para acceder a los datos. Asegúrese de que los siguientes ámbitos estén habilitados para su clave de API: transactions:read (para detalles de gastos y recibos), reimbursements:read (para el estado de envío, aprobación y pago) y users:read (para el nombre y departamento del empleado).
Rango de Fechas: La extracción se rige por los parámetros START_DATE y END_DATE en el script. Se recomienda comenzar con un período reciente, como los últimos 3-6 meses, para mantener el conjunto de datos inicial manejable. El filtro se aplica a la fecha de creación del reembolso.
Paginación: El script gestiona automáticamente la paginación de la API utilizando el cursor starting_after proporcionado por la API de Ramp. Recupera registros en lotes (hasta 100 por solicitud) para asegurar que se obtengan todos los datos dentro del rango de fechas.
Limitación de Tasas: La API de Ramp está sujeta a límites de tasas, generalmente 600 solicitudes por minuto. El script proporcionado es generalmente eficiente, pero para conjuntos de datos extremadamente grandes, podría necesitar introducir pequeños retrasos entre las llamadas a la API si encuentra errores de limitación de tasas.

a Consulta de ejemplo 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()

Pasos

Inicie sesión en su cuenta de Ramp con privilegios de Administrador o Contable.
Navegue a la sección de Transacciones desde el menú de la izquierda. Esta vista contiene todos los gastos de tarjeta corporativa.
Aplique los filtros deseados a los datos. Como mínimo, establezca un Rango de Fechas para el período que desea analizar. También puede filtrar por otras propiedades como Estado, Categoría o Departamento para acotar el alcance si es necesario.
Haga clic en el botón Exportar ubicado en la parte superior derecha de la lista de transacciones.
En la ventana modal de exportación, seleccione Transacciones como tipo de exportación y CSV como formato. Descargue el archivo y nómbrelo transactions_export.csv.
A continuación, navegue a la sección de Reembolsos desde el menú de la izquierda. Esta vista contiene todos los gastos de bolsillo presentados por los empleados.
Aplique el mismo filtro de rango de fechas utilizado para la exportación de transacciones para asegurar la consistencia de los datos.
Haga clic en el botón Exportar y descargue los datos de reembolsos como un archivo CSV. Nómbrelo reimbursements_export.csv.
Coloque ambos archivos CSV exportados (transactions_export.csv y reimbursements_export.csv) en el mismo directorio que el script de Python proporcionado.
Ejecute el script de Python. El script cargará ambos archivos, transformará los datos creando una fila distinta para cada evento de negocio y los fusionará en un único registro de eventos estructurado.
El script generará un archivo llamado ramp_event_log.csv. Este archivo está formateado de acuerdo con los requisitos de ProcessMind.
Suba el archivo ramp_event_log.csv a ProcessMind para su análisis.

Configuración

Permisos: Debe tener roles de 'Admin' o 'Bookkeeper' en Ramp para acceder y exportar los conjuntos de datos completos de transacciones y reembolsos.
Rango de Fechas: Para un análisis inicial, seleccione un rango de fechas de al menos 6 a 12 meses para capturar suficientes variaciones del proceso. Para una monitorización continua, puede utilizar un rango más corto y reciente.
Consistencia de Datos: Asegúrese de usar el mismo rango de fechas y filtros al exportar los archivos de Transacciones y Reembolsos para mantener un conjunto de datos consistente.
Formato de Exportación: Elija siempre el formato CSV para ambas exportaciones, ya que el script de transformación está diseñado para procesar archivos separados por comas.
Nomenclatura de Archivos: Adhiera a los nombres de archivo transactions_export.csv y reimbursements_export.csv o actualice las variables de ruta de archivo en el script de transformación según sea necesario.

a Consulta de ejemplo 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}'.")

Plantilla de Datos de Gestión de Gastos

Plantilla de Datos de Gestión de Gastos

Atributos de gestión de gastos

Actividades de gestión de gastos

Guías de Extracción

Exportación CSV Integrada de Transacciones y Reembolsos de Ramp

Pasos

Configuración

a Consulta de ejemplo config

Extracción de Script de Python a través de la API para Desarrolladores de Ramp

Pasos

Configuración

a Consulta de ejemplo python

Sincronización de Integración de `Data` Warehouse de Ramp (Snowflake/BigQuery)

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para comenzar?

Desbloquee la Eficiencia: Optimice la Gestión de Gastos de Ramp Hoy

Plantilla de Datos de Gestión de Gastos

Plantilla de Datos de Gestión de Gastos

Atributos de gestión de gastos

Actividades de gestión de gastos

Guías de Extracción

Exportación CSV Integrada de Transacciones y Reembolsos de Ramp

Pasos

Configuración

a Consulta de ejemplo config

Extracción de Script de Python a través de la API para Desarrolladores de Ramp

Pasos

Configuración

a Consulta de ejemplo python

Sincronización de Integración de `Data` Warehouse de Ramp (Snowflake/BigQuery)

Pasos

Configuración

a Consulta de ejemplo config

Valoramos su privacidad

¿Listo para comenzar?

Desbloquee la Eficiencia: Optimice la Gestión de Gastos de Ramp Hoy