> Amélioration continue des processus > Gestion des dépenses > Ramp > Modèle de données

Votre Template de Données de Gestion des Dépenses

Ramp

Attributs de gestion des dépenses (23) Activités de gestion des dépenses (12) Guides d'extraction (3)

Votre Template de Données de Gestion des Dépenses

Ce modèle fournit une feuille de route claire pour la collecte des données nécessaires à l'analyse et à l'optimisation de votre processus de gestion des dépenses. Il décrit les attributs essentiels, les activités clés à suivre et des conseils pratiques pour extraire vos données de Ramp. Utilisez cette ressource pour vous assurer de rassembler toutes les informations nécessaires à une découverte et une amélioration éclairées des processus.

Attributs recommandés à collecter
Activités clés à suivre
Guide d'extraction pour Ramp

Nouveau dans les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Télécharger le modèle

Attributs de gestion des dépenses

Ce sont les champs de données essentiels à inclure dans votre journal d'événements pour une analyse complète de votre processus de gestion des dépenses.

3 Obligatoire 6 Recommandé 14 Facultatif

	Nom	Description
	ID du rapport de dépenses ExpenseReportId	L'identifiant unique pour chaque note de frais, servant d'identifiant de cas principal pour le processus.
Description L'ID de la note de frais regroupe tous les événements et activités liés à une seule soumission de dépenses. Il permet un suivi complet et chronologique d'une demande de remboursement, de son entrée initiale à son paiement final. Dans le process mining, cet attribut est essentiel pour reconstituer le parcours de bout en bout de chaque note de frais. En l'utilisant comme ID de cas, les analyses peuvent calculer avec précision les temps de cycle, identifier les goulots d'étranglement et visualiser les différents chemins empruntés par les rapports à travers le processus d'approbation. Pourquoi c'est important C'est l'attribut fondamental qui relie toutes les activités associées en une seule instance de processus, rendant possible l'analyse de bout en bout. Où obtenir Cet identifiant devrait être disponible dans la table principale des notes de frais ou des transactions au sein de Ramp. Exemples ER-2023-08-1123ER-2023-09-4591ER-2023-10-0024
	Nom de l'activité ActivityName	Le nom de l'événement ou de la tâche spécifique qui s'est produit à un moment donné du processus de gestion des dépenses.
Description Cet attribut décrit une étape unique dans le cycle de vie de la note de frais, telle que « Dépense soumise », « Approuvé par le manager » ou « Remboursement exécuté ». Ces activités constituent les nœuds de la cartographie des processus, permettant la visualisation et l'analyse du flux de processus. L'analyse des activités aide à identifier les étapes les plus fréquentes, où se produisent les goulots d'étranglement et comment les différents workflows varient. C'est un composant essentiel pour comprendre la séquence des opérations et mesurer la performance à chaque étape. Pourquoi c'est important Il définit les étapes de la cartographie des processus, permettant la visualisation et l'analyse du flux de processus du début à la fin. Où obtenir Ceci est généralement dérivé des journaux d'événements ou des enregistrements de changement de statut associés à chaque note de frais dans Ramp. Exemples Dépense soumiseApprouvé par le responsableRévision financière en attenteRemboursement exécuté
	Timestamp de l'événement EventTimestamp	La date et l'heure exactes de l'activité.
Description Chaque activité du processus a un horodatage (`timestamp`) correspondant qui enregistre le moment où elle s'est produite. Ces données temporelles sont utilisées pour ordonner les événements chronologiquement et constituent la base de toutes les analyses liées au temps. En Process Mining, les horodatages sont utilisés pour calculer les `cycle times` entre les activités, mesurer la durée totale d'un cas et identifier les retards. Cette information est essentielle pour la surveillance des performances et l'identification des opportunités d'amélioration des processus. Pourquoi c'est important Cet attribut fournit l'ordre chronologique des événements et est essentiel pour tous les calculs de durée et l'analyse des performances. Où obtenir Ces informations se trouvent généralement à côté des enregistrements d'activité ou de statut dans les journaux d'événements ou les données de transaction de Ramp. Exemples 2023-10-26T10:00:00Z2023-10-26T14:30:00Z2023-10-27T09:00:00Z
	Catégorie de dépense ExpenseCategory	La catégorie attribuée à une dépense, telle que 'Voyage', 'Logiciel' ou 'Repas'.
Description Cet attribut classe les dépenses en catégories prédéfinies, ce qui aide à suivre et à contrôler les dépenses de l'entreprise. Une seule note de frais peut contenir des éléments de plusieurs catégories. L'analyse par catégorie de dépenses est essentielle pour le dashboard « Analyse des catégories de dépenses ». Elle aide les équipes financières à comprendre où l'argent est dépensé, à surveiller le respect du budget et à identifier les tendances ou les anomalies en matière de dépenses au fil du temps. Pourquoi c'est important Il permet une analyse détaillée des dépenses, aidant à identifier les principaux facteurs de coût et les opportunités d'optimisation budgétaire. Où obtenir Il s'agit généralement d'un détail au niveau de la ligne sur la note de frais dans Ramp. Les données peuvent nécessiter d'être agrégées au niveau du rapport pour certaines analyses. Exemples Billets d'avionRepas et divertissementsAbonnement logicielFournitures de bureau
	Département de l'employé EmployeeDepartment	Le département de l'employé qui a soumis la note de frais.
Description Cet attribut indique l'unité commerciale ou le département auquel appartient l'employé soumettant la dépense, comme 'Ventes', 'Ingénierie' ou 'Marketing'. C'est une dimension d'analyse critique, car elle permet de filtrer et de comparer les performances des processus à travers différentes parties de l'organisation. Elle peut révéler des variations dans les temps d'approbation, les taux de révision et la conformité aux politiques entre les départements, soutenant des initiatives d'amélioration ciblées. Pourquoi c'est important Il permet de comparer les métriques de processus entre différentes unités commerciales, mettant en évidence les variations d'efficacité, de conformité et de dépenses. Où obtenir Ces informations sont probablement associées au profil utilisateur de l'employé dans Ramp ou un système RH intégré. Exemples VentesMarketingIngénierieFinance
	Indicateur de violation de politique PolicyViolationFlag	Un indicateur signalant si le rapport de dépenses a été signalé pour une violation de politique.
Description Cet attribut booléen est défini sur vrai si les vérifications automatisées du système détectent une violation potentielle des politiques de dépenses de l'entreprise, comme le dépassement d'une limite de dépenses ou la soumission d'une dépense en double. Cet indicateur est essentiel pour le dashboard « Détection des violations de politique » et le KPI associé. Il aide à mesurer l'efficacité des contrôles de politique et à identifier les domaines courants de non-conformité, ce qui peut éclairer les mises à jour de politique ou la formation des employés. Pourquoi c'est important Il mesure directement la conformité aux politiques, aidant à identifier et à réduire les dépenses non conformes et les risques associés. Où obtenir Il s'agit probablement d'un indicateur généré par le système au sein de Ramp, déclenché par des contrôles de politique automatisés pendant le processus de soumission ou d'approbation. Exemples truefaux
	Montant total du rapport ReportTotalAmount	La valeur monétaire totale de la note de frais.
Description Cet attribut représente la somme de toutes les dépenses incluses dans un seul rapport. C'est une métrique financière clé pour comprendre les schémas de dépenses. Dans l'analyse des processus, le montant du rapport peut être utilisé pour segmenter les cas et étudier si les rapports de grande valeur suivent des parcours d'approbation différents ou prennent plus de temps à traiter. Il est fondamental pour les dashboards d'analyse des dépenses et pour identifier les opportunités d'économies. Pourquoi c'est important Il fournit une dimension financière cruciale pour l'analyse, permettant la segmentation des rapports par valeur et le suivi des dépenses globales. Où obtenir Ceci est un champ principal sur l'objet note de frais dans Ramp. Exemples 150.752500.0089.99
	Nom d'utilisateur UserName	Le nom ou l'ID de l'utilisateur qui a effectué l'activité, y compris l'employé soumettant la dépense ou l'approbateur.
Description Cet attribut identifie l'individu responsable d'un événement particulier dans le processus, tel que la soumission, l'approbation ou la révision d'une note de frais. Il peut s'agir du nom d'un employé ou d'un ID utilisateur unique. L'analyse par utilisateur aide à comprendre la répartition de la charge de travail, à identifier les meilleurs performeurs et à cibler les individus qui pourraient nécessiter une formation supplémentaire. C'est un élément clé pour les dashboards liés à la performance d'approbation et à la gestion des ressources. Pourquoi c'est important Il attribue les activités de processus à des individus spécifiques, permettant l'analyse des performances au niveau des ressources et l'identification des besoins de formation. Où obtenir Les informations utilisateur sont généralement enregistrées dans la piste d'audit ou l'historique des transactions pour chaque note de frais dans Ramp. Exemples Alice JohnsonBob SmithCharlie Brown`Automatisation du système`
	Raison de la révision RevisionReason	La raison fournie lorsqu'une note de frais est renvoyée à l'employé pour révision.
Description Lorsqu'un approbateur rejette ou renvoie une note de frais, il fournit généralement une raison. Cet attribut capture cette raison, telle que « Reçu manquant », « Catégorie incorrecte » ou « Non conforme à la politique ». Ces informations sont inestimables pour le dashboard « Taux de révision des dépenses et causes ». En analysant les raisons les plus courantes de retravail, les organisations peuvent identifier les problèmes systémiques dans le processus de soumission et mettre en œuvre des formations ciblées ou des améliorations de système pour réduire les erreurs. Pourquoi c'est important Il offre un aperçu direct des causes profondes des retouches, permettant des actions ciblées pour améliorer la qualité des soumissions initiales. Où obtenir Ces données seraient capturées dans les commentaires ou les détails de rejet lorsque l'activité « Dépense renvoyée pour révision » se produit dans Ramp. Exemples Reçu détaillé manquantDépense dépassant la limite de politiqueCatégorie de dépense incorrecte sélectionnéeTransaction en double
	Approbateur financier FinanceApprover	L'utilisateur de l'équipe financière qui a approuvé la note de frais.
Description Pour les `workflows` qui incluent une étape de révision financière, cet attribut identifie la personne ou l'équipe spécifique au sein du service financier qui a effectué l'approbation finale. Cet attribut soutient le Dashboard 'Efficacité de la révision financière' en permettant d'analyser les performances au niveau individuel ou d'équipe. Il aide à identifier les goulots d'étranglement, à évaluer la répartition de la charge de travail et à mesurer l'efficacité de l'étape de révision financière. Pourquoi c'est important Il permet une analyse détaillée des performances de l'étape de révision financière, contribuant à optimiser un point de contrôle critique du processus. Où obtenir Ceci serait capturé dans l'historique d'approbation de la note de frais dans Ramp pendant l'étape d'examen financier. Exemples Équipe financière ADavid LeeRobot d'automatisation financière
	Dernière mise à jour des données LastDataUpdate	Le timestamp indiquant la dernière fois que les données ont été actualisées à partir du système source.
Description Cet attribut enregistre la date et l'heure de la dernière extraction de données. Il fournit un contexte sur la fraîcheur des données analysées. Dans toute analyse, connaître la date de mise à jour des données est crucial pour interpréter correctement les résultats. Cet attribut aide les utilisateurs à savoir s'ils consultent des informations à jour. Pourquoi c'est important Il informe les utilisateurs sur la pertinence des données, garantissant que les analyses sont basées sur des informations actuelles et pertinentes. Où obtenir Cet horodatage est généré et ajouté pendant le processus d'extraction des données. Exemples 2023-11-01T06:00:00Z
	Est un retravail IsRework	Un indicateur calculé qui signale si un rapport de dépenses a été renvoyé pour révision au moins une fois.
Description Cet attribut booléen est dérivé en vérifiant si l'activité « Dépense renvoyée pour révision » s'est produite pour un cas donné. Il est défini sur vrai pour tout rapport ayant subi au moins un cycle de révision. Cet indicateur simplifie le calcul du KPI « Taux de révision des notes de frais » et permet un filtrage et une comparaison faciles entre les rapports approuvés dès le premier passage et ceux qui ont nécessité un retravail. L'analyse de ces deux cohortes peut révéler l'impact temporel et financier des révisions. Pourquoi c'est important Il segmente facilement le processus pour l'analyse des retouches, aidant à quantifier la fréquence et l'impact des rapports renvoyés pour correction. Où obtenir Ceci est un champ calculé, dérivé lors de la transformation des données en vérifiant l'existence d'une activité de révision au sein du cas. Exemples truefaux
	Heure de fin de l'événement EventEndTime	L'horodatage indiquant la fin d'une activité ayant une durée.
Description Alors que de nombreuses activités sont instantanées, certaines, comme « Contrôle de politique effectué », peuvent avoir une durée mesurable. Cet attribut capture l'heure de fin de ces activités, complétant l'heure de début. Avoir à la fois une heure de début et de fin permet le calcul précis des temps de traitement des activités. C'est essentiel pour les KPI comme « Durée moyenne du contrôle de politique » et pour identifier exactement combien de temps les tâches automatisées ou manuelles spécifiques prennent pour être complétées dans le processus global. Pourquoi c'est important Il permet le calcul précis des durées d'activités individuelles, ce qui est crucial pour identifier les étapes de processus inefficaces. Où obtenir Pour les activités ayant une durée, cela serait enregistré dans les données d'événements de Ramp. Pour les événements instantanés, cela peut être identique à l'heure de début (StartTime). Exemples 2023-10-26T10:00:05Z2023-10-26T14:35:10Z2023-10-27T09:10:00Z
	Méthode de remboursement ReimbursementMethod	La méthode utilisée pour exécuter le paiement de remboursement, telle que l'ACH ou le virement bancaire.
Description Cet attribut spécifie le canal de paiement par lequel l'employé a été remboursé. Différentes méthodes peuvent avoir des temps de traitement et des coûts associés différents. L'analyse de la performance du remboursement par méthode aide à identifier les canaux de paiement les plus efficaces. Le dashboard « Performance des méthodes de remboursement » utilise ces données pour comparer les temps de cycle et la fiabilité, pouvant potentiellement conduire à l'optimisation des stratégies de paiement. Pourquoi c'est important Il permet de comparer les performances entre les différents canaux de paiement, aidant à optimiser la vitesse et la fiabilité. Où obtenir Ces informations devraient être disponibles dans les enregistrements de paiement ou de remboursement au sein de Ramp. Exemples Virement ACHCrédit de carte d'entrepriseDépôt direct
	Méthode de soumission SubmissionMethod	Le canal par lequel la note de frais a été soumise, tel qu'une application mobile ou un portail web.
Description Cet attribut indique comment l'employé a soumis sa note de frais. Les méthodes courantes incluent l'utilisation d'une application mobile, d'un navigateur web de bureau ou le renvoi par e-mail. L'analyse de la méthode de soumission peut fournir des informations sur le comportement des utilisateurs et l'adoption de la technologie. Par exemple, un taux élevé de révisions pour les rapports soumis via un certain canal pourrait indiquer des problèmes d'utilisabilité avec l'interface de ce canal. Pourquoi c'est important Il fournit un contexte sur le comportement des utilisateurs et peut aider à identifier si certains canaux de soumission sont associés à des taux d'erreur ou des retards plus élevés. Où obtenir Ces informations peuvent être capturées dans les métadonnées de l'événement de soumission dans les journaux système de Ramp. Exemples Mobile AppPortail webE-mail
	Nombre d'étapes d'approbation ApprovalStepCount	Le nombre total d'étapes d'approbation formelles qu'une note de frais a traversées.
Description Cette métrique calculée compte le nombre d'activités d'approbation distinctes, telles que « Approuvé par le manager » et « Approuvé par la finance », qui ont eu lieu pour une seule note de frais. Elle aide à quantifier la complexité du workflow d'approbation. Cet attribut est utilisé pour le KPI « Nombre moyen d'étapes d'approbation par rapport » et le dashboard « Parcours d'approbation des dépenses simples ». En analysant ce compte, notamment en relation avec la valeur ou la catégorie du rapport, les organisations peuvent identifier si les dépenses simples et de faible valeur sont soumises à des processus d'approbation excessivement complexes. Pourquoi c'est important Il quantifie la complexité du `workflow`, aidant à identifier les opportunités de simplification, en particulier pour les rapports à faible risque. Où obtenir Ceci est calculé en comptant les occurrences d'activités spécifiques liées à l'approbation au sein de chaque cas dans le journal d'événements. Exemples 123
	Responsable approbateur ApprovingManager	Le nom du manager qui a effectué l'étape d'approbation.
Description Cet attribut identifie le manager responsable de l'examen et de l'approbation de la note de frais d'un employé. Il est distinct de l'utilisateur qui a soumis le rapport. Le suivi du manager approbateur est essentiel pour le dashboard « Temps de cycle d'approbation du manager ». Il permet d'analyser les charges de travail et les performances d'approbation, en mettant en évidence les managers qui approuvent rapidement par rapport à ceux qui constituent des goulots d'étranglement. Cela peut aider à équilibrer les charges de travail ou à fournir un soutien supplémentaire. Pourquoi c'est important Il permet l'analyse des performances des approbateurs individuels, aidant à identifier et à résoudre les goulots d'étranglement dans le `workflow` d'approbation. Où obtenir Ces informations font partie des données du workflow d'approbation dans Ramp, enregistrées lorsqu'un manager agit sur un rapport. Exemples Jane DoeJohn MillerSusan Chen
	Résultat de l'audit AuditOutcome	Le résultat d'un audit interne ou externe de la note de frais.
Description Pour les rapports de dépenses qui font l'objet d'un audit formel, cet attribut enregistre le résultat final, tel que 'Approuvé', 'Partiellement refusé' ou 'Informations complémentaires requises'. Ces données sont au cœur du Dashboard 'Performance d'audit des dépenses'. Elles aident à évaluer l'efficacité du processus d'audit, à suivre la fréquence des différents résultats et à comprendre l'impact financier des conclusions de l'audit. Pourquoi c'est important Il mesure l'efficacité et les résultats du processus d'audit, fournissant des aperçus sur la conformité et les faiblesses de contrôle. Où obtenir Ceci serait enregistré dans le module d'audit de Ramp ou un système intégré si l'un est utilisé pour un audit détaillé des dépenses. Exemples RéussiApprouvé avec commentairesRejetéEscaladé
	Système source SourceSystem	Identifie l'application source à partir de laquelle les données ont été extraites.
Description Cet attribut spécifie le système d'enregistrement des données de processus, qui est Ramp dans ce cas. Il est utile dans les environnements où les données peuvent provenir de plusieurs systèmes, assurant une lignée claire des données. Pour l'analyse, il aide à filtrer les données d'une source spécifique et peut être utilisé à des fins de validation et de gouvernance des données. Pourquoi c'est important Il fournit le contexte sur l'origine des données, ce qui est crucial pour la gouvernance des données et lors de l'intégration de données provenant de plusieurs systèmes. Où obtenir Il s'agit généralement d'une valeur statique ('Ramp') ajoutée lors du processus d'extraction et de transformation des données. Exemples Ramp
	Temps d'approbation du responsable ManagerApprovalTime	Le temps écoulé entre le moment où un rapport est en attente d'examen par le manager et le moment où le manager l'approuve ou le rejette.
Description Cette métrique calcule la durée de l'étape d'approbation du manager. C'est la différence de temps entre l'activité « Examen du manager en attente » et l'activité « Approuvé par le manager » ou « Rejeté par le manager » qui suit. Cette durée est utilisée pour calculer le KPI « Temps moyen d'approbation du manager » et alimenter le dashboard « Temps de cycle d'approbation du manager ». Elle aide à identifier les retards dans le premier niveau d'approbation, qui est souvent un goulot d'étranglement significatif. Pourquoi c'est important Il isole la durée d'une étape d'approbation critique, aidant à identifier et à résoudre les goulots d'étranglement causés par les révisions des responsables. Où obtenir Ceci est calculé à partir du journal d'événements en trouvant la différence de temps entre les événements d'attente et de fin d'examen du manager. Exemples 1 heure 15 minutes2 jours 3 heures5 heures 30 minutes
	Temps de comptabilisation AccountingPostingTime	Le temps entre l'exécution d'un remboursement et la comptabilisation de la transaction dans le système comptable.
Description Cette métrique calculée mesure le délai de tenue des registres financiers. C'est la différence de temps entre l'événement « Remboursement exécuté » et l'événement « Synchronisé avec le système comptable ». Cet attribut est utilisé pour le KPI « Temps moyen de comptabilisation » et le dashboard « Délais de comptabilisation ». Il aide à garantir que les registres financiers sont mis à jour rapidement, ce qui est important pour une information financière précise et opportune. Pourquoi c'est important Il met en évidence les retards dans la tenue des registres financiers, permettant des actions pour accélérer le processus de clôture comptable. Où obtenir Ceci est calculé à partir des horodatages d'événements dans le journal de données pour les événements de remboursement et de synchronisation comptable. Exemples 2 heures1 jour5 minutes
	Temps de cycle de remboursement total TotalReimbursementCycleTime	Le temps total écoulé entre la soumission d'une note de frais et l'exécution du remboursement.
Description Cette métrique calculée mesure la durée de bout en bout du processus de remboursement du point de vue de l'employé. Elle est calculée comme la différence de temps entre les événements « Dépense soumise » et « Remboursement exécuté » pour chaque cas. Cet attribut est la base du KPI « Temps de cycle de remboursement moyen » et du dashboard « Cycle de remboursement de bout en bout ». Il fournit une mesure globale de l'efficacité du processus et est un indicateur clé de la satisfaction des employés. Pourquoi c'est important Il quantifie la durée globale du processus, fournissant un indicateur clé de performance pour mesurer l'efficacité de bout en bout. Où obtenir Ceci est calculé lors de la transformation des données en soustrayant l'horodatage du premier événement de soumission de celui du dernier événement de remboursement. Exemples 3 jours 4 heures10 jours 1 heure1 jour 8 heures
	Temps de révision financière FinanceReviewTime	Le temps passé par une note de frais dans l'étape d'examen financier.
Description Cette métrique mesure la durée entre le moment où un rapport entre dans la file d'attente financière ('Examen financier en attente') et le moment où un approbateur financier agit ('Approuvé par la finance' ou 'Rejeté par la finance'). C'est la mesure principale pour le KPI « Temps moyen d'examen financier » et le dashboard « Efficacité de l'examen financier ». L'analyse de cette durée aide à identifier les opportunités de rationaliser ou d'automatiser le processus d'examen financier, réduisant l'effort manuel et accélérant le cycle global. Pourquoi c'est important Il mesure l'efficacité du processus de révision du département financier, mettant en évidence les opportunités d'automatisation et de rationalisation. Où obtenir Cette valeur est calculée à partir des horodatages des événements pour le début et la fin des activités d'examen financier. Exemples 4 heures1 jour 2 heures18 heures

Obligatoire Recommandé Facultatif

Activités de gestion des dépenses

Voici les étapes clés du processus et les jalons à capturer dans votre *log* d'événements pour une découverte de processus et une mesure de performance précises.

5 Recommandé 7 Facultatif

	Activité	Description
	Approuvé par le responsable	Le manager a examiné la dépense et l'a approuvée, lui permettant de passer à l'étape suivante, comme l'examen financier ou le remboursement. Ceci est enregistré via une action utilisateur explicite.
Pourquoi c'est important C'est un jalon clé indiquant la réussite de la première étape d'approbation. C'est crucial pour analyser les workflows d'approbation et identifier les goulots d'étranglement. Où obtenir Enregistré comme événement dans l'historique d'approbation de la dépense lorsque le manager clique sur 'Approuver'. Le journal d'événements doit contenir l'ID de l'approbateur et un horodatage. Capture Un événement est enregistré lors de l'action 'Approuver' par un utilisateur disposant des autorisations de gestionnaire. Type d'événement explicit
	Dépense engagée	Marque la création d'une dépense, généralement initiée automatiquement lors de l'utilisation d'une carte d'entreprise ou lorsqu'un employé crée manuellement un enregistrement de dépense personnelle. Cet événement est habituellement capturé à partir des flux de données de transaction ou des actions de l'interface utilisateur.
Pourquoi c'est important C'est l'événement de début principal du cycle de vie des dépenses. L'analyse du temps à partir de cet événement aide à comprendre les retards de soumission et la vitesse globale du processus. Où obtenir Généré à partir des journaux de transactions par carte Ramp ou de l'horodatage de création d'un objet de dépense saisi manuellement. Recherchez l'événement de création d'enregistrement initial dans la table des dépenses ou des transactions. Capture Enregistré directement lorsqu'une transaction par carte est traitée ou qu'un utilisateur crée une nouvelle entrée de dépense. Type d'événement explicit
	Dépense soumise	Un employé confirme que toutes les informations nécessaires pour une dépense sont complètes et les soumet pour le processus d'approbation. Il s'agit d'une action utilisateur explicite qui fait passer la dépense d'un état 'brouillon' ou 'nécessite une attention' à un état 'en attente d'approbation'.
Pourquoi c'est important Cette activité est un jalon critique qui lance officiellement le cycle d'approbation et de remboursement. Elle sert de référence pour mesurer les SLA d'approbation et de remboursement. Où obtenir Capturé à partir de l'historique de statut de l'objet de dépense. Cela correspond à l'action utilisateur de soumission de la transaction pour révision. Capture Enregistré lorsque l'utilisateur clique sur le bouton 'Soumettre', déclenchant un changement de statut. Type d'événement explicit
	Remboursement exécuté	Le paiement de remboursement a été traité avec succès et envoyé à l'employé. C'est généralement l'étape finale pour l'employé et marque la fin du cycle de paiement.
Pourquoi c'est important C'est l'événement de fin principal pour le processus de remboursement. La durée de la soumission à ce point est un KPI critique pour la satisfaction des employés et l'efficacité du processus. Où obtenir Capturé à partir des journaux de traitement des paiements ou d'une intégration avec le fournisseur de paiement. Le statut des dépenses dans Ramp serait mis à jour à 'Remboursé' ou 'Payé'. Capture Un événement est enregistré lorsque le système de paiement confirme un transfert de paiement réussi. Type d'événement explicit
	Synchronisé avec le système comptable	Les données de transaction de la dépense ont été correctement comptabilisées dans le système comptable intégré, tel que NetSuite, QuickBooks ou Xero. Cet événement marque l'achèvement de la partie de tenue de registres financiers du processus.
Pourquoi c'est important C'est l'activité finale du processus de bout en bout. Les retards ici peuvent impacter la précision des rapports financiers et la vitesse de la clôture financière. Où obtenir Enregistré dans un journal d'intégration ou comme mise à jour de statut sur l'objet dépense dans Ramp. Recherchez un statut comme 'Synchronisé', 'Comptabilisé' ou 'Exporté'. Capture Une entrée de journal est créée par le service d'intégration comptable lors d'une synchronisation de données réussie. Type d'événement explicit
	Approuvé par les finances	L'équipe financière a examiné et donné son approbation finale pour la dépense, la validant pour le remboursement et la synchronisation comptable. Ceci est enregistré comme une action utilisateur explicite par un membre de l'équipe financière.
Pourquoi c'est important Représente la dernière étape d'approbation avant le paiement. L'analyse de cette activité aide à comprendre le cycle d'approbation de bout en bout et l'efficacité de l'équipe financière. Où obtenir Enregistré comme un événement dans l'historique d'approbation de la dépense. Recherchez un événement d'approbation associé à un utilisateur du service financier. Capture Un événement est enregistré lors de l'action 'Approuver' par un utilisateur disposant des autorisations financières. Type d'événement explicit
	Contrôle de politique effectué	Le système audite automatiquement la dépense par rapport aux politiques d'entreprise configurées, signalant toute violation potentielle. Il s'agit généralement d'un événement généré par le système qui se produit peu après la soumission.
Pourquoi c'est important Mesure l'efficacité des contrôles de conformité automatisés et leur impact sur le processus. Aide à identifier les violations de politique courantes et les domaines nécessitant une formation des employés. Où obtenir Probablement enregistré dans un journal d'audit ou un log associé à la transaction de dépense. Recherchez les événements système liés à 'policy_check' ou 'compliance_scan'. Capture Une entrée de journal système est créée après l'exécution du moteur de politiques automatisé sur la transaction. Type d'événement explicit
	Dépense renvoyée pour révision	Un approbateur, qu'il s'agisse d'un responsable ou d'un réviseur financier, a rejeté la dépense et l'a renvoyée à l'employé pour correction. Ceci est enregistré par un changement de statut vers un état 'Nécessite une révision' ou 'Rejeté'.
Pourquoi c'est important Cette activité représente une boucle de retravail dans le processus, ce qui augmente directement le temps de cycle. Le suivi de ces événements aide à identifier les erreurs de soumission courantes et à améliorer le taux de réussite du premier passage. Où obtenir Déduit d'un changement de statut sur l'objet de dépense vers 'Nécessite une révision' ou un état similaire. L'événement doit être lié à l'approbateur qui a initié l'action. Capture Dérivé de l'horodatage lorsque le statut de la dépense devient 'Nécessite une révision' ou 'Rejeté'. Type d'événement inferred
	Reçu joint	Représente le moment où un reçu est associé à une dépense, soit automatiquement via la correspondance OCR, soit manuellement par l'utilisateur. Ceci est enregistré lorsque le fichier de reçu est lié avec succès à l'enregistrement de la transaction.
Pourquoi c'est important Le suivi de cette activité aide à identifier les retards causés par des documents manquants. C'est une étape clé pour garantir la conformité et la préparation à l'audit. Où obtenir Enregistré dans l'historique des dépenses ou des transactions lorsqu'un reçu est téléchargé ou mis en correspondance. Vérifiez la présence d'un événement de création de pièce jointe ou d'un indicateur signalant 'receipt_attached'. Capture L'événement est créé lorsque le système lie une image ou un fichier de reçu à l'enregistrement de dépense. Type d'événement explicit
	Remboursement planifié	Pour les dépenses personnelles (hors-poche), le montant approuvé a été mis en file d'attente pour le traitement du paiement. Cet événement indique que la dépense a passé toutes les approbations et est prête à être remboursée.
Pourquoi c'est important Ce jalon sépare le processus d'approbation du processus d'exécution du paiement. Il aide à isoler les retards qui se produisent dans le traitement des paiements par rapport à ceux qui surviennent dans les approbations. Où obtenir Probablement déduit du changement de statut de la dépense en 'Remboursement en attente' ou 'Prêt pour le paiement' après l'approbation finale. Peut également être un événement explicite si les paiements sont traités par lots. Capture Dérivé d'un changement de statut en 'Prêt pour le paiement' ou de la création d'un enregistrement dans une table de lot de paiement. Type d'événement inferred
	Révision du responsable en attente	La dépense a été soumise et est maintenant en attente d'examen par le manager direct de l'employé. Cet état est déduit lorsque le statut de la dépense passe à 'En attente d'approbation du manager' ou une valeur similaire après la soumission.
Pourquoi c'est important Identifie le début de l'étape d'approbation par le responsable. L'analyse du temps passé dans cet état est essentielle pour mesurer et améliorer les temps de cycle d'approbation des responsables. Où obtenir Déduit d'un changement de statut sur l'objet de dépense vers un état tel que 'En attente d'approbation' et d'une affectation à la file d'attente d'un responsable. Nécessite le suivi de l'historique des statuts. Capture Dérivé de l'horodatage lorsque le statut de la dépense devient 'En attente d'approbation par le responsable'. Type d'événement inferred
	Révision financière en attente	Une dépense approuvée a été escaladée et est maintenant en attente d'examen par l'équipe financière ou comptable. Cela se produit généralement pour les dépenses de grande valeur ou celles signalées pour des violations de politique. L'activité est déduite d'un changement de statut.
Pourquoi c'est important Marque le début du cycle d'examen financier. La mesure de la durée de cette étape aide à évaluer la charge de travail et l'efficacité de l'équipe financière, et identifie les opportunités d'automatisation. Où obtenir Déduit d'un changement de statut sur l'objet de dépense vers 'En attente d'approbation financière' après l'approbation du responsable. Cela nécessite un accès à l'historique des statuts de la dépense. Capture Dérivé de l'horodatage lorsque le statut de la dépense est mis à jour en 'En attente de révision financière'. Type d'événement inferred

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de Ramp

Étapes

Connectez-vous à votre compte Ramp avec les privilèges Admin ou Bookkeeper.
Naviguez vers la section Transactions depuis le menu de gauche. Cette vue contient toutes les dépenses par carte d'entreprise.
Appliquez les filtres souhaités aux données. Au minimum, définissez une Plage de dates pour la période que vous souhaitez analyser. Vous pouvez également filtrer par d'autres propriétés comme le statut (Status), la catégorie (Category) ou le département (Department) pour affiner la portée si nécessaire.
Cliquez sur le bouton Exporter situé en haut à droite de la liste des transactions.
Dans la fenêtre d'exportation, sélectionnez Transactions comme type d'exportation et CSV comme format. Téléchargez le fichier et nommez-le transactions_export.csv.
Ensuite, naviguez vers la section Remboursements depuis le menu de gauche. Cette vue contient toutes les dépenses personnelles (hors-poche) soumises par les employés.
Appliquez la même plage de dates que celle utilisée pour l'exportation des transactions afin d'assurer la cohérence des données.
Cliquez sur le bouton Exporter et téléchargez les données de remboursements au format CSV. Nommez ce fichier reimbursements_export.csv.
Placez les deux fichiers CSV exportés (transactions_export.csv et reimbursements_export.csv) dans le même répertoire que le script Python fourni.
Exécutez le script Python. Le script chargera les deux fichiers, transformera les données en créant une ligne distincte pour chaque événement commercial, et les fusionnera en un seul journal d'événements structuré.
Le script produira un fichier nommé ramp_event_log.csv. Ce fichier est formaté conformément aux exigences de ProcessMind.
Téléchargez le fichier ramp_event_log.csv sur ProcessMind pour analyse.

Configuration

Permissions: Vous devez disposer des rôles 'Admin' ou 'Comptable' dans Ramp pour accéder et exporter les ensembles de données complets de transactions et de remboursements.
Plage de dates: Pour une analyse initiale, sélectionnez une plage de dates d'au moins 6 à 12 mois afin de capturer suffisamment de variations de processus. Pour une surveillance continue, vous pouvez utiliser une plage plus courte et plus récente.
Cohérence des données: Assurez-vous d'utiliser exactement la même plage de dates et les mêmes filtres lors de l'exportation des fichiers de transactions (Transactions) et de remboursements (Reimbursements) afin de maintenir un ensemble de données cohérent.
Format d'exportation: Choisissez toujours le format CSV pour les deux exportations, car le script de transformation est conçu pour traiter les fichiers séparés par des virgules.
Nommage des fichiers: Respectez les noms de fichiers transactions_export.csv et reimbursements_export.csv ou mettez à jour les variables de chemin de fichier dans le script de transformation en conséquence.

a Exemple de requête 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}'.")

Étapes

Prérequis et configuration de l'environnement: Assurez-vous d'avoir Python 3.8 ou une version plus récente installée. Installez les bibliothèques Python nécessaires en exécutant pip install requests pandas. Vous devez également avoir un accès administrateur à votre instance Ramp pour générer les identifiants API.
Générez les identifiants API Ramp: Connectez-vous à votre compte Ramp. Naviguez vers Paramètres, puis sélectionnez API Développeur dans le menu latéral. Cliquez sur 'Créer une application', donnez un nom à votre application et configurez les scopes requis. Vous aurez besoin de transactions:read, reimbursements:read et users:read. Une fois créée, copiez en toute sécurité le Client ID et le Client Secret.
Configurez le script Python: Créez un nouveau fichier Python, par exemple extract_ramp_log.py. Copiez le script Python fourni dans ce fichier. Définissez votre Client ID et Client Secret comme variables d'environnement ou directement dans le script à des fins de test. Il est fortement recommandé d'utiliser des variables d'environnement pour la sécurité.
Définissez la plage de dates d'extraction: Dans le script, localisez les variables START_DATE et END_DATE dans le bloc d'exécution main. Ajustez ces dates pour définir la fenêtre temporelle de l'extraction des données. Une période de 3 à 6 mois est recommandée pour une analyse initiale.
Exécutez le script: Exécutez le script depuis votre terminal en utilisant la commande python extract_ramp_log.py. Le script s'authentifiera auprès de l'API Ramp, récupérera les données des points d'extrémité des utilisateurs, des transactions et des remboursements, et gérera automatiquement la pagination.
Comprenez les appels API: Le script récupère d'abord toutes les données utilisateur pour créer un mappage des ID utilisateur vers les noms et les départements. Il récupère ensuite tous les remboursements dans la plage de dates spécifiée. Pour chaque remboursement, il extrait l'historique d'approbation et de paiement.
Transformation des données en journal d'événements: La logique principale du script itère sur chaque remboursement et son historique d'état associé. Il traduit chaque changement d'état, tel que 'MANAGER_APPROVAL' ou 'FINISHED', en une activité distincte comme 'Manager Review Pending' ou 'Reimbursement Executed'. Il récupère également les données de transaction associées pour créer des événements 'Expense Incurred' et 'Receipt Attached'.
Gestion de l'enrichissement des données: Le script enrichit le journal d'événements en ajoutant les détails de l'utilisateur, les informations de département et la catégorie de dépense pour chaque événement, créant un ensemble de données complet pour l'analyse de processus.
Vérifiez la sortie: Une fois le script terminé, il générera un fichier nommé ramp_event_log.csv dans le même répertoire. Ouvrez ce fichier CSV dans un programme de feuille de calcul pour inspecter les données et vous assurer qu'elles ont été extraites comme prévu.
Préparez-vous pour le téléchargement: Le fichier CSV généré est structuré avec les colonnes requises : ExpenseReportId, ActivityName, EventTimestamp, et d'autres attributs recommandés. Ce fichier est prêt pour un téléchargement direct dans la plateforme ProcessMind.

Configuration

API Credentials: Un Client ID et un Client Secret valides sont requis pour l'authentification. Ceux-ci sont générés dans le Dashboard Ramp sous Paramètres > API Développeur.
API Scopes: Le script nécessite des autorisations spécifiques pour accéder aux données. Assurez-vous que les scopes suivants sont activés pour votre clé API : transactions:read (pour les détails des dépenses et des reçus), reimbursements:read (pour le statut de soumission, d'approbation et de paiement), et users:read (pour le nom et le département de l'employé).
Plage de dates: L'extraction est régie par les paramètres START_DATE et END_DATE dans le script. Il est recommandé de commencer par une période récente, comme les 3 à 6 derniers mois, pour maintenir l'ensemble de données initial gérable. Le filtre est appliqué à la date de création du remboursement.
Pagination: Le script gère automatiquement la pagination de l'API en utilisant le curseur starting_after fourni par l'API Ramp. Il récupère les enregistrements par lots (jusqu'à 100 par requête) pour s'assurer que toutes les données dans la plage de dates sont récupérées.
Limitation du débit: L'API Ramp est soumise à des limites de débit, généralement 600 requêtes par minute. Le script fourni est généralement efficace, mais pour des ensembles de données extrêmement volumineux, vous devrez peut-être introduire de petits retards entre les appels API si vous rencontrez des erreurs de limitation de débit.

a Exemple de requête 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()

Étapes

Connectez-vous à votre compte Ramp avec les privilèges Admin ou Bookkeeper.
Naviguez vers la section Transactions depuis le menu de gauche. Cette vue contient toutes les dépenses par carte d'entreprise.
Appliquez les filtres souhaités aux données. Au minimum, définissez une Plage de dates pour la période que vous souhaitez analyser. Vous pouvez également filtrer par d'autres propriétés comme le statut (Status), la catégorie (Category) ou le département (Department) pour affiner la portée si nécessaire.
Cliquez sur le bouton Exporter situé en haut à droite de la liste des transactions.
Dans la fenêtre d'exportation, sélectionnez Transactions comme type d'exportation et CSV comme format. Téléchargez le fichier et nommez-le transactions_export.csv.
Ensuite, naviguez vers la section Remboursements depuis le menu de gauche. Cette vue contient toutes les dépenses personnelles (hors-poche) soumises par les employés.
Appliquez la même plage de dates que celle utilisée pour l'exportation des transactions afin d'assurer la cohérence des données.
Cliquez sur le bouton Exporter et téléchargez les données de remboursements au format CSV. Nommez ce fichier reimbursements_export.csv.
Placez les deux fichiers CSV exportés (transactions_export.csv et reimbursements_export.csv) dans le même répertoire que le script Python fourni.
Exécutez le script Python. Le script chargera les deux fichiers, transformera les données en créant une ligne distincte pour chaque événement commercial, et les fusionnera en un seul journal d'événements structuré.
Le script produira un fichier nommé ramp_event_log.csv. Ce fichier est formaté conformément aux exigences de ProcessMind.
Téléchargez le fichier ramp_event_log.csv sur ProcessMind pour analyse.

Configuration

Permissions: Vous devez disposer des rôles 'Admin' ou 'Comptable' dans Ramp pour accéder et exporter les ensembles de données complets de transactions et de remboursements.
Plage de dates: Pour une analyse initiale, sélectionnez une plage de dates d'au moins 6 à 12 mois afin de capturer suffisamment de variations de processus. Pour une surveillance continue, vous pouvez utiliser une plage plus courte et plus récente.
Cohérence des données: Assurez-vous d'utiliser exactement la même plage de dates et les mêmes filtres lors de l'exportation des fichiers de transactions (Transactions) et de remboursements (Reimbursements) afin de maintenir un ensemble de données cohérent.
Format d'exportation: Choisissez toujours le format CSV pour les deux exportations, car le script de transformation est conçu pour traiter les fichiers séparés par des virgules.
Nommage des fichiers: Respectez les noms de fichiers transactions_export.csv et reimbursements_export.csv ou mettez à jour les variables de chemin de fichier dans le script de transformation en conséquence.

a Exemple de requête 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}'.")

Votre Template de Données de Gestion des Dépenses

Votre Template de Données de Gestion des Dépenses

Attributs de gestion des dépenses

Activités de gestion des dépenses

Guides d'extraction

Exportation CSV intégrée des transactions et remboursements de Ramp

Étapes

Configuration

a Exemple de requête config

Extraction par script Python via l'API développeur Ramp

Étapes

Configuration

a Exemple de requête python

Synchronisation d'intégration entre l'entrepôt de données Ramp (Snowflake/BigQuery)

Étapes

Configuration

a Exemple de requête config

Prêt(e) à démarrer ?

Débloquez l'efficacité : Optimisez la gestion des dépenses Ramp dès aujourd'hui

Votre Template de Données de Gestion des Dépenses

Votre Template de Données de Gestion des Dépenses

Attributs de gestion des dépenses

Activités de gestion des dépenses

Guides d'extraction

Exportation CSV intégrée des transactions et remboursements de Ramp

Étapes

Configuration

a Exemple de requête config

Extraction par script Python via l'API développeur Ramp

Étapes

Configuration

a Exemple de requête python

Synchronisation d'intégration entre l'entrepôt de données Ramp (Snowflake/BigQuery)

Étapes

Configuration

a Exemple de requête config

Nous respectons votre vie privée

Prêt(e) à démarrer ?

Débloquez l'efficacité : Optimisez la gestion des dépenses Ramp dès aujourd'hui